第1回 オフショア開発でハッピーになれましたか？

http://www.atmarkit.co.jp/farc/rensai/bottleneck01/bottleneck01.html
第1回 オフショア開発でハッピーになれましたか？

ボーランド
今村智
2004/2/21
　開発プロセスブームも一段落した感がある中、最近は、原点回帰ともいえる“ソフトウェア要求”に関する話題が目に付くようになりました。この短期連載では、ソフトウェア開発、特に企業情報システムのSIの現場でよく見聞きする取り組みと、そのほとんどが失敗している原因に“ソフトウェア要求”の存在があること、そういった取り組みを成功させるためには、どのように考え、何を行っていくべきかをお伝えしたいと思います。

　第1回は、「オフショア開発でハッピーになれましたか？」と題して、すでに痛い目に遭った方（プロジェクト）も多いにもかかわらず、相変わらずの低コスト化圧力への即効薬として重宝されているオフショア開発について考えてみます。

（1）オフショア開発の実態

　近年、ソフトウェア開発の現場もほかの業界同様に、非常に厳しい価格競争を強いられているのは皆さんもご存じのとおりです。そして、そのような状況に対処するための手段として、人件費の安い海外に開発拠点を置くという状況もまったくもってほかの製造業界と同じです。製造業においては、教育レベル、文化、慣習の違いなどから、現地人スタッフの教育で苦労したという話も聞くものの、オフショア“生産”は、製造業においてはすでに成功モデルとして確立しているのも確かです。

　“生産”としたことには理由があります。製造業におけるオフショアリソースの活用は、開発済みの技術、仕様に基づいた大量生産フェイズという労働集約的な部分が中心であるのに対して、ソフトウェア開発のそれは、ユーザー要求を実現するための創作活動＝“開発”が中心となっています。本質を見極めずにとにかく製造業の“改善”を取り込もうとすることには疑問を持っていますが、取りあえず本稿では脇に置いておくことにします。

- PR -

　しかし、ソフトウェア開発においてはどうでしょうか？ 少なくとも筆者の経験、それからほかの経験者から聞き及んだ範囲においては、オフショア開発が成功モデルであるとはいえません。むしろ、日本人同士で、国内で開発をする場合よりも悲惨な結果を招いていることが圧倒的に多いようです。ここで、成功という言葉を使いましたが、本稿における“成功”とは単純に、“ソフトウェア開発プロジェクトを予算内で収めること”とします。

　もちろん、プロジェクトメンバーのプロジェクト内作業にかかる残業代は100％支給され、コストとして計上されることとします。あえて残業について言及したのは、かつて、「プロジェクトの成功は、納期を守ることであり、プロジェクトのリスクは残業代が支給されない上級SEの投入でヘッジする」ということを公然というプロジェクトマネージャがいたからです。そのようなマネージャのプロジェクトにアサインされたSEの方は本当にお気の毒です。プロジェクト初期から、燃え尽きるまで走り続けさせられます。

　少し脱線してしまいましたが、ソフトウェア開発におけるオフショア開発では、手痛い失敗が非常に多いのです。ここでいう失敗とは先の成功の定義から、予算オーバーか、納品できなかったか、あるいはその両方ということになります。そして、その理由を探ってみると、「要求を正しく理解してもらえない」「日本人であれば行間を読んで要求の不備をカバーするということがあるが、オフショア開発者にはそのようなことはそもそも無理」「出来上がったプログラムを引き取ってテストしてみると、品質が悪く、まともに動作しない」といった要求仕様の理解や、品質に関するものが圧倒的に多いのです。

　また、「納期を厳守するということの重要性の認識が薄い」といった文化、慣習の違いによると思われるものも多くはありませんが耳にします。でも、要求仕様の理解や品質に関する問題は、何もオフショア開発だからというものではないと思いませんか？ そもそも、オフショア開発を行わなければならないようなプロジェクトとは、ある程度の規模と期間を要するものです。

