「業務企画と一緒に、ITロードマップを作ってほしい」
IT企画の担当者であれば、こうした依頼を受ける場面があるのではないでしょうか。
とはいえ、いざ作ろうとすると、
- そもそも ITロードマップって何を作ればいいの？
- 事業戦略とIT施策って、どうつなげればいいの？
- どこまで作れば「完成」なの？
こんな疑問が次々と湧いてきます。
結果、何から手をつけていいかわからないまま時間だけが過ぎる。あるいは、とりあえず施策を並べてみたものの、「これって本当にロードマップ？」と自分でも確信が持てない。
そんな経験はないでしょうか。
この記事では、ITロードマップの考え方と具体的な作り方を、実例を交えながら解説します。
この記事でわかること
- ITロードマップとは何か（定義と基本構成）
- なぜITロードマップが必要なのか
- ITロードマップの具体的な作り方（7STEP）
- 作った後の運用方法
ITロードマップとはなにか？
まず、ITロードマップの定義を押さえましょう。
ITロードマップとは、事業戦略をもとに、IT方針とIT施策を時間軸で可視化したもの
もう少し噛み砕くと、「自分たちの担当領域で、なぜ・何を・いつやるのかを、戦略から施策まで一気通貫で整理した資料」です。
WBS・ガントチャートとの違い
時間軸での整理となると「それって、WBSやガントチャートと何が違うの？」と思うかもしれません。
ここは明確に区別しておきましょう。
| ITロードマップ | WBS・ガントチャート | |
|---|---|---|
| 目的 | なぜやるか・何をやるかの全体像を示す | どうやるかの詳細計画を示す |
| 粒度 | 戦略〜施策レベル | タスク〜作業レベル |
| 時間軸 | 年単位（1年〜） | 週〜月単位 |
| 対象者 | 経営層・事業部・IT企画 | プロジェクトメンバー |
| 更新頻度 | 四半期〜半期ごと | 週次〜日次 |
ITロードマップは 「Why（なぜやるか）」と「What（何をやるか）」の戦略レベルの全体像 です。一方、WBSやガントチャートは 「How（どうやるか）」の詳細な実行計画 です。
つまり、ITロードマップで方向性と施策を決めてから、個別の施策をWBSに落として実行する、という関係になります。
IT戦略との違い
もうひとつ、整理しておきたいのが「IT戦略」との違いです。
| IT戦略 | ITロードマップ | |
|---|---|---|
| 役割 | どこを目指すか・何をやるかの方向性を示す | いつ・何を・どの順で実行するかの実行計画を示す |
| スコープ | 全社・本部レベルの広めの領域 | 特定の業務領域 |
| 作り手 | スコープのマネジメント層 + IT企画 | 業務領域のIT企画 + 業務企画 |
| 粒度 | 方針・方向性レベル | 施策・タスクレベル |
| 時間軸 | 1〜2年の中期的なスパン | 年度単位（四半期ごとの施策配置） |
| 読み手 | 経営層・事業部長・下位組織の責任者 | IT企画・業務企画・プロジェクトメンバー |
| 更新頻度 | 年次（大きな方向転換時に見直し） | 四半期ごとに振り返り・アップデート |
IT戦略は「地図」、ITロードマップは「行程表」 と考えるとわかりやすいです。
IT戦略で「どの山に登るか」を決め、ITロードマップで「どのルートで・いつまでに・どう登るか」を計画するイメージです。
ITロードマップの基本構成
ITロードマップは、次の7つの要素で構成します。
| # | 構成要素 | 内容 |
|---|---|---|
| 1 | 上位の事業戦略 | 担当領域の上位にある事業戦略のサマリー |
| 2 | 担当領域のIT方針 | 事業戦略をもとに導き出すIT方針 |
| 3 | 現状分析 | 現在の業務・システムの状況整理 |
| 4 | 課題と対応方針 | IT方針を実現するうえでの課題と解決の方向性 |
| 5 | 今年度の注力領域 | 今年度に絞ったフォーカスエリア |
| 6 | 今年度の施策一覧 | 具体的な施策の一覧（タイトル・概要・優先度など） |
| 7 | ITロードマップ | 施策を時間軸に配置した一枚絵 |
上から下に向かって、抽象（戦略）から具体（施策・ロードマップ）へと段階的にブレイクダウンしていく構造です。
この後、この構成に沿って具体的な作り方を解説していきます。
なぜITロードマップが必要なのか
ITロードマップがない状態では、何が起こるでしょうか。
- 事業部から「あれやって、これやって」と場当たり的に依頼が来る
- その都度、対応可否を判断し、保守開発として個別に進める
- 年間の計画がないため、予算の確保も開発体制の構築も後手に回る
- 結果として、小さな改修はできても、大きな施策には手が出せない
実際の現場では、このような状態のチームは少なくありません。忙しくはあるけれど、戦略的にITを使えている実感がない。そんな状態です。
ITロードマップを作ることで、この状態を変えることができます。具体的には、次の3つの効果があります。
1. 戦略に沿った施策を実行できる
ITロードマップでは、上位の事業戦略からIT方針を導き、そこから施策を設計します。
この構造を作ることで、「なぜこの施策をやるのか？」に対して、戦略に紐づいた根拠を示すことができます。
逆に言うと、ロードマップがなければ、施策は「やりたいことの羅列」になりがちです。上位戦略との接続がないまま施策を進めると、「結局それって何のためにやってるの？」という問いに答えられなくなります。
2. IT投資の予算を確保できる
年間の施策計画があれば、必要な予算を事前に見積もり、経営層や上位のマネジメント層に対して計画として提示することができます。
計画がない状態では、「必要になったときに都度申請する」しかありません。これでは、まとまった予算が取りにくく、大きなプロジェクトの立ち上げも難しくなります。結果として、足元の対応しかできない状態が続いてしまいます。
3. 計画的に実行し、予実管理ができる
ロードマップがあれば、「いつまでに何をやるか」が可視化されているので、予実の管理ができます。
四半期ごとに振り返りを行い、計画と実績のギャップを確認する。必要に応じてロードマップをアップデートする。このサイクルが回ることで、場当たり的な対応から脱却し、チームとして計画的にIT施策を実行する体制が作れます。
ITロードマップの作り方
ここからは、具体的な事例をもとに、ITロードマップの作り方を7STEPで解説していきます。
前提となる事例
今回は、次のような設定で解説を進めていきます。
事例の設定
- とある営業部の業務企画担当とIT企画担当が、初めてITロードマップを作ることになった
- 担当している業務は、フロント営業の仕事（提案準備〜受注まで）
- 主に扱っているシステムは BIツール と SFDC（Salesforce）
- 営業戦略として、昨対比10%の大幅成長を狙う方針が出ている
本記事で作成するロードマップのサンプルはこちら：
では、STEP1から順に見ていきましょう。
STEP1：上位の事業戦略の確認
このSTEPでやること
・担当領域の上位にある事業戦略を確認し、サマリーとして可視化する
最初にやることは、自分たちの担当領域における上位の事業戦略を確認することです。
ITロードマップは事業戦略と紐づいていることが前提です。上位戦略を確認せずに施策を考え始めると、単なる「やりたいことリスト」になってしまいます。
今回の事例では、次のような戦略が上位から降りてきていると仮定します。
確認するポイントはシンプルです。
- 担当領域の上位にある事業戦略を確認する（課であれば部や事業部の戦略）
- 上位のIT戦略・IT方針があれば、あわせて確認しておく（担当領域のIT方針と整合を取るため）
- 可能であれば、関連部署の戦略（隣の事業部の戦略など）も拾えるとベター
- 確認した内容をサマリーとして1枚に可視化しておく
ここは自分たちで考えるパートではなく、上位の方針を正しく把握するパートです。業務企画側と一緒に「この理解で合ってるよね？」と認識を揃えながら進めましょう。
STEP2：担当領域のIT方針の検討
このSTEPでやること
・上位戦略をもとに、担当領域のIT方針を検討する
上位戦略を確認したら、次はそれをもとに自分たちの担当領域のIT方針を検討します。
IT方針とは、「上位戦略を実現するために、ITの観点で何を目指すか」を言語化したものです。全社・本部レベルのIT戦略よりも対象範囲が狭く、担当領域に絞った方向性の整理です。
今回の事例で考えてみます。上位戦略は「昨対比10%成長」「データドリブンな営業活動の推進」「提案力の強化」でした。これを受けて、IT企画と業務企画で「じゃあ自分たちの領域では、ITとしてどこを目指す？」を議論します。
ポイント：期間は1年で十分です。
一般的に3年スパンで語られることもありますが、ITのトレンドは変化が早く、中期計画のようなものは長すぎて機能しないことが多いです。
1年単位で作り、毎年アップデートする方が現実的だと思っています。作成コストも低く抑えられますし、まずは作って動き始めることの方が大切です。
STEP3：現状分析
このSTEPでやること
・IT方針を実現する前に、現状がどうなっているかを確認する
IT方針を決めたら、すぐに施策に飛びつきたくなるかもしれません。でも、その前に現状の整理が必要です。
現状分析を行う理由はシンプルです。現状がわからないと、課題の特定が曖昧になるからです。
分析の軸は戦略によって変わりますが、主に次の2つは外せません。
- 業務の現状：今の業務フローはどうなっているか？どこに非効率や課題があるか？
- システムの現状：今のシステム構成はどうなっているか？どこに制約やボトルネックがあるか？
今回の事例では、次のような現状が見えてきたとします。
ここでのポイントは、業務企画側と一緒に現状を整理することです。IT企画だけで現状分析をすると、システム寄りの視点に偏りがちです。業務の実態は業務企画の方が詳しいので、協力して進めましょう。
STEP4：課題と対応方針の検討
このSTEPでやること
・IT方針を実現するうえでの課題を洗い出し、対応方針を決める
IT方針と現状分析が揃ったら、次は課題の特定です。
考え方はシンプルで、「IT方針で目指す姿」と「現状」のギャップが課題になります。
今回の事例で見てみましょう。
IT方針では「営業データの可視化・活用基盤の強化」を掲げています。一方、現状分析では「SFDCの入力率が低い」「BIツールの活用が限定的」「データ連携が手動」という状態がわかりました。
このギャップから、次のような課題と対応方針が導き出せます。
課題を洗い出すときは、IT方針の各項目に対して「これを実現しようとしたときに、何がボトルネックになるか？」と問いかけると整理しやすいです。
対応方針は、この時点では大きな方向性でOKです。具体的な施策はSTEP6で検討します。
STEP5：今年度の注力領域の検討
このSTEPでやること
・課題と対応方針のうち、今年度どこに注力するかを絞り込む
課題と対応方針が出揃ったら、次は今年度の注力領域の絞り込みです。
すべての課題に一度に対応するのは現実的ではありません。予算もリソースも限られています。だからこそ、今年度はどこにフォーカスするかを明確にする必要があります。
今回の事例では、次のように整理したとします。
注力領域を決めるときのポイントは、施策間の依存関係を考えることです。
今回の例では、BIツールでデータを可視化するには、まずSFDCのデータ品質が上がっていないと意味がありません。だから、上期にSFDCの整備、下期にBIの活用推進、という順番にしています。
上期・下期で分けることで、「まず何から手をつけるか」が明確になります。
STEP6：今年度の施策一覧の検討
このSTEPでやること
・注力領域に基づいて、具体的な施策を一覧化する
注力領域が決まったら、いよいよ具体的な施策の検討に入ります。
施策を検討するうえでは、主に次の軸で整理していきます。
- 施策タイトル：施策の名称
- 施策概要：何をやるかの概要
- 対象システム：どのシステムに関わるか
- 優先度：高・中・低
- 対応予定時期：いつ頃対応するか
- 概算工数（人月）や概算費用：どれくらいの規模感か
施策の一覧を作成したら、課題や対応方針との整合性を確認します。課題に対応する施策が漏れていないか、逆に戦略と紐づかない施策が紛れ込んでいないかをチェックしましょう。
また、すべてをやろうとせず、予算やリソースの制約を踏まえて取捨選択することも重要です。優先度をもとに「今年度はここまでやる」というラインを引きます。
STEP7：ITロードマップへの落とし込み
このSTEPでやること
・施策一覧をもとに、時間軸に施策を配置した「一枚絵」を作成する
最後のステップです。ここまでで検討してきた施策を、時間軸に並べたロードマップ（一枚絵）に落とし込みます。
よくある形式は「矢羽（やばね）」と呼ばれる、横軸に時間・縦軸にカテゴリを取った図です。
ロードマップが完成したら、関係者（業務企画の責任者、IT企画の上長など）と合意を取ります。ここで合意を得ることで、ロードマップが「個人の計画」ではなく「チームの計画」になります。
ロードマップは完成した瞬間から「古くなる」ものです。完璧を目指しすぎず、まず作って合意を取り、動き始めることが大切です。
実体験：ITロードマップを導入して変わったこと
ここで、私自身の実体験を共有します。
Before：場当たり的な保守開発しかできなかった
私がある事業部の担当領域に着任したとき、ITロードマップは存在していませんでした。
担当システムは3つほど。IT企画と業務企画が相談しながら、その都度必要な保守開発案件を進めている状態でした。
具体的にはこんな状態です。
- 事業部から「あれ直して」「これ追加して」と場当たり的に依頼が来る
- その時に必要なものを、その都度対応する
- 上位の営業戦略とITの施策は紐づいていない
- 年度の計画がないので、予算が取りにくい
- 開発体制も組みにくい
- 結果として、大きなプロジェクトには手が出せず、小さな保守開発を繰り返す日々
忙しくはあるけれど、戦略的にITを使えている実感はまったくありませんでした。
ロードマップを導入した
そこで、私がまずやったのがITロードマップの作成でした。
事業部の戦略をもとに、中期でやるべきITと業務改善のテーマを戦略として可視化しました。そのうえで、年度の施策も具体的に引いていきました。
このプロセスは、業務企画の担当者と一緒に進めました。もともとは「業務企画からやりたいことが降りてきて、IT企画がそれを整理してベンダーに投げる」という構造でしたが、ロードマップを作る過程で関係性が変わっていきました。
After：チームとして動ける体制ができた
ロードマップを作ったことで、大きく3つの変化がありました。
-
予算と体制が組めるようになった
年間の施策計画があることで、必要な予算を事前に確保できるようになりました。開発体制も計画的に組めるようになり、今まで手が出せなかった大きなプロジェクトにも着手できるようになりました。 -
担当領域のIT化が進んだ
場当たり的な対応から脱却し、戦略に沿った施策を計画的に実行できるようになりました。結果として、今までよりも担当領域でのIT化が大きく進みました。 -
業務企画との一体感が生まれた
これが一番大きな変化かもしれません。ロードマップを一緒に作り、一緒に実行することで、IT企画と業務企画の間にチーム感が醸成されました。「IT企画に依頼する」という関係から、「一緒にロードマップに沿って進める」という関係に変わったのです。
ITロードマップは、単なる計画資料ではありません。チームの方向性を揃え、一体感を持って動くための土台にもなります。
ITロードマップの運用方法
ITロードマップは作って終わりではありません。作った後に運用し続けることが、ロードマップを機能させるために欠かせません。作ってからが本番です！
運用として行うことは、大きく2つです。
1. 定期的な振り返り
四半期ごとに振り返りを実施します。確認する内容はこんな感じです。
振り返りで確認すること
- ロードマップで予定していた施策の実行度合い（事実の確認）
- 良かったこと・改善点の洗い出し（チームで実施）
大事なのは、「できた／できなかった」の事実確認で終わらないことです。なぜできなかったのか、次にどう活かすかまでチームで議論しましょう。
施策の進捗を確認することも大事ですが、チームとして良かったところや改善点を考え共有していく中で、チームとしての一体感や団結力も高まっていきます。
2. ロードマップのアップデート
振り返りの結果や、新たに発生した課題を踏まえて、ロードマップをアップデートします。
アップデートで行うこと
- 進捗や新たな課題を反映してロードマップを修正する
- 次の四半期のアクションプランを具体化する
ロードマップは修正される前提で運用します。最初に作った計画がそのまま完遂されることはまずありません。環境は変わりますし、想定外の課題も出てきます。
大切なのは、振り返り → アップデート → 実行のサイクルを回し続けることです。このサイクルが回っている限り、ロードマップは「生きた計画」として機能し続けます。
まとめ
この記事では、ITロードマップの考え方と作り方を解説してきました。
改めて、ITロードマップの定義を振り返ります。
ITロードマップとは、事業戦略をもとに、IT方針とIT施策を時間軸で可視化したもの
ITロードマップを作ることで、
- 戦略に沿った施策を実行できる
- IT投資の予算を確保できる
- 計画的に予実管理ができる
- チームとして同じ方向を向いて動ける
という状態を作ることができます。
作り方は、次の7STEPです。
- 上位の事業戦略の確認
- 担当領域のIT方針の検討
- 現状分析
- 課題と対応方針の検討
- 今年度の注力領域の検討
- 今年度の施策一覧の検討
- ITロードマップへの落とし込み
そして、作った後は振り返りとアップデートのサイクルを回し続けること。これがITロードマップを機能させるための鍵です。
完璧なロードマップを目指す必要はありません。まずは作ってみる。そして、運用しながら改善していく。その繰り返しが、場当たり的なIT対応から戦略的なIT活用への転換を実現します。
ぜひ、現場で試してみてください！
おまけ：NGパターン
最後に、ITロードマップにまつわるNGパターンを紹介します。いずれも現場でよく見かけるものなので、当てはまっていないか確認してみてください。
NG① 作って終わりになっている
ロードマップを作成したものの、そこから更新されていない。あるいは、作成したがそのとおりに施策が進められていない。
- ロードマップが更新されないまま放置されている
- 施策がロードマップどおりに進んでいない
- 振り返りもされておらず、計画倒れになっている
実際に、部下にロードマップ作成を任せた際にこのパターンを経験しました。初めてのロードマップ作成で3か月ほど時間をかけて作成したものの、翌年度が始まってもロードマップどおりに進められない。結局、場当たり的な施策対応に戻ってしまい、ロードマップは使われなくなりました。
対策：
- ロードマップから具体的なタスクに落とし、進捗管理する
- 四半期ごとに振り返りを行い、計画と実績のギャップを確認する
- ロードマップは「使うもの」であって「飾るもの」ではない
NG② 戦略との整合性が取れていない
単にやりたいことの羅列になっているパターンです。
- 施策はあるが、上位戦略と紐づいていない
- 「なんのための施策？」と聞かれたときに答えられない
このパターンに陥ると、施策を実行しても事業成果につながらず、「IT部門は何をやっているのか」と言われかねません。
対策：
- 上位の事業戦略からIT方針を導く（STEP1→2の流れ）
- 施策を実行することで、戦略の実行がなされるという構造を作る
- 「この施策は、どの戦略に紐づいているか？」を常に確認する
NG③ 作成に時間をかけすぎている
しっかり作りたい気持ちはわかります。でも、ロードマップ作成に数か月〜半年かけてしまうのはNGです。
- いつになっても完成しない
- 完成度にこだわりすぎて、実行に移れない
- ロードマップ自体は何の成果でもない
ロードマップで考えた施策を実行することで、初めて成果が生まれます。ロードマップ作成は、あくまでも実行のための準備です。
対策：
- 作成期間をあらかじめ決める（1〜2か月が目安）
- 完成形のイメージ（スライド枚数・構成）を先に決めておく
- 内容をリッチにしすぎない
- 変更される前提で、完成度にこだわりすぎない
関連記事