初めてPMを任されたエンジニアが、生成AIで見積もりからWBS管理まで回してみた

はじめに — この記事を書いた背景

4年目のフルスタックエンジニアです。2025年、ありがたいことにPMを任せてもらえる機会がありました。

ただ、いざ始めてみると「何から手をつければいいのかわからない」の連続でした。いままではチケットを渡されて作る側だったので、「誰が・何を・どの順番で・いつまでに」を自分で決めるという経験がなかったんですよね。

そんな中で大きく助けになったのが 生成AI（ChatGPT・Claude） でした。見積もりの考え方やプロセス設計は自分で学ぶ必要がありましたが、WBSのデータからフロー図や設計図を作る作業はAIに投げることで劇的に効率化できました。この記事では、その実践内容を共有します。

この記事の対象読者

• 10人以下の中小規模チームで開発をしている方
• PMを初めて任された、またはPMと開発を兼任している方
• スプレッドシートでWBSを作ってみたものの、うまく運用できていない方
• 見積もりが毎回外れて困っている方

大規模プロジェクトのPMBOK的な話ではなく、「少人数チームで明日から使える実践的なやり方」に絞って書きます。

Udemy講座を受けてみた

まずは体系的に学ぼうと思い、以下のUdemy講座を受講しました。

【ウェブ・アプリ開発のプロダクトマネジメントをケースで学ぶ】プロダクトマネージャー入門

参考になった点

• 1人日を何時間と設定するかの考え方
• 毎日朝会をやって同期を取ること
• 「誠実でいよう」「自分から情報を拾いに行こう」というマインド面

これらは今の自分の日々の運用にしっかり活きています。

ただ、自分の状況にはハマらなかった点もありました。

• 講座の構成が「大まかなテーマだけ決まっていて、関係各所に確認しながら要件を決めていく」フェーズが中心だった。自分の場合はモックアップや大まかな仕様がすでにある状態で、「これからどう開発を回すか」が知りたかった
• 具体的にどういうツールで進捗を管理していくかの情報がなく、「じゃあ明日から何やればいいの？」状態になった
• エンジニアとしてMermaidやGitHub Projectsを使ってどう管理するか、みたいな情報が欲しかった（これは講座選びの問題）

この記事のゴール

「読んだ翌日に管理体制を立ち上げられる」 こと。

エンジニアが使い慣れたツール（GitHub、Mermaid、スプレッドシート）と生成AIを軸に、最小限の工数で必要な管理体制を作る方法をまとめます。PM業務に工数をかけすぎて開発が止まったら本末転倒なので、「これだけやっておけば炎上を早期検知できる」くらいの粒度を目指します。

この記事では、例として「タスク管理アプリ」（ユーザー登録・ログイン・タスクのCRUD・ダッシュボード）を開発するケースを使って説明していきます。

---

1. まず機能をテキストで洗い出す

「タスク管理アプリを作ってくれ」と言われたとします。目的はわかりますが、具体的にどういう画面があって、どういう順番でユーザーが操作するのかは、誰もまとめていないことが多いです。

モックアップや仕様書がある場合でも、それは個別の画面の説明であって、「全部でどれだけの作業があるのか」は一覧になっていないことがほとんどです。

なので、まず機能を文字で洗い出すところから始めます。

1. ユーザー登録
2. ログイン
3. タスク一覧を確認できる
4. タスクを新規作成できる
  4-1. 作成したタスクを編集できる
  4-2. タスクを削除できる
5. ダッシュボードで進捗を確認できる

大したことないように見えますが、これがこの後のすべての起点になります。WBSもここから作るし、設計図もここから派生させます。

ポイントは「ユーザーが何をできるか」を動詞で書くこと。「タスク機能」みたいな名詞だと粒度が曖昧になります。

---

2. エンジニアがニガテな見積もりの技術

正直、見積もりは外れます。外れることを前提にした仕組みを作るのが大事です。

WBSを作る前にこの章を読んでおいてください。ここで説明する「1人日の定義」「個人係数」「レビューバッファ」がないと、WBSの見積列が埋められません。

