スケーラブルで生産性高いチームをつくるための取り組み

背景

まず背景として、直近の取り組みに繋がったサービスやチームの現状について簡単に紹介します。

サービスの成長

2022年4月にNEWTをローンチしてから今まで、総予約流通総額及びアプリインストール数は急激なスピードで成長してきています。

ローンチしてからの最初の1年はコロナウイルスの流行も落ち着きを見せる中で、本当にサービスが世の中に受け入れられるのか、PMFするのかに注力して、様々な機能を開発しリリースしてきました。

そして約1年弱で、一定PMFは達成できたといえるところまで、サービスを成長させることができました。

現在は0→1の探索フェーズを終え、1→100のサービスをグロースさせるフェーズに変わってきました。サービスの成長自体は非常に喜ばしいことである一方で、サービスのスケールにしっかりと追従できるように、スケーラブルなチームを作っていくことが早急に求められる状況になってきました。

チームの状況

現在(2023年12月時点)、弊社には51名のフルタイムメンバーが所属しており、その約半分弱23名がプロダクト開発チームになります。

その中で、3つのチームに分かれており、NEWT App開発チームにフォーカスすると、メイン業務としてアプリ開発をしているアプリエンジニアは iOS / Android でそれぞれ1名ずつ、業務委託・副業のメンバー (弊社ではプロパートナーと呼んでいます) が3名という規模で開発を行っています。

そんなチーム規模の現状がある中で、サービスの成長に伴い、以下を同時並行で進めていく必要性が高まってきました。

ストレッチな事業KPIを達成するために、今まで以上にスピーディーかつ高品質な機能開発

今後の事業戦略を見据えた、スケーラブルなプロダクトにしていくための戦略の立案と推進

中長期的のサービス運用を意識したメンテナビリティの向上、および適切なタイミングでの技術課題の解消

上記をこなすためには、より生産性を高める仕組みづくりとチーム規模を大きくしていくことに向き合っていかないと、健全に対応することが難しくなってきました。

取り組み

前述の背景を受けて、自身がマネージャーを担当しているNEWT App開発チーム (以下、Appチーム) において、スケーラブルでより生産性の高いチームを目指して、取り組んできたことを「モニタリング」「ドキュメンテーション」「品質・メンテナビリティ」の3つの観点でいくつかご紹介します。

モニタリング

より生産性を高めるために開発フローにおけるボトルネックやチームの現在地を可視化するモニタリングを進めました。

ストーリーポイント

Appチームでは基本的に1スプリント1週間のスクラム開発で毎週リリースを行っています。

今までは各スプリントにおいて、案件数でのモニタリングをしており、案件のサイズの考慮ができていなかったことから、より正確な見積もりを実現するためにストーリーポイントを導入しました。

各スプリントのベロシティを計測することで、安定した見積もりへの寄与と同時に、絶対数を増やす(=生産性を高める)ためのアクションがどう作用したかを可視化するのが主な目的です。

ストーリーポイントの付与方法については、エンジニアで毎週プランニング前にプランニングポーカーを実施し、次スプリントに対応予定のチケット全てにストーリーポイントを付与した状態でプランニングに臨みます。

このときポイント数が大きくなりすぎるチケットはスコープを切ったり、より小さなチケットに切り分けることでなるべく小さく早く最小限で価値を届けることを意識しています。

アジャイルにおけるストーリー・ポイントとはどのようなもので、どのように見積もりますか？ | Atlassian

アジャイルな見積もりとストーリーポイントの秘訣を探ります。アジャイルな見積もりが上手くできれば、プロダクトオーナーは効率と効果を最適化できます。

https://www.atlassian.com/ja/agile/project-management/estimation

バグ発生要因

Appチームでは、QAでの検知したバグやリリース後に発覚したインシデントに対して、全てチケットを切る運用をしています。

そしてそのチケットに対して、以下で定義したバグの発生要因ラベルを、修正完了時に付与する運用を追加で始めました。

これによって、一連の開発フローにおいて、どこが原因でバグが生まれやすくなっているのかを可視化できるようになりました。

開発フローにおけるボトルネックを適切に改善することで、QA時の手戻りや工数の増大を避け、デリバリー速度を高めることを目的としています。

ラベル	概要
要件解釈ミス	・定義されている機能や要件と異なるものを実装した
要件実装漏れ	・定義していた機能や要件が開発されていない（新規案件&既存箇所の変更) ・単純なコード不備や不具合
仕様考慮漏れ	・実装前の要件定義の段階で考慮すべき観点から抜けていた・考慮漏れのため、未実装であった / 仕様を変更・追加した
デグレ	・該当範囲の機能実装では、影響がないと思われた機能でエラー・誤動作が発生した場合
環境・端末不備	・ある特定の条件や環境下でのみ問題が起きる場合・OSやデバイスなど特定の環境下でのみ発生

後述するDev Docについては、〇〇漏れによる手戻りが多くなっていたことに対するアプローチだったりします。

