システム開発の案件に入るとき、発注側から「現状のシステムをご説明します」と言われる場面がある。だが実際に出てくる情報は、担当者がその場で思い出せるもの、手元にある古い資料、ベンダーから受け取ったまま読んでいないドキュメント——そういうものの寄せ集めであることが多い。発注側に悪意があるわけではない。「整理されていない」という自覚すらないまま、説明しているのが実態だ。現行調査をする立場から見ると、発注側が把握できていない情報にはパターンがある。よく見る5つを整理した。パターン1：担当者の頭の中にしかない仕様がある設計書は存在する。だが、実際の動きと設計書の記述がどこかで乖離している。「この処理、設計書だとAと書いてあるけど実際はBで動いてますよ。あのとき変えたんです」——そういう発言が現行調査中に出てくる。その「あのとき」がいつで、なぜ変えたのか、誰もドキュメントに残していない。担当者が在籍しているうちはなんとかなる。だがその担当者が異動・退職した瞬間に、システムの「本当の仕様」が組織から消える。これは小規模なシステムに限らない。長く運用されてきた基幹系ほど、このパターンが蓄積している。パターン2：保守ベンダーに聞かないと何もわからない状態になっている「それはベンダーさんに確認しないと」——現行調査中に発注側担当者からこの言葉が出る回数が多いほど、依存度が高い。保守を外部に委託すること自体は問題ではない。問題は、発注側の内部に「ベンダーが言っていることの妥当性を判断できる人間がいない」状態になったときだ。こういう状態では、ベンダーからの見積もりや提案に対して是非を判断できない。「高いと思うけど、わからないから頼む」という意思決定が繰り返される。システムに関する意思決定の主導権が、実質的に外部に移っている。現行調査でこのパターンを発見したとき、最初にやるべきことはベンダーへの聞き取りではなく、「発注側が自分の言葉でシステムを語れる状態」を作ることだ。パターン3：過去の改修履歴が追えないシステムは一度作ったら終わりではない。業務の変化、法改正、トラブル対応——さまざまな理由でスポット改修が繰り返される。問題は、その改修の経緯が残っていないことだ。「なぜこの処理だけ例外的な動きになっているのか」を調べようとすると、コードを読むしかない。コードを読んでも、「意図」はわからない。改修履歴が追えないシステムで新たな改修をすると、思わぬところで既存の処理と衝突する。「なぜこのバグが出るのか」の原因特定に時間がかかるのは、多くの場合このパターンが根本にある。また、「この動きはバグなのか、仕様なのか」が判断できなくなることも起きる。現場が「そういうものだ」と受け入れているだけで、本来は意図していない挙動のまま動いているケースも少なくない。パターン4：本番環境と設計書が別物になっている設計書の最終更新日が数年前、というケースはよくある。その後も本番環境は改修され続けているが、設計書は更新されていない。現行調査の現場では「設計書は参考程度に見てください」という言葉をしばしば聞く。参考程度にしか使えない設計書は、要件定義では使えない。このパターンが厄介なのは、設計書の記述を信じてヒアリングを進めると、途中で「実際と違う」ことが発覚するためだ。設計書ベースで議論していた時間が無駄になり、調査がやり直しになる。現行調査では「設計書に書いてあること」より「本番で実際に動いていること」を先に把握する必要がある。設計書は、差分を確認するための照合材料としてのみ使う。パターン5：業務プロセスとシステム機能の対応関係が語れないシステムは業務のために動いている。だが発注側の担当者に「この業務プロセスで、どのシステム機能を使っていますか」と聞くと、答えられないことがある。「この画面を開いて、ここに入力して——」という操作手順は言える。だが「なぜその入力が必要なのか」「そのデータが後工程のどこに使われているのか」は、把握されていない。この状態でシステム刷新の要件定義を始めると、「今と同じ機能が欲しい」という要求になりやすい。業務上本当に必要な機能と、「今使っているから必要だと思っている機能」の区別がつかないまま議論が進む。結果として、不要な機能を作り込んだシステムができあがる。あるいは本当に必要な機能が抜け落ちて、稼働後に発覚する。これらのパターンがある状態で要件定義を始めると5つのパターンは、組み合わさって現れることが多い。設計書は古く、改修履歴もなく、担当者の頭の中にしか仕様がない——そういう状態が「普通」として積み重なっている。この状態で要件定義を始めると、ヒアリングのたびに「後で確認します」が積み上がる。確認に時間がかかり、確認結果が出た頃には議論の前提が変わっている。スケジュールが後ろに延びる。現行調査は、「今のシステムが何をやっているか」を発注側が自分の言葉で語れる状態を作るプロセスだ。この状態ができてから要件定義に入ることで、後工程の精度が変わる。現行調査をどこから手をつければよいか、自社のシステムがどのパターンに当てはまるかを整理したい場合は、現行調査（AI仕様解析）サービス からご相談ください。