変更を止めずに、合意を守る

架空事例：青葉機材で、予約確定後の期間変更を追加する提案を検討する。識別子、承認者、影響表は、本書の説明用の設定であり、実際のプロジェクトに一律の会議体や文書を要求するものではない。

一行の変更が、小さいとは限らない

要件のレビューが終わった翌週、営業から依頼が来た。「貸出し期間を後から延長できるようにしてほしい」。画面には終了日の入力欄がある。編集できるようにするだけなら、修正は小さく見える。

倉庫は反対した。後ろの期間には、別の顧客の予約が入っているかもしれない。料金も変わる。既に出庫準備を始めているなら、準備票や配送の予定と食い違う可能性もある。

変更の大きさは、書き換える文章の行数や入力欄の数では決まらない。変える約束が、ほかのどの判断や記録に使われているかで決まる。

「もう承認したから変更できない」と断るだけでは、必要な業務への対応を失う。一方、「簡単そうだから」と画面を変えれば、合意した予約の確保条件を壊す。変更管理が必要なのは、この二者択一を避けるためである。

ベースラインは、禁止の壁ではなく比較の基準

承認済みの要件の集合を、識別できる状態で基準として管理する。この基準があれば、変更前後の差、変更理由、影響、合意した版を説明できる。ベースラインは永久に変更しない文書ではない。管理された手順で更新するための比較点である。これはコンプリートテキスト第2章で扱った区別に当たる。1

青葉機材では、予約の確定条件をR-12、予約の期間をR-13、取消し条件をR-14として識別していた。今回の期間変更は、R-13の入力仕様だけに関わるのではない。変更後もR-12の確保条件を満たす必要があるか、R-14の状態制約と矛盾しないかを確かめる。

識別子は、内容を一意に参照する助けである。ただし、識別子があるだけで追跡できるわけではない。R-12の意味を大きく変えたのに版や変更理由が残っていなければ、過去の試験結果が現在のR-12を証明するように見えてしまう。どの時点のどの要求に対して、どの結果が得られたかが必要になる。

記録方法は規模に合わせてよい。一つの管理文書で十分なら、専門ツールや会議体を追加すること自体が目的ではない。必要なのは、合意された内容と実装が無断でずれず、変更の影響を判断できることである。

前向きにたどると漏れが、逆向きにたどると過剰が見える

R-12を「確定予約の機材確保を矛盾させない」とする。その要求に対し、期間重複を判定する業務ルール、予約確定の処理、同時要求の制御、検証ケースが結び付く。要求から実現方法と検証へたどれば、実装や確認の欠落を探せる。

逆に、予約を保存する処理から要求へ戻る。保存の前に、営業担当者の評価点を計算していることが見つかった。依頼にない追加機能なら、根拠を問う必要がある。ただし、直接対応する利用者の要望が見つからないから、即座に不要とは限らない。安全上の制約、外部インタフェースの条件、既に採用した方式から導かれた要求もあり得る。

NASAの要求管理の説明は、親の要求との双方向の対応に加え、設計判断などから導出された要求についても、その根拠と承認を扱っている。対応がないものは、追跡漏れなのか、妥当な導出なのか、根拠のない作り込みなのかを調べる必要がある。2

青葉機材の期間変更を、簡略化して次のように追う。

要求・ルール	関連する設計・業務	変更時に確かめること
確定予約の確保量を矛盾させない	予約判定、同時更新の制御	延長後の全期間で条件を満たすか
許可された状態だけを変更する	状態遷移、権限、倉庫への連絡	出庫準備中を勝手に変更できないか
合意した料金を保存する	料金計算、契約記録、顧客への説明	再計算の対象と確定時点は何か
結果不明時に二重処理しない	受付番号、結果照会、再送	再送で延長を重複適用しないか

これは一対一の対応表ではない。一つの要求が複数の設計要素で実現され、一つの設計要素が複数の要求を支える場合がある。表の行が埋まったことと、要求を十分に満たしたことも同じではない。対応付けの意味をレビューする必要がある。

