LASSIC Media らしくメディア

2026.07.02 らしくコラム

システム化構想・企画フェーズの進め方

LASSIC IT事業部|元請(プライムベンダー)としてシステム保守・運用を受託

システム化構想・企画の検討イメージ

この記事のポイント

  • システム化構想・企画フェーズは要件定義より前の超上流工程であり、経営層の意思決定がプロジェクトの成否を左右します。
  • 共通フレームでは企画プロセスを「システム化構想の立案」と「システム化計画の立案」に分けて定義しています。
  • 経営戦略との整合、費用対効果、体制、リスク分析をどう組み立てるかを発注責任者の視点で整理します。

システム化構想・企画フェーズとは — 要件定義より前の意思決定

上流工程の計画立案イメージ

システム化構想・企画フェーズとは、経営戦略や業務課題を起点に、システム化の方向性と実行計画を固める要件定義前の工程を指します。情報処理推進機構(IPA)の共通フレームでは、この工程を「企画プロセス」と呼び、要件定義プロセスより前段に位置づけています*1

要件定義は「何を作るか」を機能・性能レベルまで詰める工程です。これに対して企画フェーズは、そもそも何のためにシステム化するのか、どこまでの範囲で取り組むのかという経営判断を扱います。この判断が曖昧なまま要件定義に進むと、後工程での手戻りが発生しやすくなります。

発注責任者にとって企画フェーズが重要なのは、要件定義以降の工程はこの段階で決めた方向性・予算・体制を前提に進むためです。企画段階での認識のずれは、要件定義・設計・開発が進むほど修正コストが大きくなります。経営層・DX推進部門・情報システム部門・事業部門が、要件定義に入る前に共通の土台を作る工程が企画フェーズです。

図

共通フレームにおける企画プロセスの位置づけ

IPAが公表する共通フレーム(SLCP-JCF。ソフトウェアライフサイクルプロセスの日本版共通フレーム)は、システム開発を発注者と受注者が共通の物差しで捉えるための工程モデルです。この中で企画プロセスは、要件定義プロセスの前段に置かれています*1

共通フレームは企画プロセスの目的を、経営・事業の目的や目標を達成するために必要なシステム関連の要件とシステム化の方針、およびシステムを実現するための実施計画を得ることと定義しています*1。企画プロセスはさらに「システム化構想の立案」と「システム化計画の立案」という2つのプロセスに分かれます*1

システム化構想の立案は、経営課題を解決するための新たな業務とシステムの構想を立案するプロセスです*1。システム化計画の立案は、システム化構想を具現化するためのシステム化計画とプロジェクト計画を具体化し、利害関係者の合意を得るプロセスです*1。この2段階を経たうえで、要件定義プロセスに引き継がれる流れになります。

要件定義との違いを整理すると、企画プロセスは「なぜ・何のために・どこまで」を扱い、要件定義プロセスは「具体的に何を実現するか」を扱います。企画プロセスの成果物が曖昧なまま要件定義に着手すると、要件定義の途中で「そもそもの目的」に立ち返る手戻りが起きやすくなります。IPAの事例集でも、システム化方針の確認やプロジェクトの背景・目的の共有を要件定義フェーズの計画と承認より前段の取り組みとして整理しています*2

経営戦略と業務課題から方向性を導く — システム化構想の立て方

システム化構想の立案では、経営戦略や事業計画を起点に、どの業務課題をシステム化で解決するのかを明確にします。IPAの事例集は、この段階の成果物として「システム化方針の確認」「プロジェクトの背景・目的の共有」「システム化範囲の選択と集中」を挙げています*2

システム化方針の確認では、既存システムの全体像や機能の関連、業務のカバー範囲を可視化します*2。個別のシステム単体ではなく、事業全体の業務とシステムの関係を俯瞰したうえで、どこに手を入れるべきかを見極める段階です。

プロジェクトの背景・目的の共有では、なぜこのプロジェクトが必要なのかという背景と、解決すべき課題を関係者間で言語化します*2。この共有が曖昧だと、後工程で部門ごとに異なる期待値を持ったまま進み、要件定義の段階で目的の解釈がぶれる原因になります。

