MIC

読み込み中 0%

MICMIC

App開発外注の検収で手戻りを防ぐ方法

·

App開発の外注検収は、最後に画面を一瞥してサインするだけではありません。この記事では、検収前に何を準備すべきか、どの順序で確認するか、手戻りにつながりやすい落とし穴、そしてMIC Studioのようなチームに協力を依頼するのが適切なケースについて解説します。

多くの経営者は初めてAppを作る際、「外注に任せればリリースを待つだけ」と考えがちです。しかし検収の日になって、ログインが遅い、メッセージが届かない、バックエンドでデータを変更するのに半日待たされるといった問題が発覚し、双方が責任の押し付け合いを始めます。一方は「要件が明確に書かれていなかった」と言い、もう一方は「これも追加費用だ」と言います。手戻りが1〜2ヶ月続き、予算もリリース時期も一緒に失われてしまいます。


問題は多くの場合、技術ではなく、検収という作業がプロジェクトの一部として設計されていないことにあります。以下では順序立てて考えるべきポイントを整理します。これにより大部分の手戻りを防ぐことができます。


検収前に「何を検収するか」を明確に定める


検収はリリース1週間前から始めるものではありません。契約締結やプロジェクト立ち上げの時点で、「どのボタンを押すと、何が表示されるか」という粒度まで落とし込んだ確認可能な機能リストが必要です。


例えば予約系のミニプログラム開発プロジェクトの場合、リストには「予約をサポート」とだけ書くのではなく、「ユーザーが日付を選択した後、満席の時間帯は選択不可、送信後に通知を受け取る、店舗のバックエンドで注文ステータスを確認できる」と書く必要があります。具体的に書くほど、検収時のトラブルが減ります。


注意点:「〇〇というAppのようなもの」を要件にしないでください。相手の理解とあなたの理解が一致する可能性はほぼありません。


画面をクリックするだけでなく、フローに沿って検収する


画面がきれいでも使えるとは限りません。以下の流れで一通り確認することをお勧めします:


1. メインフローを通す:登録、ログイン、コア業務、決済、ログアウトを、実際のスマートフォンと実際のネットワークで実行する。

2. 異常系:ネットワーク切断、弱電波、二重送信、タイムアウト、権限拒否時に、メッセージが明確か、データが混乱しないかを確認する。

3. バックエンド管理:多くのApp開発プロジェクトではフロントエンドに問題がなくても、バックエンド管理システムでデータを変更できず、ログも確認できず、運用が直接行き詰まることがあります。

4. 複数機種:少なくとも主要な機種とOSバージョンをカバーし、1台のテスト機だけでデモをしないでください。


注意点:検収の場では、相手に内部テストアカウントでデモをさせず、自分で新しいアカウントを登録して一通り実行してください。


成果物が揃っていなければ、納品されていないのと同じ


コード、データベース、サーバーアカウント、サードパーティサービスアカウント(プッシュ、決済、地図)、APIドキュメント、デプロイ手順は、契約書に明確に記載する必要があります。


現実によくあるのは、企業サイトとAppを別々の2社に依頼した結果、アカウントが誰の手にあるか不明確になり、後でチームを変更して保守しようとしたら、コードが取得できず、サーバーにもログインできないという状況です。


注意点:検収書に「成果物リスト」のセクションを別途設け、項目ごとにチェックを入れ、1つでも欠けていればサインしないでください。ソースコードは自分の名義のリポジトリでホスティングし、権限は自分で管理してください。


セキュリティとパフォーマンスは別途検収する


通常の機能テストではセキュリティ問題は発見できません。少なくとも以下の3つを実施してください:


- 一般アカウントで他人のデータへのアクセスを試み、権限逸脱がないか確認する;

- APIが返すべきでないフィールド(電話番号、身分証番号など)を返していないか確認する;

- 主要ページの弱電波下での読み込み時間を確認する。


業務が取引やユーザープライバシーに関わる場合、ウェブサイトセキュリティテストまたはAPIレベルのセキュリティテストを別途実施し、リリース前に問題を顕在化させることをお勧めします。


注意点:リリース後にユーザーやセキュリティスキャンで問題が発覚するのを待たないでください。その時点での修正コストはリリース前の数倍になります。


検収の進行と最終支払いを連動させる


検収を2〜3ラウンドに分けます:第1ラウンドで問題リストを提出、第2ラウンドで再確認、第3ラウンドでリリース前のリグレッション。各ラウンドで書面記録を残し、誰が指摘し、誰が修正し、いつ完了したかを明確にします。


最終支払いを検収結果に紐付け、一部をリリース後の安定稼働後に支払うようにします。これは不信感ではなく、双方が問題を確実に解消する動機付けです。


注意点:口頭で問題を指摘しないでください。WeChatで「ここが少し重い」と言っても、1ヶ月後には誰も認めません。


MIC Studioへの依頼が適しているケース


企業サイトのリニューアル、予約系ミニプログラム開発、またはバックエンド管理システム付きのApp開発を進めていて、検収段階での度重なる調整を避けたい場合は、MIC Studioにご相談ください。


私たちは企業サイト開発、ミニプログラム開発、App開発のほか、スクリプト開発やウェブサイトセキュリティテスト、リバースエンジニアリングテストも手がけています。以下のようなケースに適しています:要件がまだ固まっておらず、機能リストと検収基準を一緒に整理する支援が必要な場合、または既存システムを引き継いで保守する必要があり、まずコードとセキュリティ面の健康診断を行う場合。


適さないケースも明確にします:テンプレートサイトだけでよい、予算が極端に低い、1週間でリリースしたいという場合は、標準化された製品を利用する方がコスト効率が良いです。


実行可能な3つの提案


1. プロジェクト立ち上げ時に検収リストを作成する:機能、異常系、バックエンド、成果物の4ブロックで、各ブロックをチェック可能なレベルまで列挙し、契約の付属文書とする。

2. 自分でアカウントを登録して全フローを実行する:デモを見ず、テスト機を見ず、実際のネットワークと実際のデータでメインフローを一通り実行する。

3. 最終支払いを段階的に行う:検収通過時に一部を支払い、リリース後の安定稼働を一定期間確認してから残額を支払い、手戻りコストを検収段階で解決する。