モバイルアプリ開発における共通化・標準化とパッケージ化へのアプローチ

モバイルアプリ開発における共通化・標準化とパッケージ化へのアプローチ

【はじめに】

モバイルアプリ開発においては、一般向けサービスや業務アプリを問わず、AndroidとiOSの両方に対応することが主流となっています。理由は大きく次の通りです。

  • スマートフォン市場はAndroidとiOSの二極化が進んでおり、どちらか一方の身に対応した場合、ユーザーを取りこぼす
  • 法人・自治体・大規模サービスでは、利用端末を限定できない

一方で、両OSを個別に開発・運用していく中では、OSごとの技術者の育成や品質に差が出るという課題が生じやすくなります。こうした背景から、共通コードを中心に複数プラットフォームへ展開できるクロスプラットフォーム技術に注目が集まっています。

図1:クロスプラットフォーム技術とは(イメージ)

図1:クロスプラットフォーム技術とは(イメージ)


【クロスプラットフォーム開発導入前の課題】

クロスプラットフォーム開発を導入する前のアプリケーションの開発では、大きく3つの課題がありました。

①ナレッジと人材の課題
AndroidとiOSでは、使用する言語や開発環境が異なります。そのため、OSごとに専門の技術者を確保・育成する必要がありました。その結果、以下のような問題が発生しやすくなります。

  • 特定OSにのみ詳しい担当者に依存しやすい
  • 引き継ぎや体制変更時のリスクが高い

②品質のばらつき
同じ仕様の機能であっても、以下の理由からOSごとに品質差が発生しやすくなります。

  • Android版とiOS版で実装者が異なる
  • 設計・エラー処理・ログ方針が揃わない

また、複数アプリケーションで共通して使われる機能をプロジェクトごとに個別実装していると、障害対応や改修時の影響範囲把握が難しくなるという運用上の課題も顕在化します。

③コストの増大
OSごとに開発・テスト・保守を行うため、以下の問題が避けられません。

  • 人件費・教育コストの増加
  • 見積り精度のばらつき
  • 開発期間の長期化

【解決策としてクロスプラットフォーム開発を導入】

こうした課題に対する有効なアプローチが、Flutterをはじめとするクロスプラットフォーム開発の導入です。

■クロスプラットフォーム開発の導入による主な効果

  • 1つのコードベースでAndroid/iOS両対応
  • 技術スタックの統一によるナレッジ集約
  • OS間での共通の挙動・UIを実現しやすい(ただしOSガイドライン配慮は必要)
  • 開発スピード向上と工数削減

クロスプラットフォーム開発により、「2つ作っていたものを1つにまとめる」ことが可能になり、ナレッジ・品質・コストの各課題をまとめて改善できます。

scroll

課題 解決へのアプローチ 期待されるメリット
ナレッジ
  • クロスプラットフォーム開発ナレッジを共通資産として蓄積
  • ドキュメント・導入手順を整備
属人性低減/引き継ぎ容易化/複数プロジェクトの同時推進
品質
  • 単一コードベース+共通の設計・運用ルールで方針を統一
品質の平準化/レビュー効率化/障害対応の迅速化
コスト
  • 1つの実装で両OSに対応し、開発・保守工数を集約
立ち上げ短縮/開発工数の削減/見積り精度の向上

【クロスプラットフォーム開発導入後に見えた課題】

クロスプラットフォーム開発の導入により、Android・iOSを個別に開発していた頃と比べ、開発効率が向上しました。一方で、アプリ開発案件が増え、複数のプロジェクトを並行して進める中で、新たな課題が見えてきました。

具体的には、多くのアプリで共通して必要となる以下のような機能を、プロジェクトごとに個別実装している状態が続いていました。

  • 通信処理
  • 認証
  • 課金
  • エラーハンドリング
  • ログ出力 など

この状態のまま案件数や開発チームが増えると、共通ルールや共通部品が存在しないため、プロジェクト単位で判断や実装が分かれやすくなります。その結果、次のような課題が顕在化します。

  • 実装方針や品質がプロジェクト単位でばらつく
  • 各案件での改善が他のプロジェクトに横展開されにくい
  • 修正や改修のたびに個別対応が必要となり、長期的に保守コストが増加する
図2:共通化・標準化の対象領域(全体像)

図2:共通化・標準化の対象領域(全体像)


【さらに一歩進める取り組み】

そこで当社では、クロスプラットフォーム開発導入に続く次のステップとして、共通機能のパッケージ化(ライブラリ化)が有効な選択肢の1つになると考えています。

■パッケージ化(ライブラリ化)とは
機能をプロジェクトごとに作り込むのではなく、開発の共通化・標準化を実現する考え方です。

  • 共通部品として切り出す
  • 利用ルール・設計方針を統一する
  • 複数案件で再利用可能にする

■パッケージ化(ライブラリ化)によるメリット

  • 開発効率の向上
  • 品質と信頼性の均一化
  • メンテナンス性の向上

■パッケージ化(ライブラリ化)の対象を考える際の観点

①現場課題の整理と共通化ニーズの把握
過去および現行案件で発生した課題や失敗事例を整理します。現場レベルで繰り返し挙がる課題は、実運用上のボトルネックとなりやすく、共通化による効果が期待できる領域と捉えられます。

②各案件で繰り返し利用される処理の抽象化
複数の案件で繰り返し実装されている処理は、パッケージ化の有力な候補になります。多くのアプリで共通して利用される機能を案件固有の実装に依存しない形で抽象化することで、再利用性の高い機能として提供できます。

③リスクの高い処理への着目
実装ミスがサービス全体に影響を及ぼす可能性のある処理については、個別実装を避け、共通化を検討する意義が大きいです。このような処理を共通部品として整理できれば、品質や安全性の観点で一定の水準を保ちやすくなると見込まれます。

このような考え方により、個別最適から全体最適への移行が期待できます。

図3:パッケージ化(ライブラリ化)による期待効果例

図3:パッケージ化(ライブラリ化)による期待効果例


【今後の展望】

本取り組みは、クロスプラットフォーム開発案件の拡大に備えて、開発プロセスをより効率的かつ安定的に進めるための基盤づくりの一環として技術的な改善に留まらず、品質・納期・運用の安定化に寄与する取り組みとして位置づけています。
今後も設計方針や運用ルールの整理を進め、最適なタイミングで活用できるよう、AIを活用した段階的な品質向上に取り組んでいきます。さらに、技術トレンドを捉えつつ、より良いプロダクトを継続的に生み出す“仕組み”の拡充を進め、プロジェクト価値の最大化につながる環境整備に取り組んでいきます。

サービステクノロジー事業部 第3システム部
武村 亮平

※ Android、Android Studio、Flutter、DartはGoogle LLCの商標または登録商標です。
※ Xcode、Swift、iOS、macOSはApple Inc.の商標です。
※ WindowsはMicrosoft Corporationの商標です。
※ Linux® は、米国およびその他の国における Linus Torvaldsの登録商標です。
※ JavaはOracleおよびその関連会社の登録商標です。
※ KotlinはKotlin Foundationの商標です。
※ 本ページに記載されている製品名、サービス名、会社名などは、それぞれの企業の登録商標または商標です。

【公式X(旧Twitter)】

株式会社NTTデータSBC株式会社NTTデータSBC X(旧Twitter)でシェア