このユニットの結論
大規模システム開発の難しさは、「作るものが大きい」ことだけではありません。
関わる人・会社・システム・データが多く、期間が長いため、「つなぎ目」と「決めること」が爆発的に増えることにあります。だから、技術と同じくらい、決め方・伝え方・確かめ方が大切になります。
1. 何の話か
このユニットは、この教材全体の入口です。大規模システム開発とは何かを考えます。
会社の中で、数人で小さな業務のアプリを作ることもあれば、数百人が何年もかけて会社の中心の仕組み（基幹システム）を作り直すこともあります。どちらも「システム開発」ですが、後者には、前者にはない難しさがあります。
2. なぜ必要か
小さな開発の感覚のまま大きな開発に臨むと、
- 「話せば分かる」人数を超えているのに、口頭で決めて、決めたことが伝わらない
- 自分の担当が終われば全体も終わると考え、つなぎ目の問題に最後まで気づかない
- 途中で要件や担当が変わることを想定せず、変わったときに混乱する
ということが起きます。
3. このユニットで分かること
- 大規模システム開発で、何が「大きい」のか
- 規模が大きくなると、何が難しくなるのか
- この教材で学ぶことの全体像
4. 何が「大きい」のか
| 大きさ | 小さな開発（一般的な例） | 大規模な開発（一般的な例） |
|---|---|---|
| 人 | 数人。全員が顔を合わせて話せる | 数十〜数百人。全員が互いを知らない |
| 会社 | 1社、または社内だけ | 複数の会社（ベンダー）が分担する |
| 要件 | 数十件。担当者が覚えていられる | 数百〜数千件。一覧と番号で管理する |
| システム | 1つ | 複数のシステムが、データをやりとりしてつながる |
| データ | 新しく作る | 古いシステムから長年のデータを移す |
| 期間 | 数週間〜数か月 | 1年以上。途中で人も要件も変わる |
5. 規模が大きくなると何が難しくなるか
- つなぎ目が増える：人と人、会社と会社、システムとシステムの間に、誰の担当か分かりにくい部分が増える
- 決めることが増える：毎日たくさんの判断が必要になり、誰が決めるかがあいまいだと、判断が止まる
- 伝えることが難しくなる：決めたことを、影響を受ける全員に届ける必要がある
- 確かめることが増える：部品が正しくても、全体として正しく動くかを、段階を追って確かめる必要がある
- やり直しが高くつく：あとの工程で見つかった問題ほど、直すのに手間と時間がかかる
この教材の多くのユニットは、この5つのどれかに対する答え方を学ぶものです。
CASE FACTFROZEN正本に記載されたアステリア案件の事実
この教材で追いかけるプロジェクトの規模
- アステリア株式会社（架空企業）の大規模基幹システム刷新
- 約120人規模のプロジェクト
- 約1,500件の要件、約36本のシステム連携、10年分のデータ移行
- マルチベンダー（Vendor 4社）、システム 11
- AI活用あり
- M-6 構想開始、M0 正式キックオフ、M18 本番稼働、M21 初期安定化完了
この教材は、15の STAGE で、構想から稼働後までを順に学びます。アステリア案件の詳しい紹介は 00-02 アステリア刷新プロジェクトを知る にあります。
6. THINK — 「優秀な人を集めれば大丈夫」
プロジェクトを始めるにあたり、ある役員が次のように言いました。
「優秀なエンジニアを集めれば、大きなシステムでも問題なく作れるはずだ。」
問題
この考えだけで、大規模なプロジェクトを始めてよいでしょうか。
判断例を開く
判断
優秀な人は大切ですが、それだけでは足りません。
確認すること:
- 誰が何を決めるか、決まっているか
- 決めたことを、全員に正しく伝える仕組みがあるか
- 会社・システムのつなぎ目を、誰が担当するか決まっているか
- 途中で要件が変わったときの手続きがあるか
- 全体として正しく動くことを、どう確かめるか
大規模な開発の失敗の多くは、個人の技術ではなく、つなぎ目と決め方で起きます。
7. よくある失敗
- 小さな開発と同じ進め方（口頭の合意、担当者の記憶）で進める
- 各担当が自分の部分だけを見て、全体を見る人がいない
- 最初の計画どおりに進むことを前提にして、変化への備えをしない
- 文書を作ること自体が目的になり、判断に使われない
8. 成果物との接続
- PRG-001 プロジェクト憲章：プロジェクトの目的・範囲・責任者を、全員の出発点としてまとめる
- ARC-001 システム全体構成図：複数のシステムとそのつながりを、1枚で示す
この教材では、70種類のプロジェクト成果物を扱います（成果物一覧）。
9. AI WORKFLOW — AIを「速い作業者」として使う
大規模な開発では、AIは文書の整理、抜けや食い違いの候補探し、下書き作りなどに役立ちます。
指示例:
「次の会議のメモから、①決まったこと、②決まっていないこと、③誰かが確かめると言ったこと、を分けて一覧にしてください。決まっていないことを、決まったことのように書かないでください。」
10. REVIEW — AIの整理を確認する
- AIの一覧が、元のメモと合っているか
- 「決まったこと」とされたものが、本当に決まったことか
- 担当と期限が抜けていないか
ADVANCED深掘り — 実務者向けに一段深く
深掘り — つなぎ目の数を数える
つなぎ目は数えられる
「つなぎ目が増える」は感覚ではなく、数で見られます。システムとシステムの間でデータを受け渡す連携の本数、会社と会社の分担の境目の数、部門と部門の間で受け渡す業務の数です。アステリア案件では、連携が約36本あることが正本に書かれています。1 本の連携には、送る側・受ける側・データの形・時刻・失敗したときの扱いの取り決めが要るため、連携の本数は、決めることの数の目安になります。
組織の形がシステムの形に映る
世界で共有されている考え方に「コンウェイの法則」があります。システムの構造は、それを作る組織の話し合いの構造に似る、というものです。会社ごとに分担して作れば、会社の境目がそのままシステムの境目になります。一致している箇所は責任がはっきりします。一致していない箇所（1 つのシステムを 2 社で作る、1 社が複数のシステムにまたがる）が、つなぎ目の問題が起きやすい場所です。
直す費用は工程が進むほど増える
あとの工程で見つかった問題ほど直すのに手間がかかる、という経験則は、要件の段階で直せば 1 の手間が、設計・実装・テスト・稼働後と進むにつれて何倍にも増える、という形で語られます。倍率は現場で違うので、「早く見つけるほど安い」という向きを使い、早く見つける仕組み（レビュー、つなぎ目の早い確認）に時間をかける根拠にします。
測り方の例
- 連携の本数と、取り決めが文書になっている本数
- 組織の境目とシステムの境目が一致していない箇所の数
- 問題が見つかった工程ごとの件数
現場で確かめる問い
- つなぎ目（連携・会社の境目・部門の境目）を数えたことがあるか。数えると何本になるか
- 1 つのシステムを複数の会社で作っている箇所、1 社が複数のシステムにまたがる箇所はどこか
- 問題が見つかった工程を記録しているか。あとの工程で見つかる割合が増えていないか
- 早く見つける仕組みに、どれだけの時間を割いているか
アステリア案件で、組織の境目とシステムの境目がどう対応していたか、問題がどの工程で見つかったかは、正本に記録がありません。記録なし
11. 人間が判断すること
- プロジェクトの目的と範囲
- 誰が何を決めるか
- 決めたことを確定し、全員に伝えるか
この教材では、投資承認・要件確定・設計承認・本番移行承認・Go / No-Go・重大障害判断などを、AIへ最終委任しない事項として扱います（正本の方針）。
12. 判断演習
あなたが、これまでに関わった仕事（システム開発でなくてもかまいません）を1つ思い出してください。
関わる人が10倍になったら、何が一番困ると思いますか。理由とともに書いてください。
あなたの記録あなたの考え。事実ではありません
判断ノート
このユニットで覚えてほしいこと
大規模システム開発の難しさは、つなぎ目・決めること・伝えること・確かめることが増えることにあります。
この教材では、それぞれへの向き合い方を、アステリア案件を通して学びます。