Gaudiy Tech Blog

Gaudiyの技術、開発組織、カルチャーについてお伝えするブログです

文化人類学の手法を用いたユーザーインタビュー実践のコツ

f:id:gaudiy:20211129210805p:plain

こんにちは!エンタメ領域のDXを推進するブロックチェーンスタートアップ、GaudiyでプロデューサーをしているRyosuke(@RNmlc1)です。

プロダクト開発において「UXリサーチ」を実施している企業は多いと思いますが、Gaudiyでもユーザー中心のプロダクト開発を進めるため、積極的に取り入れています。

なかでも、N1でユーザーのメンタルモデルを深掘る「デプスインタビュー」をよく実施しており、プロデューサーとデザイナーが中心となって取り組むことも多いです。

前回のTech Blogでは主にフィールドリサーチをご紹介しましたが、本エントリでは、デプスインタビュー実践のコツや、どのようにインサイトを作り出しているかについて詳しくお伝えしてみます。

ユーザーインタビューってどうやるの? ユーザーインタビューしてはいるけど、うまくインサイトが導き出せない…といった課題感のある方に、ご参考になると嬉しいです!

なぜユーザーインタビューを大事にしてるのか

はじめに、なぜGaudiyではユーザーインタビューを大事にしているかについて、簡単にご説明します。

Gaudiyが開発・提供するファンコミュニティサービスは、マンガ、アニメ、ゲーム、アイドル、スポーツなど様々なエンタメ領域のIP(知的財産)を扱っていますが、当然ながら、そのIPごとにユーザーの属性が全く異なる独自の文化圏が存在します。

そうしたユーザーの方々に、GaudiyのバリューのひとつでもあるFandom(ファンを喜ばせる体験)を届けるためには、どういう属性のユーザーが、普段どんな活動をどういう感情で行っているのかを理解しておく必要があります。

そこでGaudiyでは、ユーザーの「メンタルモデル(※)」から良質なインサイトを抽出し、プロダクトや企画の方向性を決定していくことを大事にしており、そのための「ユーザーインタビュー」をよく実施しています。

※メンタルモデル…認知心理学の用語で、人間が無自覚のうちに持っている認識と行動のパターンのこと。

ユーザーインタビューは、「探索」「検証」の目的によって大きく2つに分類され、それぞれに様々な手法が存在しますが、Gaudiyでは、N1でより深いインサイトを得られる「デプスインタビュー」を実施する場合が多いです。

そこで今回は、マンガアプリ「GANMA!」さんとの共同プロジェクト「GANMA!コミュニティ」におけるデプスインタビューを例示しながら、Gaudiyで普段どのようにユーザーインタビューを設計、実施し、インサイトを抽出しているのか、その具体的なプロセスをご紹介できればと思います。

デプスインタビューの全体プロセス

今回は、GANMA!コミュニティを利用しているユーザーの方5名を対象に、それぞれ約1時間ほどデプスインタビューを実施しました。

インタビュイーの選出については、コミュニティの利用頻度や、普段の活動内容など、さまざまな軸で異なるタイプの方々にお声がけし、ご協力いただきました。

デプスインタビューの設計・実施から、インサイト抽出までの一連のプロセスは以下になります。

  1. メンタルモデルの仮説を元にしたインタビュー設計
  2. インタビューの実施
  3. 個々のインタビュー記録に、メンタルモデルの解釈を加えて整理
  4. すべてのインタビューをまとめ、ペルソナを分類
  5. ペルソナごとにユーザーインサイトを作り出し、モデリングで可視化

f:id:gaudiy:20211126163053p:plain

それでは、各プロセスにおいてどのように実施しているのか、具体的な方法とそのポイントを次からご紹介していきます。

1. メンタルモデルの仮説を元にしたインタビュー設計

まずは、インタビュー対象のユーザーさん(以下、ユーザー)のメンタルモデルを考慮した質問項目を設計します。

具体的には、普段のコミュニティ活動やTwitterなどのSNS上での活動をリサーチし、ユーザーの特徴的な発言や行動を拾います。

これらを元に「このユーザーはこういう発言をしているから、こんなメンタルモデルを持っているんじゃないか」といった仮説を話し合いながら、質問を設計していきます。

実際のインタビューの設計手順としては以下です。

  1. インタビュー対象ユーザーの、コミュニティ(プロダクト)での活動や、TwitterなどSNS上での活動をリサーチする
  2. ユーザーが普段どういう活動しているかを付箋で挙げていき、いくつかのトピックを抽出する
  3. ユーザーの言動から仮説を立て、インタビューで掘りたい箇所に見当をつける
  4. 仮説に関する質問を列挙し、トピックに紐づけて整理する
  5. 自分たちが聞きたい質問を追加する
  6. それらをシーケンスに並べる(会話が連続しそうな順番、関連性を意識する)

f:id:gaudiy:20211126145714j:plain

👆上記の手順に従って作成した、質問シーケンス

このように、事前に対象ユーザーのメンタルモデルの仮説を立て、インタビューでどこを掘るべきかの見当をつけておくことが大事です。一方で、実際のインタビューでは質問シーケンスは参考程度に留め、会話の流れに合わせて質問の順番や内容を変えています。

2. インタビューの実施

事前準備ができたら、インタビューの実施です。ここでは、インタビューにおいて気をつけているポイントを4つほどご紹介します。

2-1. 相手との「ラポール形成」を大事にする

信頼関係が築かれている状態のことを心理学の用語で「ラポール形成」と呼びますが、インタビューにおいても相手とのラポール形成は重要です。

相手の感性に対して興味・共感を示すことで、ユーザーが自分の話に興味を持ってくれていると感じることができ、より深いストーリーを聞き出すことができます。

ここでのコツとしては2つあって、ひとつは「尋問形式にならない」ということ。淡々と質問をしていくと尋問のようになり、ユーザーが心地よく発言することが難しくなってしまいます。結果的に、本来のメンタルモデルを引き出せない、という失敗にもつながってしまうので注意が必要です。

2つめに「インタビューの設計段階で盛り上がるポイントを作っておく」ということ。設計段階の洗い出して多くでた質問項目は、ユーザーにとっても中心の活動である場合が多く、発言しやすいポイントになります。こうしたポイントを把握し、そのための質問や話題を用意しておくことで、インタビュー中の盛り上がりを作りやすくなります。

2-2. ひとつの話題を深く掘り下げ「メンタルモデル」を探る

話の表層だけをすくわないことが大切です。ユーザーが「〇〇するのが楽しい」と言ったとき、〇〇がその人にとってどういう活動、どういう意味を持つのか。ここが重要なメンタルモデルになります。

これを引き出すためには、このメンタルモデルの解釈ができるまで一次返信で終わらせず、ひとつのトピックについて掘り下げる、枠を広げることが重要です。

