【初めてのロードマップづくり】 扉：全16回の案内

　こんにちは。クオリティアーツの池田です。ソフトウェアの品質とテストを中心に、ソフトウェアエンジニアリング全般が専門です。コンサルタントとして、組織の伴走支援をしています（自己紹介）（noteホーム）。改善プロジェクトのWG主査が、3年のロードマップに向き合う。そこで何が起きるかの話です。

　12月の部の全体会から、翌年4月のキックオフまで。プロセス改善プロジェクトのWG主査を任された若手エンジニアが、3年のロードマップを一人で作り切るまでを追う、全16回の連載です。毎週金曜、主人公は一枚の紙を印刷して、先輩の席へ持っていきます。その紙が7回でどう変わったか、という話でもあります。

　この記事は、その連載「初めてのロードマップづくり。田口さんの奮闘物語。」の扉です。連載が何を扱うのか、誰が出てくるのか、どの順番で進むのかをまとめました。本編は第1回から始まります。

この記事のポイント

• ゴールが決まった計画は作れる。ゴールを自分で決める仕事は、訓練される機会が少ない。この連載が扱うのは、こちら

• 3年後を「嬉しい未来」として描き、そこへ最短でたどり着く道を引く。この2つが難しい

• 行き先は一人で書き切る。現状と手段は、聞きながら作る

1. この連載の進み方

　この連載は、プロジェクトが始まるまでの3か月を16回に分けてたどります（第1回だけは、前編と後編の2本です）。基本は1回につき、物語の1週間分です。最後に、手元に置いて使うための巻末記事が、前編・後編の2本つきます。

　公開した回は、下の一覧のリンクからたどることができます。まとめて読むときは、マガジン「初めてのロードマップづくり」からどうぞ。

• 第1回（前編）　プロローグ。12月、部の全体会。部長が語る、狙いと3年後の姿

• 第1回（後編）　プロローグ。全員でやる、という建て付け。何を渡されたのか

• 第2回　主査に任命される。「作っておいて」では終わらせない

• 第3回　1周目。作ってきたのは、作業計画書

• 第4回　2周目。それ、今の延長だよね

• 第5回　3周目。それ、どうやって確かめるの？

• 第6回　4周目。で、なんでそうなってるの？

• 第7回　1月末。部長への状況説明。まだ紙は途中のまま

• 第8回　5周目。これ、全部1年目にやるの？

• 第9回　6周目。それ、やることリストだよね

• 第10回　2月中旬。β版のレビュー会。部長が、初めて3年分の紙を見る

• 第11回　7周目。いちばん上の段が空いてるね

• 第12回　2月末。最終レビュー会と、承認。紙が終わる日

• 第13回　3月上旬。メンバーはロードマップから選ぶ。席に名前が入る

• 第14回　3月中旬。で、私は何をすれば？　1回目の説明会は伝わらなかった

• 第15回　3月下旬。その資料、進捗報告ですね

• 第16回　エピローグ。4月1日のキックオフ。作り切った先に、まだ何段もある

• まとめ前編　9つの問いで、紙はこう育った（巻末記事）

• まとめ後編　手元に置いて使う20点と道具（巻末記事）

　前半（第2回から第12回）は、田口さんがロードマップという紙を作り上げるまでです。後半（第13回から第16回）は、その紙が出来たあとの話になります。紙が良くなることと、人が動き出すことは別です。 田口さんは、ここでそれを知ることになります。

　各回の作りは同じです。場面から始まり、そこで出た指摘を解説し、また場面で閉じます。解説だけを読んでも手順を追うことができますし、場面だけを読んでも話は通ります。どちらから入っていただいてもかまいません。

　第3回から第11回までは、その回に田口さんが持っていった紙を、各回の図表1として載せています。2回目からは、前に同じ相手へ見せた紙を上に、その回の紙を下に置いて、どこが変わったかが見えるようにしました。中村さんに見せた紙（1周目から7周目）と、部長に見せた紙（第7回・第10回）は、別の列として追っています。中身は、その回の本文に書かれているものだけで起こしました。

