App Rescue & Rebuildの対象範囲

App Rescue & Rebuildは、既存のアプリケーションが未完成、不安定、保守しにくい、あるいは自信を持って前に進められなくなったときに、どうすべきかをチームが理解できるよう支援する業務です。作業は、現在のコードベースを残すか作り直すかを判断する前に、その証跡を集めるところから始まります。評価から始まります。完成間近に見える製品でも、依存関係、アーキテクチャ、リリース、担当体制の問題を隠し持っていることがあります。同様に、信頼性が低いと感じられる製品にも、役に立つ土台が残っていることがあります。最初の作業は、何が存在し、何が機能し、何が危うく、何を次の開発判断に妥当に引き継げるかについて、実践的な見解を確立することです。

何であるのか

この業務では、コードベースと製品の状態の評価に、必要に応じた安定化、修復、部分的な作り直し、全面的な作り直しのための管理された計画を組み合わせます。初期レビューでは、入手できるアプリケーションの構造、現在のビルド、依存関係、環境へのアクセス、既知の不具合、リリースプロセス、ドキュメント、製品が支えるべきユーザーフローを調べることができます。評価の具体的な範囲は、利用できるアクセスと資料を把握した時点で確定します。指摘事項は、既存の土台の中で修復できる問題と、より大きな変更なしに作業を続けると非効率になったり安全に計画できなくなったりする問題とを区別するために使います。レスキューの業務では、アプリケーションを回復させ、リリースし、保守可能にできるかどうか、またその方法について、証跡に基づく見解をお渡しします。次の開発方針を選ぶための証跡に基づく根拠をつくり、実現可能なスコープに合意できる場合には、合意した安定化や作り直しの作業を実施します。

誰のために

App Rescue & Rebuildは、次のようなチームに適しています。

担当者が変わった、停滞した、あるいは進めにくくなった未完成のアプリや製品の開発を抱えているチーム
既存のアプリケーションをめぐって、繰り返す不具合、不安定なリリース、依存関係の問題、あいまいな担当体制に直面しているチーム
機能している部分を残すか、特定の箇所を修復するか、一部のフローを作り直すか、新しい土台を計画するかを判断する必要があるチーム
現在の技術と製品の状態を理解しないまま機能を追加し続けるのではなく、より規律ある進め方を求めるチーム

明確にするのに役立つこと

レスキューの評価では、次の点が明確になります。

現在のコードベース、ビルド、環境、依存関係、製品フローで確認できることと、証跡が欠けている箇所
不具合やリリース上のリスクのうち、局所的な問題であるものと、より広いアーキテクチャ、担当体制、開発の問題を示すもの
残す、修復する、部分的に作り直す、全面的に作り直すという選択肢が、スコープ、リスク、依存関係、判断の時期の点でどう異なるか
信頼できる開発スコープを確定する前に必要なアクセス、製品上の判断、外部事業者、検証の手順

含まれる内容

合意した範囲で入手できるコードベース、ビルドの状態、依存関係、環境、ドキュメント、製品の背景の初期レビュー
観察された不具合の傾向、アーキテクチャ上の懸念、依存関係の健全性、リリースやデプロイのリスクの実践的な切り分け
観察された事実、前提、制約、さらなるアクセスや調査が必要な領域を区別した、平易な言葉による評価
最も現実的な次の方針についての推奨（残す、対象を絞った修復、部分的な作り直し、または別スコープでの全面的な作り直し）
評価の後に、実行可能なスコープ、アクセスの範囲、受け入れ方法に合意できた場合に限る安定化または開発作業
現在の優先事項、担当体制に関する問い、合意した次のステップを記録した引き渡しまたは判断のサマリー

含まれていないもの

評価が完了する前に、既存のコードベースのあらゆる部分を残せる、修復できる、リリースできるという約束
すべての不具合、技術的負債、セキュリティ上の懸念、依存関係の問題、リリース上のリスクを発見または除去するという約束
別途合意した開発スコープ外での、無制限のデバッグ、無制限の機能開発、際限のない保守
入手できない認証情報、ソースリポジトリ、ベンダーのアカウント、外部サービス、業務に提供されていないドキュメントの自動的な復旧
別途スコープを定めない限り、緊急のインシデント対応、ストア審査通過の約束、広範なバックエンド、コンプライアンス、インフラの作業

それを選ぶべきとき

重要な判断が、もはや何を作るかではなく、すでにある成果物から何を安全かつ妥当に引き継げるかである場合は、App Rescue & Rebuildをお選びください。制作会社や以前の開発者が未完成のプロジェクトを引き渡してきた場合、リリースが不安定な場合、コードベースが変更しにくくなった場合、製品チームが現在の計画に自信を失った場合に役立ちます。依存関係やアーキテクチャの負担の兆候がすでに出ている開発に、さらに予算を投じる前にも有用です。既存のアプリケーションがない、シンプルな新しい製品アイデアの場合は、通常、MVPやディスカバリーの業務のほうが明確な進め方です。レスキューの進め方が最もうまく機能するのは、企業側が入手可能なリポジトリ、アクセス情報、製品の背景を提供でき、初期評価の後に優先順位を決められる意思決定者がいる場合です。

私たちのアプローチ

既存の製品についての思い込みではなく、入手できる証跡から始めます。最初の段階では、どのようなアクセスがあるか、何を実行または確認できるか、どの依存関係が使われていると見られるか、現在リリースがどのように扱われているか、どのユーザーフローが最も重要かを記録します。そのうえで、当面の安定化に関する問いと、長期的な作り直しの判断とを切り分けます。コンポーネントを残すとは、定められた範囲内で維持するだけの価値と保守性があることを意味します。修復とは限定された問題に対処することであり、より広い土台はそれ自体として評価します。部分的な作り直しは、合意した機能している部分を残しつつ、選んだフローや層を置き換えます。全面的な作り直しは、既存の土台が管理された前進のための現実的な基盤にならない場合に検討します。開発スコープは、評価から責任ある判断に足る証跡が得られた時点で確定します。安定化や作り直しのフェーズに進む場合は、その受け入れ基準、依存関係、リリースの範囲を書面で合意します。成果は、証跡に基づく、より明確な判断の道筋です。

App Rescue & Rebuildのサービスページを見る