〜「この機能がほしいか」をユーザーに聞くのは意味がない。開発サイドとビジネスサイドが相互に連携し、真のユーザーファーストを追求する開発プロセスとは〜

プロダクト成長において、ビジネスサイドと開発サイドのシームレスな連携は欠かせない。

リリース2年で300万ユーザーを突破した名刺管理アプリ「Wantedly People」を運営する、ウォンテッドリー株式会社。

同社では、ビジネスサイド5名と開発サイド15名からなるチームで、同サービスの成長を実現している。

その根底には、同社の「真のユーザーファースト」「WHYから始める」といった開発思想がある。

例えば、ユーザーインタビューでは「この機能がほしいか」ではなく、実際の行動やその動機をヒアリングすることで、ペルソナの共通認識づくりと事業アイデアの「種探し」をしているそうだ。

その上で、機能追加の際には「確かめ算」としてのユーザーテストを実施し、手戻りの少ない開発を進めている。

さらに、開発サイドとビジネスサイドの連携をスムーズにするため、全メンバーがGitHubを活用し、機能改善のIssue（イシュー）を共有。

そして、各Issueを立てる際には「WHY・WHAT」のテンプレートを活用し、必ず「なぜ必要なのか」から始めることを基本としているという。

今回は、同サービスのビジネス責任者である逆瀬川さんと開発責任者である相川さんに、ビジネスサイドと開発サイドの連携を中心として、Wantedly People開発の裏側を詳しくお伺いした。

リリース2年で300万ユーザーを超える「Wantedly People」

逆瀬川　僕は2016年4月に中途入社し、同年8月より名刺管理アプリ「Wantedly People」のビジネスサイドに携わっています。

それまでビジネスSNSの「Wantedly Visit」がメイン事業だった弊社にとって、Wantedly Peopleは社内リソースを集中させた一大プロジェクトだったんです。その立ち上げのタイミングで、唯一のビジネス側として加わることになりました。

現在はビジネスサイドにも5人の社員がいますが、2017年の夏頃まではPMから営業、マーケ、PRまで多岐にわたる業務をひとりで回していましたね（笑）。

相川　僕は、Wantedly Peopleの開発サイドのマネージャーを務めています。開発チームには現在、iOS、Android、バックエンドなど全体で20人弱の社員が所属しています。

▼左：相川さん、右：逆瀬川さん

逆瀬川　弊社のミッションである「シゴトでココロオドル人をふやす」を実現するために、「出会う、つながる、つながりを深める」の3つの体験が大切だという考え方があって。

Wantedly Visitを通じた「出会い」をつなぎ、そのつながりを深めるための事業を作りたいと代表の仲がずっと思っていたんですね。そうした想いから、人軸でつながる名刺管理アプリ「Wantedly People」の構想が立ち上がりました。

相川　複数枚の名刺を瞬時に撮影し、データ化できるというアイデアをもとに、エンジニア数人でプロトタイプを作り、検証してみたんです。そこで良い反応を得られたので、3ヶ月ほどの開発期間を経て、2016年11月に正式リリースしました。

それからプロダクトの改善を重ね、この2年で300万ユーザーを超える事業へと成長しています。

コミュニケーションは「WHY」「WHAT」で伝える

逆瀬川　今でこそチーム全体の連携も上手くいっていますが、初期の頃は、ビジネス側と開発チームとのコミュニケーションが難しくて。

例えば、ビジネス側の立場だと「目の前のお客様の課題を解決する」ことが念頭にあるので、「こういう課題を抱えていて、こういう機能がほしい」とエンジニアに伝えがちなんです。

ですが、開発サイドからはそのロジックや数値的なインパクトをきちんと説明してほしいと。最初の頃はそこを伝えることができておらず、慣れるまで結構苦労しましたね。

相川　僕らは「数字とロジックが一致するのか」を実装前に確認することが大事だと思っていて。

そこで職種によらず、何かしらの依頼をする際には「WHY」「WHAT」をシンプルに記載する、全社共通のテンプレートを使っています。

▼WHY・WHATのテンプレート

例えば、「読み取った名刺を職歴と紐づけ、複数枚の名刺を登録できるようにする」というWHATがあります。

それに対するWHYとして、「個人アカウントを作成し、自動でマッチさせていくというサービスの仕様上、別の会社に行っても同一人物だと判断したい」などの背景を書いています。

▼実際の、テンプレート使用例

というのも、コミュニケーションって「WHY」が重要なんですよね。特に依頼をする場合「〇〇してください」という指示になりがちだと思うのですが、その背景を教えてもらわないと、本当に必要かどうかの判断がつかないじゃないですか。

逆瀬川　一方で、それって僕らからすると既に共有できていると思いがちで、同じチームだからこそハイコンテキストに伝えてしまうこともあると思っていて。

なので、テンプレートによって常にWHYから始めることで、意思疎通がスムーズになっていると思います。

真のユーザーファーストは「種探し」と「確かめ算」から導き出す

逆瀬川　また全社共通の開発思想として「ユーザーファースト」があります。これは、「ただユーザーの声を聞く」のではなく、「ユーザー必要としているものを作る」ことを意味しています。

そのために、ユーザーインタビューとユーザーテストを、目的に応じて使い分けています。

まず、ユーザーインタビューはビジネスサイドとデザイナーが一緒に行っているのですが、これは事業アイデアの「種探し」だと思っていて。

ここでは「この機能がほしいか」を聞くのではなく、実際の行動やその動機をヒアリングしています。

というのも、インタビューで大事なのはペルソナの共通認識を作ることと、ユーザーが本当に必要としているものは何か？　というインサイトを得ることだと考えているんですね。

