プロダクト主導型の組織をめざして（2022年の抱負）

こんにちは！エンタメ領域のDXを推進するブロックチェーンスタートアップ、Gaudiy共同創業者の後藤（@PTeamd）です。

Gaudiyは2018年5月に創業し、今年は5期目を迎える年になります。

創業当初からブロックチェーン技術を活用したプロダクト検証を行い、2020年からはSony Music社、集英社、アニプレックス社などの国内大手IPホルダーと協業。エンタメ業界の構造的な課題を解決するプロダクトを通じて、新しいファン体験を提供してきたGaudiyですが、2022年はさらに「PLG（Product-Led Growth）」（※）へと舵取りをしていきます。

今回のブログでは、その背景とGaudiyが今年注力することについてお伝えします！ぜひご一読ください。

※PLG…「プロダクトがプロダクトを売る状態（Product sells itself）」をめざす戦略

1. 創業時からめざすのは「ファン国家」の実現

2018年の創業時より、ファンの応援や創作といった熱量が適正に認められ、ファンに還元されるエコシステム「ファン国家」の実現をめざしてきました。

Gaudiyでは単にブロックチェーン技術をPoCで試すというやり方ではなく、トークンを使ったコミュニティプロダクトをファンに向けて提供することで、New Standardかつベストな体験を社会に普及する取り組みを進めてきました。

創業初期はブロックチェーンの顕在的なニーズが世の中にあまりなく、先行事例も少なかったため、PMFをめざす上で重要だったのは「いかに関係者に価値を理解してもらえるか」でした。

そこでまずは、クライアント企業に深く入り込み、個別の状況に対して理解と共感を深め、エンタメ企業に共通するペインを見つけながら、それを解決するプロダクトをつくる。そのプロセスが必要であり、意図的に「案件ベース」でのプロダクト開発を進めてきました。

具体的には、Sony Music社のデジタル声優アイドルグループ「22/7（ナナブンノニジュウニ）」や、週刊少年ジャンプの人気漫画「約束のネバーランド」など、大手IPホルダー（知的財産コンテンツを有する企業）との協業案件です。

その中で、ファンコミュニティサービスの開発・提供を行いながら、中長期的なファン国家のエコシステム構築をめざして、様々な”仕込み”を行ってきました。

例えば、そのひとつが「分散型ID（DID）」の開発です。ブロックチェーン技術を活用した独自のIDシステムを構築し、実際のコミュニティプロダクトにも組み込んでいます。

note.com

また、Gaudiyの経済設計顧問である慶大・坂井教授や、同じくコミュニティサイエンス顧問である早大・石川教授とともに、トークンエコノミーの経済設計などにも取り組んできました。

このように、エンタメ企業の課題を解決するソリューションをブロックチェーンベースで組みながら、新しい経済圏づくりに必要な研究と実装を行いつつ、SLG（Sales-Led Growth）での着実な成長を遂げてきました。

2. 昨年起きた市場の変化と「PLG」への転換

そして昨年、市場に大きな変化が起きました。

NFTを中心にWeb3.0が大きな注目を集め、世間からの認知度・関心度が一気に高まりました。ありがたいことに、Gaudiyも大手IPホルダーから数多くのお問い合わせをいただいています。

創業時からこのタイミングが来ることを信じ、案件ベースで様々な仕込みを行ってきたGaudiyにとって、2022年は勝負の年。今後大きく飛躍できるかどうかの転換点になります。

そのために注力していきたいのが「PLG（Product-Led Growth）」です。

SaaSプロダクトでよく聞く言葉ですが、良いプロダクトが次の顧客を呼び込むような、プロダクト主導型の事業成長モデルのことです。（PLGについて詳しく知りたい方はこちらの本がおすすめです。）

2022年は「ファンと共に、時代を進める。」というミッションに向けて、より多くのファンに「Web3.0の体験」を提供し、最高の体験を実現をめざします。

具体的にいうと、Gaudiyでは単にNFTを販売するのではなく、Non-Fungibleな体験を提供していきます。トークンエコノミーで最も重要とされる「コミュニティ」を形成し、そのコミュニティと従来は散らばっていた関連サービスをDIDで統合することで、ファンの活動に対して還元するエコシステムをつくります。

また、エンタメ企業の課題を解決する、IP独自のファンプラットフォーム「Gaudiy Fanlink」というプロダクトに全集中します。国内はもちろん、海内のIPコンテンツとそのファンに対しても最適な体験を一貫して提供することをめざします。

3. これからの「プロダクト主導型組織」について

PLG型で世界中のファン体験を前進させるために、組織全体としても、プロダクトに対してフルベットします。「Product-Led Organization（PLO）」という言葉もありますが、Gaudiyはプロダクト主導型の組織づくりに注力します。

プロダクト主導の成長・組織構築をしていくためには、ソフトウェアの開発だけでなく、ビジネス、コーポレートなどを含むすべての活動を、プロダクトビジョンへのコミットに紐付けて目標設定と戦略実行のできる体制が重要です。

その大方針として、以下3つに取り組んでいきます。

3-1. 全社でプロダクトをつくる

あらゆる活動を上位のプロダクトに紐付けて設計します。エンジニアリング、デザイン、ビジネス、採用、組織開発、広報、バックオフィスなど、あらゆる活動を個別最適化させずにプロダクト中心に組み立てることで、より良いプロダクトづくりをめざします。

例えば、これまでプロジェクトベースで動くことが多かったBizDevの活動も、いかにプロダクトの成功に紐付くアウトプットにつなげられるかを軸に進めていけるようにする。またtoC向けサービスであることから、プロダクトを触ったり、関連したプロモーションを見て興味を持っていただくことも多いため、採用・広報として伝えていきたいストーリーをプロダクト側でも汲み取り反映していく。

さらには、全社的に「プロダクトの成長」を目標にすると同時に、プロダクトサイドでは全ステークホルダーがプロダクトづくりを「自分ごと化」できるように、要望に共感し成果につながるよう支援することで、全員が一丸となってPLGにコミットできる体制をめざします。

3-2. 人間中心設計（HCD）を強化する

人間中心設計（Human Centered Design）とは、簡単に言うと「人のことを理解し、ユーザーにとって使いやすいシステムを設計する」ということです。 案件ごとに、個別のユーザーやクライアントに向けてプロダクトをつくることは、その要望も目標も個別の最適化が追求できたため、ある意味で対象への共感がしやすい側面もありました。

