システム企画とは？構想と計画の2段階で決める範囲、企画書の項目と要件定義への渡し方

システム企画は、要件定義に入る前に「何のために、どの業務を、いくらで、いつまでにシステム化するか」を決め、経営の承認を取る工程です。IPAの共通フレーム2013では、この工程が「システム化構想の立案」と「システム化計画の立案」の2段階に分かれています。本記事では、両者のタスクを発注者の作業に置き換えたうえで、システム化計画書に書く項目、投資回収年数の計算例、企画段階でシステム化を見送る条件、開発会社に任せてよい範囲までを整理します。

まとめ：システム企画は作るかどうかと予算・期限の枠を決め、承認を取って要件定義へ渡す工程

システム企画の成果は2つの承認です。1つめは構想の承認で、経営課題に対して「どの業務をシステム化の対象にし、どれだけの効果を狙うか」を決めます。2つめは計画の承認で、システム方式・概算費用・投資効果・全体スケジュール・推進体制を文書にし、プロジェクトとして予算を確保します。

要件定義はこの2つの承認を前提に始まります。企画が曖昧なまま要件定義に入ると、要件の取捨選択に使う物差しがなく、機能が膨らみます。発注者が手放してはいけないのは、目的・対象範囲・投資目標の3つの決定です。調査や方式案の作成は開発会社に任せられますが、決めるのは発注者です。投資回収年数が自社利用ソフトウェアの償却年数（5年）を超える計画は、範囲を絞るか効果の見積もりをやり直してから承認に回します。

システム企画の意味と、共通フレームで要件定義より前に置かれる構想・計画の位置

「システム企画」は職種名としても使われますが、本記事では工程としての意味を扱います。開発工程の全体像はシステム開発の流れとは？工程の全体像と各フェーズのポイントで解説しており、システム企画はその手前、要件定義の前に置かれる工程です。

共通フレーム2013で企画プロセスが構想7タスクと計画16タスクに分かれる構造

IPAの共通フレーム2013は、システムの構想から廃棄までの作業を発注者と受注者が同じ言葉で話すための枠組みです。IPAが2013年3月に公開した「共通フレーム2013に基づく調達管理ガイド」試作版のWBSを見ると、企画プロセス（2.1）は次の2つで構成されています。

構想は「どこを変えるか」、計画は「どう実現し、いくらかかるか」を決める段階です。構想の承認タスクには「システム化推進体制の確立」が含まれ、計画の承認タスクには「プロジェクト計画の文書化と承認」が含まれます。体制とプロジェクト計画まで決めて初めて、企画が終わったことになります。

要件定義・業務分析との境目と、システム企画で決めない項目の線引き

境目を引くための判断軸は「何を決めるか」です。業務分析は現行業務の問題と真因を特定する作業で、手法は業務分析とは？手法と進め方の5段階で扱っています。システム企画はその結果を受け取り、システム化する対象と投資の枠を決めます。要件定義は、その枠の中で機能や性能を具体的に決める工程です。

企画で決めないのは、画面の項目や帳票の様式、個々の機能の振る舞いです。逆に、運用と廃棄の方針は企画で考えておきます。調達管理ガイドの制約事項には、共通フレーム2013がシステム化計画立案や要件定義の段階で運用や廃棄に関する要件も考慮することを求めている、と書かれています。運用費を企画に入れないと、後で示す回収年数の計算が成り立ちません。

経済産業省のシステム管理基準（令和5年4月26日）は、区切り方が異なります。同基準の「Ⅱ.3 企画プロセス」は、ビジネス分析から業務要件定義・システム要件定義・基本設計・詳細設計、実現可能性及び効果の分析までを含む構成です。社内規程が管理基準に沿っている会社では「企画」の範囲が広くなるため、どの定義で話しているかを最初に確認しておくと、開発会社との認識のずれを防げます。

システム化構想の立案で経営課題から対象業務と投資目標を絞り込む手順

構想段階の7タスクは、IT部門だけでは進められません。経営層と業務部門の判断が要る作業が半分以上を占めます。

構想の7タスクを発注者の作業と成果物に置き換えた進め方の順序

共通フレームのタスク名は抽象的なので、発注者が実際に行う作業に置き換えると次のようになります。

1. 経営上のニーズ・課題の確認：中期経営計画や年度方針から、システムで解く課題を1〜2行で書き出す
2. 事業環境・業務環境の調査分析：法改正、取引先の要求、人員の増減など外部の変化を並べる
3. 現行業務・システムの調査分析：業務棚卸と業務量の数字、現行システムの保守期限や契約更新日を集める
4. 情報技術動向の調査分析：パッケージ、SaaS、クラウドなど実現手段の候補を挙げる
5. 対象となる業務の明確化：システム化する業務としない業務を分ける
6. 業務の新全体像の作成：変更後の業務の流れを1枚の図にする
7. 対象の選定と投資目標の策定：対象業務を確定し、削減時間や売上への寄与を金額と期限で置く

