assess-react-native-migration

React Native への移行評価

読み取り専用の移行判断を作成します。プロダクトとデリバリーシステムを診断し、移行は実行しないでください。

プロダクトの範囲を確定する

できるだけ多くの本番クライアントコードベースを確認できるワークスペースから評価を実施してください。現在のチェックアウトにプロダクト全体が含まれているとは限りません。

準備状況を評価する前に、次のことを行ってください。

1. 現在のリポジトリと、エージェントが利用できるすべてのワークスペースルートを調査します。
2. プロダクトのドキュメント、CI、リリース設定、ワークスペースマニフェスト、サブモジュール、および隣接リポジトリへの参照から、対応するクライアントプラットフォームを推定します。
3. 別個のネイティブ iOS リポジトリと Android リポジトリ、アプリのバリアント、および人員配置やコード共有の提案に関係する Web クライアントを含め、本番クライアントの各コードベースを特定します。
4. クライアント、リポジトリまたはパス、プロダクトに含まれることを示す証拠、およびアクセス状況を記載したプラットフォーム一覧を作成します。

iOS と Android の両方に対応している場合、方針を推奨する前に、両方のネイティブコードベースを調査してください。コードベースを利用できない場合は、その証拠を unknown と記録し、評価対象がアクセス可能なプラットフォームに限られることを明記したうえで、信頼度を下げてください。現在のリポジトリにプロジェクトがないという理由だけで、そのプラットフォームに対応していないと推定しないでください。

範囲の確認条件： 対応する本番クライアントがすべて一覧に記載され、各コードベースがアクセス可能、明示的に利用不可、または存在しないことが確認されていること。

最初の応答の確認条件

範囲の確認条件を満たしていない場合、最初の応答は次のとおりでなければなりません。

**Question:** Where can I access the production codebase for each client platform this product supports, including iOS and Android if both exist?

**Why it matters:** A migration path based on only one platform can miss native dependencies, product behavior, and delivery constraints that change the decision.

範囲の確認条件を満たした後、概況を聞くのではなく、厳しく掘り下げて質問してください。リポジトリの証拠から判断できない場合に限ります。

測定可能な移行の推進要因が不明な場合、最初の応答は次のとおりでなければなりません。

**Question:** What measurable delivery or business problem should a React Native migration solve?

**Why it matters:** This determines whether migration is relevant and which outcomes the assessment must test.

推進要因がすでに判明している場合は、最も影響の大きい次の不明点だけを、同じ2行形式で質問してください。質問と理由を述べたら、直ちにターンを終了してください。前置き、質問票、推奨事項、実装ガイダンスを追加しないでください。

ルール

• ドキュメント化されていない動作も含め、本番アプリをすべて信頼できる情報源として扱ってください。
• 質問する前に、利用可能なコード、CI、テスト、リリース設定、プロダクト文書、実行時の証拠を調査してください。
• 実装、動作、依存関係、デリバリー、ロードマップに違いがある場合は、iOS と Android を明示的に比較してください。
• プロダクト全体に関する主張は、対応するすべてのプラットフォームの証拠に基づくか、対象とするプラットフォームを明記してください。
• 重要な主張には observed、measured、reported、assumed、unknown のいずれかを付けてください。
• 集約した準備状況スコアではなく、証拠に基づいて推奨してください。
• ブラウンフィールド、グリーンフィールド、移行そのものを既定路線とせず、まず証拠を集めてください。
• 判断フェーズを主導してください。Path A が承認される前に、実装スキルを適用したり、Expo と bare React Native のどちらかを選択したりしないでください。
• 現行のネイティブシステムに対する React Native の限界的な価値だけを数えてください。
• エージェントの評価は、トークン数、生成コード、プルリクエスト数ではなく、受け入れられ検証済みの作業に基づいてください。
• 期間、コスト、コード共有、エージェントの生産性、ROI について、普遍的な主張をしないでください。

エビデンスモードを選択する

