この記事は、NTTテクノクロス Advent Calendar 2021の5日目です。
NTTテクノクロス デジタルトランスフォーメーション事業部の中島です。
普段はコンシューマ向けモバイルアプリをアジャイルで開発しています。
はじめに
みなさん、お仕事ではどんなプロジェクト管理サービス（ツール）を使っていますか？
世の中には色々なサービスがありますよね。
これらのサービスにはGUIでなくAPIによってチケット管理する機能も備わっています。
今回の記事ではそれらのAPIを利用することで、自分たちの開発サービスに対するユーザからのFeedback情報をプロジェクト管理サービスに連携し活用する方法について紹介します。
ユーザからのフィードバック情報は宝の山
ユーザからのフィードバック情報は宝の山ですね。
ダイレクトに受け取ったユーザの要望・不満を元に、CX改善、機能の調整・追加、ユーザビリティ向上を実施し、CRR(顧客維持率)の向上を狙えます。
ユーザのフィードバックの受け取り方は色々とありますが、アンケート、ストアレビュー、SNSがメジャーではないでしょうか。
- アンケート・問い合わせ
- Microsoft Forms
- Google Forms
- ストアレビュー
- Google Play
- App Store
- Microsoft Store
- Galaxy Store
- SNS
フィードバックからUser Storyを作成
フィードバックからUser Storyを作ってMVPを開発する流れを見てみましょう。
ユーザからのフィードバックがあったとします。
これを見て、PMやDesigner, Researcherがリサーチ、仮説検証等をおこない、User Storyを作ります。
そして、そのUser Storyを見たDeveloperがプロダクトを開発します。
だいたいこんな感じじゃないですかね。
ただ、この図を見ると、ユーザのフィードバックとDeveloperの距離が離れているように感じられます。
ユーザからのフィードバックとDeveloperの距離
Developerがユーザからのフィードバック情報を直接知らなくてもUser StoryからProductの開発は可能です。また、Iteration Planning Meeting等で、Storyの価値や背景の説明にフィードバック情報を紹介されることもあるでしょう。
ですが、プロダクトへの興味や当事者意識を高めるためにも自分たちが開発しているユーザがどう考えているのかを知ることは有益であると考えます。
フィードバック情報をプロジェクト管理サービスに連携
改善方法の一つとして、各種フィードバックはそのままBacklogサービスに取り込むことを提案します。
きょうび、色々なシステムが情報を取得・登録するためのAPIやツールがあります。
ですから、ユーザのフィードバックをAPI・ツール経由で取得し、Azure BoardsやJira等のProduct BacklogサービスにAPI経由で登録可能です。
ユーザのフィードバック情報をそのままBacklog内に取り込んで、それとUser Storyが関連づけられるようにしましょう。
ここで注意したいのはFeedback情報とProduct Backlogはプロジェクトを分けて管理できるようにしたいです。
同一のプロジェクト内で管理するとProduct Backlogがぐちゃぐちゃになります。フィルターで分けるような運用にするぐらいなら別プロジェクトで管理しましょう。別プロジェクトで扱えば、そのフィードバック用プロジェクトではカスタマーサポート担当がユーザへの返信を考えたりもしやすいです。
Microsoft Forms から Azure Boards へ Power Automateを使った連携例
アンケートの用意
今回は以下のようなアンケートを作成しました。
Power Automate による連携
世の中には色々なサービスとサービスをつなげる仕組みがあります。
Botだったり拡張機能として提供されていたりなどなど。
できれば既に世の中にあるものは一から作らない方が無駄がないですよね。
そんなわけでPower Automateの既存テンプレートを使った連携例を示します。
使用するテンプレートはCreate AzureDevOps workitem and send email when Microsoft Form is submittedです。
このテンプレートはMicrosoft Formsに投稿されたタイミングでAzure BoardsへのItemの投稿と Office 365 Outlookにメールを送信してれるFlowがあります。今回はメールは省きました。
それぞれのシステムにサインインすると、アカウントに紐づいた情報がプルダウンで表示されます。
Forms側の設定では対象とするフォームIDを指定し、Azure Boards側の設定では組織、プロジェクト、作業項目はプルダウンで指定し、タイトルと説明はFormsのパラメータを指定します。
設定を保存したらFormsの投稿ごとに自動で実行されるようになります。
アンケートの投稿
Power Automateによって登録されたAzure BoardsのWork Item
投稿した内容がFeedback用プロジェクトのWork Itemとして新規登録されます。
Product Backlogでバグ票を起票
Product Backlog側のプロジェクトでBugを起票するときに関連付けます。DeveloperがBugに着手するときに元となったアンケート内容を確認できます。
Product Backlogとフィードバックを紐づける効果
Product Backlogとフィードバックの相互参照が容易
フィードバックがProduct Backlogと同じサービス上で管理されていることで相互参照が容易です。
Developerがユーザを意識するようになり、サービス全体のコンテクストが深まる
User Storyを作っても、ペルソナを理解せずユーザを意識しないで開発するDeveloperはまあまあ見かけます。
ユーザからのフィードバックを見ると、ユーザを意識しやすいです。普段自分が意識しないところについてコメントがあるとサービスのコンテクストも広がります。
また、不具合報告であってもサービスの評価が高いユーザなどからは期待されている、叱咤激励されていると受け取りモチベーションが上がるかもしれません。
これだけでDeveloperのコンテクストが上がるわけではないですが、そのきっかけを作ることは大事です。
カスタマーサポート担当と開発チームが協力しやすい
バグ報告の場合、Feedbackに関連するBug Storyが修正されたタイミングでカスタマーサポート担当に通知が飛び、ユーザに返信する、なんて運用もしやすいです。
ユーザからのフィードバック情報を定期的に見ているDeveloper側から、フィードバック情報が過去のバグと関連しているか等、積極的にカスタマーサポート担当と連携することもあります。
声なき評価
一般的にフィードバック情報を寄せるのは不満を持っている人が多いですし、不満を持っていても手間をかけてフィードバックをくれるとは限りません。
ここではそのような声がないユーザの評価をどのように拾っていくかを検討します。
満足している人のフィードバック
満足している人にフィードバックをしてもらうためには、特定の操作の後にアンケートやレビューを投稿する画面に遷移する仕掛けが一般的です。
GooglePlayにはIn-App Review API、AppStoreにはSKStoreReviewControllerを使って、そのようなことを実現する仕組みがあります。
大事なのは出すタイミングと頻度です。あまり頻繁に求めてしまうとそのことに不満を持ってしまいます。
検索できない不満
アプリ内検索で検索結果から次の画面に遷移せず、他のキーワードで再検索した場合、ユーザが想定したキーワードで満足な結果が得られなかったという可能性があります。
こういった情報をログで収集してフィードバックとして登録することも良いかもしれません。
チャットボットとコミュニケーションできない不満
チャットボットサービスではユーザが入力した自然言語を解析し、複数の文脈候補のなかからスコアが高いものを問い合わせ内容として回答情報を作成します。
入力された自然言語の解析結果でスコアが高いものがなかった場合、機械学習等が不足している可能性があります。
それらをログとして収集してフィードバックを登録し、機械学習を強化するStoryを検討しても良いかもしれません。
まとめ
- ユーザからのフィードバック情報は宝の山
- ユーザからのフィードバック情報をProduct Backlogと同じサービス(Azure Boards等)内に入れよう
- Product Backlogが汚れないようにフィードバックはプロジェクトを分けよう
- Developerのプロダクト/サービスのコンテクストを高めるきっかけになるかも
- ユーザからの声なき評価もフィードバックとして取り込んでいこう
- チームメンバ全員が当事者意識を高めて、サービス、および、チームを育てていこう