　田口さんは、自分で調べて作ったものを毎週金曜、先輩の中村さんのところへ30分だけ持っていきます。 合わせて7回。呼ぶのも、作るのも、直すのも田口さんです。本文では、この1回を「1周目」「2周目」と数えています。

　※ この連載の作り方は、若手へイメージを伝えることを重視しています。理論や手法、手順の厳密さは重視していません。用語も、現場で通じる範囲に寄せています。厳密な定義や体系立った手順をお求めの方は、専門書や他の解説記事をご参照ください。

2. この連載の問題提起　決める仕事は、訓練されていない

　まず、この連載を書こうと思った理由をお話しします。

　エンジニアの多くは、計画を作るのが上手です。リリース日が決まっていて、作るものが決まっていれば、それを分解して、順番に並べて、日程を引くことができます。開発計画、移行計画、ツールの導入計画。どれも見事なものが出てきます。

　ところが、同じ人が3年の改善ロードマップになると、手が止まります。

　違いは、ゴールが決まっているかどうかです。

• 得意なこと：ゴールが決まっている。そこまでの道筋を分解して、日程に並べる

• 苦手なこと：ゴールを自分で決める。3年後の在りたい姿を定め、そこから現在へ逆に道筋を引く

　前者は分解の技術、後者は決める技術です。訓練される機会の量が、まるで違います。若いうちに任されるのは、たいてい前者だからです。ゴールは、上の誰かが決めてくれていました。

　もうひとつ、後者には前者にない要素が2つ入ります。

　ひとつは、3年後を「嬉しい未来」として描くことです。数値目標ではなく、そこで働く人がどうなっていたら嬉しいか。これを業務の言葉で書く習慣は、あまり持たされていません。

　もうひとつは、そこへ最短でたどり着く道を選ぶことです。やったほうがよいことは無数にあります。そのなかから、3年後の姿に効くものだけを残す。残すより、捨てるほうが難しい。

　この連載が扱うのは、この後者だけです。分解の技術は、みなさんすでにお持ちだからです。

3. 世の中の「プロジェクト」と「WG活動」

　次に、この連載の舞台になる「改善のプロジェクト」がどういうものかを整理しておきます。

　会社で「プロジェクト」と呼ばれるものには、幅があります。片方の端は、新しい製品や新しいシステムを作るプロジェクト。作るものが決まっていて、いつまでに出すかも決まっています。もう片方の端が、改善のプロジェクトです。決まっているのは「良くしていく」ことだけ。何を作るのかは決まっていません。

　WG（ワーキンググループ）は、その下に作る作業班です。組織の線をまたいで人を集め、ひとつのテーマを担当します。専任はまれで、たいていは本業との兼務です。WGのまとめ役を主査と呼びます。主査は、若手や中堅に回ってくることがあります。

　改善プロジェクトのWGには、共通の難しさがあります。よく出てくるのは、次の4つです。

• 成果物が最初から決まっていない。何を作れば終わりなのかを、自分たちで決めることになる

• メンバーに本業がある。使える時間は、週に数時間ということも珍しくない

• 効果が出るまでに時間がかかる。半年やって「で、何が良くなったの」と言われる

• 人が動くと止まる。推進役が異動しただけで、翌年には誰も覚えていない

　この4つは、どれも「3年後にどうなっているか」が決まっていないほど重くなります。逆に、決まっていれば、成果物はそこから導ける。使う時間の配分も決まる。半年後に何が出来ているかも説明できる。人が代わっても、行き先は紙に残る。

　最初に3年後を決めておくことは、この4つへの手当てでもあるのです。

4. 舞台と登場人物

　すべて架空の設定です。特定の企業・個人を指すものとしては読まないでください。

　舞台　…　業務システムのパッケージ製品を作っているIT企業の第2開発部です。下に課が3つあり、開発チームは合わせて14、約120人です。2027年4月に、この3課を横断する開発プロセス改善プロジェクトが発足し、WGが4つ立ちます。

