構想策定とは？ 構想策定の実施内容や課題、意識すべきポイントなどを解説

構想策定は、新しくERPなどのシステムを構築・導入するプロジェクトにおいて、最初に実施する工程です。構想策定では、主に新しいシステムの構想や事業計画などの体系的な整理を行います。

本記事では、構想策定の概要や実施内容、課題、実施にあたって意識すべきポイントについて解説します。

はじめに、構想策定の概要や要件定義との違いについて解説します。

構想策定とは、業務改革やシステムの構築・導入などのプロジェクトにおいて、最初に行う超上流工程を指します。

新しく実現したい業務の方針検討や、システムの構想・企画を行うことが一般的です。たとえば、業務改革のロードマップ策定や、改革実現のためのシステム全体像、導入効果、コスト試算、開発計画などの各観点を整理していきます。

要件定義もシステム構築・導入の上流工程にあたりますが、構想策定は要件定義よりもさらに上流工程の位置づけとなります。

要件定義は、構想策定によってまとめた業務改革の構想や事業ロードマップ、プロジェクト計画などをもとに、システムに対する要件を具体化していく工程です。

構想策定の実施内容について、4つのステップに分けて解説します。

まずは業務改革の企画・構想として、どの対象領域・部門のどのような課題を解決していくのかを検討します。たとえば、BtoB領域であれば、業界や業種、抱えている業務課題などを定義することになるでしょう。

そのうえで、業務課題に対してどのようなアプローチで解決するかを策定していきます。

次に要求定義として、企画・構想した業務改革の方針を具体化し、機能要求に落とし込んでいきます。たとえば、利用者や利用シーン、使用するシステムの機能、扱うデータなどを洗い出します。

機能要求を整理することで、システムの機能体系や必要な予算、競合他社と比べた優位性などの判断が可能です。そして、必要な予算や実現すべき機能体系の情報をもとに、事業計画を立案していきます。

事業計画の立案では、システムを導入するまでのスケジュール策定や費用対効果、競合優位性、実現アプローチなどの検討を行います。

また、事業計画においては、構築するシステムの実現スコープや時間軸を明確にしておくことが重要です。

実現スコープや時間軸が不明瞭な場合、後続のシステム要件定義の検討スコープや要員計画などが定まらず、システム要件定義工程を開始できないおそれがあります。構想策定の段階でしっかりと実現スコープや時間軸を定めていきましょう。

構想策定では、構想策定以降のシステム要件定義などの工程も計画します。たとえば、システム要件定義の対象となる機能や成果物、体制、スケジュール、予算などをプロジェクト計画書として整理します。

加えて、プロジェクト計画書をもとに、予算確保や決裁、人員配置、ベンダーとの契約など、プロジェクトを立ち上げるうえで必要な準備も行いましょう。なお、構想策定では基本的に上記のステップを踏みますが、必ずしも直列的に検討が進むわけではなく、検討の手戻りが生じることもめずらしくありません。

検討が進むにつれて新たに判明する部分もあるため、企画・構想を何回か練り直せるよう、余裕を持ったスケジュール計画を立ててください。

ここでは、構想策定での成果物について、前述の4つのステップに従って解説していきます。

業務改革の企画・構想としては、以下のようなビジネス課題や実現アイデア、システムのコンセプトなどをまとめた資料が成果物となることが一般的です。

• ビジネス上の課題をまとめたリスト
• 課題解決のための施策やアイデアをまとめたリスト施策
• アイデアを具現化するシステムのコンセプトや概要図

企業課題を包括的に洗い出し、それらの課題を解決するアイデアや実現システムのコンセプトを整理していきます。

業務改革に対する要求定義では、実現したい事項をシステムやデータに落とし込むための資料が成果物となるでしょう。

• システムの利用や運用に関するフローチャート
• 利用者やユースケースを整理した一覧
• システム機能要求一覧
• システム全体像
• 取り扱うデータの一覧

コンセプトレベルから一歩踏み込んで、システム機能要求レベルに具体化していきます。

システムを事業化するための戦略・計画の立案では、要求定義で整理した情報をもとに、システムの説明資料や事業計画のロードマップを作成します。

• システムの特徴や効果、競争優位性などをまとめた説明資料
• 事業計画を整理したロードマップ

要求事項を実現するためのシステム内容や、実現までの筋道を立てていくイメージです。