事業KPIと開発案件

各チケットに対してエピックとして紐づく事業KPIを付与する運用を始めました。

こちらは事業として達成したいKPIに対して各案件がどう寄与しているか、KPI達成のために適切な配分で技術資本を投資できているかを把握し改善することを目的としています。

PM視点ではKPIの管理や成果の分析を行いやすくなり、エンジニア視点では開発した機能が事業にとってどういう価値をもたらしているのか見えやすくなりました。

これによってチームでより事業KPIを意識できるようになり、達成に向けた動きが取りやすくなることに期待しています。

あわせてプロダクトチームとしてKPIの数値モニタリングも進めています。

ドキュメンテーション

チームがスムーズにスケールできるようにするため、適切なコスト感を意識しながら、ドキュメンテーションも進めました。

Dev Doc

AppチームではGoogleのDesign Docsに着想を得て、Dev Docというドキュメントを作成することを始めました。

Googleが提唱するDesign Docは、エンジニアが実際にコーディングする前に書くドキュメントで特に決まったフィーマットがあるものではありません。

そこで我々のチームでは、あくまでエンジニアがコーディングに着手する前に仕様書の内容をよりエンジニア目線でまとめておくドキュメントとして考えたとき、必要な項目は何かを洗い出してフォーマットを作成しました。

その結果、Design Docと呼ぶには少し毛色が違うもの、つまるところ詳細仕様書のようなものを現状求めていることが分かったので、あえてDesign Docとは呼ばずにDev Docと呼ぶことにして運用を始めました。

現状、以下の目的・方針で運用をしています。

<目的>

実装漏れ・考慮漏れの軽減

iOS / Android での不要な実装差異を防ぐ

開発前に仕様を詰めることで、手戻り、追加要件を防ぐ

複数メンバーによる知見共有・仕様のドキュメント化推進

<方針>

iOS / Android アプリエンジニアが書く＆読むもの

ストーリーポイントが5ポイント以上の案件(チケット)において作成する

実装を始める前に作成し、実装中も追加で決まったことがあれば加筆・修正していく

なるべくコストをかけすぎずに複数の目的を達成できるように日々フォーマットやルールを見直しながら運用を進めています。

▼ GoogleのDesign Docsについて

Design Docs at Google

One of the key elements of Google's software engineering culture is the use of design docs for defining software designs. These are...

https://www.industrialempathy.com/posts/design-docs-at-google/

コーディング規約

NEWTアプリの開発初期からこれまでにかけては、そこまで多くのメンバーがコードに関与することがなかったので、コーディング規約を整えることはどちらかというとコスト過多な印象でした。

また、明示的なコーディング規約を用意しなくとも、公式ドキュメントが充実しており、準拠することで、一定統一感あるコーディングができていました。(ここはフレームワークの選定時に考慮したポイントの1つでもありました。)

しかし、フェーズも変わってきており、新しいメンバーのジョインやメンバーの異動などが増えてきており、プロダクトチーム全体でコーディング規約を整えることの重要度が高まってきました。

現状はまだまだ整えている最中ではありますが、それぞれのチームで共通のフォーマットを元に少しずつ対応を進めています。

▼ iOSで採用しているThe Composable Architecture

Documentation

https://pointfreeco.github.io/swift-composable-architecture/main/documentation/composablearchitecture/

▼ Androidで準拠しているGoogleのアプリアーキテクチャガイド

アプリアーキテクチャガイド | Android デベロッパー | Android Developers

このガイドでは、品質の高い堅牢なアプリを作成するためのおすすめの方法と推奨アーキテクチャを紹介します。

https://developer.android.com/topic/architecture?hl=ja

品質・メンテナビリティ

スピードを維持しながらも、中長期を見据えて品質高いプロダクトを維持するために品質やメンテナンス性を高める施策も進めました。

技術課題への対応・予実管理

2022年4月にアプリをローンチしてからこれまで、デリバリースピードにこだわり、たくさんの機能開発を進めてきました。

そしてこれからも変わらず、むしろ更にスピード感を持って機能開発を進めていくつもりです。

しかし、プロダクトを運用している以上、技術的な課題の解消も同時に行っていく必要があります。

一言に技術課題と言っても、毎年のOSアップデートや利用しているライブラリ・フレームワークのアップデートなどの外的な要因に対するものであったり、事業の方向性やサービスの規模による内的な要因によるものであったり様々です。

そしてこれらの課題は、計画的に適切なタイミングで工数を取り、対応を進めておく必要があります。

また、自動化やリファクタリングなどスピード感をある開発を継続・効率化するために、マストではないがやっておくと複利的に効いてくるものもあったりします。

こちらはなかなか目先の機能開発を優先すると優先度がいつまでも上がらずやれないままになりがちだったりします。

