案件日誌①：受注初日に82箇所を直した

ある企業の基幹業務システムを、全面的に作り替える案件を受注しました。期間は約3ヶ月。要件定義のキックオフは、この日から3週間あとです。

普通なら、この3週間は「資料を読む時間」になります。提案依頼書、現行システムの仕様、業務フロー、過去のやり取り。読んで、理解して、質問リストを作る。それが要件定義の入口だと教わってきました。

今回はそうしませんでした。受注した初日にやったのは、動くプロトタイプを82箇所直すことでした。

要件定義がうまくいかない理由は、だいたい同じところにあります。文字で書かれた要件を、お客様と私たちが同じ意味で読めていない。「一覧で検索できること」と書いてあっても、誰が何を何件見て、何秒で判断したいのかは書いてありません。

この溝は、質問リストでは埋まりません。画面を見せると埋まります。

だから提案の段階で作った動くプロトタイプを、キックオフの場でそのまま触っていただける品質まで引き上げることを、初日の仕事にしました。

この日の作業は、記録に残っている範囲でこれだけありました。

全画面のQAを2巡目まで回して、82件を検出して直しました。1巡目の指摘を直すと、その副作用で別の画面が壊れます。だから2巡目が要ります。

実機を人間の目でウォークスルーして、18件を発見し、14件をその場で直しました。QAで拾えるのは「動かない」までです。「動くけれど使いづらい」は、実際に触らないと出てきません。

約束した機能の抜けを、優先度ごとのギャップ分析で洗いました。提案書で必須と位置づけた要件が、プロトタイプのどこに実装されているか。ないものはこの日に足しました。

そして、これらすべてにAIによるクロスレビューを2巡かけました。自分が書いたものを自分でレビューしても、見落としは同じ場所に残ります。別のAIに違う立場でレビューさせると、自分では絶対に気づかない指摘が出ます。この日の修正のうち何件かは、人間が誰も気づいていなかったものです。

もうひとつ、地味ですが効いた作業があります。

この案件は受注までに234通のやり取りを重ねていました。決定事項も、言い出しにくかった懸念も、条件の変更も、全部この中にあります。ところが実務では、必要になったときに誰も探せません。

そこで全234通を、要約つきの一覧に落としました。日付、相手、要旨、決まったこと。これで「あの条件はいつ、誰が、どういう文脈で言ったか」が数秒で引けるようになりました。

要件定義で一番揉めるのは、仕様の中身ではありません。「そう決めたはずだ」「聞いていない」の食い違いです。その予防にかけた手間は、後から必ず回収できます。

ここまで書いたことを、従来の体制でやろうとしたら何が必要か考えてみてください。

全画面のQAを2巡。実機ウォークスルー。優先度ごとのギャップ分析。指摘の修正と再検証。過去のやり取り234通の要約。普通なら、複数名を張り付けて2週間以上かかる分量です。だから従来のやり方では、この作業は「やらない」ことになります。資料を読んで質問リストを作るだけで3週間が終わる理由は、能力の問題ではなく物量の問題でした。

AIを開発の主力に据えると、この物量が1日に収まります。そして収まった結果として、上流の打ち手そのものが変わります。「プロトタイプはキックオフ後に作るもの」という前提が崩れ、受注した初日から実物を持って会話できるようになる。これは速くなった話ではなく、順番が入れ替わった話です。

キックオフで配るのが紙の資料だけなら、その日は説明の日になります。動くものがあれば、その日は決める日になります。

要件定義の生産性は、最初の会議に何を持ち込めるかでほぼ決まります。そのために初日を使いました。

この連載では、この案件が要件定義に入るまでの記録を全7回で書いていきます。AI駆動開発で営業から要件定義までがどう変わるのかを、うまくいったことも、つまずいたことも、後から間違いだと分かった判断も含めてそのまま残します。

次回は、初回打合せのアジェンダから自社の説明を削った話です。