あなたのアプリには、すでにユーザーがいて、保存されたデータがあり、人々が頼りにしている動きがあります。バグ修正や機能追加のために開発者を迎えるときは、そうした既存の約束ごとも作業の一部になります。
私はまず、今のシステムと、必要な変更を理解するところから始めます。わかりやすい具体例、関係するサービスの全体像、そして今後も動き続けなければならないもののリストがあると助かります。このガイドでは、準備しておくことと、調査に期待できることを説明します。
変更内容を利用者の行動で説明する
「アプリが遅い」も出発点としては役に立ちます。ただ、「スマートフォンで、注文履歴が多いお客様の注文ページを開くと数秒かかる」とあれば、調べる対象がはっきりします。新機能なら、利用者が何をできるようになるべきか、今は何ができるのかを書いてください。
バグの場合は、再現手順、期待していた結果、実際に起きたことを送ってください。関係がありそうなら、デバイスやブラウザも書き添えてください。短い画面録画も役に立ちますが、共有する前に顧客情報や個人的なメッセージは取り除いてください。
問題がどのくらいの頻度で起き、誰に影響し、回避策があるかどうかも教えてください。利用中のお客様の決済が失敗する問題と、社内ページの見た目の崩れとでは、必要な対応が違います。
調査を始めるのに十分な情報が入った、架空のバグ報告の例です。
注文ページで「過去30日間」を選び、検索結果の2ページ目を開きます。日付の絞り込みがリセットされ、古い注文が表示されます。
期待する動作：ページを移動しても日付の絞り込みが維持されること。
ノートパソコンの Chrome で毎回発生します。スタッフは注文番号で検索して回避できますが、最近の注文を確認するのに時間がかかっています。
今のシステムの全体像を共有する
技術的な細部まですべて知っている必要はありません。わかっている部分から始めて、残りについては誰に聞けばよいかを教えてください。
コードの保管場所、リポジトリの所有者、本番で動いているバージョン。
アプリケーションが動いている場所と、現在の変更の反映方法。
使っているデータベース、ファイルストレージ、外部サービス。
セットアップ手順、自動チェック、既存のドキュメント。
既知の問題、途中の作業、この問題に対する過去の対応。
前任の開発者や別のチームに質問できるかどうか。
ステージング環境（変更をお客様に届ける前に試すための別環境）があれば、アクセス方法を教えてください。なければ、作業上必要になった時点で用意を検討します。
既存のリンク、保存済みのデータ、ユーザーの権限、外部連携、まだお客様のスマートフォンに入っている古いアプリのバージョンなど、今のシステムで守るべきものも挙げてください。新しい画面一つの話をしていると、見落としやすい部分です。
アクセス権は招待で渡す
リポジトリ、ホスティング、ドメイン、決済アカウントの所有権は、ご自身で持ち続けてください。開発者には、各サービスのアクセス管理機能を使って、作業に必要な権限だけを付けて招待してください。サービス側が対応していれば、調査は読み取り専用の権限とテスト環境から始められます。
パスワード、本番用の API キー、顧客データのエクスポート、環境設定ファイル一式を、ブリーフに貼り付けないでください。必要な秘密情報は、別の方法で受け渡す手順を相談して決めます。問題の再現には、本番の顧客データへの無制限なアクセスより、テスト用アカウントとサンプルデータのほうが役に立つことがほとんどです。
見積もりの前に調査の中身を理解する
既存のコードでは、どう動いているかを確認し、該当する処理を追い、変更が影響しうる範囲を把握する必要があります。独立して見える機能でも、権限、課金、データベースの移行に関わることがあります。
調査の範囲と条件は、始める前に合意します。調査結果の報告書では、次の点を説明すべきです。
何を調べたか、何を再現できたか、まだ足りないアクセス権や情報は何か。
推奨する変更と、検討に値する別の案。
影響を受けるおそれのある既存の機能やデータ。
作業の確認方法、リリース方法、問題が起きたときの戻し方。
今の時点で見積もれることと、さらに調査が必要なこと。
作り直す前に理由を確認する
古いコードでも、きちんと役目を果たしていることはよくあります。別のフレームワークを使いたい、新しい開発者の好みに合わない、というのは、動いているシステムを置き換える理由としては弱いものです。多くの場合、適切なのは的を絞った修正や、足りなかったテストの追加、段階的なアップグレードです。
置き換えが妥当な場合もあります。今のシステムでは無理なく満たせない要件は何か、残せる部分はどこか、移行をどう進めるのかを尋ねてください。比較には、新しいシステムを作る作業だけでなく、データの移行や既存の動作を維持する作業も含める必要があります。
変更を利用者に届ける方法を決めておく
反映の前に、変更をどうテストし、誰が確認し、問題が起きたらどうするかを決めておくべきです。稼働中のプロダクトでは、合意したリリース計画と、元に戻す手段を用意したいと考えています。コードを戻すだけではデータの変更は元に戻らないことがあるため、データベースの移行には別の計画が必要です。
日付の絞り込みの例なら、ページを移動しても選択が維持されること、ほかの絞り込みも正しく動くことを確認します。修正が本番サイトに反映される前に、プレビューでその動作を確かめていただけるようにします。
引き渡しの時点で、何が変わったか、どう確認したか、残っている作業は何かがわかるようにすべきです。新しいセットアップ手順、設定の変更、既知の制約はドキュメントに残します。
最初に送っていただきたいこと
プロダクトと利用者について：…
機能または問題と、その具体例：…
今後も動き続ける必要があるもの：…
コード、ホスティング、現在の開発者についてわかっていること：…
影響、優先度、期限（あれば）：…
まずはお問い合わせフォームからこうした情報を送ってください。相談する前に、プロジェクト全体を整理したり技術文書を書いたりする必要はありません。