編集部注
本稿は、CodeZineに掲載された、ソフトウェア開発者向けカンファレンス「Developers Summit 2024（デブサミ2024）」のセッションレポートを転載したものです。プロダクトづくり、プロダクトマネジメントに近しいテーマを選りすぐってお届けします。
エンジニアが陥りがちなHow起点の新規事業開発から脱却するために
2023年7月にベリサーブにジョインする以前は、BtoCの事業会社でWebエンジニアやテックリードとしてサービス開発や新規プロダクトの立ち上げに従事してきたという田中氏。
プロダクトマネージャーとして入社してから約2カ月がたち、オンボーディングを無事に終えて新たな仕事にもなじんできた頃、同社ではコーポレートロゴと事業ドメインが再規定されることになった。
「品質を創造する力でイノベーションを加速する会社」と銘打ち、より幅広い事業ドメインでビジネスを展開していこうと舵を切ったのだ。そんな会社の事業戦略の変更に伴い、上司から「何か新しいプロダクトを作れ」と命じられた田中氏は、当初戸惑いを覚えたという。
「0→1プロダクトへの参画経験はあるけれど、新規事業の立案経験はゼロ。テストコードを書いたり、CI環境を構築したりした経験はあるけれど、テスト／QA専門家としての経験もゼロ。テーマは自由だと言われたが、縛りがないのは、それはそれでつらいものがあった」と語る。
田中氏自身、手応えはないながらも、見よう見まねで書いた企画書を出してみたが、あえなく撃沈。上司から次の3つのフィードバックをもらった。
- イノベーションを加速するものであれば、QA／テスト分野に縛られなくてもよい
- HowよりWhat・Whyを考えろ
- 顧客は本当にその問題を抱えているのか？
「HowよりWhat・Whyを考えろ」とは、どういうことなのか。田中氏はエンジニアとしてキャリアを歩んできたため、どうしても「どういう技術を使って作るのか」というHowのほうに目が向いてしまいがちだった。けれども、これは顧客にとってはどうでもいいことだ。それよりも大切なのは、「誰の（Who）どんな課題を（What）なぜ私たちが解決するのか（Why）」である。
実際に考えてみると、WhoとWhyは次のように比較的スムーズに固まったという。
Who：
- Webプロダクト開発チーム
Why：
- Webプロダクト開発をより良いものにしたい：Webプロダクト開発に携わってきた人間として、体験をより良いものにしたい
- PLG（Product-Led Growth）との親和性：プロダクトがプロダクトを売り込むような、営業やマーケティングの機能をプロダクトに内包する戦略。フリーミアムからの有料化を狙う
- ドッグフーディングによる自己顧客化：自社のプロダクトを日常的に使用することで改善していく。BtoB企業で部門横断的に使われることを狙うサービスには非常に有効である
残るはWhatだ。顧客の課題を田中氏はどのように見つけていったのだろうか。
Whatはどこにあるのか？
What（＝顧客の課題）を見つけるには、顧客に聞く必要がある。自分の経験則はn=1のサンプルでしかなく、ビジネスになり得るような普遍的な課題であるとは限らないからだ。田中氏はCB INSIGHTSによる『The Top 20 Reasons Fail』の調査結果を紹介し、「スタートアップ（≒新規プロダクト）が失敗する理由のトップは『マーケットニーズがないものを作ってしまった』ことである」と強調した。
ベリサーブでは、これまでテストエンジニア当事者としての身近な課題から企画を始めており、市場ニーズはあまり意識していなかったという。例えば、テスト管理ツールの「QualityForward（クオリティフォワード）」は、当時Excelライクな操作性で、うまくテストを管理できるツールがなかったから誕生したものであり、テスト技法ツールの「GIHOZ（ギホーズ）」は、クラウドで軽量かつ複数のテスト設計技法をサポートしたツールが市場になかったから生み出したものだ。
冒頭でも紹介したが、田中氏はテストエンジニアではなく、当事者としての強いニーズもなければ、市場に受け入れられる確証もまったくない状態である。そのような中でもWhatを見つけるには、やはり顧客と話して探す“マーケットイン”アプローチにするしかない。
マーケットインのやり方は、書籍やブログを参照した。田中氏がさまざまな情報に当って分かったのは、みな共通して「インタビューによってCPF（Customer-Problem Fit）を検証しろ」「Burning Needsを見つけろ」と説いていることだった。
Burning Needsとは、髪の毛に火が付いて、すぐに消さなければならないような、切迫したニーズのことである。
このBurning Needsを見つけるため、田中氏はこれまでに60〜70社くらいのプロダクト開発に携わる人たちにインタビューを重ねてきた。インタビューを受けてもらう人は、これまでの知人・友人のネットワークで探したり、社内の他プロダクトの開発メンバーに協力を依頼したり。「ユニーリサーチ」や「トリマイン」といったオンラインインタビューのマッチングプラットフォームも活用しているという。
インタビューはオンラインで開催。プロダクトマネージャー、エンジニア、マーケター、セールスなどプロダクト開発に携わるさまざまなポジションの人たちに話を聞く。時間は30分程度〜長くても45分まで。YES／NOで完結するクローズドな質問ではなく、「プロダクト開発で一番困っていることは？」といったオープンな質問を投げかけることも忘れない。脱線を厭わず、無意識からこぼれ出る本質的なニーズをすくい上げることを大切にしているそうだ。
「理想的なインタビューのイメージを言えば、30分間ずっとインタビュイーに好きなことをしゃべってもらい、私は相づちを打つだけにしたい。だから基本的にインタビュー中はうなずいているだけだが、たまに相手の話を要約して、『こういう認識で合っていますか？』と確認を取る。これにより、勘違いによる思い込みを防げるし、そこから新たな話が広がることもあるので、メリットが多い」と田中氏は述べた。
チームコミュニケーションの課題はBurning Needsなのか？
インタビューを繰り返して見えてきたのは、「プロダクト開発に関する課題のほとんどが、チームコミュニケーションにあるのではないか」ということだった。例えば、以下のようなものに思い当たる節はないだろうか。
- 要求・要件の認識のズレによる手戻りや不具合の多発
- 成果物への期待値の認識のズレによるチームの不和
- 情報やナレッジの分散・属人化、頻繁な人材流動によるナレッジの散逸
- プロジェクトマネジメントの機能不全、あるいはプロジェクトマネージャーの業務過多
- コンウェイの法則に引きずられたアーキテクチャと、縦割りのコミュニケーションによる弊害
- ビジネスサイドと開発サイドの対立、古参と新人の対立
……など。
とはいえ、「これがBurning Needsであるとは言い切れない」と考えた田中氏は、さらに掘り下げて聞いてみることにした。すると、「『Notion』を使って解決しようとしている」と答えた人が多くいたのだ。
プロジェクト管理やナレッジマネジメントツールは他にも数多く存在するが、なぜNotionなのか。その理由について田中氏は、「Notionは『All-in-one workspace』をうたっており、分散した情報を集約してコミュニケーションの問題を解決できるからだろう」と分析した。
一方で、Notionの活用がうまくいっていない組織も少なくない。その理由として、「ストック／フロー情報の分類が難しい」「ナレッジを集約するための設計が難しい」「目先の業務に追われて、優先順位が上がらない」といったものが挙げられる。要するに、コミュニケーションを改善するためのコミュニケーションにコストがかかっており、“服を買いに行く服がない”状態に陥っていると考えられる。
Slackの会話をナレッジにするにはコストがかかるのは容易に想像が付くだろう。フロー情報（メールやチャットのように一時的なやりとりの情報）とストック情報（ドキュメントのように後から参照しやすいように整理された情報）は性質に大きな違いがあり、フロー情報をストック情報に移行するには大きなコストがかかる。またストック情報とフロー情報の両方の性質を持った中間的な情報（GitHubやチケット管理ツールに集まる個々のタスク情報・議事録やインタビューの書き起こし・意思決定の歴史的背景や目的・思いなど）のボリュームが大きく、処理の仕方に頭を悩ませることになる。
「これらの課題を解決するのは、人間には難しい。それならば技術の力で解決すれば、売れるプロダクトになるのではないか」と考えているという田中氏は、今後も継続してインタビューを行うとともに、生成AIを使った技術検証を進めている最中だ。
「インタビュイーやパイロットユーザーを絶賛募集しているので、興味のある方は、ぜひお声がけいただきたい」と語り、田中氏はセッションを締めくくった。なお、本稿の読者に対しても問い合わせページから応募を受け付けているという。