変更の理由を聞くと、解く範囲が変わる

営業は「期間変更機能が欲しい」と言った。理由を確かめると、顧客が工事日程を変更したとき、いったん取消し、新しい予約を取り直しているという。取消しと再予約の間に枠を他の顧客に取られることがあり、同じ機材を継続して使えない。それが困り事だった。

この目的なら、単に終了日を編集可能にするのではなく、変更が成立するまで元の確保を失わないことが重要になる。変更後の条件を満たせなかった場合、元の予約を維持するのか、取消しに進むのかを決めなければならない。

本事例では、変更できない場合は元の予約を維持し、延長できない理由を示す案を検討する。必要数量が足りないのに元予約まで消すと、営業の困り事を解決できないからである。このとき、「元の確保を維持する」という要求が、期間入力欄の変更よりも重要な設計条件になる。

要求の変更は、利用者の表現をそのまま足す作業ではない。目的を確かめ、既存の合意との関係を整理し、必要な結果へ変換する。新規の要件定義と同じ分析が、変更の場面にも必要になる。

比較表を作る前に、守るべき条件を置く

期間変更の実現方法として、三つの候補が出た。予約画面から自動で変更する。倉庫担当者が確認して変更する。当面は変更機能を追加せず、現行手順を残す。

どの案が最も安いかだけを比べると、現行手順を残す案が有利に見える。しかし、現行手順では失うことのある元予約の確保を、今回の変更要求がどこまで解消すべきかを先に合意する必要がある。必須の結果を満たさない案を、低価格だからという理由だけで採用できるわけではない。

一方、すべての変更を自動化する必要があるとも限らない。本事例では、出庫準備開始前で標準条件を満たす変更だけ自動で扱い、それ以外は倉庫との調整に回す案を考える。範囲を限定すれば、実現する機能を小さくできる。ただし、対象外の依頼を受け渡す業務が必要になることは、第1章と同じである。

比較するのは、機能の多さではない。目的の達成、制約への適合、運用負担、実現の費用と期限、残るリスクである。未知の項目に点数を付けて合計しても、未知が解消されるわけではない。自動変更の同時実行が実現できるか未確認なら、確認すべき技術リスクとして残す。

SAシラバス7-2と8-4は、要件との一貫性や実現可能性に加え、運用・保守の実現可能性も評価に含めている。3 動く案かどうかだけでなく、業務として維持できる案かを考える。

必須、優先、先に作るは同じではない

顧客への回答を速くする画面は、利用者から強く望まれている。予約の重複を防ぐ処理は画面上では目立たない。それでも、後者が予約の成立条件を守るために必要なら、人気が低いという理由で省くことはできない。

必須性は、採用した目的や制約を満たすために欠かせないかという話である。優先順位は、価値、リスク、費用などを踏まえて取り組む順番を決める話になる。開発の順序には、さらに依存関係が加わる。画面を完成させる前に、予約データの扱いを確かめる必要があるかもしれない。

逆に、技術的に先に着手する基盤作業が、利用者へ単独で価値を提供するとは限らない。「最初に実装するから最優先の業務要件だ」と説明すると、目的と手段が逆になる。

青葉機材では、期間変更の自動化全体を初回公開へ入れるかを検討する一方、元予約を失う問題への暫定的な業務対応も比較する。段階的に導入する場合は、それぞれの段階で何を保証し、何をまだ扱わないかを明示する。計画に「対応予定」と書くだけでは、その間の業務は成立しない。

未確定事項を、合意したことにしない

外部の契約管理システムが、変更後の料金を照会する機能を提供できるかは、まだ確認できていなかった。要件書には「外部サービスと連携して料金を取得する」とだけ書かれている。

