このユニットの結論
大規模システム開発では、最初から細かい技術を覚えるより先に、「誰が、何のために、どの業務・システム・データを、どの期間で変えるのか」をつかむことが重要です。
アステリア刷新プロジェクトは、1つのアプリを作る話ではありません。
業務、要件、設計、プログラム、データ、他システム、テスト、運用がつながった大きな変革プロジェクトです。
1. 何の話か
この教材では、架空企業「アステリア株式会社」の大規模基幹システム刷新を追いながら学びます。
アステリア株式会社は、
- ITコンサルティング・システム開発企業
- 売上高 約5,000億円
- 従業員 約4,000名
という設定です。
今回の刷新プロジェクトでは、
- 約120人が参加
- 約1,500件の要件
- 約36本のシステム連携
- 10年分のデータ移行
- 複数ベンダーが参加
- AIを活用（活用の範囲は正本に記載なし）
します。
時間軸は、
- M-6 構想開始
- M0 正式キックオフ
- M18 本番稼働
- M21 初期安定化完了
です。
2. なぜ最初に全体像が必要なのか
大規模プロジェクトでは、自分の担当だけ見ていると判断を誤ります。
たとえば「請求処理を変える」という要件でも、
- 業務手順
- 要件
- 画面
- データ
- 会計連携
- 権限
- テスト
- 運用
へ影響する可能性があります。
大規模開発では、
1つの変更がどこまでつながるか
を見る必要があります。
3. プロジェクトはつながっている
この教材では、次の連鎖を何度も使います。
- 業務
- 要件
- 設計
- プログラム
- データ
- 他システム
- テスト
- 運用
たとえば業務ルールが変われば、要件が変わり、設計が変わり、コードが変わり、テストも変わるかもしれません。
その変更が外部システムへデータを渡す処理なら、相手システムとの調整も必要です。
4. THINK — 「自分の担当だけ終わればよい」？
あなたはデータ移行担当です。
自分の移行プログラムは正常に動き、予定件数のデータを新システムへ投入できました。
しかし、新システム側の業務担当は、「一部のデータが、業務の画面でそのままでは使えない」と指摘しています。
問題
移行プログラムが正常終了したので、データ移行は完了と判断してよいでしょうか。
判断例を開く
判断
まだ完了とは言えません。
確認すべきなのは、
- 件数
- 値
- データの意味
- 業務で利用可能か
- 後続システムが正しく解釈できるか
です。
プログラムが動いたことと、プロジェクトとして正しい状態になったことは別です。
5. 120人は同じものを見て仕事をする
約120人が口頭だけで判断を共有することはできません。
そこで、
- 要件
- 設計
- 課題
- テスト結果
- 移行計画
- 障害記録
- 本番切替計画
などの成果物を使います。
成果物の目的は、文書を増やすことではありません。
多くの人が同じ事実を見て判断できる状態を作ることです。
このプロジェクトでは70種類のプロジェクト成果物を扱い、そのうち29種類を重点成果物として扱います。（成果物一覧）
6. システムだけでなくデータを見る
画面が正常でも、データが正しいとは限りません。
また、自システムが正常でも、連携先が止まっていれば業務は完了しないことがあります。
そのため、
- 画面
- 処理
- データ
- 連携
- 業務結果
まで見ます。
この考え方は、後のデータ移行、システム連携、本番障害のユニットにつながります。
7. AI WORKFLOW — AIはどこで使えるか
AIは大規模プロジェクトで、
- 文書の整理
- 要件の重複候補抽出
- 設計レビュー
- コード生成
- テスト生成
- ログ分析
- 差分確認
- リスク候補抽出
などに利用できます。
ただし、
AIが速く作業できることと、AIの判断が正しいことは別です。
たとえば「2ファイルだけ変更する予定」だった作業で、AIが17ファイルを変更したとします。
テストが全部PASSしていても、
「なぜ17ファイル必要だったのか」
は確認しなければなりません。
8. REVIEW — AIの仕事を何で確認するか
AIをレビューするときは、
- 指示した範囲を超えていないか
- 正本にない設定を作っていないか
- 変更理由を説明できるか
- テストが本当に重要な失敗を検出できるか
- データや本番環境へ不要な影響がないか
を確認します。
「AIが成功と言った」「テストがPASSした」
だけでは完了にしません。
ADVANCED深掘り — 実務者向けに一段深く
深掘り — 「完了」を段階ごとに定義する
完了は 1 つではない
このユニットの演習は、「自分の作業が終わった」と「プロジェクトとして完了した」の区別でした。実務では、この区別を言葉で決めておきます。世界で共有されている考え方では「完了の定義（Definition of Done）」と呼ばれます。作業の種類ごとに「何がそろえば完了と言うか」を一覧にし、全員が同じ一覧を使います。
段階ごとに条件を重ねる
完了の定義は、段階ごとに重ねます（教材上の例）。
- 開発の完了：コードがあり、レビューを通り、担当のテストが通っている
- 機能の完了：関係する要件がすべて確かめられ、他システムとの受け渡しが確かめられている
- 移行の完了：件数・値・意味が確かめられ、業務の担当が画面で使えることを確かめている
- 稼働に向けた完了：運用の手順と引き継ぎが終わり、未解決の課題に扱いが決まっている
下の段階が終わっても、上の段階は終わっていません。報告では、どの段階の完了かを添えます。
「完了」が戻った回数を数える
完了と報告されたあとで、やり直しになった件数を数えます。この数が多い作業の種類は、完了の定義があいまいか、確かめる人が足りていない印です。数えるだけで、報告の言葉が変わります。
定義は実際の問題から育てる
完了の定義は、最初から正しくは書けません。やり直しが起きたとき、「どの条件があれば防げたか」を一覧に足します。ただし、条件が増えすぎると誰も守らなくなるため、実際に起きた問題から足すことを原則にします。
現場で確かめる問い
- 「完了」の意味が、作業の種類ごとに言葉で決まっているか。決まっていないなら、誰がどう判断しているか
- 報告の「終わりました」に、どの段階の完了かが添えられているか
- 完了と報告されたあとで戻った件数を、作業の種類ごとに数えたことがあるか
- 完了の定義を最後に見直したのはいつか。実際のやり直しから足した条件はあるか
アステリア案件で完了の定義がどう決められ、どの段階で使われたかは、正本に記録がありません。記録なし
9. 人間が判断すること
最終的に人間が決めるものがあります。
たとえば、
- どこまでを今回の対象にするか
- どのリスクを許容するか
- どの要件を優先するか
- 本番へ進めるか
- 障害時に止めるか続けるか
です。
AIは判断材料を作れますが、プロジェクトの責任そのものを引き受けるわけではありません。
10. 判断演習
あるチームから、
「担当機能の開発とテストは終わりました。完了でよいですか？」
と報告がありました。
あなたなら、
- 関係する要件
- 関係する他システム
- データ
- テスト結果
- 未解決課題
- 運用への引継ぎ
のどこを確認するでしょうか。
「自分の作業が終わった」と「プロジェクトとして完了した」を区別してください。
あなたの記録あなたの考え。事実ではありません
判断ノート
このユニットで覚えてほしいこと
大規模システム開発では、
部分ではなく、つながりを見る。
これが最初の基本です。
アステリア案件では、これから、要件、設計、連携、AI、テスト、移行、本番障害までを、1つのプロジェクトの中で追っていきます。