オフショア開発の進捗報告：「90％完了」の中身を確認する

「機能は90％完了しています」と聞くと、完成間近に感じられます。しかし、SIer、CTO、DX担当者が知りたいのは、どこまで動き、何を確認済みで、何が納期に影響し得るかではないでしょうか。

オフショア開発では、確認できる成果をもとに進捗を説明する方法を合意しておくことを提案します。進捗率を集計に使う場合も、定義と根拠を添えることが大切です。

1. 作業ごとに「完了」の条件をそろえる

着手前に、作業の種類に応じた完了条件を決めます。設計なら、レビューが終わり、確認事項が解消されていることが条件になり得ます。機能開発では、実装完了、内部テスト完了、結合確認済み、顧客が確認できる状態を区別します。

これらを一括して「完了」と表現しないようにします。顧客の確認が終わっていない場合は、確認待ちの範囲と、開発側で継続できる作業を明示します。

報告の各項目には、対象範囲、現在の状態、根拠、残作業を記載します。根拠には、レビュー済み資料、テスト結果、合意した環境で動作する版などが考えられます。版と確認日時も記録し、異なる状態を比較しないようにします。

デモでサンプルデータや模擬接続を使っている場合は、その制約を明記します。デモに参加していない人にも、何を確認できたかが正確に伝わることが目的です。

あるオフショアチームが、受注照会機能の進捗を90％と報告しています。画面は整っていますが、表示内容はサンプルデータで、倉庫システムとの連携は未確認です。

より明確な報告は、「画面はサンプルデータで確認済み。倉庫連携は未確認。日本側の窓口による接続環境の確認が必要。環境が整い次第、開発側が連携テストを実施する」となります。完了見込みにも、この前提を添えます。

こう書くことで、PMは必要な判断や支援を把握できます。機能全体が引渡し可能な状態に近いと誤解することも避けやすくなります。

実績は、すでに起きたことを示します。見通しは、完了予定とその前提を示します。判断が必要な事項には、担当者と希望する回答期限を記載します。

新しい情報が分かったら、見通しと変更理由を更新します。対象範囲が増えた場合は、従来の範囲と追加分を追えるようにします。算定の前提が変わったことを説明せず、進捗率だけが動く状態は避けましょう。

簡潔な報告を会議前に共有します。日越間の打ち合わせでは、新たに確認できた成果、止まっている作業、合意が必要な選択肢を優先します。会議後は、作業を管理している場所に決定事項と実行担当者を記録します。

管理向けの報告に技術的な詳細をすべて載せる必要はありません。責任者が適切な時点で判断でき、必要に応じて根拠を確認できる情報をそろえます。

TECHNESTは、日本市場との長年の協業を通じて、業務システムの設計・開発、レガシーシステムのモダナイゼーション、日本のコンサルティングパートナーとの連携に取り組んできました。

案件のご相談時には、完了条件、共有する根拠、確認待ち事項への対応を一緒に整理しましょう。オフショア開発サービスをご覧いただくか、TECHNESTへのお問い合わせから、適切な進め方をご相談ください。