これは実現性の確認を終えた要求ではなく、成立条件が未確認の案である。必要な料金情報を取得できるか、取得の時点や遅延、改修できる範囲を確かめる必要がある。NASAの技術要件定義でも、要求の理由、仮定、設計制約を記録することが扱われている。4

ただし、未確定事項が一つあるから、無関係なすべての開発を止める必要があるとは限らない。料金連携に依存しない調査や設計は進められるかもしれない。何が未確定で、どの決定がそれに依存するかを分けることで、止めるべき作業と進められる作業を区別できる。

記録には、確認する対象、確認を担う人、決定が必要な時点、成立しなかった場合の影響を残す。長い未確定事項一覧を作ることではなく、その不確実性が意思決定から消えないようにすることが目的である。

承認した後に、何を揃えるか

期間変更の案が承認された。これで実装して終わりではない。要件の版、状態遷移、インタフェース、業務手順、検証条件のうち、変更の影響を受けるものを合わせる必要がある。以前の要件に基づく試験が成功していても、新しい要求を満たした証明にはならない。

一方、変更と無関係な文書や試験を、形式だけ揃えるために全面改訂する必要もない。追跡関係は、必要な見直しを漏らさないと同時に、不必要な見直しを減らすために使える。

承認した人、変更の理由、採らなかった案と主要な理由が残っていれば、後から同じ議論を繰り返しにくくなる。状況が変わったときは、その理由が今も成立するかを再評価できる。決定の記録は、過去の判断を永久に正当化するためではなく、前提が変わった箇所を見つけるためのものである。

一行の変更は、最後まで一行のままかもしれない。しかし、その一行が支える約束をたどれば、変えるべき範囲を具体化できる。変更を許すことと、合意を守ることは、対立しない。

知識を答案へ戻す

午前Ⅱの判別軸。 ベースラインは変更禁止ではない。双方向トレーサビリティは、要求から実現・確認へたどるだけでなく、実装や派生要求の根拠へ戻ることも支える。要件の優先順位、必須性、実装順序は別の軸として読む。

午後Ⅰへの接続。 変更対象の項目だけでなく、それを使う判断、後続処理、他システムを本文から探す。本事例では終了日の変更が、元予約の維持、機材確保、料金、出庫準備へ影響する。一般的な変更管理手順を並べるのではなく、問題文にある依存を答える。

午後Ⅱへの接続。 変更要望を受けた事実だけでなく、何を問題と捉え、どの代替案をどの条件で比較し、どの範囲を採用したかを述べる。本事例なら、取消しと再予約の間に枠を失うことを防ぐため、変更不成立時にも元予約を維持する要求を置いた判断が説明の中心になる。

立ち止まって考える：要求に直接ひも付かない処理は、すべて削除してよいか

直ちには削除しない。追跡の記録漏れ、外部制約や採用した設計からの妥当な導出、根拠のない機能追加を区別する。必要な導出であれば根拠を明らかにし、合意する。根拠がなく今回の目的にも不要なら、削除や対象外とする判断につながる。

出典と照合範囲

[1] コンプリートテキスト『午前Ⅱ 技術知識の地図』第2・8・9・24章：ベースライン、追跡可能性、段階的な開発、契約上の合意を出発点とした。期間変更の問題、要件識別子、比較案は本書独自の設定である。

[2] NASA Systems Engineering Handbook, 6.2 Requirements Management：双方向の追跡、変更の影響評価、妥当な導出要求と根拠のない作り込みの区別を参照した。NASAの変更管理委員会などを、すべてのプロジェクトに必要な手続として扱ってはいない。原文

[3] IPA「SAシラバス Ver.5.2」：5-1、5-6、7-2、7-3、8-4、9-2。制約、スケジュール、要件と方式の評価、共同レビューの位置付けを照合。公式PDF

[4] NASA Systems Engineering Handbook, 4.2 Technical Requirements Definition：要求の理由、仮定、設計制約を記録し、実現可能性と検証可能性を評価するという観点を参照した。原文