2か月で成果を出すDX計画：90日DXロードマップの作り方

「DXを進めたいが、どこから手をつければ良いか分からない」「ベンダーから提案は来るが、ROIやリスクを説明しきれず社内合意が進まない」。年商5〜10億規模の企業で、こうした悩みを抱える経営層・事業責任者・管理部門・DX推進担当の方は少なくありません。そこで本記事では、単なる流行のDX計画ではなく、90日で“最初の手応え”を出すDXロードマップの作り方を、実務レベルで整理します。

ここでいうDXロードマップは、「3年構想の立派な資料」ではなく、四半期（90日）単位でROIを確認しながら意思決定を前に進めるための実行計画です。2か月目までに小さく成果を出し、3か月目で体制と要件定義を固めることで、「経営判断として筋の通った投資ストーリー」と「ベンダーに渡せるDX計画・要件整理の形」を同時に手に入れることを目指します。

また、この記事は特定ツールの宣伝ではありません。作るか買うか（受託/SaaS/AI）をどう判断するか、どこまで要件定義すべきか、どの順番でDX計画を進めればROIとリスクが両立するかという、経営と現場の間をつなぐ視点に重点を置いています。

なぜDXロードマップは「90日」で考えるべきか

多くの企業でDX計画が止まる理由は、「スローガンはあるが、90日単位の具体的なDXロードマップがない」ことです。経営会議では「データ活用」「AI活用」「海外対応」などのキーワードが並びますが、実務レベルに落とした要件定義や要件整理が追いつかず、結局は既存業務の延長で年度が終わってしまう、というパターンがよくあります。

そこで有効なのが、四半期＝90日を1スプリントとみなしたDXロードマップです。これは「90日で全てを完成させる」という意味ではなく、90日の中で「判断」と「検証」と「次の一手」を必ず進めるという考え方です。具体的には、1〜2週で課題とKPI・ROI仮説を整理し、3〜6週で主要業務の整理と要件定義のたたき台を作り、7〜12週でPoCや限定導入を行いながら、次の投資判断の材料を集めます。

この90日DXロードマップのメリットは、「完璧なDX計画がないと動けない」という思い込みから解放されることです。年商5〜10億規模の企業では、専任の情報システム部門がなく、経企・財務・法務・情シスを兼務する管理部門責任者がDXロードマップも担っているケースが多く見られます。そのような環境では、最初から大規模な要求定義やDX計画を作るよりも、「90日でどこまで要件定義できれば次の判断ができるか」を明確にした方が、現実的かつROIも高くなります。

また、90日という区切りは、現場の「動いている感」を生みやすい点も重要です。例えば、営業支援のDX計画であれば、「1か月目で既存プロセスの見える化と課題の定量化」「2か月目でSFAやMAツールの候補選定と要件定義」「3か月目で一部チームへの試験導入とROIの仮測定」といったDXロードマップを引くことができます。これにより、経営も現場も「具体的な進捗」と「ROIの兆し」を共有しやすくなり、次の投資判断に必要な材料が揃っていきます。

重要なのは、90日ごとにDXロードマップをアップデートし続ける前提をおくことです。最初から3年分のDX計画を作るのではなく、「90日で学びを得て、ROIが見込める領域から順に拡張する」というスタンスこそが、変化の激しいIT・AI・海外展開の時代に適したアプローチだといえます。

経営判断として筋を通すDX計画：ROIと優先順位の決め方

DXロードマップを描く前に必要なのが、「このDX計画に投資する理由」を経営として説明できる状態を作ることです。ここで鍵になるのがROIです。ただし、ROIと言っても「何％回収できるか」だけを指すのではありません。実務上は、ROIを①コスト削減②売上・粗利の増加③リスク削減（事故・監査・コンプラ対応）の3つに分けて整理すると、投資対効果を説明しやすくなります。

例えば、受注〜請求までのバックオフィスをDX計画の対象とする場合、「入力作業削減による人件費削減」「請求漏れ防止による売上機会損失の削減」「監査対応工数の削減」といった複数のROIが見込まれます。これらを簡単な試算でも良いので数値化し、DXロードマップの冒頭で示しておくことで、社内の合意形成が進みやすくなります。ここでは厳密な財務モデルよりも、「なぜ今このDX計画に優先的に投資すべきか」が一貫していることが重要です。

次に、優先順位の決め方です。DXロードマップでは「インパクト×実現性×リスク」の3軸で評価することがよく行われます。インパクトは先ほどのROI（投資対効果）、実現性は要件定義の難易度や社内リソース、リスクはセキュリティ・法規制・監査・コンプラなどです。例えば、インパクトが大きくても要件整理が極めて難しく、関係部門が多い場合は、90日DXロードマップの第1弾ではなく、第2弾以降に回すといった判断も必要になります。

