なぜわずか2週間で開発中止を決断したのか？　ラクスの駆け出しPdMが経験したしくじり先生

ラクスの駆け出しPdMの失敗談

松浦孝治氏（以下、松浦）：それでは「開発を止めるという選択〜かけだしPdMの失敗談〜」という内容で発表させていただきます。よろしくお願いします。

まず簡単に自己紹介です。私は松浦孝治と申します。弊社の製品である「楽楽明細」の製品開発リーダーを主にやっていまして、2020年度ぐらいからPdMの見習いというかたちでPdMも始めている状況です。

ラクスに入ってから丸2年ぐらいになるんですけど、前職はメーカー系のSIerでPM、PLを中心にやっていました。

とにかく楽しく仕事することを大切にしています。ケジメをつけて仕事する感じで、あまりピリピリし過ぎずというか、いい感じでというか、そんな感じで仕事を日々平常心でやっていきたい思いがあります。

最近ラクスでも、緊急事態宣言もあってリモートワークが中心になってきていまして、かなり運動不足になってくるので、近くに海が……近くないんですけど、がんばって歩きに行っています。

まず、私の担当している「楽楽明細」というシステムの紹介をさせてください。「楽楽明細」は帳票発行業務を自動化してくれるクラウド型のシステムになります。帳票を発行したい側が、左側にある「御社」と書かれているところです。

楽楽明細を直接契約する方が帳票データをアップロードすると楽楽明細で帳票の作成、発行を統合して顧客に届けます。

Webやメール、郵送、Faxなど、さまざまな方法で送ってくれるシステムになります。ここまでが前置きになります。

プロダクトマネジメントの役割とは？

松浦：本日のお題は、プロダクトマネジメントの失敗談がエピソードになるんですけど、その前にみなさまにいったん質問をさせてください。

PdM、プロダクトマネジメントの役割と言われて、まず何を想像しますか？　こちらはZoomでもけっこうですのでコメントをいただければと思います。

選択肢Aは、顧客に価値を届ける人。選択肢Bは中長期的なロードマップを作る人。選択肢Cは具体的な開発アイテムの優先順位を決める人ですね。

続々と回答が返ってきていますね。これに限った話じゃなくても構わないんですけど。

藤澤貴之氏（以下、藤澤）：松浦さん、これは複数回答ありですか？

松浦：複数回答はありですね。

藤澤：A、A、A、B、C……。

松浦：Aが多いですね。みなさまありがとうございます。やはり予想していた通りですね。僕も結論から言うと実は選択肢の全部が役割だと思っているんですけど、PdMはスライドに書いてあるだけでも多種多様な役割があるなと思ってます。

ですので、PdMと言われると戸惑っちゃうこともあるんですけど、ラクス的にやりやすいようにというか、開発の中でそのPdMと言われている位置付けを定めているので、そちらを次に説明させていただきます。

ラクスの中でのPdMの役割は、事業部が立案した製品戦略をもとに、開発速度の向上を図ることです。ラクスでは開発とは別に、営業やCSなどを担当する部署がありまして、そちらを事業部と呼んでおります。事業部の特性上、お客さまと接点を持ちやすいので、その部署が基本的に製品戦略を立てています。

開発はその製品戦略を正しく速く理解することによって、開発速度の向上を図るかたちを目指しています。その具体例が下に書いてあるんですけど、体制は商材ごとに異なっていて、具体的なアクションもそれぞれ異なっています。

「楽楽明細」での役割分担

松浦：私の担当している楽楽明細の役割をお話しさせていただきます。今日はこれから本題でお話しする話の中にも出てくるんですけど、楽楽明細のプロダクトは主にこの3人で決めています。

サービス立ち上げ当初からの事業部長、CSリーダーの方が顧客の声との接点が多いので、顧客の市場調査やニーズ分析、製品企画というかたちで兼務をして、その開発アイテムが開発に降りてくるのが基本的な流れになります。

僕が入社した時は、顧客の分析やニーズ分析などにあまり開発が入っていなくて、事業部長やCSリーダーに思っていることを伝えてもらってなんとか開発していたんですけど、だんだんニーズが増えてきたこともあって齟齬が多くなってきました。