1人日を何時間にするか決める

8時間フルに開発できる日はほぼありません。実際にはこんな感じで時間が消えます。

• 朝会、レビュー、質問対応、Slack対応：1〜1.5時間
• 休憩、集中力の切れ目：0.5〜1時間

なので 1人日 = 6時間 あたりが現実的かと思います。ただしこれはあくまで目安で、チームの実態に合わせて調整してください。他プロジェクトを兼任している人なら5時間かもしれないし、集中できる環境なら7時間かもしれません。

係数を設定する

メンバーごとに得意分野やそのプロジェクトの技術スタックへの慣れは異なります。全員を同じ見積もりで扱うと確実に破綻するので、経験係数を設定します。

以下は一例です。チームの実態に合わせて調整してください。

係数	対象
1.0	その技術に十分な経験がある
1.3	開発経験はあるが、この技術スタックは初めて
1.5	経験が浅く、かつこの技術も初めて
2.0	頻繁にサポートやペアプロが必要

これは「能力の評価」ではなく、「そのプロジェクトでの経験値」を数値化したものです。ベテランでも初めてのフレームワークなら1.3になりますし、若手でも経験のある技術なら1.0にできます。プロジェクト固有の係数なので、メンバーの評価とは切り離して考えてください。

レビューバッファを組み込む

見積もりが外れる最大の原因の一つが、レビュー→修正→再レビューのオーバーヘッドを計算に入れていないことでした。

タスクごとの調整後工数

調整後(h) = 見積(h) × 個人係数 × レビューバッファ(1.2)

レビューバッファはレビュー→修正→再レビューのオーバーヘッドを吸収するための係数です。目安は ×1.2 ですが、レビューの往復が多いチームなら1.3にするなど、実態に合わせてください。

【計算例】ログイン画面（見積16h）を田中さん（係数1.3）が担当する場合

調整後(h) = 16h × 1.3 × 1.2 = 25.0h
人日      = 25.0h ÷ 6h = 4.2人日
→ ログイン画面は田中さんで約4日かかる見込み

レビューの往復が多いメンバーだと、実質的には 1.5 × 1.2 = 1.8倍 になったりします。これは大げさではなく、現実的な数字です。

プロジェクト全体のバッファ

タスクごとの調整後工数に加えて、プロジェクト全体のスケジュール末尾に プロジェクトバッファを積みます（目安として ×1.15）。これは「想定外の仕様変更」「体調不良」「環境トラブル」など、個別タスクでは吸収できないリスク用です。

プロジェクト全体の見積 = Σ 調整後(h) × 1.15

【計算例】5タスクの調整後合計が102.3hの場合

バッファ込み = 102.3h × 1.15 = 117.6h（19.6人日）
→ 見積上は17.1人日だが、バッファ込みで19.6人日をスケジュールに確保する

この割合もプロジェクトの不確実性に応じて調整してください（高リスクなら20%、安定なら10%）。

---

3. WBSに落とし込む

見積もりの考え方がわかったら、洗い出した機能をタスクに分解してWBS（Work Breakdown Structure）を作ります。

スプレッドシートでWBSを作る

スプレッドシートでのWBS作成については、以下の記事がわかりやすくまとまっています。

GoogleスプレッドシートでWBSを作成する方法

この記事で紹介されているWBSテンプレートの列はこうなっています。

タスクID / タスク / 所有者 / ステータス / 開始日 / 終了日

このベースに、以下の列を追加するのがこの記事でおすすめする方法です。

追加する列	目的
機能	タスクを機能単位でグルーピングするため
依存関係	クリティカルパスを見つけるため
見積(h)	純粋な見積もり工数
係数	メンバーの経験差を見積もりに反映するため
調整後(h)	見積(h) × 係数 × レビューバッファ(1.2)。実際のスケジュールに使う現実的な工数
人日	調整後(h) ÷ 1人日の時間。スケジュールが現実的か一目で判断できる

拡張後のWBSはこうなります（1人日=6hで計算した場合）。