ソースコードまたはデリバリー成果物を利用できる場合は、リポジトリに基づく評価を行います。

1. プラットフォームの一覧を完成させ、評価で調査できるリポジトリを特定します。
2. アクセス可能なモバイルコードベースごとに、アプリのバリアント、CI、テスト、リリース設定、アーキテクチャ記録、製品ドキュメントを確認します。
3. 各ネイティブコードベースを検索し、SDK、権限、アプリ拡張機能、ストレージ、認証、プッシュ通知、ディープリンク、分析、実験、プラットフォーム固有の動作を調べます。
4. コードベースが分かれている場合もエビデンスを追跡できるよう、リポジトリ名に加えてファイルパスと行番号を記載します。
5. 関係者への質問は、不足しているコードベースの場所、またはリポジトリでは確認できない製品、組織、運用上の事実に限ります。

リポジトリを利用できない場合、または重要なエビデンスが不足している場合は、インタビューによる評価を行います。

1. ユーザーがすでに示している場合を除き、測定可能なデリバリー上またはビジネス上の課題から始めます。
2. 1回のやり取りにつき、意思決定を左右する質問を1つだけ尋ねます。
3. 回答によってどの選択肢、リスク、または前提が影響を受けるかを1文で説明します。
4. 曖昧または矛盾した回答をエビデンスとして受け入れず、より範囲を絞った質問で掘り下げます。
5. 回答を記録し、エビデンスの状況を更新して、次に影響が最も大きい不明点を選びます。
6. 追加の回答によって推奨内容、確信度、またはチェックポイントが変わらない場合は、質問を打ち切ります。

エビデンスのゲートを通過するまでは、すべての回答に次の内容のみを含めます。

**Question:** [one question]

**Why it matters:** [one sentence]

この段階では、質問票、選択肢の推奨、チェックポイント、実装ガイダンスを含めないでください。ユーザーがインタビューを中断した場合は、評価が完了したかのように装わず、現在のエビデンスの状況と、影響が最も大きい不明点を1つ提示します。

インタビューのターンゲート： 回答を1つ求めており、その意思決定への影響を明示し、2つ目の質問を含めていないこと。

1. 意思決定に必要なエビデンスを収集する

意思決定の内容、期限、現在の代替案、測定可能な推進要因を明示します。フレームワークの好みは推進要因ではありません。

次の観点を調べます。

観点	最低限必要なエビデンス
製品	対応プラットフォーム、アプリのバリアント、共有ロードマップとプラットフォーム固有ロードマップ、重要なフロー、アクセシビリティ、分析、エッジケース
ネイティブ領域	SDK、モジュール、権限、バックグラウンド処理、アプリ拡張機能、決済、ハードウェア API、カスタムレンダリング、実現可能な React Native の移行経路
継続性	認証とセッション、セキュアなストレージと永続化ストレージ、プッシュトークン、ディープリンク、サブスクリプション、インストール済みユーザーのアップデート、法務、セキュリティ、オフラインの制約
検証	再現可能なビルド、テストアカウント、手動および自動の QA、デバイス操作、ネイティブ実装との比較エビデンス、パフォーマンスのベースライン、独立レビュー
リリース	現在のリリース頻度と復旧方法、社内配布、フラグ、実験、ストアでの段階的リリース、希望するバイナリ配信レーンと任意の OTA 配信レーン
所有権	成果物、同等性、ネイティブとの境界、共有基盤、検証、リリースについての意思決定権限と担当者
エージェントガバナンス	承認済みモデルとソースの境界、保護されたシークレットとテストデータ、最小権限アクセス、エビデンスの保持、監査証跡、アーキテクチャとリリースに関する人間の承認
デリバリーのベースライン	実装とレビューの重複、待ち時間と引き継ぎ、同等性のギャップ、2プラットフォームでの検証、リリース指標、不具合、手戻り、保守コスト

OTA に依存する計画では、ランタイム互換性、段階的リリース、可観測性、ロールバックまたは再公開、監査方針を担当するオーナーを定めます。OTA が利用可能であることだけでは、移行のメリットにはなりません。

