こんにちは。Gaudiyでソフトウェアエンジニア兼スクラムマスターをしている Namiki ( @ruwatana ) です。
「チームが向き合う不確実性が大きいと手戻りが増えて価値提供のリードタイムが遅くなる」
「チーム内の心理的安全性の低さや認知負荷の高さによってエンゲージメントが低下して従業員がオンボード・定着しにくい」
...
などなど、昨今のチーム開発はこうした課題で溢れかえっていることかと思います。
結局のところ、我々は具体的にどんなプラクティスを行うことで、こうした課題を解決できていくのでしょうか？
本稿では、筆者と筆者が4ヶ月ほど前に配属することになったチームがこうした問題に対して執ったアプローチおよびその効果をより具体的に示すことができればと考えています。
プロダクトチーム開発を行う皆様に何かしらの参考になれば幸いです。
- 1. チーム構成と特性
- 2. 特性が生み出しうるリスクや課題
- 3. それぞれの課題に対するアプローチ
- 4. まとめ
1. チーム構成と特性
Gaudiyでは、複数のIP（知的財産）に関するコミュニティプラットフォーム「Fanlink」を提供しています。
現在、Gaudiyにはプロダクト開発チームは複数存在しますが、筆者が所属するチームは「特定のIP向けの連携機能やエンハンス開発に注力したチーム」となっています。
そのため、下記のような特性があります。
- IPプロバイダーとの協業をより求められ、チーム開発の中でIPの影響力が大きい
- 連携機能はリッチで新規の機能開発が求められやすい
- マイルストーンやスコープが変化しやすい
また、メンバー構成は以下の通りです。
- 👥 プロダクトマネージャー 1名 (+ UXデザイナー1名も兼任)
- 👥 UI/UXデザイナー 3名
- お試し入社者を含む ※
- 👥 フルサイクルエンジニア 4名 ← 筆者はここに所属しています
- お試し入社者を含む
- （その他、BizDev・コミュニティマネージャーとも連携）
※ お試し入社の制度に関しては採用情報をご覧ください
site.gaudiy.com
ピザ2枚ルール🍕にギリギリ収まるような人数構成です（これ以上増えても減ってもバランスが崩れそうなちょうど良い状態です）。
チームの中にデザイナーも所属しており、デザイン（ディスカバリー）と開発（デリバリー）のどちらの進捗も統合的に管理するデュアルトラックアジャイルのような開発手法をとっています。
弊チームだけでなくGaudiyのプロダクト開発チームは基本的にこの構成をとっているのが特徴です。
2. 特性が生み出しうるリスクや課題
さて、こうした特性が以下のような問題を生み出すと考えられます。
2-1. プレッシャーが高くストレスフルな環境に陥りやすい
IPに密着したチーム特性ということで、特定IP向けのプロダクトが生み出すアウトカムが会社というよりも特にチーム（メンバー）に直結する構造となりえます。
完全内製なプロダクトなどと比較すると、先方と握った納期・スケジュールに間に合わせなければならず、何か問題が発生した場合に社内だけでなくIPにも影響が出てしまいかねないですし、先方の要望に叶った要件を着実にデリバリーしなければならないといった外部からのプレッシャーを比較的受けやすく、一概にはいえませんがストレスフルな環境に陥りやすい構造と考えられます。
2-2. 技術的な複雑性や負債が高くなりやすい
Fanlinkは、マルチテナント（IP）向けのプロダクトですが、IPからはIP特有の要望を受けることも少なくありません（要望をいただくことは率直にありがたいことです）。
その中で、機能追加したものが特定IP専用の機能にならないように極力、汎用的に要件を落とし込むという正解があるようでない難易度の高い判断が求められることもあります。
専用の機能が増えてしまうと、固有のロジックや他チームからしたら知りもしない機能が増え、複雑性や技術的負債が増加してしまいます。もしかすると、他チームが勝手に消しにかかってしまうかもしれません。
2-3. さまざまな不確実性が高い
また、さまざまな不確実性が高いということもいえます。
Gaudiyの推奨図書にもなっている広木大地さんの「エンジニアリング組織論への招待 不確実性に向き合う思考と組織のリファクタリング」によれば、不確実性は大きく下記の3つがあるとされています。例とともに分類します。
- 目的不確実性
- プロダクトにおけるマーケットに何が求められているのかの正解が見えない
- 他の競合サービスなどの取り巻く環境の変化に適応しなければいけない
- 方法不確実性
- スケジュールに対して要件が決まりきらずに開発を始めなければならない
- ある大きな機能を開発中に方針・優先度が変わってペンディング・ピボットする
- チームにプラクティスが存在しない新しい技術を用いた実現方法を求められる
- 通信不確実性
- PdMやデザイナーが考えた要件がデリバリーする際に適切に伝わらず手戻りを起こす
- お試し入社者が目の前のタスクをこなす上での情報やコンテキストの不足
- リモート主体の開発で、メンバーに聞きにくい・意見しにくい
3. それぞれの課題に対するアプローチ
ここまでは、特に目新しい情報はあまりなかったと思いますが、もしかすると「うんうん」と頷いていただけた方もいらっしゃるのかなと思います。
ここからは、より具体的なアプローチをご紹介できればと思います。
3-1. チームの成長実感や自己肯定感の醸成
もしかしたら、目的不確実性によって価値提供をしてもマーケットのアウトカムを得られないということもあるかもしれません。
そんなときもプロセスに注目し、人やチームの良かった動きやことに対してねぎらいを与えるきっかけを作ることはとても重要であると考えます。
弊チームでは、1週間1スプリントとしてスクラム開発を行っており、レトロスペクティブ（振り返り）やスプリントレビューを定期的に実施して改善を続けてきましたが、その中のHowに工夫を加えていく動きが加速しているので一部をご紹介します。
3-1-1. レトロスペクティブにSpeed boatを導入
まず、レトロスペクティブでは従来 Win-Learn-Try のようなフォーマットを用いていましたが、割と個人の内省に使われることが多く、チームや他人に対してのフィードバックが欠如してきていました。これではみんなでやる理由があまりありません。また、ずっと同じ手法を使っていると飽きも来てしまうというのもあったかもしれません。
こうした問題に気づき、チームのメンバーが立候補して、レトロスペクティブの改善のオーナーを担ってくださいました。これによって、新フォーマットの Speed boat （国内ではSail boatという方がなじみが多いかもしれません）を行うことになりました。
※ちなみに現在は、また別のフォーマットを試すなど改善がどんどん進んでいます。
Speed boatでは、そのスプリントでのチームの動きを事象別に振り返ります。
テンションが上がったアイスブレイク的な内容（太陽）、チームが進むのに助けになった要因（追い風）、逆に止めた要因（錨）、わかった潜在的なリスク（岩）を書いて内容をシェアし、最後に次に取るべきアクションをボート上に乗せて投票でネクストアクションを決めるというシンプルな内容です。
これによって、他者の動きを褒めたり助かったなどの声が圧倒的に増えました。また、個人よりもチームに向いた振り返りができるようになり、みんなが納得感のある振り返りの場になったと思います。
自分の成果を自分であげるよりも、他者からフィードバックをもらえる方が自己肯定感を醸成できると思いますし、何より褒められたら嬉しいですよね？
Gaudiyは評価という仕組みがない会社なため、正も負もフィードバックを他者からもらえるシチュエーションが欠如しているという特性もあり、そういった部分にもアプローチできているのかなと考えています。
3-1-2. スプリントレビューにてPdMからの今週のスポットライト選出
スプリントレビューはプロダクトマネージャーが主導していますが、ビジネス周りのメンバーも含めてディスカバリー・デリバリーのスプリント内での成果を共有する場というのが基本的な立ち位置です。
そこに、毎週チームの中で良い動きをしたメンバーにスポットライトを当て、選出の理由とともに発表いただくアジェンダを追加するという動きがありました。
こちらもレトロスペクティブの改善と同様、チームメンバーのエンゲージメントを向上する要因となっていると思います。PdMからの視点をもらえるという意味でも、たとえ選出されなかったとしても選出理由を聞けるだけで学びが大きいなと感じます。
※ UNIFORMな人とは弊社のクレド（行動指針）の模範となっている人のことです
note.gaudiy.com
我々は、いつもPdMの方々にスポットライトをあてていただく側なので、この場を借りて弊チームのPdMの皆様にも素晴らしいアクションをとってくださったことを改めて讃えたいと思います。ありがとうございます！
3-2. チームとしての共有知やコンテキストレベルの底上げ
特定のメンバーだけが知っていること、複数人で会話する時に相互のコンテキストの違いによって前提が合わなくてコストがかかるといったことが起きないように、短いスパンでコンテキストの共有を行っていくことが必要と考えています。特にエンジニアは4名在籍しており、ここのコンテキストレベルのズレが大きく進捗にも影響しかねないです。
下記にそれらを実現するアプローチを示します。
3-2-1. SlackのハドルミーティングやGatherに常駐する
弊チームでは地方に住むメンバーもいたりするなどリモートが主体の開発を行っています。そこで、朝から晩まで、基本的にはSlackのハドルミーティングに常駐していつでも口頭での相談や同期ができることを実現しています。
話す時以外は大体ミュート状態にしている運用で、話しかける時に「〇〇さん今いけます？」的な形で質問や相談、ペア作業などがすぐにできるような形にしています。
これには、心理的安全性を高める効果があると考えています。
最近では、試験的に Gather というサービスを用いてバーチャルオフィスを構築し、チームのミーティングなどを全てこのサービス上で行ってみるような取り組みを全社的に行なっています。
隣り合うだけでプライベートの会話空間が作り出せるのでペアプロがしやすかったり、他の人が話している場合は吹き出しマークが出て視覚的にも様子がわかるなど、会話のし始めや既に会話しているところへのジョインのハードルを下げるような狙いもありそうです。
Slackハドルミーティングとの大きな違いとして、後から会話にこっそり入室しても何もフィードバックがない（気付きにくい）ので、リアルタイム空間のような他チームのミーティングの盗み聞きみたいなこともカジュアルにできるのが斬新だなと思います（笑）
（モザイクやアバターも相まって怪しさMAXですが健全な議論をしています）
3-2-2. QAをチーム全員参加で行う
Gaudiyでは、トランクベースの開発プロセスを取っており、ほぼ毎日リリースを行なっています。そのため、前日の夕方に各チームにてデイリーQAを行って、その日にマージされた改修の品質をE2Eでチェックしています。時間としてはその日のマージした分量にもよりますが、早い場合は5分で終わる場合もあれば、30分以上かかる場合もあります。
弊チームでは基本的には、Pull Requestにスクラムのアイテム（JIRAチケットで管理）を紐づけるような運用となっていて、マージすると自動的にQAレーンに移動するようにしており、チケットに書かれた受け入れ条件に沿ってQAを行うという流れで開発を行っています。
一見、エンジニアや受け入れ条件を確認するPO/PdM向けの作業に見られがちですが、ここにはデザイナーのメンバーにも参加してもらっています。
これによって、ディスカバリーとデリバリーの認知の分断を防ぐ役割や、エンジニアが気付きにくいデザイン目線でのデザイン仕様との乖離を検出しフィードバックしてもらえるなどの効果が得られています。
また、エンジニアメンバーが有志で行なったチームのコンテキストとは関係のないバグ修正や改善などに関しても、レビューからQAをチームとして担当・チケット管理するようにしており、属人化や個人への責任を緩和できるような効果も期待しています。
ちなみにコードレビューにおいても、弊チームではすべての領域の改修に関してチームのエンジニア全員のApproveを原則もらう形としており、チームメンバーが行なった改修内容のコンテキストを必ず得られるように工夫しています。（日課として、溜まったレビューを捌いたり、連携するところから業務が開始します）
3-2-3. チームで判断しきれない問題はチーム外を積極的に頼る
チームのエンジニアメンバーにおいて、どういうアーキテクチャで価値提供するかを調査・検証しレビューするというプロセスがありますが、迷った挙げ句結論がなかなか出なかったり、そもそも判断するための確度が高くないといったことが往々にして起こります。
その場合は、積極的にチーム外を頼るようにしています。
チーム外とは、社内のEnabling Teamなどの他エンジニアはもちろん、外部のコンサルタントなども含んでいます。
例えば、チーム内で認可サーバを実装する必要が出た時は、社内に詳しい知見を持つ人がいなかったため、利用するSaaSの窓口から外部の有識者を紹介していただいて仕様のレビューを受けるなどを行なってきました。
もちろん、チーム内で考えうる方針案を複数用意しつつ比較し、最適と思う案をピックアップするところまでは行い、相手のレビュー負荷を下げてから依頼することを怠ってはいけません。
このような外からの知見を獲得するプロセスを経ることによって、チームの中にも知見やコンテキストが増えていくことを期待しています。
3-3. コンテキストフォーカスによる高速デリバリーの実現
コンテキストのレベルを底上げしたり、共有したりすることも重要ですが、フォーカスすることもとても重要です。
3-3-1. フロー効率とリソース効率を意識して使い分ける
例えば、「エンジニアが4人いるなら、半分ずつに割ってそれぞれで大きなコンテキストを抱えて並行稼働すれば、二つもアウトカムを同時に得られるのでは？」というのは誰しもが考えうるかなと思います。
果たして、本当にそうでしょうか・・・？
その2ラインのレビューやQAは誰がやるのでしょうか？お互いに1人しかレビュアーがいないと質の部分に問題が生じるリスクがあり、結局相互に行わないといけないとなると設計や要件、直面した問題の背景なども十分に理解する必要が出てきてしまいます。
それを知るための時間や不確実性（ここでは先ほど挙げた通信不確実性）が暗黙的には増えてしまうわけです。
また、2つの価値提供がともに2人月ずつかかる見積もりだった場合、どちらの機能も提供まで4人2ラインでの開発では単純計算で1ヶ月かかってしまいます。
こうした半分に分けて生産性をあげようという考え方はリソース効率と呼ばれます。
もちろん適切に使えば、この考え方も大きな成果を挙げられる手法であるといえます。例えば、だれもがやり方を熟知していて誰がやっても一定のスピードでできることであれば、ペア作業で行うよりも、それぞれが分散して並行に着手する方が効率が良いに決まっています。
しかし、実装方法も定まっていない・仕様も詳しく知らないような不確実なものでは、コンテキストレベルを合わせたり、異なる視点を入れながら検討して前に進む方が手戻りも少ない可能性があります。コンテキストスイッチも不要なので、頭がパンクせずにしっかりコトに向き合えるというメリットもあるでしょう。
こうした、一つの物事を優先的に着手から完成まで行う考え方をフロー効率といいます。
例えば先ほどの価値提供の例も、全員で取り掛かったら一つの機能は半月でリリースできるかもしれません。もう半月経つと次の機能を出せて1ヶ月後から見ると価値提供完了のスピード自体は変わらないですが、一つの機能を早く価値提供でき仮説検証できるというアドバンテージが生まれます。
デュアルトラックアジャイルを敷いている我々にはこの早く検証を回せる状態はとても相性が良いと考えています。
リソース効率とフロー効率の両者をケースバイケースで使い分けていくことが、より早いリードタイム（価値提供）を生み出せるといえるのではないでしょうか。
3-3-2. ペア/モブプログラミングをカルチャーとして根付かせる
不確実なものにはフロー効率という考え方が良さそうということが先ほどの結論ではありますが、弊チームでは積極的に2人でのペアプログラミングやさらに多い人数でのモブプログラミング（モブ作業）を行なって手戻りリスクを抑えたり、同時に把握が必要なコンテキストの量を減らしレベルを揃えやすいような取り組みをしています。
プログラミングに精通しない人からすると、ペアプロする（2人で1つのことをやる）わけだから単純に速度も1/2になるのでは？と考えるかもしれませんが、下記の理由で十分に有効であると考えています。
- ソロだとコーディング時にわからないことが出て、調査に時間がかかるかもしれない
- 各々が分散し目前のコンテキストに集中した結果、他のメンバーのコンテキストに対してのフォローが行き届かなかったり、あまり理解しないままコードレビューまで問題に気づかず、後から手戻りするコストが発生するかもしれない
- 従来のペアプロのドライバ・ナビゲータという役割を超えた並行的なペアプロが実現可能になったため、何もしていない時間は実は少ない
- お試し入社者を置いてけぼりにせず、ハマりやすい罠を共有することで、早期に立ち上がってもらえる
XP（エクストリームプログラミング）などで提唱されている従来のペアプロ手法では、ドライバとナビゲータに分かれて指示を出す人とコーディングする人がそれぞれ存在しました。
同じPC上で一つのエディタを使ってお互いに操作しなければならなかったので必ず待つ人が発生してしまうという物理的な問題もあったと思われます。
しかし現在は、Visual Studio CodeのLive ShareやJetBrains製IDEのCode With Meといった主要なエディタにて、複数のPCから同時並行作業ができるソリューションが登場したことにより、双方が手を止めずに同一のブランチを並行で修正できるようになりました。もちろん、リモートにも対応していて、ホストのローカルホストポートの共有やコマンドラインの実行なども可能になっています。
これを生かし、弊チームでもペアプロ中にある程度のやるべきことだけ最初に認識を合わせたら、あとは別れてコーディングをすることも多いです。例えば、テストケースの名前だけ先に書いてその実装を分担したりするといったイメージです。一人がミーティングになっても、コネクションを繋げておけば残りの一人が作業を続行することも可能です。
Gaudiyでは、どんどん新しい仲間が増えており、ほとんどのチームがお試し入社のメンバーを迎えながら開発をしています。お試し入社者の中には、特定の技術スタックは強いけど特定のスタックは経験がない・少ないというメンバーもいらっしゃいます（何を隠そう、自分が完全にそれでした）。
そうしたメンバーと作業をする場合は特にペアプロは大きな威力を発揮すると考えています。技術スタックや既存フィーチャーの仕様・コンテキストが不足していると、その時点で心理的安全性がかなり低くなってしまいます（自分も入社時はソロタスクが多く、わからないことを聞くためにも中々人が捕まりにくいなどの問題があり不安なこともありました）。自走ができる状態に持っていくための最短手段としても素晴らしいソリューションだと思います。
一方で、常にサポートが入っている状態だとアウトプットのスピードと質は保証できるかもしれませんが、個人としてのインプットや納得感・達成感は得られにくいといった問題は大いに考えられます。
時には、「一人でトライしてみたい」や、「最近あまり技術的なチャレンジできていない」といった意思やモヤをできるだけ表明しやすくし、他のメンバーはそれを尊重できるような関係性の構築も重要だといえるでしょう。
3-4. USMからバックログアイテムを転用
主にデザイナーが行うディスカバリーの手法としてはリーンXPやMVP仮説検証などを用いており、新たな価値を提供するときはユーザーストーリーマッピングという主にエンドユーザーの行動をベースとした体験を時系列などにまとめたものを制作しています。
現在はオンラインホワイトボードツールのMiroでUSM（ユーザーストーリーマップ）を作っていますが、JIRA連携の機能を利用してディスカバリーフェーズで作成されたユーザーストーリーをそのままデリバリーのバックログアイテムとして転用しています。
これによって、わざわざスクラムにおけるプロダクトオーナー（PO）がバックログアイテムを作るという作業をスキップできるようになりました。
さらに、USMがユーザの行動ベースかつ比較的粒度自体も小さく設計されているため、チケットの要件記述も非常にシンプル（時にはタイトルで自明なので詳細不要）になり、要件の手戻りもしにくくなりました。
USMの例としては「ログインしていると〇〇が表示される」、「〇〇を押したら〇〇に遷移する」といった非常に小さな粒度となっています。
チーム構成のところでも紹介しましたが、メンバー数も比較的多く、デザインと開発をチーム内で抱えており、IPと密着したチーム特性もあることで、特にPdMの負荷が高くなっており、ビジネスなどのより本質的な仕事にフォーカスできるようにすべく、この手法を取り入れたという背景がありました。
チームの声としては、「チケットがわかりやすくなった」などのポジティブな反応もあったため、やって良かったと思います。
この取り組みに関しては、絶賛PDCA中になりますので、それなりに形になったタイミングでまたその内容を詳しく共有できればと考えています。
4. まとめ
いかがでしたでしょうか。最後に抽象的にはなってしまいますが、まとめです。
- チームの取り巻く状況や環境、特性を理解する
- 生まれうる/生まれた課題をしっかりと捉える
- 課題に対して適切なアプローチと改善のサイクルを早期に回す
この特性や課題の設定は、設定をする人のスキルセット（いわゆるメタ認知と構造化する力）に依存してしまうとは思います。そのため、その設定自体がブレていると、ただ自分がやりたいことを改善しているだけになってしまう可能性があり、本質を解決できていないことがあります。
ブレていないかは、チーム内外のメンバーに雑談ベースでも良いので壁打ちしてもらい、ブラッシュアップするのが良いかなと感じています。
筆者も、チームへのジョイン時に既存メンバーと1on1を設定させていただき、チームが置かれている状況や課題などの解像度をより鮮明にするところからアプローチしました。
この課題設定の確度を上げることが、結果的に短期での解決や改善を生む要因になったのではないかと考察しているので、非常に重要なステップだと考えています。
また、こうした取り組みがどんどん回せているのは、筆者が主導・管理したからというわけでもなく、チーム全体で一人ひとりが問題に向き合い、自律的に改善することができている結果だと考えています。
一人が主導するよりも、このように自己組織化するチームになる方が、並行してたくさんの改善が回せると思うので、チームのカルチャー創りというのも非常に重要かなと思います。
--
以上になります、お読みいただきありがとうございます！
ぜひこの記事に対しても感じたことなどありましたら、率直なフィードバックをいただけますと幸いです 🙏
11/16（木）の自社イベントでも開発組織についてお話しするので、ご興味ある方はぜひ！
