技術ロードマップの例：プラットフォームチームのための Now、Next、Later の計画

技術ロードマップの失敗の仕方は、たいてい 2 つのどちらかです。誰も信じていない日付が並び、四半期ごとに描き直されるガントチャート。あるいは、タイトルを付けただけのバックログのエクスポート。どちらも、あなたに依存しているチームに、いま何が起きていて、次に何が来て、何がまだ決まっていないのかを伝えません。

プラットフォームチームは、ほかのチームよりも難しい立場にあります。期限は、Kubernetes や PostgreSQL のバージョンのサポート終了のように、他者が決めることがよくあります。顧客はほかのエンジニアリングチームで、それぞれに要望があります。そして仕事には、何か月も「ほぼ完了」のままの長い移行がつきものです。

この記事では、プラットフォームチームの技術ロードマップを Now、Next、Later（今、次、後で）の形式で作り、この形式の由来と技術的な仕事に向いている理由を説明し、ロードマップを正直に保つための運用方法を紹介します。

なぜ Now、Next、Later なのか

この形式は ProdPad から生まれました。共同創業者の Janna Bastow は The Birth of the Modern Roadmap の中で、2012 年の終わりごろに共同創業者の Simon Cast が紙ナプキンに Current、Near term、Future の 3 列を描いたいきさつを語っています。列は時間軸であり、その背後にある考え方は確実性でした。最初の列の仕事は明確で近く、最後の列の仕事は範囲があいまいです。彼らはこれを Now-Next-Later ロードマップとして ProdPad に組み込みました。

列が表すのは確実性であり、カレンダーの四半期ではありません。項目が左へ移るのは、四半期が終わったときではなく、確約できるだけのことが分かったときです。

技術ロードマップならではの点

外部の期限。 運用しているソフトウェアにはサポート期間があり、その期間が仕事の順番を決めます。Kubernetes プロジェクトは最新の 3 つのマイナーリリースを保守しており、それぞれに約 1 年のパッチサポートがあります。そのためアップグレードは一度きりのプロジェクトではなく、ロードマップに繰り返し現れる項目です。また kubeadm クラスターではマイナーバージョンを飛ばすアップグレードがサポートされていないので、1.35 から 1.37 へ上げるにはアップグレードが 2 回必要です。PostgreSQL は各メジャーバージョンを 5 年間サポートし、その後に最後のマイナーリリースが出て、そのバージョンはサポート終了となります。

社内の顧客。 ストリームアラインドチームは、プラットフォームが何を提供するかを前提に計画を立てます。何が確約済みで何がそうでないかを知る必要があり、列はまさにそれを示します。

長いしっぽ。 90 % 終わった移行でも、古いバージョンにデータベースやサービスが残っています。進捗は日付ではなく、移行が残っているものとして示しましょう。

依存関係。 プラットフォームの仕事は、別のプラットフォームの仕事の上に成り立つことがよくあります。トレーシングを組み込んだサービステンプレートは、トレーシングが動くまでリリースできません。

プロジェクトではなく成果を書く

各項目は、誰もが完了を判断できるよう、目指す結果として書きます。

項目の説明には指標を加えます。トレースをエクスポートしているサービス数、サポート対象バージョンのクラスター数、まだバージョン 15 のデータベース数などです。

例：プラットフォームチームのロードマップ

この例は 2026 年 10 月時点のものなので、期限は Kubernetes と PostgreSQL のリリースページに載っている実際の日付です。

• Now。 OpenTelemetry の展開である Traces everywhere は 3 分の 1 ほど完了していますが、エンジニアがもう 1 人必要なためリスクがあります。Kubernetes 1.37 は進行中です。Kubernetes 1.35 は 2027 年 2 月 28 日にサポート終了を迎え、それは Next の期間に入るので、アップグレードはいま行う必要があります。
• Next。 CI/CD、トレーシング、ダッシュボードを組み込んだサービステンプレートである Golden path は、トレーシングを待っています。Off PostgreSQL 15 は、2027 年 11 月 11 日のバージョン 15 のサポート終了より前に、pg_upgrade でバージョン 18 へメジャーアップグレードするものです。
• Later。 探るべき課題が 2 つあります。チームごとのクラウドコストを見えるようにすることと、チェックアウトがリージョン障害を乗り越えられるようにすることです。どちらにもまだ担当者も解決策もありません。

図の読み方は次のとおりです。