その掘り下げのコツとしては、以下があります。

  • 具体的なエピソードを聞いて、過去の描写を引き出す(メンタルモデルは過去の体験によって構築されるため)
  • どのように? どう思ったか? を繰り返し尋ねて、その時の状況や感情を掘り下げる

2-3. 解釈の確認と、その反応から掘るべきポイントを見極める

話を掘り下げていき、ある程度見えてきたら、次に「〜ということですかね」とメンタルモデルの解釈を相手に当ててみます。

ここで重要なのが、この時の相手のリアクションを見て、その解釈が正しいかどうか、つまり掘るべきポイントなのかどうかを見極めることです。

たとえば、解釈を確認する質問に対して、ユーザーの返答が「たしかに〜」と続いた場合、これは元々ユーザーの考えにないリアクションなので、その解釈は外れている場合が多いです。

反対に、「そうそれ!」などテンションが明らかにあがった場合などは、メンタルモデルの解釈が正しかった時の特徴のひとつです。この場合は、このリアクションの後に出てくるワードがキーワードになる可能性が大きいです。

このように解釈の確認を挟みながら、それが正しければ深掘るべきポイントになり、それが正しくなければ別の路線に方向転換します。基本的には、「ひとつの話題を掘り下げる→解釈をぶつける→深堀り or 方向転換」を繰り返していくことになります。

2-4. 先入観が入った質問やワードをださない

聞き手の先入観が入った言葉を用いると、間違った方向にユーザーの答えを誘導してしまいます。正確なメンタルモデルを掘るためには、自分の先入観を取り除くことが重要です。

そのためには、自分たちが使う専門用語などは控え、普段ユーザーが使っているワードにインタビュアーが合わせるなどの工夫も大切です。

3. 個々のインタビュー記録に、メンタルモデルの解釈を加えて整理

インタビューを終えたら、記録を整理して、解釈を加えていきます。

インタビューの記録においては、ユーザーの発言に加えて、相手のリアクションや、聞き手の解釈も合わせて記録することが大事です。

文化人類学では「Thick Description(厚い記述)」という言葉もありますが、インタビュー中は、ユーザーが発していた言葉や反応をそのまま記述するだけでなく、なぜそのように行ったのか、根拠や背景、メンタルモデルの解釈も合わせて記録していきます。

次に、ユーザーの発言やメンタルモデルの解釈を視覚的に整理していきます。

Gaudiyでは、ホワイトボードツールのmiroを活用して、発言の解釈や重要なポイントを、インタビュー出席者で話し合いながら整理していきます。基本的には「KJ法」のような方法でグルーピングしたり、「この時にこういう行動をとる」など実際の行動フローをストーリーでまとめたりしています。

f:id:gaudiy:20211126145751j:plain

👆実際のインタビュー整理

4. すべてのインタビューをまとめ、ペルソナを分類

こうして、全員分のインタビューが終わり、それぞれの情報を整理した上で、ペルソナを分類します。

インタビューで出てきたキーワードをもとに、どういう活動の軸があったかを話し合いながら、属性の分析や、ユーザーのグルーピングを進めていきます。

GANMA!コミュニティでは、対象ユーザー5名の共通点や違いなどを抜き出し、その特徴や関係性を整理していくと、大きく3つのペルソナに分類されました。

f:id:gaudiy:20211126150111j:plain

👆実際に分類したコアユーザーのペルソナ

5. ペルソナごとにユーザーインサイトを作り出し、モデリングで可視化

さいごに、3つのペルソナのまとめとして「共感マップ」を作成します。

このモデリングを行うフェーズでは、以下のようなプロセスで思考しています。

  • メンタルモデルを表す言動を中心に、断片的な個々の情報からインサイトを作り出す
  • インサイトのロジックが通るかを検証するため、具体的なファクト(ユーザーの実際の言動)で裏付けを取りに行く
  • 重要なインサイトを中心にモデリングでまとめる

共感マップは、ペルソナの視点での感情・行動や、ペイン・ゲインなどをマップ化して整理したものです。可視化しておくことで、ペルソナのニーズ把握に役立ちます。

f:id:gaudiy:20211126145833p:plain

👆実際に作成した「共感マップ」

また他にも、「文化モデル(Cultual Model)」というモデリング手法を活用する場合もあります。

f:id:gaudiy:20211126145947p:plain

👆実際に作成した「文化モデル(Cultual Model)」

文化モデルは、インタビューで登場した人物やコト、モノに対する、対象ユーザーのメンタルモデルや、それぞれがどのように影響しあっているかの関係性を可視化するものです。

今回ご紹介した共感マップや文化モデルの他にも、メンタルモデル・ダイアグラムやKA法など、様々なモデリング手法が存在するので、目的に応じて選択すると良いと思います。

また近年、海外を中心にReseachOpsの概念が広まっていますが、 GaudiyでもUXリサーチレポジトリ構築の一環として、モデリングで可視化されたユーザーインサイトをNotionにストックしていくという運用も始めています。

さいごに

今回はGANMA!コミュニティの事例をもとに、ユーザーインタビューとインサイト抽出について、具体的なプロセスや手法をご紹介させていただきました。

GaudiyではこうしたUXリサーチをもとに、プロダクト設計のフェーズから、ビジネス、エンジニア、デザイナーなどの関係者全員がコラボレーションし、UX起点で開発を進めているので、この辺りはまた追ってお伝えできたらと思います。

Gaudiyでは、今回ご紹介したユーザーインタビュー以外にも、目的やフェーズに応じて様々なUXリサーチを実践しています。UXリサーチやユーザー中心のプロダクト開発にご興味のある方はぜひお話ししましょう〜!

meety.net

12/3(金)にUXリサーチについて何でも聞けるグループトークも開催します!

meety.net

オープンオフィスやオープン勉強会もやってるので、遊びにいらしてください!

www.notion.so

地下アイドルのライブに潜入!プロダクト開発に活きるユーザーリサーチ

f:id:gaudiy:20211119181910p:plain

こんにちは!エンタメ領域のDXを推進するブロックチェーンスタートアップ、GaudiyでデザイナーをしているSuma(@piyojirou224)です。

このTech Blogはいつもエンジニア中心に投稿していますが、今回は初のデザイナーからのエントリです!プロダクト開発で大切な「ユーザーリサーチ」をテーマに書いてみました。

ユーザーリサーチは多くの手法があり、書籍で読んだらなんとなくわかるものの、実践するとなると生の情報って意外と少ないですよね。

そこで今回は、Gaudiyが実際のプロジェクトで実施した2つのユーザーリサーチについて、具体的なプロセスや意識したこと、学びなどをまとめてみたいと思います!

