＜Flutter攻略への道・開発基盤の構築＞第７回　技術選定から実装へ ― 部内ポータル開発の現在地とこれから

導入部で述べたとおり、私たちの部ではテレワーク主体の勤務形態となり、社員同士のコミュニケーション不足が課題となっていました。
この課題を解消するため、部内向けのポータルアプリをスマートフォン向けに開発することを決定し、あわせて今後のアプリ開発にも活用できる基盤の構築を進めています。
これまでの回では、開発基盤の構想や標準機能、ポータルアプリの概要、開発構成などをご紹介してきましたが、今回は実際の開発状況についてお伝えします。

基盤構築の検討を経て、現在は実装フェーズに入っています。
まずは部内ポータルの簡易サンプルアプリを作成し、基盤の有効性を確認しているところです。
現時点で実装済みの機能は、共通エラー処理、ログイン画面、部員一覧・詳細表示、Chatwork連携、Googleカレンダー連携などです。

ただし、APIはまだ未実装で、アプリ内のモックデータにより動作確認を行っている段階です。
また、前回ご紹介したAWS Cognitoとの連携については、クラウド側の設定が必要なため、今後の対応となります。バックエンドの実装と並行して、認証機能の連携も進めていく予定です。

Flutterを用いた基盤構築において、最も時間をかけたのがアーキテクチャとパッケージの選定です。さまざまな選択肢を検討した結果、以下のような構成に落ち着きました。

アーキテクチャ：

保守性と拡張性を考慮し、MVVMパターンを採用。状態管理にはRiverpod 2.xを、ウィジェットの状態管理にはFlutter Hooksを組み合わせています。これにより、コードの可読性が高まり、状態の依存関係も明確になりました。

コード生成：

Freezed、build_runner、riverpod_generatorを使用。特にFreezedは、イミュータブルなデータクラスの生成を簡略化し、パターンマッチングにも対応できるため、型安全なコーディングに大いに貢献しています。

画面遷移：

go_routerを採用。ネストされたルーティングやディープリンクへの対応が容易になり、遷移ロジックの一元管理が可能となりました。

API通信：

DioとRetrofitを組み合わせて使用。Dioは柔軟なHTTPクライアントとして、RetrofitはAPI定義のコード生成により開発効率の向上に寄与しています。

ローカルDBと環境変数：

ローカルデータベースにはhiveを、環境変数の管理にはFlutter Dotenvを使用。オフライン対応やキャッシュ管理、環境の切り替えにも対応しています。

テスト：

Flutter TestとMocktailを併用し、単体テストから統合テストまで、各レベルのテストを効率的に実施できる体制を整えています。

実際に開発を進める中で、Flutterの強みを随所で実感しています。 特にホットリロード機能により、UI調整やバグ修正のサイクルを短縮でき、開発効率が大きく向上しました。

一方で、パッケージ選定には慎重さが求められることも改めて感じました。Flutterのエコシステムは急速に進化している一方で、メンテナンスが止まっているパッケージも少なくありません。
私たちは「部内メンバーで開発できる技術」「開発コストの抑制」「簡便な機能追加」を重視し、安定性と将来性のバランスを意識して選定を行いました。

現在のサンプルアプリをベースに、次のステップではAWSバックエンドとの連携を予定しています。
具体的には、Cognitoによる認証基盤の構築や、RESTful APIを介した実データとの連携に取り組んでいきます。

なお、当初検討していたGraphQLは、現時点での開発規模と要件を踏まえ、今回は採用を見送りました。その代わりに、よりシンプルで扱いやすいREST API構成としています。
今後は、今回得られた知見や設計パターンをライブラリ化し、他の社内プロジェクトでも活用できる共通資産として整備していく方針です。

選定したアーキテクチャとパッケージは、当初の想定以上に開発効率と保守性の向上に貢献しています。
とりわけ、RiverpodとFlutter Hooksによる状態管理の明確化や、Freezedを用いた型安全なコーディングは、チーム開発の品質担保に大きく寄与しています。

今後はこの基盤をもとに、業務アプリケーションやプロトタイピングツールなど、さまざまな用途への展開も視野に入れています。