VMOST → Roadmap → Log を一本の線でつないだ

何が問題だったか

VMOST で設計図は描いた。VMOST ページに Vision / Mission / Objectives / Strategy / Tactics が並び、VMOST とは にはフレームワークの解説もある。だが肝心の 「Tactics（何をするか）」と、実際に手を動かす日々のタスク、そしてやってみた結果の記録が、 サイトの上で分断されていた。

これでは framework が説く T→V の検算——日々の行動が上位の目的に本当に効いているかの 確認——が回らない。Tactics は立派に書いてあるのに、そこから「今週やること」へ降りる道も、 「やってみてどうだったか」へ昇る道もなかった。いわゆる 偽りの生産性（忙しいが上位に 紐づかない状態）を、サイトの構造そのものが誘発しかねない。

そこで 3 つを一本の線に並べ、しかも 往復できるようにした。

• VMOST … Tactics（3 本の柱）で「何をするか」を定義する
• Roadmap … Tactics を期限付き・実行可能な TODO に落とす
• Log（このページ）… TODO を実施した結果を一次情報として残す

設計 — 何を「つなぎ目」にするか

つなぎ目を人手のリンクで書くと必ずドリフトする。そこで id を唯一のつなぎ目にした。

• Roadmap の各 TODO に安定した id（例 connect-flow, deploy-domain）を持たせる。
• Roadmap の柱グループの key を Tactics の柱の key と一致させる （technology / education / discipline）。これで Tactics ↔ Roadmap が 文字列一致だけで突き合わせられる。
• Log は frontmatter の roadmap: にその TODO の id を書くだけで、 「この記事はどの TODO の結果か」を宣言する。

つまり 柱の key と TODO の id の 2 つのキーだけで、3 ページが機械的につながる。

やってみたこと

1. Roadmap ページを新設

3 本の柱と同じ区分で TODO をグループ化し、各 TODO に「効くところ」（どの行動原則・ Objective に紐づくか）と、優先度（P1〜P3）・状態（未着手／進行中／完了）を添えた。 文言は content/roadmap.ts を唯一の出所にし、色やラベルはコンポーネント側で key から 解決する（このリポジトリの「文言はデザインに混ぜない」方針）。

ページ冒頭には VMOST → Roadmap → Log の 3 ステップ導線を置き、 「どこが起点で、どこに結果が残るか」を最初に示す。

2. Tactics（トップ）から降りる道

トップの各柱カードに「この柱の Roadmap」リンクを足し、/roadmap#{柱key} へ飛ばす。 グループ key を柱 key と一致させてあるので、リンク先は自動でその柱の TODO 群になる。 Tactics セクションの末尾には、Roadmap 全体への CTA も置いた。

3. Log ↔ TODO の相互リンク

ここが今回の肝。frontmatter に roadmap: を足し、実施した TODO の id を指せるようにした。

---
title: "..."
pillar: "technology"
roadmap: "connect-flow"   # ← この記事が由来する TODO の id
---

読み取り層（lib/logs.ts）に逆引きを実装した。全 Log を走査し、roadmap を持つものを TODO id ごとにまとめる。存在しない id を指す Log は（誤記防止のため）マップに含めない。

// TODO id → その実施結果の Log（新しい順）
export function getLogsByRoadmapId(): Map<string, LogMeta[]> { /* ... */ }
// ある Log が実施した TODO 群（無ければ空配列。1 本の Log が複数の TODO を倒すこともある）
export function roadmapOriginsOf(log: LogFrontmatter) { /* ... */ }

後日追記: roadmap: は 1 本の Log で複数の TODO を倒したときのために配列でも書ける （例: roadmap: ["deploy", "deploy-domain"]）。逆引きも「Log が由来する TODO」も複数前提にした。

これで両方向がつながった。

• Roadmap 側は各 TODO の下に「実施 Log」への順リンクを出す（結果 → 記録）。
• Log 側は記事冒頭に「Roadmap の実施 Log」カードを出し、由来する TODO へ戻す （記録 → TODO）。
• 一覧では、Roadmap 由来の記事に「Roadmap より」バッジを付ける。

4. Log の 2 つの由来を明示

これで Log には 2 種類の由来ができた。

1. Roadmap 由来 — 線の上で TODO を実施した結果として書くもの（この記事がそう）。
2. 自主記録 — 線の外で、日々の気づきをその都度残すもの （最初の記事「VMOST で設計図を作った」は、 Roadmap より前の話なのでこちら）。

一覧の冒頭でこの違いを説明し、由来のあるものには印を付けた。どちらも一次情報として 対等に扱い、無理にすべてを TODO 起点にはしない——線の外の発見も、そのまま残す価値がある。

検証

コンテンツもコードも、壊れていないことを機械的に確かめた。

• pnpm typecheck / pnpm lint … 型・Lint ともにパス。
• pnpm build … /roadmap と両方の Log が静的生成されることを確認。
• 生成 HTML を grep し、双方向リンクが実際に描画されていることを確認 （Roadmap の connect-flow にこの記事へのリンク、この記事に /roadmap#connect-flow への戻りリンク、一覧の「Roadmap より」バッジ、 トップの /roadmap#technology リンク）。

学び

• 情報設計を「理念 → 計画 → 記録」の一方向ではなく、往復できる双方向にすると、 「やったこと」が必ず上位の意図に紐づき、迷子のタスクが生まれにくい。VMOST の検算が サイトの構造として常時働く。
• つなぎ目を id という 1 つの事実に寄せると、リンクの二重管理が消える。 柱 key と TODO id さえ合っていれば、ページをまたいだ導線が自動で成立する。
• この記事自体が connect-flow という TODO の実施 Log。まず、やってみるの実演として、 仕組みを作ったその足で最初の一本を残した。作った仕組み（VMOST → Roadmap → Log の線）を 自分の発信の場としてそのまま使う——これは自作物を自ら使って磨く ドッグフーディングでもある。次はこの線に沿って、各柱の P1（デプロイ・ 各柱の最初の Log・進捗ダッシュボード）を一つずつ倒していく。