株式会社リンクアンドモチベーションでプロダクトマネジャーをしている武田です。
リンクアンドモチベーションでは、この1年間での開発生産性を上げることを掲げ、要件定義までのリードタイムの削減に取り組みました。
結論
取り組んで大きく効果が出た施策は、主に3つになります。
①難易度を厳密に定義し、目標値を設定した。
②仮説検証の設計と要件定義の論点出しを自動化し、手戻りする回数を減らした。
③顧客インタビューを固定化し、検証までの待ち時間を減らした。
プロジェクトの進め方と当時の課題
リンクアンドモチベーションでは、新規開発を含めて約5つのプロダクトを開発しています。プロジェクトは主に、次のステップで進めています。
・課題仮説の検証：解くべき課題が「本当に存在し」「誰にとって」「どれくらい重要か」を確かめる
・ソリューション仮説の検証：その課題を解く方法として「この方向性で解ける見込みがあるか」「顧客が価値を感じるか」を確かめる
・要件定義：ユーザーストーリーや、期待する動き、条件、制約を合意できる形にする
※本記事での要件定義までのリードタイムとは、「課題仮説検証の着手」から、「要件定義書のレビュー完了」としています。
これまで、スムーズに進んだプロジェクトとそうでないプロジェクトを比較・分析したところ、課題は特に次の2点に集約されました。
課題1：仮説の精度が低く、顧客検証に着手するまで時間がかかる
仮説の精度が低いまま進めると、確認すべき点が増え、検証の設計や準備に時間がかかります。加えて、顧客インタビューの日程調整にも手間がかかり、結果として「検証に着手できるまで」の期間が長くなっていました。
課題2：要件定義では論点・選択肢の漏れが発生しやすい
要件定義の初期版に論点や選択肢の漏れがあると、レビューでの指摘が増えてしまいます。その結果、修正と再レビューが繰り返され、要件定義までのリードタイムが伸びていました。
施策① 難易度を厳密に定義し、目標値を設定した。
要件定義までのリードタイムを短くするうえで、最初に取り組んだのは目標を明確にすることでした。
これまでも「設計・実装を開始する予定日」はありましたが、プロジェクトごとの目標期間（どれくらいの期間で要件定義まで進めるか） は定められていませんでした。
目標期間はプロジェクトの難しさによって変わります。そこで、難しさを感覚で扱うのをやめ、「課題」と「解決策」それぞれの不確実性として明文化し、プロジェクトごとに「どれくらいの期間をかけるべきか」を判断できるようにしました。
具体的な定義は以下の通りです。
課題の不確実性（定義）
| レベル | 定義 |
|---|---|
| 高 | - 課題が明確ではなく、関係者間でも合意が得られていない - 理想状態から逆算して課題の特定が必要 - 既存の業務の流れ（ワークフロー）が存在していない - 関連データや情報が不足し、現状把握が困難 |
| 中 | - おおよその課題の当たりがついている - 関係者間でも合意形成が可能 - 既存データや情報をある程度活用すれば把握できる - 営業にも納品にも一定数、影響しうる |
| 低 | - 課題は明確で、関係者間の認識も一致している - 関連データや情報収集が容易にできる - すでに業務の流れや手順が明確に存在している - 営業か納品のどちらか一方にのみ影響 |
解決策の不確実性（定義）
| レベル | 定義 |
|---|---|
| 高 | - 解決策がアイデアとしてあるだけで、顧客の反応がまだない - 社内で過去に提供したことがないものを提供しようとしている（手法・技術） - 全事業部やデザイン部門を横断して合意形成が必要 |
| 中 | - 開発範囲（スコープ）が不明確で、定義から必要 - 自サービス以外の他システムへの影響がある - 複数事業部間で合意形成が必要 |
| 低 | - 開発範囲がある程度明確 - すでに使用されている技術を使う前提 - 1つの事業部との合意形成で十分 |
この難易度の考え方は、pmconf2022 のセッションを参考にしました。
https://2022.pmconf.jp/session/uJJsTy36
この難易度の組み合わせによって、課題仮説の検証／ソリューション仮説の検証／要件定義それぞれに対して、難易度に応じた目標期間を設定しました。
また、難易度が明確になったことで、単に「期間を決める」だけでなく、各PMにとって必要な経験や支援を踏まえて、適切なアサインを検討しやすくなる効果も生まれました。
施策② 仮説検証の設計と要件定義の論点出しを自動化し、手戻りする回数を減らした。
要件定義までが長引く典型パターンの一つは、初期版の「仮説」や「要件を決めるための論点」が不十分で、レビューで指摘→修正→再レビューを繰り返してしまうことです。この領域は人によるばらつきが出やすく、特に初期アウトプットの漏れが手戻りを増やしていました。
そこで、一次作成（たたき台作り）を生成AIを用いて自動化し、論点漏れと作成時間を減らしました。
具体的には、以下の4つのツールを作成しました。
1.課題仮説の検証設計（課題仮説検証用）
2.ソリューション仮説の検証設計（ソリューション仮説検証用）
3.顧客インタビュー設計（検証の具体的設計書）
4.要件定義の初期版作成と論点出し
ツールの構成は、誰でも迷わず使えるように極力シンプルにしました。入力は、初期の課題仮説・ソリューション仮説、あるいは他3つのツールのアウトプットをそのまま貼り付ける形式です。これにより、整理のための作業を増やさず、同じ流れで検証から要件定義までつなげられるようにしました。
また、プロダクトごとの前提情報として、以下をあらかじめ取り込んでいます。
- ターゲットユーザー
- 提供価値
- 主要機能
- 用語の説明（社内用語・機能名など）
- 過去の要件定義書 など
この前提情報をもとに、検証設計や要件定義のたたき台を出力させています。
たとえば「課題仮説の検証設計」ツールでは、次のようなアウトプットを返すようにしました。
- 具体的なターゲットの整理
- 課題の詳細化
- その課題に対して現在行われている代替手段
- 課題が存在するかの確認方法
- 確認の基準（何が言えれば「課題がある」と判断できるか）
プロダクトの前提情報をあらかじめ持たせることで、検証設計の精度が上がり、初期アウトプットのばらつきを抑えられました。その結果、論点漏れに起因するレビュー指摘と手戻りを減らしやすくなりました。
施策③ 顧客インタビューを固定化し、検証までの待ち時間を減らした。
他のボトルネックになっていたのは、顧客ヒアリングに行ける状態になるまでの準備と調整に時間がかかることでした。そこで、案件ごとに都度日程調整をする運用をやめ、毎週実施するインタビュー枠を先に固定しました。
運用は次の通りです。
-
毎週、固定の顧客とのインタビュー枠を確保
「必要になったら調整する」から「常に実施する」へ切り替えました。 -
同席者を固定
PMに加えてデザイナー・エンジニアも同席し、検証の場で解釈のズレを減らすようにしました。 -
対象顧客の決め方を固定
「課題がありうるターゲット」を起点に、カスタマーサクセス（CS）チームと相談しながら候補顧客を決める運用にしました。
今後に向けて
生成AIも活用したことで、一次アウトプットは効率化できましたが、最終的に「良い／悪い」を判断するのは人になります。判断の質を上げるためにも、PMには顧客業務や顧客課題に関するドメイン知識を積極的に増やし、仮説や要件の妥当性をより精度高く見極められることが求められます。
また今回の改善は、初期仮説がある程度ある前提で、検証〜要件定義までのリードタイムを短縮した取り組みでした。プロダクトマネジャーとして本質的に価値が出るのは「そもそも何の課題を解くべきか」を見極め、解くべき順番を決めることです。単なる業務効率化ではなく、プロダクトの価値向上が増えたかを来年は追っていきたいと思います。