Fusic Tech Blog

Fusion of Society, IT and Culture

pmconf2021発表内容の補足とかいろいろ_受託開発に強い会社が、新規プロダクトをリリースし、短期間で撤退判断に至った失敗談、赤裸々に全部話します。
2021/10/26

pmconf2021発表内容の補足とかいろいろ_受託開発に強い会社が、新規プロダクトをリリースし、短期間で撤退判断に至った失敗談、赤裸々に全部話します。

はじめに

2021.10.26に開催されたプロダクトマネジメントカンファレンス2021に私船越と安河内の2名で登壇しました。

https://2021.pmconf.jp/sessions/L9r89sln

スライドは↓をご覧ください。

登壇の内容はスライドを観ていただければ概ねわかる感じになっていると思います。

当初伝えたい失敗談はもっと溢れていたのですが、メッセージを絞って以下の2点を伝えています。

  • スピードは大事…、でもとにかく早く実装しろってことではない!
  • 自社プロダクトは甘くない、だからこその必要な覚悟!

この記事では、時間の都合削った内容とか、参考になる書籍とか、補足とかつらつらとふわふわと書かせてもらいます。

pmconfと私

まだ、前段が続くんかい…という感じですが、少しだけ。 過去に 新米PM(プロダクトマネージャー)がサービス成長期に向けて奮闘した話 でも記載したのですが、pmconf初参加で衝撃を覚えたのが2019年。それから2年間いろいろとプロダクトマネジメントについて学んだり考えたりしてきました。しかしながら、実際の業務で上手に活用できているかというとNOの部分も多くあり、いろいろな失敗が起こっちゃうわけです。その辺が今回発表のテーマとなりました。

ビルドトラップ

発表スライドの中ではビルドトラップという話をしています。

「ビルドトラップ」という言葉は、プロダクトマネジメント ―ビルドトラップを避け顧客に価値を届けるという書籍より引用した言葉です。(有名な書籍なので紹介するのも恐縮ですが…)

本来は、顧客に対して実際に届けられる価値「アウトカム」に注目するべきところですが、実際の価値ではなくリリースされた機能など「アウトプット」に注目してしまうことがよくあるよというのが書籍のメッセージで、これを「ビルドトラップ」と言っています。


著者の方のYoutube動画もあるので参考まで。

あとプロダクト筋トレというコミュニティで輪読会もしていて、先日始まったばかりなので是非ご参加ください!


今回の我々が陥ったビルドトラップは「何かと急ぎすぎる」というところでした。

書籍の序盤の方で「テクノロジー主導」の企業がよく陥るビルドトラップが記載されています。要約すると「テックに注目しがち」「マネタイズやマーケティングを製品を作ってから考える」といったところ。つまりは、イケてるけど売れないツールを作りがちという感じです。わりと近いことが発生してたなと反省しています。

Fusicの行動指針の中に「 結果にこだわろう。本気の失敗はたたえよう。 」というものがあります。いいものを作って失敗することは決して悪いことではないですが、「本気の失敗」といえるためには、作る前にできることがたくさんあるよねと考えています。

リーンキャンバスとかバリュープロポジションキャンバスとか

こういうの普段から全く作らないわけではないんですが、急いでいるとないがしろにしてしまいます。でも、なんだかんだ超大事です。少なくとも仮説レベルでもそれなりにイケそうか!?というのを把握するのにすごく役立ちます。

受託開発で、お客様のプロダクトをお手伝いするときもあるのですが、ある程度成功しそうかを判断するために作ったりもしていました。この辺をズバッとまとめられないプロダクトは内容として弱い可能性がとても高い。自社プロダクトについても当然しっかりと考えておきたいものです。

ユーザーインタビューや仮説検証のぶんまわし

これは、いろんな書籍やら記事やらで本当に大事だと伝えられている内容だと思います。

読めてはないのですがリーン顧客開発がまさに作る前にできるアクションにフォーカスした書籍(のはず)です。

以下のスライドも、とても勉強になります。

プロダクトマネジメントの仕事は、「ビジネスの側面」「顧客の課題解決の側面」の両方を成功へ導くことですが、実際の業務としては、「 リスクを減らしてどれだけ仮説検証をぶん回せるか 」といってもよいのではないかと考えています。これがむずいんですが、作るより前にできることが多いっていうのは、本当に忘れないでいたいものです。

