導入事例・モバイルアプリ開発／DX
商用モバイルアプリのFlutter移行と開発基盤の整備
担当者が変わっても設計意図を掘り起こす必要がなく、機能追加やリリース確認を継続しやすくなります。
- 対象
- リリース済みの大規模toCアプリ
- 費用
- 約470万円（税別）
- 公開日・更新日
- /
結果
- 移行リスク 配信を止めずに実施
- 引き継ぎ 設計判断の経緯が残る
- リリース前 動作確認を自動化
課題
すでに配信中のネイティブアプリをFlutterへ移行するプロジェクトに、開発の途中から参画しました。課金・広告・通知など収益と体験の根幹に関わる機能を作り込みつつ、仕様と品質を後から追える形で残す必要がありました。
- 配信中のアプリの機能を落とさず、Flutterへ移行し切る必要がある
- 仕様が実装者の手元に留まり、設計判断の記録が残らない
- 受入基準が明文化されず、動作確認が手作業に依存
作ったもの
収益・体験の中核機能をFlutterで実装しながら、要件・設計・受入テストを記録として残す開発基盤を整備。開発はユースケース駆動で進め、自社開発のプロジェクト管理ツールとAIエージェントを組み合わせたAI駆動の開発フローで、設計から実装・レビューまでを回しました。
- iOS・Androidのサブスク課金、アプリ内広告、プッシュ通知、ネイティブ機能連携を実装
- ユースケース単位で要件を起票し、設計判断を選択肢と却下理由まで記録・E2E化
- 自社のプロジェクト管理ツールとAIエージェントを組み合わせた開発フローを運用
結果
配信中のアプリを止めずにFlutterへ移行し、課金・広告・通知という売上に直結する機能を作り切りました。なぜその設計にしたのかを却下案まで含めて残しているため、担当者が代わっても過去の判断をそのまま読んで引き継げます。受入基準をユースケース単位で自動テストにしたので、リリース前の確認が手作業の総当たりでなくなりました。
Beekleだからできたこと
動くコードだけでなく、次の担当者も判断できる仕様を残す
担当者が変わっても設計意図を掘り起こす必要がなく、機能追加やリリース確認を継続しやすくなります。
課金・広告・通知をFlutterへ移行しながら、要件・設計判断・却下理由・受入基準をユースケース単位で記録し、E2Eテストにつなげました。
Beekleでは、自社開発のプロジェクト管理ツールとAIエージェントを使い、ユースケース単位で要件・設計判断・却下理由・受入基準を残し、そのまま実装とE2Eテストへつなげています。そのため、担当者が変わっても『なぜこの設計なのか』をコードから推測し直さず、仕様を追跡しながら継続開発できます。
発注判断の裏側
このお客さまが、何と比べ、何を不安に感じ、なぜBeekleに決めたか。
- 比べたもの
- 社内での移行／別の開発会社
- 不安だったこと
- 課金・広告・通知など、収益に関わる機能を移行で壊さないか。前任が失敗した開発を引き継げるかも不安でした。
- 決め手
- 要件定義の力と、少ないやり取りで意図をくみ取る力を評価していただきました。前任が失敗した開発を引き継いで最後までやり切ることと、要件・設計判断・受入基準を記録に残しながら作る進め方が決め手になりました。
よくある質問
- Q. 商用モバイルアプリのFlutter移行と開発基盤の整備では、何が課題でしたか？
- A. すでに配信中のネイティブアプリをFlutterへ移行するプロジェクトに、開発の途中から参画しました。課金・広告・通知など収益と体験の根幹に関わる機能を作り込みつつ、仕様と品質を後から追える形で残す必要がありました。
- Q. 商用モバイルアプリのFlutter移行と開発基盤の整備の費用はいくらでしたか？
- A. 約470万円（税別）です。
- Q. 商用モバイルアプリのFlutter移行と開発基盤の整備で、何が変わりましたか？
- A. 配信中のアプリを止めずにFlutterへ移行し、課金・広告・通知という売上に直結する機能を作り切りました。なぜその設計にしたのかを却下案まで含めて残しているため、担当者が代わっても過去の判断をそのまま読んで引き継げます。受入基準をユースケース単位で自動テストにしたので、リリース前の確認が手作業の総当たりでなくなりました。
- Q. ほかにどんな方法と比べましたか？
- A. 社内での移行、別の開発会社と比べました。
- Q. なぜBeekleに依頼したのですか？
- A. 要件定義の力と、少ないやり取りで意図をくみ取る力を評価していただきました。前任が失敗した開発を引き継いで最後までやり切ることと、要件・設計判断・受入基準を記録に残しながら作る進め方が決め手になりました。