ユーザー中心のプロダクト開発や、ユーザーリサーチに関心のあるPdM、デザイナー、エンジニアのみなさんにご参考になると嬉しいです!

1. ユーザーリサーチとその種類

ユーザーリサーチとは「ユーザーの特性や物事を達成する際のモチベーションや言動・行動を学ぶために行う調査」のことです。(※こちらの記事が詳しいです。)

簡単に言うと、ユーザーのことを深く理解するために行われる調査になります。

ユーザーリサーチを大きく区分すると、「Generative Studies(生成的調査)」「Evaluative Studies(評価的調査)」に分けられますが、前者がユーザーの価値観や課題を探り、ビジネス機会を見出すことを目的とする一方で、後者は仮説課題がそもそも存在しているか、考案したソリューションは機能するのかを検証します。

具体的な手法としては、アンケートやデプスインタビュー、フィールドワーク、エスノグラフィーなどが「Generative Studies(生成的調査)」、プロトタイプテストやユーザビリティテストなどが「Evaluative Studies(評価的調査)」にあたります。

f:id:piyojirou224:20211119174521p:plain

生成的調査と評価的調査

ユーザーリサーチといっても多種多様なので、何を検証したいかによってその手法を使い分けることが大切です。

2. Gaudiyのプロダクト開発におけるユーザーリサーチの役割

Gaudiyでも、プロダクト開発のフェーズごとに様々な手法を用いてユーザーリサーチを行っていますが、なかでもユーザーの価値観や課題を探りにいく「Generative Studies(生成的調査)」を重点的に行っているのが特徴的かなと思います。

なぜかというと、Gaudiyは「FPaaS(Fan Platform as a Service:エフパース)」という、ファンとIPコンテンツを直接つなぐプラットフォームサービスをSaaS的にエンタメ企業に提供していますが、そのプロダクトのユーザー属性はIPごとに大きく異なるからです。

たとえば、身の回りの人を思い浮かべてみてほしいのですが、マンガのファンとアイドルのファンでは、雰囲気や趣味など結構違うのではないでしょうか? また、同じ「マンガ」というカテゴリであっても、作品のジャンルによって年齢や性別などファン層は異なるはずです。

f:id:piyojirou224:20211119174831p:plain

だからこそ、プロダクトを通じてファンに最良の体験を届けるために、個別IPのファンを深く理解することが大切です。その上で、クライアントとも共創しながら、ファンの特性に合わせて機能をカスタマイズしています。

またGaudiyでは、NFTやブロックチェーンなどの新しい技術をプロダクトの裏側で活用しているため、機能を開発する前に「どのような体験にすればファンに受け入れてもらいやすいか」を十分に検討する必要があります。

そこでサービスの企画前や、機能要件の設定前、リリース後などのタイミングで、インタビューやフィールドワークなどを中心としたユーザーリサーチを実施しています。また開発においては、このユーザーリサーチで作ったペルソナをもとにユーザーストーリーマッピングを作成し、開発要件の洗い出しをチームで行っています。

3. TIFのプロジェクトでユーザーリサーチを実施した背景

ここからは、実際のプロジェクトを例にしてご紹介したいと思います!

今年10月に開催された、フジテレビ主宰のアイドルフェス「TOKYO IDOL FESTIVAL(以下、TIF)」のプロジェクトでは、サービスの企画案を具体化していくために6月頃からユーザーリサーチを始めました。

その理由としては、大きく3つあります。

ひとつは、いままでGaudiyが提供してきたマンガやゲームのコミュニティとは、ファン層が違うことが予想されたこと。

ふたつめに、複数のIP(アイドル)をひとつのコミュニティで扱う形は今回が初めてだったので、大規模な改修が必要だったこと。開発コストをなるべく抑えつつ、ファンのニーズを満たすために、どんなファンがいて、なにに価値を感じるのかの理解は必須でした。

最後に、企画案を出すにあたり、取っ掛かりとなるヒントがほしかったこと。TIFとしてもオンラインコミュニティは初の試みだったため、これまでの知見がなく、ゼロベースで企画を立てなければいけませんでした。

こうした理由から、まず「どのようなファンがいて」「どんなライブの楽しみ方をしているのか」を探るために、アイドルライブでのフィールドリサーチ(観察&インタビュー)と、社内のペルソナに対するデプスインタビューを実施することにしました。

4. 実際のユーザーリサーチの進め方

では、具体的にどのようにリサーチを進めていったのか、そこで何を意識していたのかを思い出しながらまとめてみます。

4-1. 潜入フィールドリサーチ(観察&インタビュー)

まずフィールドリサーチとして、地下アイドルのライブと、TIFに先行する「mini TIF」のライブに潜入し、そこでユーザーの観察とヒアリングを行いました。

たとえば地下アイドルのライブ会場では、

  • 場内の人の分布
  • ファンの服装や雰囲気
  • 前方と後方の座席ではどんな人が座っているか
  • 推しアイドルの出番前後でどんな反応をしているのか

といった「状態」「行動」を観察しました。(ちなみに推しを聞き出すのは、ひとりで来ていらっしゃる方の隣に座って話しかけるのがスムーズでした。)

この観察から、たとえば「推しのグループの出番中ずっと反応している人もいれば、推しがステージの前に来た時だけ控えめに反応する人もいる」「グループの入れ替わりにより観客も入れ替わる(出番後の物販のためすぐ会場の外に出る)」といったことがわかりました。

さらに、その行動の背景を探るため、推しの出番が終わった2名のファンの方にお声がけして、直接インタビューをさせていただきました。

具体的には、以下のような質問をしました。

  • 応援し始めたきっかけはありますか?
  • どのくらいの頻度でライブに参加されていますか?
  • 周囲より控えめな応援だった気がしますが、いつもと同じですか?
  • アイドルフェスに行ったことはありますか?

こうした質問を通じて、おふたりの共通点として「元々は地上アイドルが好きだったけど、友人に教えてもらったり、ライブ配信アプリで可愛い子を見つけてハマった」という経緯があることがわかりました。

また、元の地上アイドルに戻らない理由としては、「距離感の近さ」「実際に会って話せること」「写真を撮れるから」といった回答があり、ファンが地下アイドルに感じている価値の共通項などを導き出すことができました。

ヒアリングを通じて得られたペルソナは、社内で「楽しんでもらいたいのはこういう人」というイメージを共有するために、簡単にスケッチをしてまとめました

f:id:gaudiy:20211119173605p:plain

実際のスケッチ

4-2. デプスインタビュー(社内インタビュー)

次に、アイドルファンの中でも、アイドルフェスに行くようなペルソナの解像度を上げるため、社内でTIFに何度か参加したことのあるメンバーにデプスインタビューを行いました。

社内インタビューでは、信頼関係のベースがあるため、より深いところまで聞けるというメリットがあります。