ここで有効なのが、「経営判断用の1枚サマリー」を作ることです。1枚の中に、現状課題、DX計画のゴール、ROIの方向性、優先順位、主要リスク、対応方針を整理します。この1枚を、取締役会・経営会議・部門長会議・プロジェクトメンバーの全てで共通言語として使うことで、DXロードマップの議論がぶれにくくなります。1枚サマリーの中には、簡易な要件定義や要件整理の内容も含めておくと、後続のRFPやベンダー選定にもそのまま活用できます。

ポイントは、「ROIが高いからやる」のではなく、「ROIとリスクと実現性のバランスが、今の自社にとって妥当か」を判断することです。その判断の結果をDXロードマップという形で可視化することで、「なぜこの90日でこのプロジェクトをやるのか」を社内で説明しやすくなります。

作るか買うかを決める：要件定義から考える選択とリスク管理

「自社専用システムを開発すべきか、それともSaaSや既製品で済ませるべきか」。これはDXロードマップの中でも最初に悩まれるポイントです。結論から言うと、この問いは技術の問題ではなく、要件定義とROIの問題です。作るか買うかを感覚で決めてしまうと、後からDX計画全体の整合性が崩れ、費用対効果が見合わなくなるケースが多く見られます。

まず考えるべきは、「自社の競争優位がどこにあるのか」です。競争優位そのものを支える業務やデータであれば、要件定義をしっかり行った上で、受託開発や内製開発を検討する価値があります。逆に、業界共通の定型業務であれば、SaaSの標準機能に合わせることで、DXロードマップの初期投資を抑えつつROIを早期に出せる可能性が高まります。いずれの場合にも、「どこまで要件定義を行い、どこからは標準機能やベストプラクティスに合わせるのか」を明確にしなければなりません。

SaaS導入の失敗で多いのは、要件整理をしないまま契約し、「使い始めてから現場に合わせて設定する」パターンです。この場合、権限設計やマスタ統一、他システムとの連携が後追いになり、DX計画のROIが見えづらくなります。一方、受託開発やAI活用では、要求定義が曖昧なまま見積もりを依頼すると、ベンダー側もバッファを多めに見積もらざるを得ず、費用対効果が悪化しがちです。

そこで、90日DXロードマップの前半（1〜6週）では、SaaSを含む複数の選択肢に共通するレベルの要件定義を行います。たとえば、「この業務フローをどう変えたいのか」「何をどのデータとして保持し、どのシステムと連携させるのか」「どの権限の人がどの操作をできるべきか」といった要件です。ここまではSaaSでも自社開発でも共通するため、DXロードマップの中で早い段階に整理しておく価値があります。

そのうえで、「この要件ならSaaSの標準機能に寄せた方がROIが高い」「この部分だけは自社固有要件なのでカスタマイズが必要」といった判断を、DX計画の投資ストーリーと照らし合わせながら行います。作るか買うかは、技術トレンドではなく、DXロードマップと要件定義とROIの整合性を見ながら決めることが、実務では非常に重要です。

90日DXロードマップの具体例：Week1〜12の進め方

ここからは、実際にどのように90日DXロードマップを回していくかを、Week1〜12の流れとして整理します。あくまで一例ですが、年商5〜10億規模の企業が新規システムやSaaS導入、AI活用を検討する際に使いやすい形を想定しています。

Week1〜2：現状把握とゴール・ROI仮説の整理
最初の2週間でやるべきことは、「現状業務の棚卸し」「関係者の洗い出し」「課題の整理」「ゴール設定」「ROIの仮説づくり」です。ここでは詳細な要件定義はまだ行いません。代わりに、「このDX計画が実現したとき、どのKPIがどう変わっているべきか」「投資対効果をどの観点で測るか（工数削減・売上増・リスク削減など）」を言語化します。この段階で、DXロードマップの全体像と優先順位をA4一枚にまとめておくと、社内合意が取りやすくなります。

Week3〜6：業務整理と要件定義のたたき台作成
次の4週間では、主要な業務プロセスをAs-Is/To-Beで整理し、データ項目・連携・権限・非機能（セキュリティ・可用性・監査ログなど）を洗い出します。ここで作るのは、「最終版の要件定義書」ではなく、ベンダーや社内エンジニアと建設的に議論できるレベルの要件定義のたたき台です。同時に、SaaSや既存ソリューションの候補をリストアップし、「この要件ならこのSaaSが候補になる」「ここは自社開発が必要」といった目星をつけていきます。

