WEEK 8 ／ 事前学習 最終回
アストロキャンプ2026 ／ 衛星開発ゼミ
0.1 前回までと今回の位置づけ
1
標準の定義を読み替えると判断の元手に行き着き、その元手が有限であることからトレードオフが生まれ、その正体は依存関係だと分かる。
1.1 標準の定義
プロジェクトの要求事項を満たすために、知識・スキル・ツール・技法をプロジェクト活動へ適用すること。
PMI（Project Management Institute）によるプロジェクトマネジメントの定義。PMI は標準体系 PMBOK ガイド（Project Management Body of Knowledge、現行第8版）をまとめた団体出典：PMI, “What Is Project Management?”
つまりどういうこと？
1.2 定義の読み替え
プロジェクトの要求事項を満たすために、知識・スキル・ツール・技法をプロジェクト活動に適用すること。
1.3 プロジェクト資源
では、その判断は何に対して行うのか。
1.4 トレードオフ
1.5 トレードオフの正体
両立できないように見える
依存関係があるから競合してトレードオフが生まれる
1.6 削る前に問うこと
1.7 選ぶときの基準
1.8 参考：PMBOK の全体像と今日の通り道
PMBOK 第8版の7つのパフォーマンス・ドメイン ／ 並行して走り続ける
横＝並行して管理し続けるドメイン、重ねた①②③＝本回で決めていく順番。独自の分類は立てず、標準の区分の上に通り道を描いている
1.9 この章のまとめ
実際の活動＝判断に根拠を持たせ、前に進め続けること。元手のプロジェクト資源（人・時間・予算）は有限で、判断は配る先＋配り方の両方。
トレードオフの正体は、依存の構造にある。ほぐせば消える対立と、外から固定されて残る本物の制約を見分ける。
削るのは最後の手段。まず依存を解き、次にリスクに備え、それでも足りないときに削る。
2
今日の中心。まず依存を読み、そのうえで2つの手でほどく。
2.1 密結合の3つの難しさ
① 絡む相手が多い。サブシステムの数だけ依存の相手がいる
② 内部事情まで絡む。例：姿勢角を返す関数の入出力で済むはずが、換算・フィルタの実装まで待ってしまう
③ 依存が堂々巡りする。互いに相手の完成を待つ循環ができ、両方が止まる
2.2 堂々巡り（循環依存）
互いの完成を待ち、両方が止まる。誰も怠けていないのに、何も進まない。
2.3 待ちが資源を捨てる
待っている間も、Cさんの時間は消費され続ける。作業の失敗と違い、やり直しても何も残らない
2.4 順番と完了時期
カレーライスとサラダを作る。工程はどちらも同じで、着手の順番だけを変える。
2.5 依存を読む（PERT 図とクリティカルパス）
2.6 ガントチャートとの対比
いつ何をするかと進捗は見える。矢印がないので、炊飯が完了時期を決めていることは読めない。
依存の線と最長経路が見える。時間軸は持たないので、着手の時刻は別に決める。
全タスクがテレコマの完成に依存する自分たちの計画では、依存を描けない図は計画の最大の敵を映せない。
2.7 参考：PDM・CPM と本来の PERT
ふだんの呼び名は「PERT 図」でよい。呼び名の違いで詰まる必要はない。
2.8 参考：ノードの書き分け
2.9 参考：ほかのスケジュール管理の手法
タスクを時間軸上のバーで並べる図
○ 大人数・長期の進捗共有に強い
△ 依存関係が主役ではない。少人数・短期間では得るものが少ない
Work Breakdown Structure。成果物・作業を階層的に分解して網羅する図
○ 抜け漏れの点検に強く、PERT 図のノードを書き出す下ごしらえになる
△ 一度で分解し切るのは難しい。粗く始めて更新し続ける
節目（マイルストーン）だけを時間軸に打つ図
○ 長期日程が一目で共有できる
△ 途中の作業量や依存は見えない。少人数・短期間では得るものが少ない
「未着手・作業中・完了」の列でタスク札を動かす板
○ いま誰が何をしているかが見える
△ 完了時期の見通しは示さない
2.10 何からやるか
作業量は同じでも、順番で完了時期は変わる。では、何を根拠に順番を決めるか。
2.11 優先度の3つの型
3つとも、依存の構造とリスクから順番の根拠を取っている。難しさや得意さは、順番の根拠にならない。
2.12 ほどく2つの手
2.13 手① 内部事情を切り離す
パケットフォーマットの合意に最低限含めるもの （行の中身は例。何を載せるかはチームの設計判断）
Week 7 の「呼ぶ側を変えずに中身を差し替えられる」を、コードの層からチームの層へ持ち上げた操作。契約まで固めることは、要求と制約を人にもAIにも渡せる形にする作業でもある。
2.14 手② 輪を切る
決め打ちを動かす道具が、ダミーデータとモック（Week 7）。実物ができたら差し替える。あわせて、依存の向きは一方向に揃え、最小の経路を先に1本通してから太らせる。
2.15 Conway の法則
システムを設計する組織は、その組織のコミュニケーション構造を写した構造の設計を生む（Conway, 1968）。
2.16 逆コンウェイ
上：望むシステム構造 下：そこから導く分担（2.15 の逆向き）
2.17 この章のまとめ
待ちが資源を最も大きく捨てる。マネジメントの本質はタスクの依存関係をほどくこと。
クリティカルパスが完了時期を決める。「何からやるか」は、経路上・リスクの高さ・依存の根元で決める。
ほどく手は2つ。切り離し（インターフェース）・輪を切る（決め打ち）。可視化（PERT 図）は、ほどく前に依存を読む道具。
分担の線がシステムの分かれ目になる。割り当てと、どこで依存を切るかは1つの判断。
3
依存をほどいても、見積もりは外れる。手戻りと停止に先に手を打ち、残量を見張る。
3.1 不確実性とリスク
不確実性（上位の語）
リスク＝名指しできるもの
洗い出して評価し、対応を作れる事象
残り＝名指しできない外れ → 使い道を決めない資源で備える
3.2 リスクマネジメントの3段階
Week 6 で技術的な壊れ方（故障モード）に当てたこの形を、計画・スケジュール・資源へ当てる。例は、電池が想定より持たない、部品が壊れる、メンバーが1日離脱する。
3.3 対応の4つの型
備えないという判断も、根拠を言えるなら判断である。起こりやすさも影響も小さいものに資源を割くほうが、配り方としては下手になる。
3.4 マージン
使い道が決まっていないことが機能。どんな外れ方にも充てられる
マージンは怠慢ではなく、有限の資源の配分に関する意思決定である。
3.5 参考：三点見積もり
カレーの煮込み（2.5 の例）を1点の20分ではなく、15〜30分の幅で扱う。この3点を PERT 図に載せた派生が、本来の PERT（2.7）。
3.6 計画の窓
運用中、衛星の中は覗けない。テレメトリだけが観測の窓。
計画のズレは、マージンの残量とクリティカルパス上の進み具合に現れる。
3.7 スナップショット
3.8 決め直しの輪
3.9 計画の立て方
どれを採るかは、全体像がどれだけ見えているかで決まる設計判断。本ゼミでは適応型を中心に、固定された日程や合流点には予測型の考え方も使う。どの部分を固定し、どの部分を反復するかも設計判断で、ダブルダイヤモンドを繰り返す形（4.2）と同じ向き。
3.10 この章のまとめ
名指しできるリスクは、洗い出して評価して対応を決める。対応の型は、避ける・減らす・移す・受け入れるの4つ。
名指しできない残りには、使い道を決めない資源を残す。これがマージン。使い道が決まっていないことが機能。
マージンは、残量を見張って初めて機能する。計画の窓はマージンの残量とクリティカルパス上の進み具合。更新前の計画はスナップショットとして残す。
決め直したら、また取りこぼしを潰す段へ戻る。この輪が回り続けることが「前に進め続ける」の中身。
まとめ
判断に根拠を持たせ、前に進め続ける。元手のプロジェクト資源（人・時間・予算）は有限で、判断は配る先＋配り方。
トレードオフの正体は、依存の構造にある。ほぐせば消える対立と、外から固定されて残る本物の制約を見分ける。
削る前に、取りこぼしを潰す。依存は PERT 図で読み、インターフェースとダミーの2つの手でほどく。
リスクは名指しして対応を作り、残りはマージンで備える。残量を見張り、更新前の計画はスナップショットとして残して決め直す。決め直したら取りこぼしへ戻り、この輪が回り続けることが「前に進め続ける」の中身。
宿題
模擬衛星の初回打ち上げに必要な機能を考える
お題は Week 6 と同じで、今日はどう進めるか（依存と計画）
4
宿題や今後の作業期間で必要なスタンス
4.1 AIとの協働モデル
「毎回チェック」は量で破綻し、「全部信じる」は判断の明け渡し。審査の根拠は設計されていない。
人間が要求と契約（テスト・インターフェース）を固め、内側を委任する。人間の役割は「広げたか、何で確かめたか」を説明できること。
4.2 ダブルダイヤモンド
この形を1周で終えず繰り返す。作業期間の計画づくりが、このループの設計をAIと対等に分担する最初の実践になる。
付録 出典