タスクID	機能	タスク	所有者	依存関係	見積(h)	係数	調整後(h)	人日	開始日	終了日	ステータス
A-1	認証	ログイン画面	田中	-	16	1.3	25.0	4.2	2/17	2/20	未着手
A-2	認証	ユーザー登録画面	田中	A-1	12	1.3	18.7	3.1	2/21	2/25	未着手
B-1	タスク	一覧画面	鈴木	A-1	16	1.0	19.2	3.2	2/21	2/25	未着手
B-2	タスク	作成・編集フォーム	鈴木	B-1	12	1.0	14.4	2.4	2/26	2/27	未着手
C-1	集計	ダッシュボード	田中	B-1	16	1.3	25.0	4.2	2/26	3/3	未着手

プロジェクト全体: 調整後合計 102.3h（17.1人日）→ バッファ込(×1.15) 117.6h（19.6人日）

「人日」列があると、スケジュールに無理がないかすぐに気づけます。たとえばA-1は4.2人日なのに開始日〜終了日が2日しかなかったら、それは無理なスケジュールです。

実績の工数は別列を作らなくても、実際の終了日から逆算できます。「見積3.5人日のタスクが実際は5営業日かかった」とわかれば、次回の見積もり精度を上げる材料になります。

セクション1で洗い出した機能を、「1人が1〜2日で完了できる」サイズに分解するのがポイントです。粒度が大きすぎると進捗が見えなくなり、小さすぎると管理コストが増えます。

タスクIDの付け方 — 階層型 vs フラット型

WBSのタスクIDには2つのスタイルがあります。

スタイル	例	メリット	デメリット
階層型	1.1.1, 1.1.2, 1.2.1	親子関係が一目でわかる	スプシで並び替えると構造が壊れる
フラット型	A-1, A-2, B-1	並び替え自由、シンプル	階層の深さが表現しにくい

この記事ではフラット型（A-1, B-1など）を採用しています。

• スプシで担当者やステータスでフィルター・並び替えしても構造が壊れない
• 「機能」列でグルーピングすれば、階層型と同等の整理ができる
• GitHub Issueのタイトルに[A-1]と入れやすい

階層型（1.1.1形式）は並び替えない前提のWBSに向いています。大規模プロジェクトでWBSを「設計書」として管理する場合は階層型が適切ですが、10人以下のチームで日々フィルターしながら使うなら、フラット型のほうが運用しやすいです。

---

4. WBSを視覚化する — 箇条書きだけでは伝わらない

WBSは作った。でも、ただの表のままだと2つの問題が出てきます。

• 箇条書きの表は全員にとって理解しやすいものではない。 特に非エンジニアの関係者に見せるとき、表だけだと「で、全体像は？」となる
• クリティカルパスが見えない。 どのタスクとどのタスクが並行して進められるのか、最短でどのくらいで終わるのか、表を眺めてもわからない

ここでMermaidが登場します（Mermaidについては記事末尾のコラムを参照）。

WBSのスプシデータをそのままコピペしてAI（ChatGPTやClaude）に投げると、Mermaidの図を生成してくれます。自分でMermaidの構文を覚える必要はありません。

ユーザーフロー図 + クリティカルパスの可視化

「全体のどこを作っているか」「どのタスクが遅れると全体が遅れるか」を全員が理解できるようにします。

WBSのデータをそのままAIに投げれば、画面遷移図とクリティカルパスを同時に可視化できます。

AIに投げるプロンプト例

以下のWBSデータをもとに、画面遷移図をMermaidのgraph LRで作ってください。
各ノードにタスク名と調整後工数(h)を表示してください。
依存関係を元にクリティカルパス（最長経路）を赤色で強調、それ以外はグレー破線にしてください。

タスクID	機能	タスク	担当	依存関係	見積(h)	係数	調整後(h)
A-1	認証	ログイン画面	田中	-	16	1.3	25.0
A-2	認証	ユーザー登録画面	田中	A-1	12	1.3	18.7
B-1	タスク	一覧画面	鈴木	A-1	16	1	19.2
B-2	タスク	作成・編集フォーム	鈴木	B-1	12	1	14.4
C-1	集計	ダッシュボード	田中	B-1	16	1.3	25.0