Week7〜12：PoC・限定導入・次フェーズDXロードマップの策定
最後の6週間では、候補として残ったSaaS・ソリューション・開発方針をもとに、小さなPoCや限定部署での導入を行います。このフェーズで重要なのは、ROIとリスクの仮説検証です。たとえば、「受注処理時間が何分短くなったか」「エラー件数がどれだけ減ったか」「監査に必要なログがどこまで自動取得できるか」といった指標を計測します。これにより、DX計画の旨味が見えるようになり、次の四半期のDXロードマップ（第2弾）に向けた投資判断がしやすくなります。

このように、90日DXロードマップでは、「完了」よりも「学びと判断材料の獲得」を重視します。2か月時点で一定の成果を確認し、3か月目でDX計画の次フェーズに向けた要件定義と体制づくりを進めることで、DXが“掛け声”で終わらず、継続的なROI創出サイクルへとつながっていきます。

ベンダーと伴走するための要件定義・ガバナンス・グローバル設計

DXロードマップを現実のプロジェクトに落とす際、避けて通れないのが「ベンダーとの情報非対称」と「ガバナンスの後付け」です。これを避けるために、発注側で最低限押さえておくべき要件定義とガバナンス設計のポイントを整理します。

まず要件定義です。ベンダーにRFPや見積もりを依頼する前に、少なくとも以下の観点は自社側で要件整理しておく必要があります。すなわち、対象範囲の業務フロー、画面や帳票のイメージ、必要なデータ項目とマスタ構造、他システムとの連携、ユーザー種別と権限、非機能要件（性能・可用性・ログ・バックアップなど）です。これらを全て完璧に決める必要はありませんが、「決まっていること」と「これから決めるが重要な論点（未決事項）」を分けて記載することで、要件定義の質とDX計画全体の透明性が上がります。

次にガバナンスです。セキュリティ・規程・監査への対応は、DXロードマップの後ろではなく、最初の要件定義の中に含める必要があります。たとえば、「誰がどのデータにアクセスできるか」「どの操作をログとして残すか」「ログをどのくらいの期間保持するか」「SaaSベンダーがどこまでデータにアクセスできるか」といった論点です。これらを曖昧にしたままSaaSやシステム開発を進めると、後から監査やコンプラの観点で大きな改修が必要となり、ROIが大きく毀損されてしまいます。

さらに、中長期的にグローバル展開を視野に入れる場合、DXロードマップの初期段階から、多言語・多通貨・税制・データ越境に耐えられる設計を意識しておくことが重要です。住所・氏名・税情報・インボイス番号などのマスタ項目を、将来の海外拠点やEC展開にも対応できるようにモデリングしておくことで、後からの作り直しを大幅に減らせます。特に、請求・決済・税計算は国ごとにルールが異なるため、「今は国内のみだが、将来は海外も想定している」という前提を要件定義に書き込んでおくだけでも、ベンダー側の設計が変わってきます。

こうした要件定義・ガバナンス・グローバル設計を、限られたリソースのなかで進めるのは簡単ではありません。そこで有効なのが、経営と現場の間を翻訳し、DXロードマップの作成から要件定義、技術選定、開発・導入、運用・ガバナンスまでを一気通貫で伴走できるパートナーを持つことです。内部のリソースでカバーしきれない部分を補いながら、投資ストーリーと実装をつなぐ支援を受けることで、DX計画全体の成功確率とROIを高めることができます。

まとめ：DXロードマップを現場の行動と経営判断につなげる

本記事では、2か月で成果を出し、90日で次の一手につなげるDXロードマップの考え方と、その中核となるROI・要件定義・ガバナンス・ベンダー連携のポイントを整理しました。重要なのは、「まずは90日で何を判断できるようになりたいか」を明確にし、そのために必要な要件定義と検証を逆算することです。完璧なDX計画を目指すのではなく、DXロードマップを短いサイクルで回し続けることで、投資対効果を確認しながら前に進める状態を作れます。

また、作るか買うか、AIをどこまで活用するか、グローバル展開をどのタイミングで織り込むかといった論点も、すべては要件定義とROIの整合性の問題です。自社だけでDX計画を進めるのが難しい場合は、経営と現場の間を翻訳し、DXロードマップの設計から実装・運用まで伴走できる外部パートナーを活用することも選択肢になります。

もし貴社が、「DXをやらなければとは思っているが、投資判断と要件整理で止まっている」「既にツールを入れたが、ROIや業務プロセスが見直せていない」といった状況にあるなら、今回紹介した90日DXロードマップのフレームを、一度社内プロジェクトに当てはめてみてください。小さなDX計画からでも構いません。2か月で成果を出し、3か月で次のステップへつなぐサイクルが回り始めれば、DXは単なるスローガンではなく、経営に組み込まれた継続的な投資判断プロセスへと変わっていきます。