この際、ヒアリングで気をつけていたのは、自分の解釈を「こういう認識であっていますか?」と当ててみて、返ってくる反応を見ることです。というのも、結局ユーザーの認知の中で体験の良し悪しを判断されてしまうため、こちらの推測が「あくまで相手の認識に沿うものであるのか」を確認することを意識していました。

f:id:gaudiy:20211119172604p:plain

実際のインタビュー時のメモ

そして、1時間ほどのインタビューを通じて「この人からみたアイドル界隈はどういう関係になっているのか」というCultural Model(文化モデル)を作りました。

このCultural Modelをもとに、インタビューから得られた情報を整理し、関係性を可視化することで、のちに企画をする際のファンの体験設計に役立てました。

f:id:gaudiy:20211119172651p:plain

実際につくったCultural Model

こうした手法の異なるアプローチからユーザーのことを理解した上で、実際の企画を詰めていく際には、よりライトにリサーチできるSNSも活用しました。

例えば「エンタメ、NFT」といったワードで検索して、それに対して一般の人はどんな反応を見せているのか、またこれをアイドルファンに提供したらどんな反応になりそうか、といったことを調べ、企画の参考にしていきました。

5. ユーザーリサーチから得た学び

改めて振り返ってみて、ユーザーリサーチにおいて大事だと思うポイントをまとめてみます。

① なるべく多くの一次情報を得ること

まずは、なるべく多くの一次情報を得ることが大事です。対象となる人や状況の観察やインタビューなどを通じて、信頼できる一次情報を社内に持ち帰ってくることがファーストステップになります。

② 発言や行動の「特徴」に気づくこと

次に、一次情報を得ていく中でその特徴に気づくことが大事です。「普通はこう思うんじゃないか?」「こう行動するんじゃないか?」という仮説をなんとなく持った上でインタビューを行うことで、相手の発言との違いに気づくことができます。

また、話の矛盾点もヒントになります。たとえば「人の目なんて気にしない」と発言していた人から、別の文脈では「間違いを指摘されたら怖い」といった発言が出てきたりすることがあります。

この矛盾には、その人なりの背景や認知(=メンタルモデル)が潜んでいることが多いので、それを深掘っていくことでペルソナの特徴に気づくことができます。

③ フラットな目線で分析すること

最後に、分析の際には、個人のバイアスを入れないように気をつけることが重要です。

最初からフラットな目線を持つのはなかなか難しいので、場数を踏んだり他の人からフィードバックをもらったりして、認知の歪みに気づくことが必要になります。実際に、数人が同じ対象を各々で分析すると全然違う見方をしていることがあるので、自分の歪みに気づくきっかけを得やすくなるかなと思います。

ペルソナの発言や実際に目にした反応(=一次情報)を軸にして、飛躍しすぎないように気をつけながら解釈することで、実際のユーザーに近づけていくことができます。

6. さいごに

今回のエントリでは、Gaudiyで実施しているユーザーリサーチの一部を紹介させていただきました。

ユーザーリサーチを通じてアイドルファンの方々を深く理解できたことで、TIF本番では、動画を視聴しながらNFTサインが受け取れるなど、ファンの方々を楽しませるFandomな体験を提供できたかなと思います。

今回はインタビューなどの具体的なユーザーリサーチをメインにしたので、そこからどのように企画や機能に落とし込んでいったかについてはあまり触れられませんでしたが、そこは次週のblogにバトンタッチできればと思います!

Gaudiyではユーザー中心のプロダクト開発を行っているので、ユーザーリサーチやデザインにご興味のある方はぜひお話ししましょう〜!🐤🐤

meety.net

12/2(木)にプロダクトデザインの裏側をお見せするグループトークも開催します!

meety.net

オープンオフィスやオープン勉強会もやってるので、よければぜひ〜

www.notion.so

レトロスペクティブを週次→毎日に変更したら、チームの改善がどんどん進んだ話

f:id:gaudiy:20211112105421p:plain

こんにちは!エンタメ領域のDXを推進するブロックチェーンスタートアップ、Gaudiyでエンジニアをしている土居(@taro_engineer)です。

僕は普段、コミュニティや決済などの基盤を開発するPlatformチームで、バックエンドを中心に担当していますが、週次から毎日へとふりかえりの仕方を変えました。

ふりかえりはどのチームでも実践していると思いますが、よくあるのが「ふりかえって課題を洗い出せたものの、それが改善につながらずに忘れられてしまう」ことではないでしょうか。

そこで今回は、2ヶ月ほどチームでうまく運用できているレトロスペクティブの方法について、運用の工夫とともにお伝えしたいと思います。

チームの改善やDXの向上に取り組みたい方に、ご参考になると嬉しいです!

1. なぜ「毎日」ふりかえることにしたか

Gaudiyのふりかえりの歴史から言うと、元々はプロジェクトが終わるごとに実施していました。

背景として、Gaudiyではブロックチェーンを活用したファンコミュニティサービスを開発していますが、新規コミュニティの開発もあれば、既存コミュニティの新機能開発などもあり、常に複数のプロジェクトが進行しているような状況です。

大小さまざまなプロジェクトがありますが、大体2週間〜3ヶ月ほどの期間になるため、プロジェクト終了時のふりかえりだけでは十分な頻度を確保できていませんでした。

そこで、毎週金曜に開発チームでふりかえりを行うようになったのですが、それでも「1週間なにをしていたか、その時なにを感じていたかを思い出せない」「記憶が曖昧で事実にバイアスがかかってしまう」「ふりかえり自体に時間がかかる」といった問題がありました。

また、ふりかえりによって改善案がたくさん上がってきても、そのすべてを実行に移すまでには時間がかかるし、正確なイシューを捉えて次の改善にうまく結びつけることができていませんでした。

Gaudiyの事業は進むスピードが速く、不確実性が高いことを開発で取り扱っているため、チームの改善もアジャイル的に進める必要があると感じて、ふりかえりを「毎日」実施する運用に変えました。

2. Gaudiy流・レトロスペクティブと運用の工夫

このふりかえり手法を、Gaudiyでは「レトロスペクティブ」と呼んでいるので、その運用方法と意識していることをご紹介してみたいと思います。

※厳密なレトロスペクティブではないですが、「Don’t just Do Agile, Be Agile」という言葉があるように、アジャイル的な開発手法に固執するのではなく、アジャイルな状態であることが大事だと考えています。

まず運用としては、毎日実施している夕会で、10分間のレトロスペクティブを設けています。

10分間にした理由としては、毎日行うのでふりかえりに対する時間的コストや心理的コストをなるべく下げたかったのと、実際に何度か試したところ、1日分のふりかえりであれば10分程度でできることがわかった、ということがあります。

