📝

要件認識はズレが出る。だからユーザーマニュアル駆動開発を。

Mizuhiro Kio

2025/12/11に公開

この記事は「Hacobell Developers Advent Calendar」ー 11日目の記事です。
こんにちは。ハコベルでプロダクトマネージャーをしている黄王（キオウ）です。
みなさん、こんな経験はありませんか？

要件定義書をしっかり書き、開発も順調に進んだ。ところがリリース直前のレビューでCSチームから「え、この動きだと現場で使えないです」と指摘される。急いで修正するものの、リリースは延期。さらに悪いことに、リリース後も「聞いてた仕様と違う」という顧客問い合わせが来て、緊急修正対応に追われる…。
この記事ではそんな状況に悩まされたチームがどのように問題を乗り越えたかを紹介します。

 なぜ認識齟齬が起きるのか
 口頭説明には限界がある当初はミーティングで要件書をもとに実際の画面を見せながらすり合わせをしていました。しかし、ステークホルダー全員に対して毎回行うには時間がかかりすぎるため、一部のメンバーとしかすり合わせができず、「あとはドキュメントを見ておいてください」と伝えることになっていました。

 ドキュメントは開発者目線で書かれている

要件定義書の例
主に「見ておいてください」で共有されるドキュメントとは要件定義書（Product Backlog Item）です。開発チームが実装するために必要な情報を過不足なく書くことを目指したもので、技術的な仕様や制約条件、エッジケースの扱いまで詳細に記述します。これをCSや営業が読み解いて仕様を理解することは容易ではありません。

 結果として起きていたこと

耳がいたい問い合わせ
読みづらいドキュメントでは十分に伝わりきらず、リリース間近の最終チェックで「この機能、こういう使い方を想定していたんですが…」という指摘が入るようになりました。修正が必要になり、リリースが延期されるたり、場合によってはリリース後にも「聞いていた仕様と違う」という問い合わせが来て、緊急修正対応に追われることが発生しました。

 ユーザーマニュアルを先に作ろう

振り返りボードの様子
チーム振り返りで対策を議論し、「ユーザーマニュアルを要件定義段階から作ってすり合わせる」という手段を取りました。
これはAmazonの「プレスリリースドリブン開発」から着想を得たものです。

Amazonでは新機能を開発する際、まず顧客向けのプレスリリースを書くことから始めるようです。プレスリリース草稿を通して顧客目線でどんな価値が提供されるべきかを明確にすることができます。
https://forbesjapan.com/articles/detail/38145
同じように、ユーザーマニュアルも「ユーザーがどう使うか」を具体的に記述する必要があります。これを要件定義段階から作れば、CS・営業・開発が同じ完成イメージを持てるのではないかと考えました。


実際のマニュアルの例
私の担当プロダクトでは、リリース時に必ずユーザー向けのマニュアルを整備しています。これはかなり網羅的で、機能の概要から具体的な操作手順、トラブルシューティングまで含まれています。
これを要件定義段階から作って、CS・営業とすり合わせに使えばどうなるか？認識齟齬を防ぎ、そのままユーザーマニュアルとして流用でき、二重管理の手間もなくなるので一石三鳥のはずです。

 AIでマニュアルを自動生成しようマニュアル駆動開発を決めた上で、1つ作成するのに1時間以上かかる作業を要件定義段階で毎回やるのは現実的ではありません。
そこで、Notion AIを使った自動生成の仕組みを作りました。
まず、トラック簿のマニュアルの特徴を分析し、Notion上にルールとして定義しました。


実際のルール例
このルールをNotionページに保存し、要件定義書（PBI）と一緒にNotion AIに読み込ませます。


読み込んでもらう。ちなみにNotion AIのカスタマイズはアヒルがお気に入りです。
成果物を加筆修正し、所用時間は5〜10分程度。従来の1時間から約90%削減できました。

 具体的にどう運用しているか現在の開発プロセスは以下のようになっています：

要件概要の作成：WHY/WHATレベルで要件概要を作る

CS・営業との相談：初期段階で方向性をすり合わせる

リファインメント：要件定義書に詳細を落とし込む

マニュアル生成：Notion AIでユーザーマニュアルを自動生成

CS・営業と確認：マニュアルをベースにすり合わせる

齟齬チェック：考慮漏れやブラッシュアップがないか確認

プランニング以降：開発・QA・リリース
ポイントは、
マニュアルをなるべく早い段階で共有してフィードバックをもらうことで不確定要素を早期に潰すこと
初期段階では用途を要件すり合わせに限定し、細かな言い回しなどの調整はリリース段階に回すこと

 みんなハッピーになったよ
 手戻りがほぼゼロに認識齟齬による手戻りはほぼゼロになりました。マニュアルという具体的な「完成イメージ」を共有することで、CSも営業も開発も、同じゴールを見ながら進められるようになりました。
リリース間近での「え、そういう仕様じゃなかった」も、リリース後の緊急修正対応も、この原因では発生しなくなりました。

 工数削減しながら品質向上マニュアル作成工数は約90%削減されました。営業チームも、顧客への説明資料としてマニュアルを活用できるようになりました。

 そのままユーザーに渡せるすり合わせに使ったマニュアルは、ユーザーが実際に困るポイントや疑問に思うポイントが既に反映されているので、最小限の加筆修正でそのままユーザーに提供できます。

 まとめユーザーマニュアルを要件定義段階から作ることで、認識齟齬を防ぎ、手戻りをなくせました。それだけでなく、別途発生していたマニュアル作成工数もこの取り組みで削減することができました。Notion AIを使えばPdMの工数も増加せずに対応することが可能です。
みなさんのチームも、同様の問題に悩まされている場合はぜひお試しください。