　そして、そのような規模の開発であれば、日本人同士で行ったとしてもうまくいかないことが多いのです。ここで、明確にどのくらいの規模、期間かを指針として出せないのは、どの程度のスキルのメンバーをそろえられるか、チーム構成の工夫によって、必要なコミュニケーションラインをどれだけ単純に（少なく）できるか、といったことによって大きく変動するからです。ただ、経験からいえることは数十人程度の開発者のチームや、プロジェクト期間が半年以内のものであれば、優秀な国内の開発者を使う方がはるかに安全に成功を手にする可能性を高めることができると思います。

　それ以上の開発者を1つのプロジェクト内でコントロールしなければならないという場合には、まず本当にそれだけの人数を1つのプロジェクトメンバーとして必要なのかを再考すべきです。そのような規模のプロジェクトでは、ほとんどの場合、サブプロジェクトに分割し、個々のプロジェクト活動が、ほかのサブプロジェクトを意識しないようにすることが可能です。

（2）ブリッジSEの役割

　チームの規模による1人当たりの生産性の変化と、チーム全体の生産高の変化については、『アジャイルプロジェクト管理』（アリスター・コーバーン著、長瀬嘉秀、今野睦訳、ピアソン・エデュケーション）に詳しく説明されていますが、簡単に解説すると、開発者1人当たりの生産性は、プロジェクト規模が大きくなるに従って落ちていくのですが、まったくのゼロになることはありませんから、ある規模を超えると、チームとしての生産高が、少数精鋭のチームの生産高を超えることになるということです。ですから、この分岐点を越えるような人海戦術的なケースでは、オフショア開発が有力な選択肢として重宝されるのですが、先に述べたような、要求仕様の理解や品質に関する問題は、人海戦術では解決しないどころか、さらに悪化することになります。

　オフショア開発では、この問題に対処するために、さらにブリッジSEと呼ばれる役割を担う人を投入します。ブリッジSEとは、ユーザーからの要求仕様を、オフショアの開発者へ伝え、オフショアの開発者との質疑応答に対応することが主な仕事になりますから、オフショアの開発者の数が増えればそれだけブリッジSEの人数も増やさなければなりません。ところが、ブリッジSEが増えても最終的に対応するのは真の要求者である顧客メンバーですから、彼らの処理能力が増えない限りはボトルネックが移動するだけとなります。

　また、オフショアでは日本との時差も数時間ありますので、同じ日本国内であればユーザーとの仕様調整、仕様確認が日付をまたがることなく済んだものが、日付をまたがらざるを得ないケースが頻発します。これは、回復不可能な時間の損失としてあっという間に蓄積されます。それでもリリースの日付が変更されることはありませんので、結果として、開発の現場では単体テストコードどころか、手動での動作確認さえもままならない状態となってしまいます。

　ここまでの、ソフトウェアにおけるオフショア開発の問題を整理してみると、

要求仕様が正しく伝わらないことによって、低品質のプログラムが出来上がる

要求仕様の正しい理解を助けるためにブリッジSEを必要とし、コストメリットが増幅すると考えられる大規模開発になればなるほど、コスト増大、スケジュール遅延を招いている
ということになります（いうまでもなく、これらは実はオフショア開発に限った問題ではありません）。もちろんこれら以外にも、言葉の問題もありますし、文化、慣習の違いがあるのは先に述べたとおりです。しかし、この要求仕様を起点とする問題に対処することで、オフショアの人材を有効に活用することが可能です。上記問題点を見ればお分かりのとおり、要求仕様に含まれるあいまいさが少なければ少ないほど、これらの問題による影響を少なくすることになります。


（3）要求仕様のあいまいさをなくす

　要求仕様のあいまいさをなくすために有効な方法として、要求仕様がテスト可能であるかを確認するということが挙げられます。開発の進め方として、一般的には図1の進め方をよく見掛けます。しかし、この進め方では、要求仕様を書いた時点ですぐにその要求がテスト可能であるかを確認することができず、しばらく間が空いて、テストシナリオの作成段階において要求仕様がテスト不可能であることが判明し、それまでに済んでしまった設計、実装までもが見直し、再作業を必要とする事態が多く発生します。なお、ここでのテストシナリオとは、単体テストのパターンではなく、ユーザー要求に対するテストシナリオを指しています。つまり、どのようにすればユーザー要求（機能要求、システム要求ではなく）を満たしていることを確認できるのか、というものです。