しかしながら、国内外のより多くのコンテンツとファンにプロダクトを提供していくと、汎用性をめざす必要性が出てきますし、関係者と直に接点を持てる度合いも制限されます。それにより、これまでよりも「共感」をベースとしたFandomな体験の実現が難しくなります。

そこで、より体系的な形でファンにとって最高の体験を作るために、共感をベースとしたプロダクト開発手法である人間中心設計を強化していきます。

3-3. プロダクトを作るように組織を作る

上記のようなプロダクト開発手法を、ソフトウェア開発だけでなく、組織も広義の”プロダクト”として、それぞれの手法を一般化して各所に取り入れていきます。

例えばチームトポロジーに代表されるように、カプセル化・抽象化・インターフェースの設計など、エンジニアリングの観点を組織開発にも取り入れて、組織フェーズごとに最適なアーキテクチャーをつくり続けます。

またUXデザインにおける調査・モデリングの手法を、エンジニアリングではDDDなどのバックエンドの設計手法に、採用ではEXの可視化・改善のために利用します。

さらにピープルマネジメントにおいて重要なコーチングの概念は、プロダクトマネジメントや自律分散的な組織マネジメント、カスタマーサポートなどコミュニティの運営にも共通のコミュニケーションスタイルを利用していきます。

4. おわりに

今回のブログでは、2022年の抱負として、PLG型の事業成長と組織づくりの方針をお伝えさせていただきました。

Gaudiyでは、ファンにとっての最高の体験を実現し、時代を進める取り組みをもっと加速させていくため、プロダクト中心組織を一緒に創りあげていきたいと思う方を全方位で募集しています。

職種や職務で分断された形ではなく、ビジネス・テクノロジー・ユーザーの3領域を横断してプロダクトを磨き続けることは、ある意味では個々の専門性に閉じて役割分担をするよりも大きな負担がかかり、難しいことです。

出典：The Product Management Triangle – Product Logic

ですが、まだ世の中にない世界観である「ファン国家」の実現に向けて、新しい概念や技術を取り込みながらプロダクト開発を進めるGaudiyにとっては、この形が必要不可欠だと考えています。

困難なチャレンジになるとは思いますが、プロダクト中心組織をつくり、2022年もビッグなIPと時代の先端をいく取り組みを進めていきます。

国内はもちろん、言語の壁を超えてグローバルで通用する突き抜けたプロダクトを生み出すことに興味のある方は、ぜひお気軽にご応募ください！ワクワクする未来を、共創していきましょう。

---

最後に宣伝させてください🙏　1月25日（火）19時〜、クラウドサインさんと一緒に「不確実性に向き合うプロダクトマネジメント」をテーマにしたウェビナーを開催します！Gaudiyの開発全般についてお話しするので、PdMの方はもちろん、エンジニアやデザイナーの方々もよければご参加ください。

bengo4.connpass.com

ほぼ全職種オープンしています。お気軽にご応募ください。

www.wantedly.com

いろんな職種のメンバーがMeetyをオープンしてますので、こちらからでも！

meety.net

借りたものはきっちり返す。技術的負債への向き合い方

はじめまして。エンタメ領域のDXを推進するブロックチェーンスタートアップ、Gaudiyでエンジニアをしている@kaa_a_zuです。

早速ですが、質問です。みなさんは、所属している組織のコードを誇りに思い、この先数十年間に渡って使い続けることができると確信していますか？

私は、この質問をされた場合、顔を背ける自信があります。今回は、私と同じようにこの質問に対して "YES" と答えることが出来なかった人たち、そして 「リファクタリングをしたい」と思っているエンジニアが在籍する組織の偉い人たち に読んでもらいたい内容を書こうと思います。

テーマは、技術的負債の返済方法と技術的負債をためない方法についてです。（かなり長いので、HOWだけ知りたい方は4章から読んでいただけたらと思います。）

1. 一般的な技術的負債とは

「負債」という言葉を、日々の開発ではよく耳にするかと思います。改めて、技術的負債とはなんなのでしょうか。

技術的負債というものは、1992年にWikiの開発者であるウォード・カニンガム氏によって使われた表現です。彼の言葉を引用すると、技術的負債は「借金」と表現できます。それも開発が進めば進むほど、利息が高くなる悪魔のような借金です。

Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite. Objects make the cost of this transaction tolerable. The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation, object- oriented or otherwise.

初めてコードを出荷することは、借金をするようなものです。少しの借金は、書き直しですぐに返済される限り、開発を加速させます。オブジェクトは、この取引にかかるコストを許容範囲にしてくれます。危険なのは、借金を返せなくなったときです。正しいとは言えないコードに費やされた時間は、借金の利息としてカウントされる。オブジェクト指向であろうとなかろうと、統合されていない実装の負債によって、技術者組織全体が立ち行かなくなる可能性があるのです。

お金に余裕のない企業が国や金融機関から借金をして事業をするのと同じように、「余裕がない状態で、負債をしてでもサービスをつくり提供する」という意味が込められています。この意味を読み取ると、改めて技術的負債という表現は上手くできていると感じます。

しかし、エンジニアリングにおいて、技術的負債をためようと思ってためているチームは存在しないはずです。ではなぜ技術的負債がたまってしまうのか。技術的負債と借金が大きく異なる点は「借主が借りたことを知らない（気付かない）」ことだと私は思います。

もちろん、納期が近いなかでやっつけの開発をした場合には、負債がたまっていることを自覚しています。しかしながら、みなさんが既に経験をしているように、通常の開発においても技術的負債はたまっています。借りていたことに気がつくのは数日後かもしれないですし、数年後かもしれません。

そして非常に残念なことに、その負債に関連したコードを書けば書くほど利息がついてきます。気がついた時には、利子が複利になっており、返済額もとても大きくなっているかもしれません。取り立てをされることはないですが、寝れない日が続く可能性は高いはずです。

さまざまな技術的負債が存在しますが、まとめると以下4つに分類することができると思います。

1. 影響範囲が大きく、目に見えるもの
2. 影響範囲が小さく、目に見えるもの
3. 影響範囲が大きく、目に見えないもの
4. 影響範囲が小さく、目に見えないもの

次の章では、4種類の技術的負債がなぜ発生するのかについて、私の考えを示します。

