これは何か
システム投資企画書は、「なぜ今、このシステムにお金と人をかけるのか」を、承認する人に説明し、判断してもらうための成果物です。
「システムが古いから新しくしたい」だけでは、投資の理由になりません。何を実現したいのか、どこまでを対象にするのか、費用はいくらで、効果をどう確かめるのかを、1つの文書で示します。
なぜ作るか
- 承認する人(経営層)が、投資するかしないかを判断できるようにする
- プロジェクトが途中で迷ったとき、「そもそも何のためだったか」に立ち返る基準になる
- 稼働したあとに、狙った効果が出たかを確かめる出発点になる
誰が使うか・いつ作るか
- 作る人:投資を提案する部門と、IT 部門。一般的には、事業側の責任者が中心になります
- 読む人・判断する人:投資を承認する経営層、プロジェクトの責任者(スポンサー)
- 一般的には、プロジェクトの構想の段階で作り、承認を得てから、提案依頼(RFP)や体制づくりへ進みます
- アステリア案件で、この企画書を誰が作り、誰がいつ承認したかは、正本に記載がありません。未確定
CASE FACTFROZEN正本に記載されたアステリア案件の事実
企画の前提になる記載
- アステリア株式会社:架空企業。業種は IT コンサルティング・システム開発
- 売上高 約5,000億円、従業員 約4,000名
- 大規模基幹システム刷新、約120人規模のプロジェクト
- 約1,500件の要件、約36本のシステム連携、10年分のデータ移行
- マルチベンダー、AI活用あり
- M-6 構想開始、M0 正式キックオフ、M18 本番稼働、M21 初期安定化完了
- P-001 佐伯 隆志 — CFO/プロジェクトスポンサー
- 投資承認は、AIへ最終委任しない事項の1つ
アステリア案件の投資額、期待する効果とその金額、回収の期間、効果を測る指標、承認の日付と承認した会議体は、正本に記載がありません。未確定 STAGE 01 の題名「なぜ数十億円を使うのか」は学習の問いの表現であり、承認された投資額の記載ではありません。
主な項目
一般的には、次の項目で構成します。
- 背景と課題:今の業務とシステムで、何に困っているか
- 目的:投資で何を実現するか(「新しくする」ではなく、実現したい状態)
- 対象範囲:今回の対象にするもの、しないもの(01-05)
- 実現の方針:どのように作るか(自社か外部か、段階的に進めるかなど)
- 費用:開発費だけでなく、運用・保守・利用料・移行・教育などを含めた総額(01-04)
- 効果:何がどれだけ良くなるか。金額にできるものと、できないもの(01-03)
- 効果の測り方:どの指標で、いつ確かめるか
- リスク:うまくいかない場合に何が起きるか。やらない場合に何が起きるか
- 体制とスケジュールの大枠:責任者、大きな節目
- 判断してほしいこと:承認者に何を決めてほしいか
教材用サンプル成果物の読み方を学ぶための例
教材用サンプル — 目的・効果・測り方の書き方
この成果物は学習用サンプルです。FROZEN正本に記載されたCASE FACTと、成果物の読み方を学ぶための教材用サンプル値を区別して表示しています。
次の表は、目的と効果を「確かめられる形」で書く例です。値はすべて教材上の架空の例で、アステリア案件の目的・効果ではありません。
| 目的(実現したい状態) | 効果の例 | 測り方の例 | 金額にできるか |
|---|---|---|---|
| 案件ごとの採算を、月の途中でも見られる | 採算の悪い案件に早く手を打てる | 採算を確認できるまでの日数(導入前と比べる) | 一部できる |
| 同じデータを何度も手で入力しない | 入力の手間と入力ミスが減る | 手入力の件数、入力ミスによる修正の件数 | できる |
| 古い仕組みの保守の不安をなくす | 保守を続けられない危険が減る | 保守の期限、障害の件数 | しにくい |
| 費用の区分 | 含めるものの例 | 抜けやすさ |
|---|---|---|
| 開発・導入 | 設計・開発・テスト、ベンダーへの支払い | 抜けにくい |
| 移行 | データ移行、切替の作業、リハーサル | 抜けやすい |
| 運用・保守 | 稼働後の保守、監視、問い合わせ対応 | 抜けやすい |
| 利用料 | クラウドや SaaS(インターネット経由で借りて使うソフトウェア)の利用料(毎年かかる) | 抜けやすい |
| 社内の人 | 利用部門の確認・テスト・教育にかかる時間 | 最も抜けやすい |
表の区分・例は構造を学ぶためのものです。アステリア案件の費用の内訳ではありません。
読み方
- まず「目的」を読み、それが「新しくすること」ではなく「実現したい状態」になっているかを見る
- 目的ごとに、効果と測り方が対応しているか
- 費用が、開発費だけになっていないか。毎年かかる費用が入っているか
- 対象範囲に「今回は対象にしないもの」が書かれているか
- 「やらない場合」のリスクが書かれているか
- 承認者に何を判断してほしいかが、はっきりしているか
書き方
- 困りごとを、業務の場面で書く(「システムが古い」ではなく「月の途中で採算が分からない」)
- 困りごとから、実現したい状態(目的)を書く
- 目的ごとに、効果と、その測り方を書く。金額にできない効果は、できないと書いたうえで、どう確かめるかを書く
- 費用を、開発・移行・運用・利用料・社内の人に分けて見積もる
- 対象範囲と、対象にしないものを書く
- リスクと、判断してほしいことを書く
何を書いてはいけないか
- 根拠のない効果の金額(「年間○億円の削減」だけで、計算の根拠がない)
- 目的のない機能の一覧
- 開発費だけの費用
- 「最新の技術を使う」ことを目的にすること
どこを見るか
- 目的・効果・測り方が1本の線でつながっているか
- 費用に、稼働後に毎年かかるものが入っているか
- 対象範囲の外にあるものが書かれているか
- 誰が承認し、承認後に誰が責任を持つか(スポンサー)が書かれているか
- 効果を、稼働後のいつ、誰が確かめるかが書かれているか
赤信号
- 目的が「システムの刷新」だけ
- 効果が「業務効率化」「DX推進(デジタル技術で業務を変えること)」などの言葉だけで、測り方がない
- 費用が開発費だけ
- 対象範囲が「全業務」
- 承認後に効果を確かめる人と時期が決まっていない
よくある失敗
- 承認を得ることが目的になり、効果を大きく、費用を小さく書く
- 承認後に企画書を読み返さず、プロジェクトの途中で目的を見失う
- 稼働後に効果を確かめず、投資が良かったのか分からないまま終わる
関係するUnit・成果物・危機演習
- Unit:01-05 どこまでを今回の対象にするか、01-02 システム投資で何を実現するのか、01-03 投資対効果をどう考えるか、01-04 システムの費用は開発費だけではない
- 成果物:PRG-001 プロジェクト憲章、BUS-005 提案依頼書(RFP)、BUS-003 プロジェクト対象範囲定義書、BUS-004 効果測定指標一覧
- 危機演習:この成果物を直接の題材にする危機演習はありません。企画の段階で決めた目的と対象範囲は、その後のすべての工程の判断の土台になります
AI WORKFLOW
AIは、企画書の抜けや、目的と効果のつながりの弱さを探す下書きに役立ちます。
「この企画書の目的ごとに、①対応する効果、②効果の測り方、が書かれているかを表にしてください。書かれていないものは空欄にし、効果の金額や測り方を補わないでください。」
REVIEW
- AIが効果の金額や数値を補っていないか
- 表が、企画書の元の文と合っているか
- 「投資すべき」「投資効果が高い」などの判断を AI がしていないか
人間が判断すること
- 投資するか、しないか
- 目的の優先順位と、対象範囲
- 金額にできない効果を、どう評価するか
投資承認は、AIへ最終委任しない事項です(正本の方針)。
いつ使うか
この教材では STAGE 01|なぜ数十億円を使うのか の文脈で扱います。 アステリア案件での正式な作成・使用時期(月)は正本に記載がないため、未確定としています。
最後の問い
この企画書を読んだ承認者は、「何のために、いくらかけ、何をもって成功とするか」を説明できますか?