• テスト品質強化（主査：田口さん）

• 開発プロセス標準化（主査：佐々木さん）

• 次世代エンジニア教育制度（主査：橋本さん、副主査：坂井さん）

• 開発インフラDX（主査：宮田さん）

　4人は、同じ3か月のあいだ、それぞれの紙を同時に作っています。 打ち手が重なっていないかを確かめに行く場面も出てきます。5年前にも似た活動がありましたが、推進役の異動とともに止まりました。今回は、それを部の横断プロジェクトとして立て直す形です。

　田口涼介（たぐち・りょうすけ）さん　…　入社8年目、30歳。第2課のサブリーダーで、設計とテストのあたりが持ち場です。去年はテスト管理ツールの導入を任され、作業計画書を引いて日程どおりに終わらせました。ロードマップを作るのも、WGの主査をやるのも初めてです。分からないことは自分で調べ、まず作ってから人に見せる人。

　森下隆（もりした・たかし）部長　…　第2開発部長。本文では「部長」と呼んでいます。2026年4月に着任したばかりで、2027年度から自分の方針で部を動かし始めます。その柱のひとつがこのプロジェクトです。全体会で配る資料の2枚目に、言葉の定義を一枚つけてくる人。答えを言わずに問いを返します。

　中村和彦（なかむら・かずひこ）さん　…　10年上の先輩。5年前の活動に入っていて、立ち消えになるところまで見ています。今回はWG主査に入っていません。だから、毎週30分の壁打ち相手を頼むことができました。

　そのほか　…　ここは覚えなくてけっこうです。出てきたところで、その都度ご紹介します。

• 他のWGの主査3人と、副主査の坂井さん。打ち手の重なりを確かめに行く相手です

• WGのメンバー5人（西村さん・大石さん・藤井さん・小島さん・渡辺さん）。決まるのは第13回。それまでは、まだ名前のない席です

• 社外の相談役。部長がプロジェクトの相談相手として招いている人です。WGの席ではありませんが、詰まったときに時間をもらうことができます

• 田口さんの上長の谷口第2課長と、岩田開発本部長

• 久保田さん。5年前の活動を一人で回していた人。第6回で、田口さんが話を聞きに行きます

　場面はすべて、田口さんの一人称（「僕」）で書いています。 誰が何に気づいたのかを、そのまま追ってほしいからです。場面と場面のあいだの解説は筆者（池田）の言葉で、そこでは田口さんを三人称で呼びます。

5. この連載でたどる5つの手順

　田口さんがこの3か月でたどる道を、先に示します。

1. ToBeを作る　…　3年後の嬉しい世界を描き、それを裏付けるアウトプットを決める（2周目・3周目／第4回・第5回）

2. AsIsを作る　…　今どうなっているか、なぜそうなっているかを自分で明らかにする（4周目／第6回）

3. ギャップを分析する　…　嬉しい世界との差を並べ、埋める仕事に変える（5周目／第8回）

4. バックキャストで並べる　…　3年目から逆に、年度へ割り付ける（6周目／第9回）

5. ロードマップに仕上げる　…　直近6か月を実行できる形まで落とし、3層の図にする（β版レビュー・7周目／第10回・第11回）

　この5つの前に、第2回と第3回があります。第2回は主査の任命、第3回は田口さんが手順を知らないまま最初の1週間で作ってきたものを先輩に見てもらう回です。手順1に入るのは、そこで一度差し戻されてからになります。

　WBSの出番が来るのは、手順4の回（第9回）です。第3回で田口さんが持っていくのは、WBSではなく作業計画書のほうです。WBSの出番がなくなるわけではないので、そこは安心していただければと思います。

　5つの手順の並びと、各回の対応は図表1にまとめました。

6. 行き先は一人で書く。現状は、聞きながら作る

　手順に入る前に、この連載の前提を決めておきます。3年後の姿（ToBe）は、一人で書き切ってください。 第1回に出てくる部長も、全体会で同じことを言います。