2. なぜ技術的負債が発生するのか

4種類の技術的負債がたまる代表的な原因をそれぞれ挙げてみます。

※原因の大きさによって、生じる技術的負債の種類が変わることをご了承をいただきたく思います

1. 影響範囲が大きく、目に見えるもの

• ビジネスプレッシャー…ビジネス的な観点ですぐにリリースする必要があり、設計やコードにおいて妥協せざるを得なかった。
• 不十分な先行定義…時間短縮のために、要件がまだ定義されていない状況で開発を開始しなければならなかった。
• 誤ったテックリード…十分に考えられていない指示が指揮系統のもとに伝わってしまった。

2. 影響範囲が小さく、目に見えるもの

• 割れ窓理論…DRYでなかったり、直交性がなかったり、変数名が適当なコード、コード規約が守られていないコードが散乱していたため、同様のごみ（ひどいコード）が捨てられ、さらに汚くなってしまった。
• ビジネス的柔軟性…機能が適切な粒度のモジュールになっていないため、ビジネス要求の変化に柔軟な対応を取れない状態になってしまった。

3. 影響範囲が大きく、目に見えないもの

• 継続的な開発…プロジェクトの息が長い場合、利用しているコアなライブラリやソリューションが最適ではなくなってしまった。
• コラボレーション不足…知識や決定事項が組織内で共有されておらず、エンジニアと他の部署での認識のずれが生まれてしまった。
• 知識の欠如…その時点で在籍している開発者が、問題に対してのベストな解決策や綺麗なコードの書き方を知らなかった。

4. 影響範囲が小さく、目に見えないもの

• 偶発的プログラミング…コードがたまたま上手く動いているが、なぜ動いているのかを説明することができない。または、データ構造やアルゴリズムについて深く考えることができていなかった。
• 不十分なテスト…テストスイートがないため、迅速だがリスクの高い暫定的なバグ修正が行われた。
• 属人化…（小さな組織では特に）知識が属人的になってしまい、負債かどうかの判断もつけにくい状態になってしまった。

これらの原因のうち、心当たりがあるものはありましたか？もしあった場合、それは悪いことではなく改善するチャンスだと私は思います。

3. 技術的負債がもたらす問題点

返済方法について考える前に一度立ち止まって、技術的負債の問題について考えてみます。私は、技術的負債がもたらす問題には、大きく分けて3つあると思っています。

3-1. バグの温床になる

他の部分に影響が出ないと思って書いたコードが、実は様々な部分に影響を及ぼしていた場合にバグが生じます。バグは、サービスのユーザーをイライラさせます。そして悪い評判が立ったり、遅延やセキュリティ問題が発生することは、サービスだけではなく会社に悪影響を及ぼします。

また、CSチームやQAチームのやることも増えるため、社内の環境も悪くなります。当然、エンジニアはそのバグの対処に時間を割かなくてはいけなくなります。該当コードを書いた人はすでに組織を去っているかもしれず、バグの温床になってしまいます。

3-2. 新しい機能をユーザーに届けることが出来ない

よくない設計をしていたが故に、想定していなかった修正をしなくてはいけなくなる恐れがあります。そうなると見積もりで引いていたスケジュールの間にギャップが生まれるため、機能のリリースが遅れます。結果的に機能を渇望しているユーザーの期待を裏切ります。

スケジュールが数日ズレるだけならまだ良いですが、内容によっては「現在の設計だったらこの機能を作ることは難しい」という結論に至る可能性があります。新たな機能が加わらないために飽きがきたユーザーは、そのサービスから離れていってしまいます。

3-3. DXが損なわれる

思いもよらぬ様々なバグを生じさせた過去があったり、ノンリーダブルなコードを見ていると、コードを書く前に勇気をふり絞らないといけなくなります。また、新しいコードを書くために、多くの既存コードを読む必要がでてきます。

最終的に、離職率の上昇やエンジニア採用の成功率低下にもつながる可能性もあります。ひどい作業を好んで取り組みたい、引き継ぎたいと考えるエンジニアはかなり少数なはずです。

…いかがでしょうか？「技術的負債を甘くみていた」と思ってくれた方がいたら嬉しいです。

以上、技術的負債がどういう時に発生して、何が問題であるのかについて説明をしてきました。ここまで読んでくださった方は、おそらく技術的負債を抱えている人だと思います。大変お待たせしました。

次の章では、技術的負債の返済方法について、私の考えを示します。

4. 技術的負債の返済方法

もしも、読んでくださっている方の中に「海老で鯛を釣る」ことが好きな方がいたら、非常に残念なお知らせをしなくてはいけません。

人生と違って、宝くじや玉の輿に乗って大逆転をすることができないのがこの世界です。

また、目に見えない負債を返済することもできません。私たちにできることは、目に見える負債を減らすことと、目に見えない負債を少なくすることの2つだけです。

先ほど「2. なぜ技術的負債が発生するのか」の章で、4種類の技術的負債における代表的な発生原因を挙げました。それぞれの原因を潰すことができれば、返済をする、または返済額を減らすことが可能です。返済が簡単な順で見ていきます。

4-1. 影響範囲が小さく、目に見えるもの

まず、影響範囲が小さく、目に見えるものが最も簡単です。その発生原因としては「割れ窓理論」と「ビジネス的柔軟性」がありました。 それぞれの返済方法には、以下が挙げられると思います。

＜割れ窓理論＞

割れ窓理論…DRYでなかったり、直交性がなかったり、変数名が適当なコード、コード規約が守られていないコードが散乱していたため、同様のごみ（ひどいコード）が捨てられ、さらに汚くなってしまった。

• コード規約ツールの利用
• フォーマットの自動化
• コードレビュー
• CIで規制
• 割れた窓を見つけた時に直す、もしくはチケットを切る

＜ビジネス的柔軟性＞

ビジネス的柔軟性…機能が適切な粒度のモジュールになっていないため、ビジネス要求の変化に柔軟な対応を取れない状態になってしまった。

• デメテルの法則
• 直交性,SOLID原則の意識
• コードレビュー
• DDD
• ADR(Architecture Decision Records)

4-2. 影響範囲が小さく、目に見えないもの

次に、影響範囲は小さいけれど、目に見えないものです。その発生原因としては「偶発的プログラミング」「不十分なテスト」「属人化」がありました。それぞれの返済方法には、以下が挙げられると考えます。

