こちらはTimee Advent Calendar 2023シリーズ1の15日目の記事になります。
こんにちは、タイミーでAndroidエンジニアとして働いている @orerus こと村田です。
私は現在タイミーのAndroidChapter（弊社は特定領域のメンバーの集まりのことをChapterと呼称しています）の一員で、喜ばしいことに来年早々にメンバーが大きく増加する予定です・・・！
以前はAndroidChapterのメンバーが全員同じチームで開発を行っていましたが、タイミーのエンジニア組織拡大に伴い全員が異なる開発チーム（弊社ではSquadと呼称しています）に所属する形へと変化しました。その為、各SquadにはAndroidエンジニアが少人数しか所属しておらず、Androidアプリに関するPRレビューについてはSquadを跨いで行うことになります。必然、故も知らないPRレビューが飛んでくる為、PRレビューの負荷が上がり工数的にも心理的にも辛いものとなってしまいました。
そこで今回は、そういった組織のスケールに伴い発生する課題解決の為の施策の一環として、弊社AndroidChatperで導入した独自のLADR（Lightweight Architecture Decision Records）について紹介したいと思います。
また、導入して得た学びや見えてきた改善点についても共有できればと思います。
施策の背景、課題
先述の通り、タイミーでは現在Androidメンバーが全員異なるSquadに所属し、それぞれが異なるプロダクトゴールに向けた機能開発を行っています。
AndroidChapterで毎日10分程度のデイリーMTGは行っていますが、そこでは現在取り組んでいるもの・これから触るコード領域、困りごと等の共有に留まります。（各Squadのデイリースクラムもある為、あえて軽い内容にしてあります）
そのような状態で開発サイクルを回す中で、いくつかの大きな課題が見えてきました。
- PRレビュー
- レビューに入る前に、PRが行っている開発内容を把握する為の多大なコンテキストスイッチコストがかかる
- コンテキストを十分に理解できていない為、仕様や設計の妥当性の判断が困難で表面的なレビューになりがち
- PRという完成形で初めてレビュー依頼が飛んでくる為、仕様や設計で致命的な問題があった場合に後戻りが難しい（修正コストが高い）
- PRレビューコストが高い為、PRレビューを行う際にまとまった時間を確保する必要がありレビュー完了までのリードタイムが長くなる
- 改修/影響調査
- 昔のコードや自身が触っていないコードについて、開発当初の意思決定根拠や設計意図が分からず、影響調査に時間がかかったり変更妥当性の判断が難しい
そこで、これらの課題を解決するために実験的に導入を始めたのが独自LADRでした。
独自LADRについて
ここでは我がAndroidChapterで定義している独自LADRについて紹介します。なお、ここでいうLADRは弊社AndroidChapter用に独自改変したLADRですが、AndroidChapter内では単に「LADR」と呼称している為、この記事でも以後は単にLADRと記述します。
そんなAndroidChapterで導入している独自LADRですが、株式会社ラクスの鈴木さんが公開されているLADR-templateをベースにさせていただいています。
また、鈴木さんの記事にある通り、LADRの本来の用途はアーキテクチャ選定において「導入しなかった」記録を残す為であると認識していますが、AndroidChapterではLADRの目的や対象をそこから拡大解釈して利用しています。
目的や対象を具体的にどのように拡大解釈しLADRを運用しているかについては、実際に私が作成した「LADRを導入する為のLADR」を以下に添付しますので、こちらをご覧いただければ雰囲気が掴めるかと思います。（「Context - 文脈」「Specification - 仕様、やること、やらないこと」の項目のみご覧いただければ十分です）
ご覧の通り、LADRのドキュメント自体は軽量なものになっている事が分かるかと思います。ここがLightweight形式を採用した最大の理由でして、ハードルを下げることでまずはこのドキュメントが書かれることを一番の狙いとしています。
LADRのサンプル
先ほどお見せしたLADRは機能開発を伴うものではなかった為にいくつか項目を省略してますが、機能開発時のLADRでは必要に応じて詳細な仕様を記述したり、実装時の設計についても触れています。
以下、実際に作成されたLADRのサンプルです。（雰囲気が伝わるようにシンプルなものと重めなものを抜粋しています）
サンプルA. 機能追加のためのLADR
サンプルB. 不具合修正のためのLADR
このようなLADRを作成した後、AndroidChapterにLADRのレビュー依頼をPRとして投げ、そこでLADRに書かれたコンテキストや仕様、設計について開発着手前にレビューを受けるようにしています。
LADR導入の経緯
先述のLADRについての記事を拝見したときに「これだ！」と思い、すぐさま「LADR導入の為のLADR」、および「LADRのテンプレート」を作成し、AndroidメンバーにPRという形で投げつけました。LADRについて解説するより、まず実物を見せ、そこから話をするのが早いと感じた為です。
PR上でLADRの狙いや、他ドキュメントとの棲み分けについてなどの多少のラリーはありましたが、好意的に受け入れられすんなりと実験導入が始まりました。
運用を初めて2ヶ月程度ですが、現在以下の18個のLADRが作成されています。
導入後の成果と学び、および見えてきた改善点
AndroidChapterメンバーからのFB
まずは2ヶ月運用してきて、AndroidChapterのメンバーはどう感じているのかを探るためにアンケートを実施してみました。
アンケート結果について、AndroidChapterメンバーの中でLADR作成経験済み、作成機会がまだ無い状態の2人の回答を紹介します。
「ありのままを記事に書きたいので率直に書いてね」とお願いをしておいたので、きっちりと本音が書かれているかと思います・・・！
※なお、アンケートの設問はChatGPT先生にご協力願いました
その結果がこちらです。
まずは分かりやすく数値で評価してもらいました。
一番右の私の回答分はバイアスがかかりまくっているのでスルーして、他メンバーの評価は以下のような感じです。
- 満足度はどちらも7と「やや良い」点数
- プロセスの効率化や課題解決度合いの感じ方はLADR作成機会があったメンバーは全体的に高め、機会が無かったメンバーは低め
- Bの方が「LADR導入によって解決された課題の効果度」の項目の3点について、「まだ自身で作成したことがないために自分事感が薄い」とのFBをもらっています
次に、フリーテキストで回答してもらったものを原文ママで掲載します。
※2人分の回答をマージしています
まずは導入による成果についての質問についてです。
こちらにより以下のことが言えそうです
- A、Bの両者ともに「コンテキスト共有」については効果を明確に感じている
- LADRを作成する機会があったメンバーは仕様/思考の整理に効果を感じている
- LADRを作成する機会がなかったメンバーもPRレビューの効率化には効果を感じている
- ただし、自身でLADR作成を行っていないと課題解決の実感が薄い
次に改善点についての質問です。
こちらにより以下のことが言えそうです
- LADRの制度自体の課題点はまだ発生していない
- 一方、ドキュメントの参照のしやすさ、ドキュメント作成のオンボーディングといったLADRの活用方法についての改善点が挙がっている
- この点は当初から想像していた懸念点であった為、今後の明確な改善点だといえる
- 組織がスケールしてもコンテキスト共有に関する課題解決の効果が見込めそう
自身の振り返り
また、私自身が感じているLADRのメリットデメリットも軽く挙げておきます。
メリット
- 何にせよ意思決定のログが残るようになった
- メンテを保証できない仕様書にするより、意思決定のログと割り切って扱っている
- PR作成時のコンテキスト共有が楽になったように感じた
- 「実装→ドキュメントを書く」が「ドキュメントを書く→実装」と順序が変わったのが大きいのかもしれない
- 設計段階の指摘や懸念点の伝達が事前にできるようになった
- 実装者以外のメンバーのコンテキストの理解度合いが深くなったように感じた
デメリット
学びと改善点のまとめ
以上から、学びと改善点について乱暴にまとめると以下のようなことが言えるかと思います。
- 課題解決に一定の効果は確実に出ており、デメリットを上回るメリットがあるといえる
- LADRドキュメントの参照性に課題がある
- LADRドキュメントを作成するまでのハードルがまだ感じられる
- オンボーディング時に1度作成してもらう等のケアが検討余地としてありそう
当初抱えていた課題は解決できたのか
最後に、当初挙げていた課題がどの程度解決できたかの所感をまとめます。
- 課題1: レビューに入る前に、PRが行っている開発内容を把握するためのコンテキストスイッチコストがかかる
- 解決状況: ✅ 完全に解決
- 課題2: コンテキストを十分に理解できず、仕様や設計の妥当性判断が困難
- 解決状況: ✅ 完全に解決
- 課題3: PRという完成形で初めてレビュー依頼が飛んでくる為、仕様や設計で致命的な問題があった場合の修正コストが高い
- 解決状況: 🤔 様子見
- 現状では問題なし。設計難易度の高い開発での対応を今後注視
- 課題4: PRレビューコストが高く、レビュー完了までのリードタイムが長い
- 解決状況: 🟢 一定の解決
- PRレビューコスト減少、ラリーの回数も減少
- 課題5: 昔のコードや自身が触っていないコードの開発意図が分かりづらい
- 解決状況: 🟢 様子見、ただし解決の兆しあり
- まだ運用期間が短く見返す機会が少ないが、LADRのルールを見直す際に当初作成したLADRドキュメントが役立った
結論として、全体的には解決に向かっていると感じています。ただし、組織のスケールアップに対する対応として導入した施策であるため、今後も組織がスケールした際の変化に注視しつつ、より良い形へと進化をさせ続けていく所存です。
