トランクベース開発とカンバン改善でリリース速度を早めたDevOpsの取り組み

こんにちは、Gaudiyでエンジニアをしている勝又（@winor30）です。

アジャイル的に開発することは、ソフトウェアに関連するサービスをもつ会社であれば、ほぼ全ての企業が採用する意思決定だと思います。不確実性の高い現代社会において、柔軟かつ効率的にアプローチができる手法なためです。

そのプラクティスでよく言われることとして、「小さいバッチで開発して、頻繁にリリースをしよう」というものがあると思います。これを悪だという開発者の方はほとんどいないと思いますが、その実践はかなり難易度が高いと思います。

実際にGaudiyでも、アジャイルが大切であることは理解しながらも、個人の意識、文化、しくみ等が十分ではなく、自然とアジャイルから離れることを行ってしまうことがありました。

そこで最近、QAやユーザー価値を担保しながら「小さいバッチで開発して、頻繁にリリースをしよう」という理想を追求するために、トランクベース開発をはじめとした様々なしくみやプラクティスを導入してみました。

実際に成果も出てきているので、今回はその取り組みをご紹介していきたいと思います。

そもそも「小さいバッチで開発して、頻繁にリリースをしよう」なのはなぜ？

問題点や実際やったことを書く前に、先に理想的な状態とその理由に関して書いておきたいと思います。

そもそも「小さいバッチで開発して、頻繁にリリースをしよう」なのはなぜか、についてです。これは、アジャイル的な開発を進めていき、よりユーザー価値のあるプロダクトをアウトプットすることに繋がるためです。

なぜアジャイルが使われるか？と同じ理由にはなりますが、どんなユーザー価値があるのか？どうやればよいのか？というのは、現代の市場やプロダクトの不確実性が高いことから、すべてを詳細まで予測することはかなり難しいです。

そこでアジャイル的な開発では、今提供できるユーザー価値を頻繁にアウトプットしていくことで不確実性を徐々に潰しつつ、フィードバックループを回して意思決定の変更を頻繁に行うことで、最終的な予測を確実なものにしていく必要があります。この意思決定の変更を頻繁に行い、プロダクトを正しく作るためにも「小さいバッチで開発して、頻繁にリリースをしよう」が必要となります。

この「小さいバッチで開発して、頻繁にリリースをしよう」やアジャイル的な開発がなぜ必要なのか？に関しては、最近の資料ですと、@t-wadaさんが書かれた下記資料が非常によく分かるので、ぜひ一読いただきたいです。（他の話題に関しても書かれていますが、歴史から理解できる内容だと思います）

speakerdeck.com

既存のしくみ・問題点

既存のしくみは、カンバンとGitフローを採用した開発フローになっていました。ざっくり説明すると、カンバンの1チケットが1つのPRに相当し、このチケットが大きな機能を表現していました。それを様々なステークホルダーでレビューした上でマージし、全体の機能ができたらリリースをしていく流れとなっていました。

理想状態を目指す上では、基本的に大きなバッチの開発によるリードタイムの低下が問題となっていました。さらにその原因を細分化すると、下記のような問題がありました。

1. リソース効率（マルチタスク）に陥りやすい
   • mainブランチとの乖離が大きいfeatureブランチでQAをする
     • 開発以外の視点がこのときに入るのは👍
     • 差分が大きくて、マージまでの速度が上がらない → 待っている間に他のタスクをやる → リソース効率
2. コンフリクトやデグレリスクが高まる
   • 早くmainブランチに取り込まれないため、差分が大きくなりコンフリクトやデグレの確率が上がっていた
   • 結局mainにマージする前のreleaseブランチでリリースする機能すべてにQAをして、バグを洗い出し、リリースみたいな感じになってしまい、アジャイルらしくなかった
3. ユーザー価値の測定・判断が不明確
   • featureブランチでの検証や価値を判断する項目が多い
   • もっと前に気づけたのでは？みたいなことがあって出戻る

上記の問題を解決するために、トランクベース開発の導入とカンバンの見直しを行いました。

トランクベース開発とは？

引用：Trunk Based Development

トランクベース開発とは、メインブランチ（トランク）をベースとして、トランクに対して修正を行っていく方法です。詳細に関しては、GCPの記事が分かりやすいかと思います。

DevOps 技術: トランクベース開発 | Google Cloud

トランクベース開発の本質的な価値としては、トランクと修正するブランチの差分が極限まで下がり、コンフリクトやデグレリスクを下げつつ、トランクを常に最新の状態に保つことができる点だと思います。

この性質が特に今回の課題であった「１. リソース効率に陥りやすい」「２. コンフリクトやデグレリスクが高まる」に関して、効果がありそうだと考えました。

カンバンで足りなかったところは？

今までのGaudiyのカンバンでは、「ストーリーを小さく分割し、リードタイムを短くする」という部分に対して、うまく動けなかったところがありました。これを実現することによって、このチケットでなにを行えばよいのか？というゆらぎが減りつつ、最速でユーザーへの価値提供ができるようになり、様々な側面での不確実性を減らすことができるようになります。

これは当たり前ではあるのですが、意外とカンバンやスクラムをやることに集中してしまい、それに慣れてしまって形骸化していたのが事実としてあったので、今回の機会にカンバンとしてどう進めればよいのか？何を意識すべきなのか？というところを再考しました。

実際に導入したトランクベース開発とカンバンのプラクティス

今回行ったトランクベース開発とカンバンのプラクティスは、下記のようなものを導入しました。

• トランクベース開発に必要なプラクティスの導入
  • Githubフローライクな自動デプロイ設定
  • 同期的なレビューを率先して行う
  • mainブランチがデプロイできない状態を作らないように徹底する
