このユニットの結論
システムの作り方には、自社で作る、外部の会社に作ってもらう、できあがったサービスを借りて使う、などの選択肢があります。大規模な刷新では、これらを組み合わせるのが一般的です。
ただし、どの方法を選んでも、目的を決めること、要件を確定すること、できたものを受け入れるかを判断することは、発注する側に残ります。外に出せるのは作業であって、責任ではありません。
1. 何の話か
このユニットは、誰に作ってもらうかの最初の判断の話です。
投資の目的と対象範囲が見えてきたら（STAGE 01）、次は「それを誰が作るのか」を決めます。社内の人で作るのか、外部の会社（ベンダー）に頼むのか、すでにあるサービスを使うのか。この判断によって、その後の提案依頼（02-02）や契約（02-05）の進め方が変わります。
2. なぜ必要か
作り方を深く考えずに決めると、一般的に次のことが起きます。
- 社内に人がいないのに自社で作ろうとして、進まない
- 外部に任せきりにして、社内に仕組みを分かる人がいなくなる
- 借りて使うサービスに合わせられない業務を、あとから無理に作り足す
- 複数の会社に分けて頼んだのに、会社と会社の境目を誰も管理しない
3. このユニットで分かること
- 作り方の主な選択肢と、それぞれの向き・不向き
- どの方法でも発注する側に残る役割
- 作り方の検討で、AIに任せてよいことと人間が決めること
4. 作り方の主な選択肢
| 選択肢 | どういうものか | 向いている場合（一般的に） | 気をつけること |
|---|---|---|---|
| 自社で作る（内製） | 社内の人が設計・開発する | 業務の強みに直結し、頻繁に変えたい部分 | 必要な人数と技術を社内でそろえられるか |
| 外部に作ってもらう（外部委託） | ベンダーに、設計・開発を頼む | 規模が大きく、社内の人だけでは足りない部分 | 任せきりにしないこと。社内に分かる人を残すこと |
| できあがったものを使う（パッケージ・サービスの利用） | 市販のソフトウェアや、インターネット経由で借りて使うサービス（SaaS）を使う | 多くの会社で業務のやり方がほぼ同じ部分 | 業務をサービスに合わせられるか。データの置き場所と、やめるときの扱い |
実際には、1つの方法に決めるのではなく、「この部分は借りて使う、この部分は外部に作ってもらう、この部分は社内で持つ」のように、部分ごとに選ぶことが多くなります。部分ごとに別の会社に頼む形を、マルチベンダーと呼びます。
5. どの方法でも発注する側に残ること
外部に頼んでも、次のことは発注する側（システムを使う会社）が持ち続けます。
- 何のために作るのか（目的）を決める
- 何を作るのか（要件）を確定する
- できたものが要件を満たしているかを確かめ、受け入れるかを決める
- 複数の会社に頼むなら、会社と会社の境目を管理する（05-06）
- 稼働したあと、システムをどう使い続けるかを決める
そのため、外部に頼む場合でも、社内には発注と管理ができる人が必要です。社内に誰もいないと、ベンダーの説明が正しいかを確かめられません。
CASE FACTFROZEN正本に記載されたアステリア案件の事実
アステリア案件の作り方に関係する記載
- アステリア株式会社の業種：ITコンサルティング・システム開発
- マルチベンダー。Vendor は4社
- Vendor A / ネクサスシステムズ — 新基幹アプリケーション
- Vendor B / クラウドブリッジ — クラウド基盤、ネットワーク、IAM、連携、CI/CD、監視
- Vendor C / ファイナンスシステムサービス — FIN-CORE、会計連携
- Vendor D / タイムリンク — 勤怠・工数管理SaaS
- アステリア側に、プログラムマネージャー（P-003）、システムアーキテクト（P-008）などの役割の人物がいる
正本から読み取れるのは、Vendor ごとに担当の範囲が記載されたマルチベンダーの形だということです。すべてのシステムについて担当の Vendor が正本に書かれているわけではありません。未確定 なぜ外部に委託したのか、どの部分を自社で持つことにしたのか、社内の人がどの作業を担当するのかは、正本に記載がありません。未確定 アステリア自身の業種がシステム開発であることと、委託を選んだ理由との関係も、正本には書かれていません。未確定
6. THINK — 「全部お任せします」
（教材上の例）ある会社の刷新の構想で、責任者が次のように言いました。
「社内には開発の経験者が少ないので、要件をまとめるところから稼働まで、全部を外部の会社にお任せしましょう。」
問題
この進め方で、発注する側としての役割を果たせるでしょうか。
判断例を開く
判断
作業を外部に頼むこと自体は、選択肢の1つです。ただし、「全部お任せ」では発注する側の役割が抜けます。
確認すること:
- 要件を確定し、できたものを受け入れるかを判断する人は、社内の誰か
- ベンダーの説明や見積もりを確かめられる人が、社内にいるか
- 稼働したあと、仕組みを分かる人が社内に残るか
- 社内に足りない役割を、どう補うか（社内の人を育てる、発注する側を支える別の専門家を頼む など）
作業は頼めても、判断と責任は発注する側に残ります。
7. よくある失敗
- 作り方を、費用だけで決める
- 外部に任せきりにし、社内に分かる人がいなくなる
- サービスを借りて使うのに、業務をサービスに合わせる準備をしない
- 部分ごとに別の会社に頼んだのに、会社と会社の境目の担当を決めない
- 稼働後の保守を誰が持つかを、作り方を決めるときに考えない
8. 成果物との接続
- BUS-005 提案依頼書（RFP）：外部に頼む部分について、何を提案してほしいかを伝える
- ARC-003 システム責任分担表：どのシステムを、どの会社・役割が担当するかを示す
- PRG-004 役割・責任分担表：発注する側に残る判断を、誰が持つかを示す
9. AI WORKFLOW — 選択肢の比較の観点を並べさせる
AIは、作り方の選択肢を比べるための観点を整理する下書きに役立ちます。
指示例:
「次の業務の一覧について、業務ごとに『自社で作る・外部に作ってもらう・サービスを使う』を比べるための確認の質問を挙げてください（業務の独自さ、変える頻度、社内の人と技術、データの扱い、稼働後の保守）。どの方法がよいかは判断しないでください。」
10. REVIEW — AIの整理を確認する
- 質問が、実際の業務の内容に合っているか
- AIが、特定の方法や特定の製品を推していないか
- 社内の人の数や技術について、AIが推測で書いていないか
ADVANCED深掘り — 実務者向けに一段深く
深掘り — 作るか頼むかの判断軸と、抜け出す費用
判断軸を先に決める
作るか、頼むか、借りるか。世界で共有されている考え方では「メイク・オア・バイ」の判断と呼ばれ、感覚ではなく軸で決めます。一般的な軸は 4 つです。
- 差別化：その業務が、会社の強みと直結しているか。直結するなら、自分たちで変えられる形を残す
- 変える頻度：年に何度も変えるなら、変えるたびに外に頼むのは遅い
- 社内の能力：作る人・運用する人が今いるか、育てられるか
- 情報の扱い：データをどこに置けるか、外に出せない情報があるか
業務ごとにこの 4 つを採点し、採点の理由を残します。
抜け出す費用を先に見る
借りて使うサービスや、特定のベンダーに深く頼る形は、始めるのは楽でも、やめるのが難しくなります。これを「ロックイン」と呼びます。契約のときに、やめるときのこと（データを取り出せる形、取り出しの費用、引き継ぎの期間）を決めておきます。やめる費用が見積もれない選択肢は、本当の費用が分かっていない選択肢です。
発注する側に残す能力を数える
外に頼んでも、要件を決め、受け入れを判断し、ベンダーの説明を確かめる人は社内に要ります。この人数と役割を、作り方を決める段階で数えます。足りないなら、育てる計画か、発注する側を支える別の専門家を頼む計画を、同時に立てます。
測り方の例
- 業務ごとの判断軸の採点と、採点した人
- 選択肢ごとの「やめる費用」の見積もりの有無
- 発注する側に必要な役割の数と、埋まっている数
現場で確かめる問い
- 作り方は、業務ごとに判断軸で決めたか。それとも費用だけで決めたか
- 借りて使うサービスについて、やめるときのデータの取り出しと費用を確かめたか
- 発注する側に残す役割を数えたか。埋まっていない役割はどれか
- 深く頼っているベンダーについて、交渉の余地が残る形になっているか
アステリア案件で作り方をどの軸で決め、やめる費用をどう見たかは、正本に記録がありません。記録なし
11. 人間が判断すること
- どの部分を自社で持ち、どの部分を外部に頼み、どの部分でサービスを使うか
- 発注する側の役割を、社内の誰が担うか
- 外部に頼んだ部分の知識を、社内にどう残すか
12. 判断演習
あなたは、刷新の構想をまとめる担当です。
外部の会社に開発を頼むことが決まりました。発注する側として社内に残すべき役割を3つ挙げ、それぞれを担う人に必要な知識を書いてください。
あなたの記録あなたの考え。事実ではありません
判断ノート
このユニットで覚えてほしいこと
作り方は、部分ごとに選び、組み合わせるのが一般的です。
どの方法を選んでも、目的・要件の確定・受け入れの判断は発注する側に残ります。外に出せるのは作業であって、責任ではありません。