• 列は四半期ではなく確実性。 左から右へ、仕事は確約済み、可能性が高い、まだ決まっていない、の順に並びます。
• 各カードは成果です。 担当者、ステータス、進捗バーがあります。Later の項目にはまだ担当者がいません。計画ではなく課題だからです。
• 依存関係のバッジ は、トレーシングが Golden path をブロックしていることを示します。テンプレートはトレーシングを有効にした状態で提供されるからです。
• マイルストーンは外部の期限です。 該当する列に置きます。Kubernetes 1.35 のサポートは Next の間に終わるので、そのアップグレードは Now にあります。PostgreSQL 15 のサポートは Later で終わるので、そのアップグレードは Next で始め、長いしっぽのための時間を残します。
• ステータスのバッジ がリスクを説明しています。トレーシングには人手が必要です。

運用の仕方

• 決まったリズムで見直します。 たとえば 2 週間ごとに、サービスを提供しているチームのリードと一緒に行います。項目を動かすのは見直しのときだけにして、ロードマップが人々の足元で勝手に変わらないようにします。
• Now は小さく保ちます。 チームが人員を割けるものだけを入れます。何か新しいものが Now に入るなら、何かが出ていきます。
• Later から Next へ移すのは具体化できたものだけです。 課題の記述、完了の基準、担当者、おおよその規模がそろっていることが条件です。
• 日付は外部の期限にだけ使います。 社内の見積もりは、ロードマップ上の約束としてではなく、項目の説明に幅を持たせて書きます。
• 完了した項目は一度だけ示します。 次の見直しで示したら、アーカイブします。ロードマップはこれから先のことを扱うものです。
• 項目を詳細にリンクします。 設計ドキュメント、移行の進捗管理、アーキテクチャ図などです。CI/CD パイプライン図と Kubernetes アーキテクチャ図の記事で、そうした図の例を紹介しています。

よくある間違い

• 日付付きの機能一覧。 日付がずれるまで不確実性が隠れ、ずれたときに全員が一斉に知ることになります。
• すべてが Now。 10 個の項目が進行中なら、実際にはどれも進んでいません。
• 担当者がいない。 Now や Next にある担当者のいない項目は、ただの願望です。
• 隠れた依存関係。 ある項目が別の項目を必要とするなら、それを描きましょう。そうしないと、後の項目が始まってから止まってしまいます。
• 急を要するときにだけ現れるアップグレード。 依存しているすべてのサポート期間を、そのバージョンを採用した日にマイルストーンとしてロードマップに載せましょう。
• 誰も見ないロードマップ。 人がふだん仕事をしている場所に置き、古くなるスクリーンショットを貼るのではなく、ドキュメントに埋め込みましょう。

Archboard で作る

1. Google または GitHub でサインインし、図を作成するか、Now / Next / Later ロードマップのテンプレートから始めます。
2. ロードマップパックから 3 つの 四半期 フレームを追加し、Now、Next、Later と名前を付けます。
3. 成果ごとに エピック を追加し、タイトル、担当者、ステータス、進捗を設定します。
4. 外部の期限ごとに、日付を入れた マイルストーン を該当する列に追加します。
5. 一方が他方をブロックしている 2 つのエピックの間に 依存関係 のバッジを追加し、破線のエッジでつなぎます。
6. リスクには ステータス のバッジを、各列のルールには基本パックの メモ を追加します。

この例で使うダイアグラムノードは 13 個で、Free プランの範囲に収まります。

よくある質問

技術ロードマップとプロダクトロードマップの違いは何ですか？ プロダクトロードマップは、顧客が何を手にするかを扱います。技術ロードマップは、それを可能にする機能基盤、アップグレード、移行を扱い、その顧客はたいていほかのエンジニアリングチームです。形式は同じでかまいません。

技術ロードマップに日付は必要ですか？ 日付が実在する場合だけです。サポート終了、契約、規制などです。それ以外はすべて確実性の列に入れます。

Later はどこまで先を扱うべきですか？ 決まった期間はありません。Later は課題を置く場所なので、どの項目も次の見直しで議論する価値があるくらいに短く保ちましょう。

長い移行の進捗はどう示せばよいですか？ クラスター、サービス、データベースなど、移行が残っているものを数え、見直しのたびにその数を更新します。数のない割合は、長いしっぽを隠してしまいます。

プラットフォームのロードマップは誰が見るべきですか？ プラットフォームに依存しているすべての人です。サービスを提供しているチームと共有し、そのリードと一緒に見直しましょう。そうすれば、確約済みのものを前提に計画を立てられます。

無料で始める — 1 シート、クレジットカード不要。