• カンバンの見直し
  • デイリースタンドアップで青ワークに切り替える
  • ストーリーの価値を明確にし、その検証を小さく多角的に行う
  • WIP制限をうまく使い、リリース頻度を上げる

トランクベース開発に必要なプラクティスの導入

トランクベース開発は原則として、トランクを中心に開発していく開発手法になります。ただし、これを実現するためには、レビューコストと自動テストが課題となります。そのため、トランクベース開発を導入しつつこのあたりの課題も解決するようなプラクティスを導入しました。

Githubフローライクな自動デプロイ設定

Gaudiyでは今までGitフローを採用していました。開発してPRがマージされたものが取り込まれるdevelopブランチが存在し、大きな機能開発があるときはfeatureブランチを作ってそこで開発していました。リリース準備にはリリースブランチを切り、最後にmainブランチにマージすることで、デプロイ・検証・本番反映を通してリリースが完了するような流れでした。

わりと自然にこのような形にたどり着いたのですが、ブランチ間の差分が大きくなることが多々あり、コンフリクトリスクやレビューのコストが増大していました。

ここから、トランクベース開発に変えるために、developブランチを削除し、PRを基本mainブランチからしか切らないようにしました。

また、各環境のデプロイに関しては、mainブランチマージ時にdevelopとstaging環境にデプロイし、mainからリリースタグを切ることによって本番環境にデプロイするようになっています。この理由としては、基本的にmainブランチにマージされたものがユーザー価値の現在の最新状態であるため、それを各環境にできるかぎり反映し、検証やすぐに本番反映できるような状態にしておきたかったためです。

同期的なレビューを率先して行う

トランクベース開発の原則として、mainブランチとPRの差分は極力減らす必要があります。そこで大事なのが、レビューの速度を上げることです。そのため、Gaudiyでは以前から取り組んでいるペアプロを率先して行いつつ、ペアプロを行わなかった場合でも同期レビューを頻繁に行うようにしました。

基本的に非同期のレビューも行ってはいるのですが、デイリースタンドアップ等でPRを投げているがレビュー待ちなものがあるというところから判断し、同期レビューをそこでアサインするようになっています。

mainブランチがデプロイできない状態を作らないように徹底する

トランクベース開発では、mainブランチは基本いつでもデプロイできる状態を作る必要があります。これを実現するために、下記のようなことを行いました

• featureフラグをうまく使う
• 自動テストを使って、品質を担保する

featureフラグとは、新しい機能を隠してリリースを行いたいときなどに、その機能を隠す（制御できる）フラグのことです。featureフラグはかなり昔からある考え方になりますが、トランクベース開発ではデプロイ可能状態というものを維持することが重要になるので、featureフラグを使いユーザーにはまだ見せないがデプロイはしたいみたいなことを実現できる必要があります。

自動テストを使って、品質を担保するについては、基本的にはよくあるCI時の自動テストになります。GoでもReactの場合でもunit test、hooksのtest、コンポーネントのインテグレーションテストなどCI環境で実行できるものはすべて実行し、基本的に品質担保を目指します。また、GaudiyではAutifyという自動E2EテストのSaaSを利用しており、これを毎日実行することでmainブランチの品質担保をしています。

詳しくはGaudiyの西岡が下記ブログで説明しているので、興味ある方は読んでいただければと思います。

GaudiyがAutifyを導入して手戻りコストを削減した話 - Gaudiy Tech Blog

また、このあたりのテストや検証で気づいたりした場合は、基本的にその問題の優先度を上げ、なるべくデプロイ可能な状態を作ることにフォーカスすることも重要な点です。

カンバンの見直し

さらに、「小さいバッチで開発して、頻繁にリリースをしよう」を達成するため、カンバンでもいくつかの点を見直しました。これらの改善点も基本的にはアジャイル的な原則に従った、ということが結論になります。

デイリースタンドアップで変更できるようにする

デイリースタンドアップが形骸化されていたときは、タスクの進捗や困ってることの報告がメインになっていました。この方法でも、どこまでチームが達成しているのか？が分かるので良いとは思うのですが、アジャイルの原則で言えば、そういったことを踏まえてどう柔軟に意思決定を変えていけるか？ということが大事になります。

これを実現するために、デイリースタンドアップでは上記のような報告に加え、どうしたらよりリードタイムを縮めることができるかをベースに、どう変更することができるのか？を問いかけるようにしています。具体例としては、ストーリーの分割を行ったり、ビジネスの状況から考えて次優先すべきところを話したりなどがあります。

また、この変更するような作業を「青ワーク」と呼び、プログラミングやデザイン作るなどの作業を「赤ワーク」とGaudiyでは呼んでおり、言葉としても使うことで「今は青ワークだから変更に柔軟になろう」と意識付けられるようにしています。

ストーリーの価値を明確にし、検証を小さく多角的に行う

もうひとつ、ここも形骸化されやすいポイントですが、チケットのストーリーの価値を明確にすることに注力しました。基本的にテンプレートを作成し、作業に入る前には必ず書くようにしました。このチケットを達成したとき、ユーザーにどんな価値を提供できるのか？というところを明らかにしてから作業に入るように徹底しています。

また、ユーザー価値の検証のためにストーリーが一通りできたら、エンジニア、デザイナー、Biz、コミュニティマネージャーなど様々な視点からそのストーリーの検証を同期的に行い、どこが良いか、どこが改善必要 or 足りないかなどを実際にアプリを触りながら話すようにしています。

