SAP導入の構想策定 ─ 成果物は計画書より、経営が決めた4つの判断の記録

SAP導入の構想策定を終えると、厚い計画書が残ることが多いと筆者は見ています。現状の課題、新しい業務の全体像、システムの構成、スケジュール。それでも要件定義が始まると、「対象に海外の子会社は入るのか」「過去のデータは移すのか」といった問いが、あらためて出てくることがあります。

計画書に書いてあっても、経営が決めていなければ、その論点は決まっていません。筆者は、構想策定の成果物を計画書だとは考えていません。残すべきものは、経営が決めた4つの判断の記録です。 導入の目的、対象範囲、移行の方式、予算と期間の置き方の4つです。

SAP導入の構想策定とは、要件定義の前に「決めること」を決める工程

構想策定は、導入を始める前に、何のために、どの範囲で、どう進めるかを決める工程です。グランドデザインと呼ぶ会社もあります。

IPA（情報処理推進機構）の「ユーザのための要件定義ガイド」は、要件定義の前の工程を企画と呼んでいます。企画では、経営上の課題を解決するための新しい業務の全体像と、その実現に向けたシステムの構想を立てます。そのうえで計画を具体化し、関係者の合意を得ます。同じガイドには「良き構想なくして良き要件定義はない」という一節があり、構想に不備があれば、要件定義の前に整える時間を取るべきだとしています。

筆者の見るところ、SAPの導入方法論であるSAP Activateでは、最初のDiscoverフェーズがこれに近い位置にあります。SAPの説明では、ビジネスケースをつくり、プロジェクトのスコープを決める段階です。

要件定義は、細かいことを決める工程です。画面、帳票、勘定科目、承認の流れ。こうした細部を決められるのは、その手前で大きな枠が決まっているからです。構想策定は、要件定義で決めることの枠を先に決める工程です。

構想策定が枠を決め、要件定義はその中の細部を決める

IPAのガイドに沿うと、構想策定で作る成果物は5つの項目に整理できる

構想策定の実施内容と成果物は、会社によって呼び名が違います。IPAの同じガイドは、要件定義を始める前に確かめる企画の内容として、5つの項目を挙げています。

表　要件定義の前に確かめる企画の内容（出典1の表6.1をもとに作成）。

筆者の見るところ、この5つは、書類としてそろえるだけなら、外部の支援者が書き上げられます。難しいのは、そこに書かれた内容を経営が決めたと言える状態にすることです。同じガイドは、企画の内容が不十分なら、無理に要件定義を始めず、構想・企画に差し戻すよう勧めています。

5項目がそろっても、誰が決めたかを言えなければ、要件定義には進まない

経営会議で決める4つのこと

構想策定の出口で、経営会議にかける判断は4つです。

構想策定は、集めた材料を、経営が決めた4つの判断に変える工程

計画書は材料をまとめた書類で、出口に残すのは判断の記録。4つは経営会議で決め、その下の細かい論点は、仮の前提と決める日を書いて持ち越す。

SAP導入の目的：何を変えるための導入かを決める

「老朽化した基幹システムの刷新」は、目的としては弱いと筆者は考えています。刷新して何を変えるのかが書かれていないからです。決めるのは、何を、いつまでに、どこまで変えるかと、その責任者です。書き方は、あとの節で扱います。

対象範囲：入れるものと、入れないものを決める

対象の会社、国、拠点と、対象の業務を決めます。販売、購買、生産、在庫、会計のどこまでを一度に入れるのか。会計から先に入れるのか。入れないと決めたものも書いておきます。範囲の外が書かれていないと、要件定義の途中で範囲が広がります。

移行の方式：何を持ち越すかを決める

いまSAP ERPを使っている会社は、新しく入れ直すのか、いまのシステムを変換するのか、必要なデータを選んで移すのかを決めます。方式によって、持ち越す設定とデータが変わり、作業の中身がまるごと変わります。初めてSAPを入れる会社は、いまのシステムから何を持ち越すか（マスタ、残高、過去の明細）と、提供形態を決めます。構想で決めるのは、どの方式を前提に見積もりを頼むかです。現行の調査や追加開発の棚卸しの結果で、見直すことはあります。選び方はSAP移行の方式の記事で扱っています。

