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

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

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

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

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

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

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

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

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

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

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

生成的調査と評価的調査

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

実際のスケッチ

4-2. デプスインタビュー（社内インタビュー）

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

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

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

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

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

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

実際につくったCultural Model

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

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

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

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

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

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

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

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

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

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

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

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

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

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

6. さいごに

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

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

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

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

meety.net

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

meety.net

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

www.notion.so

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

こんにちは！エンタメ領域の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をベースにしながら、独自の項目を設定しました。

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

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

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

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

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

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

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

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

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

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

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

ちょいデモしてる様子

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5. さいごに

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

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

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

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

meety.net

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

www.notion.so

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

こんにちは。エンタメ領域の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のデザインは決定事項ではない」ということを明確に伝えた上で、デザイナーにヒアリングして提案する、というコミュニケーションの指針を明確にしました。

Notionでスタンスを明示

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

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

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

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

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

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

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

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

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

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

★仕様の確認

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

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

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

実際のワークフロー

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

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

① 同期レビュー

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

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

② ログの蓄積

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

Figma上にログを蓄積

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

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

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

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

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

4. さいごに

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

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

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

speakerdeck.com

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

meety.net

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

techblog.gaudiy.com

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

www.notion.so

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

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

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

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

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

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

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

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

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

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

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

そのファンの方々にとって最高の体験を届けるためには、開発フローにおいて多角的な視点を取り入れることが大切だと考えています。そこでGaudiyでは、ストーリーマッピングやDDD、ATDDといった開発手法を取り入れて、あらゆるステークホルダーの視点を取り込むようにしていますが、それは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やどういった手順で検証するのか、前回との差分は何か、といった基本的な情報が一目でわかるようなフォーマットを用意していました。

QAフォーマット

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

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

実際のNotion。多いときは100以上の項目が挙がっていました。

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

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

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

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

オンライン動画の視聴ページへの行き方がわかりづらい

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

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

特典の受け取りが他の通知に混ざっていてわかりづらい

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

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

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

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

キャンペーンページのUX検証依頼

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