図1 よく見掛ける開発ライフサイクル

　なぜ、このようなプロセスを行っているのか、私はいままで一度も納得のできる説明を聞いたことはありません。一番よく聞く説明は、「いままでずっとそうしてきたから」というものです。ではなぜ、最初にそのようにしたのかというと、

テスト担当は、開発チームとは別のテスト専門の部隊に所属し、テストシナリオ作成とテスト実施および結果のレポートが責務となっている

開発ライフサイクルが比較的長いウォーターフォール型の開発においては、テスト部隊のリソース管理上、テストシナリオ作成期間とテスト実施期間との間が開いてしまうのを避けたいために、テストシナリオ作成が、テスト実施の直前に完了するように計画する
ということです。つまり、大きな組織で、分業化が進んでいる状態で、個々の部隊の効率的なリソースマネージメントを行うためであり、プロジェクトの品質確保のためではないのです。

　ところで、米国でのソフトウェア開発プロジェクトの実態調査の１つでは、「ソフトウェアの問題（バグ、性能問題など）の30％は、“要求”に起因するものであった」という報告があります。30％とは、私の経験に照らし合わせると、かなり控えめな数値です。実際、ほかの調査報告では、「ソフトウェアシステムの問題の60％は、要求とその分析の過程において作り込まれていた」というものもあります。いずれの調査も、特定のプロジェクトを対象としたものではなく、複数のプロジェクトに対する調査結果をまとめたものです。


図2 要求に起因する問題の発見タイミングとその修正にかかるコスト

　図2は、そのような“要求”に起因する問題の発見されるタイミングが遅ければ遅いほど、その修正にかかるコストが飛躍的に増大することを表しています（Source：Boehm, Barry W. 『Software Engineering Economics』. Englewood Cliffs, NJ：Prentice-Hall, 1981）。

　具体的な数値は置いておくとしても、このような傾向は、遅ければ遅いほど、それまでに行ったすべての作業に見直しと再作業が必要になることから明らかです。

　ですから、“要求”の問題はとにかく早く発見する方がよく、そのために有効な手段である、要求がテスト可能であることの確認、つまりテストシナリオの検討、作成を早く行うことが重要になってきます。図3はテストシナリオ作成を、要求定義と並行して行う様を表しています。



図3 要求の品質を上げるための開発ライフサイクル

　要求定義とテストシナリオ作成を同時期に、反復的に行うことによって、すべての要求定義が完了するタイミングが、従来のやり方に比べて遅れるとしても、その効果はそれを補って余りあるものとなります。テスト可能であるためには、要求に矛盾点がなく、あいまいさもない状態でなければなりません。ですから、テストシナリオを考えたときに、合否の判断基準が明確ではない場合は、要求としては不適切だと判断し、見直すことができるのです。

　このようにして、あいまいさがなく、高品質な要求仕様を定義することができれば、現状のオフショア開発で直面している問題のかなりの部分を解決することができますし、さらにいうと、そのような要求仕様の定義をすることで、わざわざオフショア開発をするまでもなく競争力を持つことができるはずです。もちろん、すべてのソフトウェア開発プロジェクトでこれが実行されれば、またしても価格競争に陥ることになるかもしれませんが、幸か不幸か、まだまだオフショア開発以前のところでの改善ポイントがありますから心配には及びません。

　今回は、開発ライフサイクルからのアプローチによって、ソフトウェア要求の問題を改善し、オフショア開発が行える要求定義を行う、という内容でしたが、実際にどのような要求定義（要求開発）を行えばよいのかというより実践的な内容については、また別の機会にお伝えできればと思います。

　次回は、「コンポーネント再利用できていますか？」というタイトルでお伝えする予定です。