さて、住宅の建築と比較して考えていた、ＩＴシステム開発プロジェクトの完成結果を要件定義時点でクライアントやユーザーにどう伝えるかについて考えています。
よりよく理解されるために、ユーザーインタフェース部分のモックアップを作成し、説明するという手法があります。この方法はユーザーが明確なイメージを持つことができるため結構有効なので良く使われるものです。
欠点は、モックアップはあくまでモックアップであり、紙芝居にすぎないため、ユーザーの想像力に頼らざるを得ないことです。
また下手なモックアップは、それ自体が完成形とのギャップを作り出す原因になってしまい、後々のトラブルの種になってしまう可能性があることです。
と、このように完全スクラッチ開発の場合、クライアントやユーザーと未来の姿を共有する有効な方法論はあまり多くはありません。原因は、ユーザーが限られた資料を元に想像力を発揮して、未来の姿をイメージするしかないからです。
しかも、想像力は個人に差があるため詳細部分について明確に共通の理解を得ることは至難の業と言ってもいいくらいです。
そのため、ITプロジェクトのトラブルの原因の多くは、要件定義フェーズでの作業のクオリティに依存することになります。
通常これをどう解決しているかというと、結局双方の信頼関係による（大人の）合意という形を取ることになってしまいます。
結局、曖昧な基準を基に曖昧な”何か”に依存した判断をするしかないのです。それでも、要件を定義する側と、システムの未来のユーザーとの関係が上手く行っている時には大きな問題となることはありません。
ただ一度その関係がこじれ始めると、そもそも「（にわかにつくられた）信頼関係」という、とてもあやふやな土台に立つものですから、再び充分な信頼関係を構築するには大きな労力を必要としますし、必ずしも再構築できるとは限らないという、とても困った状況に簡単に陥ることになります。
言いたいのは、どんなに頑張っても要件定義書などで未来の業務の姿を、ユーザーに理解してもらうのには限界があるということです。
もちろんこれには、要件定義を主導するエンジニアの責任ばかりではなく、ユーザー側の意識やITシステムや、プロジェクトマネジメントに対する、リテラシーの問題があることも付け加えておきます。
ではこの様な状況に打つ手はないのでしょうか。もちろんそんなことは無いわけで、これまでいろいろな解決のための手法が考えられてきました。その最たるものが、アジャイル型の開発手法です。
この問題、次回さらに掘り下げて行くことにします。