予算と期間の置き方：幅と、見直す時点を決める

構想の段階では、金額も期間も確定しません。決めるのは、予算の幅と、どの工程の終わりで見直すかです。これも後の節で扱います。

4つの判断と、判断に要る材料を表にまとめます。

表　経営会議で決める4つの判断と、判断に要る材料。筆者の整理。

ほかの記事で挙げた数え方との関係も書いておきます。SAP導入の費用の記事では、見積もりを頼む前に経営会議で決める項目として、対象範囲、利用区分、標準機能で足りない要件、移行データの4つを挙げました。対象範囲は、この記事の2つめと同じ判断です。移行データは、方式の判断を、移す範囲と年数まで細かくしたものです。利用区分と標準機能で足りない要件は、構想の4つを決めたあと、見積もりを頼む前に足して決めます。

SAP導入の失敗事例の記事では、要件定義の前に決める5つの判断を挙げました。そのうち目的は、この記事の1つめと同じ判断です。現行の業務とシステムの調査は、構想の材料集めにあたります。標準との線引き、切替、変更の止め方の3つは、構想の4つを決めたあと、要件定義に入る前に決めます。

構想で4つを決めたあと、見積もりの前に2つ、要件定義の前に3つを足して決める

SAP導入の目的を、測れる言葉と責任者で書く

目的があいまいなまま進むと、何が起きるか。IPAのガイドは、企画の目的が「サプライチェーン業務の見直し」のようなあいまいなものだと、関係者ごとに目的の受け取り方が違ってきて、手戻りのリスクがあるとしています。経営層に対しては、数値で示した目標か、達成したかどうかを確かめられる目標を置くよう求めています。

政府の情報システムのルールである「デジタル・ガバメント推進標準ガイドライン」も、同じ考え方です。プロジェクト計画書に、達成する目標を、具体的な指標と達成の年度で書くよう定めています。計画書の素案は、構想の段階でつくるとされています。

書き方の例を示します。数字は説明のための例です。

表　目的の書き方の例。日数、社数は例示で、目安や推奨の値ではない。

目的は、追加開発を認めるかどうかの物差しにもなります。要件定義で「この処理は標準機能に合わない」という論点が出たとき、目的に照らして要るかどうかを判断できるからです。目的が「刷新」のままだと、現場の要望を断る理由がありません。

測れる目的と責任者があれば、追加開発が要るかどうかをその場で判断できる

予算は幅で置く

構想の段階で出てくる金額は、確定した金額ではありません。IPAと経済産業省が整備した「情報システム・モデル取引・契約書」は、工程が進むにつれて見積もりの精度を上げる考え方を採っています。IPAの解説は、見積もりの精度を、システム化の方向性と計画を決める段階では試算、要件定義の段階では概算、外部設計の段階では確定と示しています。

構想の段階の金額は試算。幅で置き、工程の終わりごとに狭めていく

構想の段階で一つの金額を約束すると、その数字が確定額として残る。幅と見直す時点を、先に経営会議で決めておく。

経営会議の資料には、一つの金額でなく幅を書きます。あわせて、要件定義と外部設計のそれぞれの段階で見直すことと、幅を超えそうなときに何を削るかを書いておきます。費用の内訳と、見積もりを取る前にそろえる項目は、SAP導入の費用の記事にまとめています。期間も同じで、構想の段階では幅で置きます。

構想策定を外に頼むときは、成果物を判断の記録として頼む

構想策定は、外部の支援を受けて進める会社もあります。頼めるのは、材料を集めて整理する作業と、経営会議の資料づくりです。決めること自体は頼めません。

頼み方で気をつける点を3つ挙げます。

成果物の定義。 計画書の章立てでなく、「経営会議で4つの判断が決まった状態」を成果として頼みます。契約の形は、IPAが示す多段階契約の例では、システム化の方向性と計画を決める段階は準委任です。完成を約束する請負でなく、決めるための作業を頼む形です。

