プロンプトと適用範囲
頻繁に接続が途切れるユーザーや、データ通信コストが高いユーザー向けのオフラインファーストなプロダクトを設計してください。回答には、ターゲットセグメント、重要タスク、オフライン時の動作、同期の仕様、競合処理、MVP、および指標を含める必要があります。
オフラインファーストは、単なるキャッシュのチェックボックスではなく、プロダクトとしての約束事として扱ってください。Android のガイドラインでは、コア機能のすべてまたは重要なサブセットをインターネットなしで使用可能な状態に保つことと定義されています。また、web.dev でもリクエストを完了できない場合にユーザーに対して明確なステータスを示す必要性が強調されています。
面接官が評価しているポイント
面接官は、セグメンテーション、制約下での優先順位付け、データ状態に対する信頼性、そして体験の選択を成果に結びつける能力をテストしています。優れた回答は、「オフラインで動作する」ことと「後で同期する」ことを明確に区別し、ネットワークなしでプロダクト全体が使えると約束するのではなく、限界を可視化します。
回答前に確認すべき明確化のための質問
- どのユーザー、場所、デバイス、接続パターンが対象範囲ですか？
- オフラインで動作しなければならない単一のタスクは何ですか（閲覧、作成、編集、取得、または共有）？
- データはプライベートなものですか、共同作業用ですか、規制対象ですか、それとも安全性に関わるものですか？
- コンテンツの鮮度はどの程度許容され、2台のデバイスが同じアイテムを編集した場合は何が起こりますか？
- ストレージ、バッテリー、データコスト、サポート体制は厳格な制約となりますか？
30秒で答えるフレームワーク
「圏外で記録を取得し、接続が復旧した際に同期するフィールドワーカーから始めます。MVP では、割り当てられた作業の閲覧、下書きの作成、軽量な証跡の添付、明確な同期状態の確認を可能にし、オフラインでのリアルタイムな共同作業までは約束しません。ローカルストレージを即時の信頼できる情報源とし、冪等なアップロード用のアウトボックスと明示的な競合レビューを備えます。適用範囲を拡大する前に、切断セッションでのタスク完了率、同期成功率、競合解決時間、データ使用量、サポートへの問い合わせ数を測定します。」
ステップごとの詳細解説
ステップ 1: 接続環境とタスクによるセグメンテーション
「インターネット環境が悪いすべての人」をターゲットにしてはいけません。タスク、障害の頻度、デバイスの性能、失敗に伴うコストによってセグメント化します。配達証明を取得する配送員、メモを記録する臨床医、チケットを閲覧する旅行者では、必要とされるオフライン保証が異なります。
ステップ 2: オフライン価値によるタスクの優先順位付け
各タスクを緊急度、頻度、データサイズ、可逆性に基づいてマッピングします。準備された作業リストの閲覧、入力の取得、下書きの保存、以前にダウンロードしたアーティファクトの取得など、限定されたクリティカルパスから始めます。コアのループが安定するまで、共同編集や重いメディアの処理は後回しにします。
ステップ 3: プロダクトの状態を明示する
ユーザーが次のアクションを起こせるラベルを使用します（このデバイスに保存済み、同期待機中、同期完了、競合のレビューが必要、アップロード失敗など）。web.dev では、グレー表示や曖昧なオフライン状態がユーザーを混乱させる可能性があると警告しています。現在利用可能なものと、接続がまだ必要なものを明確に示してください。
ステップ 4: 信頼できる情報源（Source of Truth）を定義する
オフラインファーストでは、ローカルのデータソースを即時の信頼できる情報源とし、後からサーバーと整合性を取ります。どのフィールドに権限があるか、バージョンがどのように比較されるか、同期前にユーザーがローカルの変更を取り消せるかどうかを説明します。
ステップ 5: 同期規約を設計する
変更処理（ミューテーション）を冪等性キーとともにアウトボックスにキューイングし、安全な操作のみを再試行して、進捗状況を表示します。同期を自動にするか、ユーザー起点にするか、あるいはその両方にするかを決定します。ネットワーク障害時にはユーザーの下書きを保持し、ローカルでの保存成功がサーバーによる確認済みの公開であるかのように見せてはいけません。
ステップ 6: 競合ポリシーを選択する
独立したフィールドについては、フィールドごとにマージします。共有されるステータスや数量については、暗黙的な Last-Write-Wins（最終書き込み優先）よりも、バージョンチェックとレビュー画面を優先します。競合が手動解決できるほど稀であるか、また機密データを公開せずにプロダクトが2つのバージョンを表示できるかを検討します。
ステップ 7: MVP とロールアウトの定義
最初のリリースは、1つのセグメント、1つの重要タスク、および制限されたローカルデータ量に絞り込みます。フィーチャーフラグの配下でパイロット運用を行い、機内モードや不安定なレイテンシをテストし、データ保持期間や添付ファイルのサイズを増やす前にリカバリパスを追加します。
ステップ 8: 成果指標とガードレール指標の設定
主要指標には、オフライン中の対象タスクの正常完了率や、同期完了までの時間などが含まれます。ガードレール指標には、データ損失の報告、未解決の競合、ストレージの圧迫、バッテリー消費、データ使用量、サポートへの問い合わせを含める必要があります。オンラインのベースラインと比較し、接続品質ごとにセグメント化して分析します。
トレードオフと境界線
トレードオフ 1: 鮮度か可用性か
わずかに古い作業リストを表示する方が何も表示しないより良い場合がありますが、タイムスタンプと鮮度の保証を明示する必要があります。安全性に関わるデータや財務データの場合は、楽観的な可用性ではなくオンラインでの確認が必要になることがあります。
トレードオフ 2: ローカルストレージかプライバシーか
ローカルデータを増やすと利便性は向上しますが、デバイス紛失時のリスクが高まります。フィールド数を最小限に抑え、機密コンテンツを暗号化し、ダウンロードに有効期限を設定して、明確な削除またはサインアウトの動作をユーザーに提供します。
トレードオフ 3: 自動同期かユーザー制御か
自動同期は手間を減らしますが、手動制御は従量制データプランや共有デバイスを利用するユーザーに役立ちます。デフォルトの動作に加えて、セグメントの必要に応じて一時停止や Wi-Fi 専用オプションを分かりやすく提供します。
障害シミュレーションと進化計画
シミュレーション 1: デバイスが1週間オフラインのままの場合
何が失効し、何が編集可能なままで、アウトボックスのデータがどれだけ保持されるかを定義します。ユーザーはローカルの記録がまだ有効か、再検証が必要かを把握できる必要があります。
シミュレーション 2: 2台のデバイスが同じレコードを編集した場合
具体的な例を用いて競合ポリシーを示します。自動マージによって重大な変更が隠れてしまう場合は両方の値を保持し、解決に要する時間を測定します。
シミュレーション 3: 同期は成功したがサーバーが変更を拒絶した場合
理由と次のアクションを添えて失敗状態を表示します。ローカルの下書きを保持し、無限リトライを防ぎ、安全な修正パスを提供します。
よくある間違いとフォローアップ
間違い 1: オフラインを単なる技術的な機能リストとして扱う
ユーザーのタスクと失敗時のコストから始めてください。Service Worker やローカルデータベースは、プロダクトの約束事を定義した後の実装上の選択肢にすぎません。
間違い 2: 完全な機能同一性を約束する
重要なサブセットと、意図的に除外するものを明確にします。制限のないオフライン対応は、ストレージ、プライバシー、サポートの問題を引き起こします。
間違い 3: 同期ステータスを隠す
ユーザーは、公開と区別がつかない保存を信頼できません。アクションに基づいたステータス、タイムスタンプ、検査可能なリトライパスを使用してください。
間違い 4: あらゆる場所で暗黙的な Last-Write-Wins を採用する
実装はシンプルですが、重要な作業を消去してしまう可能性があります。ビジネスへの影響が低く、ユーザーがリカバリできる場合にのみ使用してください。
間違い 5: オンラインのリテンションのみを測定する
オフライン機能は、毎日のアプリ起動数を変えなくても、現場作業の成功率を高めることができます。切断セッション、同期完了、データ損失に関する不満を計測してください。
間違い 6: リカバリのテストなしでローンチする
全体へのロールアウトの前に、機内モード、低速ネットワーク、ストレージ満杯、時計の変更、期限切れの認証情報、中断されたアップロードをテストしてください。