はじめに

こんにちは。jamboでテックリードをやっているishidaです。
2022年11月に入社し、現在はテックリードとモバイルアプリ事業のリーダーを担当しています。

Flutter未経験の状態から社内で導入を進め、
現在は日商250万円規模の機能を支えるモバイルアプリとして運用しています。

本記事では、

• なぜFlutterを選んだのか
• 戦力化するまでのキャッチアップ、学習方法
• 新技術をチーム開発する際に生じた課題と対応
• AIエージェントとの付き合い方
• 新技術導入時に1人目が意識すべきポイント

を、実体験ベースでまとめます。

!

なお、サービス名については伏せさせていただきます。ご了承ください。

補足として、本記事で扱う取り組みの時系列を簡単にまとめます。

• 1ヶ月目：Flutterキャッチアップ・技術検証（個人開発）
• 2ヶ月目：主要機能の開発・アプリリリース
• 3〜4ヶ月目：売上、DAUが拡大・メンバーの増員
• 5〜6ヶ月目：チーム開発・品質改善フェーズへ移行

✒️技術選定、Flutter導入の背景

🤔技術選定

Flutter導入の背景には、「新しい技術を使いたかったから」という理由以外にも様々な背景がありました。
事業要件とプラットフォーム制約の両方を満たすために、
新しい技術にチャレンジせざるを得ない状況でした。

当時のモバイルアプリには、
リアルタイム通話機能が必須要件としてあり、
Agora SDK を用いた通話が安定して動作することが求められていました。
この時点で、「要件を満たせるかどうか」は技術選定において絶対条件でした。

さらに、Appleの審査対応という現実的な課題もありました。
これまではUIKit, SwiftUIを使用したアプリ開発をしていましたがAppleにリジェクトされるようになってしまいました(ガイドライン 4.3 ソースコードの類似性)

こういったリジェクト対応の経験から、
既存の構成のままでは限界があると判断し、
フレームワークや言語レベルから見直す必要がありました。

👍Flutterにした理由

要件を整理した結果、
今回のアプリ要件を満たせそうな選択肢は
「React Native」 と 「Flutter」 の2つに絞られました。

どちらも Agora SDK を利用した通話が可能で、
アプリの操作性もかなりよく、条件を満たしていました。

最終的な決め手は、技術的な優劣というよりも、
自分が責任を持ってやり切れるかどうかでした。

当時の自分にとっては、
Flutterの方が学習していて楽しそうで、
長期的に向き合えるイメージを持てたことが、
最終的な後押しになりました。

📖戦力化するまでのキャッチアップ、学習方法

Flutterのキャッチアップにおいて意識していたのは、
「知識を増やすこと」よりも「実際に動くものを作れる状態になること」でした。
そのため、早い段階から自分でコードを書くことを最優先に進めました。

具体的には、入社後のトレーニングで作成していた既存の iOS アプリを題材に、
同じアプリを Flutter で実装することから始めました。

トレーニング時に開発するアプリは下記で公開しています
興味がある方は是非みてみてください

https://github.com/Jambo-Inc/iOS-Pokemon-SwiftUI-Hands-On

デモアプリイメージ

ゼロから新しいアプリを考えるのではなく、
仕様や挙動がすでに分かっているものを Flutter で書き直すことで、
フレームワークの理解に集中できるようにしています。

この段階で意識して実装したのは、
HTTP リクエストを用いたデータ取得や、
Widget のライフサイクルの理解といった、
実務で避けて通れない基礎的な部分です。
UI を作り込むことよりも、
「画面が表示され、データが取得でき、状態が更新される」
という一連の流れを体で覚えることを優先しました。

また、学習の過程では AI を積極的に活用しました。
いわゆるエージェント的な使い方で、
設計や実装方針について壁打ちを繰り返しながら進めています。

ただし、コードをそのまま生成させて使うことは最小限に留め、
「なぜこの実装になるのか」「他に選択肢はあるのか」といった理解を深めるための
対話ツールとして利用することを意識しました。

同時に、あらかじめ「やらないこと」を決めていたのも重要だったと感じています。
最新すぎるライブラリや、当時まだ情報が少なかった手法については、
無理に取り入れず、必要になったタイミングで検討する方針にしました。
また、UI の細かな作り込みや最適化についても、
戦力化の初期段階では後回しにしています。