出力例

各ノードに工数が入っているので、「このタスクにどのくらいかかるか」が図を見るだけでわかります。

クリティカルパスの読み方

上の例だと、

• 経路1: A-1(25.0h) → B-1(19.2h) → B-2(14.4h) = 58.6h
• 経路2: A-1(25.0h) → A-2(18.7h) = 43.7h
• 経路3: A-1(25.0h) → B-1(19.2h) → C-1(25.0h) = 69.2h

経路3が最も長いので、これがクリティカルパスです。A-1 → B-1 → C-1のどれかが遅れると全体が遅れるということがわかります。WBSを更新するたびに同じようにコピペし直せばいいだけです。

ワイヤーフレーム付きの画面遷移図が欲しい場合
Mermaidは画像の埋め込みができないので、モックアップ付きの遷移図はFigmaやMiroで作ります。Figmaにモックがあるなら、Connectorツール（Shift+C）で矢印を引くだけ。

ユーザーストーリーマップ

機能の優先度と、スケジュールが押した時にどこを削るかの判断基準を作ります。

横軸にユーザーの行動フロー（時系列）、縦軸に優先度を並べます。上の行がMVP（絶対必要）、下に行くほど「あったらいいけど後回しOK」です。

これもWBSの機能一覧をAIに投げて整理させます。

AIに投げるプロンプト例

以下のWBSの機能一覧をユーザーストーリーマップの形式に整理してください。
横軸はユーザーの行動フロー（時系列順）、縦軸はMVP / 必要 / 後回しOKの3段階で分類してください。
Markdown表で出力してください。

タスクID	機能	タスク
A-1	認証	ログイン画面
A-2	認証	ユーザー登録画面
B-1	タスク	一覧画面
B-2	タスク	作成・編集フォーム
B-3	タスク	詳細画面
B-4	タスク	削除確認
C-1	集計	ダッシュボード

出力例

	ユーザー登録	ログイン	タスク一覧	タスク作成	タスク編集	タスク削除	ダッシュボード
MVP	メール登録	ID/PW認証	一覧表示	新規作成フォーム	編集フォーム	削除機能	件数表示
必要	入力バリデーション	ログイン状態維持	ページネーション	入力バリデーション		削除確認ダイアログ	ステータス別集計
後回しOK	SNS連携	パスワードリセット	検索・フィルター	ファイル添付	変更履歴	一括削除	グラフ表示

スケジュールが遅延した時、下の行を削ればいい。この判断が一瞬でできるのがストーリーマップの最大の価値です。AIの出力をスプレッドシートにコピペして、チームで見ながら「これは本当にMVPか？」を議論して調整してください。

---

5. WBSから設計図を作る

WBSの可視化でプロジェクト全体の見通しが立ったら、次は開発者が実装に入れるように設計図を用意します。

フロー図やストーリーマップは「WBSのデータを別の形式に整理し直した」ものでしたが、シーケンス図やER図は仕様書やWBSに書かれていないことが多いです。「この画面でどのAPIを呼ぶか」「テーブル構造はどうなるか」は、PMが設計するか開発者と一緒に決めるパートです。

ここでもWBSの機能一覧をベースにAIに投げて、たたき台を作ります。

シーケンス図（システム間連携）

「どのAPIをいつ呼ぶか」を明確にしておくためのものです。

フロントエンドとバックエンドが分かれている構成だと、「この画面でどのAPIを呼ぶの？」「レスポンスの何を画面に表示するの？」が曖昧になりがちです。シーケンス図でこれを整理しておくと、開発中の質問が激減します。

AIに投げるプロンプト例

以下のWBSの機能をもとに、タスク管理アプリのシーケンス図をMermaid記法で作成してください。
ユーザー、フロントエンド、バックエンドAPI、データベースの4者間の通信を書いてください。

