複数課題が混ぜこぜで、HOWだけが書かれていたPRD　要件定義の工数を50パーセント減・手戻りゼロにした改善策

植木氏の自己紹介、株式会社ラクスの紹介

植木遼太氏：では発表を始めます。「ARR100億SaaSの現実～新設PdM組織が、PRD品質向上のため泥臭く越境した2つのこと～」というテーマで発表します。よろしくお願いします。

まず簡単に自己紹介と会社の紹介だけさせてください。私は植木遼太と申します。現在、株式会社ラクスというところで、「楽楽精算」という経費精算SaaSのプロダクトマネージャーをしています。

経歴としては、新卒はインフラエンジニアからキャリアをスタートして、その後にプロジェクトマネージャー、プロダクトマネージャーと役割を変えていったかたちになります。

次に、簡単に会社紹介です。弊社は楽楽精算だったり「楽楽明細」といったバックオフィス系のSaaSサービスと、あとはメール関連のフロントオフィス系のサービスを展開している企業となります。

（スライドを示して）こちらはIRの抜粋になります。今回は一番上のオレンジ色の部分ですね。この楽楽精算についての話をしたいと思っています。

PRDを見た時に納得できなかったこと、ありませんか？

では、本題にいきます。突然ですが、ご視聴してくださっているみなさまの中でも、PRD（Product Requirements Document）を見た時に「あれ？　これちょっと納得感がないなぁ」とか、作成する側でも「どうも納得感を醸成できないなぁ」ということがあったりしないでしょうか？　私自身は正直けっこうあるあるかなと思っていて、実際に楽楽精算でもこのような状況が起きていました。

今回は、その楽楽精算でどういう課題があって、どう対応して、どういう成果が出たのかのケースシェアリングをさせてもらえればと思っています。

課題が混ぜこぜで、HOWだけが書かれていたPRD

では、実際に起きていた開発課題です。PdMの組織ができたのが2021年程度になるんですが、その時に起きていたのが、HOWだけが書いてあるPRDが開発に渡されて、そこからいろいろと提供元のほうにヒアリングしていくと、いろいろな課題が混ぜこぜの状態で書いてあるような状態になっていました。

これの何が困るのかというと、HOWだけだと顧客の事実情報が薄いというか、ほぼない状態になるので。「本当にこれって解決すべき課題なんだっけ？」「この解決策でいいんだっけ？」というところがよくわからないし、もっといいものが考えられるという材料が、そもそもない状態になってしまう。

また、複数課題が混ぜこぜだと、同時開発ができないものがあったり、1つの案件がめちゃくちゃボリュームが大きくなっちゃうということが起きます。

実際に楽楽精算内では、開発の要件定義担当の方がこれを整理して調整していました。（スライドを示して）そうすると、書いてあるとおり、開発着手がどんどん遅れて、最終的にお客さまへの価値提供もどんどん遅れるという状況が生まれてしまいます。

なぜこんなPRDになってしまっていたのか

これが起きてしまっていた背景ですが、もともと楽楽精算には元エンジニアの事業本部長と発足時からいるフルスタックのリーダーエンジニアがいて、ここが密に連携を取ってPRDを作っていました。

ですが、後に売上や人員が伸びたことで企画部門と開発要件定義担当というそれぞれの役割ができて、ここでPRDをやり取りするというように変わっていきました。

以前の2人と何が違うのかというと、企画部門のほうはエンジニアリング経験が薄かったり、開発要件定義担当のほうは、発足時からいる人よりは仕様の詳細理解が薄いというところがあるんですが、一番違うのは顧客解像度が揃っていないというところでした。

なので、以前のようなコミュニケーションではPRDを作れない状態なんですが、（それにもかかわらず）前任者と同じようなアウトプットのレベルで作成してしまっていたという背景です。

全体で合意した対応方針

では、これに対してどういう対応策を取ったかというと、まずはこの間を取り持つというかたちでPdMという役割ができました。このタイミングで私も私の上長も同じタイミングで入社しました。

（スライドを示して）そこで、先ほどの状態の再掲にはなるんですが、HOWオンリーのPRDと、複数課題が混ぜこぜの状態を要件定義担当が整理している中で、関係者にヒアリングをしに回りました。

その結果、全体で合意した対応方針としては、「本来PRDに必要な情報って何だっけ？」というところをちゃんと見直しましょうという話と、「必要になった情報って、誰が計画して、収集して、分析して、アウトプットするのかを今一度見直ししましょう」という方針を立てました。

（スライドを示して）具体的にはこの2つです。「プロダクト4階層を用いてPRDに必要な要素をちゃんと定義しましょう」ということと、「DACI（Driver、Approver、 Contributors 、Informed）というフレームワークを使って役割分担をしましょう」というものです。

プロダクト4階層を用いてPRDに必要な要素を定義する

1個目のプロダクト4階層を用いた必要な要素です。このセッションを視聴している方は既知の方が多いかなと思うんですが、『プロダクトマネジメントのすべて　事業戦略・IT開発・UXデザイン・マーケティングからチーム・組織運営まで』から抜粋している4階層の資料になります。

楽楽精算としては、この中のWhyとWhatの部分ですね。これがPRDの中にきっちり書かれていることが必須な要素だと定義しました。この中に「MRD」と書かれている要求仕様があるんですが、これも最終的にはPRDにマージするかたちになっています。

「これは必要だね」ってなったところで、「特にWhyの、誰をどんな状態にしたいのかというところは、お客さまにちゃんと調査が必要だよね。じゃあどうやって調査をするんだっけ？」というところを検討しました。

（スライドを示して）書かれているような実際の調査計画のアジェンダを作成して、関係者で内容をどんどん埋めていく。かつ合意をしていくというようなことをやっていきました。

その調査した結果を踏まえて、「PRDのアジェンダってこうだよね」と定義しました。最初は誰の、どんな課題を、どのように行動変容して、アウトカムに導くのか。実際の業務フローはどうなるのか、（顧客に）どう見えるのかという画面のラフ図。あとは「ROIはちゃんとあるんだよね」というところと、「成功の指標ってどう取るんだっけ？」というところをちゃんと書くというかたちで定義しています。