相川　例えばリリース前には、名刺交換の頻度をヒアリングしてもらいました。僕は自社の営業を見ていて1日10枚くらい交換するイメージがあったのですが、実際には大企業の営業マンだと1ヶ月に10枚とかだったりして。

であれば、名刺を読み込むためのプッシュ通知は毎日でない方がいいな、といったインサイトを得ましたね。

逆瀬川　また、新しい機能を実装する際には、ユーザーテストを実施しています。

こちらは、ユーザーインタビューで得た知見や、僕らが考えた仮説が実際のペルソナに合っているのかを確認する「確かめ算」のイメージですね。

例えば、「名刺撮影のボタンがわかりづらい」という仮説に対しては、デザインやチュートリアルを変えてユーザーテストで試してから、エンジニアに実装してもらいました。

相川　僕は、ユーザーインタビューって基本的に「やる気のある人」が答えてくれるものだと思っていて。なので、例えばより良い機能にするためのアイデアには役立つのですが、どの機能をつけるべきかの判断にはあまり役立たないと思うんですよ。

その意味でも、ユーザーインタビューは「種探し」、ユーザーテストは「確かめ算」と考えて、目的を区別することを大切にしています。

ビジネスサイドもGitHubを活用！開発の優先順位のつけ方とは

逆瀬川　Wantedly Peopleでは、プロダクトの大きな方針は経営で決めていますが、日々の小さな機能改善はエンジニア主導で行っています。

営業やカスタマーサポートなどビジネスサイドのメンバーが、拾ってきた顧客の声をGitHub上でIssueとして立てるんです。エンジニアと同じ管理ツールを活用することで、ビジネス側との連携をスムーズにしています。

▼実際の、GitHub ProjectsでIssueを立てているボード画面

相川　チームのビジネス・エンジニアの両方のメンバーで、「ここちょっとイケてないから直したい」という部分を一気に洗い出すような会があって。

ここで上がったIssueを解決する時は、ある程度の優先度は付けるのですが、基本的にその着手順はエンジニア1人ひとりに任せています。

というのも、早急に対応すべきバグなどでない場合、どちらを早く改善すべきかの判断って結構難しいと思っていて。そこで無理に優先度をつけるよりも、直せるところから潰していった方が早かったりするんですよね。

僕は、気持ちが上がっている時にやるのが結局早いと思っていて。過去の経験から言っても、まだ終わっていないのにどんどん新しい要望がくるのって結構辛いんです（笑）。

実際に、開発チームでバグの洗い出しを行った時には、全部で100個くらいのイシューが出てきました。

そこで、エンジニアに対しては「自分の心が動くものを、1人2つ直そう」と。一方のビジネス側には「これだけは直してほしいものを、1人2つ選べる」というやり方で、着手する目安をつけました。

ただ、Issueだけを見てもどう直すべきか明確でなかったり、たまに今は直さない方がいいみたいなものもあったりして。

例えば「メールテンプレートを編集できるようにUIを改善してほしい」という要望があった時に、相手の名前や会社名に置き換わる要素をどう表現するか、など要件定義が結構大変なわりに、そこまで重要な機能じゃなかったりするケースもあります。

そういう時にはデザイナーやビジネスサイドと話をして、実装を一旦見送ることもありますね。このときは、メールテンプレートにデフォルトの文章はいれず、宛先と署名だけを入れて解決するという判断をしました。

逆瀬川　営業側がIssueを立てる際には、この課題は他の顧客にも当てはまるのか、改善することで数値的メリットがあるのか、といった点を考えるようにしています。

ですが、僕らがあんまり考えすぎると「実はすぐ直せる」ような大事な要望も拾えなくなってしまうので、迷ったら上げるようにしていますね。

マネジメントは最小限に。判断のための「選択肢」をもらう

相川　また、開発メンバーのマネジメントは最小限にしていて。個人で判断できる量を、なるべく大きくしています。すると自然に、明確な指示をしなくても、以前から直したいと思っていたことが直っているんですよね。

こうした自律的な組織にするためには、いくつかポイントがあると考えています。

ひとつは、何かしらのプロジェクトをする際に、必ず責任者を立てることです。そして開始時には、なぜやるのか（WHY）、何でやるのか（WHAT）の部分をメンバーに伝えるキックオフミーティングを行っています。

さらに、プロジェクト別の定例ミーティングを開いて、進捗を追うことも大切です。

こうした仕組みの他、メンバーとのコミュニケーションの取り方にも意識していて。それは、何かの問題が生じた時に「わかった、考えておく」と言うのではなく、「どうすれば解決できると思うか、選択肢がほしい」と伝えるんです。

これには、指示を待たず自分で考えてほしいという意図もあるのですが、実際にプロダクトが大きくなってくると、細かいところまで僕も把握できていないことが多いんですよね。

なので、その課題を一番よくわかっている人に解決方法を考えてもらった方が、結果的にいいのかなと思っていて。

その選択肢には、必ずWHY・WHATを書いた上で、どのような思考プロセスかまでわかるように説明してもらうことを基本としています。

逆瀬川　ビジネスサイドも、昨年の夏以降、営業やマーケティングなど、役割ごとにプロフェッショナルなメンバーがジョインしてきているので、基本的に各担当の意思決定に従うという体制を徹底していますね。

また、開発サイドとビジネスサイドの全員が集まる振り返りミーティングを、3ヶ月に1回ほどの頻度で開催し、そこで課題や意見を出し合うことでブラッシュアップしています。

今後も、チーム全体の連携を深めながら、事業の挑戦を続けていきたいと思います。（了）