Optixという会社で代表をしている黒田（Twitter）です。僕たちのチームではユーザーのヒアリングを活かしたスタイルを重視しています。プロダクトに関する議論がユーザーの行動やインサイトから出発するというスタイルをとっています。

特にプロダクト開発において、エンジニアがユーザーに直接ヒアリングする機会を多く設けるようにしています。僕たちがエンジニアのユーザーヒアリングを重視している理由を紹介してみようと思います。

後回しにされるエンジニアのユーザーヒアリング

エンジニアのリソースは、専門性が高く、代替性が低いので、優先度をつけていくとどうしてもユーザーヒアリングのような「組織知」の獲得に割かれるリソースは少なくなってしまいます。

特にスタートアップのように限られたリソースで、クイックに多くの機能をリリースしていかなければならない状況の会社にとっては仕方のないこととも思います。

しかしOptixではアジャイルな開発形態をとっており、エンジニア自身が、ユーザーへの解像度を高めることによって、本当に開発すべき機能を必要十分な要件で、最速で開発することができると考えています。

なぜエンジニアにユーザーヒアリングが大事なのか

Facebookの創業から発展を描いた映画「ソーシャルネットワーク」では、マークザッカーバーグが交際ステータスの表示機能を思いついて、興奮のあまりそのまま急いで帰宅して実装するシーンが描かれています。

まさに開発者がユーザーのことを理解していることの重要性が詰まっているシーンで、大好きなシーンです。

これは別のシーンです

発想から開発までの速度を最短にする

エンジニア自身がユーザーへの理解が深ければ、施策の発案から実装までの流れをクイックに行うことができます。

背景となるユーザーに対する認識があるためどの程度重要な機能であるのか、どのように使われるのかなどを少ないコミュニケーションで擦り合わせることができるからです。

エンジニアとビジネスサイドが分断されており、ユーザーへの認識がずれていると、要件定義の段階でかなりの時間がかかります。リソースが限られているスタートアップにおいては致命的です。

too muchな要件を避ける

新しいプロダクトを開発するとき、ユーザーにとって必要十分な要件で、素早く機能をリリースしていくことが重要です。

エンジニア自身が、どのようなユーザーに、どのようなシーンで使われる機能なのかを、解像度高く把握していることは、要件定義の際に、開発工数を踏まえて、機能の盛り込みすぎていないかという議論をすることができるようになります。

機能変更による手戻りを避ける

プロダクト開発では、様々な機能をリーンに検証していくため、あらゆる機能はバージョンアップの余地を持ってリリースされます。

初期段階のリリースで、機能にどの程度の拡張性を持たせておくべきかは、手前のスピード感とのトレードオフも含めて議論できなければいけません。

それは詰まるところ、どのようなユーザー体験を届けられなくなるか/届ける余地を残せるかという話であり、やはりこれもエンジニアがユーザーのことを理解できていなければ十分な議論はできません。

コーディングに気持ちが入る笑

ある意味、一番大事なことなのですが、自分が作っているものがユーザーにとってどのような価値になるのかを迫真として理解できると気持ちが乗ってきます。

そのようなユーザーとの接続感はプロダクトを作っている醍醐味でもあり、こういう感覚を全メンバーが持っているチームにしたいと思っています。

最後に

初期のスタートアップにとって、完全に分断された役割などなく、全員でユーザーのことを考えて必要な機能を最速で作っていくということに尽きると思います。

ユーザーのことがわかっていればビジネスサイドからのアイデアだけでなく、エンジニア自身のアイデアを直接開発することもできます。発案する脳と、実際にコーディングしていく体が一体化しているようなチームでの開発はスタートアップにとって非常に重要です。

ご要望あれば、実際のヒアリングの獲得から実施までの流れも紹介しようと思うので、ぜひお問い合わせください。

Optixでは、ユーザーに向き合って一緒にプロダクトを作っていける方を随時積極募集しているので、いつでもご連絡下さい〜！