こんにちは！株式会社フィードフォースでマーケティングを担当している つつみ けんいちろう です。

我々は企業のデジタルマーケティングを支援する SaaS プロダクト「dfplus.io」を提供しています。日々、お客様の課題を解決するために開発を重ね、より使いやすく価値のあるプロダクトを目指しています。

プロダクト開発の提供価値を高めるためには、お客様との接点が多いビジネスチームと開発チームの連携が重要です。しかし、仕事の進め方や前提となる知識が違うため、連携に苦労されている会社も多いのではないでしょうか？

今回はその中で、ビジネスと開発、2 つのチームがタッグを強めるために実施した「リーン顧客開発」の読書会について、進め方や効果をご紹介します！

ビジネスと開発の距離は遠くなかったけど・・・

dfplus.io チームはビジネスチームが 12 名、開発チームが 8 名というメンバー構成です。プロダクト開発には、全員が何かしらの形で関わっています。

2 週間に 1 回のスプリントレビューで、開発スケジュールと開発中の機能について共有があり、ビジネスメンバーが意見や要望を伝えています。また、お客様から要望があれば専用の Slack チャンネルに投稿し、月に 1 回は全員で内容を確認する場を設けています。

ビジネスチームと開発チームの距離は遠くないものの、「開発した機能は価値を届けられているのか？」「お客様の要望をきちんと聞けているのか？」という疑問を両チームのメンバーが持つようになりました。

我々は速く走る馬を開発していないか？

史上初の量産型自動車を発明したヘンリー・フォードの名言に以下のようなものがあります。

当時の主な交通手段は馬車であり、自動車は普及していません。そのため、顧客に「何が欲しか？」を聞くと「顧客は速い馬が欲しい」と答えてしまいます。「速く移動する手段が欲しい」という本質的な顧客の要望に気づいたからこそ、ヘンリー・フォードは自動車の量産に向けて動きだします。

dfplus.io はリリースから 7 年がたち、企業が商品データを活用したデジタルマーケティングに取り組むために「データフィードをかんたんに管理する」という課題の大きな部分は解決できています。

プロダクトの提供価値をさらに高めるには、まだ顧客も気づいていない「潜在的なニーズ」を把握しなければなりません。ユーザーから「潜在的なニーズ」を引き出し、プロダクト開発に落とし込むためには、体系だったスキルが必要です。

そこで有志で集まったエンジニア 3 名とビジネスメンバー 10 名で、『リーン顧客開発』という本から必要なスキルを学ぶべく、読書会を実施しました。

「リーン顧客開発」は売れないリスクを減らす技術を学べる本

この本はリーンスタートアップを実践するにあたり、「顧客が本当にほしがるもの」を理解し開発するための具体的なノウハウが学べる一冊です。スタートアップに限らず、大手企業でも応用できる技術が紹介されています。

輪読形式で参加ハードルを下げて、ディスカッションを中心に

読書会は「輪読形式」で行いました。「輪読」とは、同じ本をみんなで読み、ディスカッションをして理解を深める読書会です。

輪読形式を採用したのは、参加者の職種が幅広く（エンジニア、デザイナー、セールス、カスタマーサクセス、マーケティング）、それぞれの立場から顧客やプロダクト開発について意見交換をするためです。

書籍は「まえがき」と 9 つの章から成り立っているので、毎週 2 章 × 5 週で読み進めました。1 つの章につき 1 名の担当を割り振って、簡単なサマリを用意します。

各回は 1 時間で、進め方は以下のとおりです。

• 章の説明①：5～10 分

• 4~5 人でディスカッション①：15 分

• 全体でディスカッション内容の共有①：5 分

• 章の説明②：5～10 分

• 4~5 人でディスカッション②：15 分

• 全体でディスカッション内容の共有②：5 分

• 次回の案内：1 分

1 週間に 2 章ずつなので読書の負担が少なく、詳しく本を読めなくても誰かのまとめを聞いてからディスカッションに入るので、本が苦手な人でも参加しやすかったようです。

やって良かったこと

共通言語・理解ができた

ビジネスチームの中にはプロダクト開発の知識が無いメンバーもいたので、「MVP（Minimum Viable Product）」などの基本的な考え方を共有することが出来ました。

また、ヘンリー・フォードの「もし顧客に、彼らの望むものを聞いていたら、彼らは『もっと速い馬が欲しい』と答えていただろう。」に通じますが、ユーザーの声を聞くことは重要だが全て正しいわけではないことを、参加者の共通理解にできました。これは、今後のプロダクト開発に大きく生きてくるはずです。

開発とビジネスでプロダクトについて会話する機会になった

2 週間に 1 回のスプリントレビューはあるものの、20 人近くが参加しているため、個別の会話は生まれにくい状況でした。読書会では 4～5 人のグループで異なる職種の人が会話する機会になり、お互いの考え方を知るキッカケになりました。

読書会の後は、職種をまたいだコミュニケーションも取りやすくなっています。

本の内容について、それぞれの職種の観点を出し合うことで、相互理解が深まった

本をトークテーマにして、これまで開発した機能について、それぞれの観点から意図や効果を話すことができ、相互理解が深まりました。

まとめ

ビジネスチームと開発チームでプロダクト開発への考え方が異なると、ともすれば対立する関係になりかねません。お互いの考え方を知り、共通言語ができると、協力し合ってプロダクト開発に楽しく取り組めるようになります。

今回の記事が、同じ悩みを抱えるチームのご参考になれば幸いです。我々も引き続き、試行錯誤しながら、素敵なプロダクトを世に届けられるように頑張ります！