情報システム開発では、上流工程にも WBS、工数、期限、進捗率を持ち込み、下流工程と同じ形式で管理しようとする場面が多い。表は細かく、会議は頻繁で、報告資料には百分率が並ぶ。それでも、何を決めるべきか、誰が判断するのか、どの前提が崩れたのかは見えないまま残る。管理対象を細分化したように見えて、実際にはプロジェクトの不確実性が帳票の外へ追い出されている。
この構図は偶然ではない。下流工程の受注と遂行を中心に成長した会社では、指示された作業を分解し、要員を割り当て、納期までに成果物を納める能力が評価されてきた。その能力は必要である。しかし、目的や要求が固まっていない段階で問いを立て、調査し、利害を調整し、経営判断を成立させる能力とは異なる。後者を持たない会社が上流工程を担当すると、未知を扱う代わりに、上流工程を自社が扱える下流工程の形式へ変形する。
必要なのは、この疑似管理への批判に加えて、上流工程を実際に前進させる代替手法である。上流工程で管理すべき対象を定義し直し、ロードマップ、アプローチ図、セッションスケジュールという三つの管理層を、調査と判断の結果に応じて更新する方法を組み立てる。管理資料の記載項目、状態遷移、終了条件、会議設計、更新周期、導入手順まで明示し、現場で再現できる形へ落とし込む。
1. 下流工程の管理では上流工程を管理できない
1.1 WBS と進捗率が成立する条件
WBS は、仕事を成果や作業の単位へ分解し、計画、見積もり、責任分担、実績管理を接続するための管理資料である[1]。費用や期間の見積もりも、対象範囲、技術上の前提、作業構造、リスク分析が結び付いて初めて根拠を持つ[2]。つまり、WBS と進捗率は、分解する対象がある程度定義され、全体量を仮定できる場面で力を発揮する。
詳細設計、実装、単体試験では、この前提が比較的成立しやすい。作る機能、変更する画面、実装する処理、確認する試験項目が決まれば、作業を担当者へ割り振り、終了条件を置ける。作業の追加は起こるが、計画上は例外として扱える。計画値と実績値の差を追うことにも意味がある。
プロジェクト管理の国際規格も、すべての案件を一つの進め方へ押し込めてはいない。予測型、反復型、適応型など、対象の性質に合わせて管理方法を調整することが前提となっている[3]。管理手法は普遍的な型ではなく、対象工程の確定度に依存する。
| 観点 | 下流工程で成立しやすい条件 | 上流工程で起こること |
|---|---|---|
| 対象 | 作るものや変更範囲が定義されている。 | 何を変えるべきか自体が検討対象になる。 |
| 全体量 | 作業総量を一定の幅で見積もれる。 | 調査によって作業や関係者が増減する。 |
| 終了条件 | 成果物や試験結果によって事前に置ける。 | どこまで分かれば次へ進めるかを設計する必要がある。 |
| 責任 | 作業単位で担当者へ割り当てられる。 | 複数部門の知識と判断権限が必要になる。 |
| 変更 | 基準線からの差異として扱う。 | 新しい事実を反映する通常の運用になる。 |
1.2 上流工程では作業対象そのものが変化する
上流工程では、目標と実現方法の双方が確定しているとは限らない。目標は決まっていても方法が不明な案件もあれば、何を達成すべきか自体が曖昧な案件もある。目標と方法の確定度によって、同じプロジェクトという名称でも管理の性質は変わる[4]。
たとえば、「受注処理を効率化する」という依頼を受けたとする。最初は画面や処理速度の問題に見えても、現場を調べると、例外注文の承認経路、部門間で異なる品目定義、営業担当者が個別に持つ表計算ファイル、取引先との契約条件、在庫情報の更新時刻が遅延を生んでいるかもしれない。調査前に作った WBS には、これらの問題は存在しない。しかし、見つかった問題を無視すれば、画面だけを更新しても受注処理は速くならない。
上流工程では、問題の理解と解決策の検討が相互に影響する。ある案を検討した結果、それまで見えていなかった制約が分かり、問題の定義まで変わることがある[5]。作業を始めたことで作業対象が増えるのは、計画の失敗ではない。未知を調べた結果として、対象の実像が見えてきたのである。
1.3 詳細な計画が虚構を生む
全体量が変化する仕事で、進捗率だけを示しても実態は分からない。当初 10 個の作業を想定し、そのうち 8 個を終えれば 80％と報告できる。しかし調査によって新たに 4 個の重要作業が見つかれば、完了した 8 個は全 14 個の約 57％にすぎない。さらに、追加作業の大きさや難しさが既存作業と同じとは限らない。百分率は精密に見えても、分母が変動する以上、計算結果に安定した意味はない。
それでも人は、具体的な計画を与えられると、その筋書きへ注意を集中し、過去の実績や予定外の事象を軽視しやすい。これは計画錯誤として知られ、所要時間の過小評価を生む[6]。詳細な日程表は、未知を減らすのではなく、未知を見落とさせる場合がある。
数値化には、もう一つの危険がある。測定値が目的として扱われると、現実を改善する代わりに、数値だけを改善する行動が合理的になる。既稿「測ることは、考えることの代わりにならない」では、代理指標が本来の目的へ置き換わる構造を整理した[7]。上流工程の進捗率も同じである。未知の解消より、予定済みの作業を完了扱いにする方が評価されるなら、重要な問題を発見した担当者ほど遅延の原因として扱われる。
上流工程に詳細な WBS を作る行為は、未知を既知へ変えることではない。調査前の仮定を作業表へ固定し、未知を表の外へ追い出す行為になりうる。精密さの外観と、管理の実効性を区別しなければならない。
2. 下請け型組織が上流工程を下流工程に偽装する
2.1 多重下請け構造が形成する能力
ここでいう下請け型組織とは、商流上の位置そのものではなく、上位者から与えられた範囲を工数と期限の中で遂行する能力へ特化した組織を指す。
日本のソフトウェア産業では、多重下請け型の供給構造が長く続いている。公正取引委員会の実態調査でも、仕様変更への無償対応、買いたたき、下位事業者への負担転嫁など、商流の下側へ不利益が連鎖する問題が確認されている[8]。この構造では、上位会社から与えられた範囲を、限られた工数と期限で完成させる能力が生存条件になる。
そこで育つのは、受注した作業を分解し、要員を割り当て、納品物を整え、契約範囲外を切り分ける能力である。これらは下流工程で不可欠であり、それ自体を軽視すべきではない。しかし、顧客自身も答えを持っていない状況で、目的を具体化し、問いを立て、組織間の利害を調整し、判断を促す能力とは別である。
経済産業省の DX レポートは、日本では情報技術者がベンダー企業側へ偏り、ユーザー企業の内部にシステム知識が蓄積しにくいこと、外部への丸投げが起こりやすいことを指摘した[9]。ユーザー企業が判断能力を失い、受託企業が指示遂行能力へ特化すると、上流工程の責任主体が空洞化する。顧客は「専門家だから決めてほしい」と考え、受託企業は「顧客の業務だから決められない」と考える。その間に、判断されない要求、承認待ちの資料、目的の分からない会議が積み上がる。
2.2 上流工程は共同の意思決定である
上流工程では、発注側と受注側が共同で問題を定義し、合意を形成する必要がある。情報処理推進機構の「超上流から攻めるIT化の原理原則17ヶ条」も、要件定義を発注者の責任を含む共同作業として位置付け、合意されないまま次工程へ進まないこと、見積もりを段階的に精緻化することを求めている[10]。共通フレームも、企画、要件定義、開発を区別し、合意後にプロジェクト計画を見直す必要を示している[11]。
ところが、下流型の会社が上流工程へ入ると、共同の意思決定が資料作成へ置き換わりやすい。「要求を整理する」は要求一覧を埋める作業になり、「将来像を検討する」は構想資料のページを作る作業になり、「方式を決める」は比較表へ丸を付ける作業になる。資料は完成しても、何を優先し、どのリスクを受容し、誰が責任を持つかは決まっていない。
下流工程で高い成果を上げた人物が、上流工程でも同じように成果を出せるとは限らない。既稿「ピーターの法則の本当の被害者とは」で扱ったように、ある役割での実績を根拠に、異なる能力を必要とする役割へ進めると、本人だけでなく周囲が補修作業を引き受けることになる[12]。同じ能力移転の誤りは、組織にも類推できる。大量の実装要員を管理できる会社が、経営課題を構造化できるとは限らない。
2.3 帳票と承認が責任回避の装置になる
形式的な管理は、能力不足を隠すだけでなく、責任回避にも役立つ。顧客の承認印があれば、判断が誤っていても「承認された要求どおりに作った」と説明できる。成果物を納品すれば、業務上の成果が出なくても契約上の責務を終えられる。新しい問題が見つかれば、予定外作業として追加見積もりへ切り出せる。
この仕組みでは、プロジェクトの成功より、依頼された作業を実施した証拠の方が組織防衛上の価値を持つ。取引、合意、承認の構造を組み合わせると、帳票は結果として責任回避の装置としても働く[8][10][11]。上流工程で必要なのは判断責任の引受けであるが、下請け型の商慣行は、責任を細かく分割し、契約の境界へ押し戻す方向に働く。結果として、誰も全体の成果に責任を持たず、帳票だけが増える。
下流工程の管理手法で上流工程を支配しようとする会社は、上流工程を高度に管理しているのではない。未知を発見し、問いを立て、判断を成立させる能力を持たないため、上流工程を自社が扱える形式へ劣化させている。これが、細かな WBS と頻繁な報告会が存在しても、重要な判断が進まない理由である。
3. 上流工程で管理すべきものは何か
3.1 作業量から不確実性へ
上流工程の管理対象を変える必要がある。中心に置くのは、作業の消化量ではなく、不確実性、意思決定、依存関係、後続工程への着手可能性である。何時間働いたか、何ページ書いたかではなく、何が分かり、何が決まり、次に何ができるようになったかを追う。
不確実性が高い仕事では、組織が処理すべき情報量も増える。組織設計を情報処理の観点から捉える理論では、仕事の不確実性が増えるほど、部門横断の調整や情報処理能力を高める必要がある[13]。上流工程の停滞を、担当者の作業速度だけで説明してはならない。必要な情報が別部門にあり、判断権限が上位者にあり、前提が契約先の方針に依存しているなら、個人の努力だけでは解消できない。
リスク一覧に既知の事象を並べるだけでも足りない。上流工程には、事実の不足、原因の不明、解釈の対立、前提の揺らぎ、実現可能性の不明、価値の不確かさが含まれる。プロジェクト管理をリスク管理から不確実性管理へ広げる必要があるという議論は、この範囲の広さを示している[14]。不確実性は、状況の理解、意味付け、学習、柔軟な行動に関わる管理対象として捉える必要がある[15]。
| 不確実性の種類 | 観察される状態 | 必要な対応 |
|---|---|---|
| 事実の不明 | 件数、時間、費用、利用状況などが把握されていない。 | 計測、資料確認、聞き取りによって事実を集める。 |
| 原因の不明 | 現象は見えているが、なぜ起きるかが分からない。 | 因果仮説を作り、追加調査や比較によって検証する。 |
| 実現可能性の不明 | 技術、制度、予算、運用上の実行可能性が分からない。 | 小規模な試作、専門家確認、制約調査を行う。 |
| 価値の不明 | 施策を実行した場合の効果が判断できない。 | 効果試算、実験、利用者検証によって比較材料を作る。 |
| 利害の不一致 | 部門ごとに望ましい結果や優先順位が異なる。 | 判断基準を共有し、権限を持つ者が優先順位を決める。 |
| 権限の不明 | 誰が決定できるか、誰がリスクを受容するか分からない。 | 意思決定者と付議経路を明確にする。 |
| 前提の不安定 | 予算、制度、市場、組織方針が変わる可能性がある。 | 条件分岐と再確認時点を設定する。 |
3.2 完全な理解ではなく、判断可能な状態を作る
上流工程では、すべてを理解してから次へ進むことはできない。時間、情報、計算能力には限界があり、人間は完全な最適化ではなく、一定の条件を満たす選択肢を見つけて意思決定する[16]。重要なのは、未知をゼロにすることではなく、残る未知を把握し、受け入れ可能な範囲へ減らすことである。
製品選定を例にすると、全製品の全機能を比較する必要はない。必須条件を定め、明らかに適合しない候補を除外し、重大な技術的不確実性を小規模に検証し、判断できる候補数まで絞ればよい。調査の目的は知識を増やし続けることではなく、次の行動を選べる状態を作ることにある。
3.3 情報不足と解釈の対立を分ける
同じ「分からない」でも、情報が足りない場合と、同じ情報に複数の解釈が成立する場合では対応が違う。前者は資料や数値を集めれば改善する。後者は、立場の異なる関係者が対話し、言葉の意味、優先順位、利害をすり合わせなければ解消しない。組織の情報要求と伝達手段を扱う研究でも、曖昧さが高い場面では、豊かな対話手段が必要になるとされる[17]。
要件が曖昧だから追加資料を作る、という対応だけでは不十分なことがある。営業部門の「迅速な承認」と、管理部門の「統制された承認」が衝突しているなら、事実の不足ではなく価値判断の対立である。資料のページを増やしても解決しない。判断者を同じ場へ集め、優先順位を決める必要がある。
3.4 時間順序ではなく依存関係を管理する
上流工程では、どの作業を先に行うかより、どの成果がどの判断を可能にするかが重要になる。組織内の仕事には複数の相互依存があり、共通資源を使う関係、前の成果を次へ渡す関係、相互に調整しながら進める関係では、必要な管理方法が異なる[18]。
現行業務調査と現行システム調査は並行できるかもしれない。しかし、両方の結果を統合しなければ、問題原因の分析へ進めない。予算上限が決まらなければ製品候補を絞れず、法務部門がデータ保存条件を判断しなければ構成案を確定できない。作業担当者だけを追っても、この停滞は解消しない。管理すべきなのは、情報、判断、権限、資源の依存関係である。
4. 三層・反復型マネジメントの全体像
4.1 三つの管理層
上流工程では、全体の現在地、検討の構造、直近の対話と判断を、一つの巨大な工程表へ押し込めない。時間軸と目的の異なる三つの管理層へ分ける。
本稿では、この三つの管理層を調査と判断の結果に応じて連動させる枠組みを「三層・反復型マネジメント」と呼ぶ。既成の標準名称ではなく、上流工程の管理要素を実務向けに統合した呼称である。
| 管理層 | 管理対象 | 中心となる問い | 主な更新契機 |
|---|---|---|---|
| ロードマップ | フェーズ、目的、移行条件、重大な持ち越しを管理する。 | 現在はどの段階にあり、何が揃えば次へ進めるのか。 | フェーズ移行時、重大な前提変更時に更新する。 |
| アプローチ図 | 問い、検討単位、成果、依存関係、判断点を管理する。 | 何をどの順序で明らかにし、どの結果を次へ渡すのか。 | 週次、重要な発見、判断、前提変更の発生時に更新する。 |
| セッションスケジュール | 調査、議論、判断の場と参加者を管理する。 | 次に誰と何を確認し、何を決めるのか。 | 日次、セッション終了時、参加者変更時に更新する。 |
三層は、同じ計画を粗くしたものと細かくしたものではない。ロードマップはプロジェクトの意味上の現在地を表し、アプローチ図は知識と判断の依存関係を表し、セッションスケジュールは具体的な認識形成と意思決定を表す。三つを分けることで、遠い将来は粗く、近い行動は具体的に計画できる。
4.2 三層をつなぐ情報
三層を別々に作るだけでは機能しない。ロードマップの移行条件は、アプローチ図上のどの検討が終われば満たされるのかへ接続する。アプローチ図の各検討は、どのセッションや調査で進めるのかへ接続する。セッションで得た事実や決定は、アプローチ図とロードマップへ戻す。
受注処理の改善を例にすると、三層は次のように連動する。
| 段階 | 管理内容 |
|---|---|
| ロードマップ | 現状分析フェーズに置き、遅延原因と改革対象の合意を次フェーズへの移行条件とする。 |
| アプローチ図 | 業務調査とシステム調査を並行し、両方の結果を統合して主要原因を特定する流れを示す。 |
| セッション | 営業、管理、情報システム部門を集め、主要原因と改革対象の優先順位を決める。 |
| 更新 | 契約条件が遅延へ影響すると判明した場合は、アプローチ図へ法務確認を追加し、移行条件を再確認する。 |
| 状態変化 | 原因調査を「探索中」から「判断材料準備済み」へ進め、判断後に後続の将来構想へ反映する。 |
大規模なシステム工学では、ライフサイクル、技術的な検討、審査、要求、構成、検証を異なる水準で接続し、判断点を明示する[19]。本稿の三層も、管理資料を増やすためではなく、異なる時間軸の判断をつなぐために使う。
4.3 反復が管理の中心になる
三層は、最初に作って固定する計画ではない。目的、選択肢、制約、重大な不確実性を確認し、小さく検証し、その結果を次の計画へ戻す。リスク駆動型の反復を示したスパイラルモデルも、評価と計画更新を繰り返す構造を持つ[20]。
正しい計画を最初に作ることはできない。必要なのは、計画を継続的に正しくする仕組みである。新しい事実が見つかったとき、計画との差異を責めるのではなく、三層のどこを更新すべきかを判断する。
5. ロードマップでフェーズと移行条件を管理する
5.1 フェーズは解くべき問題で区切る
ロードマップは、月別の大日程表ではない。「4 月は調査、5 月は構想、6 月は要件定義」と日付だけで区切ると、必要な判断が終わっていなくても時間の経過によって次工程へ進んでしまう。フェーズは、その段階で解くべき問題と、次へ進む条件によって定義する。
現状分析フェーズなら、中心問題は「現行業務とシステムのどこに主要な阻害要因があり、改革対象をどこへ置くか」である。将来構想フェーズなら、「どの業務能力を、どの優先順位で、どの制約の下で実現するか」となる。フェーズ名より、解くべき問いの方が重要である。
5.2 ロードマップの記載項目
| 項目 | 記載内容 |
|---|---|
| フェーズ名 | 関係者が共通に理解できる名称を置く。 |
| 中心問題 | その段階で解くべき主要な問いを一文で示す。 |
| 開始条件 | 前段階から何が渡されれば開始できるかを示す。 |
| 主要成果 | 判断と後続作業に必要な結果を示す。 |
| 移行条件 | 次のフェーズへ進むために満たす状態を示す。 |
| 判断者 | 移行可否と残存リスクを受容する者を示す。 |
| 主要前提 | 現時点で成立すると仮定している条件を示す。 |
| 持ち越し事項 | 未解決のまま次へ渡す事項と影響を示す。 |
| 予定期間 | 判断と調整に必要な時間の目安を示す。 |
| 期限超過の影響 | 後続工程、予算、契約、事業計画への影響を示す。 |
5.3 移行条件を成果物名だけで定義しない
「現状分析報告書が完成したら終了」と定めると、文書を完成させることが目的になる。報告書が存在しても、主要な問題原因について部門間の認識が一致せず、改革対象が決まっていなければ、将来構想へ進む準備はできていない。
現状分析フェーズの移行条件は、たとえば次のように定める。
- 主要な問題が三つから五つに整理されている。
- 各問題の影響範囲と重大度が把握されている。
- 観察された事実と原因仮説が区別されている。
- 改革対象としない領域が明示されている。
- 重大な未解決事項とその影響が記録されている。
- 将来像の検討に必要な参加者と入力情報が揃っている。
- 責任を持つ判断者が次フェーズへの移行を受け入れている。
5.4 持ち越しを隠さない
上流工程では、未解決事項を残したまま次へ進むことがある。問題は、残すことではなく、残っていることを隠すことである。持ち越し事項には、内容、未解決の理由、後続への影響、暫定前提、解消責任者、再確認時点、リスクを受容した判断者を記録する。
ロードマップは、到達した状態、残存リスク、リスクを受容した判断者を示す。日付より状態を優先することで、フェーズの境界が実質を持つ。
6. アプローチ図で問いと依存関係を管理する
6.1 作業名ではなく問いを置く
アプローチ図は、上流工程で何を明らかにし、その結果がどの判断や後続作業を可能にするかを表す。管理単位は、「資料を作る」「聞き取りを行う」といった活動名ではなく、答えるべき問いとする。
| 作業中心の表現 | 問い中心の表現 |
|---|---|
| 現状調査資料を作成する | 受注処理の遅延を生む主要因を特定する。 |
| 製品比較表を作成する | 必須条件を満たす候補を三つ以内へ絞る。 |
| 構成案を検討する | 個人情報の保存条件を満たす構成候補と制約を明らかにする。 |
| 利用者への聞き取りを行う | 例外処理が発生する条件と判断主体を把握する。 |
活動名だけでは、何のために行い、何が得られれば終了か分からない。問いを置けば、必要な入力、調査方法、判断者、終了条件を定められる。成果物は目的ではなく、問いへの回答を保存し、共有する媒体になる。
6.2 検討単位の構造
| 項目 | 記載内容 |
|---|---|
| 問い | 何を明らかにするのかを疑問文または判断文で示す。 |
| 入力 | 開始に必要な情報、前提、先行判断を示す。 |
| 活動 | 調査、分析、試作、比較、議論などの方法を示す。 |
| 成果 | 判断材料、図、一覧、試算、決定記録などを示す。 |
| 判断者 | 結果を受け入れ、次の方向を決める者を示す。 |
| 終了条件 | どこまで分かれば後続へ進めるかを示す。 |
| 前提 | 現時点で成立すると置く条件と有効期限を示す。 |
| 未解決事項 | 残っている問いと影響を示す。 |
| 後続 | 結果を渡す検討、判断、成果物を示す。 |
| 状態 | 現在の進行状態と次の遷移条件を示す。 |
6.3 依存関係を区別する
アプローチ図では、矢印の意味を明確にする。すべてを「先に終わる必要がある」と表現すると、停滞原因が分からなくなる。
| 依存関係 | 意味 | 例 |
|---|---|---|
| 情報依存 | 先行する調査結果がなければ、後続の分析を開始できない。 | 現行業務調査とシステム調査の結果が、問題原因分析の入力になる。 |
| 判断依存 | 方針や優先順位が決まらなければ、候補を絞れない。 | 予算上限の決定が、製品候補の選定条件になる。 |
| 権限依存 | 権限を持つ者の承認やリスク受容が必要になる。 | 個人情報の外部保存可否を、情報管理責任者が判断する。 |
| 資源依存 | 同じ専門家や環境を複数の検討が取り合う。 | 基盤担当者が複数の技術検証を並行できない。 |
| 制度依存 | 法令、契約、社内規程の確認が必要になる。 | 保存期間の決定が、規制と契約条件に依存する。 |
| 相互調整 | 複数の検討が互いの結果を見ながら収束する。 | 将来業務とシステム構成を往復しながら整合させる。 |
6.4 図は変更を前提とする
アプローチ図は、調査結果に応じて追加、削除、統合、分割する。新しい規制条件が見つかれば法務確認を追加し、二つの問題が同じ原因から生じていると分かれば検討を統合する。ある案が事業方針と合わないと判断されれば、その案に依存する検討を削除する。
変更理由を残すことで、後から見た人が「なぜ当初計画どおりに進まなかったのか」ではなく、「どの事実が計画を変えたのか」を理解できる。変更履歴は責任逃れの記録ではなく、判断の再現性を支える記録になる。
7. セッションスケジュールで判断を成立させる
7.1 会議の数ではなく判断の成立を管理する
セッションスケジュールは、会議予定表ではない。アプローチ図上の問いについて、必要な知識、利害関係者、判断権限を同じ場へ接続し、次の行動を成立させる計画である。
「構成検討会」とだけ書かれた予定では、何を決めるのか分からない。「個人情報を外部クラウドへ保存できる条件を確認し、構成候補を二案以内へ絞る」と置けば、必要な資料、参加者、判断者、終了条件を決められる。判断の速さは、情報や対立を省くことで得られるのではない。現実の情報を継続的に確認し、複数の選択肢を比較し、決定過程を統合することで高められる[21]。
7.2 セッションの設計項目
| 項目 | 記載内容 |
|---|---|
| セッション名 | 解くべき問いや判断内容が分かる名称を置く。 |
| 目的 | 終了時に何が変わっているべきかを示す。 |
| 判断事項 | 選択、承認、優先順位、リスク受容の対象を示す。 |
| 事前情報 | 参加者が事前に確認すべき資料と前提を示す。 |
| 必須参加者 | 知識、利害、実行責任を持つ者を示す。 |
| 判断者 | 最終的に決定できる者を示す。 |
| 進行責任者 | 論点を整理し、議論を収束させる者を示す。 |
| 期待成果 | 決定、選択肢、追加調査、持ち越し条件を示す。 |
| 終了条件 | セッションを閉じられる状態を示す。 |
| 未決着時の処置 | 不足情報、担当者、期限、上位付議の条件を示す。 |
7.3 結果を分類する
セッション終了時の結果は、次のいずれかへ分類する。
- 決定
- 条件付き決定
- 追加調査
- 上位判断への付議
- 対象外
- 持ち越し
- 前提の変更
- アプローチ図の変更
「継続検討」とだけ記録すると、何が不足し、誰が、いつ、何を確認するのか分からない。追加調査なら、必要な情報、担当者、期限、次回判断日を決める。上位判断なら、付議先と判断材料を決める。セッションは議論した事実ではなく、次の状態を作ったかで評価する。追加調査は「探索中」へ戻し、決定は「決定済み」へ進め、持ち越しは通常の進行状態から外して持ち越し管理へ移す。
7.4 参加者を増やせばよいわけではない
必要な知識と権限を揃えることは、全関係者を常に集めることとは違う。参加者が多すぎると、説明と防衛に時間を使い、判断が曖昧になる。問いごとに、事実を持つ者、影響を受ける者、実行責任を持つ者、決定権を持つ者を選ぶ。
判断者が参加できない場合は、事前に判断基準と委任範囲を確認する。権限がない会議で結論を装うより、判断待ちを明示して上位へ付議する方がよい。上流工程では、判断待ちを作業者の遅延へ変換しないことが重要である。
8. 三層を反復運用する標準サイクル
8.1 標準となる 12 段階
- ロードマップで現在のフェーズと移行条件を確認する。
- アプローチ図から後続を止めている重大な不明点を特定する。
- 不明点を事実、原因、実現可能性、価値、利害、権限、前提へ分類する。
- 次の判断に必要な最小限の探索を設計する。
- 個別調査、試作、分析、セッションを実施する。
- 得られた内容を事実、仮説、判断へ分けて記録する。
- 必要な権限者が意思決定する。
- 決定内容を要求、構成、予算、計画などの後続成果へ反映する。
- 新たに判明した不明点と前提変更を登録する。
- アプローチ図を追加、削除、統合、分割する。
- ロードマップの移行条件と持ち越し事項を再確認する。
- 次の反復へ進む。
短い反復で要求を管理し、部門横断で協働し、実行と統制を組み合わせる考え方は、アジャイル導入の公的な実務手引でも重視されている[22]。ただし、三層・反復型マネジメントは、反復型開発手法である Scrum の言い換えではない。開発作業の反復より前に、何を作るべきか、何を決めるべきかを管理する。
8.2 最小限の探索を設計する
探索は、対象を完全に理解するためではなく、次の判断を可能にするために行う。製品候補が 20 個あるなら、最初から全機能を比較しない。必須条件と除外条件を決め、重大な不確実性だけを確認し、候補を三つ程度まで絞る。その後に詳細比較を行う。
計画には、最初から決められた部分と、行動の中から形成される部分がある。意図した戦略と、実際の経験から生まれる戦略を連続体として捉える考え方は、計画変更を学習の結果として理解する助けになる[23]。上流工程では、当初計画へ従うことより、現実から得た情報を計画へ戻すことの方が重要である。
8.3 探索と活用の切替え
調査を続ければ、新しい情報は際限なく見つかる。一方、早すぎる決定は重大な不確実性を残す。組織学習では、新しい可能性を探す探索と、得られた知識を利用する活用の均衡が問題になる[24]。上流工程も同じであり、調査から判断へ移る停止条件が必要になる。
既稿「選択のパラドックスとは何か：意思決定設計の原理」では、選択肢が多いほどよいとは限らず、評価基準と停止条件を先に設計する必要を整理した[25]。三層管理では、各検討単位に終了条件を置き、追加情報が判断を変える可能性と、調査継続に必要な時間を比較する。
8.4 更新周期を分ける
| 周期 | 主な確認内容 | 更新対象 |
|---|---|---|
| セッション終了時 | 決定、条件、宿題、前提変更、次の行動を確認する。 | セッション記録、検討単位、意思決定記録を更新する。 |
| 日次・随時 | 重大な不明点、後続を止める障害、外部条件の変化を確認する。 | 不明点一覧、前提一覧、直近予定を更新する。 |
| 週次 | 依存関係、判断待ち、追加作業、次週の判断を確認する。 | アプローチ図とセッションスケジュールを更新する。 |
| 月次・節目 | 期限、予算、体制、事業計画への影響を確認する。 | ロードマップと重大な持ち越し事項を更新する。 |
| フェーズ移行時 | 終了条件、残存リスク、後続工程の受入可能性を確認する。 | ロードマップ、引き渡し一覧、判断記録を確定する。 |
8.5 補助管理資料を増殖させない
三層を支えるために、不明点一覧、前提一覧、意思決定記録、持ち越し事項一覧、変更履歴を使う。ただし、帳票を増やすほど管理が良くなるわけではない。同じ情報を複数の表へ転記すると、更新漏れと不整合が増える。
各情報には一つの正本を決める。アプローチ図は関係を示し、検討単位票は詳細を持ち、意思決定記録は判断理由を保存する。週次会議のために別の報告資料を作るのではなく、これらの資料を直接確認しながら進める。
9. 進捗率を捨て、状態と終了条件で管理する
9.1 検討単位の状態遷移
上流工程の「80％完了」は、残りの内容も阻害要因も示さない。代わりに、検討単位がどの状態にあり、次の状態へ進む条件が何かを管理する。
進行状態と、検討を終了または中断する区分は分けて管理する。
| 進行状態 | 意味 | 次へ進む条件 |
|---|---|---|
| 問い未定義 | 問題意識はあるが、何を明らかにするかが定まっていない。 | 問い、影響、判断主体を定義する。 |
| 問い定義済み | 調査対象と終了条件が定義されている。 | 必要な入力、担当者、方法を確保する。 |
| 探索中 | 調査、分析、試作、聞き取りを行っている。 | 主要な事実と論点を整理する。 |
| 論点整理済み | 原因仮説、選択肢、制約が見えている。 | 判断基準と必要な追加情報を揃える。 |
| 判断材料準備済み | 判断者が選択できる材料が揃っている。 | 判断者と判断日を確保する。 |
| 判断待ち | 作業ではなく権限者の決定を待っている。 | 決定、条件付き決定、上位付議のいずれかを行う。 |
| 決定済み | 方針、選択肢、リスク受容が確定している。 | 要求、計画、構成、予算へ反映する。 |
| 後続反映済み | 決定が後続成果へ組み込まれている。 | 終了条件を確認する。 |
| 完了 | 終了条件を満たし、検討単位を閉じている。 | 前提変更や重大な新事実が生じた場合だけ再開する。 |
通常の進行状態から外れる場合は、次の終了・例外区分を付ける。
| 終了・例外区分 | 意味 | 処理 |
|---|---|---|
| 持ち越し | 未解決事項を明示し、リスクを受容して次へ進む。 | 再確認時点、解消責任者、リスク受容者を記録する。 |
| 破棄 | 方針変更などにより検討の必要がなくなった。 | 破棄理由と後続への影響を記録して閉じる。 |
| 上位判断へ移管 | 現在の判断者の権限では結論を出せない。 | 付議先、判断材料、期限を定める。 |
| 前提変更により再開 | 完了後に主要前提が崩れ、判断の再検討が必要になった。 | 影響を受ける状態へ戻し、変更理由を記録する。 |
「決定済み」と「後続反映済み」を分け、終了条件を満たした段階で「完了」とすることが重要である。会議で方針が決まっても、要求、設計条件、予算、契約、計画へ反映されなければ、実務は変わらない。持ち越しや破棄を進行状態から分けることで、通常の前進と例外処理も混同せずに管理できる。
9.2 終了条件を設計する
各検討単位は、次の条件を確認して閉じる。
- 問いに対する回答が示されている。
- 回答を支える事実または合理的な根拠がある。
- 観察事実と原因仮説が区別されている。
- 主要な前提と有効期限が明示されている。
- 未解決事項と後続への影響が記録されている。
- 判断者が結果または残存リスクを受容している。
- 後続工程が具体的な行動を開始できる。
- 決定内容が後続成果物へ反映されている。
完了とは、対象について完全に理解した状態ではない。残る未知を把握し、後続工程が合理的に着手できる状態である。必要な精度は、後続が何を行うかによって決まる。概算予算を出す段階と、契約を締結する段階では、同じ問いでも必要な精度が違う。
9.3 持ち越し条件
未解決事項を残して進む場合は、少なくとも次を記録する。
| 項目 | 記載内容 |
|---|---|
| 未解決内容 | 何が分かっていないかを具体的に示す。 |
| 未解決理由 | 時間、情報、権限、外部条件などの理由を示す。 |
| 暫定前提 | 後続が行動するために置く仮定を示す。 |
| 影響 | 前提が外れた場合の費用、日程、品質、事業への影響を示す。 |
| 解消責任者 | 再確認と解消を担当する者を示す。 |
| 再確認時点 | 日付、条件、判断点のいずれかを示す。 |
| 受容者 | 残存リスクを理解して進行を認めた者を示す。 |
9.4 管理指標
単一の進捗率に代えて、停滞の場所と種類を示す少数の指標を使う。
- 重大な不明点の件数
- 判断待ちの件数と滞留日数
- 後続作業を停止させている依存関係
- 判断材料準備済みの検討数
- 後続反映済みの決定数
- 重大な持ち越し事項の件数
- 前提が崩れた件数
- 判断者を確保できていないセッション数
- 次の一定期間に必要な意思決定数
新しい問題が見つかった件数は、単純な悪化指標ではない。早期に重大な問題を発見できたなら、上流工程が正常に機能している。評価すべきなのは、発見された問題が構造化され、優先順位を付けられ、次の行動へ変換されたかである。
9.5 意思決定記録を残す
後から結果だけを見ると、当時の判断が愚かに見えることがある。反対に、結果が良ければ、危うい判断まで正しかったように見える。既稿「認知バイアスを深堀りする」で整理したように、後知恵による再解釈を避けるには、判断時点の情報、選択肢、前提、懸念を保存する必要がある[26]。
意思決定記録には、判断事項、選択肢、採用案、採用理由、却下理由、前提、残存リスク、判断者、判断日、再確認条件を残す。これにより、前提が崩れたときに、当時の判断全体を否定するのではなく、どの部分を再検討すべきかを特定できる。
10. 上流工程を上流工程のまま管理できる組織
10.1 必要なのは道具ではなく役割と権限である
三層の図や表を導入しても、判断権限が曖昧なら機能しない。管理資料は停滞を可視化できるが、誰かに判断責任を引き受けさせることはできない。少なくとも、次の役割を明確にする。
| 役割 | 責任 |
|---|---|
| プロジェクトオーナー | 目的、優先順位、重大なリスクの受容、フェーズ移行を決める。 |
| フェーズ責任者 | 移行条件、アプローチ図、重大な依存関係を管理する。 |
| 検討責任者 | 問いを定義し、調査し、判断材料を作る。 |
| 判断者 | 選択、優先順位、承認、リスク受容を行う。 |
| 進行責任者 | セッションを設計し、論点を整理し、結論へ収束させる。 |
| 後続工程の代表者 | 結果が実際に利用可能かを確認し、不足する入力を指摘する。 |
| 管理担当 | 三層の整合、判断待ち、持ち越し、変更履歴を管理する。 |
10.2 問題を発見した者を罰しない
反復型の管理では、新しい問題を早く報告できることが重要になる。懸念や誤りを示すことが対人的な危険になる職場では、組織学習が阻害される。心理的安全性と学習行動の研究も、問題を表明できる環境の重要性を示している[27]。
予定外の問題を見つけた担当者を「遅延の原因」として扱えば、次から問題は隠される。進捗率は高く維持されるが、後工程で大きな手戻りが起きる。報告者を守るという道徳的配慮だけではない。上流工程を機能させるための管理条件である。
10.3 計画変更を敗北にしない
組織が当初計画へ強く責任を結び付けると、悪い結果が見えても方針を変更しにくくなる。既に投じた資源や自分の判断を正当化するため、むしろ追加投入を続ける現象は、コミットメントのエスカレーションとして研究されている[28]。
三層管理では、変更を三段階に分ける。セッションの日程や調査方法の変更は局所変更として検討責任者が判断する。作業の追加、削除、依存関係の変更はアプローチ変更としてフェーズ責任者が判断する。目的、対象範囲、主要期限、予算、体制の変更はプロジェクト変更としてオーナーが判断する。変更を抑止するのではなく、影響範囲に応じて決定権限を変える。
10.4 最小構成から導入する
最初から大量の帳票を作る必要はない。次の四点から始めれば、従来の WBS 中心管理との差が見える。
- フェーズと移行条件を一枚のロードマップで示す。
- 重要な問いと依存関係を一枚のアプローチ図で示す。
- 直近二週間の判断セッションを予定する。
- 判断待ちと持ち越し事項を一覧化する。
運用を始めた後、必要に応じて検討単位票、前提一覧、意思決定記録を追加する。最初から完成形を導入しようとすると、方法論自体が帳票主義へ戻る。
10.5 失敗する典型
| 失敗 | 起きていること | 修正 |
|---|---|---|
| ロードマップが大日程表になる | 日付だけが並び、移行条件と判断者がない。 | 各フェーズを中心問題と到達状態で定義する。 |
| アプローチ図が細かな WBS になる | 活動が細分化され、問いと依存関係が見えない。 | 後続判断を可能にする検討単位まで粒度を上げる。 |
| セッションが定例報告会になる | 進捗報告だけで、判断事項と終了条件がない。 | 解くべき問い、判断者、期待成果を事前に定める。 |
| 判断者が不在になる | 実務担当者だけが議論し、結論を出せない。 | 判断者を招集するか、委任範囲と上位付議を定める。 |
| 変更が失敗扱いされる | 新しい事実が隠され、古い計画が維持される。 | 変更理由と影響を記録し、適切な権限で更新する。 |
| 持ち越しが宿題になる | 責任者、期限、影響が不明なまま放置される。 | 暫定前提、再確認条件、リスク受容者を記録する。 |
| 状態を百分率へ戻す | 判断待ちや権限不足が作業進捗へ圧縮される。 | 状態、次の遷移条件、滞留原因をそのまま示す。 |
10.6 上流能力とは何か
上流能力は、会議資料を作る能力でも、顧客の発言を要求一覧へ転記する能力でもない。何が分かっていないかを特定し、必要な問いへ変え、適切な人物を集め、判断材料を作り、権限者に決めさせ、その結果を後続工程へ接続する能力である。
この能力は、下流工程の管理能力を拡張すれば自動的に得られるものではない。作業を管理する発想から、知識と判断を管理する発想へ移る必要がある。顧客の指示に従うだけでなく、指示の前提が誤っていれば指摘し、判断者が不在なら明示し、必要な決定を要求しなければならない。
下流工程しか実質的に扱えない会社が上流工程へ進出すると、上流工程を下流工程の形式へ偽装しやすい。詳細な WBS、頻繁な進捗報告、厚い成果物は、その偽装を管理の高度化に見せる。しかし、未知を隠し、判断を先送りし、責任を承認印へ分散する管理は、プロジェクトを前へ進めない。
上流工程で管理すべきものは、作業の消化率ではない。どこに不明点があり、何を調べれば判断でき、誰が決め、その決定がどの後続作業を可能にするかである。ロードマップで現在地と移行条件を示し、アプローチ図で問いと依存関係を示し、セッションスケジュールで対話と判断を具体化する。得られた事実に応じて三層を更新し、完全な理解ではなく、次の行動を合理的に開始できる状態を作る。
これが、上流工程を上流工程のまま管理するための三層・反復型マネジメントである。
参考文献
- Department of Defense, MIL-STD-881F: Work Breakdown Structures for Defense Materiel Items（2022-05-13）. https://quicksearch.dla.mil/qsdocdetails.aspx?ident_number=36026
- U.S. Government Accountability Office, Cost Estimating and Assessment Guide: Best Practices for Developing and Managing Program Costs（2020-03-12）. https://www.gao.gov/products/gao-20-195g
- International Organization for Standardization, ISO 21502:2020, Project, programme and portfolio management — Guidance on project management（2020-12）. https://www.iso.org/standard/74947.html
- J. Rodney Turner and Robert A. Cochrane, Goals-and-methods matrix: coping with projects with ill defined goals and/or methods of achieving them（1993-05）. https://doi.org/10.1016/0263-7863(93)90017-H
- Horst W. J. Rittel and Melvin M. Webber, Dilemmas in a General Theory of Planning（1973-06）. https://doi.org/10.1007/BF01405730
- Roger Buehler, Dale Griffin and Michael Ross, Exploring the “Planning Fallacy”: Why People Underestimate Their Task Completion Times（1994-09）. https://doi.org/10.1037/0022-3514.67.3.366
- id774, 測ることは、考えることの代わりにならない（2026-07-02）. https://blog.id774.net/entry/2026/07/02/4931/
- 公正取引委員会, ソフトウェア業の下請取引等に関する実態調査報告書（2022-06-29）. https://www.jftc.go.jp/houdou/pressrelease/2022/jun/220629_sw_03.pdf
- 経済産業省, DXレポート～ITシステム「2025年の崖」の克服とDXの本格的な展開～（2018-09-07）. https://www.meti.go.jp/policy/it_policy/dx/20180907_03.pdf
- 情報処理推進機構, 超上流から攻めるIT化の原理原則17ヶ条（2006）. https://www.ipa.go.jp/archive/publish/qv6pgp0000000xa0-att/000005109.pdf
- 室谷隆, 共通フレーム2013の概説（2013-03）. https://www.ipa.go.jp/archive/files/000027415.pdf
- id774, ピーターの法則の本当の被害者とは（2026-01-25）. https://blog.id774.net/entry/2026/01/25/3361/
- Jay R. Galbraith, Organization Design: An Information Processing View（1974-05）. https://doi.org/10.1287/inte.4.3.28
- Stephen Ward and Chris Chapman, Transforming project risk management into project uncertainty management（2003）. https://doi.org/10.1016/S0263-7863(01)00080-1
- Olga Perminova, Magnus Gustafsson and Kim Wikström, Defining uncertainty in projects — a new perspective（2008）. https://doi.org/10.1016/j.ijproman.2007.08.005
- Herbert A. Simon, A Behavioral Model of Rational Choice（1955-02-01）. https://doi.org/10.2307/1884852
- Richard L. Daft and Robert H. Lengel, Organizational Information Requirements, Media Richness and Structural Design（1986-05-01）. https://doi.org/10.1287/mnsc.32.5.554
- James D. Thompson, Organizations in Action: Social Science Bases of Administrative Theory（2017、初版 1967）. https://doi.org/10.4324/9781315125930
- National Aeronautics and Space Administration, NASA Systems Engineering Handbook, NASA/SP-2016-6105 Rev 2（2016）. https://www.nasa.gov/wp-content/uploads/2018/09/nasa_systems_engineering_handbook_0.pdf
- Barry W. Boehm, A Spiral Model of Software Development and Enhancement（1988-05）. https://doi.org/10.1109/2.59
- Kathleen M. Eisenhardt, Making Fast Strategic Decisions in High-Velocity Environments（1989-09）. https://doi.org/10.2307/256434
- U.S. Government Accountability Office, Agile Assessment Guide: Best Practices for Agile Adoption and Implementation（2020-09-28）. https://www.gao.gov/products/gao-20-590g
- Henry Mintzberg and James A. Waters, Of Strategies, Deliberate and Emergent（1985）. https://doi.org/10.1002/smj.4250060306
- James G. March, Exploration and Exploitation in Organizational Learning（1991-02-01）. https://doi.org/10.1287/orsc.2.1.71
- id774, 選択のパラドックスとは何か：意思決定設計の原理（2026-02-18）. https://blog.id774.net/entry/2026/02/18/3682/
- id774, 認知バイアスを深堀りする（2026-01-05）. https://blog.id774.net/entry/2026/01/05/3219/
- Amy C. Edmondson, Psychological Safety and Learning Behavior in Work Teams（1999-06）. https://doi.org/10.2307/2666999
- Barry M. Staw, Knee-deep in the big muddy: a study of escalating commitment to a chosen course of action（1976-06）. https://doi.org/10.1016/0030-5073(76)90005-2