そこでそれらの技術課題に対して、チームとして工数の10%をかけること、技術課題に対して定期的に洗い出しを行い優先順位をつけ、マイルストーンを定めて推進していくことを行っています。

まだ比較的若いプロダクトなので、直近大きな課題・問題を抱えているわけではないですが、むしろ今後スケールする方向性が多岐に渡る今だからこそ、しっかり課題と向き合い、健全な状態を保つことで事業の方針に柔軟に対応できるプロダクトにしておくべきだと考えています。

Dog Fooding

現在、アプリは週1のリリースサイクルで開発をしています。

そして、このリリースサイクルを維持できるスピード感を保ちつつ、プロダクトの品質を担保するためにDog Foodingを採用しています。

Dog Foodingとは”Eating your own dog food”とも呼ばれ、自社で開発した製品を従業員自ら利用することで製品テストを行うことを指します。

AppチームではQA着手前にリリースパッケージを社内で配布し、プロダクトチームのメンバー中心にデバッグする時間を取っています。

これによってQAフローに入る前に実際の使い心地に対するフィードバックであったり、早期のバグ検知ができるようになりました。

また、通常のリリース前のプロセス以外に大きな機能に対しても早い段階でDog Foodingを行い、使い勝手や動くものを実際に触って気づく改善点を洗い出すことも行っています。

実際にDog Foodingを始め運用を続けた結果、目的や方針もブラッシュアップされ、QA期間の安定化や大きな機能での手戻りが減ることに寄与できています。

▼ Dog Foodingとは

Eating your own dog food

Eating your own dog food or "dogfooding" is the practice of using one's own products or services.[1] This can be a way for an organization to test its products in real-world usage using product management techniques. Hence dogfooding can act as quality control, and eventually a kind of testimonial advertising. Once in the market, dogfooding can demonstrate developers' confidence in their own products.[2][3]

https://en.wikipedia.org/wiki/Eating_your_own_dog_food

まとめ

スケーラブルで生産性高いチームを目指して直近取り組んできたことについて、いくつかの項目に分けて紹介させていただきました。

今回紹介させていただいた取り組みは、まだまだ試行錯誤しながら進めているものや実際に効果が出ているもの、まだこれからのものなど様々ですが、可逆的なものはどんどんトライしていくことが必要だと思っています。

そして、プロダクトや事業、チームの規模・フェーズなど様々な要因によって今やるべきことは日々変化していくので、常に課題や改善点を見つけて施策を打っていくことはこれからもスタンスとして大事にしたいと思っています。

また、ここまでの取り組みは決して1人で進められたものではなく、チームのメンバーと連携することで形になり、磨かれ定着していったものになるので、必要性や目的を説きながら、チームを巻き込んで推進していくことがこれからもチームを大きくしていく上で必要不可欠だと感じています。

まだまだフロー効率を意識したチームづくりであったり、事業KPIを達成するための開発チームとしての追いかける指標のFixなどやるべきことがたくさんあるので、引き続きより良いチームを目指して推進していきたいと思っています。

▼ フロー効率を解説したリーンマネジメントについての書籍

This is Lean 「リソース」にとらわれずチームを変える新時代のリーン・マネジメント

Amazonで二クラス・モーディグ, パール・オールストローム, 前田俊幸, 小俣剛貴, 前田俊幸, 小俣剛貴, 長谷川圭のThis is Lean 「リソース」にとらわれずチームを変える新時代のリーン・マネジメント。アマゾンならポイント還元本が多数。二クラス・モーディグ, パール・オールストローム, 前田俊幸, 小俣剛貴, 前田俊幸, 小俣剛貴, 長谷川圭作品ほか、お急ぎ便対象商品は当日お届けも可能。またThis is Lean 「リソース」にとらわれずチームを変える新時代のリーン・マネジメントもアマゾン配送商品なら通常配送無料。

https://amzn.asia/d/3boKOJF

This is Lean 「リソース」にとらわれずチームを変える新時代のリーン・マネジメント

令和トラベルでは一緒に働く仲間を募集しています

ぜひこの記事を読んで会社やプロダクトについて興味を持ってくれた方はご連絡お待ちしています！お気軽にお問い合わせください！

フランクに話だけでも聞きたいという方は、カジュアル面談も実施できますので、お気軽にお声がけください。

▼ 採用サイトはこちら！！

Recruit | 株式会社令和トラベル

私たちは「あたらしい旅行を、デザインする。」というミッションのもと、挑戦を始めました。令和時代を代表するデジタルトラベルエージェンシーとなり、あたらしい旅行体験を提供します。そして、5年以内の上場を目指し、全速力で社会価値を創出していきます。創業メンバーの一員として、大きな変革にチャレンジする仲間を募集しています！

https://www.reiwatravel.co.jp/recruit

さらに定期的に令和トラベルの技術や組織に関する情報発信を開催予定です。connpass にてメンバー登録して最新情報をお見逃しなく！

それでは次回のブログもお楽しみに！Have a nice trip ✈️