ストーリー分割とこのプロセスが合わさることで、かなり認識のブレはなくなりつつ、開発としてもYAGNIな精神を維持することで、バーティカルスライスを意識した開発を実現することができます。

WIP制限をうまく使い、リードタイムを減らす

引用：Recruit Tech Blog

カンバンの原則として「WIP制限」というものがあり、これを徹底することでリードタイムを下げるようにしています。

詳しくは下記記事が分かりやすく書かれているので、こちらを見ていただければと思います。

SUUMOアプリチームがスプリントを廃止してカンバン方式に移行した話

WIP制限とはフロー効率的に動くためにカンバンボードに導入される仕組みとなります。フロー効率とは、たくさんの仕事に労力をかける（リソース効率）よりも、何かの１つの仕事にフォーカスし、それを終わらせたあとに次の仕事に集中する方式（フロー効率）のほうが最終的にかかる時間は同じ、かつリードタイムは短くなるという考え方です。これを実現するために、カンバンではWIP制限というものが存在し、カンバンボード内で取り掛かることができるチケットの枚数を制限しています。

Gaudiyでは、作業中やレビュー中などのレーン単位でWIP制限を導入し、基本的にそれを超えないように作業しています。WIP制限により、多くの種類の仕事ができないため、ペアプロなどの同期的作業が強制され、属人化の防止やレビューコスト削減などの恩恵もあります。

結果

今回のトランクベース導入とカンバンの見直しを行いよりアジャイルな開発文化に変えた結果、リードタイムがかなり短くすることができました。また、下記例は１週間だけですが、基本的にこのぐらいのリードタイムを安定して出しているので、定常的にアウトプット出せているものだと思います。

リードタイム10日

リードタイム4日

また、定性的なものを例に上げると、チームのメンバーからも「開発フローがガラリと変わったけれど、よりアジャイルな開発になって前よりもストレスなく開発できる」という声も上がっていました。

まとめ

今回の記事で紹介したとおり、トランクベース開発とカンバンの改善を行ったことにより、アジャイルな「小さいバッチで開発して、頻繁にリリースをしよう」という理想的な状態に少しだけ近づくことができたと思います。

特に、チームのメンバーからも「アジャイルな開発に明らかに変わった感じがして良かった」という声が上がったのはかなり良かった点かなと思います。

ただ、まだまだ改善できる点はあり、Gaudiyはかなり不確実性が高い事業領域を扱っていることもあるので、よりアジャイルな組織を目指していければと思っています。Gaudiyの開発組織に興味を持っていただいた方は、ぜひ気軽にお話ししましょう！

▶︎カジュアル面談はこちら

▶︎オープンオフィス・オープン勉強会はこちら

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

techblog.gaudiy.com

GaudiyがAutifyを導入して手戻りコストを削減した話

こんにちは！エンタメ領域のDXを推進するブロックチェーンスタートアップ、Gaudiyで社員代表（笑）をしている西岡（@TakeshiNishioka）です。

今回はスタートアップ企業の社員代表がどのような役割を担っているかを、この場を借りて紹介させていただきたいと思っています。

…というのは冗談で、今回は主に業務で携わっているプロダクト開発のプロセスや、QAまわりのお話をさせていただこうと思います。

前回に永井（@sho0910K）から紹介させていただいたATDDの話にも関係する内容になりますので、併せてご覧いただけると嬉しいです。

techblog.gaudiy.com

プロセスやQAまわりお話といわれても「？」と思いますので、そもそもの前提からお話しします。

Gaudiyに求められる速度と品質

Gaudiyはいわゆるスタートアップといわれる企業ですが、事業ドメインがエンタメ領域ということもあり、週刊少年ジャンプの漫画『約束のネバーランド』など人気IPのコミュニティサービスを開発・運営させていただいています。

人気IPかつ、集英社やアニプレックス社など誰もが聞いたことのある企業様との協働になりますので、弊社が提供するコミュニティサービスには高いレベルのクオリティを求められていますし、プロダクトの品質も同様となります。

さらに複数のコミュニティを並行開発しており、まだ未発表のIPも多数動いている状況のため、肌感覚で普通は3ヶ月ほど掛かる規模の開発を1ヶ月でリリースするぐらいのスピード感が求められています。

ただ早ければ良い訳ではなく高い品質も求められますので、個々のスキルは当然ながら、チームとしてどれだけ効率良くプロセスを推進できるかが大切になります。

分かりやすくいうと、どれだけ手戻り作業をなくせるか、どれだけ重複や無駄な作業をなくせるか、が肝になります。

手戻りや重複など無駄な作業を発生させない為に

無駄な作業を発生させない為に、GaudiyではAgile的な取り組みを実施していますので、３つ紹介します。

スリーアミーゴス

前回のATDDでも紹介されていますが、Biz（BizDev、コミュニティマネージャー）、デザイナー、エンジニア、テスター（テスターはPOやPdMが兼任することが多い）が、ストーリーマッピングや受け入れ条件の設定、QAにも参加して、多角的な視点を取り込みながらプロダクト開発を推進しています。

早い段階から複数職種の視点を加えることで、開発視点だけでなく、クライアント要求、顧客価値の側面で問題点に気付け、手戻りの発生を防ぐことができています。

とはいえ、大人数になって逆に効率が悪くなるのではないか？と思われるかもしれませんが、Gaudiyでは最小・最適なコラボレーションを促進しているので、 個別に確認できることは日々のコラボレーションで解決したり、同じロールの人が複数参加しないなど、同じ視点が重複しないように意識しています。

GaudiyではFourAmigos

バーティカルスライス

次に、ストーリーを可能な限り小さく分割することを意識しています。

具体的には、実装からQAまで最大でも3日で完了できるボリュームに抑えています。

