この記事はTimee Product Advent Calendar 2025の12日目の記事です。
1. はじめに
こんにちは、タイミーでAndroidエンジニアをしている村田（@orerus）です。
私は2年前の2023年のアドベントカレンダーで、「Lightweight Architecture Decision Recordsの導入」という記事を書きました。
当時はAndroidエンジニアの人数も少なく、少人数だからこそ導入しやすかった実験的な施策でしたが、あれから2年が経ち、メンバー数は約3倍にまで急拡大しました。
一般的に、少人数チームで機能していた「全員合意」や「ドキュメント運用」は、人が増えると形骸化したり、ボトルネックになったりしがちです。 果たして、我々の独自LADR（Lightweight Architecture Decision Records）はスケールする組織に耐えられたのか？それとも破綻してしまったのか？
約2年間の運用の「通信簿」を、チームメンバーへのアンケート結果と共にお伝えします。
2. 独自LADRのおさらい（前提共有）
本題に入る前に、我々が2年間運用してきた「独自LADR」について簡単におさらいします。 （導入の経緯や詳細なフォーマットについては、前回の記事をご参照ください）
一般的なADR（Architecture Decision Records）はアーキテクチャ選定の記録を主としますが、我々は対象を拡大し、以下の目的で運用しています。
LADRの目的
- 案件のコンテキスト共有: 「なぜやるのか」「背景は何か」を実装前に同期する
- 設計レビュー: 実装着手前に設計方針の合意形成を行う（手戻り防止）
- 意思決定ログ: 「なぜその実装になったか」を未来に残す
また、運用ルールとして以下の特徴を持たせています。
- 「仕様書（Specification）」ではない
- あくまで「その時点での意思決定のログ」です
- リリース後に仕様変更があっても、過去のLADRは更新しません。改修時は 「新たなLADR」 を作成してリンクさせる運用です
- 書くハードルは極限まで下げる
- 必須項目は 「Context - 文脈」のみ
- 記述量は執筆者に委ねており、「悩むくらいなら1行でも書いて出す」を是としています
この「仕様書としてメンテしない（=数が増え続ける）」という性質が、後述する組織拡大期の課題にも関わってきます。
3. 【定量評価】数字で見るLADRの現在地
実際のところ、LADRはまだまだ元気に運用を続けております！ LADR総数も2年前の18個から約175個へと大幅に増加しました。
では、チームが拡大した現在、メンバーはこの運用をどう感じているのでしょうか？ 全メンバーにアンケートを実施し、2年前と同じ項目で数値化してもらいました。
▼ LADR運用に関するアンケート結果 （※各項目10点満点 / 古参メンバー：2年前の導入初期を知るメンバー、新メンバー：その後に加入したメンバー）
| 評価項目 |
全体平均 |
上限 / 下限 |
古参メンバー平均 |
新メンバー平均 |
| 1. 満足度 |
7.9 |
10 / 4 |
8.7 |
7.4 |
| 2. 効率化 |
7.1 |
10 / 3 |
8.3 |
6.4 |
| 3. コミュニケーション |
8.2 |
10 / 5 |
9.7 |
7.4 |
| 4. 課題解決効果 |
7.8 |
10 / 4 |
8.7 |
7.2 |
| 5. 学習・成長 |
6.5 |
10 / 3 |
8.3 |
5.4 |
| 6. 他チーム推奨度 |
7.2 |
10 / 3 |
8.3 |
6.6 |
数字から見えること
まず注目したのは 満足度の高さ（平均7.9点） です。 「人数が増えたら面倒になるだけでは？」という懸念に反し、組織が大きくなっても高い水準で支持されています。また、途中からJoinした新メンバーも一部が「満足度10点」をつけてくれていました。これは率直に嬉しいですね！
また、最もスコアが高かったのが 「コミュニケーション（8.2点）」 でした。 Squad（開発チーム）が分かれて普段の業務がバラバラになりがちな組織拡大期において、LADRが「エンジニア同士の会話のハブ」として機能していることがわかります。
一方で、「効率化」や「学習・成長」の項目では古参メンバーと新メンバーで特にスコアに開きが見られました。このギャップについては、LADR導入以前の痛みがある状態を知っている古参メンバーにとっては「LADRはマイナスをプラスに変えてくれるもの」だが、整備された状態で入社した新メンバーにとってはLADRがある状態がスタート地点（あるいは単なる追加タスクという認識）となった為ではないかと推察しています。実際、新メンバーからは「スピードが求められるシーンでボトルネックになる」という率直な意見も挙がっており、ここは今後の改善ポイントです。
4. 【定性評価】3倍規模になってもまだまだ手放せないLADR
一方、アンケートの定量評価（自由記述結果）から、LADRが一定支持されていることが伺えます。そこで、今度はその理由について考察してみます。
（※アンケートの設問と実際の回答内容については文末に付録として掲載します）
① 手戻りの撲滅と設計の民主化
LADRを出すタイミングはコードを書く前を推奨（最遅でも実装PRと同時）しています。これにより、実装後のコードレビュー（Pull Request）で議論が白熱し丸々作り直し…といった事態がなくなります。
実装前に設計のプロセスが強制的に組み込まれること、そのため設計時点でレビューしてもらうことで大規模なロールバックが発生しづらいことは大きなメリットかと思います。 （新メンバーより）
また、これから作る機能について「こうしたいんだけど、どう思う？」とLADRを通して気軽に相談できる文化が、心理的な負担を下げているようです。
② コードレビューの純度向上
LADRで設計の合意が取れているため、実際のコードレビューでは「設計議論」をする必要がなくなります。
コードレビューをする際に、設計周りのコメントをする必要がほぼ無くなる為レビュー側としても楽。 （新メンバーより）
これはレビュアー・レビュイー双方にとって大きなストレス軽減になっています。余談ですが、我々はAIコードレビューも導入しており、単純なロジックミス等はAIが先に指摘してくれる状態となっているため、相乗効果で実装PRのレビュアー負担を大きく減らすことができています。
③ 心理的安全性とオンボーディング
個人的に一番嬉しかったのが、新しく入ったメンバーからの以下の反応でした。
過去ログを参照してみましたが Light なこともあり書き方も人それぞれだったためいい感じに肩の力を抜いて書く事ができました。 実際 LADR を書く中でチームメンバーに質問したときも丁寧に教えてもらえたことを覚えています。 （新メンバーより）
書き方の参考にとてもなった。 足りてない部分や書き方など、チームメンバーが丁寧に指摘してくださった印象があり受け入れ体制は丁寧に感じた。 （新メンバーより）
ドキュメント文化が「参入障壁」にならず、むしろ「チームに馴染むためのツール」として機能していました。その結果がコミュニケーションの高得点に繋がっているのかと感じました。
5. 課題をどう乗り越えているか？ 〜AIという新たな相棒〜
もちろん、良いことばかりではありません。人数が増え、ドキュメントの数が膨大になるにつれて顕在化した課題と、2年前には予想していなかった解決策について触れておきます。
課題1：過去のドキュメント、どうやって探すのだ問題
「仕様書」として更新せず、ログとして積み上げる運用のため、GitHub上のファイル数は増え続けます（現在約175個）。2年前の懸念通り、人間が目で探すのは困難になりつつあります。
しかし、この課題はAIの進化によって思わぬ形で解決されていました。
最近は AI が便利なので Claude Code に 「この項目とその時書いた設計を LADR から探してサマライズしてください」 などと投げ掛けています。 （新メンバーより）
新しくLADRをつくる際に既存のLADRをAIに探させることがあったがよく探してくれる印象 （新メンバーより）
GitHubのリポジトリをAIに読み込ませることで、「検索性」の問題はAIが解決してくれました。これは2023年時点では想像していなかった嬉しい誤算です。*1
課題2：レビューのボトルネック化
一方で、組織拡大に伴う悩みもやはり出てきています。現在はLADRが出されるとAndroidメンバー全員がレビュアーにアサインされます。これがスピード感を損ねる要因になりつつあります。
実装とLADRのレビューからマージまでには数日かかっている印象があります。 スピードが求められるシーンでも、LADR をレビューに出しながら並行して実装し PR までたてた後 LADR 側で指摘をもらった場合に、実装の PR を LADR を見ながら修正する必要もありコンテキストが分断されるのでネックかもしれません。 （新メンバーより）
マージ条件としては「Android Chapter LeadのApproveのみ必須」という緩めな形にはしているものの、より多くの人の目に触れればそれだけコメントの数も必然的に多くなります。
ここについては、「10人程度までが見れる範囲。15人を超えたらコードオーナー制や分散レビューが必要かもしれない」といった意見も出ており、まさに今のフェーズが運用の転換点であるとも感じています。
課題3：AI時代の「思考停止」リスク
AI活用は書くハードルを劇的に下げてくれましたが、副作用も無視できません。
実際、定量評価における「学習・成長」のスコアが新メンバーで顕著に低かった（5.4点）のは、「AIが下書きをしてくれる分、自分の頭でゼロから言語化して悩む機会が減った」ことの裏返しである可能性があります。
AIにほとんどを書いてもらうため、記述するコストを小さくすることに意識が向くことが多くなったと感じる。 （新メンバーより）
AI活用自体は組織的にも推進しており歓迎するところですが、「AIに下書きさせて、人間が思考を整理する」という健全なバランスをどう保つかが、今後の新たな課題点となりそうです。
結論：約3倍規模になってもLADRは必要だったか？
結論として、 「必要だし、むしろ人数が増えた今こそ手放せない」 存在です！
約3倍規模に増えても、LADRは形骸化することなく、チームの意思決定の質とコミュニケーションを支え続けてくれています。 特に、新しく入ったメンバーがこの文化をポジティブに受け入れ、すぐに適応してくれている姿は、導入者として何よりの成果だと感じています。
ただし、（努力目標とはいえ）「全員で全部見る」運用はそろそろ限界に近づいています。 次のフェーズ（10人〜20人規模）に向けて、AI活用を前提としつつ、レビュー体制の分散化など、仕組みのアップデートを進めていくつもりです。
この記事が、拡大するチームでの情報共有やドキュメント運用に悩む方の参考になれば幸いです。
タイミーのプロダクト開発に興味を持ってくださった方、よろしければぜひ一度お話ししましょう！
プロダクト採用サイトTOP
カジュアル面談申込はこちら
付録: アンケート自由記述の全回答まとめ
アンケートの自由記述設問、および全回答です。
クリックしてアンケートの全回答（原文ママ）を見る
### 1. 組織拡大（Scale）に関する変化
**Q. 人数が増えてLADRのレビュー依頼も増えましたが、レビュー負荷や承認までのスピード感はどう変化しましたか？（ボトルネックになっていませんか？）**
- CLとして全てのLADRを見るのでその分負荷は増加しているが、いうほどLADRの数自体が多く無いため変化は感じない
- LADRが最近になってApproveまでのスピード感が落ちた気がします。他のも見るPRが増えたことや、AIによって書かれる分量が増えたので把握する量が増えたことなどが要因な気がします
- 多少のボトルネックは発生しているように感じますが、それを補って余りある効果があると思います
- （自分も含め）忙しさの度合いによりLADRのレビューが若干後回しになってしまっている印象があり、開発スピード上がったという印象はそこまで感じていないが、著しく開発スピードが落ちた、という印象もない
- レビュー負荷は良いが、レビュー完了までに時間がかかりリードタイムが悪くなるのに貢献している気がして申し訳ない
- レビューはLADRがあることでやりやすい
- 個人的に事前に設計を考える点はメリットである反面、メンバーの設計をレビューするのは特に自分が持っているコンテキストの外側だと心理的にもハードルが高く、なかなかレビューに参加できなかったりします。実際 LADR のレビューからマージまでには数日かかっている印象があります
- 基本的にはみるようにしている、特に負担と感じたことはない。忙しいタイミングかつ多くのメンバーに承認されている状態だとクリティカルではなさそうな気になりはコメントしない・残さないことは何度かあったかもしれない
**Q. 過去のLADRの数がかなり増えているはずですが、現在「過去の意思決定」を探すのは容易ですか？**
- GitHubの検索機能やローカルでの検索を使っているのでいうほど困ってない
- そんなに過去のLADRを探すケースがないので、困っていないです
- Githubのblobから検索して探しています。検索容易性は十分あると思います
- 過去の意思決定を探すのは容易。すべてのLADRを目を通しているので脳内INDEXがあり AndroidStudio で検索すれば出てくる。最悪思い出せなくても ladr フォルダにまとまっているので探し出すのに困っていない
- AIがあるので問題ないかも
- 特定のLADRを読んだときに、これは今も正しい情報なのかの確信は持てていない
- 最近は AI が便利なので Claude Code に「この項目とその時書いた設計を LADR から探してサマライズしてください」などと投げ掛けています
- 普段の開発において既存のLADRを参照する機会があまりないかも（Androidにおける開発の実装方針が大きくはずれることがなさそうなことに起因していそう）。新しくLADRをつくる際に既存のLADRをAIに探させることがあったがよく探してくれる印象
**Q. 書くこと自体の心理的・工数的ハードルについて、現在の率直な感覚は？**
- AIによって、より書くハードルは下がった気がします、レビューするハードルは分量の増加によって上がったかもなぁという感じです
- どのくらいの内容で書けば良いかはあまり肌感覚がなく、後から「書いてください！」と言われることもあります
- 仕様が固まっていなくても方針や予定を含んだ内容で書いてもOKとなっているので、書くことへの心理的ハードルはない。ある程度仕様をまとめたりしなければならないので工数的ハードルは忙しい時は少し気になるが、実装PRレビュー時などに使えることを考えると、工数的ハードルもほとんど感じていない
- あまりない
- 作りながら仕様が変わるのでドキュメントをアップデートし続けるのが難しい
- プロダクトタスクの立ち上がりから実装までの間にどうしても LADR を書く工数が少なからず発生してしまうこと、作りながら仕様を決めることもあるためその都度 LADR に立ち戻ってドキュメントを修正することになり勢いが削がれてしまう点は課題かなと感じます。スピードが求められるシーンでも、LADR をレビューに出しながら並行して実装し PR までたてた後 LADR 側で指摘をもらった場合に、実装の PR を LADR を見ながら修正する必要もありコンテキストが分断されるのでネックかもしれません
- AIによって書きやすくなった印象がある。実装を終わらせてから論点を整理させるといった使い方もできそう
### 2. オンボーディング・新メンバー視点
**Q. 入社時や新しい領域を触る際、過去のLADRを読むことは役立ちましたか？**
- 役に立ちそうとは思うが、直接恩恵を受けたというエピソードはないかも
- 仕様や経緯が記載されているのでその機能に手を加える際の参考になりました。ただ、Git 管理なのでドキュメントの更新も少しハードルがあると感じていて特に仕様について見つけた情報が最新かの判断が難しい気もしています
**Q. 初めてLADRを書いた時、既存のLADRは参考になりましたか？ また、チームの受け入れ体制はどう感じましたか？**
- 書き方の参考にとてもなった。足りてない部分や書き方など、チームメンバーが丁寧に指摘してくださった印象があり受け入れ体制は丁寧に感じた
- 既存のLADRは、ある程度参考になった（ある程度、なのは粒度がそれぞれ異なりどれに合わせれば良いか迷ったと思うため）。レビューで指摘してもらえブラッシュアップ可能なため、わからないままで終わるとかがなく受け入れ体制は良いなと感じた
- LADRを書くこと以外にも初めてのことが多くて書いたが、あまり深く考えていなかった気がする
- 過去ログを参照してみましたが Light なこともあり書き方も人それぞれだったためいい感じに肩の力を抜いて書く事ができました。実際 LADR を書く中でチームメンバーに質問したときも丁寧に教えてもらえたことを覚えています
- 他のLADRを参考に書いた記憶、書き手によってフォーマットが異なっていた気がしている。AI主体で書いてくれるようになれば記述のハードルやフォーマットもそろいそう
### 3. 未来へ向けて
**Q. 独自LADRの「ここが好き」（一番気に入っている点）**
- 自分・所属Squad以外の開発内容についても知れ、自身の意見を述べる機会が与えられるところ。意思決定意図をリポジトリ内に残せるところ
- Planモードの先駆けてきな感じで、最初に仕様を自身でも整理できるのが良いですね
- みんなでレビューすることにより認識がそろえられるところ
- これからこういった機能を開発したい、こういった機能を入れたいんだけどどう思う？を気軽に共有できる点
- 他のメンバー・squadが何をしているのか知ることができる。コードレビューをする際に、設計周りのコメントをする必要がほぼ無くなる為レビュー側としても楽
- とにかく書くハードルを下げていること
- 実装前に設計のプロセスが強制的に組み込まれること、そのため設計時点でレビューしてもらうことで大規模なロールバックが発生しづらいことは大きなメリットかと思います
**Q. 改善したい点・今後への提言**
- もっと書きやすいように項目を取捨選択・整理したい
- やはり把握する量が増えるので、LADR管理者の負担が心配になってきます
- 全員レビューは人数が増えると限界を迎えると思うので、他に認識を揃える方法を考えるべきだと思います
- 15人を超えてくるとすべてのLADRに目を通すことはかなり負担になりそうに感じるため、そこまでスケールはしないやり方かな、というところに限界を感じる。10人くらいまでが見れる範囲だと思っている。もし今の倍の人数になるならば半分くらいのメンバーを自動アサインなどにし...など分散する仕組みがあっても良いかも
- レビューを締め切るタイミングが難しい為、一次コメントは3日以内にとか決めたいかも
- 仕様書駆動開発になった時にLADRが仕様書っぽくなったりするのか妄想をする
- 物理的・心理的ハードルの課題も散見され、特に高速なバリューデリバリーが求められる中で小さくないボトルネックになりつつある気がします。とは言え数10人規模になってくると rails chapter と同様に領域ごとのコードオーナー制も視野に入ると思うのでそこまで人数がネックになることも少ないかなとは感じます