システム化範囲の選択と集中では、複数の解決策を比較検討したうえで、どの範囲までシステム化するかを絞り込みます*2。すべての業務課題を一度にシステム化しようとすると、投資規模が肥大化し、優先度の高い課題への対応が遅れます。経営戦略上の優先度に照らして、着手する範囲を意図的に絞り込むことが構想段階の要になります。

費用対効果・体制・リスクを固める — システム化計画の立て方

システム化構想で方向性が固まったら、それを実行可能な計画に落とし込むのがシステム化計画の立案です。IPAの事例集は、この段階の成果物として「プロジェクト実行計画の策定」「投資効果による評価」を挙げています*2

プロジェクト実行計画の策定では、QCD(品質・コスト・納期)の目標、全体スケジュール、開発体制、リスク管理の方針を定めます*2。全体スケジュールは要件定義以降の工程に対する前提条件になるため、この段階で現実的な期間設定をしておく必要があります。

投資効果による評価では、開発工数の見積り、定量効果と定性効果の予測、収支予測を行います*2。定量効果はコスト削減額や業務時間の削減など数値で示せる効果、定性効果は業務品質の向上や意思決定の迅速化など数値化しにくい効果を指します。両方を整理することで、投資判断の材料が経営層に提示できる形になります。

リスク分析では、プロジェクトが計画通り進まない場合に想定される要因を洗い出します。要員確保の遅れ、既存システムとの連携における技術的な不確実性、業務部門の合意形成に要する期間などが典型的な検討対象です。リスクを事前に洗い出しておくと、要件定義以降で問題が顕在化した際の対応判断が早くなります。

これらの計画は、要件定義フェーズの計画と承認という次の工程へ引き継がれます*2。企画段階で固めたスケジュール・体制・投資効果の前提が、要件定義以降の詳細な検討の土台になります。

目的の明確化・合意形成・優先順位 — 発注責任者が押さえる論点

費用対効果・スケジュール策定のイメージ

企画フェーズを主導する発注責任者が押さえるべき論点は、大きく4つに整理できます。第一に、システム化の目的を事業目標に紐づけて明確化することです。目的が「業務効率化」のような抽象的な表現にとどまると、要件定義の段階で優先順位の判断基準が定まりません。

第二に、経営層・事業部門・情報システム部門の関係者間で合意を形成することです。部門ごとに異なる期待や利害を持ったまま企画を進めると、要件定義以降で「聞いていた話と違う」という食い違いが表面化します。企画段階で関係者を巻き込み、合意形成の場を設けることが手戻り防止につながります。

第三に、要求の優先順位を付けることです。すべての要望を同列に扱うと、システム化範囲が際限なく広がり、費用対効果の評価が困難になります。経営戦略への貢献度と実現の緊急性を軸に、対応する要求と見送る要求を仕分ける判断が企画段階で求められます。

第四に、内製と外注の方針を決めることです。自社に企画・要件定義の経験を持つ人材が確保できているか、どの範囲を社内で担い、どの範囲を外部の専門知見に委ねるかを、企画の早い段階で方向づけておく必要があります。この判断を要件定義の直前まで先送りすると、体制構築が間に合わず計画全体が遅延する要因になります。

構想策定・PMOの外部活用という選択肢

システム化構想・企画フェーズを自社だけで進めるには、経営戦略の理解と情報システムの知見の両方が必要です。この2つを兼ね備えた人材を社内に確保できていない企業では、構想策定やPMO(プロジェクトマネジメントオフィス。複数のプロジェクトを横断的に管理・支援する機能)の段階から外部の専門知見を活用する選択肢があります。

構想段階で外部支援を受ける場合、業務課題の整理や現状のシステム全体像の可視化を、第三者の視点で棚卸しできる利点があります。社内の担当者だけで進めると、既存の業務慣行を前提にした議論になりがちで、システム化の方向性が視野狭窄に陥る場合があります。

