😺

AIがプロジェクトドキュメントを書く世界を目指して

Nanami Sannohe

2025/08/15に公開

project

idea

 はじめに：PMとして避けて通れなかった"あの仕事"こんにちは。Finatextで日々プロジェクトマネージャーとして働いている三戸です。

プロジェクトマネージャーという仕事柄、「ドキュメントを作るのも、整えるのも、最終的にはPMの責任」という状況に何度も直面してきました。

要件定義書、基本設計書、WBS、受入テスト項目リスト…いわゆる”顧客向けに見せるドキュメント”の数々です。


ドキュメント成果物の壁
私自身も「完璧な仕様書」を書けるタイプではありませんが、前職では公共案件に携わっていたこともあり、300ページを超えるエビデンス付きの提案書作成やその印刷、毎週と毎月の報告資料作成という修行を経て、ドキュメント作成に対しての苦手意識だけはありませんでした。
一方で、メンバーの中にはドキュメント作成やその意義に懐疑的な人も多く、ドキュメントを作る暇があるのであれば、その分の時間でコードを書け、テストを書け、という文化があるのも事実です。

しかし、顧客案件では納品物として定められたドキュメントをきちんと作成し、納品する必要があります。（そういう契約を結んでいますので！）

適当なドキュメントを納品してしまうと、後で自分たちのクビを絞めることにもなりかねないので、とりあえずPMが必死になってドキュメントを作る/作ってもらうという状況でした。

 allmightの構想：資料と概要から“プロジェクト全体像”を立ち上げるSlackに限らず、案件の概要資料、ヒアリング議事録、RFPなど、ドキュメントの素材になる情報はすでにプロジェクト開始前から揃っていることも少なくありません。

にもかかわらず、それらを整理し、形に起こすという作業は属人化しやすく、時間もかかります。
「すでにある素材を渡すだけで、必要なドキュメントの“たたき台”が出てくれば、どれだけ楽だろうか？」
そう考えて開発したのが、**プロジェクトドキュメント一括生成ツール「allmight」**です。
名前の由来は、「いつでもどこでも見守ってくれる"全能の味方"でありたい」という思いから。

（某有名ヒーローに少し影響を受けたのは否定しません…!）
allmightは、案件の目的や背景、顧客資料、Slack上でのメンバー間のやり取りなどを読み込み、以下のようなアウトプットを自動生成します：
プロジェクト基本構成（目的、体制、スコープ）
要件定義書（機能・非機能・前提条件）
見積工数案とスケジュール
提案資料構成案


allmightの概念図
例えば、顧客から以下のような素材を受け取ったとします：
案件の背景や目的が書かれたPDF（RFPや提案依頼書）
参考URLやベンチマークサービスのメモ
ヒアリング議事録や営業が事前にすり合わせた内容
それらに過去の類似案件で使ったWBSや見積フォーマットなどをallmightに読み込ませると、次のようなアウトプットが自動生成されます：

 生成されるドキュメント例（抜粋）プロジェクト基本情報

•	案件名、背景、目的、スコープ

•	関係者一覧（社内・顧客・ベンダー）

•	想定体制と役割分担（RACI表）
要件定義ドラフト

•	機能要件（大分類・小分類ごと）

•	非機能要件（セキュリティ、運用体制、SLAなど）

•	前提条件・リスク
スケジュール案・マイルストーン

•	要件定義〜設計〜開発〜テスト〜リリースまでの初期工程表

•	依存関係とバッファの可視化

•	顧客レビュータイミング案
工数見積もり

•	WBSベースでの工程別工数（例：要件定義5人日、設計10人日…）

•	ざっくり人月換算とフェーズ別コスト感

•	補足：過去案件との比較コメント（←これが地味に嬉しい）
提案資料の構成素案

•	スライド構成案（目的→現状課題→提案概要→スケジュール→体制→費用）

•	セクションごとの説明文ドラフト


