正しく作れる要件と、作るべき要件

架空事例：青葉機材の要件を、実装と業務開始へ引き渡す場面を扱う。章末の設問と解答例は本書オリジナルであり、IPAの過去問題、公式解答、採点基準ではない。

仕様には適合している。それでも使えない

予約画面は、合意した項目をすべて表示する。試験条件の下では二秒以内の応答も達成している。予約の重複を防ぐ確認も行った。開発者から見れば、要求を満たしたシステムである。

実際に営業に使ってもらうと、電話を保留する回数が減らなかった。貸出し可能な機材は表示されるが、顧客へ説明すべき条件を別の文書から探す必要があった。機材の準備時刻と顧客の希望受取時刻も、画面上で比較できない。営業は、結局倉庫へ確認していた。

ここで確認すべき問いは二つある。指定した要求を満たすように作ったか。そして、その要求と実現したシステムで、本来の業務の必要を満たせるか。

前者がverification、後者がvalidationという区別に対応する。NASAのハンドブックでも、仕様・要求への適合と、意図した利用環境で関係者の期待を満たすことを分けて説明している。1 どちらも重要であり、片方がもう片方の代わりになるわけではない。

誰が試験したかではなく、何に照らしているか

開発者が確認したから検証で、利用者が確認したから妥当性確認。こう覚えると、境界を取り違える。

営業担当者が「数量がゼロならエラーになる」という仕様を試すなら、その活動は仕様への適合を確認している。一方、開発者が現場の条件を再現し、「この情報で顧客へ貸出しを確約できるか」を評価するなら、意図した用途への適合という観点を含む。担当者の肩書だけで評価の目的は決まらない。1

同じ試験が、両方の証拠を提供する場合もある。例えば、実際の営業担当者が想定した負荷環境で、標準依頼への回答を完了する試験では、画面の応答要件と、業務の回答時間の両方を測れる。ただし、片方を測ったからもう片方も分かったとは限らない。どの評価基準に対して、どの観測値が証拠となるかを分けて記録する。

また、妥当性確認を完成後だけの作業とみなす必要はない。要件そのものが目的に合っているかは、要件定義時にも検討する。SAシラバス7-2は、取得ニーズとの一貫性、テスト可能性、方式設計や運用・保守の実現可能性を、システム要件の評価に含めている。2

完成した画面で発見できた問題を、要件段階の具体的なシナリオで発見できなかったか。後から見直すべきなのは、試験の回数よりも、その試験でどの問いに答えようとしていたかである。

薄く広く作るものと、深く一筋を通すもの

営業が必要な情報を見付けられるかを知りたいなら、画面や操作の全体像を示す試作品が役に立つ。多くの画面を浅い実装でつなぐ水平型プロトタイプなら、表示の意味、入力順序、行き来の負担を早期に検討できる。

一方、外部の点検情報を取得し、予約記録を照合して、所定時間内に結果を返せるかを知りたいなら、画面だけでは足りない。一つの機能を表示から処理、データ取得まで深く通す垂直型プロトタイプが適する場合がある。水平・垂直の区別は、既存テキスト第3章の基礎に対応する。3

どちらも、作った範囲の外までは証明しない。垂直に通した一件が速くても、負荷が増えた場合や別倉庫のデータで同じ結果になるとは限らない。水平型で操作が分かりやすくても、同時予約、復旧、移行を実現できるとは限らない。

青葉機材では、最初の画面試作で、機種名だけでなく、貸出し条件と回答の根拠を表示する必要が分かった。この結果を要件へ反映する。一方、機材の確保を矛盾させない処理については、競合する要求と、結果が届かない場合を含む別の検証を行う。試作品を一つ作って「実現性を確認した」と一括しない。

試作品の合否も、先に置く。何が分かれば採用できるのか、どの結果なら案を変更するのかを定める。完成度の高いデモを作ることと、不確実な設計判断に答えを得ることは、目的が違う。

要求を、確かめられる観測へ変える

「二重予約を防ぐ」を確認したい。営業が順に二件登録し、二件目が断られることを確認すれば十分だろうか。順次実行では成立しても、同時に要求した場合に両方が確定する可能性は残る。

本事例では、同じ期間の最後の一台に対して、複数の確定要求が競合する条件を用意する。見るべきなのは、画面にエラーが出た回数だけではない。確定した予約と機材確保の記録が、採用した制約に違反しないかを確かめる。通信断の試験では、再送後の画面だけでなく、同じ業務操作が重複して確定していないかを確認する。

要求の文章と、試験で観測できる事実の間には、この変換がある。「テストケースを一件ひも付けた」だけでは、その要求を確認できているとは限らない。

