こんにちは、@satoshin21です。 これはmikan Advent Calendar 2023の13日目です。

mikanでは現在、「スクラム開発」ライクな開発フローを取り入れ日々アプリの改善に取り組んでいます。去年のAdvent CalendarでもiOSチームの開発体制についてちょっと触れました。

今年は個人的に特に開発プロセスについてチームの協力を得ながら改善してきた年になりました。特に大きかったのが開発チームの編成を目的別チームや職能別チームなどいろいろ試してみたことです。今回はそのチーム編成を変えつつ、どのように開発プロセスを変えていったのか、チームの1メンバーという視点から振り返っていきます。

プロジェクト別チームの課題感

2023年はじめ、とある大きなプロジェクト完遂のために各プロジェクトごとにPjM、Designer、Engineerをそれぞれのプロジェクトに専任でアサインし、プロジェクトごとにチームを編成しました。よりリソース効率を最大化、プロジェクト内のコミュニケーションを圧縮しスピード感を持ってプロジェクトを進めることが目的です。 当初のチーム編成を振り返ってのProsは以下の2つかなと思います。

1. プロジェクトチーム内でコミュニケーションが閉じることで意思決定や仕様調整などをスピード感を持って進められた

2. 各チームメンバーごとの担当範囲が明確になり、進捗管理などのプロジェクト・マネジメントが効率化された

四半期以上かかってしまったプロジェクト自体は完遂できたものの、iOSチームとしてこの新しいチーム編成について振り返ってみた所、以下の点で改善点が見つかりました。

1. 施策の仕様が各プロジェクトチームに閉じてしまい、コードレビューの時に仕様を踏まえたレビューが難しい

2. 長期的継続的な開発を進めていくための「守りの開発」にiOSチームとして取り組みにくい構造になってしまっていた

3. 細かい改善系施策や問い合わせ対応など、どちらのチームが担当すべきかあやふやなボールが宙に浮きやすい（問い合わせ対応など）

3などは特にチームとしてのガイドラインを策定すれば解決できることはあると思います。が、特にmikanではほぼフルリモートで日々開発を行っていることもあり、気づくと上記課題について気づく機会が失われてしまい改善点が見えにくくなってしまっていたようにも思えます。
一旦プロジェクトが終わった後、上記Pros/Consを踏まえ職能別のチーム編成へと戻す意思決定をしました。このチーム編成に変えてからおおよそ半年近く立つのですがiOSチームとしては以下のようなメリットを感じています。

チームとしての行動

職能別に戻した時にまずiOSチームとして決めたのは、キックオフや仕様整理会などのPMやDesignerとのコミュニケーションは、基本的にチーム全員で参加しようという点です。見積も各メンバーで閉じていたものを、iOSチーム全員で見積やタスク分解をするように開発フローを変更しました。
最初は無駄にMTGメンバーが増えることで話が分散しないか、開発時間が減ってしまうのではないかという懸念も出ていましたが、改めてチーム全員でMTGに参加することで

• 伝言ゲームになりやすい施策共有のコミュニケーションコストが大幅にさがった

• 見積を全員で行いさまざまな視点から仕様を設計に落とし込むことができ、見積の精度向上につながった

• コードレビューの時に施策共有ができているので施策観点でのコードレビューがしやすくなった

のような点で非常に施策の実装が楽になりました。個人個人で行動するよりも、スクラムで実施している以上チームを1つの単位として開発を進める方が結果としてスループットの向上に寄与している、と実感しています。

攻めと守りを両立

上記Consでも上げたように、プロジェクトチームとしての課題の一つとして長期的継続的な開発を進めていくための「守りの開発」ができなかった点があります。開発メンバーリソースのほぼ100%を新機能開発に割いており、プロジェクトに関連した改善以外はなかなか手を付けられない状態でした。合わせてCSからの問い合わせ対応や不具合の対応など、iOSチームとして取り組まなければならないタスクが後手に回り、プロジェクトチームのどちらで差し込みに対応するか、というコミュニケーションも都度発生していました。
職能別に変更してからは8:2のルールを策定してスクラムのプランニングを実施しています。

