仕様書を厚くしても手戻りはなくならない――要件を確定する前に、同じ場面へ同じ答えを出せるか

「注文はキャンセルできる」。仕様書にはそう書いてあり、発注側も開発側も承認した。しかし完成した画面を見て、倉庫担当者が「出荷作業に入った注文まで取り消されては困る」と言う。営業は「顧客との契約では、この時点まで受け付ける」と答える。

この仮の例で足りなかったのは、キャンセル機能という単語ではない。どの状態で、誰が、何を取り消せるかという共通の判断だ。文書のページ数を増やすだけでは、この食い違いを解消したことにならない。

本稿の問いは、要件をいつ確定して実装へ進め、いつ追加の確認を挟むべきかである。実務調査と政府のサービス開発指針を材料に、具体的な場面に対する答えが一致した範囲は実装へ進め、答えが分かれる重要な境界は、試作や業務上の合意を先に行うという進め方を提案する。要件変更をゼロにする手法を約束するものではない。

手戻りを一つの原因で数えない

修正が発生した事実だけでは、最初の要件定義が悪かったとは限らない。既に存在していた制約を聞き漏らした場合と、開発中に事業方針が変わった場合では、必要な対処が違う。

NaPiREの研究は、10か国228社から得たデータを用いて、要件工学の21の問題と、実務家が認識する原因・影響を分析している。多様な現場における問題の観察であり、特定の改善策を導入して手戻りが何割減ったかを示す介入実験ではない。Naming the Pain in Requirements Engineering

調査の回答は実務家の認識であり、業種やシステムの種類の構成にも偏りがある。研究自身も母集団の代表性を確定できないと説明するため、問題の順位を日本の案件へそのまま当てはめることはできない。論文本文・5.4節

本稿では、手戻りを次のように分けて考える。これは調査の分類をそのまま転載したものではなく、要件の確認方法を選ぶための編集上の整理だ。

利害の衝突を、ヒアリング不足として扱うと会議だけが増える。逆に、解釈の違いを上位者の決裁だけで終えると、実装する人に曖昧さが残る。先に原因を分ければ、必要な作業を選べる。

「翌営業日」へ、三人が同じ日付を答えられるか

要件を確かめる際、本稿が勧めるのは、抽象的な文章へ賛成を求めることより、具体的な入力と結果を一緒に見ることだ。

例えば「翌営業日までに処理する」という要件なら、金曜日の締切後に受けた注文、祝日のある週、拠点をまたぐ注文を用意する。処理期限はいつか、どの時点を受付とするか、締切を過ぎた注文を誰に知らせるか。同じ場面に異なる答えが返るなら、文面への同意はできていても、実行するルールは一致していない。

すべての例外を列挙する必要はない。先に確かめたいのは、答えが変わる境界である。締切の直前と直後、出荷前と出荷後、権限のある人とない人。境界の違いが、データの持ち方や他システムとの接続まで変えるなら、後で画面だけを直して済むとは限らない。

ここで必要なのはテスト担当者だけではない。実際に例外を処理する人、顧客へ説明する人、最終判断の責任を負う人も参加する。現場が日常的に補っている作業を、標準の業務説明だけから発見するのは難しいからだ。この参加方法自体に、一律の工数削減率が実証されているわけではない。

試作は、きれいな画面を見せるために使わない

試作品を作っても、「使いやすそうですね」で終われば重要な不確実性は残る。画面の色が問題なのか、顧客が必要な情報を入力できないことが問題なのかで、作るべき試作は違う。

英国政府のalpha段階の指針は、最もリスクの大きい仮定を試すことに重点を置き、利用者の行動全体や製品全体を試作する必要はないとする。英国の公共サービス開発における指針であり、その期間や工程を日本企業へ一律に適用する根拠ではない。GOV.UK「How the alpha phase works」

この考え方を使うなら、試作の前に「何が分かれば次へ進めるか」を書く。キャンセル機能なら、顧客がボタンを見つけられるかと、出荷中の注文を取り消せる業務が成立するかを分ける。前者は操作の試作で調べられる。後者は倉庫の処理や外部接続を含む確認が必要になる。

画面のデモだけで業務全体を検証したと扱わないことが重要だ。操作の理解が進んでも、データの整合性や例外時の責任が未確認なら、その点は残っている。試作の成果は作った機能数より、どの仮定について答えが出たかで記録する。

アジャイルなら、要件の問題を後から解消できるのか

短い周期で見直せる開発でも、曖昧な言葉が自動的に共通理解へ変わるわけではない。

Wagnerらは、NaPiREの一環として92組織の回答からアジャイル開発の要件実務を分析し、不明確な要件やコミュニケーションの問題を報告している。要求とコードの対応やテストとの連携も扱われており、アジャイルだから要件を記録しないという捉え方とは異なる。先ほどの調査と同じ研究系列であり、独立した二つの追試として数えるべきではない。Requirements Engineering Practice and Problems in Agile Projects

本稿の判断案では、開発方式の名称より、誤解に気付いたときの変更範囲を見る。表示文言や操作順の変更なら、小さく実装して確認しやすいことがある。取引の識別方法や金額確定のタイミングが複数システムに及ぶなら、早い段階で関係者と具体例を確かめる価値が高い。

変更を歓迎することと、影響を記録しないことは違う。合意した内容を変えるなら、何を変え、どこへ影響し、誰が判断したかを残す。その記録が、次の確認を最初からやり直さずに済ませる材料になる。

同じキャンセル機能でも、先に作るかが変わる

冒頭の仮の会社で、注文は出荷前に限って全額キャンセルできると既に決まっており、システムから出荷状態を確実に取得できるとする。通常、出荷直前、出荷後の期待結果も一致している。残る争点がボタンの位置なら、実装して操作を確かめる案を選びやすい。

一方、営業は出荷開始後も取り消せると考え、倉庫は開始後に止められず、経理には送料の扱いも未決という条件ならどうか。先に画面を完成させても、取消可能な状態、返金額、必要なデータが後から変わり得る。この場合は、業務方針を決め、処理が成立するかを確かめる方を優先する。

それでも開発全体を止める必要があるとは限らない。独立して確定できる注文の参照画面などは、未決部分との境界を確認して進められる。保留するのは不確実な判断に依存する範囲であり、すべての要件が完全に分かるまで待つという意味ではない。

後から顧客向けの新しい返品制度が決まった場合は、さらに別の判断になる。初期の聞き漏らしとして責めるのではなく、制度変更の価値と開発・運用への影響を比較する。必要な変更を防ぐことまで、手戻り削減の目標に含めない。

要件を確定するのは、問いが消えたときではない

すべての疑問がなくなるまで検討を続けると、検証のための検証が増える。確定の目安として、本稿は三つの確認を提案する。対象業務の重要な場面に同じ期待結果を答えられること、未決事項の影響範囲が分かること、その残りを誰がいつ判断するかが決まっていることである。

実装後に修正が出たら、件数だけでなく原因を記録する。以前からある業務制約の聞き漏らしが減ったのか、境界の解釈違いが残っているのか、事業上必要な変更が増えたのか。納期前だけ変更を受け付けず件数を下げても、良い要件定義になったとは言えない。

具体的な場面への答えが一致し、未決部分を切り離せる範囲は作り始める。答えが割れ、変更が業務の広い範囲へ波及する部分は先に確かめる。 仕様書の厚さより、この境界を共有することが、次の実装へ進むかを判断する実務上の手掛かりになる。