機能一覧：
1. ログイン（ID/PW認証 → トークン発行）
2. タスク一覧表示（GET /tasks）
3. タスク新規作成（POST /tasks）
4. タスク編集（PUT /tasks/:id）
5. タスク削除（DELETE /tasks/:id）

出力例

この図があると、「この画面ではどのAPIを呼ぶの？」「認証が通った後のデータの流れはどうなるの？」という質問に対して「シーケンス図見て」で済みます。リクエストボディの詳細まではシーケンス図の範囲外ですが、「誰が誰に何を依頼して、結果がどう返ってくるか」の全体の流れが整理されているだけで、開発者が自分で判断できる場面が格段に増えます。

ER図（テーブル設計）

DB設計のレビューやバックエンドとの認識合わせに使えます。これもWBSの機能一覧をAIに投げて「必要なテーブルとリレーションをMermaidのER図で作って」と言えばたたき台が出てきます。

アーキテクチャ図（architecture-beta）

Mermaid v11.1.0以降で使えるarchitecture-beta記法を使うと、クラウド構成図っぽいアーキテクチャ図が書けます。cloud、database、disk、server、internetのアイコンが標準で使えます。

※ architecture-betaのラベルは現時点で日本語（非ASCII文字）を使うとsyntax errorになります（mermaid#6056）。ラベルは英語で書いてください。

これらの設計図はAIが出したたたき台をチームでレビューして修正するのが効率的です。ゼロから完璧に書こうとする必要はありません。

---

6. 日々の運用 — 最小工数で回す

PMもやりながら開発もする以上、管理に工数をかけすぎると自分の開発が止まります。最小限で回す仕組みを作りましょう。

ツールの使い分け

用途	ツール	理由
日々のタスク管理	GitHub Projects	Issue/PRと連動するので開発者が自然に触る
スケジュール・クリティカルパス	スプレッドシート	依存関係と日程の管理は表計算が一番低コスト
フロー図・シーケンス図	Mermaid	リポジトリに直接コミットできる。git diffで追える
ユーザーストーリーマップ	スプレッドシート or Miro	2次元マトリクスはスプシが楽
画面遷移図（モック付き）	Figma or Miro	画像を貼って矢印を引くだけ

全部を1つのツールで統一しようとしないでください。GitHub Projectsにクリティカルパスの機能はないし、Mermaidにユーザーストーリーマップは向いていません。それぞれ得意なことに使うのが、結局一番工数がかかりません。

WBSのタスクIDをGitHub Issueのタイトルに入れておくと、スプシとの対応が取れます。
例：[B-2] タスク作成・編集フォーム実装

朝会（15分以内）

毎日の同期は大事ですが、時間をかけすぎないこと。

各メンバーが話すこと（1人2〜3分）

1. 昨日やったこと
2. 今日やること
3. 困っていること

ルール — 困り事が出たらその場で解決方針を決める。「持ち帰って検討します」はNG。その場で方針だけ決めて、詳細は後で詰める。

これはUdemy講座で学んだマインド面の実践でもあります。「誠実に、自分から情報を拾いに行く」を朝会で体現するイメージです。

週次チェック（15分で終わらせる）

週に1回、以下を確認するだけです。

Week X:
- 予定完了タスク: A-1, A-2, B-1
- 実際完了タスク: A-1, B-1
- 遅延タスク: A-2（理由: ○○）
- 来週のリスク: C-1がB-1に依存しているため連鎖遅延の可能性
- 対応: A-2を自分が巻き取り、担当者にB-3を割り当て

WBSのメンテナンスはこの週1回のタイミングだけで十分です。毎日更新しようとすると続きません。

見積もりが外れた時の修正方法

ここが一番大事なところです。見積もりは外れるものなので、外れた後にどう修正するかの仕組みを持っておきます。

ステップ1 — 実績から係数を再計算する

WBSの終了日から実際にかかった日数がわかります。

見積: 16h × 係数1.3 × レビューバッファ1.2 = 25.0h（4.2人日）
実際: 開始2/17 → 終了2/24 = 6営業日 × 6h = 36h
→ 実質係数: 36h ÷ (16h × 1.2) = 1.875
→ 次回から係数を1.3→1.9に修正