構想策定以降の計画では、後続のシステム要件定義などの工程を進めていくために、スコープや体制、予算、スケジュールなどをまとめたプロジェクト計画書が成果物となります。

• プロジェクト計画書

実際のプロジェクトに移行できるよう、人員や予算といった各要素をプロジェクト計画書として具体的にまとめていきます。

ここでは、構想策定において生じやすい課題を3つ紹介します。

経営層と現場層の視点や考え方が異なると、構想策定の検討が進みにくくなるおそれがあります。

経営層は、投資コストや社内のマネジメント体制、デジタル人材の不足など、経営にまつわる大きな視点で事業運営上の課題を捉えています。

一方、構想策定を主導する現場の業務担当や情報システム担当は、システム導入における社内方針や組織間の協力体制、業務プロセス改革の意思決定スピードなど、実行者視点でプロジェクト推進課題を捉えています。

立場の違いによる関係者間の視点や考え方の相違を埋めていくよう、関係者を集めた方向性のすり合わせが重要です。

新たなシステムを構想する場合、まだ具体化できていない構想策定では、システムへの期待値が過度に上がる傾向があります。

期待値が上がりすぎた結果、システム導入後に利用者の満足度が低下するリスクが考えられるため、構想策定の段階からシステムで実現できること・できないことのスコープを示していくことが大切です。

また、導入直後から短期的な効果を期待する利用者もいるため、中長期的な目線でビジネスを改革していくロードマップの共有も大事なポイントとなるでしょう。

本来はゼロベースでビジネス競争力向上につながる構想策定を行うのが望ましい一方で、議論の土台がないとなかなか検討が進まない面もあるのが実情です。

システムやデータは具体的な議論の土台になりやすいことから、システムやデータを先行した検討になる可能性があるでしょう。しかし、運用担当のリソースや業務オペレーションの計画など、システムやデータ以外の観点も並行して検討を進めていくことが必要です。

加えて、導入システムの特性によっては、法規制や税制度などのクリティカルな要素が含まれる場合もあるため、観点の抜け漏れがないかを慎重に確認することも求められます。

構想策定を成功させるためには、以下のポイントを意識しておくことが重要です。

企業のあるべき姿を実現するシステムを形づくるうえでは、幅広い部署からの意見を集めることが大切です。

経営戦略部門や営業部門、製造部門、財務部門など、業務に関わるさまざまな部署からメンバーを選定し、ヒアリングを行いましょう。ヒアリングの際は、決まった質問を一方的にするのではなく、意見を聞きだすように振る舞うことがポイントです。

新しく業務改革を実現するプロジェクトに一緒に参画している意識を醸成することで、後続の実行フェーズなどで再度関わりが出てきた際にも、スムーズにコミュニケーションを図れるでしょう。

システムに対する過度な期待を防ぐためには、実現できる業務改革のスコープを早めに関係者と共有し、認識を合わせることが肝心です。

特に、業務改革においてスコープ対象外となる業務領域や技術レベルなどは、事実ベースで共有しておくことで、後々トラブルとなる事態を防止できます。

経営層と現場層との認識相違を防ぐために、経営層とコミュニケーションを取る機会を定期的に設けることも欠かせません。

たとえば、四半期に1回ステアリングコミッティの場を開催し、構想・企画内容やプロジェクト計画の共有・合意形成を図ることなどが有効でしょう。ステアリングコミッティを開催するうえでは、早めに経営層の予定を押さえること、会議内容を録音やテキストでしっかりと記録して関係者へすぐに共有することがポイントです。

システムやデータ先行の議論にならないよう、さまざまな専門職能チームをプロジェクトに巻き込みましょう。

業務現場やUI/UXチーム、経営企画、経理、法務など、それぞれの専門職能の立場から意見を出してもらうことで、検討の抜け漏れを防止できます。特に、法規制などのクリティカル要素の見落としを防ぐためには、一見システム構築には無関係に見える法務担当の参画が重要な役割を果たします。

業務改革をしっかりと実現するためには、事前にシステムを多面的に評価することが重要です。

利用者のニーズ、業務フローの実現性、技術面のサポート体制、法規制の制約など、複数の観点を洗い出して評価していきます。また、Return on Investment（ROI）のシミュレーションを行い、業務改革後の収支計画や黒字化までの期間などを見積もることもポイントです。ROIをシミュレーションすることで、体制構築の実現性や外注要否の検討など、具体的な施策の検討も進めやすくなるでしょう。

