2024.10.10
将来は卵1パックの価格が2倍に? 多くの日本人が知らない世界の新潮流、「動物福祉」とは
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.11.13
週3日働いて年収2,000万稼ぐ元印刷屋のおじさん 好きなことだけして楽に稼ぐ3つのパターン
2024.11.11
自分の「本質的な才能」が見つかる一番簡単な質問 他者から「すごい」と思われても意外と気づかないのが才能
2024.11.13
“退職者が出た時の会社の対応”を従業員は見ている 離職防止策の前に見つめ直したい、部下との向き合い方
2024.11.12
自分の人生にプラスに働く「イライラ」は才能 自分の強みや才能につながる“良いイライラ”を見分けるポイント
2023.03.21
民間宇宙開発で高まる「飛行機とロケットの衝突」の危機...どうやって回避する?
2024.11.11
気づいたら借金、倒産して身ぐるみを剥がされる経営者 起業に「立派な動機」を求められる恐ろしさ
2024.11.11
「退職代行」を使われた管理職の本音と葛藤 メディアで話題、利用者が右肩上がり…企業が置かれている現状とは
2024.11.18
20名の会社でGoogleの採用を真似するのはもったいない 人手不足の時代における「脱能力主義」のヒント
2024.11.12
先週まで元気だったのに、突然辞める「びっくり退職」 退職代行サービスの影響も?上司と部下の“すれ違い”が起きる原因
2024.11.14
よってたかってハイリスクのビジネスモデルに仕立て上げるステークホルダー 「社会的理由」が求められる時代の起業戦略