見出し画像

カスタマーサクセスマネージャーからプロダクトマネージャーに転身した私がもっと早く知っておきたかった開発思想

hiroseayumi

みなさんこんにちは。
これは、LAPRAS Advent Calendar 2023の６日目の記事です。

私が前回noteをしたためたのはちょうど１年前、エンジニアスカウトサービスLAPRAS SCOUTのカスタマーサクセスマネージャー（CSM）としてのオンボーディング改善活動を記録し、HUNTER×HUNTERの最新刊に打ちひしがれていたタイミングでした。

https://note.com/ayukichi3/n/nbf1057ef3359

それからちょうど１年、HUNTER×HUNTERは週刊連載ではない掲載形態での継続が発表され、湘北高校バスケ部において３年生引退後の戦力が若干不安視されていたものの実は宮城リョータが公私共にキャプテンになる準備がなされておりかつゴリもそれを頼もしく思っているであろうことが描かれた傑作映画が公開され、秦国では李信将軍が今までにないかっこよさを見せた姿に最高に泣かせられながらも「え、今70巻でまだ中華統一できてないの大丈夫なんかな」って一抹の不安を抱える今、
私はLAPRAS SCOUTのプロダクトマネージャー（PdM）をしています。

思えば、本当に色々あった1年でした。

この記事で書いていること


4年近くCSMを経験したのちに今年7月からPdMとして着任してから、CSM時代には色々と不可解（ごめんなさい）であった開発チームの動きが、自分がその立場になることで「なるほど、あれはこういうことだったのか！！！！！」と腹落ちしたことが多かったので、この記事では「開発側のこういう考え方、もっと早く知りたかった！」と感じたことをまとめます。

とはいえ、もちろん会社によって色々考え方はあると思いますし、自社サービス／受託開発という違いでも考え方は変わってくると思います。
あくまで一事例として参考になれば幸いです。

この記事を読んで頂きたい方

  • 開発チームに要望を上げても、なかなかこちらがイメージした機能ができてこない！と悩むセールス・カスタマーサクセスマネージャ

  • 開発した機能の意図がなかなかセールス・カスタマーサクセスチームに伝わらない！と悩むプロダクトマネージャー・プロダクトオーナー

  • 開発未経験のプロダクトマネージャー

    のみなさんが、少しでも社内コミュニケーションがとりやすくなるための参考になれば幸いです。

正直、この記事で書いていることは、
なんならビジネスサイドの方々からすると「言い訳か！！」と取られかねない内容かもしれません。
そしてプロダクトサイドの方々からすると「当たり前だろ！！」と思われる内容かもしれません。

ですが、だからこそ双方を経験した自分が言語化する意味があるのではないか、と信じて書いてみようと思います。

PdMになって学んだ開発における３つの基本思想

１．ユーザーにとってプロダクトの変化がいいか悪いかは、実際に使ってみてもらうことでしかわからない

CSMであった頃は、「多少時間がかかってでも、顧客にとってよりよい機能を作ることが是である」と考えていました。顧客がより快適に、価値を感じてもらえる可能性があるのであれば多少リリースが伸びてもその機能は提供すべきであろうと。
もちろん今でも、この考えは間違ってはいないと思っています。

しかし、その機能が本当に顧客にとってあったほうがいいのか、悪いのかは出してみないとわからないものです。
故に大事なのは、とにかく最速・最小限で顧客に機能を使ってみて頂いて反応を得てアップデートするサイクルを回し続ける、ということになります。

早く出して早く仮説検証を回すのが大事、ということはなんとなく頭では理解していたものの、「なぜそれが大事なのか」が、めちゃくちゃ腹落ちした考え方でした。特にCSMを経験したうえでPdMになった身からすると、あえて「自分はユーザーのことをなんも知らない」くらいの気持ちでかからいとな、と身が引き締まる思いがしました。

ただ、それでも「いや～ここまであったほうが良いと思うんだけど…」という欲と常に戦っていますが、その機能はあったほうがいいかもしれないが、他にも山のように求められている機能がある中で、それでも今この開発に時間を投下すべきか？という問いかけはかなり意識的に行うようにしています。
…とカッコよくいいましたが、迷ったらプロダクトオーナーとプロダクト部門責任者にコミュニケーションを取りに行き、「今、それは本当に必要？」をしつこく問いかけてもらう場を設けるようにしています、というのが実際です。

また、大雑把でもいいのでFigmaというデザインツールで3−4ヶ月先までにやりたいテーマを入れたスケジュールをひき、こまめに（週に2−3回ほど）スケジュール図を更新しに行っています。これによって、常に時間は足りないという感覚を研ぎ澄ます事ができ、他チームにも週1程度で「◯月までに〇〇な状態にすることを目標に、直近3ヶ月はこんなことをします」も合わせて伝えるようにし始めています。

スケジュール図。推しが常に見守ってくれています

２．仮説検証と機能リリースをセットで行う。施策が当たっても当たらなくても、そこから必ず「学び」を得る