確認したい約束	必要な条件の例	観測する事実の例
競合しても確保量を矛盾させない	同じ期間・同じ最後の一台への確定要求	確定結果と確保記録が制約を満たす
変更できなければ元の予約を維持する	延長先の期間が別予約で埋まっている	元の期間・数量・確定状態が維持される
通知失敗だけでは予約を取り消さない	予約確定後の通知経路が失敗する	予約は確定のままで、未通知を識別できる
営業が標準依頼へ自ら回答できる	想定する担当者・端末・業務シナリオ	判断に必要な情報と回答手順が成立する

表は試験の全件を列挙したものではない。要求が何を保証するかを、確認条件と観測値へつなぐ例である。実際の試験の十分性は、対象となるリスク、実現方式、既存の証拠を踏まえて判断する。

受入れは、開発者の試験結果に丸を付けるだけではない

供給者が試験を実施し、その結果を取得者へ説明することは重要である。しかし、その結果だけで取得者の受入れ判断が自動的に完了するわけではない。契約や合意した受入条件、実際の業務で使う手順、未解決事項の扱いを確認する必要がある。

SAシラバス15-1は、取得者の受入れレビューと受入れテストを、開発側が支援する活動として扱っている。2 実装した側が支援することと、業務上の受容や契約上の判断の責任をすべて引き受けることは同じではない。

例えば、確認中の依頼が一日残った場合に誰が対応するか決まっていないなら、プログラムに不具合がなくても業務開始には支障がある。利用者用文書を納めただけでは、その文書を使って担当者が判断できることを確かめたとはいえない。

逆に、新しく気付いた便利な機能を、すべて受入れの必須条件へ追加するのも適切ではない。既に合意した範囲への不適合なのか、意図した用途を満たすうえでの不足なのか、追加の改善要望なのかを分ける。基準を後から動かさず、必要な変更は影響を評価して扱う。

新しい状態へ、古いデータはそのまま入らない

旧システムには、予約状態として「受付済み」しかなかった。新システムでは、確認中と確定を区別する。旧データの受付済みを、すべて確定へ変換すれば、まだ機材の確保を約束していない依頼まで確定扱いになる。

単なるコードの変換ではなく、業務の意味を照合する必要がある。

この事例では、予約台帳だけで区別できない依頼について、倉庫の確保記録や担当者の確認を使って判定する。判定できないものを、自動処理に都合のよい状態へ黙って入れない。移行の対象から保留し、稼働までに対応するのか、新システムで未確認として扱うのかを業務側と合意する。

件数の一致は大切だが、それだけでは意味が保存されたことにならない。旧千件が新千件になっても、確定していない予約を千件確定にしたなら誤りである。状態ごとの件数、機材との対応、期間、必要な履歴など、変換した意味を確認する。

新旧の業務差を踏まえた移行は、SAシラバス17-1の対象である。また、2025年度春期の午後Ⅱ採点講評は、データ移行の論述について、新旧の差異を明らかにし、データの仕様・特性に応じた検討を説明することを求めている。24 ただし、その年度の講評を、すべての出題に同じ書式で答える規則として使わない。

一つの短い事例を、三つの力で読む

次の文章は、本書が作成した練習用の設定である。

旧システムでは、営業は機種別の保有台数を参照して貸出し可否を回答していた。点検未了の機材と、同じ期間に確定している予約は、その保有台数から除かれていない。新システムでは、営業が倉庫へ電話せずに標準依頼へ回答することを目指している。ただし、点検が完了していない機材を貸し出すことは認めない。

ここから、機材台帳、予約データ、点検結果という技術用語を拾うだけなら、知識の識別で止まる。設計へ進むには、それらをどの条件で組み合わせれば業務上の判断になるかを考える必要がある。

「どの情報を利用して、何を判定すべきか」と問われたなら、本設定の範囲で、対象期間の確定予約と点検状態を参照し、必要数量を確保できるか判定する、という方向になる。単に「在庫を確認する」では、旧システムとの違いが出ない。「AIで需要を予測する」は、本文にある問題を直接解く要件ではない。

ただし、これだけで任意の未来の期間の供給を厳密に計算できるわけではない。点検状態の将来変化や個体ごとの制約まで設計するなら、さらに情報が必要である。短い練習文にない条件を、完成した予約エンジンの仕様として推定しない。設問が求める粒度と、与えられた事実の範囲を守る。

このように、知識は本文にない事実を足すためではなく、本文の意味を具体化するために使う。2025年度春期の午後Ⅰ採点講評でも、集計条件の不足、業務上の問題の読み違い、どのシステムを指すかの曖昧さなどが指摘されている。5

理由を一つ置くと、論述は変わる