そんなわけで、今私はPdMとして、開発アイテムを発案した人と開発をする人を正しくつなぐ役割を主にやっています。そのために必要な領域として、彼らと同じ目線を持たなきゃいけないので、顧客・市場調査やニーズ分析、製品企画に領域を拡大していっています。

なぜ2週間で開発中止になったのか

その中で開発中に起きた僕の失敗談をお話させていただければと思います。今日の話は開発着手後、2週間で中止になった話です。実際の機能開発にあったエピソードなんですけど、製品戦略を含む具体的な内容は一部伏せさせていただくことをご了承いただければと思います。

まずは事件の始まりです。事業部長と会議で機能開発リストの議論をしていました。ラクスでは具体的な顧客からの要望をベースに開発する機能は、実際に売り上げが見込めるかどうか、分析を少ししてから開発アイテムの候補を選定していくかたちで進めています。

昔、僕が入る前から「楽楽明細の次期開発として、ある機能を開発してほしい」と欲しているお客さまがいて、「営業時に（それがないことで）失注するケースもあって、明確に販売増が見込めるんだよ」と言われました。僕的には「非常に大変そうだな」と思いました。一定数の要望があることもわかっていたので、「やるしかないのかな」と思っていたところです。

この時の僕のプロダクトマネジメントの思いとしてはWhatとWhyですかね。その開発アイテムをなぜやるのか、なぜやるのか、何をするべきなのかは確認していました。あとはWhen、いつを納期にしてリリースをしないといけないのかに、気が行っていたなと思います。

2週間で開発チームから悲鳴が上がる

松浦：ここから3ヶ月後、「開発着手前に具体的に顧客に提案したい」「現在提案中の企業が○○機能をぜひ使いたい」と言われました。「顧客には具体的な機能の保証をしないんですけど、機能がある前提でいったん提案をしたいです」という話を受けました。

僕もこの3ヶ月後は実は当初とあまり考えは変わっていなくて、開発がぜんぜん空かなかった時期でした。基本的には現案件が終わり次第、優先度を高くして対応することと、かなり大きい工数があることを見込んではいたんですけど、「総動員でがんばります」みたいな感じで話をしていました。なので、「ここはWhenの話だな」と気にしていた感じです。

実際にそのあとに開発に着手することになるんですけど、2週間後には周りから悲鳴がかなり上がることになります。

開発チームからは、詳細を検討していったら、全機能の8割ぐらいのSQLに手を入れないといけない。その機能があることで今後も工数がかかる。こういった意見が上がってきました。

開発部長からは「かなりのリスクがある機能で、お客さんの設定が原因で意図せぬ動作をしても責任を問われる可能性もあるので、他の商材ではやらないよ」と言われました。僕もみんなの悲鳴に驚かされたんですけど、絵の通り、僕はかなり小さくなっておりました。

ある程度辛いということはわかったんですけど、想像以上になっていました。小さくなってばかりもいられないので、悲鳴から2日後にみなさんから言われた意見を真摯に受け止めて、中止の提案を持ち掛けることになりました。

幸い、事業部長にもその内容を理解していただいて、商材の中長期視点を考えたら開発すべきことではないとなり、すんなり中止という選択を取ってもらいました。

結果的には営業部側の巧みなプレーで失注とはならなかったんですけど、提案中の顧客や事業部長を始めとした営業メンバーには、かなりの迷惑をかけたなと思っています。

PdMはいかにして開発中止を招いたのか

松浦：かなりツッコミたくてうずうずしている方も多いかなとは思うんですけれども、ここで僕の何が悪かったのかを振り返っていきたいと思います。

まず1個目ですね。受け身の姿勢があるかなと思っています。僕も完全に前職の癖というところもあったんですけど、「お客さまから言われたものは絶対」みたいな意識を持っていました。なので開発を中止する選択肢がそもそも頭の中になくて、顧客が必要だからやると考えていました。意識の問題ですね。