また、レトロスペクティブの観点は「👍良かった!」「👎惜しかった... 」「💪変えてこう!」「🧠今日のナレッジ」の4つにしています。KPTをベースにしながら、独自の項目を設定しました。

f:id:gaudiy:20211112090816p:plain

レトロスペクティブ用のNotionテンプレート

ここで大事にしているのは「ふりかえりが、次の改善アクションにきちんとつながるか」という点です。

KPTもシンプルで使いやすいですが、Problemはたくさん出てきたけど、具体的なTryにつながらない…といったことはよく起こりがちかなと思います。「ここを、こう改善していこう」と意思決定しても、それが実行に移されなければ意味がないので、それを解決する仕組みを取り入れたいと考えました。

そこでGaudiyでは、毎日のレトロスペクティブで「良かったこと」をたくさん出すように意識して、それを汎用化させることでチーム全体の改善を促しています。

というのも「良かったこと」は、だれかの実績なので他のメンバーも取り入れやすく、「惜しかったこと」を改善するTryよりも再現性が高いため、チームへの浸透率が高いです。各人の良い行動をチームみんなで真似していくイメージです。

f:id:gaudiy:20211112090913p:plain

各人の良い行動を、チームに共有して取り入れる

また、ふりかえりの最後に「今日のナレッジ」を設けることで、ただふりかえるだけで終わらせず、個人の良い動きをチームのナレッジに昇華させるアクションにつなげています。ちなみに最近では「今日のナレッジ&ドキュメント」という項目に改良して、プラス担当者も決めることでナレッジ蓄積を意識しています。

f:id:gaudiy:20211112101911p:plain

ふりかえり項目も改善し続けてます

もちろん良くなかったことの改善も大事なので、「惜しかったこと」に対してもチームで改善に動けるような工夫を取り入れています。そのひとつが、パターン・ランゲージの作成です。

たとえば、ある日のレトロスペクティブで「もう少し早く、Pull Requestを出すくらいのタイミングで、ステークホルダーと一緒に実際に開発したものを触りながら仕様漏れがないかの確認や改善を試みれるといいよね」といった声がありました。

そこから生まれた「ちょいデモ」というパターン・ランゲージは、手戻りが起きる可能性を極力避けるために、実際にチームでよく活用されています。

f:id:gaudiy:20211112102038p:plain

ちょいデモしてる様子

3. レトロスペクティブから実際に生まれた改善たち

運用開始してから数ヶ月ほどうまく回っていますが、ここでは、実際に生まれた改善アクションについていくつかご紹介してみたいと思います。

3-1. レビュー待ちPull Requestが解消され、開発全体のスピードが上がった

ある程度要件が決まり、不確実性が少なくなってくると、開発に集中してコードをゴリゴリ書いていくフェーズになります。このフェーズは開発のスピードが一段と上がるので、チーム全体のPull Requestがたくさん出てくるようになりますが、自分の開発とレビューのバランスを取るのがわりと難しかったりします。結果的にレビューが溜まってしまい、全体の開発スピードが鈍化することがありました。

そうした状況に対し、ある日のレトロスペクティブで「レビュー待ちのPull RequestがないかをSlackで尋ねたら、そこからチームでレビューを解消する動きが生まれた」ことが、良かったこととして挙げられていました。

f:id:gaudiy:20211112102107p:plain

自発的にレビュー待ちがないか確認してる様子

そこで、あるメンバーが自律的に実践してくれていた「レビューの時間を決めて解消する」という動きをチームで取り入れるため、「全員でレビューするタイミングをつくる」ことをNext Actionにしました。

レトロスペクティブでチームとしてのActionを決めると、また同じような状況があった際に、気づいた人が行動に移すことができているなと感じます。

f:id:gaudiy:20211112091205p:plain

チーム全体のレビューが早くなりました


3-2. 開発とコンテキストが異なる全社的なことにも、率先して参加した

またある日のレトロスペクティブでは、「全社宛ての依頼に対して、〇〇さんが率先して対応していた」ことが良かったこととして挙げられていました。

f:id:gaudiy:20211112091546p:plain

この良かったことの共有から、実際、また同じようなことがあった際に、チームのみんなが意識して行動に移すことができました。

f:id:gaudiy:20211112104430p:plain

他チームの依頼に開発メンバーみんなでレビューしている様子

f:id:gaudiy:20211112091431p:plain

良かった行動をまたふりかえり、カルチャーを強める

開発に集中していると、コンテキストが違う全社系の依頼をついつい見過ごしてしまうことがありますが、全社目線をもって改善していこうというチームの意識に変わりました。ナレッジ化まではいかなくても、チーム全員として何が良い行動なのかの意識醸成につながったかなと思います。

3-3. フロー効率を取り入れて、チームの生産性を向上した

さいごは、惜しかったことからの改善です。ひとつのチームが持つコンテキストが広がり、各人が別々のコンテキストのタスクを抱えていたことで、お互いのレビューをする際のコンテキストスイッチにコストがかかったり、今誰が何をやっているか把握しづらくてヘルプしづらいといった課題がありました。

結果として、チーム全体の生産性を下げているのでは? ということがレトロスペクティブで挙がっていたため、「次はフロー効率でやってみよう」というNext Actionが生まれました。

f:id:gaudiy:20211112091912p:plain

フロー効率を取り入れた日のレトロスペクティブ

こうした改善は、レトロスペクティブでなくても誰かの発案から実行に移せると思いますが、誰でも気がつける状態や、行動に移せる状態まで昇華していくためには、チームのレトロスペクティブで意識レベルの共有を行い、再現性を高めていくことがポイントだと思っています。

4. 現在感じている課題と今後改善したいこと

毎日のレトロスペクティブを導入したことで、以下のようなメリットを感じています。

  • 記憶が新しいのでふりかえりに時間がかからない
  • ある事象に対するリアルな気持ちを忘れにくい
  • 改善アクションが格段に増え、すぐに実行できる

特に、やはり3つ目の「小さく、すばやく」改善していけることが一番のメリットかなと感じます。

改善点を溜め込んでしまうと、Next Actionを決めてもそれを消化していくのに時間がかかるし、そもそもの状況が変わってたり、さらに負債が溜まってしまうこともあるので、毎日ひとつずつでも改善していくことが大事だと思います。

一方、以下については今後の課題として、これから改善していきたいと思っています。

① 定量的な観測はできてない

「変えていこう!」に挙げられたことがどのくらいチームに浸透したか、また実際に改善できたかの効果検証については、いまは定性的な感覚になってしまっています。これに対するひとつの解決策として、パターン・ランゲージの作成や活用があると思うので、定量的に測れるアクションにつなげていきたいです。

② チームに閉じている改善が多い