＜偶発的プログラミング＞

偶発的プログラミング…コードがたまたま上手く動いているが、なぜ動いているのかを説明することができない。または、データ構造やアルゴリズムについて深く考えることができていなかった。

• 利用しているアルゴリズムとオーダー(O)を意識
• 劣化が起きていないかCIでモニタリングを行う
• TDD
• コードレビュー

＜不十分なテスト＞

不十分なテスト…テストスイートがないため、迅速だがリスクの高い暫定的なバグ修正が行われた。

• テストを書く
• テストカバレッジをCIで規制

＜属人化＞

属人化…（小さな組織では特に）知識が属人的になってしまい、負債かどうかの判断もつけにくい状態になってしまった。

• 社内勉強会
• ドキュメント作成の義務化

4-3. 影響範囲が大きく、目に見えるもの

次に、影響範囲は大きいけれど、目に見えるもの。この発生要因としては「ビジネスプレッシャー」や「不十分な先行定義」「誤ったテックリード」がありました。それぞれの返済方法には、以下が挙げられると思います。

＜ビジネスプレッシャー＞

ビジネスプレッシャー…ビジネス的な観点ですぐにリリースする必要があり、設計やコードにおいて妥協せざるを得なかった。

この原因はエンジニアだけでは絶対に解決できません。ビジネスサイドの技術的難易度や技術的負債への理解と、ビジネスサイドとエンジニアサイドの心理的安全性を高める日々のコミュニケーションが必要です。 その上で、以下の方法があります。

• ビジネス要件のうち落とせるものがないかを確認
• 生じた負債はすぐにチケットを切る
• アジャイル開発をしている場合は次スプリントに負債返済を入れる

＜不十分な先行定義＞

不十分な先行定義…時間短縮のために、要件がまだ定義されていない状況で開発を開始しなければならなかった。

• 曳光弾の利用
• 使い捨て前提のコードを利用するプロトタイプの作成

＜誤ったテックリード＞

誤ったテックリード…十分に考えられていない指示が指揮系統のもとに伝わってしまった。

• キックオフミーティングや定期的なミーティングでその指示について議論する
• （全開発者が意見を言えるように）開発者がただの作業員だと思わないような環境づくりを行う

4-4. 影響範囲が大きく、目に見えないもの

さいごに、影響範囲が大きく、目に見えないという返済が最も難しいもの。この発生原因には「継続的な開発」「コラボレーション不足」「知識の欠如」がありました。それぞれの返済方法としては、以下が挙げられると思います。

＜継続的な開発＞

継続的な開発…プロジェクトの息が長い場合、利用しているコアなライブラリやソリューションが最適ではなくなってしまった。

• 定期的にライブラリをアップデートする
• ライブラリアップデートの自動化
• 技術アンテナを高く持ち、日頃から新しい技術を試す機会を設ける

＜コラボレーション不足＞

コラボレーション不足…知識や決定事項が組織内で共有されておらず、エンジニアと他の部署での認識のずれが生まれてしまった。

• 勉強会を開く
• デザインコラボレーションの機会を設ける

＜知識の欠如＞

知識の欠如…その時点で在籍している開発者が、問題に対してのベストな解決策や綺麗なコードの書き方を知らなかった。

• 既存の類似サービスの真似をする
• 先に利用する技術についての勉強会を行う
• 知見を持つ技術顧問を雇う

上記のそれぞれに対する解決方法を用いることで、いくつかの原因を潰すことができると思います。次の章では、これらの解決策をふまえて私たちがどのような取り組みをしているのかについて紹介します。

5. Gaudiyの技術的負債に対する向き合い方

ここからは弊社が技術的負債とどのように向き合っているのかについて、いくつかの事例をご紹介しようと思います。

はじめに、弊社はWebアプリケーションを提供しています。メインのリポジトリは2つで、それぞれがモノレポの形を取っており、フロント, BFF, 複数のバックエンドサービスが管理されています。さらに興味がある方はこちらの記事をご覧ください。

5-1. 技術的負債を解消する取り組み

5-1-1. ソリューションの乗り換え

私たちのアプリケーションには、WindowAとWindowBでリアルタイムなやり取りをしなければならない仕様があります。これを実現するために、当初は window.postMessage() を1年近く利用し、うまく動いていました。ところがある日、それが負債であることに気がつきました。

この負債は、前章までに挙げた「影響範囲が大きく、目に見えない技術的負債」に当たります。感覚としては、ある日郵便受けを見ると、数千万円と書かれた連帯保証請求書が届いている感じです。当然びっくりしますね。

この負債に気がついた時に、問題や影響箇所の詳細について調査し、今乗り換えるべきかどうかをプロダクトオーナーを含めて相談しました。そして返済をするべき負債と決定したものの、どのようすれば返済ができるのかがすぐにはわかりませんでした。

ここで用いた方法が「知識の欠如」で挙げた「既存の類似サービスの真似をする」でした。幸いなことに、私たちが実現をしようとしていたタブ間通信と非常によく似ている挙動をするサービスを見つけることができました。その挙動がどのように実現されているのかをDevToolsのパフォーマンスタブやネットワークタブを用いて徹底的に調べ、解決方法を見つけることができました。

旧アーキテクチャ

旧アーキテクチャ図

新アーキテクチャ

新アーキテクチャ図

私たちのサービスは新たなアーキテクチャに乗り換えられ、（今この瞬間は）うまく動いています。

5-1-2. 戦略的に作った負債の回収

私たちのアプリケーションは一言でいうと「エンタメSNS」に当たります。機能として、投稿一覧で画像や動画などのリッチなコンテンツが見れたり、他にも様々なアニメーションや動的なコンテンツを提供しています。ユーザーを飽きさせないために、新しい機能を頻度高く提供をすることも多いです。

また、ブロックチェーンなどの不確実性の高い要素によってスケジュールの見積もりが難しい側面があり、時折、QCDでいうQualityを二の次にしDeliveryを優先した開発をすることもあります。そうして出来上がったコードは、当然ながら質が良いものではありません。

これは、前章までに挙げた「影響範囲が大きく、目に見える技術的負債」に当たります。ユーザーからは見えづらい負債であっても、後々すばやい機能開発やより良い体験の提供がしづらくなってしまうため、すぐに返済計画を立てる必要があります。実際に、弊社ではアジャイル開発をしているので、「次スプリントに負債返済を入れる」ことで解消しています。