3番目の材料は業務棚卸とは？洗い出しのフォーマットと進め方で作る業務一覧がそのまま使えます。手戻りが多いのは5番目です。対象業務の線を引かないまま4番目のツール選びに進むと、製品の機能一覧が対象範囲を決めてしまいます。

1番目の課題を全社のIT戦略から選ぶ段階、つまりどのIT施策に何年でいくら投じるかを決める作業はIT戦略とは？経営戦略からの落とし込み方とIT中期計画の作り方で解説しています。

投資目標を金額と期限で置くための現状値の測り方と記録の残し方

投資目標は、現状値が無いと置けません。「請求書発行の工数を減らす」ではなく「請求書発行に月120時間かかっている作業を、稼働から6か月以内に月30時間にする」のように、現状値・目標値・期限の3つを書きます。

現状値は、担当者への聞き取りだけでなく、件数と処理時間の掛け算で裏を取ります。月の請求書が800件、1件あたり9分なら月120時間です。数字の出どころを企画書に残しておくと、稼働後の効果測定で比べる相手がはっきりします。システム管理基準の「Ⅱ.4.6 稼動後評価と報告」では、定量的な目標だけでなく定性的な目標にも客観的な証拠が必要です。「問い合わせへの回答が早くなる」のような定性目標も、測り方を企画の時点で決めておきます。

システム化計画書に書く項目と、計画段階で決めて要件定義へ渡す成果物

計画段階の16タスクは数が多いものの、計画書の章立てにすると8項目に収まります。

計画の16タスクをシステム化計画書の章立て8項目にまとめた対応表

タスク番号は調達管理ガイドのWBSに基づきます。マネーフォワードなどが紹介する「システム企画書」は、多くの場合この1・2・3・7章に相当し、承認を得るための要約版です。社内の決裁が企画書で済む会社でも、6章の選定方針と8章の体制は別紙で用意します。この2つが無いと、要件定義やRFPの段階で「誰が決めるのか」が決まっていない状態になります。

開発会社に見積もりを依頼する場合は、計画書の1〜6章をもとに提案依頼書を作ります。記載項目はRFPとは？提案依頼書の意味・目的・記載項目で整理しています。

費用とシステム投資効果の予測に使う投資回収年数の計算例と判断基準

IPAの「超上流から攻めるIT化の原理原則17ヶ条」は、原理原則の6番目に「システム化実現の費用はソフトウェア開発だけではない」、7番目に「ライフサイクルコストを重視する」を挙げています。7番目の行動規範は、システムのライフサイクルにわたって投資対効果（ROI）を算定することです。企画段階では、次の式で回収年数を出すのが扱いやすい方法です。

投資回収年数 ＝ 初期費用 ÷（年間の効果額 − 年間の運用費）

説明のための数字で計算します。初期費用1,200万円、年間の運用保守費180万円とします。効果は前の見出しの請求書業務で、月120時間が月30時間になれば年1,080時間の削減です。人件費を1時間4,000円で換算すると年432万円になり、回収年数は1,200万円 ÷（432万円 − 180万円）で約4.8年です。

判断の目安は、自社利用ソフトウェアの法定耐用年数である5年です。会計上の扱いはシステム開発費の資産計上と費用処理で解説しています。償却が終わる前に回収できない計画では、範囲を絞るか、効果の見積もりに漏れがないかを見直すことが必要です。上の例の4.8年はぎりぎりで、運用費が年30万円増えるだけで5年を超えます。ROIとNPVの使い分けはROI（投資利益率）とは？計算式・目安を参照してください。

システム企画を社内で担う範囲と開発会社に任せる範囲、企画段階で見送る判断

企画を外部に任せること自体は可能です。ただし、任せられるのは作業であって、決定ではありません。

発注者が手放してはいけない決定と、開発会社に任せてよい調査・試算の作業

17ヶ条の9番目は「要件定義は発注者の責任である」です。企画は要件定義よりさらに上流にあるので、同じ考え方がより強く当てはまります。社内で決めるのは、目的、対象業務の範囲、投資目標、予算の上限、プロジェクトの責任者の5つです。

開発会社に任せてよいのは、情報技術動向の調査、システム方式の比較案、概算費用の試算、全体スケジュールの素案、実現可能性の検証です。システム管理基準の「Ⅱ.3.6 実現可能性及び効果の分析」はPoCやPoTを例に挙げ、分析結果を経営者に報告することを求めています。PoCの進め方はPoC（概念実証）とは？意味・進め方と計画書で扱っています。

