あたりまえの話ですが提案するシステムや機能に対し、お客様は何らかの効果を期待されて依頼されているものです。具体的な実現機能を明確にする前に、期待される効果について確認することが要件の本質を掴むのに役立ちます。
（「何を提供するか？：手段」より「何のために提供するのか？：目的」の確認を優先するという話）
企業が期待する４種類の効果
企業が投資を行う場合、その投資目的として最上位にあるものは「自社の永続的な繁栄」です。なのですべての投資はこの目的に繋がっていなければならないはずですよね。
でも「自社の永続的な繁栄」だとちょっと漠然としすぎていてイメージが掴めないと思いますので、もう1段階ブレークダウンしてみると以下の４つに分類することができます。
期待効果１：売上が増加する
->例：営業管理システムの構築、オンラインショップシステムの構築・・・
期待効果２：経費が削減される
->例：交通費精算システムの構築、テレワーク環境の構築・・・
期待効果３：各種ルールに準拠する
->例：JSOX対応、監督官庁からの指導対応・・・
期待効果４：リスクが回避できる
->例：セキュリティ機能の強化、災害対策・・・
仮に現在提示されている要件の効果が、上記４つのどれにも紐づけられないとすれば「どれに紐づければいいのか？」を早急に確認する必要があります。（もちろん複数の効果に紐づく場合もあります）
お客様の期待する効果の根幹を理解していなければ適切な提案書を書くことは難しいですし、仮に受注できたとしてもお客様の期待とはズレたものが出来上がってしまいクレームになるケースもあります。（「言った/言わないの論争」ってイヤですよねぇ）
逆に期待する効果の根幹部分をしっかりと理解していれば、適切な提案書が書けるだけでなく、「そういうご期待でしたらこっちの方がいいですよ」といったお客様が考えるよりもより効率的な対応策を提示するハイレベルな提案書が書ける可能性も出てきて、受注確率が格段に上昇します。
さらには受注後のプロジェクトもスムースに実施できるようになります。
システムはあくまで期待した効果を得るための道具です。期待する効果を認識しなければ適切な道具を提案することも、提供することもできないことを強く認識してください。
ちょっと注意！！！
提案には「期待の根幹部分をしっかりと理解する必要がある」と書きましたが、システム屋が提供するのはあくまで機能です。ですので契約上という話になると、システム屋がコミットすべきは「機能の実装」までです。
提供された「機能」を使って期待していた効果を上げるのはあくまでお客様の責任なので、契約内容には「お客様の期待」についてはあまり記載すべきではない場合もあることを認識してください。
コメント