既存の製品知識とネイティブの知識を React Native の移行専門知識と組み合わせた、小規模な移行中核チームを活用します。意思決定を変える可能性がある不足情報だけを質問し、それ以外は前提として明示します。

ゲート： すべての観点にエビデンスまたは明示された不明点があり、経路を妨げる不明点がすべて特定されていること。

2. パスを選択する

いずれかの方針を選び、他の選択肢を採用しない理由を示してください。

方針	推奨する状況
パス A：ブラウンフィールド	リリースやインストール済みユーザーの継続性が最優先である場合、ネイティブとの結合が深い場合、フローを個別に移行できる場合、またはアプリ全体の一斉切り替えのリスクを許容できない場合です。ホスト境界と二重アーキテクチャのコストも含めてください。
パス B：グリーンフィールド	動作を再現でき、ネイティブ依存関係に信頼できる代替手段があり、継続性を実証でき、検証が十分で、置き換えが完了するまでレガシーの範囲を管理できる場合です。
パス C：グリーンフィールドを優先し、ブラウンフィールドへのフォールバックを設けるチェックポイント	グリーンフィールドの方が目標をシンプルに実現できますが、重要な不確実性が残っており、拡大する前にネイティブホスト内で完成した React Native の実装を検証できる場合です。
延期	事業上の根拠は妥当と思われますが、エビデンス、検証、責任者、予算、またはリリース準備が不足している場合です。最小限必要な準備作業と、再検討する条件を明記してください。
移行しない	ネイティブシステムが望ましい成果を満たしている場合、モバイル開発の重複が重大でない場合、ロードマップが非対称な場合、プラットフォーム固有の作業が大半を占める場合、またはリスク調整後のリターンが妥当でない場合です。

パス C は、業界標準ではなく、2025 年以降に Callstack が取り入れつつある運用モデルとして扱ってください。エージェントを利用できることで動作の移植はより現実的になりますが、速度と品質を確立するには、このプロダクトで測定したチェックポイントが必要です。

パス A が承認されたら、実装計画を react-native-brownfield-migration に引き継いでください。Expo、XCFramework、AAR、またはホスト統合に関する指針を繰り返さないでください。

ゲート： 決定的なエビデンスによって方針が 1 つ支持され、却下した選択肢には理由があり、確信度がエビデンスの質を反映していること。

3. 代表的なチェックポイントを定義する

パス C、および1つの不確実要素によって推奨パスが無効になり得る場合は、チェックポイントを設けます。組織が定めた固定のカレンダーと工数予算を設定します。次の2〜3つの垂直フローを選択します。

1. UI、データ、分析、ナビゲーションを網羅する一般的なフロー。
2. 永続化、エラー、セッションの動作を網羅する、認証が必要なステートフルフロー。
3. ネイティブ SDK、バックグラウンドタスク、ハードウェア API、オフライン時の動作、アプリ拡張機能、アクセシビリティ要件、ローエンド Android の制約など、計画を覆す可能性が最も高い境界。

各フローを、ネイティブのソース参照、実行時のエビデンス、担当者、パリティのシナリオに紐付けます。簡単な画面だけを選ばないでください。

既存のプロダクトを基準として、測定可能な受け入れ基準を定義します。

• 動作、状態、バリデーション、エラー、分析、アクセシビリティ、視覚的な出力がネイティブのリファレンスと一致していること。
• 認証、ストレージ、ディープリンク、プッシュ通知、選択したネイティブの境界が、必要なデバイスと OS バージョンで動作すること。
• 起動、インタラクション、メモリ、クラッシュの動作が、合意済みのベースラインまたは許容範囲を満たしていること。
• CI、社内配布、オブザーバビリティ、想定するリリース経路が、継続に十分な信頼性で機能すること。
• すべてのフローについて、デバイスレベルのエビデンスと、クリーンなコンテキストでの独立したレビューがあること。
• パス C で、必要な各ネイティブホストに少なくとも1つの代表的な React Native フローをパッケージ化し、起動できること。

