要求仕様のボトルネックを探る-オフショア開発でハッピ−か

   要求仕様のボトルネックを探る

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

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

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

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

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

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

   　しかし、ソフトウェア開発においてはどうでしょうか？ 少
   なくとも筆者の経験、それからほかの経験者から聞き及ん
   だ範囲においては、オフショア開発が成功モデルであるとは
   いえません。むしろ、日本人同士で、国内で開発をする場
   合よりも悲惨な結果を招いていることが圧倒的に多いよう
   です。ここで、成功という言葉を使いましたが、本稿におけ
   る“成功”とは単純に、“ソフトウェア開発プロジェクトを予算
   内で収めること”とします。 
   　もちろん、プロジェクトメンバーのプロジェクト内作業にか
   かる残業代は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 要求の品質を上げるための開発ライフサイクル

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

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