「顧客志向」が「楽しい環境」を作る / 10Xとみてねが語る、顧客志向な開発カルチャーの作り方・育て方に参加した

「10Xとみてねが語る、顧客志向な開発カルチャーの作り方・育て方」に参加しました。サブタイトル「「エンジニアが楽しい」環境をどう実現するか？技術トップがホンネで語ります！」も良いですね。

「顧客志向な開発カルチャー」と「エンジニアが楽しい環境」の両立を目指して日々開発に勤しんでいる僕としても興味深いテーマでした。

また、10Xさんは「Free Agenda」のPodcastで、みてねさんはアプリの利用者として普段からお世話になっているので、そんな企業の方々のお話が聞けるのも楽しみでした。

今回の配信はアーカイブ、公開されていますので、ご興味のある方は御覧いただけます。ありがたい。
www.youtube.com

今回のイベントは株式会社ミクシィの酒井さんと株式会社10Xの石川さんが自社の開発組織の説明をした後、参加者からの質問にパネルディスカッションで答える流れでした。詳細は動画に任せるとして、本記事はお話を聞いて僕が特に「おぉーー」と思った点に絞ってまとめていきます。

内容のハイライト

みてねさんの開発

サービスのミッションとは別に開発グループ向けにミッションがある
自身の領域に閉じず、あらゆる物事に前のめりなチーム
エンジニアが責任感を持って、チャレンジしていく
顧客にも、技術にも、好奇心を継続させる
組織作りは理論だけじゃなく、課題から取り組んでいる

10X さんの開発

状況に応じて何でもやる
Why/WhatまではPMが決めるが、Howはエンジニアに任せている
ビジネスチームがユーザーの声を集めて、言語化してエンジニアに伝える
課題に対してビジネス1名、エンジニア2名の少数チームで開発している

パネルディスカッション

エンジニアが顧客を知る機会はどのような場があるのでしょうか？
- 酒井さん
  - ユーザーインタビューに同席
  - カスタマーレビューを見たりリアクションしたり
  - 社内ユーザーにヒアリング
- 石川さん
  - 専用チームからインタビュー動画やレポートがアップされる
  - エンジニアも現地に出向いて仕事を知る
技術よりな関心の強いエンジニアに顧客志向な開発カルチャーを浸透させるには？
- 酒井さん
  - ユーザーの声やアプリレビューの声に対して責任を持ってどう関わるか考えてもらう
  - 個々というよりチームとして顧客志向を目指す
- 石川さん
  - メンバー全員が日ごろから顧客の声を聞くことが普通になっている
  - エンジニア力を高めるために顧客志向が第一じゃないメンバーも必要になる
  - チームへの貢献によりチーム全体が顧客志向になっている状態が良い
エンジニアチームが「プロダクトによる顧客の喜びやその手ごたえ」を感じながら楽しく働くために取り組んだこと
- 酒井さん
  - わいわいの楽しさじゃなく、顧客の課題を解決してプロダクトを良くすることが楽しくなる
  - 人を褒める文化を作っていく
- 石川さん
  - 大きく任せることを意識している
  - 自分で考えて、自分でリリースして、良いフィードバックがあれば嬉しい

他にも色々な質問があり、時間オーバーするぐらい盛り上がっていました。

学んだこと

今回のイベントで「顧客志向な開発カルチャー」と「エンジニアが楽しい環境」の両立を目指すために大切なことが見えてきました。

「顧客志向」が「楽しい環境」を作る

f:id:iucstscui:20201224004451p:plain

「顧客志向」と「楽しい環境」は関係性がありそうです。自分の開発したプロダクトで誰かの役に立ちたい。そういう志でエンジニアを目指した方は多いと思います。顧客の声を聞き、開発し、さらに顧客からフィードバックをもらうサイクルが回っていれば顧客志向で楽しい環境になりそうです。

そのためには、何ができるでしょうね。スクラムを採用していればスプリントレビューのタイミングで顧客の声を共有し話し合えたら良いなと思います。そんなとき、POだけじゃなくエンジニアから「こういう機能、どうですか？」とか話せると最高だな。

チームで顧客志向になる

f:id:iucstscui:20201224233348p:plain
かといって、1人ひとり全員が顧客志向は難しいです。エンジニアの個性もあるでしょうし、顧客の声が表れにくい開発もあります。バックエンドの改善やセキュリティ周りなど。こういった開発も貢献が感じられて、結果チーム全体として顧客志向になれると良い。

そのためには何ができるでしょうね。貢献と効果が目に見える形で表されて、良いこと悪いこと含めてフィードバックできると良さそうかなって思いました。良いことはすこし大げさにみんなで褒める！

Who/Why/Whatまで決めてHowからは一緒に進める

f:id:iucstscui:20201225001139p:plain
「POに言われたから作った」ではなく、自分が開発したと胸はって言えるよう「一緒に作った」感覚が欲しいですね。みてねさんも、10Xさんも、細かなタスクじゃなくて大きな仕様を渡して作り方はエンジニアに任せていました。

そのためには何ができるでしょうね。Howは決めずWhy、Whatまで決まったらエンジニアと共に考えるだと思いました。そして、考えるときは共通認識がブレないようにユーザーストーリーを使うと良いでしょう。「[Who]として[What]がしたい。なぜなら[Why]だからだ」の[●●]が埋まった段階で相談して、「じゃあ、こうすれば」「それも良いね。さらに、こうすれば。」「じゃあ、この機能は後回しでも良さそう」と会話の中でHowを決めていく。一体感が生まれ、コミュニケーションの中で予想を超えるHowも見つかると思います。

また、ユーザーストーリーを使えば[Who]が明確になるので自然と顧客に意識が向きます。