オフショア開発で目標とする品質・納期・コストを達成するには、日本で行っている以上にソフト開発工程をマネジメントする必要がある。しかも、できるだけ手間をかけずに効果的に進める方法を追求する。海外側が日本の品質レベルを理解しなければ真の改善は望めないからだ。
海外の発注先が決まり契約書を交わしたら、いよいよ実際のソフト開発が始まる。一般に海外のソフト開発会社に対しては「日本のソフト開発会社と比べ品質・納期意識が低い」と指摘する声が少なくない。だが、それは彼らが日本との取引経験が少なく、日本のソフト開発現場の実情をよく知らないことに起因する。加えて、品質・納期問題が発生した際に、いつも日本側がフォローして仕上げていては、品質・納期は向上しない。オフショア側に品質向上の意識を持たせ、問題に対応させながら改善していくことが大事である。
これまで筆者が経験した大失敗も、改善に対する気の緩みが原因だった。直近のプロジェクトが上手く完遂できたので「次も成功するだろう」と思い基本設計レビューの手を抜いた。するとデータベースやソフト構造に問題が発生。何とか修復しようと関係者で多大な時間や努力を費やしたにもかかわらず結果的に挫折した。常にプロジェクトの変化を認識し開発プロセスをマネジメントする必要がある（図1）。
 |
| 図1●契約マネジメントの範囲 |
重要なドキュメント、相手への渡し方に工夫も
オフショア開発における開発工程のマネジメントで鍵を握るのは、ドキュメントとプロセスの標準化だ。日本国内での外部委託のように「大体こんな感じで開発してほしい」と口頭で説明し、そのまま進めることは危険極まりない。要件定義はドキュメント化する必要がある。ドキュメント作成は、日本側でドキュメントを作成してから説明する方法や、口頭で説明し相手に書かせてから確認する方法などがある。
海外の技術者が日本語を話せれば十分に委託できると思う人も多いが、そもそも純粋に技術的な問題は、単純に言語の問題ではつまずかない。技術者のスキルが高ければ、ドキュメントと、それを使った説明がしっかりしていることのほうが重要だ。日本語ができる海外のプロジェクトリーダーに要求定義や基本設計をいくら口頭で説明しても、それを現地のプログラマらが作業を進めるためのドキュメントがないと要求が組織内に正確にブレークダウンされないからだ。
要求仕様や仕様変更をドキュメント化しても、その出し方にも工夫がいる。追加仕様ドキュメントをバラバラ送ったり、電子メールの文中に書いて連絡したつもりになったりなど、ドキュメントを一本化しない場合に、多くのプロジェクトが失敗している。変更はまとめて連絡し、必要によっては契約も含めて見直す必要がある。
海外の技術者にすれば、仕様定義が遅れたままプロジェクトがスタートしたり、毎日のように変わる仕様と向き合わなければならないのは「計画そのものが悪い」と映る。にもかかわらず日本側が、いつものように「とにかく、この通りにやれ」などと命令すると、相手側は参画意識や良い物を作ろうという情熱を失い、ただ言われた作業のみをこなせばよいと考える。こうしたやり方での失敗が実に多い。
日本では顧客の要求に柔軟に対応し、変更や改善を積み重ねて、より良いものを作るやり方が定着している。仕様変更を避けられない場合は以下の点に留意すれば対応が可能だ。
(1)要求変更管理の仕組みを持つ
(2)発生する仕様変更を一定期間ごと、または設計の区切りで伝える
(3)短納期の仕様変更はオンサイトで対応する
(4)仕様変更ごとの費用発生を考慮する
要件定義と並び重要なのが、ソフト開発計画だ。できるだけ、ソフトの開発要素を細かく分解する。開発要素を吟味しWBS（ワーク・ブレークダウン・ストラクチャ）に落とし、プロジェクト管理ツールなどで各要素をだれが、いつまでに完了させるかを可視化する。ソフト開発を小さく分解し進捗を管理すれば、各工程で問題を早期に発見し対策を打てる。
そのためには、開発途中での成果物の検収とレビューが欠かせない。プロジェクト開始時からレビューの予定を確認する。レビューで不具合を指摘して直らなければ委託中止の判断も必要になる。受け入れ検査の基準も明確に決める。ここでも「これくらいは、やってくれているだろう」という期待は禁物である。品質確保のためには、ソフトウェアメトリックスなども検討する必要がある。設計・デバッグ段階などの定量的なデータからソフト品質を測定し品質改善につなげる方法だ。
軌道に乗れば乗るほど人的対応は限界に
ソフト開発計画の中では、コスト計画も同時に立てる。日本で開発する場合の相当額に対しコストダウン目標を設定する。コストは日本側の人件費や社屋などの固定費と、海外委託費などの変動費からなる。オフショア開発を効率的に進めながら、技術やオフショアマネジメントのノウハウを自社に保有していければ、これらの総和が小さくなる（図2）。
 |
| 図2●オフショア開発のコスト計画 |
だが、オフショア開発が軌道に乗りプロジェクト数が増えてくると、それぞれを細かく定義、レビューすることが難しくなる。離職率が高い海外では、日本型の“人”が対応するスタイルには限界がある。
海外のソフト開発会社の場合、CMM（能力成熟度モデル）認定や独自の開発手順を持っていることが多い。だが、設計者やプログラマがその重要性を認識していないと形式的な運用になるので、期待を裏切られることもある。日本側が期待する品質・納期を実現するためには、そのための仕組みや基準、マニュアル作りが必要だ。
|