システムの内容・特性にもよりますが、可能であればまずプロトタイプを作成し、関係者間に共有できると効果的です。

一部の機能などに限定しながらも、具体的な動作やデザインを実装し、利用者にとって満足のいくシステムであるかを評価することで手戻りリスクを軽減できます。プロトタイプ作成においては、開発担当やUI/UX担当、業務現場担当など、複数のステークホルダーで協力して実施することがポイントとなるでしょう。

構想策定を担当するメンバーと、実行フェーズや運用フェーズを担当するメンバーは異なる場合があります。

そのため、構想策定の段階で後続の実行フェーズや運用フェーズの体制案まで考案し、各部署の責任者や関係者と合意形成していくことが大切です。もし外部のコンサルティング会社などを構想策定段階でアサインさせる場合は、構想策定終了段階で成果物の説明をしっかりと受け、実行フェーズのメンバーに引継ぎできるように準備しておきましょう。

ここまで、一般的なシステム開発・導入における構想策定の方法やポイントを解説してきました。ここからは、ERPに焦点を当てた構想策定について解説していきます。

ERP（Enterprise Resource Planning：企業資源計画）とは、ヒト・モノ・カネ・情報などの経営リソースを一元管理し、有効活用する考え方やシステムのことです。ERPは、社内情報の一元管理に役立つだけではなく、一元管理しているデータをもとに経営上の意思決定を支援する役割も持ちます。

ERPにおいても、システム構築・導入の流れは一般的なプロセスと大きく変わらず、まずは構想策定から検討していきます。

ERPの構想策定では、導入目的によって適切なERPパッケージや導入形態などが異なるため、ERPによって解決したい企業課題の明確化が欠かせません。さらにERPのケースでは、導入範囲の定義も重要なポイントとなります。

本社だけに導入するのか、または各地方の支店や海外拠点のグループ会社にも導入するのかなど、導入スコープを明確にしていきましょう。

パッケージや導入形態、導入スコープを明確化することで、プロジェクトで必要な予算やスケジュール、体制などを具体的に定義できるようになります。

構想策定後は、要件定義や導入、運用保守といった各工程を進めていきます。

要件定義では、実現したい業務プロセスとERP機能とのフィット＆ギャップ分析などを行います。近年では、ERPの標準機能に業務を合わせるスタイルが主流です。これをFit to Standardと言います。

導入においては、フィット＆ギャップ分析で生じた導入課題に対する対応方針を明確化したうえで、まずは試行的にERPを導入して運用を実施します。導入後の運用保守では、試行導入で判明した運用課題を解決するための運用改善やソフトウェアのチューニングなどを行い、本格運用を進めていきます。

ERPにおける構想策定では、以下のポイントを意識することが重要です。

ERP導入プロジェクトでは、企業の業務プロセスやデータの管理方法などを抜本的に変革する場合も少なくありません。

そのため、現状の業務課題やシステム課題について、局所的ではなく、全体的に洗い出して把握することが大切です。

全体的に明確化した結果、業務都合などを考慮し、あえて一部の業務やシステムをERP導入対象外とすることも選択肢の1つでしょう。

多くの場合、ERP導入目的は特定の業務の効率化ではなく、企業全体の業務効率化や生産性向上による競争力の強化です。

したがって、構想策定で検討する際も、全体最適の視点で業務効率化を追求する姿勢が重要となります。たとえば、商品データなどのインプット業務を効率化しても、データ形式の変更などでデータを活用する部署の生産性が低下する場合、全体最適の視点では得策とはいえません。

構想策定は、業務改革やシステムの構築・導入などのプロジェクトにおいて、システム要件定義よりも前に実施する超上流工程です。

構想策定では、業務改革構想やプロジェクト計画書の策定などを行い、後続のシステム要件定義などの工程へスムーズにつないでいく必要があります。

構想策定を効果的に進めるためには、経営層や関連部署との密なコミュニケーションや、多角的な検討が欠かせません。そして、ERPにおける構想策定では、各拠点や各業務への導入スコープを明確化するとともに、ERPの導入目的となる企業の全体最適化を踏まえた検討が重要となります。構想策定でERPなどの実現スコープや機能をしっかりと関係者間で合意形成し、自社の競争力強化につなげていきましょう。