「構想策定はAIで短くできます」と言われた方へ
SAP ERP（ECC 6.0）からS/4HANAへの移行、あるいはSAP以外の基幹システムからS/4HANAへの乗り換えを検討していて、ベンダーから「AIで現行システムを可視化し、構想策定を数か月に短縮する」という提案を受けた、または受けそうな情報システム部門や経営企画の方に向けて書いています。
短縮を疑う記事ではありません。短くなる工程と、短くならない判断を分けて読むという話です。分けて読むと、発注側が先に用意するものが見えます。
SAP刷新の構想策定とは
SAP刷新の構想策定とは、現行の業務とシステムを把握し、SAPの標準業務プロセスに照らして、どの業務を標準に乗せ、どれを作り替え、どれを別手段にし、どれをやめるかを決めて、導入範囲と計画を確定する工程です。業務をSAPの標準に合わせる考え方をFit to Standardと呼び、その判断の材料を作るのがこの工程です。
SHIFTは2026年9月2日、この工程を対象にした「SHIFT DQS for リバースエンジニアリング SAP S/4HANAオプション」の提供を始めました（プレスリリース）。SAP ERPの標準保守が終わる2027年問題を背景に、現行システムのブラックボックス化と、ヒアリングや文書解読に依存した調査手法が、上流工程が難航する最大の要因だと同社は書いています。
サービスは3つの段階で進みます。
| 段階 | 誰がやるか | 出てくるもの |
|---|---|---|
| 現行システムの可視化 | AI（既存サービスのリバースエンジニアリング） | ソースコードから起こした外部仕様と内部仕様。最大46種のドキュメント |
| SAP標準プロセス（スコープアイテム）への対応づけ | AI | 機能を業務単位に整理し、SAP標準へ紐づけたマッピング案 |
| 検証と業務のスリム化 | SHIFTのSAPコンサルタントと発注側 | マッピング案の再評価と、業務ごとの4分類 |
最後の4分類が、このサービスの出口です。
- 標準対応。カスタマイズせず、SAP標準プロセスをそのまま使う
- 業務変革。業務の目的は残し、SAP標準に合わせて業務の進め方を作り直す
- 拡張。SAP標準で代替できないので、別手段で拡張する
- 廃止。業務自体をやめる、または対象外にする
この分類を積み上げて、不要な追加開発をしない「アドオンゼロ」とクリーンコアを目指す、という建て付けです。
12か月が2か月になる数字の中身
平均と最短想定の比較です
| 数字 | 何の数字か | 前提 |
|---|---|---|
| 最大1/6 | 現行可視化から構想策定までの期間の短縮率 | 当社調べ。従来手法の平均約12か月と、本サービス適用時の最短想定約2か月の比較 |
| 6か月〜1年 → 最短2か月 | 同じ短縮を期間で表したもの | S/4HANAの対象範囲をフルモジュール（FI/CO/SD/MM）・ビッグバン導入とした場合。規模と範囲で変動 |
| 46種 | AIが生成するドキュメントの種類 | 2026年1月提供開始の「SHIFT DQS for リバースエンジニアリング」 |
| 累計2億Step | 同サービスのソースコード解析実績 | 2026年7月時点 |
| 100社超 | SHIFTのSAP関連支援の実績 | 設計・開発・テスト・教育・データ移行・運用保守を含む |
最大6分の1という数字は、同じ条件の実測を並べたものではありません。手作業の平均と、AI適用時の最短想定の比較です。前提のフルモジュール・ビッグバン導入と違う進め方、たとえば段階導入や一部モジュールでは比率が変わると、注記に書かれています。実測の公開事例は、この記事を書いた時点ではありません。
短くなるのは調査の工程です
AIが受け持つのは、最初の2段階です。どちらも、人が読んで突き合わせるのに時間がかかっていた調査です。
- 現行把握。ヒアリングと文書の解読に頼っていた工程を、稼働中のソースコードの解析に置き換える
- 標準との突き合わせ。起こした機能情報を業務単位で整理して、SAPの標準業務プロセスに紐づける
3段階目の検証は、SHIFTのコンサルタントがマッピング案の妥当性を業種と業務の文脈で再評価し、現行の独自カスタマイズの適合度を見直す、と説明されています。そのうえで、と同社は続けています。最終的に4分類のどれにするかを決めるのは、お客様自身です。
4つの分類を決めるのは発注側です
4分類の判断には、それぞれ違う人の合意が要ります。
| 分類と、決めるときに要るもの | 決めないとどうなるか |
|---|---|
| 標準対応。今のやり方を捨てることへの業務部門の合意 | 現行踏襲の要望が残り、拡張に流れる |
| 業務変革。業務の目的の再定義と、現場の教育計画 | 標準に乗せたつもりが、現場で別運用が生まれる |
| 拡張。別手段の費用と、SAPの外側で持ち続ける保守の見込み | アドオンが積み上がり、クリーンコアにならない |
| 廃止。業務そのものをやめる決裁 | 使っていない機能まで移行対象に残る |
アドオンゼロは方針であって、結果ではありません。SHIFTの資料でも「推進する」という表現です。4分類で拡張が多く残れば、クリーンコアにはなりません。何割を標準対応と業務変革に寄せるかの目標を、構想策定に入る前に経営側で置いておくと、分類の会議がぶれません。
決める会議体を先に用意する
構想策定を2か月で終えるということは、その2か月のあいだに、業務部門の決裁者が分類の会議に出続けるということです。AIが選択肢を出しても、決める人は減りません。この構造は要件定義をAIに任せてもで整理した話と同じです。決めるときの基準を先に文章にしておく価値は、機構は買える側に回りましたで扱いました。
現行の可視化を先に、要件ヒアリングを後に
このサービスの順番そのものは、SHIFTを使うかどうかにかかわらず参考になります。要件ヒアリングから始めると、出てくるのは「今と同じものが欲しい」で、見積もりの幅が倍になります。その構造は450人月と900人月の差はで見ました。
ソースコードから仕様を起こし、機能一覧を標準に照らしてから、ヒアリングは差分に絞る。この順番なら、業務部門に聞くのは「標準と違うこの部分をどうするか」だけになります。AIが読む範囲を絞ったときに何が速くなるかは、2年が2日になった案件でにあります。
注意点が一つあります。ソースコードから起こした仕様は「今こう動いている」であって、「こう動くべき」ではありません。使われていない機能や、誰も理由を知らない分岐も、同じ精度で仕様書になります。それをそのまま標準へ対応づけると、廃止すべき業務が移行対象に残ります。可視化の成果物を受け取ったら、業務側で「使っていない」を先に消す工程が要ります。仕様の復元と、その先の小さな試作の話はブラックボックス化したシステムをAIで読み解くを参照してください。
AIで構想策定を短縮する提案を受けたときに聞く5項目
-
現行システムの言語と規模は解析の対象に入るか。SAP以外の基幹からの新規導入でも同じサービスが適用できるかを含めて聞きます
-
46種のドキュメントのうち、自社の案件で実際に出てくるのはどれか。成果物の所有権と、別ベンダーへ渡せるかを確認します
-
マッピング案の検証は誰が何を見るのか。発注側に要る工数を、業務部門の人数と時間で出してもらいます
-
最短2か月の条件は何か。自社の範囲（モジュール、段階導入かビッグバンか）だと何か月の想定になるかを聞きます
-
可視化・対応づけ・検証の3段階を別々に見積もれるか。上流だけを切り出し、導入ベンダーを別に選べる形にします
ベンダーの提案説明の場と、社内の投資判断の会議で、そのまま確認項目として使えます
数字の出どころと限界
この記事の数字は、SHIFTが2026年9月2日に公開したプレスリリースと、同社のERPサービスサイト、リバースエンジニアリングのサービスサイト、IT Leadersの2026年9月3日の記事（SHIFT、SAP刷新の構想策定を最短2カ月に短縮するコンサルティング）に基づきます。12か月と2か月は同社調べで、実測の公開事例はありません。費用は公開されていません。
対象範囲には読み方の幅があります。IT Leadersの記事は対象を「SAP ERP（ECC 6.0）からS/4HANAへの刷新」と書いていますが、プレスリリース本文は「レガシーシステム」「現行システム」と広く書いています。基盤の解析サービスはSAP以外のコードも対象なので、SAP以外の基幹からの新規導入でも使える可能性は高いものの、公開情報だけでは断定できません。持ち帰り成果物の1項目目は、この確認のためのものです。
解析のAIは松尾研究所と共同で開発と精度検証を進めている、と同社は書いています。可視化の精度が案件ごとにどれだけ違うかは、公開されていません。直す範囲より先に直さない範囲を決める話は直す範囲より先に決めるのはに、テストしない範囲を先に決める話は自動化率85%より先に決めるのはにあります。