少なくとも1つのフローで2つのパスを実行します。

1. 忠実なパス： 動作、分析、アクセシビリティ、状態、エッジケースを維持します。パリティのために維持したネイティブに沿ったアーキテクチャを記録します。
2. 慣用的なパス： React コンポーネントの構成、明確な状態の境界、型付きナビゲーション、再利用可能なプリミティブ、適切なテスト、測定済みのパフォーマンスを導入します。パリティとデバイスのチェックを再度実施します。

拡大する前に、MIGRATION.md、SCREENS.tsv、STATE_AND_STORAGE.tsv、DEPENDENCIES.tsv、EVENTS.tsv、PARITY_CHECKS.md の担当者を決めます。評価中は、依頼がない限り、完全な一覧を作成するのではなく、欠けている成果物を特定します。

最後に、次のいずれか1つの判断を下します。グリーンフィールドを続行する、パス C を続行する、完了した作業をパス A に移す、延期する、中止する。結果が都合の悪いものであるという理由だけで、チェックポイントを延長してはいけません。

ゲート： フロー、予算、基準、エビデンス、担当者、最終判断が明確であること。

4. 経済性を検証する

実装準備完了から両プラットフォームでの提供確認まで、代表的な変更を1つ追跡します。次の2つの時間を記録します。

1. 変更のリードタイム： コミットから本番環境の対象ユーザーに提供できる成果物まで。バイナリと OTA の配信を分けて記録します。
2. クロスプラットフォーム機能のリードタイム： 実装準備完了から、iOS と Android の両方で提供が確認できるまで。

重複実装とビジネスロジックのレビューの削減、パリティ調整の削減、エンジニアの配置転換のしやすさ、測定済みのリリースまたは復旧の改善による潜在的なリターンを数えます。iOS と Android のデバイス検証は、引き続き計算に含めます。別途予算を確保して評価しない限り、ウェブとの統合は基本ケースに含めません。

投資の全体像を計上します。チェックポイント、二重保守、ネイティブモジュール、トレーニング、慣用的な2回目のパス、テストとデバイス自動化、オブザーバビリティ、リリース基盤、プラットフォームのオーナーシップ、切り替え、ネイティブサーフェスの廃止を含めます。

投資回収に関する入力値をでっち上げてはいけません。提供されたデータに不確実性がある場合は、範囲で示します。検証と境界対応により予想される削減効果が消費される、ネイティブサーフェスが増え続ける、二重保守に終了期限がない、エージェントが検証済みの処理能力向上なしに手戻りを増やす、パリティは改善してもリリースが改善しない、または創出された余力に使い道が計画されていない場合は、見直し、延期、または中止します。

ゲート： 2つのプラットフォームでの検証を削減対象の作業として扱わずに、限界便益と投資全体を比較できること。

出力契約

証拠ゲートを通過した後、またはユーザーがインタビューを終了した場合にのみ、この契約を使用してください。

以下の順序で簡潔なレポートを返してください。

1. 推奨事項： 結論、確信度、決定的な理由、判断の境界。
2. 証拠： プラットフォームの一覧、網羅性の限界、出典の状況とプラットフォーム間の違いを含む重要な調査結果。
3. 前提と障害要因： 意思決定への影響が大きい順に並べた不明点。
4. チェックポイント： 予算、フロー、基準、担当者、証拠、最終判断。
5. ベースラインと ROI： 測定済みの入力、不足している入力、計上したリターン、投資総額、除外項目。
6. 次の意思決定： 誰が、どの証拠を使って、いつ何を決めるか。

結論は診断的なものにしてください。実行の話題が出た場合は、オーケストレーション、タスク契約、プロンプト、リトライルール、非公開エージェントは案件固有であるとだけ述べてください。非公開の実装情報を明かしたり、作り出したりしないでください。