また、このうちの一部は「影響範囲が小さく、目に見えない技術的負債」に当たります。その代表例になるのが、パフォーマンス劣化です。時間がない中で書いたコードは、吟味されたものではないため、その塵が積み重なると、いつのまにか目の前には大きな山ができあがっています。

この負債を返済をするためには、パフォーマンスチューニングという地道な作業をする必要があります。Gaudiyでは、この山を作らないようにするために「偶発的プログラミング」で挙げた「利用しているアルゴリズムとオーダー(O)を意識する」や「劣化が起きていないかCIのタイミングでLighthouseAPIを使いモニタリングを行う」を取り入れています。

5-2. 技術的負債を未然に防ぐ取り組み

最後に、そもそも借入をしないために、技術的負債を未然に防ぐ取り組みについてご紹介をします。

5-2-1. DDDの推進

DDDの目的は「影響範囲が小さく、目に見える技術的負債」を防ぐことです。

私たちのアプリケーションには複数のドメインが存在し、バックエンドではマイクロサービスの運用を行っています。ある時、追加開発を行う必要がでた時に、破壊的修正を要してしまうという問題を抱えていました。そこでDDDの導入を行いました。

結果的にドメインエキスパートの考え方やメンタルモデルをシステムに組み込むことができ、これによってレバレッジが効きつつも、柔軟性をもった開発ができるようになりました。これは「ビジネス的柔軟性」が原因で起こる負債を防ぐために機能しています。

5-2-2. ちょいコラ、ちょいデモ、マルチアイ

次に、パターン・ランゲージとして社内で使っている「ちょいコラ」「ちょいデモ」「マルチアイ」の取り組みです。この目的は「影響範囲が大きく、目に見えない技術的負債」を防ぐことにあります。

大前提として、人は誰しもがケアレスミスをしてしまいます。ですがこのミスは、他者とのコラボレーションをすれば防ぐことが可能です。それを日常的に意識するため、利用しているパターン・ランゲージが以下になります。

• ちょいコラ…デザインとビジネスの観点をエンジニアリングに取り込みたいときに、担当者がその人達に助言をもらいにいく。
• ちょいデモ…細かいサイクルでデモを実施して、実際に動くものを確認するタイミングを設けることで、ユーザー視点を最初から開発に取り入れる。
• マルチアイ…偏った視点ではなく、複数の視点を交えて、最適解を導き出す。

これらは「偶発的プログラミング」や「コラボレーション不足」が原因で起こる負債を防ぐために機能しています。

5-2-3. オールオーナー（ALL OWNER）の考え

この行動指針は「影響範囲が大きく、目に見える技術的負債」を防ぐために機能しています。

どれだけ経験を積んできた人でも、勘違いや誤ったリードをしてしまうことがあります。この問題は、言われたことを鵜呑みにしないことで防ぐことが可能です。

Gaudiyには16のクレド（行動指針）がありますが、そのひとつに「オールオーナー（ALL OWNER）」という考えがあります。自律分散的なブロックチェーンの考え方に基づいて運営されている弊組織では「相談した上で、自身で最終決定をする」という考え方が存在します。

この考え方が組織で当たり前となっているため、プロダクトオーナーや、開発経験が長い人、年上の人、その他すべての人の意見を脳死で受け入れることはありません。これは「ビジネスプレッシャー」や「誤ったテックリード」が原因で起こる負債を防ぐことができます。

5-2-4. ドキュメントをすぐに作る文化

最後に、ドキュメント文化は「影響範囲が小さく、目に見えない技術的負債」を防ぐために機能します。

私たちは、様々な技術や言語、プラットフォーム、さらにブロックチェーンという変化の激しい先進技術を利用して開発に取り組んでいます。十数人のエンジニアしかいない組織ですので、いちコンテキストに関わっているエンジニアは、1〜3人程度です。つまり、設計背景や技術知識が簡単に属人化してしまいます。この「属人化」を防ぐために、実施したことや知見をNotionに蓄積しています。これもひとりだと後回しにしがちなので、朝会や夕会のタイミングでドキュメント作成をタスク化しています。

6. まとめ

この記事では、技術的負債をテーマに、発生原因や返済方法などを弊社の具体例を添えて書かせていただきました。

正直、私は恵まれていると思っています。というのも、未熟さが故に発生させてしまった技術的負債を解消する機会を設けてもらえているからです。

よく「コードの改修（=リファクタリング）をしてビジネス的になんの旨味があるの？」と問われたり、「リファクタリングをするならこの機能を作ってほしい」と要求をされる組織があるという話を聞きます。この時に、エンジニアは、WHYをしっかりと答える責任がありますが、（上下関係や心理的安全性の低さが故に）そのWHYを答えることすらできない組織もあると聞きます。

冒頭で質問させていただいた「所属している組織のコードを誇りに思い、この先数十年間に渡って使い続けることができると確信していますか？」という問いに 「YES！」 と答えることが出来ないのは仕方がないことかもしれません。でもこれは、エンジニアだけが悪いという話ではないと思っています。サービスを提供する組織全体として技術的負債を認知し、その返済をサポートする必要があると思っています。

この記事を読んだみなさんが少しでも技術的負債への解像度を高め、上記のような働きかけができるようになれば、書いた甲斐があるなと感じています。

ここまで読んでくださり、ありがとうございました。 書ききれていないこともあるので、よければカジュアルにお話しさせてください。

meety.net

techblog.gaudiy.com

10min勉強会の導入と、運用改善をふり返る。

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

色んなアドベントカレンダーをみながら、もう2021年が終わるのか…という実感が湧いてきました。

今回は、約2ヶ月前から開発チームで取り入れた「10min勉強会」について、その運用と改善の道のりを振り返ってみたいと思います。

勉強会がなかなか続かなかったり、チーム間のコラボレーションを促したい方にかなりオススメなので、よければご参考ください！

1. 10min勉強会を導入した背景

元々Gaudiyでは「dev hour」という名の、1時間枠での勉強会を開催していました。

その後、職種横断のコラボレーションをより促進するために、エンジニアに閉じない全社向けの勉強会として「Gaudiy Hour」が今年の6月から始まり、その運用が継続されている状況でした。（今もGaudiy Hourの運用は続いています。詳しくは、デザイナーのTORAJIROくんが以下noteにまとめてくれてます。）