　WGのメンバーと議論しながら決めたくなると思います。そのほうが早そうに見えますし、みんなの合意も得られそうです。ところが、そうやって作ったものは最大公約数になりがちです。誰も反対しない代わりに、誰も本気にならない。3年計画の、いちばん静かな失敗のしかたです。

　高い目標を置くときは、なおさらです。会議の場で「リリース前の追い込みをゼロに」と言い出すと、ほぼ確実に「無理だ」が返ってきます。一人で書いてから持ち出せば、議論は「どうすれば届くか」に変わります。

　そもそも田口さんの場合、ロードマップを作り始める時点ではWGのメンバーがまだ決まっていません。メンバーを選ぶのは、ロードマップが出来たあとです。順番として、一人で書くしかないのです。

　一人で書き切るのは、3年後の姿までです。 そこから先は、話が変わります。現状（AsIs）は、数えるだけでは出てきません。なぜそうなっているのかは、作った人や運用している人に聞くしかない。田口さんも第6回で、5年前の活動を回していた人のところへ話を聞きに行きます。ギャップから打ち手を出すときも、他のWGに重なりを確かめに行くことになります。

　順番でいえば、行き先は一人、現状と手段は聞きながらです。この連載で「一人で作り切る」と言っているのは、前半のことだと思って読んでください。

　では、他の人は何をするのか。

• 先輩・上司・壁打ち相手：レビューを依頼する相手。指摘をもらうことはできますが、代わりに書いてはくれません。社内に頼める人がいなければ、他部署の人でも、社外の勉強会で知り合った人でもかまいません。要るのは答えを知っている人ではなく、毎週同じ時間に紙を見てくれる人です

• WGのメンバー：実行の主役。行き先を書く段階ではまだいません

• 現場の人・過去に同じことをやった人：現状と経緯を教えてくれる相手。ここは一人では埋まりません

• 他のWG：重複と依存を確かめる相手

　もうひとつ、これも決めておきます。分からない欄を空けたまま見せに行かない。空欄を見せられた相手は「そこは君が考えて」と言うほかありません。仮の答えが入っていれば、「それは違う」「その数字はどこから」と具体的な言葉が返ってきます。第3回で、田口さんは的外れなものを先輩のところへ持っていきます。それでも、空欄よりはずっとましでした。

　順番も大事です。先に自分で調べて、作る。それから見てもらう。 何をやればいいか分からない状態で相談に行くのとは違います。前者は「これでいいですか」と聞くことができますが、後者は「どうすればいいですか」と聞くほかありません。返ってくるものの質が変わります。

　※ この連載の部長と先輩は、答えを言わずに問いを返します。これは、意図してそう書いています。改善プロジェクトは人を育てる場でもあるので、レビューする側が答えを言ってしまうと、主査の手元に残るものが減ります。上司や先輩の立場でお読みの方は、そのあたりも見ていただけたらと思います。

7. この連載での言葉の決めごと

　ここは、読み物というより参照用です。いまは眺めるだけにして、本編で引っかかったときに戻ってきてください。参考にした本と資料は、まとめ後編に一覧があります。

　この連載では、次の意味で言葉を使います。第1回で部長が配る資料の2枚目にあったもので、田口さんも同じ定義で進めます。

• 「ロードマップ」：3年後までの各時点で、組織がどんな状態になっていて、何が存在しているかを時間軸の上に並べた図。作業の日程表とは区別する

• 「ToBe」：3年後に到達していたい状態。日本語では「あるべき姿」「在りたい状態」と呼ぶ

• 「AsIs」：今どうなっているか。ToBeに対応する事実だけでなく、経緯・制約・使える資産・周囲の動きまで含む

• 「ギャップ」：ToBeとAsIsの差。まだ存在しないアウトプットの一覧という形で扱う

• 「アウトプット」：ある状態が成立していることを裏付ける文書・記録・データ・動いている仕組み。大きな成果物だけでなく、議事録・メモ・テンプレート・説明資料・月次や四半期のレポート・参加報告のような小さいものも含む