バックオフィス(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の様子

5. さいごに

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

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

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

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

meety.net

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

www.notion.so

Gaudiyのプロダクト戦略とGraphQLの活用

こんにちは！Gaudiyのエンジニアの永井（@sho0910K）です。

Gaudiyでは昨年からGraphQLを導入し、スキーマ駆動開発に取り組んできました。導入からまもなく1年を迎えようとしていますが、良かったところや、改めて浮き彫りになった課題や気づきがあったので、今回はGraphQLの取り組みについてまとめてみたいと思います。

GraphQLの導入を検討しているチームや、実際に活用しているチームのご参考になれば嬉しいです。

1. GraphQL導入の背景

導入の背景については「技術スタックと選定における思想」というブログでも簡単に触れましたが、もともとGaudiyでは、フロントエンドとバックエンドでAPIインターフェイスの認識齟齬が発生することから手戻りが起こり、開発効率を下げているという課題がありました。

またフロントエンドでは、事業ドメインの複雑化によって展開するコミュニティごとに提供する機能や扱うデータが異なったり、扱うデータの増加によってアプリケーションとして管理するデータが複雑化したり、といった状況でした。

具体的には、GraphQL導入以前は、状態管理をRedux、データベースとしてFirestoreを利用していましたが、バックエンドのマイクロサービス群と掛け合わせたクライアントサイドジョインも多くなり、クライアントからのリクエスト数の増加や扱うグローバルステートが増えたことで、コードが複雑化して可読性も低くなっていました。

結果として、状態管理やコンポーネントの繋がりが見えにくくなり、意図しないところで再レンダリングが発生するなど、プロダクトのユーザー体験として思わしくない課題を抱えていました。

2. GraphQLをプロダクトでどのように活用しているのか

Gaudiyが提供しているコミュニティアプリは、コミュニティごとに提供する機能や扱うデータに差があります。

この理由としては、Gaudiyが提供するコミュニティの主軸はIPコンテンツになりますが、IPごとにファンのユーザー層も様々です。そのため、提供する機能の出し方に関しても、そのファン層が利用しやすい形態として提供するなど、IPごとの考慮も必要になってきます。

この差分をBFF（backend for frontend）であるGraphQLサーバーを使って、できるだけ複雑性を回避したフロントエンドで扱いやすいデータとして返却しています。

例えば、コミュニティ内でNFTアイテムを提供するサービスに関しても、コミュニティ内のストアを通して手に入れられるものや、イベントに参加することで手に入れられるものなど、獲得方法はコミュニティによって様々です。この差異をBFFであるGraphQLサーバーにてマージ処理を挟むことで、できるだけフロントエンドでロジックを挟まずにデータ展開できるようにしています。

Gaudiyのバックエンドは、各コミュニティで必要な機能をマイクロサービスとして構成しており、各サービスのレスポンスをコミュニティのユーザーデータと組み合わせて返却しています。機能単位にマイクロサービス化している意図としては、作成時は特定のコミュニティに対して特化した機能だったとしても、ユーザー体験の改善や機能拡張をしながら他のコミュニティでも展開できるようにするためです。こうすることで、サービス単体として継続的な機能開発やデプロイを実行しやすくしています。

これらのマイクロサービスで構成された機能群を、BFFであるGraphQLサーバーを通すことで複雑性を回避し、フロントエンドではできるだけユーザー体験の最適化にフォーカスできるようにしています。

3. GraphQLを実践する上での工夫

では次に、実際にGraphQLを実践する上での工夫についていくつかご紹介します。

3-1. クライアントもサーバーもApolloを利用

まずGraphQLをどのように導入しているかというと、クライアントとサーバー共にApolloを採用しており、Apollo Serverは、BFF（backend for frontend）として活用しています。

Apollo採用の前には、クライアントはgraphql-requestを使い、バックエンドはGo言語でGraphQLサーバーを立てていました。しかし、Gaudiyでは創業時からフロントエンドにNext.jsを採用しており、TypeScriptを書けるエンジニアが大半を占めていたため、このGraphQL構成だとGo言語に慣れていないために実装スピードが遅くなってしまう、という懸念がありました。

これを解消するために、フロントエンドのエンジニアでもスムーズに開発できるTypeScriptを使える構成として、Apollo Client、Apollo Serverを利用しています。Apolloに関しては、Apollo Studioなどのエコシステムが揃っていることもあり、BFF含めてフロントエンドのエンジニアの開発範囲として扱えています。

3-2. Apollo Datasourceを使ったFirestore設計とテスト

BFFからFirestoreを参照するにあたっては、DataSourceを使って利用できるようにしています。これによって利用する際には、Firestoreのコレクションパスを指定するだけで利用できるようにしています。

DataSourceとして渡しているため、BFFのIntegrationテスト時には、テスト用のFirestoreインスタンスに差し替えて実行できるなど、テストもしやすくなっています。

一部分となりますが、参考にソースコードは以下のような形で利用しています。

• FirestoreをDatasourceとして作成

export class FirestoreDatasource extends DataSource {
  public db: firestore.Firestore;
  private _tenantId: string | undefined;


  constructor(firestore: firestore.Firestore) {
    super();
    this.db = firestore;
  }

  // apollo server のcontextを受け取る
  initialize(config: DataSourceConfig<Context>): void {
    this._tenantId = config.context.tenantId;
  }

  private collection(collectionPath: string) {
    return this.db.collection(withMultiTenancy(this._tenantId, collectionPath));
  }

  public get = async <T>(collectionPath: string, docId: string) => {
    const snap = await this.collection(collectionPath).doc(docId).get();
    if (!snap.exists) return undefined;
    return getDocData<T>(snap);
  };

  public set = async <T>(collectionPath: string, docId: string, data: T) => {
    await this.collection(collectionPath).doc(docId).set(data);
  };
};

• QueryResolverでの利用するときは、Context経由で利用

const Query: QueryResolvers = {

  async user(_, { userId }, { dataSources }) {

    return withApolloError(async () => {

      const user = await dataSources.firestore.get<User>(userColPath(), userId);

      if (!user) throw new Error(`no user userId: ${userId}`);

      return userToGQL(user);

    });

  },

};

3-3. ドメイン駆動によるスキーマ設計

Gaudiyでは、ユーザーストーリーマップや画面のプロトタイプが見えてきたら、実装に着手する際に、今回はどのようなデータが必要かをDDD(ドメイン駆動設計)を取り入れて設計しています。

具体的には、デザイナーやドメインエキスパートを含めてDDDを実施し、ドメインモデルを設計したタイミングでスキーマ設計を行っています。

この開発フローにすることで、モデリングに必要なデータとUI視点で必要なデータを分けて考慮することができ、認識齟齬をなくす効果があります。またスキーマ設計時にUI視点で必要なデータについて議論することで、ドメインモデルにおける考慮漏れを見つけ出せるといった副次的な効果も得られています。

khalilstemmler.com

3-4. GraphQLのナレッジをチームで貯める

GraphQLは、実践するにあたって学ぶべきものが多いアーキテクチャだと思っています。

その導入に伴い、開発効率をあげられそうな機能を学習しつつ、それをチームメンバーが利用できるように、サンプル実装を加えたドキュメントを用意したり、勉強会を開いたりしました。

また、GraphQLの知見をメンバーに布教するにあたっては、以下の技術書や資料がとてもわかりやすくて、今も活用させていただいています！

booth.pm

speakerdeck.com

zenn.dev

speakerdeck.com

4. 今後の課題

4-1. レガシーコード改善と並行したGraphQLを使ったアーキテクチャの浸透

冒頭でも述べましたが、もともとGaudiyのフロントエンドのアーキテクチャとしてはRedux + Firestoreを採用しており、今もレガシーコードとして残っています。

早々にレガシーコードをGraphQLを使った形に改善していきたい気持ちはありますが、置き換え自体がユーザーに対するアウトカムには紐付かないと考えているため、事業を進める開発に関しては率先してGraphQLを採用しつつ、その合間を見てレガシーコードのGraphQL化を進めています。そのため、レガシーコードが使われている機能に関してはユーザー体験が悪いものも存在してしまっています。

4-2. マイクロサービスとの接続・運用を簡単にしたい

Gaudiyではコミュニティアプリ以外にもGraphQLを使っているサービスが存在しています。 中には似たような処理を実装するコードやスキーマ定義がそれぞれで管理されてしまっていたり、部分的に二重管理になってしまっているという課題があります。

また、BFFとしてGraphQLサーバーを立てているため、マイクロサービスとの接続は基本的にはバックエンドAPIをラップするためだけに行っている場合もあり、記述するコードも少なからず存在するため、積もり積もればもったいないとも感じています。

解決策としては、Apollo FederationやGraphQL Meshなどがあげられると思いますが、プロダクトの今後の戦略やリソースと相談しつつ、最適な形で導入していきたいと考えています。

5. さいごに

本記事では、弊社のGraphQLに関する取り組みをご紹介しました。 レガシーコードのGraphQL化や複数GraphQLサービスの運用方式など課題もありますが、フロントエンドとバックエンドでコラボレーションをしながら、コミュニティでファンの方に最高の体験を届けるような開発を進める上で、Gaudiyでは欠かせない技術になってきています。

GaudiyではがっつりGraphQLを取り入れて運用しているので、もしこの記事を読んで、少しでもGraphQLの実運用の話を聞いてみたい！Gaudiyのコミュニティ開発をもっと聞きたい！などご興味を持っていただけたら、ぜひお話しましょう！

meety.net

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

techblog.gaudiy.com

オープン勉強会も毎週水曜に開催しています。気軽に遊びにいらしてください！

www.notion.so