チーム内のふりかえりはうまく回っていますが、改善の影響範囲はチーム内であることが多いので、今後は全社への浸透もしていきたいと思っています。メンバーの自律的な改善から、チームの改善、そして組織全体の改善につなげていきたいです。

また、レトロスペクティブのやり方自体も、試行錯誤しながら常にアップデートしています。最近では、Next Actionにつなげるまで深ぼれないことがあることから、ふりかえりの時間を10〜20分間に設定し、柔軟に調整する形にしています。

5. さいごに

今回は、Gaudiyの開発チームで実践しているレトロスペクティブについて紹介させていただきました。Gaudiyのクレドのひとつでもある「Be Agile」なカルチャーが伝わっていたら嬉しいです。

今回、ブログを書く上でふりかえってみて思ったのは、チーム全体の改善を促すには、良くなかったことを改善するだけでなく、良いことを再現性のあるものに昇華することがアジャイルな組織では大切なのでは、ということです。

また、大きな目標を掲げて、大きな改善めざすのはもちろん良いことですが、そのためにも、毎日コツコツ小さな改善を積み上げることが大事だし、結果としてそれがチームの大きな改善につながっていくと感じています。

僕たちもまだまだ改善途上で、他社の開発チームの良いところもどんどん取り入れていきたいと思うので、初Meety作ってみました(笑)。チームの改善やDX向上に取り組まれている方、関心のある方、ぜひお話ししましょう!

meety.net

オープン勉強会などもやってますので、よければ遊びにいらしてください!

www.notion.so

フロントエンドエンジニアによるデザインレビューの取り組み

f:id:gaudiy:20211105105020p:plain

こんにちは。エンタメ領域のDXを推進するブロックチェーンスタートアップ、Gaudiyでフロントエンドエンジニアをしているkodai(@r34b26)です。

Gaudiyでは、数ヶ月前からエンジニアによる「デザインレビュー」をワークフローに取り入れました。僕自身は、デザインとエンジニアリングをつなぐことに関心があるのですが、一般的にデザイナーとエンジニアの協業については語られているケースが少ないですし、あったとしても、デザイナー側から寄り添ってくれるケースがほとんどだと感じています。

そこで今回は、Gaudiyでエンジニア側としても課題意識を持って取り組んできたデザインレビューについて、ご紹介したいと思います。

プロダクト品質を高めるために大事な観点だと思うので、よければご参考ください!

1. エンジニアによるデザインレビューを導入した理由

Gaudiyでは、職種を横断したコラボレーションを大事にしています。

デザイナーがプロダクトのUI/UXをデザインし、フロントエンドエンジニアがそのデザインをもとに実装する。それぞれに専門領域があるのはもちろんですが、大事なのはその「橋渡し」だと考えています。

よくありがちなのは、共有されたUIデザインを「決定事項」としてエンジニアが受け取ってしまうことです。そうすると、本来デザイナーが意図していたユーザー体験を実現できない、デザイナーが気付けていない観点を指摘できない、といった問題が生じてしまいます。

Gaudiyでも実際に、Figma上で表現しきれないデザイナーの意図を汲み取れていなかったり、まだFIXしていないFigmaのデザインを参照して実装してしまったり、といった問題がありました。

その結果、フロントエンドの実装では、

  • errorやloadingのstatusを考慮しない実装になってしまった
  • ユーザーフィードバックへの考慮がされていなかった
  • spacingのpxが統一されていなかった
  • デザインシステムに定義したものと酷似した”別物”を作り出してしまった
  • 必要以上の工数をかけて実装してしまった
  • デザイナーの設定ミス(design systemを使わないなど)が実装まで反映されてしまった

などが繰り返し起きていました。

これらは、実装を終えたPRやQAの段階で発見されており、場合によっては期限や優先度を考慮した結果、再実装されないこともありました。

また、上記のような点をPRレビューの段階で「発見できる人」についても、デザインと実装の両視点を持つ特定の人に依存してしまっている状況でした。

こうした課題に対して、手戻りコスト少なく、チーム全体でプロダクトの品質をあげていくため、開発フローにデザインレビューを取り入れることにしました。

2. チーム全体でデザインレビューを強化

では次に、どのような方法でデザインレビューをチームに導入、浸透させていったかについて具体的にお伝えしていきます。

2-1. スタンスを揃える

まずは、デザインに対するエンジニアのスタンスを揃えることから始めました。

「Figmaのデザインは決定事項ではない」ということを明確に伝えた上で、デザイナーにヒアリングして提案する、というコミュニケーションの指針を明確にしました。

f:id:gaudiy:20211105091503p:plain

Notionでスタンスを明示

2-2. デザインレビューの観点を明示する

次に、上記スタンスのもと、エンジニアがもつべき視点についても言語化しました。

個人的には以前から、デザイナーの成果物に対して以下項目のような視点を持って確認や調整を行っていましたが、それが属人的になっていたのでNotionに書いて他のチームメンバーにも展開しました。

実際の項目を、以下にご紹介してみます。

★最適な機能実装をするために

  • 確認しているUIは全て今回の実装スコープですか?
  • 確認しているUIは要件やUXのレビューを受けていますか?
  • 実装コストの高すぎるUIはデザイナー視点でマストなものですか?
  • 実装上の制限で実現できないものはありますか? 
  • 要件レビューを改めて挟んでもらった方がいい項目はないですか?

★一貫したUIを作成するために

  • Figma上、共通コンポーネントが使用されていますか?
  • Figma上、デザイントークンが使用されていますか?
  • Figmaと実装のコンポーネントの組み方は揃っていますか?
  • Figmaと実装の名前は揃っていますか?

★手戻り/抜け落ちがないように

  • 新規に共通コンポーネントを作成するべきですか?
  • 本当にそこだけのために新しいコンポーネントを作成するべきですか?
  • 似てるけど微妙な違いは、本当に生み出すべき違いですか?
  • 新規実装するUIの意図は把握してますか?
  • 既存のUIとの違いは把握してますか?

★仕様の確認

  • レスポンシブの挙動は把握できてますか?
  • デザインとデザインの間の挙動は把握できてますか?
  • アニメーションはつけなくていいですか?
  • 実装上Empty, エラー, ローディング状態は発生しますか?
  • ユーザーにEmpty, エラー, ローディング状態は表現しますか?
  • アクションできる箇所に対して、フィードバックをつけなくて良いですか?
  • 実装上遅れて表示されるところはないですか?

2-3. 日々のワークフローに落とし込む

また、こうしたデザインレビューをチーム全体で意識し、PRやQA間のロスタイムを削るために、ワークフローの中にも「デザインレビュー」を設けることにしました。

f:id:gaudiy:20211105091654p:plain

実際のワークフロー

2-4. 同期レビューとログの蓄積

