案件日誌③：分からないことを数えて出す

要件定義でよく起きる空回りがあります。「業務の流れを教えてください」と聞き、「だいたいこういう流れです」と返ってくる。議事録には残るけれど、設計には使えない。

この空回りの原因は、聞き方の下手さではありません。質問が抽象的だからです。抽象的な質問には、抽象的な答えしか返ってきません。

プロトタイプを触っていると、必ず手が止まる場所が出てきます。この欄に何を入れるのが正しいのか分からない。この状態のとき次に進めるのは誰なのか決まっていない。この数字はどこから来るのか分からない。

その止まった場所を、全部書き出しました。結果は37項目でした。そして37項目のうち、事前すり合わせの場でお願いすべきものを抜き出して、依頼事項として整理しました。

ここで大事なのは、項目の中身よりも数えたことです。「まだ詰まっていないところがあります」では、お客様も私たちも、残りの量が見えません。37と数えた瞬間に、それは消化できる作業に変わります。

この37項目は、仕様書を読んで作ったものではありません。動くものを操作して、詰まった場所を記録したものです。

この違いは決定的です。仕様書から作った質問は「案件の進捗はどのように管理していますか」になります。実物から作った質問は「この画面でこの状態のとき、次に動くのは誰で、その人は何を見て判断しますか」になります。

後者には、具体的な答えが返ってきます。そして返ってきた答えは、そのまま設計に使えます。ヒアリングの質は、聞き手の技術よりも、その場に実物があるかどうかで決まります。

AI駆動開発で上流が変わるというのは、こういうことです。従来は「実物ができるのは設計が終わってから」でした。だから上流のヒアリングは、想像で質問を作るしかなかった。順番が入れ替わると、ヒアリングの武器が変わります。

要件の抽出は、2方向でやることにしました。

ひとつはお客様の資料を起点にする方向です。いただいた資料に書かれている要求を、漏らさず拾って一覧にする。これは当然やることです。

もうひとつが運用の観点から逆に洗う方向です。この機能は、誰がいつ設定を変えるのか。変えたい人に権限はあるのか。変えたあと、過去のデータはどう見えるのか。資料には書かれないけれど、動かし始めると必ず必要になることを、こちらから並べます。

この2方向をやると、抽出される要求の数が変わります。資料起点だけだと、運用に入った瞬間に「これができない」が出てきます。お客様が悪いのではありません。使い始める前に運用の細部を書ける人は、そもそもいないのです。

この期間に決めたことで、いちばん効きそうなものを挙げます。業務で使う言葉を、すべて設定として管理できるようにしたことです。

現行システムの課題として、こういうものが挙がっていました。選択肢を1つ増やしたいだけなのに、開発会社に依頼して改修が必要になる。費用も時間もかかるので、現場は諦めて運用で吸収する。そして誰も管理していない項目が増えていきます。

そこで、区分や状態の呼び名を画面から追加・改名・並べ替えできるようにしました。お客様が自分で足せるなら、私たちを呼ぶ必要はありません。

ここで慎重に決めた点があります。不要になった選択肢は「削除」ではなく「無効化」にしました。新しく入力するときの選択肢からは消えますが、過去のデータの表示や集計はそのまま残ります。

理由は単純です。過去に選ばれた値を消すのは、履歴の書き換えになってしまうからです。去年その状態だった案件は、去年その状態だったままでなければいけません。画面に出す言葉も「削除」を使わず「無効化」に統一しました。

要件定義の初期に、分かっていないことは山ほどあります。それを曖昧にしたまま進めるほうが不安で、詰まるのも遅れます。

数えて、表にして、相手に見せる。そのほうが、お客様も安心します。残りが見えている作業は、進み具合が分かるからです。

次回は、プロトタイプを本物の作りに寄せた話です。デモが通ることと、作り替えても壊れないことは、別の話でした。