その理由として、Gaudiyではカンバンを運用していますが、大きいチケットでは１つのレーンに数日間留まってしまい、同じチケットだけでWIP制限に達するなどしてレーン全体の動きが滞りかねません。視覚的に動きがないとメンバーのモチベーションにも影響を与え、ボディーブローのようにチームの生産性を落としていきます。

一方ストーリーを小さくすると、チケットに対する解像度が上がり、デイリースタンドアップで他のメンバーからの疑問や懸念も挙がりやすくなったり、担当者が気付けていない問題や課題が見つかりやすくなりました。

また、無駄のないハッピーパス（正常系）を通すことができるようになり、ハッピーパスのQAを早い段階で行えるので、QAで挙がった修正箇所の修正コストも抑えられています。

さらにQAが必要な範囲も狭まるので、QAに参加するスリーアミーゴスの拘束時間も減らすことができています。

薄くスライスしてもケーキとして価値がある

リグレッションテスト

最後はリグレッションテストです。けっこう普通に思えるかも知れませんね。

ただ前述の通り、小さいストーリーで細かく結合しているので、その度に既存機能でデグレが発生していないかをテストする必要があります。

まとめてリグレッションテストをしてデグレが見つかると、手戻りの修正コストが大きくなるので、ストーリーを結合する度にテストを実施しています。

頻繁にリグレッションテストを実施するので、常にリソースが枯渇しているスタートアップでは手動テストは現実的に難しく、その問題を解決する為にUI自動テストを導入しています。

ただUI自動テストを導入するといっても、エンジニアにテストコードを書いてもらうのもリソース的に厳しいので、ノーコードでE2Eテスト作成・自動化できるツールの導入を検討しました。

いくつかのツールを検討して、GaudiyではAutifyを選定しました。

autify.com

選定した理由は下記の通りです。

• シンプルで直感的に操作しやすく非エンジニアでもテストが作りやすい。
• AIによる画面の細かなズレも学習してチェックしてくれる。
• CSがとにかく丁寧に対応してくれて、かつリードタイムが早い。

またUI自動テストをどのように使っているか？ですが、まずは開発プロセスの中にUI自動テストのテストシナリオを作成するプロセスを組み込んでいます。

どれだけツールが優秀でも、それを使わないと意味がないので、カンバンにテストシナリオ作成・実行のレーンを設置しています。

また作成されたテストシナリオは、以下のケースで実行するようにしています。

＜定期実行＞
定期的に1日1回実行しています。
テスト結果がNGの場合は、NG箇所を確認してOKになるように修正して再実行します。

＜手動実行＞
Autifyのテストプランを実行するSlackアプリを作成して、任意のタイミングでSlackから簡単に実行できるようにしています。
開発中のコードが既存機能に影響を与えていないかをいつでもチェックできるようにしています。

Slackアプリ（Hatty）がAutifyのテストプランを実行

＜自動実行＞
GaudiyではSlackでリリース告知を行っていますが、リリース告知を行っても上記のSlackアプリが起動して自動でリグレッションテストが実行されます。

このようにGaudiyでは、UI自動テストによるリグレッションテストを頻繁に実行することでリリース後のデグレを防止するとともに、開発プロセスでの手戻りの発生を抑えています。

Autifyを使ったテスト事例をちょっとご紹介

先ほど紹介したAutifyを、Gaudiyでは「こんな感じで使ってますよ！」というのを少し紹介したいと思います。少しでも参考になれば嬉しいです。

前述の通り、Gaudiyではリグレッションテストを何度も実行しますので、繰り返し実行が可能かつ同じ操作が行われ、同じ結果にならなければなりません。

また同じ操作が行われ、同じ結果になったとしても、初回と2回目以降で違うロジックが走ってしまうのもテストとしては不十分です。

基本的にはテストシナリオはポチポチ操作だけでほとんどの画面や機能のテストシナリオは誰でも作成できます。ただ、Gaudiyのコミュニティサービスでは、DID（分散型ID）で外部アプリとID連携して取得したデータを使うファンバサダースコアや招待機能など、データを操作しないと繰り返してテストが行えない機能もあります。

そんな機能のテストでは、AutifyのJSステップ機能を使い、JavaScriptからコミュニティサービスのテスト用APIを呼び出してデータの初期化や登録、アカウントのステータスを更新するなどしています。

データを初期化するJSステップ

データを登録するJSスキップ

上記のようにGaudiyでは、AutifyのJSスキップとテスト用APIを駆使して、複雑な機能や手動では複数人で行う必要がある機能のテストを自動化しています。

さいごに

今回は手戻り作業などで発生してほしくないコストをなくす為の取り組みについてご紹介させていただきました。

スタートアップでは、エンジニアのリソースが常時不足しているのはよく耳にする話ではありますが、エンジニア以外のリソースも常時不足しています。

そんな状況下でGaudiyでは、組織・チームとして手戻りや重複など無駄なコストをいかに発生させないかについて強い意志を持って取り組んでおり、今回紹介したこと以外にも、フレームワークやツールの導入も積極的に行い、最大効率、最小工数で最大成果を生み出す組織を目指しています。

そんなGaudiyに少しでも興味を持ってもらえましたら、ぜひ一度お話を聞きに来てください。

▼毎週水曜、オープン勉強会&オープンオフィスを開催しています

gaudiy3.notion.site

▼カジュアルにお話ししましょう

meety.net

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

techblog.gaudiy.com

ATDDの実践 ー非エンジニアの視点を取り込んだフロントエンドTDDの進め方ー

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