2番目は着手優先順位です。顧客に提案してから中止になるまで時間が経っていたので、今開発している機能とのバランスなどが取れていなかったと思っています。もっと早く中止をしていたら、関係者には迷惑をかけなかったのかなと思っています。

3番目はコスパ意識です。目先の利益ばかりに目が行っていました。コストと利益を引いてみたら、（開発を進めても）いいんじゃないかと思ったんですけど、そこまで意識が回らなかったと思います。

最後、4番目として中長期的な視点です。我々はSaaSというサービスを提供しているので、プロダクトはずっと続いていきます。なので、将来の開発に足かせになる事項は慎重にやればよかったと思っています。ここが振り返って悪かったなと思っております。

最後に総括です。3点あります。決まっている予定の機能等は早く実現検討したほうがいいこと。それから、これも当たり前なことだと思うんですけど、コストですね。利益からコストをマイナスして、不利益の見積もりがあった機能は、（止めるという）提案を持ちかけること。また、ずっと続くプロダクト等は将来に抱える負債も考慮に入れていく必要があること。この3点を学んだなと思います。

もちろん今回は結果的に顧客に機能自体を提供することはできなかったんですけど、この開発をすることによってプロダクトに中長期的な負債をもたらすことは今使っているお客さまにも負債を及ぼすと考えると、今回の選択は顧客の価値を守ったとも言えるかなと思います。

ですので、開発を止める選択肢も顧客の価値へつながることを今回の事件を通じて学ぶことができたかなと考えております。

私の発表は以上になります。今回の私の教訓がみなさまのプロダクト開発の気付きになればと切に願っております。本日はご清聴ありがとうございました。

池田智裕氏（以下、池田）：ありがとうございました。

藤澤：しくじり先生感のある。

松浦：そうですね。

池田：私も昔の話を思い出しました（笑）。事業部長に説明する前の日に私も実現検討してみたんですよね。資料はほぼできていたんですけど、もう少し踏み込んで実現検討した時に「あれ？」となりました。結局、10人ぐらいのミーティングを説明前日にキャンセルしましたね。「これ無理です」と言って。

（一同笑）

池田：そういう苦い思い出を思い出しましたね。

藤澤：止める勇気というか。

池田：そうですね。

SIerと自社サービスの作り方に違いはあるか

藤澤：Zoomのチャットでもコメントをいただいています。「SIerと自社サービスの違いってあるあるかも」。商流のどこに入っているかにもよると思うんですけど、わりと上流に入っていると、必ずしもそうじゃないんですけれども。

池田：そうですね。それを作ったほうが良いか悪いかという、こちらの意見を挟めるお客さまもいるんですけど、いろいろ考えた結果、「それでもやってくれ」と押し切られる時もあります。自社サービスだと、我々もそこに意見を挟める余地はけっこうあったりしますよね。

なかなか、SIerの時に「止めましょう」とは言えないですよね。稼がなきゃいけない部分はあります。自社サービスならではの開発かもと言える時がある。

藤澤：あとはそういう判断をする情報をお客さんが全面的に持っていて、共有はしてもらっているんだけどすべて共有してもらっているわけではないから、しっかり判断できないシーンもあるかもしれないですね。

池田：そうそう。Zoomのチャットにも書いてあるんだけど「作って終わりか、作ったあとも関わるか」。

たしかに、作ったあとに自分たちが関わりますよね。開発的な負債を抱えることは、開発側にとっても営業側にとっても、ひいてはお客さんにとっても意味のあることではないので、開発を止める判断にもなるんですよね。

藤澤：ここで質問が来ていますね。「ラクスさんは現在、PdMの市場・顧客製品ロードマップはビジネスサイドがやられているのでしょうか？」。松浦さん、これはどうなんですかね？　もしかしたら商材によって違うと思うんですけど。

松浦：商材によって違いますね。楽楽明細は基本となるメイン部分は、ビジネスサイドに作ってもらっています。そこに最近、僕も顧客に開発案件をやる経緯は見えてきたので、そこに対して意見できるようになってきた感じですね。なので、開発優先順位もいったん僕で決めて、答え合わせをするみたいな営みになってきています。