次の工程との関係。 構想を手伝う会社が、その後の導入を請ける候補でもある場合は、範囲や方式がその会社の得意な形に寄らないかを確かめます。政府のガイドラインは、調達仕様書の作成に直接関与した事業者を、その調達の入札に参加させないと定めています（競争上有利にならない場合を除く）。民間に適用されるルールではありませんが、考え方は参考になります。

担当する人。 構想の質は、会社の規模より、担当する人の経験で決まると筆者は見ています。確かめ方はSAPコンサル会社の選び方の記事に書きました。

構想のあとは、RFPを書いて提案を受けます。書く項目はSAP導入のRFPの記事に、導入全体の流れはSAP導入の進め方の記事に整理しています。

Never Redは、構想の段階で、移行の目的、対象範囲、方式の論点を整理し、経営会議の資料に仕上げるところからお手伝いしています。支援の範囲はSAP導入支援をご覧ください。移行の方式の比べ方は、S/4HANA移行支援にもまとめています。

よくある質問

構想策定とグランドデザインは違いますか。

呼び名の違いで、指している工程はおおむね同じです。導入を始める前に、目的、範囲、進め方を決める工程です。会社によって、実施内容と成果物の範囲が違うので、頼むときは成果物の中身で確かめてください。

構想策定と要件定義は、何が違いますか。

構想策定は、何のために、どの範囲で、どう進めるかという枠を決めます。要件定義は、その枠の中で、業務の型や画面、帳票などの細部を決めます。IPAのガイドは、構想に不備があれば、要件定義の前に整える時間を取るべきだとしています。

構想策定には、どれくらいの期間がかかりますか。

一律の目安は示せません。対象の会社の数と、現行の業務とシステムをどこまで調べるかで変わるからです。期間より、4つの判断が経営会議で決まったかどうかを終わりの条件にすることを勧めます。

構想策定で、よくある課題は何ですか。

筆者の見るところ、多いのは、資料はそろったのに経営会議で決まっていない、という状態です。目的が「刷新」のまま、対象範囲に「検討中」が残ったまま、RFPを書き始めてしまう場合です。4つの判断は、経営会議で決め切ります。その下の細かい論点が決まらないときは、仮の前提を置いて、いつ誰が決めるかを書いておきます。

構想策定は、どの部門が主導しますか。

筆者の見るところ、取りまとめは経営企画や情報システム部門が担うことが多い工程です。ただし、目的と対象範囲は事業部門とCFOが、方式は情報システム部門と経理が一緒に考えます。4つの判断を決めるのは経営会議です。

SAP導入の構想策定や、経営会議の資料の組み立てについてのご相談は、お問い合わせからお寄せください。

出典

1. 企画工程の説明（新たな業務の全体像と実現に向けたシステム構想の立案、計画の具体化と関係者の合意）、「良き構想なくして良き要件定義はない」、経営層に求める目標設定、企画内容の確認（表6.1）、あいまいな目的による手戻りのリスク、不十分な企画は構想・企画に差し戻すこと：独立行政法人情報処理推進機構（IPA）「ユーザのための要件定義ガイド 第2版 要件定義を成功に導く128の勘どころ」
2. SAP ActivateのDiscoverフェーズの説明（ビジネスケースを策定し、プロジェクトスコープを決定する）：SAP Japan「SAP Activate」
3. プロジェクト計画書に書く目標（具体的な指標と達成目標年度）、構想段階でのプロジェクト計画書の素案の作成、調達仕様書の作成に直接関与した事業者の入札制限：デジタル庁「デジタル・ガバメント推進標準ガイドライン」（2026年6月12日 デジタル社会推進会議幹事会決定）第3編第2章・第6章
4. 多段階契約の例（システム化の方向性とシステム化計画は準委任のコンサル契約）と、見積もりの精度（試算、概算、確定）：独立行政法人情報処理推進機構「システム開発の健全化に向けて ～『情報システム・モデル取引・契約書』から読み解く～」（2025年4月24日講演資料）