オフショア開発

内部設計まで国内でやって、実装・テストをオフショアでやるのは、ビジネス的な観点でいうと、うまみが少ない気がします。なぜなら、このとおりに実装しろっていうレベルまで、内部設計をつめるのは、コストがかかるからです。
ただ、それよりも私が気になるのは、書いている通りに実装しろって言うのは、モチベーションがあがらないと思う点です。実装しながらおかしいなと思っても、良いやそう書いてるしということになりかねません。
間違いのない設計など誰もできないと思うので、それでは困るわけです。
そのため、私は、ビジネス的にもモチベーション面からいってもオフショアに出すのは、内部設計からだと思ってます。
そうなると、オフショアで行われる内部設計の質がポイントになります。たぶん、従来のやり方だとブリッジSEが内部設計のレビューをがんばるということになるのでしょう。しかし、このやり方だと、ブリッジSEがボトルネックになる可能性が高い。レビューに時間がかかってはいけません。
くーすは、実は最初からオフショア開発を念頭においています。内部設計をする人もレビューする人もコストがかからないように作成するドキュメントは、業務ロジック層のコンポーネント設計書とデータアクセス層のDAO設計書のみです。
コンポーネント設計書は、メソッドの引数と戻り値、事前条件、事後条件のみが記述されていて、ロジック自身は含みません。事後条件をレビューするだけです。
DAO設計書は、メソッドの引数と戻り値だけで、レビューもしません。最初は、DAO設計書はなかったのですが、ないと業務ロジック層を作っている人が困るので、後から追加しました。
これまでのオブジェクト指向型開発で、外部設計書だけ渡して好きに作ってねというとオフショアに限らず悲惨な結果になる可能性が高いでしょう。
くーすでは、プレゼンテーション層、業務ロジック層、データアクセス層にきちんと分離し、業務ロジック層とデータアクセス層はステートレス、プレゼンテーション層で必要な項目をDTOで定義し、データアクセス層でDTOとリレーショナルなデータをダイレクトにマッピング、業務ロジック層は、チェック、データの加工、フロー制御をおこなうといったようにやることが決まっているので、人によるぶれが少ないはずです。
今週からオフショア開発も本格的に始まるので、私の想定どおりにいくのかどうか直ぐに答えは出るでしょう。


2ch向けに対してコメントしておくと、前向きな批判は、ありがたいと思っているので、遠慮なく指摘してください。スルーしているわけではないです。