最初の1〜2スプリントは係数がブレて当然です。実績データが溜まるにつれて精度が上がります。大事なのは**「外れたこと」を記録して次に活かす仕組み**を持っておくことです。

ステップ2 — 週次チェックで乖離を検知する

毎週、「予定完了タスク」と「実際に完了したタスク」を比較します。

Week 2:
- 予定完了: A-1, A-2, B-1
- 実際完了: A-1, B-1
- 遅延: A-2（+8h遅れ。原因: バリデーション仕様の考慮漏れ）
- 影響: C-1の開始が2日遅れる（クリティカルパスには影響なし）

ステップ3 — 乖離が大きい場合のアクション

遅延を検知したら、関係者にトレードオフを3択で提示します。

選択肢	内容	トレードオフ
a. スケジュール延伸	納期を後ろにずらす	ビジネス側の調整が必要
b. スコープカット	ストーリーマップの下の行を削る	機能が減る
c. 担当変更	クリティカルパス上のタスクを経験豊富なメンバーに移す	他のタスクが遅れる

「全部予定通りにやります」は選択肢にしません。遅れているのに精神論で乗り切ろうとすると炎上します。

変更管理

仕様変更はかならず起きます。変更自体は悪ではなく、変更を管理しないことが悪です。

変更が発生した時の手順

1. 課題管理表に記録する（何が・なぜ変わったか）
2. 影響するWBSタスクを特定する
3. 工数を再見積もりする
4. 関係者にトレードオフを3択で提示する（スケジュール延伸 / スコープカット / 人員追加）
5. 合意を取ってWBSを更新する

鉄則 — 「変更は受け入れるが、トレードオフを必ず明示する」

「追加でこの機能もお願い」と言われた時に「はい、わかりました」とだけ答えるのは危険です。「追加すると他のこれが遅れますが、どうしますか？」と必ずセットで伝えましょう。

---

振り返り — 生成AIがPM業務で効いた場面・効かなかった場面

ここまで紹介した手法を実践してみて、「AIに任せて正解だった場面」と「AIには頼れなかった場面」がはっきり分かれました。

AIに任せて正解だったこと

場面	やったこと	所感
WBS → フロー図	スプシのデータをコピペしてMermaid図を生成	手作業なら30分かかる図が1分で出る。微調整だけで済む
WBS → クリティカルパス	依存関係と工数から最長経路を計算・可視化	自分で計算するとミスしやすい部分。AIは正確
WBS → ストーリーマップ	機能一覧をMVP/必要/後回しOKに分類	たたき台としては十分。最終判断はチームで
WBS → シーケンス図・ER図	機能一覧から設計図のたたき台を生成	ゼロから書くより「AIの出力を直す」ほうが圧倒的に速い

共通しているのは、「構造化されたデータを別の形式に変換する」タスクにAIが強いということです。WBSというインプットがしっかりしていれば、アウトプットの精度も高い。逆に言えば、WBSが雑だとAIの出力も雑になるので、セクション1〜3の「人間がやるべき整理」を飛ばしてはいけません。

AIには頼れなかったこと

• 見積もりそのもの — 「このタスクは何時間かかるか」はプロジェクトの文脈やチームの実力に依存する。AIに聞いても一般論しか返ってこない
• 係数の設定 — メンバーの経験値は自分たちにしかわからない
• スコープの判断 — 「何を作って何を作らないか」はビジネス判断。AIはトレードオフの整理は手伝えるが、決めるのは人間
• 遅延時の対応 — 「スケジュール延伸 / スコープカット / 担当変更」のどれを選ぶかは、関係者との交渉が必要

つまり、「判断」と「交渉」は人間の仕事で、「変換」と「可視化」はAIの仕事。この切り分けができてからPM業務がだいぶ楽になりました。

---

まとめ — 明日やること チェックリスト

ここまで読んだ方が、明日の午前中にできることをまとめます。

