このユニットの結論
システムを1つにまとめるか、いくつかに分けるかに、どちらが常に正しいという答えはありません。
まとめると「つなぐ手間」が減る代わりに「変える・直すときの影響」が大きくなり、分けると「影響」を小さくできる代わりに「つなぐ手間と、つなぎ目の責任」が増える。この取り引きを、業務・組織・会社の分担に照らして判断し、理由を記録します。
1. 何の話か
このユニットは、システムの分け方の話です。
大規模な基幹システムの刷新では、「全部を1つの大きなシステムで作る」か、「会計・勤怠・営業などを別々のシステムにして、つなぐ」かを決める必要があります。この判断は、あとから変えるのが難しく、プロジェクトの体制や費用、連携の数にも大きく影響します。
2. なぜ必要か
分け方を深く考えずに決めると、
- 1つにまとめすぎて、一部を直すだけでも全体のテストが必要になり、変更が遅くなる
- 分けすぎて、連携の数が増え、つなぎ目の問題が増える
- 分け方と会社（ベンダー）の担当範囲が合わず、担当の範囲を決め直す手間が増える
- なぜこの分け方にしたのかが残らず、あとから誰も説明できない
ということが起きます。
3. このユニットで分かること
- まとめる場合と分ける場合の、それぞれの長所・短所
- 分け方を決めるときの観点
- 分け方の判断で、AIに任せてよいことと人間が決めること
4. まとめる場合と分ける場合
| 1つにまとめる | いくつかに分ける | |
|---|---|---|
| データ | 1か所にあり、そろえやすい | システムごとにあり、データの正本（どこを正とするか）を決める必要がある |
| つなぐ手間 | 少ない | 連携を作り、管理する必要がある |
| 変える・直すとき | 影響が全体に広がりやすい | 影響をそのシステムの中に抑えやすい |
| 作る体制 | 1つのチーム・1社に集まりやすい | システムごとに、別のチーム・別の会社が担当できる |
| 既製品の活用 | 作り込みが多くなりやすい | 分野ごとに既製品やクラウドのサービス（SaaS）を使いやすい |
どちらにも長所と短所があります。分けるなら、つなぎ目（連携）と、つなぎ目の責任を、同じくらい大事に設計する必要があります（05-04・05-06）。
5. 分け方を決める観点
一般的には、次の観点で考えます。
- 業務のまとまり：いつも一緒に変わる業務は、同じシステムにまとめる
- 変わる速さ：よく変わる部分と、あまり変わらない部分を分ける
- データの正本：どのデータを、どのシステムで正とするか（05-02）
- 既製品・サービスの活用：分野の既製品で済む部分を切り出せるか
- 会社・チームの分担：分け方と担当の範囲が合っているか
- つなぐ費用：分けることで増える連携を、作り、管理できるか
CASE FACTFROZEN正本に記載されたアステリア案件の事実
アステリア案件の構成
- システムは 11：SYS-01 新基幹システム、SYS-02 財務会計システム FIN-CORE、SYS-03 勤怠・工数管理SaaS、SYS-04 営業管理システム、SYS-05 人事マスターシステム、SYS-06 システム連携基盤、SYS-07 BI基盤、SYS-08 認証・ID基盤、SYS-09 開発・CI/CD基盤、SYS-10 AI開発エージェント、SYS-11 監視・ログ基盤
- 約36本のシステム連携（正本で個別に定義されているのは IF-01〜IF-12）
- Vendor 4社が、それぞれの担当範囲を持つ（Vendor A 新基幹アプリケーション、Vendor B クラウド基盤・連携・監視など、Vendor C FIN-CORE・会計連携、Vendor D 勤怠・工数管理SaaS）
アステリア案件では、システムは分けられています。しかし、なぜこの分け方にしたのか（判断の理由）は、正本に記載がありません。未確定 この教材では、分け方の理由を推測しません。構成図は ARC-001 システム全体構成図 で見られます。
6. THINK — 「全部を1つにすれば、連携はいらない」
（教材上の例）構想の会議で、次の意見が出ました。
「連携があると、つなぎ目で問題が起きます。会計も勤怠も営業も、全部を1つの大きなシステムにまとめれば、連携はいらなくなります。」
問題
この意見のとおり、全部を1つにまとめると決めてよいでしょうか。
判断例を開く
判断
連携が減るという長所だけで決めることはできません。
確認すること:
- 1つにまとめると、一部を変えるときの影響とテストの範囲は、どれだけ大きくなるか
- 勤怠や会計など、既製品やサービスで済む分野まで作り込むことになるか。その費用は
- 1つのシステムを、1つのチーム・1社で作れる規模か
- 他の会社のシステム（取引先など）との連携は、どちらにしても残るのではないか
連携の問題は、分けたことそのものより、つなぎ目の設計が足りないときに起きやすいものです。
7. よくある失敗
- 分け方を、今のシステムの分け方のまま決める（業務の変化を考えない）
- 分け方と、会社の担当範囲を別々に決め、境目が合わない
- 分けたのに、データの正本を決めず、同じデータが複数の場所で食い違う
- 分け方の理由を記録しない
8. 成果物との接続
- ARC-001 システム全体構成図：分けた結果の全体像
- ARC-006 設計判断記録：分け方を決めた理由と、比べた案
- ARC-004 システム連携一覧：分けたことで生まれる連携
- ARC-003 システム責任分担表：分けたシステムごとの担当
設計の判断を記録する理由は 05-05 設計判断をなぜ記録するのか で学びます。
9. AI WORKFLOW — 案ごとの長所・短所を整理させる
AIは、分け方の案を比べる材料の下書きに役立ちます。
指示例:
「次の業務の一覧と、分け方の2つの案について、案ごとに①必要になる連携、②変更のときに影響が広がる範囲、③担当の会社・チームの分け方、を表にしてください。どちらの案がよいかは判断しないでください。」
10. REVIEW — AIの整理を確認する
- 表の連携が、業務の一覧から本当に導けるか
- AIが、一般論で「分けるのが最近の主流」のような判断を混ぜていないか
- 自社の業務・組織の事情を、人が加えて検討したか
11. 人間が判断すること
- システムをどう分けるか（または、まとめるか）
- 分け方と、会社・チームの担当範囲
- 判断の理由を記録し、承認すること
設計承認は、AIへ最終委任しない事項です（正本の方針）。
12. 判断演習
あなたは、システムの分け方を検討する担当です。
「勤怠の管理を、既製のサービスで行う」という案について、長所を2つ、短所（または確かめること）を2つ挙げてください。
あなたの記録あなたの考え。事実ではありません
判断ノート
このユニットで覚えてほしいこと
まとめるか分けるかは、つなぐ手間と、変えるときの影響の取り引きです。
分けるなら、つなぎ目とその責任を同じくらい大事に設計し、判断の理由を記録します。