さらに実際の行動に移しやすいよう、開発で推奨する行動についてもNotionに言語化しました。これを明記したことで、メンバーにもデザインを確認・調整する行動ができているかどうか促しやすくなりました。

① 同期レビュー

Figma上で「リアルタイムにコメントできる機能」などを活用して、実際のUIを触り、Figma上での組まれ方を見ながら会話をしています。

f:id:gaudiy:20211105091551p:plain

Figma上で同期レビューをしている様子

② ログの蓄積

同期レビューの結果、至った結論や追加の相談事項、対応箇所などに関しては、チケットに書いて受け入れ条件にしています。 また、非同期のレビュー時にも、実物に近いものを見ながら会話するために利用しています。

f:id:gaudiy:20211105091617p:plain

Figma上にログを蓄積

3. 実際にやってみて感じたメリットと今後の課題

実際にこの取り組みを始めてから、デザインを決定事項として捉えてしまう気持ちがやはり割と強かったんだなと感じました。そこが解消されたことで、エンジニアとデザイナーが適切にコラボレーションする機会が増えたことが一番良かったと思います。

一方で、確認事項にaskベースの項目を並べてしまったのも影響しているかもしれませんが、まだまだ改善しないといけないことは多いなと感じています。

例えば、デザインのパターンや導線、共通化の仕方など、エンジニア側からデザイナーに対する工数や実装方法などを踏まえた提案に関しては、まだまだできていないです。 また、それらの確認や提案が自分で考慮できない時に、他のエンジニアやPMに相談を持ちかける動きができていないことで、考慮すべき点がまだ抜けていることもあります。

この辺りは、引き続きチーム全体で改善を進めていきたいと思っています。

4. さいごに

今回は、Gaudiyで取り組んでいるフロントエンジニアによるデザインレビューについてご紹介しました。

デザインとエンジニアリングをシームレスにつなぐために、今後も試行錯誤を繰り返しながら、よりコラボレーションを深めて良いユーザー体験をつくっていきたいと思います。

またこうした取り組みを進める中で、iCAREさんの以下のスライドが勉強になったので最後にご紹介させていただきます。

speakerdeck.com

エンジニアリングとデザインをつなぐことに関心の高いエンジニアの方は、ぜひカジュアルにお話ししましょう!

meety.net

Gaudiyの技術選定については、こちらのblogをご参考ください〜

techblog.gaudiy.com

オープン勉強会もやってます

www.notion.so

「全員QA」でユーザー体験を高める、Gaudiyのプロダクト開発

f:id:gaudiy:20211028101934p:plain

こんにちは!エンタメ領域のDXを推進するブロックチェーンスタートアップ、Gaudiyでプロジェクトマネージャーを担当している小川(@zheye)です。

プロダクトの品質担保のため、どの会社もQAを行っていると思いますが、GaudiyではUX向上の一環として全員でQAに取り組んでいます。実際、開発メンバーだけでは気づかなかった視点も取り込むことができたり、全員がプロダクトに向き合う文化醸成にもつながっていると感じています。

そこで今回は、Gaudiyの「全員QA」の取り組みについて、先日の大型プロジェクトを例にしながら実践の工夫や学びをご紹介したいと思います。よければご参考ください!

※本記事は、UX向上を目的とした、QAプロセスにおける取り組みの一部になります。

1. なぜ全員でQAをするのか?

はじめに、なぜ全員でQAに取り組んでいるのか、という背景からお伝えします。

私たちが開発しているファンコミュニティサービスは、NFTや分散型IDなどのブロックチェーン技術を活用していることが特徴です。ビジネスモデルとしてはBtoBtoCなので、クライアント(IPホルダー)の要件を満たすだけでなく、ファン(エンドユーザー)の方々にとって最高の体験を届けることが重要になります。

そのため、ブロックチェーン技術を活用して顧客の課題を解決しながらも、ファンにとっては「ブロックチェーン技術を意識させない」よい体験づくりが事業のコアになっています。

簡単にいうと、ファンの方々は「ブロックチェーンを使っているから」ではなく「そのコンテンツが好きだから」コミュニティに参加したくなるわけです。

ブロックチェーン無関係
ファンにとってブロックチェーンかどうかは関係ない

そのファンの方々にとって最高の体験を届けるためには、開発フローにおいて多角的な視点を取り入れることが大切だと考えています。そこでGaudiyでは、ストーリーマッピングやDDDATDDといった開発手法を取り入れて、あらゆるステークホルダーの視点を取り込むようにしていますが、それはQAにおいても同様です。

UIテストについてはAutify導入による効率化にも取り組んでいますが、UXの観点では実際にいろんな人が触ってみることで気づくことが多々あるため、全員でQAを行っています。

Gaudiyの特徴としては、この「全員QA」が、本当に全員だということです(笑)。

エンジニア、デザイナー、プロダクトマネージャーはもちろん、コミュニティマネージャー、BizDev、人事広報、総務まで、メンバー全員で取り組んでいます。

2. 全員QAによるユーザー体験の高め方

では次に、実際の例を出しながら、全員QAの取り組みをお伝えしていきます。

2-1. 大型プロジェクト「TIF」の概要

2021年10月2日・3日に開催された「TOKYO IDOL FESTIVAL(以下、TIF)」にて、Gaudiyがオンラインシステムを開発・提供したので、ここでは実際にどのようにQAを行っていたか、どういった工夫をしていたかをご紹介します。

TIFについて簡単にご説明すると、フジテレビ主宰の毎年数万人が訪れるアイドルフェスで、今年はお台場のオフライン会場とオンライン視聴のハイブリッド開催でした。

そのオンラインシステム全般をSony Music Entertainment社と担うことになり、NFTオンラインチケットの販売、ファンコミュニティサービス、ライブ視聴、オンラインサイン会を、約2ヶ月かけて開発しました。(TIF全体については、以下のインタビュー記事が詳しいです。)

note.com

2-2. 全員が参加しやすい仕組みづくり

今回のプロジェクト全体を通じて、通算10回以上は全員QAを行いましたが、前述のとおりコーポレートメンバーも含む全員が毎回参加して、ユーザー体験をギリギリまで高め続けました。

私はプロジェクトマネージャーとして、QAの進行を取り纏めていたのですが、全員が参加するという観点では以下のようなことを意識していました。

  • QAフォーマットを作り、なにを検証をしているか一目でわかりやすくする
  • 修正のポイント、差分を明確に伝える
  • あまり検証の条件、ルールをつけすぎない

というのも、開発メンバー以外もQAに参加するということは、別業務からのコンテキストの移行が必要になります

そのため、テスト環境のURLやどういった手順で検証するのか、前回との差分は何か、といった基本的な情報が一目でわかるようなフォーマットを用意していました。

f:id:gaudiy:20211028093128p:plain
QAフォーマット