note.com

このGaudiy Hourは「発表するトピックを投票制で決める」というDAO的な仕組み（民主的なやり方）で、うまく運用を回せていましたが、開発が忙しい時期になるとどうしても「続かない…」という課題が再び発生してきました。

続かない理由はいくつかあるのですが、

• 開発が忙しすぎて時間が取りづらい
• 発表準備に時間がかかり、負荷が高い
• 1時間も話せるようなトピックは枯渇する

みたいなところがありました。

加えて、今年の夏頃からExperience TeamとPlatform Teamの2チーム体制に移行したことから、チーム間でのナレッジ共有がうまくできていなかったり、コミュニケーション頻度が減ってしまったことも新たな課題としてありました。

こうした課題を解決するため、今年の10月から「10min勉強会」の運用を、開発チーム全員を対象に導入してみることにしました。

2. 運用のはじまり

きっかけは、エンジニアのshoさんからの提案でした。

Slackを遡ってみたら、10月11日に提案がありました。

この10min勉強会は、ANDPADさんやログラスさんの発信を参考にして導入しました。

tech.andpad.co.jp

自律的に学んでいくチームにしようということで10分勉強会というものを始めました！
週3開催で障害対応以外のどのタスクよりも優先されます。
累計30回くらい開催できたら記事にしますね。

ANDPADさんの試みを参考にしてます！感謝！https://t.co/WIQky4WrCu pic.twitter.com/irH5h73ENi

— ゆいと🐳ログラスのエンジニア (@Yuiiitoto) 2021年9月29日

Gaudiyにおける目的としては、ナレッジを属人化させず、実際の開発で使えるようなレベルまでチームに浸透すること。10分という短い時間設定にすることで、日々のスコープでの学びや気づきを共有しやすくし、習慣化することを狙いとしています。

初期の運用としては、以下のような形でスタートしました。

• 開催日：月・水・金の12：00〜（10分間）
• 対象：開発チームのメンバー全員
• 内容：Notionにかるくまとめてシェア

GaudiyではSlackのハドルで会話する文化が根づいているので、10min勉強会も、月・水・金の12時に#dev_teamのSlackチャンネルでリマインダーを飛ばし、そこのハドルに全員が集まる形で実施しています。

スレッドに共有したいNotionやPRのリンクなどを貼ってます

3. つまずいたポイントと改善プロセス

2ヶ月ほど運用を続けてきた中で、いくつか躓いた点があったので、その改善プロセスについてもご紹介したいと思います。

3-1. 発表用の資料をつくらず、書記を立てる

はじめは発表者がかるくNotionにまとめてから共有するスタイルにしていましたが、人によっては準備に時間がかかることもあったので、発表者ではなく、他の人を書記に立ててドキュメント化するスタイルに変更しました。

これによって負荷が分散され、かつ発表が終わった段階できちんとドキュメント化がなされる状態をつくることができました。

実際の提案①

また、開始時刻に間に合わない人がいた時に、以前は集まるまで待っていることがあり、結局10分以上かかっていたことも課題のひとつでした。これに対しても、その場でメモを書き進めることで、途中から入ってきた人もある程度キャッチアップしやすくなりました。

3-2. ネタぎれ防止とkaizenをセットにする

もうひとつは、勉強会テーマの「ネタぎれ」の問題です。週3でやっていると、10分間とはいえ、発表ネタが尽きてくることがありました。

そこで10min勉強会の空いたコマに、Slackに投稿されているチームのkaizenを拾って、共有する時間を取り入れてみることにしました。

日々のSlackで、細かいレビューの観点や、細かいコード上の改善点などが共有されてはいるものの、投稿が流れてしまったりしてチームに十分浸透できていない課題もあったので、10min勉強会でその週のkaizenを拾いながら、軽く議論するみたいな形式も導入しました。

実際の提案②

Slackの共有で終わってしまいがちな細かいナレッジの蓄積だったり、習慣を途切らせない工夫として、うまく運用が回っている点かなと思います。

4. 10min勉強会を運用してみての変化

10min勉強会を運用してみて、ナレッジ共有の習慣がついたのと、課題のひとつであったチーム間でのコラボレーションが促進されるようになったなと感じます。

エンジニアメンバー全員が集まる場ができたことで、誰がどこに詳しいのか、何に興味持っているかが以前よりもわかるようになり、「このレビューだったら、この人に聞いてみようかな」という動きが、チームをまたぐ形で生まれてきています。

一方で、kaizenやナレッジの共有はチーム横断でできるようになったものの、それを実践まで落とし込むレベルまではまだ至っていないので、そこは今後の課題かなと思います。また、発表者が同じ人に偏りがちなところもあるので、うまく分散化する仕組みを導入していきたいです。

5. さいごに

今回は、Gaudiyの開発チームで取り組んでいる「10min勉強会」についてご紹介しました。

簡単に始められて、習慣化しやすい取り組みだと思うので、ぜひ試してみてください。

最近は個人としてだけじゃなく、チームとしてつよつよにならないとな、という思いが強いので、チームの改善に興味ある方がいればぜひお話ししてみたいです！

自分のmeety貼っておきます。

meety.net

あとGaudiy Hourは社外の人も参加できますので、よければぜひー

www.notion.so

LaunchDarklyを入れてフィーチャーフラグの運用を改善した話

こんにちは！エンタメ領域のDXを進めるブロックチェーンスタートアップ、Gaudiyでエンジニアをしている椿（@mikr29028944）です。

僕が所属しているExperienceチーム（ユーザー体験に関わる開発を担う）では、リリースのサイクルを極力短くして、ユーザーの方になるべく早く価値をお届けできるように「フィーチャーフラグ」を活用しています。

今年の7月頃から導入し、チームで運用を続けてきましたが、その中でいくつかの課題も見えてきました。そこで今回は、実際に直面した課題と、Gaudiyがそれに対してどのようにアプローチし、解決してきたかについて、お伝えできればと思います。

フィーチャーフラグを導入してみたけれど、うまく運用できていないチームや、フィーチャーフラグの導入を検討する上で、どのような課題が起こり得るのか把握したい方などにご参考になると嬉しいです！

1. フィーチャーフラグを運用する中での課題

