Androidアプリの受託開発

追加機能より先に、中心となる操作を決める

誰が使い、何を行い、現在どこで困っているかを教えてください。そこから必要な画面、データ、連携を定めます。

例えば現場作業アプリなら、割り当てられた仕事を開き、メモと写真を記録し、報告を提出することが中心かもしれません。予定管理、管理画面、顧客への通知は後の段階に分けられます。これは範囲の例であり、実績の紹介ではありません。

最初のリリースで実際の課題を解決しつつ、必要な依存関係も見える形にします。

Androidアプリの案件に含められる項目

これらは範囲を考えるための項目であり、すべての案件に含まれる機能ではありません。バックエンド、管理画面、サブスクリプション、継続的なホスティングは必要に応じて別途定めます。

Androidが中心ならネイティブ開発を検討

利用者がAndroidを使い、OSとの深い連携が必要なら、KotlinとAndroidのネイティブツールが候補になります。新しい画面にはJetpack Composeを使えますが、既存のViewベースのアプリも全画面を置き換えずに改善できる場合があります。

技術は要件から選びます。iOSも同じくらい重要で、体験の多くを共有できるなら、別々に開発する前にFlutter開発も比較してください。

既に製品の設計が定まり、主にネイティブ実装が必要な場合はKotlin・Jetpack Compose開発をご覧ください。

利用者が実際に遭遇する状況を考える

電波が弱い、アップロードが中断する、アプリを閉じてから戻る。重要な状況なら仕様とテスト計画に含めます。

オフライン対応は単純な切り替えではありません。通信なしでできる操作、未送信の変更の表示、同じ記録を複数人が編集した場合の扱いを決めます。キャッシュの閲覧だけと、変更を保存して後で同期することでは要件が異なります。

読み込み中、データなし、エラーの表示も定義します。「まだ結果がない」と「サーバーに接続できない」は区別すべきです。

相談から範囲を定めたリリースまで

要件の整理： 利用者、中心となる作業、既存システムを伺い、確かな見積もりを妨げる不明点を洗い出します。

技術計画： アプリの構成、データの流れ、連携、対応端末を決めます。リスクの高い依存関係は先に検証できます。

実装： 合意した機能を確認可能な段階に分けて開発し、範囲の変更は明示して相談します。

テストと引き継ぎ： 合意した利用手順を確認し、既知の制約を文書化して、提案に含むビルドと公開資料を用意します。

ストア公開の支援は範囲に含められますが、お客様の開発者アカウント、ストア要件、審査結果はそれぞれ別の責任として扱います。

見積もりを左右するもの

主な要因は操作の数と複雑さ、バックエンドの準備状況、連携先の品質、端末固有の要件、必要なテストです。既存の仕様書や動作するAPIは不確実性を減らし、未完成のコードや仕様不明の通信方式は増やします。

予算や希望時期に制約があればお知らせください。信頼性に必要な作業を黙って省くのではなく、最初のリリース範囲を相談できます。