「要件が固まらないのは発注側のせいだ」とシステム開発の現場では言われる。一方、発注側は「ちゃんと決めたのに、思っていたものと違うものができた」と嘆いている。この構造はシステム開発の世界で幾度も繰り返されてきた。要因は「意思決定が遅い」ではなく、もっと構造的な場所にある。「決めてくれない」の本質要件定義の迷走は、大半の場合、発注側が「決めたくない」のではない。「決めるための情報を持っていない」状態でヒアリングの席に座っていることが原因だ。たとえば、「この機能、今のシステムではどうなってますか」と聞かれたとき、前任者から引き継いだ構造も、自分たちの業務でなぜこうなっているかも、把握できていない担当者は多い。さらに言えば、把握できていないと担当者自身は思っていないことが多い。その状態で「今のシステムと同じ機能が欲しい」としか言えないのは、システム開発サイドの理屈から言えば、業務理解の解像度が低いため。「それ以外の言葉を持っていない」からだ。「再度ヒアリング」が発生するメカニズム高頻度で起きるのは次のパターンだ。ヒアリングで要件を聞く→発注側が「少し考えます」と言う→次回が来ると「やっぱりこうしたい」と逆の要求が出る→そこからまた議論…これは発注側の優柔不断ではなく、検討の度に新しい情報が入ってくるから起きる。「確認します」の際に、発注側はシステムの現状を改めて見ている。そこで初めて気づくこともある。要求がその都度変わるのは、多くの場合これが原因だ。言語化ができれば、要件定義の山が動く発注側が「自分たちのシステムが今何をやっているか」を実際に説明できれば、ヒアリングの質が一変する。「機能」ではなく「業務プロセス」で話せる。「画面」ではなく「この取引で何が起きているか」を話せる。「今のシステムでできること」より「自分たちの業務で何が必要か」を語れる。この状態になると、要件定義での振り出しに戻される「再度ヒアリング」が激減する。発注側の回答に具体性が生まれ、議論の前提が共有される。「現行調査」はそのためのプロセスだ現行調査は、単にドキュメントを閲覧する作業ではない。発注側が「自分たちのシステムを自分たちの言葉で語れる状態」を作り出すプロセスだ。具体的には、業務フローとシステム機能の対応関係を整理し、現在の操作手順と本当の流れの正解を確認し、「なぜそうなっているのか」の背景を語れる、SIerと会話ができる人間を発注側の内部に作り出すことだ。この状態ができてから要件定義に入ることで、後工程の精度が変わる。長年繰り返されてきた迷走が、そこで切れる。要件定義の前に自社のシステム現状を整理したい場合は、現行調査サービスからご相談ください。