要件定義の技術 — 「言われた通り」が失敗する理由

依頼者の言葉をそのまま実装すると、なぜ動くのに使われないものができるのか。顕在要求と潜在要求、ユースケース、非機能要件の数値化、そして曖昧さをその場で炙り出す質問の型を、前提知識ゼロから解説します。

4分の1インチのドリルと、4分の1インチの穴

マーケティングの古典に「人はドリルが欲しいのではない、穴が欲しいのだ」という言い回しがあります。依頼者が口にするのは道具の名前で、本当に必要なのは結果のほうだ、という話です。

ソフトウェアの現場でも同じことが起きます。「CSVでダウンロードできるボタンを付けてほしい」と言われて、その通りボタンを付ける。動くものは納品され、検収も通る。ところが半年後、その機能はほとんど使われていません。改めて聞くと、依頼者がやりたかったのは「月末に経理へ数字を渡すこと」で、CSVは相談の時点で思いついた唯一の手段だっただけでした。本当に効いたのは会計システムへ自動で送る仕組みだったかもしれません。

「言われた通りに作りました」は、失敗の弁明としては最も通りやすく、最も何も救わない言葉です。要件定義とは、依頼者の言葉を鵜呑みにも無視にもせず、その裏にある目的まで降りたうえで、検証できる形に書き直す作業のことです。書き直した結果が元の言葉と同じになることもありますが、確かめたうえで同じなのと確かめずに同じなのとでは、後で起きることがまったく違います。

要求は3階建てになっている

依頼者の頭の中にあるものは、口に出される順に並んでいるわけではありません。おおまかに3つの層に分かれています。

顕在要求は、依頼者が自分で言葉にできるものです。「CSVを出したい」「ログイン画面が欲しい」。これは聞けば出てきます。ただし出てきた時点ですでに、依頼者なりの解決策の形をしています。

潜在要求は、あれば喜ぶのに自分からは言えないものです。理由は単純で、そういうものが作れると知らないからです。「毎月20分かけて手で転記している」という事実は、聞き方さえ変えれば出てきます。しかし「その転記を自動化してほしい」という要求の形では、まず出てきません。人は自分が知っている選択肢の中でしか要求を組み立てられないからです。

暗黙の前提は、当たり前すぎて言葉にする価値がないと思われているものです。「金額がずれない」「他人の給与が見えない」「保存を押したら保存される」。満たしても誰も褒めませんが、破ると一発で信用を失います。品質工学の狩野モデルはこの非対称性を、当たり前品質（あって当然、無いと不満）と魅力的品質（無くても不満ではないが、あると嬉しい）に分けて説明しています。要件定義で事故になるのは前者で、誰も言わなかったせいで誰も実装せず、リリース後に「そんなの当たり前でしょう」と言われる層です。

顕在要求だけを丁寧に拾って作ると何が起きるか。聞き取れた事例に対しては完璧に動き、聞き取れなかった事例で急に崩れるシステムができます。これは機械学習の過学習とよく似た形をしています。

「要求」と「要件」は別の言葉

日本語だと1文字違いで紛らわしいのですが、この2つは工程が違います。要件工学の国際規格 ISO/IEC/IEEE 29148 は、利害関係者の要求（stakeholder requirements）とシステム要件（system requirements）を明確に別の成果物として扱っています。

• 要求: 依頼者・利用者・運用者が「こうなってほしい」と考えていること。主語は人。
• 要件: そのためにシステムが満たさなければならない条件。主語はシステムで、満たしたかどうかを判定できる。

「経理への転記をなくしたい」は要求です。「システムは、締め日の翌営業日09:00までに、当月分の仕訳データを会計システムのAPIへ送信しなければならない」は要件です。後者は、満たしたかどうかを人によらず判定できます。要件の良し悪しを測る基準はここに尽きます — 読んだ人が全員同じテストを書けるか。

ユースケース: 主語を人に戻す

機能を箇条書きにすると、いつのまにか主語がシステムだけになり、「誰が、何のために、どういう順序で」が抜け落ちます。ユースケースは、それを人の側から書き直す形式です。最低限、次の要素があれば形になります。

• アクター: 誰が。「経理担当者」であって「ユーザー」ではない
• 事前条件: 始まる前に成立していること。「当月の売上が確定している」
• 主シナリオ: うまくいったときの手順を番号付きで。5〜9行に収める
• 代替フロー: 途中で分岐する道。「APIがタイムアウトした場合」
• 事後条件: 終わったときに成立していること。「会計システムに当月分の仕訳が1件以上存在する」

価値の大半は代替フローと事後条件にあります。主シナリオは誰が書いてもだいたい同じものになりますが、代替フローを書こうとすると「そこで失敗したらどうするんですか」という問いが必ず発生し、それが未定義であることがその場で露見します。事後条件は、検収のときに何を見れば合格と言えるかを先に決める作業です。