どれだけユーザーインタビューしたらいいの?

これがなかなか苦しいところです。ある程度の確信を得られるまでというところが答えになるのでしょうが、これにすごく時間かけすぎるのもなーというのは開発者としても悩みどころですよね…。

2018年の記事ではあるのですが、より良い製品案を選択するために役立つツールの中でICEスコアというものが紹介されています。

優先順位付けをICEスコア=I(インパクト:Impact)×C(確信度:Confidence)×E(容易性:Ease)で行うという内容です。

この「C:確信度」に注目します。0~10までのスコアがありますが、例えば、自己確信なんてのはわずか0.01、チーム・外部の専門家・投資家などの良案認定で0.1、20人以上のユーザーとのインタビューでやっと3というスコアです。

20人以上のインタビューをコンスタントにできているかというNoです。確信を得るには、それだけインタビューを繰り返す覚悟が必要なのだろうなと感じさせる内容ではないでしょうか?

CORE , Why , Whatの補正補正補正…

発表にあるように、対応順番には反省がありましたが、ユーザーインタビューや仮説検証を繰り返していくことで、CORE , Why , Whatの補正を繰り返していく流れは、それなりに理想的なPM的アクションかなと感じておりました。

インタビューを繰り返すことにより、ユーザーの困っている現実と、それを解決しようとしている各種プロダクトのギャップみたいなものが見えてきます。

数を繰り返すことで、「我々はこういう世界を実現したいというビジョン」を、ある程度の根拠や自信を持ちながら決めていくことができるようになっていきました。(残念ながら、収益につながる確からしさまではまだまだだったのですが…。難しいですね。)

こういった検討の流れは、プロダクトマネジメントのすべてに「Fit & Refine」という項目でなケーススタディと合わせて説明されています。また著者の小城さんのnoteもとても勉強になりますのでオススメです。

覚悟の話

プロダクトをやるにはそれなりの覚悟が必要です!というお話でした。

メインの事業がプロダクトの場合、これは結構な高い覚悟の上でプロダクトを提供していると思います。 受託開発の会社がプロダクトをやる場合、今後そのプロダクトに注力していくか?というと、なかなか覚悟が足りていないケースも多いのではないかと思っています。(Fusicでは、今期からプロダクト部門ができたこともあり、それなりに本気の覚悟になろうとしているのかな?)

「多くのプロダクトは失敗する」ことを前提にすると、失敗しても続ける覚悟みたいなことが成功のためには必要なのではないかなと思います。

「12回の事業転換」世の中の課題見つけられずに SmartHR・宮田昇始社長 なんかは、まさにすごい覚悟の世界だなーと驚くばかりです。

また、9割の社会問題はビジネスで解決できる でも、社会問題を解決したい高い覚悟があるからこそビジネスとして成功できている内容が記載されています。

「あー、正直まだまだ覚悟たりなかったなー。」というのが、プロダクトの失敗(=成功まで持っていけない)の大きな要因一つのようにも思います。本気の覚悟、本気の探求は、何かしらドメインに特化していくみたいなことで磨き上げられる部分かもしれません。まだまだ、プロダクト部門として軸をもった覚悟みたいなところを言語ができていないところはあるのですが、今後も考え、チームでより強いものにしていきたいものです。

終わりに

まとまりのない駄文を読んでいただきありがとうございます。

上記のような内容は、プロダクトマネジメントを学ぶことで知ることができる知識ですし、自分自身が失敗しなくても活用できた知識でもあります。個人やチーム内だけでなく、会社全体にプロダクトマネジメントの知識が浸透していくことでもっと強い組織になるのではないかと考えています。

一方で、かなり自由に失敗もチャレンジもできる弊社はやはり楽しい環境だなと思っています。

エンジニアはもちろん、尖った方々を募集していますので興味のある方は、私のtwitter などに軽い気持ちでお声がけくださいませ!!

Funakoshi

Funakoshi

プロジェクトマネージャー。自称、愛とわくわくの伝道師。 自社サービスsigfyでは、プロダクトマネージャー的なことをしている。 元ゲームプランナー&ディレクター。趣味で少しだけYoutuber。 娘中心の生活。