藤澤：松浦さんの資料の冒頭あたりに出てきた、「松浦さんの守備範囲はここだ」みたいなスライドを見せていただいてもいいですか？

松浦：ここですかね？

藤澤：はい。スライドの前半（顧客・市場調査、ニーズ分析、製品企画）のビジネスサイドの役割をもともと肩代わりしていたのを、（今は本格的に）やっていっている途中なんですね。

松浦：そうですね。

開発とビジネスサイドの間を調整する際のポイント

藤澤：ご質問がもう1個届いていまして、「（ビジネスサイドと開発の）間に立たれて開発優先順位を調整しているイメージでしょうか？」。

松浦：そういう感じですね。結局、早く開発するためには向こうの理想ばかりを聞いているわけにはいかないので、例えば小さい案件をたくさん詰め込んででも、早くリリースしたほうがいい判断もあります。

例えば、大きい案件でもじっくりやってちゃんと獲得が見込めるのであれば、そうするべきですし、そういうところは結局開発しか見えない視点もあります。

なので、調整というか、そういうところをつないでいるので、最終的には僕でも決められるようになりたいと思っています。今はそのための情報を集めつつ、僕の考えは間違っていないのかを一緒に協力しているのが今の流れかなと思っています。

藤澤：ちなみに今、画面にも出ているんですけど、今日ご参加されている方に補足すると、松浦さんはもともと、PdMというよりはプロジェクトマネージャー的な業務が中心の役割だったんですよね。

松浦：そうですね。

藤澤：スライドのオレンジ色の部分ですかね。開発メンバーメインの作業、プロジェクトマネージャー業務と兼務なんですが、いわゆるプロダクトマネジメントという領域に広げた時にもともとやっていたけど手放された領域や、あるいは資料にはないかもしれないですけど、新しく増えたものはあったりしますか？

松浦：そうですね。完全にこの領域拡大中のところは増えますね。今はもう新機能の話をする時には、顧客にどう聞いていこうかみたいなところも合わせて、僕が実際顧客にヒアリングの内容を作ったりしますね。

逆に手放したものは、開発メンバーもかなり増えてきたのでマネジメント業務に集中しています。もちろん困った時は開発に立つんですけど、平常時は極力コードに触らないというか（笑）。

要所要所だけチェックして、問題なければOKなので、開発メンバーの方が頼もしくなってきています。そういったすごく安心して任せられる部分も増えてきたので、（PdMと開発の比率が）半々ぐらいかなとは今思っていますね。

藤澤：チーム自体がわりと自律的に動く状態に作れている感じなんですね。

松浦：そうですね。

藤澤：わかりました。ありがとうございます。

開発畑のPdMゆえの長所・短所

藤澤：松浦さんの場合だと開発出身でPdM領域に手を伸ばしているという感じですか？

松浦：そうですね。

藤澤：でも、PdMはいろいろいらっしゃいますもんね。逆パターンで、もともとマーケティングやっている人が開発も見たりするパターンもいろいろありますから、「PdMになるにはこうだ」みたいなものは、なかなか確立されていなかったりするんですかね。

松浦：そうですね。あまりないとは思うんですけど、出身によって色は出る気はしますね。開発出身だと、どうしても保守的になるとか。僕の場合だとできる約束しかできないので。

（一同笑）

松浦：例えば、「実は（顧客が）本来求めていたものと違っていた」「機能がリリースできればいいんでしょ？」みたいなことは気を付けています。

事業部長やCSのリーダーたちの顧客との接点というか声を、僕の中でもちゃんと（理解に）落として、ある程度の妥協点じゃないですけど、少工数で開発できないかは心がけています。技術者じゃないとできないこともあるし、技術者だから偏っちゃう部分もあると思っていますね。

藤澤：さきほどご質問にもありました調整役の役割として色がついたわけですね。「PdMは出身によって色が出る。非常に共感できます」とコメントをいただいていますね。PdMといっても本当に領域がすごく広いですもんね。