一創では、システム化計画書の作成支援から要件定義・RFP作成までを要件定義・RFP作成・PMO支援として請け負っています。社内に企画の経験者がいない場合は、計画書の8章のうち4章（方式）・6章（日程）・7章（費用）の素案作成を外部に頼み、1〜3章と8章は社内で書く分担が進めやすい形です。

回収年数・体制・前提の3点から見て企画段階でシステム化を見送る条件

企画の結論は「作る」だけではありません。次のどれかに当てはまる場合は、要件定義に進まず、企画を差し戻すか見送ります。

• 回収年数が5年を超え、範囲を絞っても5年以内に収まらない
• プロジェクトの責任者を業務部門から出せず、IT部門だけで要件を決めることになる
• 投資目標の現状値が測れず、稼働後に効果を確かめる手段がない
• 対象業務の手順が拠点や担当者ごとに異なり、標準の業務の姿を決められない

4つの中で費用に響きやすいのは4つ目です。業務が揃っていない状態でシステム化すると、拠点ごとの例外処理が要件に積み上がり、費用が膨らみます。この場合は先に業務の手順を揃え、3〜6か月運用してから企画をやり直すほうが、結果として費用を抑えられる進め方です。17ヶ条の8番目「システム化方針・狙いの周知徹底が成功の鍵となる」も、行動規範として情報システム構築の方針・狙いを関係者に周知徹底することを挙げています。

システム企画の進め方と発注側が作る企画書・計画書に関するよくある質問

システム企画について、発注側の担当者からよく受ける質問をまとめました。

システム企画と要件定義の違いは何ですか？

システム企画は「何のために、どの業務を、いくらでシステム化するか」を決める工程で、要件定義は「その枠の中でシステムに何をさせるか」を決める工程です。共通フレーム2013では、企画プロセス（2.1）の次に要件定義プロセス（2.2）が置かれています。企画の成果物は構想書と計画書、要件定義の成果物は要件定義書です。要件定義の進め方は要件定義とは？目的・進め方・成果物で解説しています。

システム企画書とシステム化計画書は同じものですか？

呼び方は会社によって異なり、同じ文書を指すこともあります。共通フレームの区分では、構想の段階で作るのが構想書、計画の段階で作るのが計画書です。一般に「システム企画書」と呼ばれる文書は、背景・課題・解決策・費用対効果を1冊にまとめた決裁用の資料で、計画書の要約にあたります。決裁は企画書で受け、計画書は要件定義と見積もり依頼の土台として残す、という使い分けが実務的です。

システム企画にはどれくらいの期間がかかりますか？

公的な基準はありません。一創の見立てでは、1つの部門の1業務を対象にする場合、構想から計画の承認まで1〜3か月が目安です。期間を左右するのは文書の作成ではなく、経営層と業務部門の判断を待つ時間です。決裁の会議日程を企画の開始時点で押さえておくと、期間が読みやすくなります。複数部門にまたがる基幹システムの刷新では、半年を超えることも珍しくありません。

職種としてのシステム企画はどんな仕事ですか？

事業会社の情報システム部門やDX推進部門で、本記事で扱った構想・計画の作成と承認の取り付けを担う職種です。求人では、ベンダーとの調整や導入後の効果検証まで含めて「システム企画」と呼ぶことが多く見られます。工程として必要な知識は、業務分析、費用と効果の試算、要件定義の進め方です。体制の作り方はPMOとは？役割・種類とPMとの違いも参考になります。

システム企画にかかった費用は資産計上できますか？

企画段階の費用は、一般に研究や検討の性格が強く、ソフトウェアの取得価額に含めず発生時の費用として処理されることが多い費目です。ただし、契約の形態や、どの時点で開発が確定したかによって判断が変わります。最終的な扱いは顧問税理士や監査法人に確認してください。判定の考え方は前出の資産計上の記事で詳しく解説しています。

関連記事

• システム開発の流れとは？工程の全体像と各フェーズのポイントをわかりやすく解説：企画の後に続く要件定義から運用保守までの全体像
• システム要件定義とは？業務要件・ソフトウェア要件との違いと決める項目を解説：計画書を受けて要件を決める次の工程
• 要求定義と要件定義の違いとは？責任範囲・成果物・契約の分界点を解説：企画から要件定義へ渡すときの責任の分け方
• 業務分析とは？手法と進め方の5段階、システム化の前に決める範囲と成果物：構想の材料になる現行業務の分析
• システム開発の費用相場は？内訳・人月単価と見積もりの妥当性を発注者視点で解説：計画書の費用欄を見積もるときの相場感