今回はGaudiyのフロントエンド領域の開発で実施しているテストに関してご紹介したいと思います。

第2回の内容で弊社の後藤（@PTeamd）からも紹介がありましたが、Gaudiyではコラボレーションを重視した組織文化、プロセスを採用しています。そのテストにおいては、ATDD（受け入れテスト駆動開発）を推奨・実施しています。

プロジェクト単位で開発していますが、各プロジェクトチームに関わるメンバーとしては、以下3つの職種が存在しています。

• Biz（BizDev、コミュニティマネージャー）
• デザイナー
• エンジニア

ATDDでは、このメンバー間でコラボレーションすることで、プロダクトの品質を高めています。

Gaudiyが抱えていた課題

まず、GaudiyでATDDを採用した背景としては、リリースサイクルを回す中で、Biz・デザイナーとエンジニアとの間で、コラボレーションの課題が存在していました。

具体的には、

• エンジニアがリリースしたものをBizがわからない
• Bizとデザイナーが意図したものと異なる形でリリースされてしまった

などです。

結果として、エンドユーザーに対してのリリース告知に漏れが発生したり、体験として良くないものを提供してしまうなどの課題が存在していました。

これを解消するために、リリース前のテストを手厚くするなど、Bizとデザイナー、エンジニアでテスト実施のコラボレーションをすることも考えました。

しかし、そもそも開発に入る時点にフォーカスすることで手戻りを無くすことや、エンジニアが何を開発していて、次にエンドユーザーに向けて何をリリースできるのかを事前に把握することができないか、それらを実践できる良い手段は存在しないかを求めてたどり着いたのが「ATDD（受け入れテスト駆動開発）」でした。

ATDDとは

ATDDを取り入れていくにあたっては、BASEさんの資料がとても参考になりました！
詳しくはこちらの資料を見ていただいたほうが理解しやすいと思いますので、ここでは省略させていただきます。

ATDDは、Acceptance test–driven development（受け入れテスト駆動開発）とあるように、ユーザーストーリーの受け入れ基準をベースとしたTDD（テスト駆動開発）になります。

開発するにあたってのユーザーストーリーの受け入れ基準は、エンジニアだけで書けるものではありません。つまり、コラボレーションを重視したテスト駆動開発になります。

GaudiyのATDDプロセス

GaudiyのATDDプロセスは以下の手順で行われています。

1. チケット上でのストーリー受け入れテスト作成
2. フロントエンドTDDの準備
3. フロントエンドTDD
4. レビューでの受け入れ条件の確認

それぞれ順を追って説明したいと思います。

１．チケット上でのストーリー受け入れテスト作成

Gaudiyでは、開発のチケット管理をClubhouseを使って管理しています。
開発チケットはユーザーストーリー単位で作成しており、Bizとデザイナーと一緒に作成しています。そのため、このチケット内に受け入れ基準をベースとしたテストケースを記述していくようにしました。

こうすることで、そのユーザーストーリーでエンドユーザーに届けたい価値を確認しつつ、それを達成するための受け入れ条件としては何が必要になるのかをスムーズに記載していくことができます。

チケットのサンプル

このテストケースの作成に関しては、Gherkin記法を採用しています。
これはBDD・ビヘイビア駆動開発 と呼ばれる、振る舞いを軸とした開発手法ですが、この振る舞いをユーザーストーリーの受け入れ基準として扱う点でATDDとしても利用ができます。

Gherkin記法はそれぞれ、Given（振る舞いを実行する前の状態）、When（振る舞い）、Then（振る舞いの結果）を表しています。Andは複数条件の場合に利用します。

例）
Scenario: 特定のコミュニティをフォローできる
Given ログイン済み
And 未フォローのコミュニティがある
When 特定コミュニティのフォローボタンを押す
Then 特定コミュニティがフォローできる

BDDツールにもいくつか存在しますが、ほぼ自然言語のみで書くことができ、非エンジニアとの共通認識をとりやすい点、また後ほど紹介するフロントエンド開発でのTDDプロセスへの流用も扱いしやすかったこともあり、CucumberのGherkin記法を採用しました。

２．フロントエンドTDDの準備

コラボレーションして記載したテストケースを使い、今度はフロントエンドにてTDDで開発を進めていきます。ここでは、Clubhouseで作成したテストケースをそのまま流用できるようにしています。

フロントエンドの開発環境には、Visual Studio Codeを利用していますが、Gherkinを扱いやすいように事前に２つのExtensionを導入しています。

marketplace.visualstudio.com

marketplace.visualstudio.com

まずはテスト用のディレクトリに、featureファイルを作成し、Clubhouseで記述したテストケースを貼り付けます。このまま保存すると、CucumberのExtensionによってフォーマットされます。

Feature: コミュニティのフォロー処理

Scenario: 特定のコミュニティをフォローできる
 Given ログイン済み
 And 未フォローのコミュニティがある
 When 特定コミュニティのフォローボタンを押す
 Then 特定コミュニティがフォローできる

Scenario: フォロー後続けて、別の未フォローコミュニティのフォローボタンを押す
 Given ログイン済み
 And 未フォローのコミュニティがある
 When 特定コミュニティのフォローボタンを押す
 Then 特定コミュニティがフォローできる

Scenario: 特定のコミュニティをフォローした後、フォロー解除ができる状態になる
 Given ログイン済み
 And 未フォローのコミュニティがある
 When 特定コミュニティのフォローボタンを押す
 Then フォロー解除ボタンが表示される

次に、このファイルからテストコードを自動生成します。
ファイル内の Feature 部分にフォーカスを当てて右クリックメニューを表示すると、「generate code from feature」というメニューがあるので、これをクリックすると、クリップボードにテストコードがコピーされます。

