自己紹介
プロダクトエンジニアリングチームの石川です。 2020年新卒入社で2年目のエンジニアです。 今回の記事では、エンジニアだけで新機能開発・検証を行うPEChallengeについて紹介させていただきます。 ユーザーテストの具体的なやり方まで紹介させていただきますので、最後まで読んでいただければ幸いです！
PEChallengeとは
PEChallengeは「Product Engineer Challenge」の略で、エンジニアだけでHOME'Sの新機能のプロトタイプを作るプロジェクトです。 開発はクリエイターの日という社内制度を活用して、現在は半年ごとに7営業日の活動期間を確保しています。 2020年7月に発足し、プロトタイプを二度作り、現在ユーザーテストを実施しています。
プロジェクトの内容は企業秘密になるため、具体的な内容を書くことはできないのですが、今回の記事ではエンジニアだけで、どのように新機能のプロトタイプを作り、何に悩んだのかを書かせていただきます。
メンバー構成
- エンジニアマネージャー：1人
- エンジニア：4人
ここに記載しているエンジニアは、普段HOME'Sの開発をしているエンジニアの中から有志で集まったメンバーで構成されています。 自分たちで企画を行い技術選定ができるので、そこに魅力を感じて集まったメンバーが多い印象です。
開発を行うのはエンジニアの4人で、エンジニアマネージャーは、MTGの進行を務めプロジェクトの方向性を決めたり、社内での承認対応をしています。
どのように進めているのか？
PEChallengeでは技術的な面ではなく、ビジネス的な面でのHOME'Sの課題をエンジニアリングで解決する事を目的としています。
そのために週次で全員で1時間MTGを開催し、HOME'Sのサービスとしての課題を定義し、エンジニアリングでの解決策を考え、プロトタイプの技術選定を行います。「どんな技術で何を作るのか」が決まると実際に開発に入ります。 開発は半年に一回、7営業日の時間を利用して進めているので、ここで一気に設計からプロトタイプ作成まで行います。 その後ユーザーテストや振り返りを実施し、プロダクトを作り直すのか、拡張させるのかを決めます。 このサイクルが半年で回るように進行しています。
チームがエンジニアメンバーのみで構成されるため、サービスの課題設定からプロトタイプ作成・検証まで行うことができ、非常にやりがいのあるプロジェクトです！
何が大変なのか？
設計が定まっていないと、開発が滞る
このチームメンバーで初めてプロトタイプを作る際に、画面設計、API設計、DB設計を役割分担して行いました。 画面設計(2人)、API設計、DB設計の役割を決めた後に、同時進行で設計を進めてしまいました。 僕はAPIの設計を担当だったので、DB設計ををざっくりと頭で想像しながら、設計を行っていました。 しかしその後にDBの構成に変更を加えることになり、途中まで作り上げていたAPIの設計も大幅な修正をすることになりました。
教訓としては画面設計(2人)、API設計、DB設計を同時並行で進行させずに、一つ一つの設計をメンバーで議論、吟味して着実に進めることが大切だと感じました。
何をMVPにする？
よく新規事業をするときに「MVPを作れ」と言われる事が多いかと思います。 MVPとは「minimum viable product」の略で、「価値を提供できる最小限のプロダクト」という事です。 今回のプロジェクトでは何を「実用的な最低限機能」とするのかということに度々つまりました。 新しい商品を作ろうとすると、どうしても「あんな機能も欲しい」とたくさん機能を追加したいという気持ちになります。 プロダクトを作る上で多くの人がこの問題に悩むかと思うのですが、僕たちも同じ問題に悩まされました。
そこで僕たちは再度課題に戻るために、「誰の、どんな課題を解決するのか」という問題に対して、以下の手順でアイデアを精査しました。
- そもそも最も大きな課題は何か？
- 今の方法でその課題解決できているか？
- その方法は抵抗感なく使用してもらえるのか？
結果として、最も大きな課題だけを解決するためのMVPを作成する事ができました。
しかしここで安心してはいけません。 なぜならば、MVPを作成した後のユーザーテストを行った時に、再度アイデアが発散するからです。 ユーザーテストをすると、テスターの方から「こんな機能があったら嬉しいなー」などと意見をいただく事が多々あります。 それは非常にありがたい事なのですが、その意見を全て反映させていると、結局また「誰の、どんな課題を解決するのか」という部分がうやむやになってしまいます。
ですので、ユーザーテストで今回開発した機能が課題解決に結びついているのかを最優先で確認し、 ユーザーテストの結果を踏まえて再度メンバーで上記3つの手順に戻ることが大切です。
全てのステークホルダーを重んじれているか？
LIFULL HOME'Sでは新機能を作る際に ユーザー(HOME'Sを使って住み替えをする人)とクライアント(HOME'Sに物件を載せている不動産会社) のどちらに対してもメリットが出せているかを考える必要がありました。 両者にとってメリットがある状態にする事はかなり難しく、解決策の立案に苦労しました。どちらの立場から見ても良いプロダクトにするために、僕たちは同じプロトタイプのテストを、ユーザー側とクライアント側の両方で行いました。 プロトタイプに対する両者の意見を取り入れて、どうすれば両者を立てたプロダクトができるのかを模索しております。
両者によって良いプロダクトを考えると、またアイデアが発散して混沌とした状態になってしまうので、 ユーザーテスト完了後、再度「誰の、どんな課題を解決するのか」という問題に戻りたいと思っています。
ユーザーテスト
PEChallengeのユーザーテストの手順・結果は下記のようになりました。
手順(PEChallengeのユーザーテスト)
- テスターは、今回の新機能で解決する課題を持っていそうかで選定
- テスター1人に対して対面でユーザーテストを実施(約30分)
- 1人のユーザーテストにチームメンバーが全員参加し、司会・書記を分担して行う
- 司会(PEChallengeメンバーの一人)がプロトタイプを使用する手順を一つずつ説明して、手順が終わる毎に質問する
- 「OOというボタンを押してください」
- 「期待通りに動作しましたか？、どのような動きだと良いと感じますか？」
- 「この機能に5段階で点数をつけるなら何点ですか？」
結果(PEChallengeのユーザーテスト)
- 1時間かけて2人に対してヒアリング取得
- 使い方を丁寧に説明しながら質問を重ねたので、機能を理解してもらった上で回答してもらえました
- テスターの方からの質問に対して、僕たちが随時回答することで、「それだったこんなアイデアの方が良くないですか？」という提案を頂くことも多く、質の高いフィードバックを得ることができました
テスターの方に手順を一つ一つ説明し、その後に実際のプロトタイプの操作を実施してもらい、最後に質問をしていたので テスターの方が機能をしっかり理解した状態でヒアリングをする事ができました。 また1人のテスターに対して十分な時間を確保し、双方向にコミュニケーションをとれたため、より深くまで意見を聞くことができました。
自作アプリケーションで行ったユーザーテストとの比較
個人的な話になりますが、僕もプライベートの時間で自作アプリケーションを作成して、友人にユーザーテストを行うことがありました。今回PEChallengeで行ったユーザーテストと自作アプリケーションのユーザーテストの違いを比べて、学べる部分があったので、ここで少し書かせていただきます。
手順(石川の自作アプリケーションで行ったユーザーテスト)
- LINEで複数の友人に、自作アプリケーションのURLとGoogle form(アンケート)のURLを共有して回答してもらう
- 友人の選定は協力してくれそうかで判断
- Google formに自作アプリケーションに対するアンケートを明記
- アンケートの冒頭で自作アプリケーションの特徴と使用手順をざっくり説明
- 質問内容は以下2つ
- 「このアプリを使うとOOという課題が解決された状態になりますか？」
- 「このアプリを空き時間で使用したいですか」
- 選択肢を5段階で用意してチェックして回答してもらう
結果(石川の自作アプリケーションで行ったユーザーテスト)
- 1時間LINEで複数の友人にテストの依頼を行い、13件の回答を取得
- 機能と使い方の説明がざっくりであったため、自作アプリケーションの使い方自体がわからないという声が殺到
自作アプリケーションで実施したテストでは手軽に多くの回答を得ようとするあまり、テスターの方が機能を理解しないままテストが終了してしまう事がありました。 設計思想や使用用途を激詰めするような電話もいただきました笑(良い友人なので大事にします)。このようにテスターの方が感じた疑問に対して、双方向でコミュニケーションが取れなかったため、より細かいフィードバックを得ることができませんでした。
またテスターの選定においても違いがありました。自作アプリケーションのテストでは無差別に行い、PEChallengeのテストでは、開発した機能を使用したいと想定される人を中心に選定しました。 そのため後者のユーザテストの方が、テスターの方が自分事として捉えてテストを受けてくださったので、より深いフィードバックを得る事ができました。
今回のPEChallengeのユーザテストは不特定多数の人から手軽に回答を得る事ではなく、新機能を使うと想定される人に深く質問する事を意識していました。 そのため事前に「どのようにすれば実際に使用しているように感じられるのか？」や「どういう手順ならば機能を理解してもらえるか？」などを考え、 インタビューの流れや質問内容を吟味し設計していました。このように目的に合わせてテスト設計を行う事が必要な回答を得るために重要なのだと感じました。
まとめ
約1年間このプロジェクトをやってみて、使ってもらえる新機能をつくる事がこんなにも大変なのかと感じました。 実装の前に設計を確定させる事、迷ったら常に課題に立ち戻る事、適切なユーザテストを実施する事を肝に銘じてこれからも開発したいと思います。 今後新規事業や新機能開発をされる方やそれらで困っている方々のご参考になれば幸いです。
またLIFULLでは、PEChallengeのように「エンジニアとして経営をリードする」を体現したい方を募集しております。ご興味のある方はこちらのページもご覧ください！
