はじめに
Confluence や Google Docs に並んだ何百件もの要件を、通しで確認できる気がしない。
この感覚、レビュー力ではなく脳の作りの問題だと分かりました。
今回はその真因と、構造で抜けを潰す手順を整理します。
TL;DR
- 要件が抜けるのは 短期記憶 7±2 という認知の物理的限界のせい
- OPSD で 4 視点に分類し、各視点の Bounding Model を先に描いて外枠を固める
- 新規/改修は 4 視点全部、局所修正は影響範囲だけ、が実務判断の軸
1. なぜ要件リストは必ず抜けるのか — 認知の物理的限界
「はじめに」で「レビュー力ではなく脳の作り」と書きました。
その中身をここから掘っていきます。
1.1 数千件の要件文を通しで確認できる人はいない
数百件、ときには数千件の要件文がフラットに並んだ一覧を通しで読んで、「全部揃っている」と確信できる人は、たぶん存在しません。
自分もやってみると、途中で「さっき見た要件、この後の要件と矛盾してなかったか？」を追いかけ始めます。
そのうち目の前の要件に集中できなくなる、という現象を何度も経験しました。
現代のプロジェクトでは、要件は Confluence のページや Google Docs、Jira・Linear のチケットに並んで管理されています。
ツールが古い時代の Excel から新しいドキュメントツールへ変わっても、抜けの発生確率は本質的には変わりません。
フラットな一覧で管理する形式である限り、道具を新しくしても効かない、というのが調べてみて納得した結論です。
Agile の product backlog や user story も、ネストなしの平坦な一覧で管理される限り同型の罠にはまります。
近年は AI に要件草稿を書かせる機会も増えました。
ただし最終的に人間が通しでレビューする以上、レビュー側で同じ制約に突き当たります。
この話は 5 章の最後で改めて扱います。
1.2 短期記憶が 7±2 個で頭打ちなのはなぜか（Miller's Magic Number）
なぜフラット一覧では抜けるのか、を認知の側から辿ってみます。
すると、短期記憶で同時に扱える情報の個数には物理的な上限がある という話に行き当たりました。
認知心理学の分野で古くから知られている Miller's Magic Number（1956 年）で、その数はおよそ 7±2 個 とされています。
近年の研究では、実際にはもっと少なく 3〜4 個ではないかとも言われているようです。
イメージとしては、脳のなかに「作業用のスクラッチパッド」があって、そのサイズが物理的に有限、という感じです。
買い物リストを書かずに 15 品目を買いに行くと、たいてい 2〜3 品目を落として帰ってきます。
要件も同じで、数千件を頭のなかで同時に処理するのは、そもそも脳の物理的な作りとして無理があります。
Miller の 7±2 は「同時に保持できる項目数」の理論です。
要件レビューの現場では、この数を超えた瞬間から取りこぼしが確率的に発生し始める、と考えると腑に落ちます。
1.3 構造化して視野に載せる情報量を減らすのが唯一の解
短期記憶の物理的上限は、レビュー回数を増やしても、レビュアーを増やしても動きません。
どのレビュアーも同じ 7±2 の制約に等しく晒される ため、頭数を増やす方向では抜けは潰しきれません。
残っている道はひとつだけ。
一度に処理する情報量を「数個」に圧縮するように構造化する ことです。
2. OPSD — 4 視点で分類して視野に載せる
「情報量を数個に圧縮する」方向は分かりました。
では具体的にどの単位で分類するのが良いのか、を扱っていきます。
2.1 OPSD の 4 視点で要件を分類してみる
要件モデリング専用の視覚モデル言語に、RML（Requirements Modeling Language）と呼ばれるものがあります。
この RML では、要件を Objectives / People / Systems / Data の 4 視点に分類する、という組み立てです。
頭文字を取って OPSD と呼びます。
各カテゴリが何を扱うかを整理してみました。
| カテゴリ | 何を扱うか |
|---|---|
| Objectives（目的） | システムのビジネス価値。要件を価値で優先度づけする |
| People（人） | 誰が使うか。業務プロセス・目標 |
| Systems（システム） | 何が存在するか。UI・システム間連携・振る舞い |
| Data（データ） | どんなデータを扱うか。関係・ライフサイクル・レポート利用 |
OPSD の 4 視点それぞれに代表モデルが 1 つずつあり、全体構造は 1 枚で見せられます。
「機能要件 / 非機能要件」だけで要件を分類してきた自分にとっては、独立した軸として Objectives（そもそも何のため）と People（誰がどう使う）が立てられているのが新鮮でした。
機能要件・非機能要件の分類は、この 4 視点でいうと Systems の内側の話に近い印象です。
2.2 なぜ「4」なのか — 歴史的に洗い出された「漏らせない軸」の集約結果
「なぜちょうど 4 なのか」を最初は「認知的に扱いやすい数」だと解釈していました。
ただ調べてみると、そうではありませんでした。
4 は認知的な最適解として導かれた数字ではありません。
ソフトウェア要件モデリングの発達史のなかで「解決策を漏らさず分析するために欠かせない軸」として洗い出された結果、4 に集約されたのが本当のところでした。
大まかな発達の流れは、次のような順番だったようです。
- 初期: データ視点（Flow Chart や DFD）が中心。データの入出力と変換に注目していた
- その後: ユーザー視点（Use Case、業務プロセスモデル）が確立。誰がどう使うか、という軸が加わった
- 近年: 経営視点（Objectives 系モデル）が加わる。業務目標との整合を担保する軸
ここに業務データの管理という視点を組み合わせて、O / P / S / D の 4 つに落ち着いた、という経緯です。
「そもそもなぜ 4 全部が必要か（どれか欠くと何が落ちるか）」の掘り下げは 4 章で扱います。
この 2 章では 4 という粒度で情報を圧縮する意義に絞ります。
補足すると、4 という数字は結果として短期記憶にも収まる範囲なので、実務運用にも都合が良い、という副次的な効用もあります。
ただしこれは直接論拠ではなく、「たまたま扱いやすい数に落ちた」というくらいの位置づけです。
2.3 分類は "何を選ぶか" の道具として使う
分類は情報を整理するための入れ物ではありません。
目的に応じて必要なカテゴリを絞り込むための道具 として使うのが正解でした。
たとえば板に丸い穴を開けたいとき、金槌・ヤスリ・ドライバーは一瞬で除外して、切る系の工具（ジグソー、ホールソー、ドリル）に絞り込みます。
工具を目的で分類しておくと、逆引きが一気にラクになるのと同じ理屈です。
| 目的 | 使う工具のカテゴリ |
|---|---|
| 切る | ノコギリ・ジグソー・ホールソー |
| 叩く | 金槌・木槌 |
| 削る | ヤスリ・カンナ |
| 締める・回す | ドライバー・レンチ |
要件モデルも同じです。
「今この会議で欠けている視点はどれか」を OPSD 4 分類の当てはめで確認できます。
話が Systems（連携・UI）ばかりに寄っていて Objectives（そもそも何のため）が薄い、といった偏りにも気づけるようになります。
3. Bounding Model — 各視点の外枠を先に張る
OPSD で 4 視点に分類できたところで、次は各視点でまず何を描くのか、を掘っていきます。
3.1 Bounding Model の位置づけ
各カテゴリには「分析対象を漏れなく捕捉できる高い確度で作れる」モデルが 1 つずつ用意されています。
これを Bounding Model（境界モデル）と呼びます。
作った時点で「このカテゴリはこの範囲まで」という 分析の外枠 が固まる、というのが役割です。
Bounding Model は「そのカテゴリのなかで一番重要なモデル」というより、分析の境界を張る特別な位置づけを担うモデルです。
ここが空欄のまま詳細モデルを作り始めると、後で境界の外にある要件が発覚して手戻る、という失敗パターンが典型的です。
3.2 4 つの Bounding Model — なぜ「漏れなく」作れるのか
各カテゴリの Bounding Model を、情報源とセットで並べてみます。
| カテゴリ | Bounding Model | 主な情報源 | なぜ漏れなく作れるか |
|---|---|---|---|
| Objectives | Business Objectives Model | 経営・PdM との対話 | 業務目標は経営と話せば有限個に絞れる |
| People | Org Chart | HR の組織図・利用者 DB・開発体制図 | 複数ソースを突き合わせれば関係者が列挙できる |
| Systems | Ecosystem Map | ユーザー・運用者・保守者へのヒアリング | 関わる 3 者に聞けばシステム一覧は有限で閉じる |
| Data | Business Data Diagram | 既存の入力画面・帳票・レポート | 画面と帳票は有限なので、そこから業務データが引ける |
表だけだと平坦な印象になるので、それぞれについてもう少し掘ってみます。
Business Objectives Model
Objectives の Bounding Model です。
業務目標を経営や PdM と対話すれば有限個に絞れる、というのが「漏れなく作れる」根拠です。
目標は無数にあるように見えますが、「今期・今プロジェクトで達成したいもの」に絞れば、意外と少数に収まります。
Org Chart
People の Bounding Model です。
会社の HR ソースから作れる上に、システムの利用者 DB や開発体制図といった補完材料を突き合わせて使えます。
これにより「システムを使う人」だけでなく「システムを運用する人」「保守する人」まで漏れなく列挙できるのが強みです。
エンドユーザーが顧客のように組織図に載らない存在の場合は、その顧客と接する社内側の窓口を Org Chart から特定します。
Ecosystem Map
Systems の Bounding Model です。
ユーザー・運用者・保守者の 3 者に「関係するシステムを挙げてください」と聞けば列挙が閉じます。
ここでのポイントは、詳しい相互作用まで一度に描こうとしないこと。
まず「どんなシステムが存在するか」の一覧だけを完成させます。
詳細な連携仕様は詳細モデル（System Interface Table など）に譲る、という役割分担が明確です。
Business Data Diagram
Data の Bounding Model です。
既存の入力画面・帳票・PDF レポートから業務データオブジェクトを引き出します。
既存の画面や帳票は数として有限なので、そこから引ける業務データも有限。
これが「漏れなく作れる」根拠です。
新規開発でも、参考にする既存システムや業界標準の帳票フォーマットが起点になります。
Bounding Model と詳細モデルの関係を 2 層で図解すると、外枠戦略の全体像は次のようになります。
3.3 なぜ外枠から先に張るのか — 詳細モデルは完全性を担保しにくい
「外枠から先に張る」順序が効くのは、詳細モデルの完全性がそもそも担保しにくいからです。
たとえば個々のユーザーの Process Flow を掘っているとき、「このユーザーが業務でやっていることは、これで全部か？」を保証するのはかなり難しい話です。
ユーザー本人ですら「あ、そういえば四半期に一回だけこの手順もやってた」を思い出せないことがあります。
一方、組織図なら会社の HR データから引けるので、関係者の網羅性は最初から高い確度で担保できます。
この完全性の違いを並べると、外枠戦略の意義がはっきりします。
| モデルの種類 | 情報源 | 完全性の担保 |
|---|---|---|
| Bounding Model（Org Chart など） | HR データ・画面帳票・システム棚卸 | 情報源自体が有限なので網羅性が高い |
| 詳細モデル（Process Flow など） | 個々のユーザーへのヒアリング | 「これで全部か」を本人ですら保証しづらい |
つまり、先に確度高く外枠を張れるモデルから作り、そこから詳細モデルを派生させるのが手戻りを避ける最短ルートになります。
3.4 詳細モデルは外枠が固まった後に降ろす
Bounding Model が 4 つ揃うと、そこから詳細モデルを派生させても 外枠は動きません。
Process Flow、System Flow、Data Dictionary などがその詳細モデルにあたります。
詳細を掘っている間に「外枠の外」から新しい要件が湧いてくることがない、というのがこの順序の一番の実務メリットです。
外枠が動かないと、詳細を掘る作業は「内側を埋めていく」だけの安定した作業に変わります。
手戻りが構造的に起きにくくなる、という状態です。
4. 4 視点全部を回さないと、欠けた視点の要件は必ず後工程で表面化する
そもそも 4 視点全部を回す必要があるのか、を扱っていきます。
4.1 立体物の 4 面図と 4 視点の対応
立体物を再構築するのに、正面図・側面図・上面図・背面図の 4 面が揃わないと形が定まらない、という話があります。
1〜3 面だけでは、その方向から見えない特徴が抜け落ちてしまいます。
要件も同じ構造で、O / P / S / D のどれか 1 視点でも欠くと、その方向から見えるべき情報が構造的に落ちます。
「立体物を 1 面図で再構築する」のと、「4 視点のうち 1 視点で要件を全部済ませる」のは、実は同じ形の失敗です。
4.2 現場で観測される視点欠落 3 パターンとそこから落ちる要件
実際にプロジェクトで観測される視点欠落の典型は、大きく次の 3 パターンです。
| 欠けた視点 | 起きる失敗 |
|---|---|
| Data 視点欠落（Use Case 中心） | システムは動くけど、データが正しく渡らない・整合しない |
| People 視点欠落（DFD 中心） | 動くけど使いにくいシステム。利用者が「これじゃない感」を持つ |
| Objectives 視点欠落（機能ベース中心） | 価値の低い機能に金と時間をかけてしまう |
この 3 パターンは、歴史的にも順番に主流の失敗として入れ替わってきたところが面白いポイントです。
初期のソフトウェア開発は DFD 中心で People 視点が弱く、次に Use Case が確立して今度は Data 視点が弱くなりました。
そして近年は機能一覧ベースで進めるチームが多く、Objectives 視点が薄いことが多い、という順です。
3 パターンとも、視点欠落 = 要件欠落 が構造的な必然として起きている、という共通点があります。
4.3 未使用機能 65% は Objectives 視点欠落の帰結
視点欠落型の失敗の中で、金額インパクトが一番大きい典型例が「未使用機能」の話です。
業界統計では、実装した機能の約 65% がほとんど、あるいは全く使われない という数字があります。
改めて数字にすると、なかなか強烈です。
この 65% は、Objectives 系のモデルで早期に「これは価値が低いから作らない」と切れなかった帰結です。
機能単位で見ると全部必要そうに見えても、業務目標に紐付けて価値でランキングすると、実は多くの機能が「なくても業務目標に届く」ものだった、というのが実務でよくある光景です。
Objectives 視点を最初から回しておくと、この 65% のうちのかなりの部分は「作らない」判断に落とせます。
実装コストの削減だけでなく、保守コストの削減にも直結する、というのが未使用機能を削る効果です。
5. 実務での使い分け — 何から手を付け、どこで止めるか
あとは自分のプロジェクトで実際にどう回すか、を整理します。
フェーズごとに使い分けの目安を並べてみました。
| プロジェクトフェーズ | 4 視点の扱い | 最初にやること |
|---|---|---|
| 新規プロジェクトの立ち上げ | 4 視点全部を回す | 4 つの Bounding Model を 1〜2 週で描き切る |
| 既存システムの改修 | 4 視点全部を回す（既存資産を活用） | 現行の組織図・システム棚卸表・画面帳票一覧から Bounding Model を再構築 |
| 局所修正・単機能追加 | 影響範囲のカテゴリだけ | 影響範囲を明示宣言してから、該当カテゴリだけ Bounding Model を更新 |
5.1 新規プロジェクトの最初の 1 手
新規プロジェクトの立ち上げでは、見積もり・初期スコープ確定フェーズで一番威力を発揮します。
「どこから手を付ければ全体像が固まるか？」への回答が Bounding Model です。
最初の 1〜2 週間で 4 つ描き上げるまでを終わらせると、以降のスコープ議論が桁違いにブレなくなります。
順番としては、Business Objectives Model → Org Chart → Ecosystem Map → Business Data Diagram の順で描いていくのが素直です。
目的が固まらないうちに関係者を洗い出しても手戻るので、O から始めるのが安全です。
5.2 既存システムの改修 — 現行資産から Bounding Model を再構築する
既存システムの改修の場合、現行の組織図・システム棚卸表・画面帳票一覧といった資産があるほど、Bounding Model を短時間で描けます。
ここで「あれ、この帳票はどの業務データから引いてるんだっけ？」といった抜けが検出できると、改修スコープの膨張を防げる副次的効果もあります。
現行資産の棚卸から始めるのが、既存改修での実務的なショートカットです。
5.3 局所修正では 4 視点全部を回さない
一方で、バリデーションエラーメッセージの文言修正のように影響が 1 カテゴリに閉じる場面では、4 視点を全部回すコストは払いません。
「影響範囲は Systems カテゴリの UI 部分のみで、Objectives / People / Data には波及しない」と影響範囲を明示宣言します。
その上で、該当カテゴリだけ扱えば十分です。
判断のポイントは、「本当に他カテゴリに波及しないか」を影響範囲宣言のなかで意識的にチェックすること。
バリデーション文言が Data の意味と結びついている場合（例: 「必須項目です」の裏に業務ルールがある）は、実は影響が Data にも及ぶ、というケースもあります。
5.4 モデルは要件文の置き換えではない
ここまで OPSD と Bounding Model の話をしてきましたが、実は忘れると危ない前提があります。
モデルは要件文の置き換えではありません。
「モデルを作った ＝ 要件フェーズ完了」ではありません。
開発者・テスターに最終的に渡すのは、あくまで文字列としての要件文です。
モデルは「モデル → 要件文への落とし込み」までをチェックリストとして工程に組み込んで初めて成果物として機能します。
モデル整備で満足してしまうと、開発者は結局「モデルを見て要件を推測する」羽目になり、実装のブレやテスト観点の抜けにつながります。
モデルは要件文を組み立てるための 組み立て台 であって、成果物としての要件文は別に必要です。
この位置づけを工程設計の段階で押さえておくのが安全です。
最後に、AI と一緒に要件定義を進める場面についても少しだけ触れておきます。
AI に要件定義の草稿を書かせても抜けが残るのは、AI の出力を最終判断する 人間側にも同じ短期記憶 7±2 の制約が働く からです。
AI が生成した数百件の要件文を人間が通しでレビューしても、Miller の物理的な壁は同じように立ちはだかります。
ここで OPSD は、AI 出力の「どの視点が薄いか」を人間が数個の粒度でチェックするためのフレームとしても機能します。
1 章と地続きの話として腑に落ちたポイントでした。
おわりに
冒頭の「Confluence や Google Docs に並んだ何百件もの要件を通しで確認できる気がしない」という感覚は、結局のところ 正しかった ということが分かりました。
原因は自分のレビュー力ではなく、脳の物理的な作りだからです。
ここを個人スキルの問題として片付けている限り、道具を新しくしても抜けは同じ確率で発生し続けます。
OPSD の 4 視点で分類し、各視点の Bounding Model を最初に描く。
この 2 段の手順を工程に組み込むと、抜けの発生確率が構造的に変わります。
個別モデルの描き方（Process Flow や Ecosystem Map、Business Data Diagram の具体的な作成手順）は、この記事ではスコープ外にしました。
別記事で改めて整理してみたいテーマです。