なぜ、あのPdMは「時間がない」と言わないのか？ ~元エンジニアPdMが実践する「ドキュメント化 x MCP」の全貌~​

株式会社TBC様の第4回IT大好き芸人なんでも発表会へゲストスピーカーで参加した際の登壇資料です。

「常にタスクに追われている」「口頭伝達ばかりでドキュメントがない」「仮説検証の時間が取れない」 そんな多忙なPdM（プロダクトマネージャー）がボトルネックになる状況を打破し、1人で10人分の成果を出すための実践的な手法「ドキュメント化×MCP（Model Context Protocol）」について解説しています。

人間の工学的な限界（記憶の揮発性や同期処理の遅延）を、AIとプレーンテキストを活用していかに拡張するか。株式会社PortXでの具体的な運用フローやツール構成（GitHub, Claude, v0など）を交えて紹介します。

【アジェンダ】

1. 多忙なPdMの作り方と原因
2. AIで人間の工学的な限界を拡張する取り組み
- 脳内メモリの棚卸し（Plain Text First）
- プレーンテキストを自然言語で検索可能にする（GitHub × MCP）
- 業務の全フェーズでのAI活用（Prototype as Spec）
3. 導入後の劇的な変化と実績
4. 具体的なツールとワークフロー（Claude, v0, Puppeteer, Jira等）

【こんな方におすすめ】
- 常に時間がなく、「確認します」と持ち帰ることが多いPdMの方
- ドキュメント作成や仕様調整に追われている方
- オフショア開発やリモート組織でのコミュニケーションコストに悩む方
- AIを活用して開発プロセス全体を効率化したいエンジニア・PMの方

Transcript

