こちらの記事は、Luup Advent Calendar 2025 の9日目の記事です。
はじめに
こんにちは。Luup User Product Group(以下UPG) バックエンドチーム所属の井上です。
私が所属するUPGは普段ユーザーの移動を支えているLUUPアプリの開発を担っており、バックエンドチームはモバイル開発者と連携しながら機能開発をしています。
その営みを改善し、より価値ある開発を早く実現することがグループの重要テーマとなっており、各チームとも左記に向けた目標を立てて開発プロセスや環境の改善に取り組んでいるところです。
今回は我々バックエンドチームにおける上記の取り組みについて、"Flywheel" の考え方を取り入れて課題整理してみたお話を紹介します。
バックエンドチームのFlywheel
まずFlywheel(直訳すると弾み車)とはなんぞやというところからですが、ビジネスにおいては 一つの改善が次の改善を加速させ、それが循環して事業成長を促進していく というモデルの考え方です。Amazonの例が特に有名かと思います。
Amazonの成長の原動力である「Amazonフライホイール効果」とは？ - GIGAZINE
Luupでも事業全体についての大きなFlywheelが描かれており、各部署・個々人が意識して日々の業務に取り組むべき指針として示されています。かなりよく練り込まれた力作なのですが、この場ではご紹介できないのが残念です。
そして、さらにそれに倣う形で我々UPGバックエンドチームもFlywheelを描いてみようと、グループ目標達成へ向けた課題を整理したものが以下の図です。
UPGバックエンドチームのFlywheel:
グリーンがグループ目標で、それに直接繋がるブルーの①②③がバックエンドチーム目標
ぜひ拡大してご覧ください！
ある改善が別の改善を後押しし、これが積み重なることで最終的にグループ目標で実現したいことを加速していくという構図です。
少々複雑に絡んでいますが、大小いくつか循環するパスが存在しています。
このモデルで計画を立てるメリット
大目的の達成のために逆算でやるべきことを洗い出す、というのは目標管理の場でよく行われていますが、
多くの場合ファネル(漏斗)型の絵や一方通行のフローが描かれているのではないでしょうか (私も以前はそのように描いていました)。
そこをFlywheelの考え方に変えてみると、以下の2点に関心が向くようになります。
- 加速させるための推進力を増やすこと
- 減速させる摩擦を減らすこと
すなわち、以下のように持続可能なチーム成長プランを考えられるようになるのです！
- 「この施策は、次の工程をどう加速させるか？」という視点が生まれ、単発で終わらない計画の策定に繋げられる
- 個々のテーマ・課題の関連や循環加速しそうな繋がりを見出すことで、どこに力を入れれば最も効率よく全体が回るかが判断できるようになる
- より多く線が集まっているところは大きな効果を生むであろうと捉える、など
実際に描いてみて、ソフトウェア開発チームの目標を立てるにあたっても有用なモデルと感じました。
チームの改善Flywheelを作成したその先には…
上図ではグループ目標の先へ伸びる線を省略していますが、矢印に記載の通り、その先はLuupの事業全体の成長を回すFlywheelへと繋がっています。
顧客満足度が高まり、事業がさらに成長して売上が拡大し、我々の開発リソースも増強でき、開発プロセス等のさらなる改善も推進でき、より多くの/大きな価値提供が可能になり… のように巡り続けることが期待できます。
以下、Flywheelに則った具体的な改善活動のご紹介
Flywheelで考えることの良さについて概ねお伝えできたところで、
実際どのような改善に取り組んでいるのか？という具体のお話も続けて書いてまいります。
例として図中の「①-a レビュー速度向上」「①-b 機能開発速度向上」に繋がり、小さなループを構成している (A), (B), (C) の部分を取り上げます。
(A)によって推進力を向上させつつ、(B),(C)にある摩擦を低減させていこうという意図が反映されています。
(A). AIによる開発支援とレビュー活用
Luupでも今年から本格的にAIコーディングエージェントを導入し、時間あたりのPRアウトプット量は増加してきています。
ここについては明確に「①-b 機能開発速度向上」に対するプラスとなっていますが、
世の多くのソフトウェアエンジニアが直面しているように、コードレビューがボトルネックになってトータルのスループット向上がいまいちという課題がありました。
弊社ではGitHub上で開発ワークフローを回しており、CIにCopilotやClaude Codeのコードレビューを統合する形で利用してきてはいたのですが、目標Flywheelを策定した頃はあまり効果的なレビューが得られていませんでした。
その後いくつかの試行・評価とプロンプトチューニングの結果、我々のアーキテクチャルールやissueの要求仕様・設計に照らし合わせたレビューをさせられるようになり、「①-a レビュー速度向上」への効果が出てきています。
こちらの詳細もDevelopers Blogとしてよいテーマなのですが、ここで書き始めると長くなってしまいますし、弊社メンバー誰かが書きそうな気配を感じるので割愛させていただきます🙏
(B). コアドメインのリアーキテクチャ
今年からバックエンドコードにDDDなモジュラーモノリスアーキテクチャが導入され、新たな機能・ドメインは新アーキテクチャで書かれるようになりました。
詳しくは以下の記事に書かれていますので、ぜひご一読を！
新アーキテクチャの恩恵は大きく、このスタイルで書かれるコードについては期待通り「①-a レビュー速度向上」「①-b 機能開発速度向上」に寄与できています。
現時点ですでに一定の改善はできている状態なのですが、
古くからあるコアなドメインほどレガシーアーキテクチャのまま残っている部分が多く、ここをリアーキテクチャしていくことがAIエージェントのコード理解精度アップ・開発効率アップに繋がると期待しています。
しかし機械的な移行のみでは解決せず、サービス開始初期から少しずつ増改築されてきた複雑なドメイン構造を解きほぐして再定義する必要がある… これを機に立ち向かおう！というのがチームの共通見解です。
現在、上記についてチームで定例ミーティングを置きながら整理を進めており、新規機能開発と並行しながらの現実的な移行計画を立てようとしています。
ここについても A. の成果を活用しながら移行を進めて、移行が完了しているドメインはAIエージェントによる改修も容易になり… という循環を生んでいけるはずです。
少なくない壁にぶつかることを予想していますが、移行が完遂できた暁にはそれらについても記事を執筆したいと思います。
(C). ドキュメンテーション改善
AIエージェントフル活用の開始から半年以上が経過し、また新規チームメンバーの加入も続々ある中で、いま一度ドキュメントはどうあるべきか？の見直しを行いました。
- どのようなドキュメントを、どのタイミングで、どこに残すべきなのか？
- AIフレンドリーなドキュメントの在り方とは？
- コードコメントに書くべきこと、書くべきでないことは？
いままでも開発管理やコードレビューの中で意識されている部分はありましたが、あらためて明確なガイドラインを策定しようという取り組みです。
この記事を執筆している時点で概ね方針整理はできたのですが、これから運用ということもあり詳細はまたの機会に…。
本記事に関わる部分を概要として抜粋すると、
- issue単位で、要求仕様に対する機能仕様・設計を残していくようにする
- MCPを介す際のコンテキスト消費懸念から、Notion等ではなくGitリポジトリ内にMarkdownで置くことにする
- 内容としては対エンジニア前提の記載スタイルでよい
- ドキュメント記載にもAIを活用するとよい(任意)
ということになりました。
エンジニアおよびAIエージェントにとって開発時の活用は当然できる形ですし、
非エンジニアからもAIエージェントに「ここの仕様はどうなってる？この場合はどういう挙動になるべき？」など質問を投げれば、咀嚼した形で知識を取り出すことができるようになります。
コードしかない状態でも実装がどうなっているか=How寄りの分析はできていますが、上記が整備されることでWhat/Whyの情報が得られるようになるはずです。
すると、AIにとっても整備できた領域の背景理解が向上して A. がより強化され、B. にも繋がり…… とこれも循環していくことが期待できます。
おわりに
以上、LUUPアプリバックエンドチームの開発改善の取り組みについて、Flywheelを使った整理の仕方とその具体例をご紹介しました。
例の一つ一つは普遍的な改善テーマでしたが、どのように連鎖・循環の相乗効果が生まれそうかを考えてみると、
納得感の高いチーム目標設定や計画立案時の優先度判断に役立つのではないでしょうか。
Luupのサービスはまだまだ進化を続けており、バックエンドチームも日々改善を重ねながらより良いプロダクトづくりに取り組んでいます。
もし興味を持っていただけたら、ぜひカジュアル面談でお話ししましょう！
Discussion