はじめに、フィーチャーフラグの運用を理解いただく上で、Gaudiyのアーキテクチャ構成について簡単に説明させていただきます。

Gaudiyが提供しているコミュニティアプリのアーキテクチャは、下図のようなマイクロサービスアーキテクチャを採用しています。

全体のアーキテクチャ構成

ここでは詳細な説明は省きますが、この構成のもとで、新規フラグの追加フローとしては、以下のような形で運用していました。

1. データベースにフィーチャーフラグを追加
2. GraphQLのスキーマを修正
3. フロント側も同様にスキーマを修正
4. Notionなどのドキュメントにフィーチャーフラグの詳細を記入

ただ、このフローで生じてきた問題は、フィーチャーフラグの実装コストがめちゃくちゃかかる…ということです。特に感じた課題としては、2点ありました。

1-1. 全環境におけるフラグの状態把握がしづらい

データベース上でフラグを管理していたため、全環境×テナントごとに用意されているフラグを、一覧で確認することが不可能でした。

また、いつ、誰によって状態の変更がなされたかの把握が難しく、なにかあった際に誰に聞けばいいのかわからない状態でした。加えて、フラグを追加した人がNotionにその詳細を書くという運用をしていましたが、段々とメンテされなくなり、古いドキュメントのまま残り続けてしまう、といった問題もありました。

1-2. フラグの実装上のルールが統一されてない

さらに、使われなくなったフラグが削除されずに残り続けることで、コードベースを複雑化させてしまっていました。

たとえば、トップのコンポーネントですでに制御されているにもかかわらず、フラグを挿入してしまうなどの無駄が生じる問題や、フラグを挿入する際にリファクタリングで関数を分けるのではなく、そのコード上に上書きしてしまって一つの関数が肥大化していく、みたいな問題が起きていました。

これらに加え、他にも課題がたくさん……

カテゴリ	課題
管理	環境ごとのDBにフラグを用意するコストと運用ミスの発生
管理	Bizサイドなどの開発者以外の人がフラグを変更しにくい
UX	単一ごとのフラグ取得のローディング状態を考える工数がかかり、UXも悪化
設計・開発	実装コストが高く、メンテナンスが大変（※）
設計・開発	フラグを使う方法・宣言がバラバラ
設計・開発	もともとフラグを置く想定をせずにコンポーネント設計をしていたため、 既存のコードに置く際に散在してしまうことがある

※補足すると、BFFにフラグのコードを書いていましたが、フロントからの呼び出しも含めてフィーチャーフラグの実装コストがかかるのと、BFFのないサービス環境もあるため、その場合は実装の差異が生まれてしまってメンテナンスが大変という課題がありました。

2. フィーチャーフラグのツールを調査

これらの課題を解決するため、フィーチャーフラグのよりよい活用の仕方を検討している中で、フィーチャフラグ管理ツールの利用を検討することにしました。

いくつかのツールを調査した結果、Gaudiyでは「LaunchDarkly」というツールがよさそうだ、という結論になりました。

launchdarkly.com

各ツールの比較は、下図のCodeZineさんの記事がわかりやすかったです。

参照：https://codezine.jp/article/detail/14662

特にGaudiyの場合は、サービスの品質維持の観点から、リアルタイムでフラグの状態を切り替えられるという点が大きなメリットとしてありました。実際、瞬時にON/OFFが反映できるので、非常に運用しやすいです。

他にも、「ミニマムの場合はコストが抑えられる」「障害が起きてもフラグの状態が保存されるため、サービスの継続性が高い」「公式ドキュメントが充実している」などのメリットがあることから、LaunchDarklyを利用してフラグを実装し、リファクタリングを併せて行う運用に変更しました。

docs.launchdarkly.com

また、LaunchDarklyは、開発する上でのUXが良いのも特徴です。

たとえば、Gaudiyのエンジニアの多くが使用しているエディター、VS Codeのプラグインも備わっています。

このプラグインの特徴としては、以下の3点があります。

1. ソースコード上で各フィーチャーフラグの現在の値を確認できるため、そのためだけに管理画面に入ったり、どのような値が入るかをデバッグしたりする必要がない。
2. ソースコード上でフィーチャーフラグのkey入力を自動補完してくれるため、keyのタイポによる意図しないバグが生まれにくい。
3. VS Code上でフィーチャーフラグの値を変更できるため、変更のために管理画面にいく必要がない。

👆key部分をホバーすると、現在のフラグの値が確認できる

👆各フィーチャーフラグの値を変更できる

上記のような感じで、エディターのみでフィーチャーフラグの操作を完結でき、ストレスのないフラグ管理を可能にするのが、開発者目線での魅力かなと思います。

3. LaunchDarklyを導入して何が変わったのか

LaunchDarklyの導入と、コードのリファクタリングを実施した結果、以下のように前述した課題を解決することができました。

カテゴリ	課題	結果	詳細
管理	環境ごとのDBにフラグを用意するコストと運用ミスの発生	○	各環境に自動的にフラグが生成されるようになった
管理	Bizサイドなどの開発者以外の人がフラグを変更しにくい	○	GUIツールで誰でも更新がしやすい
UX	単一ごとのフラグ取得のローディング状態を考える工数がかかり、UXも悪化	○	フラグを一括で取得することができるようになった
設計・開発	実装コストが高く、メンテナンスが大変	○	フロントからLaunchDarklyのフラグを参照する形で実装コスト減
設計・開発	フラグを使う方法・宣言がバラバラ	○	フラグの使う方法・宣言をLaunchDarklyのuseFlagsに統一した
設計・開発	もともとフラグを置く想定をせずにコンポーネント設計をしていたため、既存のコードに置く際に散在してしまうことがある	○	リファクタリングを実施して解消した（※後述）

たとえば、フィーチャーフラグの設定一覧はこんな感じです。

👆右のトグルボタンのON/OFFでフラグを切り替えられる

また、サービス環境も一覧できます。

👆フラグ追加時に右の全環境にフラグが追加される

Gaudiyでは１つのソースで複数のサービス（コミュニティ）を管理しているため、フィーチャーフラグを追加した時に、全サービスに一律でフラグが追加されるのはとても便利です。

また、フィーチャーフラグまわりの課題解決だけでなく、特定のユーザー限定でフラグを有効にできる機能を利用することで、管理者ユーザーのみフラグをONにして、本番環境での動作確認をすることが可能になりました。これによって、テスト環境でのテストから、本番環境へのデータ移行をするコストが大幅に削減できました。

