これまでソフトウエアの海外開発プロジェクトで問題にぶつかり，その対策実行を繰り返しているうちに，問題と対策の仕方に一定のパターンがあることが分かってきました。そのいくつかはこれまでご紹介したとおりですが，さらに経験を重ねるうちに，問題を未然に防ぐには，開発プロジェクトへの基本的な「取り組み方」や「姿勢」が極めて重要であると感じるに至りました。
今回は，開発対象が「ソフトウエア・モジュール」か「最終的なソフトウエア製品（以下，プロダクトと呼ぶ）」かで，日本側の取り組み方を変える必要がある点について紹介します。同じソフトウエアでも，モジュールとプロダクトの間には「必要とされるアプリケーションの知識」や「ソフトウエアの保守性」など，求められるスキルや要件が異なる部分があります。特にプロダクトの開発を海外に委託する際は，この点を見逃すと後で苦労する羽目に陥ります。
「開発完了！」と思っていたら，隠れた問題が噴き出してきた
ある海外委託開発の事例です。それは，デバイスを制御し，ホストと通信するソフトウエア・プロダクトの開発でした。この案件を担当していた筆者は，海外委託先が制御ソフトウエアの開発実績を持っていたので対応可能と判断し，開発を進めました。
当初，ソフトウエアの全体像があまり見えていない状況だったので，後になってさまざまな仕様変更が発生しました。その都度，海外委託先で変更対応をしてもらい，ようやく成果物を完了させることができました。長期のプロジェクトにもかかわらず，オフショア化により開発コストを削減できたので安心しかけていました。
ところが，それから隠れた問題が表面化してきました。フィールド・テストの段階になり，そのデバイスが予想以上にさまざまな条件で使用されることが分かってきたのです。そうした使用環境に対応するため，「デバイスが動作不良を起こした場合は，検知した不具合の内容をエラー・メッセージとして表示する」「通信エラーが発生した場合は，通信状態が正常に復帰した時点で自動リカバリーする」などの変更が必要となりました。
さらに，クリティカルなテストで，いくつか別の問題も見つかりました。海外委託先で異常処理や追加仕様を実装し，さらに日本側で確認テストを行い，ようやくそれらの問題を乗り切ることができました。しかし，この対応には数カ月の時間と相当の追加コストを要しました。
このプロジェクトにおける一番の問題点は，海外に開発委託するものが「ソフトウエア・モジュール」なのか，デバイスに組み込む最終的な「ソフトウエア・プロダクト」なのか，その違いを考慮しなかったところにあると考えています。前述したように，両者の間には，「必要とされるアプリケーションの知識」や「ソフトウエアの保守性」など，求められるスキルや要件が異なる部分があるからです。当初の筆者の認識が甘かったことに気付きました。
暗黙知の多いプロダクツ開発は難しい
開発対象がソフトウエア・モジュールだったなら，上記のような問題は起こらなかったのではないでしょうか。モジュールの開発では，入力，出力，プロセスが明確だからです。
一方，最終的なプロダクツを開発する場合はどうでしょうか。開発要素が多く，広範かつ深いドメイン知識が必要となります。さらに，プロダクツは実際の長期運用に耐えることが要求されます。
ここで注意すべきことは，プロダクツの設計書や仕様書には，ドキュメントに書きにくい「暗黙知」が隠れている点です。暗黙知は多岐にわたりますが，通常その業界の人なら「当り前」と考え，改めて定義したりしないような内容です。
ソフトウエアの開発において，既存のソフトウエアの関連ドキュメントやソースコードを示すと，優れた技術者であれば，それらから暗黙知を学び取るようです。そうやって開発作業を進め，成果を出すケースをたくさん見てきました。さらに，毎回担当する設計者が異なった場合でさえ，適切なスキルの技術者をアサインし，仕様定義，Q&Aシートでの詳細確認などをきちんと実施すれば，やはりうまく成果物が完成することを経験しました。開発ターゲットやスコープが明確であり，考慮すべき要素もはっきりしていて，暗黙知を既存ソフトウエアから学び取ることができたからと思います。プロダクツの開発では，こうした工夫が欠かせません。
前述したデバイス制御ソフトウエアの開発では，当初，「要求仕様を示し，それに基づいてソフトウエアを実装する」という単純なやり方で開発を進めました。そして，当該ソフトウエアがどのような環境条件で使用されるかの背景について，あまり検討することなく，開発作業を進めていました（そうせざるを得ない事情もありましたが）。
開発プロジェクトのスタート時に，事前のノウハウ伝承やプロダクツに精通した人材の投入，海外と国内の最適な役割分担といった対策をしておけば，おそらく問題を防げたと考えています。
