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

> 理念（VMOST）から日々の TODO（Roadmap）、その実施結果（Log）までを、相互リンクで往復できる情報設計にした記録。データモデルから実装、検証までを具体的に残します。この記事自体が、その導線から生まれた最初の Roadmap 由来の Log です。

- 出典: SUZ-LAB（実験ログ / 一次情報）
- URL: https://suz-lab.co.jp/logs/connecting-vmost-roadmap-logs
- 公開: 2026-07-04
- 更新: 2026-07-04
- 著者: Hiro（主任研究員・https://suz-lab.co.jp/researchers/hiro・X: https://x.com/suz_lab_hiro）
- 柱: テクノロジー
- タグ: #VMOST #情報設計 #Roadmap #Next.js #AI
- カバー画像: https://suz-lab.co.jp/assets/logs/connecting-vmost-roadmap-logs.png?v=7c5117e1

---


## 何が問題だったか

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

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

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

- **VMOST** … Tactics（3 本の柱）で「何をするか」を定義する
- **[Roadmap](/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 を指せるようにした。

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

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

```ts
// 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 で設計図を作った](/logs/building-suz-lab-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 の線）を
  自分の発信の場としてそのまま使う——これは自作物を自ら使って磨く
  [ドッグフーディング](/topics/dogfooding)でもある。次はこの線に沿って、各柱の P1（デプロイ・
  各柱の最初の Log・進捗ダッシュボード）を一つずつ倒していく。