企画提案編：真の目的を達成する

仮説をたて、検証を繰り返すことで、真の目的から外れないプロジェクトにすることができる。

　ユーザーの声を元に設計し、開発しても、期待される効果をあげられないばかりか、
　結果的にユーザーから使い物にならないと評価され、最後には、使われなくなるシステムが実は非常に多いのです。
　なぜ、そのようなことが起こるでしょうか？

　それは使う人の存在を忘れ、システム開発が目的になってしまったからです。

　システムは操作する人間がいて初めて成り立つものです。
　人の動きを忘れたシステムはいくら優れた機能を持っていても意味がありません。
　「このシステムは機能が優れているから、それを使った人は大変便利だ」という独りよがりの
　思いに陥ることがあります。ほんとうに使う人に便利なのでしょうか？
　ただ、根拠もなしに、「当然そのはずだ」と思い込んでいないでしょうか？

　なぜ、そのような独善的な考えに陥ってしまうかと言うと、「運用面での検証不足」が原因です。
　運用している現場をじゅうぶん理解せず、頭の上で考えたまま開発してしまう場合がそうです。
　このようなシステムでは運用に入って、現場の人に使ってもらう場面になって初めて使えないことが判るのです。

　独善的な設計者はよく「ユーザーが望んだものを作っただけだ。使えないのは正しく要望を言わなかったユーザーが悪い」と主張します。
　しかし、使う人（ユーザー）も実際の動くシステムを見るまでは想像で話しているわけですから、
　最初からピタッと的を得た要望を出すことができないものです。
　設計者と同様、ユーザーもすぐにはシステムの姿を定義できないのです。

　さらに難しいのは最近のシステムが企業の経営戦略や情報戦略支援に変わってきていることです。
　単純な業務コスト削減だけが目的ではないので、従来通りの考え方では失敗する可能性が高いと言えます。
　ユーザーの立場からも見ても、システムの目的が複雑で判りにくく、
　どのようなシステムを開発すべきかが見えてこないのです。

　このような状況を回避するために「仮説と検証」をお奨めします。
　頭で考えた設計は単なる仮説だと考えて見ます。
　仮説が正しいかどうかは検証して見ないとわかりません。
　従来は設計の正しさは本稼動時に初めて検証されることが多いでした。
　設計した成果物を使って、できるだけ早く、できる限り本番に近い形で実地検証します。

　システム開発における仮説検証の注意点：
　・検証期間は各フェーズの最後、１割程度の期間を想定します。
　　例えば３ヶ月の設計期間ならば１週間程度です。
　　検証の結果、設計の見直しや修正を行う可能性がありますから、日程的に少し余裕を見ておきます
　・設計のすべてを検証することは、ほとんど不可能ですから、検証内容は絞り込みます。
　　システムの目的の中で最もキーになる機能、あるいは初めての機能を中心に検証します。
　・検証の具体的な作業内容はケースバイケースで特に決まった方法があるわけではありません。
　　プロトタイプ的なミニシステムができれば良いですが、無理ならば紙と鉛筆でもできます。
　　現場の運用も本番をシミュレートできるのが理想的ですが、
　　だめなら仮想的な机上の検証ですませるしかない場合もあります。
　　本番に近い状況であれば、あるほど検証が効果は高くなります。
　・検証によって仮説（設計）を修正することを忘れないようにします。
　　検証は設計の正しさを証明するために実施するのではなく、
　　仮説の問題点を洗い出し、改善するためにやるのです。
　・システムの目的、プロジェクトの狙いが達成できるかを検証項目に入れておきます。

　こうすることで、プロジェクトの真の目的を外さない様にシステムを開発することができます。