１つめの基本思想にあったように、結局その施策・機能がうまくいくかどうかはリリースしてみないとわかりません。
ただ、そこで仮にあまり使われなかったとしても、「いや～外したね！ハハ！！」で終わってしまうのではなく、外れたということ自体も学びであり前進です。
実際に「これはイケるでしょ！」と考えていたがあまり使われず、さようならした機能もいくつかあります…。

仮にその機能があまり使われず、すぐにクローズする判断にしたとしても、その「学び」を資源として蓄積していくために都度機能リリース前に仮説を立てるようにしています。

ちなみに私達のチームでは、下記のような「ジャベリンボード」というフレームを用いて、Figmaにズラーッと検証したい仮説とその結果を蓄積していっています。仮に機能はあまり使われず、プロダクト上からは消えても学びは残るので、とても重要な財産だと思っています。
こちらも、他チームに次の施策を共有する際は、まず「何を検証したいのか」も合わせて伝えるようにしてみています。

ジャベリンボード

３．全ての機能は、作った瞬間から負債になる可能性をはらんでいる

これは、開発チームからすると一番他チームに表立って言いづらかったり、あるいはエンジニアリング経験のある方からすると当たり前過ぎてあえて言語化することは少ないかもしれません。
であるがゆえに、実は一番ビジネスサイドとプロダクトサイドで認識のギャップが起きやすいところなのかもしれないとも思います。

どんな機能も、作ったからには必ず負債になる可能性をはらんでいます。

技術負債とは、使っている技術が古くなってしまった、とか、ものすごくグチャグチャなコードになってしまっている、だとか、そういった一部のケースを指すものと勝手に思っていましたが、そうではないのです。もちろん、それによって引き起こされる問題の大小は色々あると思いますが。

顧客の様々な要望・利用シーンに応じた細やかな開発を行えば行うほど、のちに行う開発の際に考慮しなければならない要素・コードがどんどん膨らんでいき、それに伴いどんどん開発に必要となる時間も膨らみます。

こういった点からも、「本当に必要な機能」にスコープを絞ることが、長期的に見てより早く・より必要とされている顧客価値を提供できるサービスに近づけていくために重要になってくると理解しました。とはいえ負債を恐れすぎて提供価値が下がってしまうことも避けるべきなので、このバランスがめちゃくちゃ難しいことも現実です。

負債になることを避けたりリリースを急ぎすぎることで、そもそも使えない機能になってしまうリスクを抑えるため、できるだけ機能リリース前にユーザーにデザインモックなどを用いて事前インタビューをさせていただいています。

こういった実際のユーザーの声も合わせて、他チームに共有・発信を行っています。…といいつつこれは結構忘れてしまいがちではあるのですが…

まとめ

以上、CSMにいた頃は全く見えていなかった開発思想を書いてみました。

■ユーザーにとってプロダクトの変化がいいか悪いかは、実際に使ってみてもらうことでしかわからない

■仮説検証と機能リリースをセットで行う。施策が当たっても当たらなくても、そこから必ず「学び」を得る

■全ての機能は、作った瞬間から負債になる可能性をはらんでいる

この記事であえて「思想」の部分をメインにおいたのは、「思想」や「そもそもの考え方」の話はなかなか他チームに時間を取って伝える余裕もなく（個々の施策の内容、仮説や狙い、などなどを伝えるのでもいっぱいいっぱい…）、また冒頭にも述べたように言い訳チックにも取られかねない内容のため、正直いいづらい部分が多いです。
だからこそこういった場で言葉にしたいと思いました。

例えばビジネスサイドから見ると「この機能リリース、なんでこうなってるの…？」と疑問に感じることもあるかもしれません。
プロダクトサイドからすれば「ちゃんと説明したはずなのに、何か伝わり切っていないぞ…？」ともどかしく思うこともあるかもしれません。

もしかしたら、そこには何か「お互い当たり前だと思っていても、実はそうではない伝わり切っていない理由や考え方」があるかもしれない、と、少し立ち止まってみてもいいかもと思う今日このごろです。

おわりに

PdMは常に時間との戦いであり、かつその役割の性質上、非常に多くの場面・ステークホルダーに対して説明責任が求められます。
私自身、特にその説明部分がかなり苦手なのですでに失敗もいくつかしてしまっていますし、まだまだ足りていないところもありますので日々反省です。

それでも、人と人とは100％理解しあう事はできません。

そこで天才久保帯人先生のポエムを引用したいと思います。

美しきを愛に譬（たと）ふのは　愛の姿を知らぬ者

醜きを愛に譬ふのは　愛を知ったと驕る者

＠市丸ギン『BLEACH』第20巻

はい。

「愛」というのは、その行動・言動で全てが他者から理解され、測れるものではないと勝手に解釈しています。

これは想像ですがPdMの根底にはユーザーへの「愛」が必ずあるはずです。周りからはそう見えないかもしれないけれども（そう見えないと取られないようにPdMは説明責任を果たそうと努めなければならない、は大前提あるとして）。

ですのでPdMは全員

市丸ギン

だと思って接してあげてください。「市丸ギンて誰？」と思った方はBLEACH読みましょう。

この記事が気に入ったらサポートをしてみませんか？