オフショア開発パートナーの選定ポイントと開発フェーズにおける注意点

1. 開発計画を明確する

システムを予定通りに完成させるためには、開発計画（マイルストーンを含む）を明確する必要があります。また、開発が予定通りに進んでいるかを把握するために進捗確認のフォーマットも事前に決定しておくとベターです。

2. 作業範囲の明確化

企業によって、各作業工程の作業内容、成果物などが異なります。プロジェクト開始時に作業工程別の作業内容を明確にすれば、作業工程のずれを未然に防ぐことができます。

3. 用語辞書の共有・命名規約の明確化と共有

開発で使用する各種名称の命名規則を標準化し、要求分析/システム分析工程の成果物の仕様理解と、 以降の工程の成果物の効率的な作成が目的となります。 これは、オフショア開発会社側にとって不慣れな言語で記述された設計書の読解と、以降の設計書の作成時に有用です。さらに、オフショア開発会社側に対して、命名規約・用語を明確にしておくことで、下記をねらいます。

・委託側から受け渡した設計書の理解度向上

・オフショア開発会社側での仕様書作成の品質向上

・受け入れ時のチェックに利用 委託側にとっても、日本語の誤用や説明不足がある設計書を理解し、レビューする上でも利用可能です。

4. 共通機能の明確化

品質向上、開発効率の向上が目的となります。 具体的には、オフショア開発会社側には、一般的に次の傾向があり、それを防止する必要があります。

・提供されたサンプルや最初に作成した開発物を繰り返しコピー&ペーストし、 それを書き直して成果とする。

・コピー&ペーストにより設計や実装がなされる結果、共通コンポーネント・共通機能・汎用モジュールとして考えられる類似の機能がいくつも作成されることになる。

5. 書類の記述レベルの明確化

特にお客様にオフショア開発会社側の成果物を提出する場合には実施すべき点として、書式記述レベルの明確化があります。詳細設計書、Q&Aシートやテスト成績書（エビデンスの要不要・レベル感）など、事前に書式を指定しておくとばらつきを現象させ、工数の削減が図れます。例外処理/エラー処理についても、記述して欲しいレベルで適切にサンプルに含めておくとベターです。

6. テスト粒度の明確化

書類の記述レベルの明確化と併せて、テスト粒度についても明確化しておくと、未然にミスを防げます。

7. 仕様未決定部分の明確化

開発期間不足などの関係で、要求分析〜システム分析〜アーキテクチャ設計工程の、日本側作業での仕様未確定部分が多いまま、オフショア側に開発依頼をする場合も少なくありません。成果物の仕様未決定部分は、未決定であると明確に提示しておくと混乱を防ぐことができます。

8. 開発環境、テスト環境の明確化

OSやデータベース、プログラミング言語、フレームワーク、IDE、使用ツール、使用ブラウザ、画面解像度、バージョン情報などの開発環境、テスト環境情報を明確にすることで、オフショア開発会社側の開発環境、テスト環境に差異が生じることを防ぐことができます。

相違がある場合は、やり直しが必要になります。発見が遅くなるほど、やり直しコストが高くなります。 最悪の場合は、システムが予定期間通りに完了できないことです。

そのため、オフショア開発会社が正しく認識していることを確保するために、情報共有を徹底する必要があります。

9. 開発ルールの明確化

コーディング規約などの開発ルールがある場合は、手戻り作業が発生しないようにオフショア開発会社へ明確にすることも必要です。