• 「ケイパビリティ」：組織として、何ができるようになっているか。獲得した力。人・型・仕組み・資産のどれかに現れる

• 「バックキャスト」：3年後の姿から現在に向かって、逆向きに並べる進め方

• 「作業計画書」：やることを分解して、担当と日程に割り付けた表。行き先が決まっている仕事で使う。現場ではWBSと呼ばれることも多いのですが、別の道具です（第3回）

• 「WBS」：作るものの完成形を、階層に分けていったもの。ロードマップの1年分を実行計画に落とすときに使う。日本では「作業分解図」と訳されますが、出どころの規格 MIL-STD-881（1968年、米国防総省）はWBSを「ハードウェア、ソフトウェア、サービス、データ、施設からなる、成果物指向のファミリーツリー」と定義しています。分解の軸は作業ではなく成果物のほうです（第3回の3-2、およびWBSだけを取り上げた記事）。なお JIS Q 21500:2018 はWBSの作成の目的を「プロジェクトの目標を達成するために完了する必要のある作業を表すための、階層的分割の枠組みを提供すること」としていて、成果物から分けるとは明示していません（JIS Q 21500:2018 プロジェクトマネジメントの手引）

• 「壁打ち」：作りかけのものを先輩に見せて、意見をもらうこと。この連載では、田口さんが毎週金曜に中村さんのところへ持っていく30分を指します

• 「インクリメント」：期の終わりに増えている、動く何か。計画上の進捗ではなく、実際に使われているもの

• 「イテレーション」：期間を区切って、終わりに出来たものを出し、意見をもらって次を決める。これを繰り返す進め方の、1回分

• 「タイムボックス」：先に時間の枠を決めて、その中に入る分だけをやると決めること。中身を決めてから時間を見積もるのと、順番が逆

　※ ここに並べたのは、この部（およびこの記事）のなかでの言い方であって、一般に定まった定義ではありません。同じ言葉が、分野や文献によって、もっと広い意味でも狭い意味でも使われます。

　※ みなさんの社内で使うときは、まず自分たちの定義をそろえてください。そろえないまま議論を始めると、言葉の話で半日が消えます。

　※ 「ToBe」を「To-Be」、「AsIs」を「As-Is」と書く流儀もありますが、意味は変わりません。

次回予告

　第1回はプロローグです。2026年12月、部の全体会。新しく着任した部長が、3年後の姿と4つの柱を示します。主人公の田口さんは、まだ他人事として聞いています。

#ロードマップ #バックキャスティング #ギャップ分析 #プロセス改善 #アジャイル開発 #組織開発 #IT企業

本記事をお読みいただくにあたって

• 出典について　統計・研究・法令につきましては、一次情報で確認のうえ、出典のリンクを本文中に記載しております。ただし、誤りの可能性を完全に排除することはできません。お使いになる際は、リンク先の原典をご確認ください

• 観察と事実の区別について　現場の事例および見立ては、筆者の観察によるものであり、統計ではありません。また、特に明示していない限り、特定の企業・個人を指すものではありません

• 執筆・調査時点について　これらを確認したのは、記事公開の時点です。統計は更新され、法令は改正されますので、現時点の内容とは異なる場合があります

• 生成AIの利用について　本記事は、調査および推敲、図表作成に生成AIを利用しております

• 商標について　本文中に記載されている会社名、製品名、サービス名等は、一般に各社の商標または登録商標です。なお、本文中では ™ および ® の表示を省略しております

• 見解について　本記事の内容は筆者個人の見解であり、筆者が所属または関与する団体・企業の見解を代表するものではありません

• 免責　本記事は、筆者の調査および考察に基づく情報提供を目的としたものです。ご利用にあたっての最終的なご判断は、お読みいただく方ご自身でお願いいたします。本記事の情報を利用されたことにより生じた損害等について、筆者は責任を負いかねますので、あらかじめご了承ください