「新システムでは点検状態と予約状況を表示した」。実施した内容は分かるが、その設計がなぜ必要だったかは分からない。

「保有台数には点検未了の機材と確定予約分が含まれており、営業が貸出し可能数を判断できず倉庫への確認待ちが生じていた。そこで、標準依頼について必要な点検状態と予約状況を参照できるようにし、営業が判断する範囲と例外の引渡し先を定めた」。こう書くと、事象、原因、判断、範囲がつながる。

さらに、評価を加えるなら、何を測ったかを明らかにする。画面の応答時間を測っただけなら、業務全体の回答待ちを短縮したとはまだいえない。受付から回答までを測り、対象依頼の定義を揃えた比較ができて初めて、その効果を説明できる。確認していない成果の数値を、論述を立派にするために作らない。

2025年度春期の午後Ⅱ採点講評は、実施事項だけでなく、理由や検討の経緯を具体的に示すことを求めている。4 本巻で繰り返し扱った、条件を分けること、代替案を比べること、結果を確かめることは、その説明を支える。本巻の青葉機材は架空なので、自身の実務経験として使うための事例ではない。設計理由を記述する構造を学ぶための材料である。

要件定義は、最後まで業務の問いへ戻る

青葉機材の検討は、画面が遅いという苦情から始まった。実際に時間がかかっていたのは、情報と判断権限が分かれているための確認待ちだった。用語を揃え、機種と個体を分け、期間と状態を定義すると、何を自動化し、何を人に残すかを具体化できた。

その後、応答時間の目標を測れる形へ変え、期間変更の影響をたどり、正しく動くことと業務に使えることを分けて確かめた。いずれも、特定の製品名を選ぶ前に必要な設計である。

要件定義の到達点は、分厚い文書が承認されることだけではない。関係者が同じ条件と結果を理解し、実現する側が作るべきものを説明でき、確かめる側が判断の基準を持てることにある。要求が変わっても、その根拠と影響をたどれる状態を残す。

速い画面を作ることも、その中の一つの仕事である。だが、最初の目的は、顧客を待たせず、誤った約束をせずに機材を提供することだった。実装と検証がどれほど進んでも、この問いへ戻れなくなってはいけない。

知識を答案へ戻す

午前Ⅱの判別軸。 検証と妥当性確認は、担当者や実施時期だけで分類しない。どの要求・用途を基準にしているかを見る。プロトタイプも、水平・垂直という名前より、その実装範囲で確認できる不確実性を区別する。

午後Ⅰへの接続。 対象、条件、状態、時点を問題文から抽出し、設問が求める内容に絞って答える。業務知識は与えられた記述の解釈を助けるが、与えられていない要件を作る権限ではない。

午後Ⅱへの接続。 自身の担当と判断を、課題、制約、比較、採用理由、確認した結果として説明する。一般的な用語の列挙や、未確認の成功談ではなく、設問に沿った具体的な検討を示す。

立ち止まって考える：仕様どおりに動く試験が全件成功したら、受入れ可能か

その結果は重要な証拠だが、それだけで必ず受入れ可能とはいえない。合意した受入条件、意図した業務で使えること、移行・運用・教育などの必要事項、残る問題の扱いを確認する。一方で、合意した範囲にない改善要望を、説明なく必須条件へ追加することも避ける。

出典と照合範囲

[1] NASA Systems Engineering Handbook, 5.3 Product Verification / 5.4 Product Validation：指定要求への適合と、意図した環境・用途への適合の区別を参照した。NASAの飛行品の適格性確認・受入れ手続を、一般の業務システムへそのまま適用してはいない。Verification / Validation

[2] IPA「SAシラバス Ver.5.2」：7-2、7-3、9-3、15-1、17-1。要件評価・共同レビュー、取得者の受入れ支援、業務とシステムの移行を照合した。公式PDF

[3] コンプリートテキスト『午前Ⅱ 技術知識の地図』第1・2・3・8・11・25章：業務目的、検証・妥当性確認、プロトタイプ、試験、効果評価を接続した。本章の検証条件、移行問題、練習文、解答例は独自の作例である。

[4] IPA「令和7年度春期 SA試験 午後Ⅱ 採点講評」：全問共通の理由・検討経緯への指摘、および問2の新旧システムの差異と移行方法への指摘を参照した。特定年度の講評であり、本書の架空事例の採点を保証するものではない。公式PDF

[5] IPA「令和7年度春期 SA試験 午後Ⅰ 採点講評」：本文の条件、業務上の問題、対象システム、対象範囲を明確に読むという指摘を参照した。問題冊子を再掲したり、設問ごとの公式解答を再構成したりしてはいない。公式PDF