1. なぜ、あのPdMは「時間がない」と⾔わないのか？ ~元エンジニアPdMが実践する「ドキュメント化 x MCP」の全貌 ~ 株式会社TBC 第4回IT⼤好き芸⼈ なんでも発表会@茅場町 2025/11/29 株式会社PortX 若野 貴⼤ © PortX Inc. All Rights Reserved.
2. ⽬次 01 ⾃⼰紹介 4 02 多忙なPdMの作り⽅ 9 03 多忙なPdMの原因 20 04 AIで⼈間の⼯学的な限界を拡張する取り組み 23 © PortX Inc. All Rights Reserved.
3. ⽬次 05 結果 36 06 急な精神論 39 07 まとめ 43 © PortX Inc. All Rights Reserved.
4. ⾃⼰紹介 01
5. 数ヶ⽉前の⼀幕 © PortX Inc. All Rights Reserved.
6. toCのプロダクトのエンジニアからtoBのプロダクトのPdM(プロダクトマネージャー)に転⾝。 現在はPortXのPdMとしてオフショアxアジャイルでプロダクト開発しています。 ⾃⼰紹介 © PortX Inc. All Rights Reserved. BASE株式会社 ネットショップ作成サービスBASE クレジットカード管理 フルサイクルエンジニア エキサイト株式会社 エキサイトニュース バックエンドエンジニア Webメディア事業責任者 株式会社PortX 国際物流SaaS テックリード PdM
7. Copyright @ 2025 PortX, Inc. All Rights Reserved　|　PortX サプライチェーンの競争⼒を向上させる SaaSとAIエージェントの次世代型プラットフォーム RFQ Works Bill Trace D2Dで運賃管理‧⾒積⽐較 を実現するシステム AIを活⽤した 次世代輸送管理システム 多種多様の請求書を⼀元管理 ‧⽐較‧処理するシステム AIを活⽤した本船動静‧リス ク管理システム 「オーダー‧⽣産‧物流」各領域の情報を横断的に管理
8. 数字だけ⾒れば、まさに「順⾵満帆」な成功事例。 ⽇本の名だたる⼤企業様に導⼊いただいており、The キラキラスタートアップに⾒える！？ PortXの現在 © PortX Inc. All Rights Reserved. 会場でのみ公開
9. 多忙なPdMの作り⽅ 02
10. 売れない頃のプロダクトチームの構造 © PortX Inc. All Rights Reserved.
11. 皆さんがPdMならこの状況にどう対応しますか？ Question
12. 想定回答 © PortX Inc. All Rights Reserved. ⼀番わかりやすい解決策ですが、シンプルに売上が上がっていないスタートアップでは採 ⽤はなかなかできません。 ⼈を採⽤する 1 経営陣が聞いてくれる⼈であれば良いですが、基本は直接の声は届きません。 経営陣に直談判する 健康第⼀なので無理せずこの選択をして下さいね。 会社を辞める 2 3
13. 私の場合
14. 出典：冨樫義博『 HUNTER×HUNTER』（集英社）より引用
15. 結果
16. 出典：澤井啓夫『ボボボーボ・ボーボボ』（集英社）より引用
17. 多忙なPdMの完成 典型的な失敗例
18. PdMがボトルネックになると以下のような特徴が現ます。 皆さんの周りにこんな働き⽅になってしまっている⼈はいませんか？ 多忙なPdMとは © PortX Inc. All Rights Reserved. 1,2週間先のことに追われている 常にキャパシティの上限のタスクを抱えており、⾃ 転⾞操業状態。 ⼝頭伝達が多く資料が少ない ドキュメントを書く時間がないため、MTGやSlack での⼝頭説明で済ませてしまう。結果、後から認 識齟齬が発覚しその⽕消しでさらに追い詰められ る。 話しかけづらい 何かに常に追われている⼈はトゲトゲしたり、ひど い顔になっていることが多いです。 ⽇中は会議で埋まり定時後に作業 ステークホルダーとの調整やスクラムイベントで カレンダーが真っ黒。Deep thinkするための時間 が確保できない。 タスクがなかなか⼿離れしない 「ちょっと確認します」と⾔ったまま数⽇放置さ れたタスクが⼭積み。 仮説検証の時間がなく経験と勘に頼 る 本来やるべきユーザーインタビューやデータ分析 をスキップし、「多分こうだろう」で仕様を決 定。リリース後に全く使われない機能を⽣み出 し、その⼿戻りでさらに忙しくなる。
19. 当時はプロダクトの責任者である⾃分がこのような状態だったので、プロダクト開発もうまくいかない、採⽤するための魅 ⼒もブランディングできない、⾚字でPMFの兆しが⾒えず投資家に詰められる⽇常でした。 当時のPortXの状況 © PortX Inc. All Rights Reserved. 会場でのみ公開
20. 多忙なPdMの原因 03
21. PdMがボトルネックになると以下のような特徴が現ます。 皆さんの周りにこんな働き⽅になってしまっている⼈はいませんか？ 【再掲】多忙なPdMとは © PortX Inc. All Rights Reserved. 1,2週間先のことに追われている 常にキャパシティの上限のタスクを抱えており、⾃ 転⾞操業状態。 ⼝頭伝達が多く資料が少ない ドキュメントを書く時間がないため、MTGやSlack での⼝頭説明で済ませてしまう。結果、後から認 識齟齬が発覚しその⽕消しでさらに追い詰められ る。 話しかけづらい 何かに常に追われている⼈はトゲトゲしたり、ひど い顔になっていることが多いです。 ⽇中は会議で埋まり定時後に作業 ステークホルダーとの調整やスクラムイベントで カレンダーが真っ黒。Deep thinkするための時間 が確保できない。 タスクがなかなか⼿離れしない 「ちょっと確認します」と⾔ったまま数⽇放置さ れたタスクが⼭積み。 仮説検証ができず経験と勘に頼る 本来やるべきユーザーインタビューやデータ分析 をせず、思い込みで仕様を決定。リリース後に使わ れず何度もリニューアルを繰り返す。
22. ⼯学的な⼈間の限界 © PortX Inc. All Rights Reserved. ハードウェアの限界（Scaling Limit） ⼈間は簡単にはスケールアップ（性能向上）できない。だが、AIで拡張してスケールアウト（分 散処理）はできる 記憶の揮発性（Volatile Memory） 脳内のコンテキストは『揮発性メモリ（RAM）』。テキスト（Disk）に書き出さない限り、再起 動（翌⽇）すれば消える 同期処理の遅延（I/O Latency） 『同期的なコミュニケーション（会議‧⼝頭）』こそが、オフショア開発においては組織のス ループットを下げる最⼤のレイテンシ（遅延）要因である
23. AIで⼈間の⼯学的な限界を拡張する取り組み 04
24. 取り組みのコアの概念はシンプルです。 脳内メモリは少ないのでプレーンテキストとして常にdumpしてメモリは重要な意思決定や仕組み化のために残します。 dumpしたプレーンテキストを必要な時にAIに読み込ませて⾼速にインサイトを抽出します テキスト駆動型オペレーション © PortX Inc. All Rights Reserved. プレーンテキスト 脳内メモリのリフレッシュ AI 知識の出⼊り⼝
25. 達⼈プログラマーが取り扱う素材は⽊でも鉄でもありませ ん――知識です。 我々は要求を集めて知識とし、設計や実 装、テスト、ドキュメントの中でその知識を表現するので す。そして、知識を永続的に格納するためのフォーマットで 最も適しているのが「プレインテキスト」なのです。プレイ ンテキストを使えば⼿作業、⾃動的な作業を問わず、事実上 すべてのツールを使って思いどおりに知識を操作できるよう になるのです。 ”
26. 「体系的なドキュメント化を避けることは、組織全体に低レ ベルのカオスと混乱を植え付ける最良の⽅法である」 「ドキュメント化に真剣に取り組まない組織は、メンバーが 同じ情報を永遠に聞き返し続けるのをただ⾒守るしかない。 それは、中断、会議、そして⾮効率な知識伝達という『拷問 のようなループ（torturous loop）』を⽣み出す」 ハンドブック‧ファーストの組織は、頼るべき『唯⼀の信頼 できる情報源（Single Source of Truth）』を持つことで、超 ⾃然的なほどの効率性で運営することができる ”
27. まずは脳内やストレージに散らかった情報をプレーンテキストとしてdumpすることから始めます。 最初は⾃分の業務成果のアウトプットを全てプレーンテキストにすることから始めても良いです。 1. 脳内メモリの棚卸し © PortX Inc. All Rights Reserved. プロダクト仮説 WordやExcelで作られがち ダイアグラム系ツールで作られがち プロダクトのPRD プロダクトの仕様 商談の議事録 顧客のAsIs 運⽤ルール ロードマップ アーキテクチャ
28. 脳内にある膨⼤なコンテキスト（⽂脈‧記憶‧タスク）をプレーンテキストとして全て書き出す（ダンプす る）⾏為は、単なる「メモ書き」以上の劇的な効果をPdMにもたらします。 脳内メモリの棚卸しによる効果 © PortX Inc. All Rights Reserved. ワーキングメモリ（作業領域）を占拠する「未完了タスク」を外部へ退避 （スワップアウト）。 空いたメモリで、本来のIQと処理速度を取り戻し、 ⽬の前の判断に集中できます。 ワーキングメモリの解放によるIQの回復 「あれやらなきゃ...」という脳のバックグラウンド処理（ツァイガルニク 効果）を停⽌。 テキスト化＝処理済みと脳に誤認させることで、無駄な CPU消費を抑え、精神的な余⽩を作ります。 「ツァイガルニク効果」の無効化と精神的安定 脳内にある情報はAIには⾒えません。テキスト化して初めて、AIが参照でき る「データ」になります。 ⾃分専⽤の知識ベースを構築することで、AIが ⽂脈（コンテキスト）を理解したパートナーに進化します。 AI がアクセス可能な「外部コンテキスト」の構築 あやふやな思考をエディタというモニタに出⼒し、「客観的なオブジェク ト」として眺める。 論理の⾶躍や⽭盾といった「思考のバグ」を発⾒し、 構造化（リファクタリング）できます。 思考の客観視（オブジェクト化）と構造化
29. 2. プレーンテキストを⾃然⾔語で検索可能にする © PortX Inc. All Rights Reserved. 脳内メモリが空き、知識をディスクにdumpできたことで⾼速に業務サイクルが回り始めます。 その分「必要な情報をすぐに取り出せる」ようにしないと、結局サイクルがスタックしてしまいます。 Github Copilot MCP 検索、解析 Github データソース プレーンテキスト インサイト アウトプット
30. Github上にプレーンテキスト（Markdown等）として保存し、それをMCP（Github CopilotやClaude Desktopなど）経由で検索‧参照可能にすることには、単なる「保存」を超えた効果があります プレーンテキストを⾃然⾔語で検索可能になることの効果 © PortX Inc. All Rights Reserved. リポジトリ全体がAIの「知識」になる。 毎回⻑⽂で背景を説明しなくて も、AIが勝⼿に⽂脈を読み取り、阿吽の呼吸で指⽰が通るようになりま す。 「コンテキストの⾃動注⼊」によるゼロ‧プロンプト化 Github上のドキュメントを「正解データ」として参照させる。 AIの知った かぶり（ハルシネーション）を防ぎ、「仕様書とコードの⽭盾」をAIが指 摘できる状態を作ります。 「グラウンディング」による嘘（ハルシネーション）の排除 仕様（Text）と実装（Code）を同じ場所で管理。 エンジニアはVS Code上 で、「最新の仕様を理解したAI」の⽀援を受けながら実装できるため、⼿ 戻りが激減します。 仕様とコードの「トレーサビリティ（追跡可能性）」の確 ⽴ 仕様書もPull Request（差分）で管理。 変更履歴が残るだけでなく、AIが Diffから「影響範囲」を即座に分析し、変更リスクを可視化します。 プルリクエストによる「ドキュメントのコード化」
31. 1つ1つの業務の成果物が全てプレーンテキストとして残ります。 そうすると前の業務の成果物をインプットとしてAIが次の業務の成果物を⽣成するというループが回り始めます。 3. 業務のあらゆるフェーズでプレーンテキストとAIで成果物を作成する © PortX Inc. All Rights Reserved. 商談 仮説検証 仕様作成 実装 PRDテキストからプロトタ イプを作成し社内外で検証 プロタイプツールから仕様 書をテキストで出⼒ 商談のログテキストから PRDを作成 この段階になるとAIを常に使っていないと不安になり始めます
32. Github上にプレーンテキスト（Markdown等）として保存し、それをMCP（Github CopilotやClaude Desktopなど）経由で検索‧参照可能にすることには、単なる「保存」を超えた効果があります 業務のあらゆるフェーズでプレーンテキストとAIで成果物を作成することの効果 © PortX Inc. All Rights Reserved. 商談時の熱量や⽂脈が、そのままコードまで到達。 伝⾔ゲームによる誤解 が消え、「作ったものが顧客の要望と違う」悲劇を構造的に排除します。 情報の「蒸発」と「劣化」がゼロになる テキストが増えるほど、AI（MCP）の知識が蓄積され賢くなる。 情報の負 債化を防ぎ、開発が進むほど速度と品質が指数関数的に向上します。 コンテキストの「複利効果」が⽣まれる AIが即座にリスク指摘や修正案を提⽰。 1週間かかっていたフィードバック が「数秒」になり、1⼈の試⾏回数が劇的に増加します。 PDCAが「リアルタイム」に圧縮される PdMは情報のハブ（伝書鳩）から解放される。 AIとチームを指揮し、空い た⼿で「未来」を作る本来の役割に集中できます。 PdMが「ボトルネック」から「オーケストレーター」へ進化する
33. プロダクトディスカバリーフェーズにおける変化 仮説検証がシフトレフトし超⾼速化 ビフォアフター① © PortX Inc. All Rights Reserved. ビフォー Salesが顧客のAsIsの説明資料をPdMのた めに作成 PdMとSalesで仮説やロードマップが共有さ れていないことでPdMが常に商談に参加 顧客要望は⼀度持ち帰り、翌週以降で再 度ヒアリングの打診 これまでの仮説検証は埋もれて振り返れ なかった アフター 商談議事録からAsIs資料が⾃動作成 常に仮説やロードマップが検索可能なこと で⾃然とSalesがヒアリングをしてくれる AIプロトタイピングツールで商談時に要 望を触れる状態で再現しヒアリング 新規検証をこれまでの仮説検証と⽐べて ⽐較できる
34. 仕様作成フェーズにおける変化 プロトタイプ‧アズ‧スペックの⾃然な実践 ビフォアフター② © PortX Inc. All Rights Reserved. ビフォー 過去の資料や記憶を頼りに、PdMが⽩紙か らドキュメントを⼿書きする。「書くこ と」に時間の8割を使う エンジニアに「動き」や「状態変化」が 伝わらない 機能が増えるにつれ、過去の仕様との⽭ 盾や、エッジケース（例外処理）の記載 漏れが多発 仕様変更のたびにドキュメント更新が追 いつかず誰も読まなくなる アフター 蓄積されたコンテキスト（PRDや過去の仕 様）を元に、MCPがドラフト（叩き台）を 瞬時に⽣成。 テキストの仕様から、v0などのツール経由 で「動くプロトタイプ」を即座に⽣成。 エッジケースや整合性の網羅もAIが⾃動 で⾏う。 AIが差分を検知し、関連ドキュメントの 更新を提案するため、常に「ドキュメン トが最新の正解」であり続ける
35. 膨⼤なテキストベースの仕様書（PRD）の代わりに、「プロ トタイプ‧アズ‧スペック（Prototype as Spec）」 を採⽤す ることは、⾮常に効率的なプラクティスである 。 ⾼忠実度（High-fidelity）のプロトタイプは、ユーザー体験 や振る舞いをエンジニアに伝えるための最良の⼿段である。 しかし、プロトタイプだけではビジネスロジックやエッジ ケース（例外処理）を表現しきれない。 Caganは、プロトタ イプを補完する形で、ユースケース、ビジネスルール、受⼊ 基準などの詳細を記述することを推奨している 。ここで再び 「プレーンテキスト」の重要性が回帰する。プロトタイプ （視覚）とMarkdown等で書かれたロジック（テキスト）が セットになることで、完全な仕様となる。 ” プロトタイプ・アズ・スペック（仕様としてのプロトタイプ）
36. 結果 05
37. 運⽤イメージ © PortX Inc. All Rights Reserved.
38. 実際のPortXのカレンダー © PortX Inc. All Rights Reserved. 25年度2Q 3⽉ 4⽉ 5⽉ 6⽉ 7⽉ 8⽉ 9⽉ 10⽉ 11⽉ 12⽉ 1⽉ 2⽉ 3⽉ 4⽉ 5⽉ 6⽉ 25年 25年度3Q 25年度4Q 26年度1Q 26年度2Q 脳内メモリの棚卸し プレーンテキストを ⾃然⾔語で検索可能 にする 開発サイクルの全て のAIの導⼊ 8社と同時並⾏で商談と要件定義 展⽰会 A社商談 B社商談 C社商談 導⼊社 数1 3社導⼊決定 新規プロ ダクトリ リース 新規プロ ダクトリ リース 8社との商談の中で新 プロダクトの構想と開 発 2社導⼊決定 3社導⼊決定 顧客数やプロダクトは多忙な 頃より増えていますが、 新規プロダクトを開発できる 余裕がある開発体制になりま した
39. 急な精神論 06
40. 【再掲】⼯学的な⼈間の限界 © PortX Inc. All Rights Reserved. ハードウェアの限界（Scaling Limit） ⼈間は簡単にはスケールアップ（性能向上）できない。だが、AIで拡張してスケールアウト（分 散処理）はできる 記憶の揮発性（Volatile Memory） 脳内のコンテキストは『揮発性メモリ（RAM）』。テキスト（Disk）に書き出さない限り、再起 動（翌⽇）すれば消える 同期処理の遅延（I/O Latency） 『同期的なコミュニケーション（会議‧⼝頭）』こそが、オフショア開発においては組織のス ループットを下げる最⼤のレイテンシ（遅延）要因である
41. 時間がないと定数に対して不満に思ったり、制約を定数だと勘違いしてしまうことがあります。 時間がない時こそ個⼈の制約をAIで変数にできないかを必須に考えましょう！ プレーンテキストxAIで個⼈の制約を変数に変える © PortX Inc. All Rights Reserved. 意思決定までの「試⾏回数」 個⼈の制約 チームの定数 コミュニケーションの「伝達 ロス」 コンテキストスイッチの 「オーバーヘッド」 個⼈の「スループット（処理 能⼒）」 チームの⼈数 ステークホルダーの「多さ」 と「無茶振り」 物理的な時間と締め切り 他者の「基礎能⼒」と「学習 速度」
42. 出典：稲垣理一郎・村田雄介『アイシールド 21』（集英社）より引用
43. まとめ 07
44. Plain Text First （すべてをテキストへ） 脳内メモリを解放し、AIが参照できる「正解データ （SSOT）」を構築せよ。 Scale with MCP （ ⼈が3⼈分へ） AIをリポジトリと接続し、⽂脈を理解した「分⾝」 として並列稼働させよ。 時間がないのは個⼈のメモリ許容量のオーバーによるもの メモリ不⾜にならないように必要な知識はdumpしませんか？ まとめ © PortX Inc. All Rights Reserved. Real-time Loop （待ち時間の消滅） 「持ち帰り」を撲滅。検証‧仕様‧実装のPDCAをそ の場で完結させよ。 Be a Conductor （伝書鳩からの卒業） 情報のハブを辞め、AIとチームを指揮して「未来」 を作る時間に充てよ。
45. ご清聴ありがとうございました！