※付け加えると、一部のユーザーにこの機能を適用することで、クローズドβ公開のような限定公開も簡単に実現することができます。

4. 実装の際に注意していること

ツールを導入したことでかなり運用しやすくなりましたが、実装の際に注意している点がいくつかあるので、それについてもご紹介します。

4-1. 親コンポーネントでの制御を意識する

特にフロントエンドでは、バックエンドと比べてフラグが多くなる傾向にあります。そこで、できるだけ親コンポーネント側で制御することを優先しています。

こうすることで、フィーチャーフラグを使っていることを明示できますし、検証が終わったときには削除しやすくなります。

社内での工夫としては、フィーチャーフラグライブラリにあるLaunchDarklyのHooksを、Contextを使ったコンポーネントとして、複合コンポーネントを作って利用しやすくしています。

kentcdodds.com

...

// FeatureFlagを適用するためのコンポーネントを作成
export const FeatureToggle = ({ featureFlagName, children }: Props) => {
  ...
  return <FeatureToggleContext.Provider value={value}>{children}</FeatureToggleContext.Provider>;
};

const On = ({ children }: ChildProps) => {
  const { featureFlagEnabled } = useFeatureToggleContext();
  return <>{featureFlagEnabled && children}</>;
};

const Off = ({ children }: ChildProps) => {
  const { featureFlagEnabled } = useFeatureToggleContext();
  return <>{!featureFlagEnabled && children}</>;
};

FeatureToggle.On = On;
FeatureToggle.Off = Off;

フィーチャーフラグコンポーネントの活用例：

const Group = () => {
  ...
  return (
      <CommunityHome>
         // フィーチャーフラグを活用している箇所が深掘りをしなくてもわかる
        <FeatureToggle featureFlagName="groupTimelineReleaseFlag">
          <FeatureToggle.On>
              <TimelineGroupPage />
          </FeatureToggle.On>
          <FeatureToggle.Off>
              <GroupPage />
          </FeatureToggle.Off>
        </FeatureToggle>
      </CommunityHome>
  );
};

4-2. フィーチャーフラグの種類によって実装方針を定義する

また、フィーチャーフラグの利用法によっても実装の仕方は変わってきます。

Gaudiyでは、主にリリースフラグとアクティベーションフラグとして利用することが多いですが、できるだけコード上に存在しないほうが将来的な負債にならないと考えているため、リリースフラグとして早期に消すことを前提とした使い方が多いです。また、アクティベーションフラグに関しては、利用ケースとしても少し長期でみて、動作を変更したい時に利用しています。

リリースフラグを実装する場合は、例えばhooksの関数を制御したい場合は、同じ処理が重複することがあったとしても関数を２つ設ける方針にしています。これは消しやすさを優先した実装です。

そのため、スコープとしても、リリースフラグを消すところまで開発チームのコンテキストとして抱えるようにしています。

２つの関数に分けてフラグで制御するパターン：

const { singleGroupReleaseFlag } = useFlags();

const handleSubmitV2 = useCallback(
    async (value: TopicCreateValue) => {
        await createOrUpdateTopic(value);
    },
    [createOrUpdateTopic]
  );

const handleSubmit = useCallback(
    async (value: TopicCreateValue) => {
        ... // 他の処理
        await createOrUpdateGroupTopic(value)
    },
    [...]
  );

逆にアクティベーションフラグの場合は、すぐに削除できないものに利用されるため、２つの関数に分けて運用するのではなく、同じ関数内にフラグ制御を設けて使う場合が多いです。

これは長期に滞在することになるため、関連する箇所で不具合が発生した場合に、複数箇所を修正する必要が出てしまうことを避けるための運用です。デメリットとしては、より複雑になってしまうことがありますが、たとえば不具合発生時に、片方しか修正できていなかったなどの問題を考慮しての方針としています。

同一関数内でフラグによる制御するパターン：

const { singleGroupActivationFlag } = useFlags();

const handleSubmit = useCallback(
    async (value: TopicCreateValue) => {
       
　　 // フラグが適用される場合の処理　　　　
        if (singleGroupActivationFlag) {
            await createOrUpdateTopic(value);
　　 // それ以外
        } else {
            await createOrUpdateGroupTopic(value);
        }
    },
    [...]
  );

4-3. フィーチャーフラグの追加・更新管理

また、フィーチャーフラグを追加し忘れて実装してしまうことも一部発生していたので、フィーチャーフラグが必要かどうかのチェックと、名前、対象範囲、消すタイミングを開発チケットの段階で記入することで、抜け漏れを防ぐようにしました。

これにより、チケット作成の段階でフィーチャーフラグの考慮をするようになり、実装漏れすることがなくなりました。

👆実際のチケット

5. 解決できた課題とこれから

以上のようにフィーチャーフラグをうまく利用することで、開発コストの大きな削減と品質の向上につなげることができました。

現在はフラグが増えてきたこともあり、不要なフラグをきちんと削除することや、命名ルールなどを揃えてオペレーションミスが発生しづらくするなど、引き続き改善しています。

また、LaunchDarklyの料金プランを上げると、スケジュール機能やA/Bテスト機能なども利用できるので、このあたりは今後利用を検討していけたらと思っています。

6. おわりに

今回は、フィーチャーフラグの運用で出てきた課題と、その解決アプローチとしてのLaunchDarkly活用についてご紹介させていただきました。

まだまだ試行錯誤中なので、フラグのうまい利用の仕方や、出し分ける機能の粒度など、他社さんのよいTipsがあったらぜひお話をお伺いしてみたいです。

Gaudiyでは他にも、アジャイル開発を改善していくための取り組みを色々行っているので、開発プロセスの改善に興味のある方がいたらぜひお話ししましょう！

（僕のMeetyです。DDD以外でも全然大丈夫なのでよければ！）

meety.net

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

techblog.gaudiy.com

毎週水曜日、オープン勉強会やオープンオフィスもやってます！

www.notion.so

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

こんにちは！エンタメ領域の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. ペルソナごとにユーザーインサイトを作り出し、モデリングで可視化

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

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

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

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

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

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

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

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

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

2. インタビューの実施

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

さいごに

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

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

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

meety.net

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

meety.net

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

www.notion.so