要件定義の手戻りを減らすには？ 仕様書より業務場面の合意を確認する

「注文はキャンセルできる」。仕様書にはそう書いてあり、発注側も開発側も承認した。ところが完成した画面を見て、倉庫担当者は「出荷作業に入った注文まで取り消されては困る」と言い、営業は「顧客との契約では、この時点まで受け付ける」と答える。要件定義の手戻りを考えるための仮想例です。文面への同意と、実際の業務で同じ判断ができることは、どこで分かれるのでしょうか。

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

手戻りをすべて防ぐことはできない。それでも、実装の前に確かめられる食い違いはある。まず、仕様書の言葉を具体的な業務場面へ戻してみる。

「翌営業日」と書けば、三人は同じ日付を答えるか

取消の期限や処理の日付は、仕様書では短い言葉で表せる。その言葉を、実際の注文へ当てはめるとどうなるだろう。

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

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

日付の答えが分かれたら、休日の定義、受付の起算時点、例外の扱いのうち、何が未合意かを特定する。営業日という言葉を別の言葉へ置き換えるだけでは、同じ場面で同じ処理になるかは分からない。決まった条件を具体例に戻して確かめることで、合意を実装とテストに使える形へ近づける。

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

業務の方針と、システムで実現する条件を分ける

具体例で答えが割れたとき、誰へ戻して確認するか。ここで、業務の方針とシステムの仕組みを分けておくと、確認先を絞りやすい。

要件定義は、画面に付ける機能を決めるだけの作業ではない。業務で実現したいことを明らかにし、それをシステムの働きや制約へ具体化して、関係者と合意する工程である。IPAの解説も、ビジネス要求を定義し、機能・非機能のシステム化要求へ落とし込み、関係者と合意するという流れを示している。ここではこの整理に沿って考える。IPA「要件定義とは」・要件定義の進め方

キャンセルの例なら、受け付ける期限と返金の方針が業務側の判断であり、その条件を判定する出荷状態の取得や、取消と返金を処理する仕組みがシステム側の検討になる。方針が未決なのか、決まった方針を実現できるかが未確認なのかで、次に確認する相手も変わる。

この仮の会社が、製品を選ぶ前に取消条件を整理する場面を考える。次の表は期待結果と、まだ決めていないことを分けた仮想の記録だ。倉庫作業中の行には、最終判断までの扱いも書く。未決事項が残った行を「取消機能に対応」とだけ採点すると、候補製品ごとに違う前提で比較してしまう。

表は左右にスクロールできます。

システム担当が答えるのは、この方針を候補製品で実現できるかという問いである。送料を誰が負担するかという業務方針まで、画面の標準動作で決まったことにはしない。方針がそろった範囲を同じ代表業務による製品の試用へ渡し、未決の範囲は採点を保留する。

答えが違う理由は、聞き漏らしだけではない

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

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

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

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

合意できた範囲から、実装へ進む

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

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

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