システム開発プロジェクトにおいて、最上流に位置する要件定義は、その後の成否を決定づける極めて重要なフェーズです。ここで方向性を誤ると、設計や製造といった後続の全工程に歪みが生じ、最終的な成果物が利用者の意図と大きく乖離してしまいかねません。
手戻りによる膨大な追加コストやスケジュールの遅延を防ぐためには、初期段階で「何を作るのか」という明確なゴールイメージを、関係者全員が具体的かつ詳細に共有しておく必要があります。
しかし、システムの発注側と開発側の間には、往々にして言葉の定義や背景知識に埋めがたいズレが存在するものです。専門用語の解釈の違いや、暗黙の了解として明文化されなかった機能要件が、開発終盤になって大きなトラブルの種となるケースは後を絶ちません。
こうした認識の齟齬を埋めるためには、単に要望を聞き取るだけでなく、実際の業務フローや画面遷移を図式化するなど、視覚的な資料を用いた綿密なすり合わせが不可欠だと言えるでしょう。また、「言った言わない」の水掛け論を避けるためにも、合意形成に至るプロセスと決定事項を正確なドキュメントとして残す規律が強く求められます。
真の合意形成とは、単に仕様書への承認印を得ることではありません。互いの描くシステム像が合致するまで、粘り強く対話を重ねるプロセスそのものを指します。
上流工程に十分なリソースを割き、不明確な要素を徹底的に排除することが、結果として最短ルートでのプロジェクト完了につながるはずです。揺るぎない土台の上にこそ、長く使い続けられる堅牢なシステムは構築されるでしょう。