• 機能をテキストで洗い出す
  • 「ユーザーが何をできるか」を動詞で箇条書きにする
• 見積もりの前提を決める
  • 1人日=6h（PM兼任なら4h）、メンバーごとの個人係数を設定
• WBSを作る
  • GoogleスプレッドシートでWBSを作成する方法のテンプレートをベースに「依存関係」「個人係数」「調整後工数」を追加
• WBSデータをAIに投げて視覚資料を生成する
  • ユーザーフロー図、クリティカルパス、ストーリーマップ
• WBSデータをAIに投げて設計図を生成する
  • シーケンス図、ER図
• GitHub Projectsをセットアップする
  • IssueテンプレートとBoard設定

完璧を目指す必要はありません。「雑でもいいから全部揃っている」ほうが、「一部だけ完璧」よりもずっと価値があります。走りながら修正していきましょう。

---

最後に、自分がPMをやっていて一番大事だと思ったことを書いておきます。

「全部予定通りにいく」と思わないこと。

見積もりは外れるし、仕様は変わるし、メンバーは詰まる。それを前提にした仕組み（係数、バッファ、週次チェック、3択提示）を持っておくことが、炎上しないための最大の保険です。

そして、仕組みを作る作業こそ生成AIが得意な領域です。WBSのデータをAIに投げてフロー図や設計図を作る。更新があったらまた投げ直す。この「コピペ→生成→微調整」のサイクルが回せるようになってから、PM業務の負荷が体感で半分くらいになりました。

同じような状況でPMをやっている方の参考になれば幸いです。

※ここまでくればスプシのアドオンとして作ってしまってもいいかもしれないですね

---

コラム — Mermaidとは

記事中で何度か出てきたMermaidについてまとめておきます。

テキストでフローチャートやシーケンス図を書けるツールです。

```mermaid
graph LR
    A[開始] --> B[処理] --> C[終了]
```

これだけで矢印付きのフロー図が描画されます。

エンジニアにとっての最大のメリット

• GitHubのMarkdownでそのまま表示される。画像ファイルを作る必要がない
• git diffで変更が追える。draw.ioやFigmaの図はバイナリなので差分が見えない
• 修正が一瞬。矢印1本追加するのにマウスでドラッグしなくていい

ブラウザで試すなら Mermaid Live Editor がおすすめです。VSCodeなら「Markdown Preview Mermaid Support」拡張機能でプレビューできます。

ちなみに、この記事で説明した通り、自分で構文を覚える必要はほぼないです。ChatGPTやClaudeにWBSデータを渡して「Mermaidのシーケンス図にして」って言えば普通に書いてくれます。出力をMermaid Live Editorに貼って微調整するのが一番早いです。

得意なもの — フローチャート、シーケンス図、ER図、アーキテクチャ図（architecture-beta）
苦手なもの — ユーザーストーリーマップ、ワイヤーフレーム付き画面遷移図（画像埋め込み不可）
注意 — architecture-betaのラベルは日本語（非ASCII文字）非対応（mermaid#6056）

Mermaidの基本構文

フロー図（graph LR）

```mermaid
graph LR
    A[画面A] --> B[画面B]
```

graph LR は「左から右へ流れるフロー図」という意味です。--> が矢印。

スタイリング（色・太さ・破線）

```
%% ノード（四角）のスタイルを変更
style ノード名 fill:背景色,stroke:枠線色,stroke-width:枠線の太さ

%% 矢印のスタイルを変更（番号は定義順で0始まり）
linkStyle 0,1,2 stroke:色,stroke-width:太さ

%% 破線にする場合
linkStyle 3 stroke:#999999,stroke-width:1px,stroke-dasharray:5
```

シーケンス図

```mermaid
sequenceDiagram
    actor User as ユーザー
    participant FE as フロントエンド
    participant API as バックエンドAPI

    User->>FE: 操作
    FE->>API: リクエスト
    API-->>FE: レスポンス
```

• ->> が実線矢印（リクエスト）、-->> が破線矢印（レスポンス）
• actor は人物アイコン、participant はシステムの箱