コピーされたテストコードは、事前に用意しておいた、テストファイルに貼り付けます。

３．フロントエンドTDD

エンジニアがTDDで開発を行っていく流れになります。
テストケースが複数ある場合は、１つ目以外は一旦はskipにしつつ、コードを組み立てながらテストを確認していきます。
テストコードは、Given-When-Thenにあわせて記載していきます。

テストコードのサンプル

test('特定のコミュニティをフォローできる', ({ given, and, when, then }) => {
 given('ログイン済み', () => {
 render(<CommunityCard userId={USER_ID} community={communityData} />);
 });

and('未フォローのコミュニティがある', () => {
 expect(screen.getByRole('button').textContent).toBe(`フォローする`);
 });

when('特定コミュニティのフォローボタンを押す', async () => {
 fireEvent.click(screen.getByRole('button'));
 await wait();
 });

then('特定コミュニティがフォローできる', async () => {
 expect(screen.getByRole('button').textContent).toBe(`フォロー中`);
 });
 });

４．レビューでの受け入れ条件の確認

エンジニアによる開発完了後、プルリクエストの段階でもBizとデザイナー含めてレビューを実施するのですが、コードも少しわかるメンバーの場合は、アプリケーションとしての動作確認だけでなく、実際に受け入れ基準が守られているかをコードベースでも確認してもらうことができます。

また、ATDDの形でテストコードを書いていることで、他プロジェクトのエンジニアがレビューする際にも、何のためのコードなのか、これによってどんな価値を届けることができるのかを確認の上でコードレビューしてもらうことができます。

さいごに

フロントエンドでのATDDに関して、チケットでのコラボレーションから実際のコードでの実装まで書きました。

今回紹介したのはReactのhooksとコンポーネントのテストにスコープを置いた内容となっていますが、ユーザーストーリーによっては、ページをまたぐ場合など、E2Eレベルのテストだったり、パフォーマンスなど、実証ツールが必要な場合も存在しています。その時は、Autifyやマニュアルテストも取り入れています。

テスト駆動にならないものも存在してしまいますが、プロダクト開発で大切なことは、ユーザーストーリーをプロダクトの価値として、僕らのユーザーであるファンの方々に届けられることだと思います。そこをブレさせないためにも、エンジニア以外の視点をテスト観点に織り交ぜていくATDDはオススメできるものだと思います。

このブログを読んでご関心を持ってくださる方がいれば、ぜひ一度カジュアルにお話ししましょう！TwitterのDM（@sho0910K）でも、Meetyからでもぜひお気軽に。

meety.net

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

techblog.gaudiy.com

毎週水曜に開催しているオープン勉強会も、よければ遊びにきてください。

www.notion.so

 

 

 

 

 

 

 

 

 

 

エンジニア向け会社説明資料をNotionでつくりました。

みなさま、こんにちは！ファンと共に時代を進めるWeb3スタートアップ、GaudiyでPR・HRまわり担当している山本（@hanahanayaman）です。

本日はエンジニアのみなさまにお伝えしたいことがあり、テックブログに初投稿させていただきます！

今回お伝えしたいことは、シンプルにこれ↓↓

エンジニア向け会社説明資料「Culture Deck for Engineer」
を作りました！！！

せっかくなので背景と想い、新しい取り組みについてもあわせてお伝えします。

Be Agile にとりあえずNotionで

弊社ではほぼ全職種で積極採用中ですが、なかでも特に採用強化しているのがソフトウェアエンジニアです。現在、Gaudiyには30人ほど（副業・業務委託含む）のメンバーがおり、約40%がエンジニアになりますが、リソース的には全然たりておりません…。

事業の状況としては、誰もが知るような大型IPとの新規案件が続々と控えており、まじでがちで仲間を増やさなければという危機感をもっております。

そこで始まったのがこのテックブログであり、今後はGaudiyの開発組織やカルチャー、技術などをもっと伝えていけたらと思っていますが、今回はエンジニアさん向けの情報をぎゅっとまとめた資料として「Culture Deck for Engineer」をつくってみました。

全職種向けの採用スライドよりも詳細な、プロダクト開発にまつわる情報をまとめたり、面接でよくお受けする質問へのアンサーなども記載しています。 

そして今回は、弊社の行動規範のひとつ「Be Agile」にのっとり、Notionでサクッと作成する感じにいたしました。公開→フィードバック→改善のサイクルを回して、ブラッシュアップしていきたいと思います！

もっとゆるやかな場をつくっていきたいお気持ち

最近すごく思っているのが、採用でもっとゆるやかな接点を作りたいなということ。

転職とか全然考えてないけど、なんかおもしろいことやってそうな他社の話って純粋に聞いてみたくないですか？

なので、人事担当が会社説明するカジュアル面談ではなく、"カジュアル面談よりももっとカジュアルな場" みたいなのをどんどんつくっていきたいと思っています。

そんな文脈で、3つの取り組みをご紹介します。

1. Meetyやってるよ

弊社代表やエンジニアなど、複数のメンバーがMeetyやってます。現場メンバーと直接好きなテーマでお話しできるのでよければぜひ。

2. 社内勉強会「Gaudiy Hour」をオープン勉強会にするよ

※2022年6月現在、一時休止中です。

毎週水曜16時〜開催している社内勉強会「Gaudiy Hour」ですが、外部の人も参加できるオープンな場にしていこうと思います。昨日、早速おひとり来てくださいました。

デザインシステムの勉強会

今後の開催予定はこちら↓↓

7/21：Dapps（ブロックチェーンを使ったアプリ）をエンジニアの解説付きでみんなでお触りする会
7/28：会計の見方 入門編

