2024.10.01
自社の社内情報を未来の“ゴミ”にしないための備え 「情報量が多すぎる」時代がもたらす課題とは?
ARR100億SaaSの現実 ~新設PdM組織が、PRD品質向上のため泥臭く越境した2つのこと~(全1記事)
リンクをコピー
記事をブックマーク
植木遼太氏:では発表を始めます。「ARR100億SaaSの現実 ~新設PdM組織が、PRD品質向上のため泥臭く越境した2つのこと~」というテーマで発表します。よろしくお願いします。
まず簡単に自己紹介と会社の紹介だけさせてください。私は植木遼太と申します。現在、株式会社ラクスというところで、「楽楽精算」という経費精算SaaSのプロダクトマネージャーをしています。
経歴としては、新卒はインフラエンジニアからキャリアをスタートして、その後にプロジェクトマネージャー、プロダクトマネージャーと役割を変えていったかたちになります。
次に、簡単に会社紹介です。弊社は楽楽精算だったり「楽楽明細」といったバックオフィス系のSaaSサービスと、あとはメール関連のフロントオフィス系のサービスを展開している企業となります。
(スライドを示して)こちらはIRの抜粋になります。今回は一番上のオレンジ色の部分ですね。この楽楽精算についての話をしたいと思っています。
では、本題にいきます。突然ですが、ご視聴してくださっているみなさまの中でも、PRD(Product Requirements Document)を見た時に「あれ? これちょっと納得感がないなぁ」とか、作成する側でも「どうも納得感を醸成できないなぁ」ということがあったりしないでしょうか? 私自身は正直けっこうあるあるかなと思っていて、実際に楽楽精算でもこのような状況が起きていました。
今回は、その楽楽精算でどういう課題があって、どう対応して、どういう成果が出たのかのケースシェアリングをさせてもらえればと思っています。
では、実際に起きていた開発課題です。PdMの組織ができたのが2021年程度になるんですが、その時に起きていたのが、HOWだけが書いてあるPRDが開発に渡されて、そこからいろいろと提供元のほうにヒアリングしていくと、いろいろな課題が混ぜこぜの状態で書いてあるような状態になっていました。
これの何が困るのかというと、HOWだけだと顧客の事実情報が薄いというか、ほぼない状態になるので。「本当にこれって解決すべき課題なんだっけ?」「この解決策でいいんだっけ?」というところがよくわからないし、もっといいものが考えられるという材料が、そもそもない状態になってしまう。
また、複数課題が混ぜこぜだと、同時開発ができないものがあったり、1つの案件がめちゃくちゃボリュームが大きくなっちゃうということが起きます。
実際に楽楽精算内では、開発の要件定義担当の方がこれを整理して調整していました。(スライドを示して)そうすると、書いてあるとおり、開発着手がどんどん遅れて、最終的にお客さまへの価値提供もどんどん遅れるという状況が生まれてしまいます。
これが起きてしまっていた背景ですが、もともと楽楽精算には元エンジニアの事業本部長と発足時からいるフルスタックのリーダーエンジニアがいて、ここが密に連携を取ってPRDを作っていました。
ですが、後に売上や人員が伸びたことで企画部門と開発要件定義担当というそれぞれの役割ができて、ここでPRDをやり取りするというように変わっていきました。
以前の2人と何が違うのかというと、企画部門のほうはエンジニアリング経験が薄かったり、開発要件定義担当のほうは、発足時からいる人よりは仕様の詳細理解が薄いというところがあるんですが、一番違うのは顧客解像度が揃っていないというところでした。
なので、以前のようなコミュニケーションではPRDを作れない状態なんですが、(それにもかかわらず)前任者と同じようなアウトプットのレベルで作成してしまっていたという背景です。
では、これに対してどういう対応策を取ったかというと、まずはこの間を取り持つというかたちでPdMという役割ができました。このタイミングで私も私の上長も同じタイミングで入社しました。
(スライドを示して)そこで、先ほどの状態の再掲にはなるんですが、HOWオンリーのPRDと、複数課題が混ぜこぜの状態を要件定義担当が整理している中で、関係者にヒアリングをしに回りました。
その結果、全体で合意した対応方針としては、「本来PRDに必要な情報って何だっけ?」というところをちゃんと見直しましょうという話と、「必要になった情報って、誰が計画して、収集して、分析して、アウトプットするのかを今一度見直ししましょう」という方針を立てました。
(スライドを示して)具体的にはこの2つです。「プロダクト4階層を用いてPRDに必要な要素をちゃんと定義しましょう」ということと、「DACI(Driver、Approver、 Contributors 、Informed)というフレームワークを使って役割分担をしましょう」というものです。
1個目のプロダクト4階層を用いた必要な要素です。このセッションを視聴している方は既知の方が多いかなと思うんですが、『プロダクトマネジメントのすべて 事業戦略・IT開発・UXデザイン・マーケティングからチーム・組織運営まで』から抜粋している4階層の資料になります。
楽楽精算としては、この中のWhyとWhatの部分ですね。これがPRDの中にきっちり書かれていることが必須な要素だと定義しました。この中に「MRD」と書かれている要求仕様があるんですが、これも最終的にはPRDにマージするかたちになっています。
「これは必要だね」ってなったところで、「特にWhyの、誰をどんな状態にしたいのかというところは、お客さまにちゃんと調査が必要だよね。じゃあどうやって調査をするんだっけ?」というところを検討しました。
(スライドを示して)書かれているような実際の調査計画のアジェンダを作成して、関係者で内容をどんどん埋めていく。かつ合意をしていくというようなことをやっていきました。
その調査した結果を踏まえて、「PRDのアジェンダってこうだよね」と定義しました。最初は誰の、どんな課題を、どのように行動変容して、アウトカムに導くのか。実際の業務フローはどうなるのか、(顧客に)どう見えるのかという画面のラフ図。あとは「ROIはちゃんとあるんだよね」というところと、「成功の指標ってどう取るんだっけ?」というところをちゃんと書くというかたちで定義しています。
次に、DACIを用いた役割分担の話です。これも既知の方が多いかなと思うので簡単に説明すると、DはDriverの推進者、責任者ですね。Aが承認者、CがDに対して貢献する人、Iが報告を受ける人という定義です。
(スライドを示して)これをどうはめていったかというと、これは実際のDACI表の一部なんですが、Outputと工程に紐づけてそれぞれDACIを埋めていくというかたちを取りました。
ここで気をつけたのが、書籍とか、いろいろなWebページから得られる理想形と、実際の今の楽楽精算のリソースとスキルセットを鑑みて、「現実ラインはどこなんだっけ?」というところをちゃんと考えるようにしました。
では、実際にやってみた効果です。先ほど課題として詰まっていた要件定義のフェーズも工数を50パーセント削減できて、かつ現状は手戻りゼロにできました。
2番目は定性的にはなるんですが、各組織が「本来ここが得意だよね」という役割に集中できるようなかたちになりました。
3つ目に、これはかなり副次的な要素ではあるんですが、PdMの採用応募数が300パーセント増えました。DACIで決めたことによって、ジョブディスクリプションが明確化したことによって、採用の応募数が増えたと考えています。
以上です。これで発表を終わります。ご清聴ありがとうございました。
2024.10.29
5〜10万円の低単価案件の受注をやめたら労働生産性が劇的に向上 相見積もり案件には提案書を出さないことで見えた“意外な効果”
2024.10.24
パワポ資料の「手戻り」が多すぎる問題の解消法 資料作成のプロが語る、修正の無限ループから抜け出す4つのコツ
2024.10.28
スキル重視の採用を続けた結果、早期離職が増え社員が1人に… 下半期の退職者ゼロを達成した「関係の質」向上の取り組み
2024.10.22
気づかぬうちに評価を下げる「ダメな口癖」3選 デキる人はやっている、上司の指摘に対する上手な返し方
2024.10.24
リスクを取らない人が多い日本は、むしろ稼ぐチャンス? 日本のGDP4位転落の今、個人に必要なマインドとは
2024.10.23
「初任給40万円時代」が、比較的早いうちにやってくる? これから淘汰される会社・生き残る会社の分かれ目
2024.10.23
「どうしてもあなたから買いたい」と言われる営業になるには 『無敗営業』著者が教える、納得感を高める商談の進め方
2024.10.28
“力を抜くこと”がリーダーにとって重要な理由 「人間の達人」タモリさんから学んだ自然体の大切さ
2024.10.29
「テスラの何がすごいのか」がわからない学生たち 起業率2年連続日本一の大学で「Appleのフレームワーク」を教えるわけ
2024.10.30
職場にいる「困った部下」への対処法 上司・部下間で生まれる“常識のズレ”を解消するには