まずは事業要件を満たすアプリを動かすこと。
その上で、必要になった部分だけを段階的に深掘りする。
この順序を守ったことで、無駄に学習範囲を広げすぎることなく、
比較的短期間で実務に投入できる状態まで持っていくことができました。

🤝チーム開発の課題と対応

Flutterをキャッチアップし、アプリをリリース、実際に売上が上がるようになった後、
おおよそ3〜4ヶ月目にかけて、開発に関わるメンバーが徐々に増えていきました。(自分含めて4,5名)

この頃には、Flutterアプリが日商100万円付近、DAUも数千規模になり、
今までの延長では回らない、自分がずっと開発をしている訳にはいかないフェーズに入っていました。

次に直面したのはチームでどう開発を回すかという課題でした。
新技術導入の難しさは、個人の習熟よりも、
チーム全体の生産性と品質をどう維持するかにあると感じています。

まず大きな課題だったのは、
サービスを成長させるために、自分自身が開発以外の業務に
リソースを割かざるを得なくなったことです。
事業側との調整や意思決定が増えるにつれ、
常にコードを書き続ける前提の体制は現実的ではなくなっていきました。

その結果として表面化したのが、

メンバーの習熟度にばらつきがある状態での
いわゆる「バイブコーディング」によるコードの保守性低下です。

AI を活用することで一時的に実装スピードは上がるものの、
設計意図が共有されていないコードが増え、
長期的には修正コストが高くなっていたり、バグが頻発している状況でした。

また、新技術であるがゆえにレビューや設計判断に時間がかかり、
結果としてチーム全体の開発スピードが落ちるという問題もありました。

メンバー増員時のデプロイ件数の減少(赤枠)

これらの課題に対して、いくつかの対応を行いました。

まず試したのが「No AI week」の実施です。

期間を区切って AI の利用をあえて制限し、
自分の頭で設計し、コードを書く時間を意図的に作りました。
これは AI を否定するためではなく、
各メンバーがフレームワークや設計をきちんと理解しているかを
確認する目的で行っています。

次に、チーム内の共通認識を揃えるために
claude.md のようなガイドラインファイルを作成しました。

このファイルには、
プロジェクトの設計方針やコーディング時の前提、
AI に投げる際のプロンプト方針などをまとめています。
また、一度作って終わりにせず、
開発の進行に合わせて定期的にメンテナンスする運用にしました。

claude.md(一部抜粋)

コード品質の担保については、
PR作成前のローカルレビューを取り入れてみました。
実装の意図や背景をその場で共有することで、
単なるスタイルチェックではなく、
設計の理解を深めるレビューができるようになったと感じています。

ローカルレビューに加えて、レビュー負荷そのものを下げるために、
github acitonsの自動AI レビューも併用しています。
命名や単純な改善点、明らかなミスの洗い出しを AI に任せることで、
人間のレビュワーは設計や仕様の妥当性といった
本質的な部分に集中できるようになりました。

github actions による自動レビュー(デモ)

これらの取り組みによって、
新技術を使いながらも、チームとしての開発スピードと
コードの保守性のバランスを徐々に取り戻すことができたと感じています。

オープンからマージまでの時間の推移

結果的に、11月には日商で250万を超えるまでにサービスを成長させることができました🎉

まとめ

新技術導入を振り返って一番強く感じたのは、
最終的には「導入した人責任を持って巻き取り、やり切る必要がある」ということでした。

技術そのものが正解かどうかよりも、
それを事業として成立させるまで向き合い続けられるかどうかが、
結果を大きく左右すると感じています。

また、自分自身のリソースの使い方を常に意識することも重要でした。
手を動かして実装すべきフェーズなのか、
それとも方向性を決めたり、チームの判断を支えるべきタイミングなのか。
状況によって求められる役割は大きく変わります。

新技術導入では、
「開発すること」と「決めること」のどちらかに偏ると、
技術は定着せず、サービスの成長も止まってしまいます。

この二つを行き来しながら、
その時点で最も価値の高い行動を選び続けることが、
新技術の浸透とサービスの成長を両立させるために必要なことだと感じました。

本記事が、
これから新しい技術を導入しようとしている人や、
1人目としてその役割を担う人にとって、
少しでも判断の助けになれば幸いです。