全社でやっているので、いろんなテーマがあります！気になる回にぜひお越しください。

3.オープンオフィスもはじめるよ

※2022年6月現在、一時休止中です。

オープン勉強会に加えて、毎週水曜の17時〜オープンオフィスをはじめます。簡単な事業説明や、その場にいる社員と交流できるような時間にできればと思います。

最近「かき氷機」導入しました。ぜひ食べにいらしてください

さいごに

私は今年4月に正式Joinしたのですが、手前味噌ながらガウ社めちゃくちゃおもしろいことやっていると思ってます。代表の石川さんから事業ロードマップやビジョンの共有があるたびに、ワクワクが止まりません。

ファンと共に時代を進めていく未来の仲間をお待ちしております！！

山本とゆるく面談したい方はMeetyからもどうぞ💁‍♀️

meety.net

ビジネスと開発の「垣根」を仕組みでなくす方法 ーコラボを生む3つの工夫ー

こんにちは！ファンと共に時代を進める、Web3スタートアップGaudiy共同創業者の後藤（@PTeamd）です。普段は、プロダクト開発全般をみています。

弊社では「コラボレーション」という言葉がよく使われており、カルチャーの核になっています。特に、プロダクト開発を進める上では、職種を横断したコラボレーションがとても重要だと考えています。

そこで今回は、職種を横断した”コラボ”を生み出す上で意識していることや、実際の開発プロセスについて書いてみようと思います。（ちなみに3年ぶりのブログです…）

開発のスピードと品質を両立し、ビジネスサイドと開発サイドの垣根がないチームの作り方として、なにかのご参考になれば嬉しく思います！

なぜGaudiyではコラボレーションを重視しているのか？

そもそも、なぜGaudiyではコラボレーションを重視しているのか、という背景から。

Gaudiyがプロダクトを提供しているエンタメコンテンツ業界は、ステークホルダーが多い業界構造にあります。

たとえば、弊社が関わっているプロジェクトのひとつ、週刊少年ジャンプの人気漫画『約束のネバーランド』のコミュニティサービスでは、マンガ原作の集英社、アニメ制作のアニプレックス社、映画制作の東宝など、IPを取り巻く多数の関係者が存在しています。

また一方で、Gaudiyがつくっているのは、ブロックチェーンやAIなどの先進技術を活用した「これまでにないエンタメ体験」です。新しい技術を使った新しい体験を、ファンの方々に最速で届ける。

これを実現するには、不確実性の高い部分を早い段階で認知し、潰していくことが求められます。

「つまりアジャイル開発でしょ？」と思われるかもしれませんが、Gaudiyの場合は、その「不確実性」の変数が外部にもかなり多く存在するので、実装・リリースだけでなくビジネス的な要件定義やデザインも含めてアジャイルであることが特徴のひとつかなと思います。

この「不確実性」の観点を補足すると、GaudiyはBtoBtoCのビジネスモデルなので、クライアント（IP関係者）、ファン（エンドユーザー）、社内のそれぞれの視点が必要です。

どれかひとつでも欠けていると以下のような事態になり、開発が進んでからの大きな手戻りも生じかねません。

• クライアントの要望は満たせているが、ファンがワクワクする体験になっていない
• 新しい技術を取り入れた先進的な体験だが、クライアントの意向が汲めていない
• クライアントもファンもワクワクするような機能だが、現実的に開発困難である

こうした背景から、GaudiyではBiz（BizDev、コミュニティマネージャー）、デザイナー、エンジニアが常に協働しながらプロジェクトを進める、という特徴があります。

一般的には、PdMが要件定義し、デザイナーがUI/UXを設計して、エンジニアが実装する、といった「リレー形式の開発プロセス」が多いかと思いますが、Gaudiyではすべてのステークホルダーが要件定義からリリースまで関わり合い続ける「コラボレーション重視の開発プロセス」を採用しています。

コラボレーションを生み出す3つのポイント

ただ「みんなコラボレーションをしよう！」と言っても、BizとDevで自然に協働できるかというと、実際には難しい面もあります。

そこでGaudiyでは、コラボレーションを生み出し、促進するための工夫として、「共通のフレームワークを採用する」「モチベーションを設計する」「パターンランゲージで日常化する」の3つを導入しています。

1. 共通言語となるフレームワークを採用する

BizとDevの垣根をなくすためには、専門知識がない人でも議論に参加しやすい土壌づくりが大切だと考えています。前提知識の異なる人同士で議論する際に難しいのが、どうあるべきかの「基準」です。

そこで取り入れているのが、共通の判断基準や進め方の型となる「フレームワーク」です。詳しくは後述しますが、インセプションデッキやユーザーストーリーマッピングなどがこれに当たります。

この判断基準や議論の進め方がクリアになると、専門知識を持っていない人でも意見が出しやすくなり、アドバイスをもらいやすい状態を作ることができます。また、フレームワークを活用したワークショップを主導する人も、様々なステークホルダーの視点を効果的に取り込むことができるようになります。

さらに、技術選定においても、個々の生産性を最大化できるかだけではなく、他のロールの人とのコラボレーションを生み出しやすいか、を選定基準に含めています。

たとえば、フロントエンドエンジニアとデザイナー間の共通言語となる「Tailwind」や、フロントエンドとバックエンド間でスキーマ駆動設計を行う「GraphQL」の採用は、いずれもコラボレーションを生み出しやすい、という観点があります。（この辺りは、また別のブログでご紹介していきたいと思います🙏）

2. モチベーションを設計する

次に、職種横断のコラボレーションを促進する上で、モチベーションの設計も大切です。