これは、全員QAを重ねる中での改善として弊社デザイナーのTORAJIROさん(@jirosh1998)がNotionのテンプレートで作成してくれたもので、毎回活用されています。

QAに参加するメンバーは、体験が良くないものや不具合など、気づいたことをNotionのデータベースに書き込みます。記入項目としてはシンプルで、内容、デバイス/環境、追加した人の3つです。必要に応じて画面スクリーンショットもページ内に貼っています。

f:id:gaudiy:20211028093235j:plain
実際のNotion。多いときは100以上の項目が挙がっていました。

ここで気をつけているのは、あまり条件やルールを設けすぎないことです。「こんな視点でいいのかな…」と躊躇すると気づきを挙げづらくなってしまうので、些細なフィードバック歓迎のスタンスで参加しやすい形にしています。

不具合、ユーザー体験、テキストなど、気になる部分を全てあげてもらった上で、開発チームの方で重要度と工数感から優先度を決め、実装に反映していきました。

2-3. 全員QAから実際に改善したUX例

では実際に全員QAをした結果、TIFコミュニティにおいて改善されたユーザー体験をいくつかご紹介します。

f:id:gaudiy:20211028090238p:plain
オンライン動画の視聴ページへの行き方がわかりづらい

TIFではライブのオンラインチケットを事前販売し、当日はTIFコミュニティ内の動画視聴ページからライブ映像の視聴ができるようになっていたのですが、その導線を全員QAから改善しました。

当初は、チケットの購入完了メールや開催当日の各種リンクでのみ動画視聴ページに辿り着く導線を設けていましたが、QAをした際に「事前に購入したデジタルチケットから動画を見に行こうとした人がいた」ことから、チケットから動画視聴ページを見に行ける動線がないと困ってしまうことに気がつき、事前に対処することができました。

f:id:gaudiy:20211028090535p:plain
特典の受け取りが他の通知に混ざっていてわかりづらい

こちらは、コミュニティアプリ内の通知タブの改善です。

当初は、いいねや返信があったときの「おしらせ」と、NFTトレカなどの特典が受け取れる「おしらせ」が共通のタブになっていました。

ですが、QAをしている際におしらせ通知をたくさん受け取っていたメンバーから「NFTトレカの受け取りが他のおしらせ通知で流れてしまう」というフィードバックをいただき、特典の受け取り通知については「プレゼント」という新たなタブを用意するという改善ができました。(今後、コミュニティ内で様々なデジタルアイテムやトークンのやり取りが生じてくるロードマップも見越しています。)

また開発のQAではないですが、キャンペーンページのUX検証も全員で行いました。

f:id:gaudiy:20211028094901p:plain
キャンペーンページのUX検証依頼

こちらはSlack上で非同期的に行いましたが、多くの人がUX検証に参加していました。

f:id:gaudiy:20211028094925p:plain
バックオフィス(VRゴーグルを付けた写真の方)含めUX検証に参加する様子

3. 全員QAのメリットと課題

改めて振り返ってみて、全員QAのメリットと感じている課題についてまとめてみます。

3-1. メリット

【Good】フレッシュな目線での気づきが多い

前述した通り、普段開発に関わっていないメンバーがQAに参加することで、フレッシュな視点での気づきを多く取り込むことができました。 Gaudiyでは、いろんなステークホルダーの視点を取り込む「マルチアイ(※)」を大切にしていますが、バックオフィスのメンバーも積極的に参加してくれたことで、いい意味で一般ユーザーに近い視点を事前に取り込めたと思います。

※マルチアイ…社内で利用しているパターン・ランゲージのひとつ。偏った視点ではなく、複数の視点を交えて最適解を導き出すべき時に利用する。

【Good】チームの一体感がでてくる

全員QAはプロダクトのUX向上だけでなく、組織の体験としても良かったです。開発が忙しくなると、コーポレートやビジネス系の職種の人との温度差が生まれやすくなったりするかと思いますが、全員QAでみんなで改善に向き合ったことでチーム全体の一体感がありました。全員が「このプロジェクトを成功させて、顧客にもユーザーにも良い体験を届けるんだ」という気持ちで乗り越えることができました。

3-2. 課題

【Next】開発チケットとのズレが生じる

全員が使い慣れているNotionでQAを行うことで、参加しやすくなるという利点がある一方で、Notionに挙がった項目とShortcut(社内で利用しているチケット管理システム)のチケットがズレてしまうという問題があります。今後は、全員QAの場をShortcutに移行する or チケットをきちんと登録管理することで改善できればと考えています。

【Next】人数が増えてきたときの運用の仕方

メンバーが日に日に増えている状況なので、今後はチームの分割などを検討していくことになるとは思います。ただ、なるべく小さい単位での開発を維持しつつ、必要な視点を取り入れられるように様々な視座を持っている方を巻き込むイメージでやっていきたいです。

【Next】社外の視点の取り込みやベータ版の活用

今後はコミュニティサービスの強みを生かして、一部ユーザーの方によるテストのご協力やベータ版の活用など、社外の視点の取り込みを進めていきたいと思います。(こちらは現在進行系で進めています)

4. 全員QAの現在地とこれから

課題はたくさんありますが、プロダクトに全員が向き合うという組織カルチャーの醸成につながることが、全員QAの何よりのメリットかなと思います。

TIFのプロジェクトは一旦ひと区切りつきましたが、今回の学びを踏まえて、週次のスプリントレビューにも全員が参加するようになりました。(開発メンバー以外は任意ではありますが、毎回7〜8割の人が参加しています。)

また今回、TIFのプロジェクトを乗り越えたご褒美(?)に、代表から全メンバーにOculus Quest 2が配布されたので、今後はVR会議を活用したQAにもトライしてみたいと思っています。その模様は、また別途お届けできたら…(以下の画像は、先日、コーチMTGをOculusで実施してみた時の様子です。笑)

OculusでのMTGの様子
OculusでのMTGの様子

5. さいごに

今回のエントリでは、Gaudiyの全員QAの取り組みをお伝えさせていただきました。

Gaudiy STYLE(クレド)にも言語化されていますが、メンバー全員が「All Owner(オールオーナー)」として開発に関わる。これはプロダクト開発もそうですし、組織開発においても同様です。

全員が当事者となってプロダクトに向き合うカルチャーがあるので、このカルチャーを絶やさぬよう今後も品質維持のために多くの方の視点を取り入れ続けられるように継続的な改善を行っていきます。

Gaudiyでは他にも品質改善やプロダクト改善を運用しており、課題もたくさんありますので、もし情報の共有やプロダクト改善の取り組みにご興味をお持ちの方がいらっしゃいましたらぜひお話しましょう!

meety.net

オープン勉強会などもやってますので、よければ遊びにいらしてください!

www.notion.so