企画段階を自社だけで進める場合、必要になるのは経営戦略の理解、業務プロセスの分析、投資対効果の算出、プロジェクトマネジメントの知見です。これらを兼ね備えた専任人材を確保できない場合、企画の精度が下がり、要件定義以降での手戻りにつながるリスクがあります。

本記事で扱う構想・企画フェーズは、要件定義そのものを外部委託する取り組みとは異なる段階です。要件定義に入る前の「何を・どこまで・なぜ」を固める工程であり、この段階を丁寧に進めることが、後続の要件定義や開発委託の精度を高める前提になります。

LASSICに相談するメリット

LASSICは元請(プライムベンダー)(元請)として、システムの保守・運用を受託する体制を整えています。要件定義より前の構想・企画段階から、業務課題の整理や実行計画の検討をご相談いただくことも可能です。

まとめ:企画フェーズで固めるべき3つの判断軸

本稿では、要件定義より前の超上流工程であるシステム化構想・企画フェーズの進め方を整理しました。要点を3つに集約すると次の通りです。第一に、共通フレームは企画プロセスを「システム化構想の立案」と「システム化計画の立案」に分けて定義しており、経営戦略に基づく方向性の決定と、実行可能な計画への具体化という2段階で進める必要があります。第二に、構想段階ではシステム化方針の確認・背景目的の共有・範囲の選択と集中を、計画段階では実行計画の策定と投資効果の評価を丁寧に行うことが、要件定義以降の手戻りを防ぐ前提になります。第三に、目的の明確化・関係者の合意形成・要求の優先順位付け・内製外注の方針決定という4つの論点を発注責任者が早期に押さえることが、企画フェーズの精度を左右します。

よくある質問

システム化構想と要件定義はどちらから始めればよいですか。

システム化構想から始めるのが基本です。共通フレームでも企画プロセスは要件定義プロセスの前段に位置づけられています。経営戦略や業務課題から方向性を固めないまま要件定義に着手すると、目的の解釈が関係者間でずれたまま進み、後工程での手戻りにつながります。

システム化構想と企画にはどのくらいの期間をかければよいですか。

プロジェクトの規模や関係部門の数によって必要な期間は異なり、一律の目安を示すことは適切ではありません。既存システムの全体像の把握、関係者との合意形成、投資効果の算出といった作業項目を洗い出したうえで、自社の体制に応じた現実的なスケジュールを見積もることが重要です。

企画フェーズは情報システム部門だけで進めてよいのですか。

情報システム部門だけで進めることは推奨できません。システム化構想は経営戦略や事業の課題を起点にするため、経営層と事業部門を交えた合意形成が欠かせません。情報システム部門に閉じて進めると、技術的な実現性は検討できても、事業戦略との整合や優先順位の判断が不十分になりやすくなります。

構想段階から外部の専門家に相談するメリットは何ですか。

社内の業務慣行を前提にせず、第三者の視点で業務課題やシステムの全体像を棚卸しできる点がメリットです。経営戦略の理解と情報システムの知見の両方を兼ね備えた人材を社内で確保しにくい場合、構想策定やPMOの段階から外部知見を活用することで、企画の精度を高められます。

システム化計画で決めた内容は後から変更できますか。

要件定義以降の進捗に応じて見直すこと自体は可能ですが、頻繁な変更は前提となるスケジュールや体制の再構築を招きます。計画段階でリスク分析を丁寧に行い、想定される変動要因をあらかじめ洗い出しておくことで、変更の頻度と影響範囲を抑えられます。

著者:テレリモ総研編集部 鈴木 亮佑


ITアウトソーシング・システム開発のご相談はLASSICへ

元請(プライムベンダー)として、貴社の課題に合わせた体制構築・開発支援をご提案します。まずはお気軽にご相談ください。

無料相談はこちら

ご不明な点はお問い合わせフォームからもご連絡いただけます。

  1. *1 出典:情報処理推進機構(IPA)「共通フレーム2013」(2013年)https://www.ipa.go.jp/archive/files/000027415.pdf
  2. *2 出典:情報処理推進機構(IPA)「超上流から攻めるIT化の事例集:システム化の方向性と計画」https://www.ipa.go.jp/archive/digital/tools/ep/ep1.html


View