松浦：そうですね。

藤澤：極端な話、全部！　みたいな感じですよね（笑）。

池田：実装までやっちゃうPdMもいそうですよね。

（一同笑）

藤澤：そこの会社さんによって求められる領域も違ったりするんでしょうね。なので、もし今日ご参加されている方で、プロダクトマネジメント領域でご活躍されている方がいらっしゃったら「うちはこういうところをPdMがやってます」とか、それ以外のご意見とかもいただけると我々としても参考にしやすいところですね。

2週間で中止を招いた要因

池田：私が（松浦氏の発表で）気になっているところがあって、スライドの青い部分はプロジェクトを始める段階では気づきにくい部分でもあると思います。こういうことがあったので、この部分を調査するとか、このフェーズでやろうとか、変わったりしたんですかね？

松浦：どちらかというと、今回の場合はまっとうに（ステップを）踏んだんですね。3ヶ月前はイレギュラーだったかなと思っているんですけど、提案をしたいということ自体が急だったんですね。

昔からやりたいという構想もあることも聞いていて、もうやるしかないんだろうと僕の頭の中にもあったんですよね。純粋に開発（のリソース）が空いてなかったので、開発に着手してから詳細調査などをしようとなりました。そこはHowの部分だったので、ある程度は開発着手してから考えればいいと思っていたんですよね。

池田：なるほど。ふだんだったらもう少し早い段階で検討していた部分が、早いスパンでやってくれという話になり、お客さんとの話もあるので、プロジェクトを少しイレギュラーなかたちで進めてしまったんですね。

松浦：そんなところですね。

池田：被害者的な感じもありますね。

（一同笑）

そういう感じも少ししますよね。同情する余地はたくさんありそうだなと思いましたけど。

松浦：そうですね。

藤澤：今回のケースに関しては事なきを得たんですね。

池田：最終的にそうですね。もっと進んでたら、もっといろいろな工数が無駄になったと思います。

SaaSの開発ポリシー

藤澤：今、コメントで1件いただいていて「SaaSってあまり個別のお客さんのための機能開発をしなそうなイメージがあります」と。

池田：そうですね。1社のためより、全体を見るということはありますね。

藤澤：そうですね。弊社のすべてのプロダクトに共通して言えるのは、個別のお客さまの要望にダイレクトに対応するというケースは少ないです。

池田：もちろん一人ひとりのお客さまは大切なんですけど、全部違う意見が出てくるので、仕様スパゲッティ（注：スパゲティプログラム。開発者以外にとって解読困難なソースコードを指す）になっちゃうと、製品が立ち行かなくなります。営業さんがお客さん1社を取りたいだけの思いで上げてくる時もあるので、そういった意見をまず聞いても、いろいろ考えて検討したいですね。

藤澤：わりと共通項というか。

池田：もちろん1社が言ってきても、他のお客さんにもかなりのメリットがあると考えれば、対応はしますよね。

松浦：そうですね。1社のためにやるというのはあまりないですね。

ただ、そのまま鵜呑みにして開発したところで、実際そのお客さんの課題を解決するかというと、意外とそういうこともないんですよね。（複数の顧客の課題を）突き詰めていくと、実は同じことをしていたこともありますよね。どうしても、バラバラな意見の共通項を探していくところになっていく印象はありますね。

藤澤：何でしたっけ？　スティーブ・ジョブズの「顧客はほしいものを見せられないと本当にほしかったものに気付かない」みたいな理屈に似たところがありますよね。

松浦：そうですね。まさにそうだと思います。

藤澤：マーケットシェアのフェーズによって……。たしかにそうですね。

松浦：それもありますね。

藤澤：ビジネスサイドと開発の関係も良好という感じですよね。

松浦：そうですね。あまり荒げた話にはならないですね。あまりというか、ないですね。

藤澤：そうですね。全部の会社を知っているわけじゃないんですけど、ビジネスサイドと開発サイドのコンフリクトがそんなにない会社かなと思います。

池田：では松浦さん発表ありがとうございました。

一同：ありがとうございました。