こんにちは。技術本部 Mobile Application グループの山名です。
最近フレックスタイム制を活用した7時出社にハマっているのですが、5時台でもギチギチな小田急の快速急行に果てしない闇を感じています...
そんなことはさておき、今回は Sansan iOS の改善活動についてお話しします。
私は2021年4月に新卒として弊チームへ加入し早くも9ヶ月になりますが、一番印象的なのは改善意識の高さです。
Sansan は歴史が長く規模も大きいため、プロダクトと組織の両方に様々な負債が溜まっています。
しかし弊チームはそれらの負債から目を背けることなく日々改善を続けており、本当に良い組織だと感じています。
そこで本記事では、実際に行われている改善活動を皆様にご紹介しようと思います。
実際に行われている活動内容
主な活動は以下の通りです。
- FIXME
- チーム MTG
- GKPT
- Bug Fix Day
- Tech 案件
順に説明していきます。
FIXME(気がついたら行う)
FIXME は今後修正して欲しい箇所に付けるアノテーションコメントです。 弊チームでは最新の設計方針に沿っていない箇所を見つけた際に付けることが多いです(数年前まで採用されていた MVC の名残や、現在は使用が禁止されているレガシーなオリジナルプロトコルなど...)。
FIXME 自体は一般的な概念ですが、弊チームにおける良い点は、新機能開発時に FIXME を考慮して見積もる文化があることです。 可能な限り FIXME をリファクタリングする時間を含めた見積もりを出すため、新機能開発と同時に技術的負債も返済できます。 リファクタリングする余裕がない場合でも、FIXME が付いている箇所は理解・変更に時間がかかる傾向にあるため、多めにバッファを積むようにしています。
チーム MTG(週次)
チーム MTG はその名の通り、チーム全体で何かについて議論する場です。 毎週月曜日に時間が確保されており、議題がある場合のみ開催されます。 また MTG を入れたいチーム外の人への配慮として、毎週木曜日に Slack のリマインダを用いて来週開催するか確認し、議題がない場合は予定を解放しています。
議題は設計方針に関するものが多く、ログを残すために GitHub の Discussion へ書き溜めています。 最近だと弊チームはマルチモジュール化に力を入れているので、担当者が方針決め + 認識合わせの場として活用しています。 (マルチモジュール化の詳細に関しては、弊チームの相川が先日出した記事をご覧ください)
この取り組みの良い点は、少ない手間でチーム内の議論を活発にできることです。
まずスケジュール調整をしなくてよいので、気軽に開催可能です。
議題が発生してから全員の予定を調整するのは中々大変なので、予め確保しておくのは結構重要だったりします。
また予め全員を巻き込んで議論してよい場が用意されていることで心理的なハードルも低くなります。
実際私はこの仕組みに助けられ、入社して間もない時期でしたが Sansan が 独自に定義している VIPER *1 レイヤーを再整理するための議論を提案することができました。
予定を抑えておくだけでチーム内の議論が活発になると考えれば、中々費用対効果が高い取り組みと言えるのではないでしょうか。
GKPT(週次)
GKPT は振り返り手法の1つで、Good, Keep, Problem, Try の頭文字を取ったものです。 弊チームでは各人が Trello に Good と Problem を書き溜め、毎週火曜日の MTG でそれらについて議論します。 議論の中でこれからも続けたい Good は Keep、改善の行動に移したい Problem は Try に移動させます。 Try に関しては移動の際に担当者が割り当てられ、開発の合間等に対応します。
実際に、直近だと以下のような Try がありました。
- 未使用コード発見ツールの見直し
- CI 失敗時に担当者を Slack でメンションする
- ステージング環境検証方法のドキュメントを最新の内容にする
- Sansan VIPER の設計方針変更を Generamba *2のテンプレートに反映する
- Eight iOS チームがやっていたスキルマップ(どのメンバーがどの領域に詳しいか可視化したもの)を Sansan でもやってみる
また先日弊チームの多鹿が出した記事もその一環ですので、よろしければこちらもご覧ください。 buildersbox.corp-sansan.com
KPT 自体は一般的な振り返り手法ですが、弊チームにおける良い点は、振り返りっぱなしにならない仕組みがあることです。
具体的には、Try は毎日の朝会で担当者に進捗を確認する、チーム内で解消しきれない Problem はモバイル関係者が集まる振り返りに持っていくリストへ移動させる、リリース前等で余裕がない場合は stash に積んで後ほど取り組むといった運用がなされています。
また Try にするには大きすぎるものはチーム MTG で改めて議論したり、後述する Tech 案件の候補にしたりしています。
振り返りは本来ただの手段ですが、やったことに満足して次に繋がらないことも多いです(自戒)。
そのため、こういった振り返りの結果を最大限活かせる仕組み作りが根付いているのは非常に良いことだと感じています。
Bug Fix Day(月次)
Bug Fix Day は毎月第3木曜日に開催され、その日は1日中 GitHub の Issues にあるものを解消してよいという日です。 その名の通りバグを直す日...なのですが、Issues にはバグではないものも起票されているため、それらへの対応も行われます(デザイナーがふと気付いた表記揺れ、1stリリースには盛り込めなかった内容など...)。
この取り組みの良い点は、重要度が低い負債もきちんと返していけることです。 即座に修正されることが求められないバグや、一旦のリリースが許容される仕様漏れというのは、当たり前ですが優先度が低いからそのような判断を下されています。 そのため Issue を起票しても放置されがちで、酷い時はその機能が消えるまで対応されなかったりします。 しかし1つ1つは小さくとも、そういった負の体験は積み重なればユーザ満足度の低下にも繋がるため、Bug Fix Day のような強制的に向き合う時間を作るのは非常に重要なことだと思います。
Tech 案件(四半期毎)
我々の主な仕事はプロダクトマネージャから要求される機能の開発ですが、それ以外に Tech 案件というものがあります。 開発業務全体のうち Tech 案件が占める割合は15%となっており、役割は以下の2つです。
- ユーザ体験に直接影響しないが、運用上定期的に発生する問題への対応(新規 iOS バージョンへの対応、ライブラリのメンテナンスなど)
- エンジニアが感じている課題の解消(よく使うデザインのコンポーネント化、プロジェクト全体に関わる設計方針の変更など)
1に関しては書いてある通りの内容ですので、ここからは2について説明します。
これまで紹介してきたのは開発の合間にできる小規模な改善活動ですが、Tech 案件では開発業務全体の15%というかなりのリソースを使用できます。
時間にして数十〜百数十時間も充てることができるため、かなり大規模な改善が実行可能です。
実際に最近行った / 現在進行中の Tech 案件は以下の通りです。
- XcodeGen の導入
- マルチモジュール化
- 独自の Parallax Header コンポーネント作成
- リリースプロセス簡略化用の Slack アプリ開発
私が Sansan iOS に入って一番驚いたのがこの Tech 案件です。
開発業務全体の15%を使うことができ、かつ内容もエンジニア側の裁量に委ねられているというのは本当に凄いことだと思います。
実際に開発しているエンジニアにしか分からない課題というのは、どうしても新しい機能の開発に押されて優先度が下がりがちです。
もちろんそのような課題をチーム外の人に理解してもらえるよう努めるのも我々の役目ですが、理解してもらうには双方に多くのコストがかかるため、積極的に取り組みづらいというのが実情です。
しかし Tech 案件のようなエンジニア側に大きな裁量を持たせる仕組みがあるとそういった課題に取り組みやすくなるため、総合的に見ればプロダクトのデリバリー速度向上にも繋がるのではないかと考えています。
また内容としてチャレンジングで興味深いものが多いため開発に携わっていて非常に楽しいですし、働く上でのモチベーションにもなります。
もちろん上記であげたような内容は個人でもできますが、Sansan という大規模かつ歴史の長いプロダクトで試せるというのは得難い経験で学びも多いです。
組織やプロダクトだけでなく、そこに属している個人にとってもプラスな影響を与えてくれるこの Tech 案件は本当に素晴らしい取り組みだと思います。
おわりに
本記事では、Sansan iOS で行われている改善活動について紹介しました。
手前味噌になりますが、この記事の執筆を通して改めて弊チームの改善意識の高さを感じました。 もちろんまだまだ課題は残っていますので、これからも積極的に改善を続けていこうと思います。
また大前提として、今回紹介した改善活動を弊チームが行えているのは、それを受け入れてくれる組織風土あってのことです。 我々を信じてそれだけの裁量を与えてくれる組織や人々への感謝と感激を大切にしつつ、これからも開発に取り組んでいきたいと思います。
*1:現状採用しているアーキテクチャ buildersbox.corp-sansan.com speakerdeck.com
*2:新規 VIPER モジュールの作成を簡単にするために導入しているコード生成ツール buildersbox.corp-sansan.com