全体のストーリーポイントのうち仮説検証の施策開発に8割、それ以外の継続的・長期的な開発を可能にするための開発を2割という形です。他のプラットフォームでは改善デーや改善ウィークとしてまとまった時間を開発効率化などの施策にあてていますが、iOSチームとしては常に守りの開発を意識すべく、毎スプリントごとに少しずつ開発効率化などのタスクを実施しています。
mikanとしてはこれから大きくグロースしていくフェーズであり、仮説検証の優先順位が高くより早く、より正確に仮説検証できるような開発体制を整備しなければなりません。そのためにPMや各チームと合意を取り、仮説検証の速度を少し抑えてでもそのような改善施策に日々取り組める体制を整えています。

仮説検証のブラッシュアップ

プロジェクトチームを解体した一つの理由として、大きな施策を出して終わらせるのではなく、細かく仮説検証を行い、改善サイクルを回していきたいというのも大きな所です。
そのために施策のキックオフなど早めのタイミングでiOSチームも含めて巻き込んでもらい、より精度を高く、より早く出すためにはどうすればよいかをPMと詰めながらMVPを探っていきます。
iOSチームではそれぞれ仕様や技術的に得意な分野があるので、あらゆる観点から施策の改善提案がされるようになりました。前述しましたがこちらでも「チーム全体で参加するってなるとMTGの時間増えすぎて大変なのでは・・」という懸念もあったのですが、結果レビューコストや施策共有コストが大幅に小さくなり、集中して実装を進めることができ、最終的なスループットは大きく増えました。

部分最適と全体最適

職能別チームとは別に、各プロジェクトは大きく開発チームという単位で仮説検証などのプロジェクトを進めています。開発チームにはmikanにおける開発メンバーがほぼ全員参加していて、我々iOSチームやPM、デザイナーチームもこの開発チームに所属しています。

各チームでもスプリントごとに振り返りを実施しているのですが、職能別チームのKPTとチーム横断で表出するKPTは往々にして性質が違います。どちらかに統一する、という訳ではなく、職能別チームで実施している振り返りはそのまま進め、開発チームとしても振り返りを実施しています。
iOSチームとしては主に「スプリントのベロシティをより増やすためにはどうすればよいか？」という部分最適な話を詰めることができ、開発チームとしては各チーム間の受け渡しなどの課題感やより仮説検証施策の策定からリリース・効果検証のスループット向上など開発プロセス全体の課題感についてを話せています。

職能別チームに戻してみて

職能別チームにしておおよそ半年ですが、iOSチームとしては職能別チームに再編成したことによってiOSチーム内ですべきコミュニケーションがしっかり担保され、そしてチームとして行動することで仮説検証などプロジェクトのスループットが安定し、そして増えてきているのを実感しています。CSからの問い合わせ対応をはじめとしたスプリント途中の依頼にもチームとして取り組むことができているので、安心して普段の開発が進められるようになりました。

この方式が進めやすく感じるのは、個人的に現状iOSチームが3人だからというのもありそうだなとは思っています。NARUTOのような、スリーマンセルで動ける心理的安全性の高いチームだからこそできてるって感じですね。

現状のチーム構成としても課題感はあります。 現在mikanでは絶賛開発メンバーの募集中ですが、今後開発チームのメンバーが増えた場合に開発チームのあり方を再検討する必要がありそう、という点です。現状大きな開発チーム1つとしてもメンバー11人と、理想的なスクラムのメンバー数+αぐらいで収まっているのでこのような動き方が可能かなと思うのですが、逆にこれ以上はスケールしにくい体制かなと思っています。今後の展開次第でまた最適な形を模索していきたいと思います。現状iOSチームはフルタイム3人で進めているため、このような動き方が現状最適なのかなと思っています。

チーム一丸となって開発できるような体制を今後も引き続き整えていき、より強いチームを作っていきたいと思います。
お読みいただきありがとうございました！

弊社では絶賛メンバー募集中です！