こんにちは、技術本部 Mobile Application グループの山名です。
普段は Sansan iOS チームで iPhone/iPad アプリを開発しています。
本記事は Sansan Advent Calendar 2022 の3日目の記事になります。 adventar.org
前回予告した通り、今回は最近の Sansan iOS チームで起きた変化、生じた問題、解消に向けた試行錯誤についてお話しします。 buildersbox.corp-sansan.com
チームで起きた変化
大きく2つの変化がありました。
- 内部で2チームに分かれていたが、1つに統合
- 案件は個人が担当していたが、チームで担当することに
まず前者ですが、 弊チームは内部的に Cocoa と Cupertino という2つのチームに分かれていました。 分かれた当時はチーム全体の人数が多かった、見習い中のチームリーダー（以下 TL）を育成するためにあえて細かく分けたかったなどの事情がありました。 しかし異動によってチーム全体の人数に変化があり1チームあたり開発メンバが2人程度に、TL も見習いから正式登用になるなど状況が変化しました。 その結果、ただただマネジメントコストだけが高いという状況になったため、統合するに至りました。統合後の構成は TL 1、開発メンバ4、アーキテクト1 です。
次に後者ですが、弊チームでは余程規模が大きくない限り、案件は個人が担当する方針でした。 それはそれでマネジメントコストや開発者間のオーバーヘッドが発生しないというメリットもありましたが、ドメインの知識が偏ってしまうことや、チームとしてのベロシティが出せないので確度の高いリリース日を出しづらいという問題がありました。 そんな折、チーム統合というイベントが発生したため、それを機に案件もチーム全体で担当する方針に変わりました。
…と、ここまで聞くと良さげな変化に思えますが、水面下では色々と問題が生じていました。
生じた問題、解消に向けた試行錯誤
体制変更後、タイミング良くそこそこの大規模案件（10人月くらい）が降ってきたので、新体制で取り組むことになりましたが、その中で問題が表面化しました。 ありがたいことにプロジェクトリード（以下 PL *）を任せてもらっていたので、その視点から印象的だったことを2つ紹介します。
- コードレビューの時間増加 & 品質低下
- 案件全体の進捗が把握しづらい
* PL はその名の通りプロジェクトをリードする役割ですが、Sansan ではプロジェクト全体を横断的に見る役割としての PL は存在しないため、各プラットフォームにおけるまとめ役のことを指しています。Sansan iOS だとプロダクト側（PdM・デザイナ・データ分析）と他プラットフォーム（API・Android）に対する窓口、TL へのプロジェクト進捗報告、アーキテクトとの設計相談、開発メンバの進捗管理、チーム内でのリソース調整など、諸々の活動を主導します。
コードレビューの時間増加 & 品質低下
弊チームでは Pull Request は Approve が2つ付かないとマージできない決まりになっています。Approve を付ける人は PR 作成者が指名するのですが、以下のように1人目と2人目で役割が異なります。
- 1人目：仕様としての間違い/漏れがないか等、要件の実装に対して責任を持ってレビューする
- 2人目：具体的なコードの書き方や適切な責務分割ができているか等、保守性を意識した実装に対して責任を持ってレビューする
その性質上、1人目はチーム内の案件を把握している TL が、2人目はランダムなメンバがアサインされるのが通例でした。ただチームの統合によって TL が1人になり、そのままだとチームの全ての PR を見ることになって流石に無理があるため、2人ともランダムアサインすることになりました。
しかし、これによってコードレビューの時間増加と品質低下が発生してしまいました。案件を個人が担当し、TL以外は全体を把握していなくてもレビューできるという状況が長く続いていたためです。案件の初期から把握している TL と比べ、どうしても仕様の確認に時間がかかる、理解度が浅いことによって議論が長引く、細かな仕様までチェックしきれないという事態が起こりました。
この問題を解消すべく、実装前にチーム全体へ担当箇所の仕様と設計を共有する会を設けました。誰が1人目にアサインされても問題ないよう、共有と質疑応答を通して解像度を上げてもらうのが狙いです。実施前は PR にアサインされると「そもそも何の PR だこれは…？」という状態でしたが、実施後はタイトルを見るだけで「ああ、あの機能のあそこの部品の PR か」レベルまで理解できるようになり、明らかに時間短縮と品質向上に繋がったなと感じています。
また共有会では抜け漏れていたタスクや、PR で指摘されていたら大きな手戻りになっていた不備が発覚するなど、別方面からの効果もあったため、非常に良い施策でした。
案件全体の進捗が把握しづらい
これまでは案件を個人が担当する方式で、案件の進捗がほぼ個人の進捗と同期しているため、担当者に確認すれば大体把握できる状態でした。
また複数人で担当する場合も専属は2人までだったので、その2人に確認すればある程度把握できていました。
もちろんもっと定量的に知りたいという欲求はありましたが、割とそれで運用が回っていたため改善の優先度は低く、現状維持となっていました。
しかし、今回の案件は全員が同程度のタスク量をこなす上に、規模が大きく未決定の仕様も多いので誰がどのタスクを担当するか決まっていないため、従来の個人に依存した進捗管理手法は使えませんでした。
開発着手前の計画段階にチーム全員で一通りタスクの見積もりはしたので、最初はそれを用いて進捗を見ていましたが、すぐに問題が発生しました。
見積もりは純粋な実装時間を出していたため、コードレビューによって100%遅れが出てしまうという問題です。
実を言うとこの問題は以前から発生していたのですが、案件全体を1~2人で担当するため、タスクの並列数を上げるのが簡単でコードレビュー中に他のタスクを処理することで巻き返せたり、コードレビューが先述した運用によりスムーズだったりしたことから、支障が出るレベルでは表面化していませんでした。
しかし、今回の案件ではそれらのカバーが効かず、実装時間は見積もり通り進められているのに、スケジュールとしては日々遅れが増えていくという非常に精神的によろしくない状態になっていました。
これを解決するために、次はチーム全体で出した見積もりをマージまでかかった日付で割ってベロシティを出し、それを元に遅れを検知するという手法をとりました。 ある程度実情に沿った数値が出るようになりましたが、これもこれで問題が発生しました。 見積もりは計画段階で出したものなので、前半のタスクは確度が高く見積もりが正確ですが、後半になるほど不確実性が高く見積もりが過剰になります。これによって直近で出た現実的なベロシティを用いて後半の水増しされたタスクに対する進捗度合いを測ることになり、結局スケジュールとしては遅れているように見えてしまいました。実際、導入から時間が経つにつれてベロシティが不自然なレベルで上昇し、最終的にはスケジュールよりやや早まる形で着地したため、あまり参考になる値にはなっていませんでした。
ちなみになぜこんな中途半端な具合にスクラムっぽいメソッドを導入したかというと、導入前までは割と従来の手法に沿って進めており、いきなり完全移行するのは現実的ではなかったためです。
ただそうやっていいとこ取りをしようとした結果、なぜスクラムがあの構成になっているかを身をもって実感する羽目になったので、悪手だったなと反省しています。
チームでもこの結果を受け、次の案件ではきちんと実情に沿ったベロシティが出せるようにするため改善を回しています。
おまけ：体制変更前から感じていた問題、解消に向けた試行錯誤
ここまでの話とは別に体制変更前から感じていた課題がいくつかあり、PLという裁量のある立場ももらえたので、ついでに改善にチャレンジしました。 せっかくなので、おまけとしてここに書き残します。
改善に取り組んだ問題は以下の3つです。
- 「PL = 働き方が不自由そう」という印象
- その設計になった経緯が分からない
- 同僚評価を活用しきれていない
「PL = 働き方が不自由そう」という印象
現在弊チームでは「全員が PL になれるようにする」という目標を掲げています。
当然能力的に「なれる」ことが大事ですが、そういった人を増やすためには「なりたい」と思える環境を作ることも同じくらい大事だと考えています。
そんな自分の印象はどうかというと、「一定規模以上の案件になると色々縛られて大変そう…」というものでした。
特に感じていたのは働き方で、PL は他チームとの窓口になる、メンバの進捗を管理する、困った時の相談役になるという都合上、休みが取りづらい印象がありました。
また今回の規模の案件が降ってきたのは久しぶりなので、その間にチームへ加入したメンバにとっては良くも悪くも今回の自分の振る舞いが印象に残ってしまいます。
そういった事情があったため、せめて働き方だけは悪い印象を与えないよう振る舞いたいと考え、以下の目標を立てていました。
- なるべく残業しない
- 遠慮なく休みを取る
とはいえ単に達成するとチームに混乱をもたらすだけになってしまうので、マネジメントコストの分実装タスクを減らす、自分の進め方とメンバに期待する動きをドキュメント化、他チームからの問い合わせを早い段階で担当者にお願いするなどして、新たな問題が起きないようにしました。
結果としては約4ヶ月の案件期間において残業時間の合計は3hに収まり、休暇も10連休を取得させてもらったので、ある程度達成できたのかなと思います。 ただ残業時間はフレックスの早上がりで相殺した結果でしたし、休暇は意図した訳ではないのですが PL 不在でも問題になりにくい QA による品質検証フェーズと被っていたこともあるので、その辺りは今後改善していきたいです。
その設計になった経緯が分からない
Sansan iOS は10年近く開発されているアプリなので、実装者がいなくなってしまい、どういった経緯でその実装や設計になったかが分からないことがよくあります。 また実装者が在籍していても当時の記憶が残っておらず、結局分からないということもよくあります。 実装に関してはある程度類推できますが、設計に関してはそれが難しいため考慮漏れなどが怖く、再度手を入れる際に躊躇することが多いです。
これを解消するために、設計に使用している UML のコードを GitHub で管理し、設計に関するやりとりを Pull Request のレビューを通して行うようお願いしました。
導入してから人や記憶が消えるほどの時間が経っていないため効果は測れていません。 ただコードレビューで設計変更をお願いしようとした際に、このリポジトリを眺めて経緯を理解し自己解決するといった、時間が経っていなくても有用な場面があったので、これからも続けていきたいです。
同僚評価を活用しきれていない
こちらの記事にもあるように、Sansan では評価の際に同僚からコメントをもらう方式を採用しています。
同僚の視点から成果を伝えたり成長機会を与えられる仕組みですが、自分のチームでは以下の点を課題に感じていました。
- 半年前の同僚の活躍を忘れてしまう、1人あたりに割ける時間が少ない（複数の同僚からコメント依頼が来る + そもそも自分の評価も書かないといけない）ため、コメントが薄くなりがち
- テキストかつ一方的なコミュニケーションなので、伸びしろの指摘のようなマイナス寄りのコメントが書きづらい
これを解消するために、案件の終わりにメンバ同士で 1on1 を開催してもらいました。 プロジェクトの進め方、コードの書き方、レビューの仕方など様々な観点に対して、良かったこと・改善して欲しいことを互いに言い合ってもらいました。 また後の同僚評価で使えるよう、話した内容は2人だけが見えるプライベートなドキュメントに残してもらいました。
実際に開催してみましたが、自分の肌感とメンバへのヒアリング結果から、上記の問題はかなり改善できたと感じています。
またヒアリングでは「同僚評価の依頼は負担になるので少し躊躇してしまうが、1on1 で材料ができたので頼みやすくなった」「相手によってはあまり話題がなかったので、今後は他の人の動きにもっと着目していきたい」といったコメントも上がり、別方面からの効果があることも分かりました。
今後は日常的にこういった場を設けることや、徐々にフィードバックの場をオープンにすることでチームやメンバの目指す姿の解像度を上げていくことを考えています。
おわりに
以上、『チームが統合され、案件も全員で開発するようになった Sansan iOS チームで試行錯誤したことまとめ』でした。
結構 Sansan iOS の事情が濃い内容になってしまいましたが、皆様のお役に立てれば幸いです。
前回の記事でも書きましたが、裁量を持たせてもらえる環境というのは非常にありがたいことだなと思います。
特に今回は新体制になって一発目の案件なので色々と重要なはずなのですが、そんな機会をポンと任せてもらえるあたりに弊チームの懐の深さを感じています。
それでは最後まで読んでいただきありがとうございました。