allmightのデモ動画の切り抜き：簡単な質問に答えていくことでドキュメント作成のためのプロンプトが作成されていく

 なぜ今、“ドキュメントを書く意味”を見直す必要があるのか？プロジェクト初期──特に案件を受けた直後に必要なのは、「とりあえず全体像をつくる」ことです。

しかし、それは同時にPMのスキルと経験が最も問われる工程でもあります。
問題は、これができる人が社内にあまりいないこと。

そして、「そもそもドキュメントを書く文化がない」というチームも存在することです。
でも今はもう2025年。

AIの進化によって、テキストとしての仕様書は“AIの入口”になりつつあります。
整った要件定義書から、AIがコードのドラフトを起こす
テスト観点が明記されていれば、自動でE2Eテストを生成できる
機能一覧とスケジュール案があれば、提案資料も作れてしまう
つまり、仕様書は「人に読ませるもの」から「AIに働かせるための鍵」へと変化しているのだと考えました！

 allmightが生成するドキュメント：最初の一歩を“ひと塊”でallmightが目指したのは、完璧な成果物ではなく、「まず全体像を描くための土台づくり」です。

顧客資料、議事録、Slack上のディスカッションをもとに、プロジェクトの構造や要件を提案してくれます。

 書けない人でも、“始められるようにする”仕組みを私自身は顧客案件を中心に担当することが多く、「どんなドキュメントが必要か」「どの粒度まで書くべきか」がある程度は頭に入っています。

けれど、社内の別チームー特にプロダクト開発や新規事業のメンバーの中には、そもそも「納品物としてドキュメントを整える文化」そのものに触れたことがない人も少なくありません。
だからこそ、allmightの出力は、「こうやってまとめればよいんだ」という道しるべとしても機能します。
「こういう視点でまとめると、顧客との認識齟齬を防げるんだな」

「このスケジュール構成って、実は根拠があるんだな」
そんな気付きのきっかけになるツールでもあって欲しい。そう思って作りました。

 PMだけじゃない。プロジェクトに関わるすべての人のためにallmightはPM専用のツールではありません。

むしろ「誰かが頭の中で処理していたこと」をチーム全体に共有するための橋渡し役です。
エンジニアが仕様の背景を理解するために
営業やCSが顧客に説明するための共通言語として
プロジェクトメンバーが、全体像を把握するための足がかりに
チーム全体が“同じ地図”を見て進むための補助線として、活用されることを目指しています。

 sidekickという“従姉妹”の存在最終的には、allmightで作成されたドキュメントを起点に：
スケジュールに沿って進捗をSlackで通知したり
発生した変更を仕様書に反映したり
といったPMO業務全体を支えるツールsidekickとの連携を構想しています。

AIに任せきりではなく、「PMが考えるべきことに集中できる環境をつくる」ためのツール群です。

 さいごにAIは、あなたの代わりに仕事をする存在じゃありません。

あなたの“言語化されなかった仕事”を、そっと引き出してくれるチームの一員、そんな風に考えています。
今はまだ未熟かもしれません。けれど、allmightが描き出すドキュメントの地図と、Slackで動き続けるsidekickのレポートがあれば、プロジェクトに関わるあなたの仕事は、もっと自然に、もっと人に集中できる形で進められるはずです。


一緒に働こう
私はエンジニアではないため、直接コードを書くことは出来ません。

それでも、今回のallmightの開発においては、次のような視点で関わりました。
何をドキュメントとして抜けなく、ブレなく、表現するべきかの設定
どの順序でどういったインプットを元にアウトプットとなるドキュメントを作るべきか（ドキュメント同士の依存関係の整理など）
出力文書の粒度や文体、フォーマットの調整（受け手が読みやすいようにするには？）
特に重要だったのが、「誰が、いつ、どんな文脈でこのドキュメントを使うのか」という読み手視点。

そして、AIは超しっかりした成果物を最初から容赦なく作ってくれるため、正直人間がそれらを読むのは大変であり、人間側のテキスト情報を読むチカラが今後は求められていくんだなぁと思いました。