特に不確実性の高い案件では、各ステークホルダーが「自分がやるべきタスクはなにか」に集中しすぎてしまい、「必要な要件だけシェアしてくれれば、具体的なアウトプットはこちらで考えておきますよ」となりがちです。

これを防ぐポイントは、各ステークホルダーの動機がオーバーラップする部分をタスクとして切り出すことです。

たとえば以下のような場合であれば、それぞれのロールにとってメリットがあるので、コラボレーションに参加したいという動機が生まれやすくなります。

• BizDev：クライアントに見積もりを提出したい
• デザイナー：実現可能なUXの範囲と現状の課題を把握したい
• エンジニア：ユースケースや今後の汎用性などから、設計の方針を考えたい

また、作業自体には専門知識が要らないけれど、整理に時間がかかるようなタスクがあれば、「作業コストの削減」という観点からもコラボレーションの動機が作りやすくなります。 

3. パターン・ランゲージで日常化する

さいごに、コラボレーションを日常化する工夫として「パターン・ランゲージ」を活用しています。パターン・ランゲージとは、組織の中で暗黙知になっている行動様式（パターン）を言語化したもので、Gaudiyではプロジェクト進行やカルチャー浸透など、様々な場面で活用されています。

たとえば、コラボレーションを促進するパターン・ランゲージとしては「ちょいコラ」「コラボアンテナ」「スキマdeレバレッジ」などがあります。

Slackの絵文字にして日々のコミュニケーションでも活用しています

こうした工夫によって、コラボレーションを生み出しながらも、スピードを下げないプロダクト開発を意識しています。

コラボレーションし続けるプロダクト開発

ここでは、実際にGaudiyで活用しているフレームワークと、開発の進め方についてご紹介します。

上図の全プロセスにおいて、Biz（BizDev、コミュニティマネージャー）、デザイナー、エンジニアが一緒に進めています。それぞれの活用ポイントを簡単にまとめます。

1. インセプションデッキ

インセプションデッキは、新規プロジェクトのキックオフ時に、WHYとWHATの共通認識づくりに活用しています。なぜ、どのようなものを作るのか、の認識合わせとともに、各ステークホルダーの「利害調整」をはじめに行うのがポイントです。

たとえば、BizDevからは「クライアントが実現したいこと」を、コミュニティマネージャーからは「予想されるファンの反応」を、エンジニアからは「技術的なリスク」などが共有されます。

こうして、それぞれの視点を混ぜ込んだ上で、チーム全体で不確実性の高いところから優先的に対処するように合意形成します。

2. ユーザーストーリーマッピング

次に、「ユーザーストーリーマッピング」というフレームワークを使って、ユーザーのストーリーを整理し、それをもとに開発のチケットを管理しています。

実際のストーリーマッピング

ここでは、エンジニア、デザイナー、BizDevから各担当者が参加して、開発チケットの管理、デザインフレームの作成、プロダクトの見通し作成など、オーバーラップするタスクを解消できる仕組みとして活用しています。

また、アーキテクチャーや情報設計などを進めていく際に、必要な要件を更新することもあるため、全員が理解できる言語・表現で作成しておくことがポイントです。

3. ATDD（受け入れテスト駆動開発）

ユーザーストーリーマッピングで作成した開発のチケットには、ストーリーが成立する要件を記載していますが、その要件（＝受け入れ要件）をもとに品質テストを行う「ATDD（Acceptance Test Driven Development）」を取り入れています。

ATDDは、「部品テスト→結合テスト→UXテスト」といったやり方ではなく、顧客が本当に必要とする体験にフォーカスするので、アジャイルに開発を進めていくことができます。

当然ながら、その受け入れ要件の記載が重要になるため、ここでもエンジニア、デザイナー、BizDevそれぞれの視点を取り入れることが重要になってきます。

techblog.gaudiy.com

4. DDD（ドメイン駆動設計）

最後に、バックエンドの設計においては、「DDD（Domain-driven design）」と呼ばれるドメイン駆動設計を採用しています。

招待（リファラル）機能のDDD設計図

実装を進めていく上で、単に「チケットで定義された要件を満たすか」という視点でアーキテクチャを構築してしまうと、今後のビジネス展開で期待される役割を実現できなかったり、ユーザーからすると直感的ではない挙動を生んでしまうことがあります。

そこで、DDDによって、ビジネスサイドの意見や知見を取り入れながら、バックエンドの設計に役立つ知見に変換することで、コラボレーションを促進しやすくしています。

techblog.gaudiy.com

さいごに

今回は職域を越えた「コラボレーション」を生み出すための工夫として、共通のフレームワーク導入やモチベーション設計、文化浸透の取り組みをご紹介させていただきました。

Gaudiyでは他にも、ペアデザイン実装やデザインシステム、ペアプロなど、さまざまな職種間でコラボレーションを生み出す仕組みを導入しています。この辺りは、また別のブログでご紹介していけたらと思います。

とはいえ、まだまだ理想形には程遠く、コラボ文化を強めながらプロダクト開発を推進するエンジニアメンバーを募集中です！

最近ではDDDをより組織に浸透していくため、外部講師としてログラスの松岡さん（@little_hand_s）にお手伝いいただき、社内勉強会の開催や日々のサポートなども受けています。（DDD勉強会には、エンジニアだけでなくBizDevやコーポレートを含むほぼ全員が参加していたのも、弊社らしさが出ているかなと思います。）

少しでも興味のあるエンジニアの方は、ぜひYOUTRUST、Wantedlyでもお気軽にご連絡ください。

リンクも貼っておきます🙏

ではまた！