第2回：オフショア開発を成功させる工夫10点（前半） -ASP SaaSナビ

ASP・SaaSナビTOP > コラム > 第2回：オフショア開発を成功させる工夫10点（前半）

第2回：オフショア開発を成功させる工夫10点（前半）

第1回ではASP・SaaS事業者における自社開発とオフショア開発の相違点について分析してみました。第2回は、オフショア開発を成功させる様々な工夫をご紹介致します。

オフショア開発に関する記事や投稿の多くは日本側の視点から見た意見がほとんどです。時にはそれが少し偏った情報提供になっているかもしれません。この連載では、筆者が今までオフショア開発に関わった経験から感じたこと、工夫したことを紹介していきたいと思います。オフショア開発を導入する時のヒントを得ていただければ、と願っています。

(1)要求仕様書はできるだけ具体的かつ正確に

　オフショア開発では一番よく耳にするのは「仕様」に関するトラブルと不満です。日本側の担当者(日)とオフショア企業側のプロジェクトリーダー(オ)の以下のような会話がその一例。

日：この画面の動作がおかしい。調べて欲しい。
オ：こちらの環境では正常に動作しています。
日：○○○の場合、ボタンを押しても反応がない。
オ：そのようなケースは想定していません。
日：発生しうるケースなのに、なぜ実装しないですか？
オ：要求仕様書には記述がないから。
日：…

日本での国内外注の場合、発注側の要求仕様書に多少の記述不足があっても、受注側のシステム開発会社が仕様書の行間を読んで埋めることが当然のように行われます。なぜなら発注側の企業と受注側の協力会社は長期的な取引関係にあることが多く、協力会社は発注側の業務プロセスを熟知しているからです。仕様書に高度に業務プロセスに関する知識が組み込まれてもそれを読み取って補完することは常識の範疇です。

ところが、オフショア企業の技術者に日本語で書かれた仕様書の行間まで読むことを期待するのは現実には難しいです。このことを意識しない限り、後になって仕様をめぐる様々なトラブルが発生することになってしまいます。

また、日本に限らずソフトウェア開発の世界では、暫定仕様のまま、プロジェクトをスタートさせ、走りながら仕様を確定させていく場合が少なくありません。むしろ、最初からすべての仕様が決定することが珍しい。このことについてオフショア企業も理解していますが問題なのは、それを整理せず、両方で意識の刷り合わせができないまま突き進んでいくことです。プロジェクトの終盤になって、納品されたドキュメントやソースコードを見て気づいた時は膨大な後戻り工数を余儀なく課されることになりかねません。できるだけ上流工程でバグの芽を摘んでおかないと、同じバグでも下流工程になればなるほど修正コストが上がり、特に単体テスト、結合テスト工程になると何十倍にも跳ね上がることは知られています。

では、仕様書の記述に関してどのような工夫を施し、オフショア開発でどのような対策をとればよいでしょうか。

■工夫点および対策

・可能な限り初期段階から要求仕様を固めておく

　実際には未確定部分があってもかまいませんが、きちんと把握して、確定した段階で必　ず要求仕様書に反映します。

・UMLモデリング技術を活用する

　文章だけで細かいニュアンスの仕様を伝えるには限界がある場合、UMLモデリング技術を使い、形式的かつ論理的な表現によって詳細を記述します。また、補足資料として図面、画面コピー、グラフ、サンプルなどを多用すると効果があります。これができると仕様の誤解を減らしたり、オフショアから山のような質問が送られる状況を改善できるでしょう。

・仕様の網羅性を高める

　機能単位の細かい仕様に気を取られがちですが、要件の漏れがないように全体構成を十分に考慮しなければなりません。あらゆる条件や場面を想定し、仕様書にはその全てを記述します。性能目標や負荷テストの要件があれば忘れずに記述した方がよいです。

　注意していただきたいのは異常系処理に関する書き方です。常識だと思って省略すると実装漏れが発生してしまいます。異常系、準正常系の処理を記述せず、プログラムに任せると全体のレベルがまちまちになります。ソースコードの半分以上は異常系処理ということを意識して、異常系の網羅性に配慮した方がよいでしょう。

・優秀なブリッジSEを使う

　オフショア開発においては、ブリッジSEの役割は極めて重要です。プロジェクトの成功はブリッジSEの質に左右されると言っても過言ではありません。オフショア開発におけるパートナー選定の時に優秀なブリッジSEを確保できるかが一つの指標になります。
弊社では日本の大手企業に数年間の勤務経験を持った人材をブリッジSEのとして採用しています。日本企業の商習慣や業務プロセスを熟知しているから国内外注と同じレベルの要求仕様書でも仕様伝達ミスは防げます。

(2)コミュニケーション不足は通信技術などのテクノロジでカバー

　「仕様の誤解」、「進捗が見えない」、「日本の常識が通じない」などの問題の根源はコミュニケーション不足と筆者は考えます。日本国内開発の場合、発注者と受注者との間で上流工程から緊密なコミュニケーションによる意識あわせが頻繁に行われます。何か問題が発生した場合はすぐに担当者を一箇所に集めて会議を開くことも簡単にできます。

　もちろん、オフショア開発でも、発注者とオフショアの受注者との間で意識合わせをしようと努力しています。ところが、この意識すり合わせで重要となるコミュニケーションがなかなか難しいのです。オフショア開発におけるコミュニケーションは国内開発に比べると思った以上に密度や質が落ちてしまいます。原因は以下のように様々です。

・文化的な面

　教育、育った環境などの背景が異なる人間と話すのですから、同じ言語（日本語）で話しても細かいニュアンスやコミュニケーションの流儀が違う場合があります。自分の意図したことが正しく伝わらない時は、国の分化が違うせいにする傾向がありますが、それでは信頼関係に影響を及ぼすことになってしまいます。

・物理的な面

　距離的に離れているから、何か問題があるたびに「すぐに飛んで来い」という訳には行きません。その結果、メールでのやり取りに極端に依存してしまうことになるケースが多いです。

x・発注方法と開発プロセスの面

　日本のオフショア開発では、基本設計は日本側で行い、詳細設計以降はオフショアに発注をするか、詳細設計も日本で行って、コーディング以降はオフショアというバターンが非常に多く、上流工程からオフショアが関与することは少ない。また、単体試験や結合試験が終わった段階で納品物が一気に発注者に上がってくることが多い。つまり、詳細設計の初期と試験後にコミュニケーションが集中しすぎて、その間はお互いコミュニケーションを怠るとブラックボックスになりがちで最後になって大きな問題に発展してしまいます。

上記のような原因でコミュニケーションに限界があることをお互いにしっかり認識して、それをどうカバーするか対策をしっかり考えることが重要です。

■工夫点および対策

・通信技術を活用する

　IP電話などの技術を使って、いつでもテレビ会議、電話会議ができるような環境を整備しておくこと。特に担当者レベルでお互い気軽に直接会話ができると大変有効です。

・共通の開発サーバーを置く

　日本とオフショアの間で共有できるサーバーを用意して、そこでリアルタイムの課題管理システムを実現したり、プロジェクト状況を双方で把握できるプロジェクト管理システムを導入したり、各開発フェーズにおける成果物をいつでも確認できる状態にしたりして、それぞれの担当者が十分にコミュニケーションを図れるようにすることが大切。

・レビュー回数を増やす

　各開発フェーズにおいて最後の成果物が出揃ってからレビューするのではなく、こまめにレビューポイントを置いて、コミュニケーションの場を増やすようにします。そうすると問題を早期段階から発見でき、対策も打ちやすいです。

・上流工程からオフショア技術者を参加させる

　詳細設計からしかできないオフショア企業もありますが、優秀なブリッジSEを抱えるところには積極的に基本設計などの上流工程に参加してもらうことも有効な手段です。
弊社のブリッジSEはお客様と同行しユーザ企業の要件をまとめる能力を持っています。
その結果、開発するシステムを早くから理解し、その後のオフショア開発もスムーズに行うことができる場合が多いです。

(3)品質に対する意識を高める

　オフショア開発の目的としてコスト削減を挙げる企業は圧倒的に多いです。しかし実現するには品質も確保できるという条件付きがあります。納品された成果物の品質が悪ければ日本側で修正するコストが余計にかかってしまいます。オフショア国の安い人件費を活かして、コスト削減の一点張りで品質確保のためにあまりコストをかけない企業は、ふたを開けてみればトータルで結局コスト削減どころかお互い不信感と疲労感だけが残る最悪の結果になったケースがあります。

　特に「日本のお客様は品質に対して非常に厳しい」という意見はオフショア側の現場から聞こえてきそうです。筆者が日本の大手通信メーカーに勤めた時に、大手通信キャリアがお客様だったこともあって、品質に関する考え方、品質の確保プロセスを身に付きました。過剰とも言えるぐらい品質確保には敏感であることを身を持って経験しました。

　一方、オフショア側の品質に対する考え方はどうでしょうか。オフショア開発現場では以下のような会話はよくあります。

日：コードレビューの記録票にはいつも一人か二人しか出ないのはなぜ？
オ：有識者一人によるレビューを行っています。
日：開発チーム全員に共有するべきだと思いますが。
オ：ひとり一人の担当範囲が決まっているから、必要ない。
日：・・・

日：詳細設計のバグ傾向を知りたいからバグ分析結果を教えてください。
オ：バグ分類していないから分析できません。

日：問題が発生しました。再発防止策として机上コードレビューを実施して欲しい
オ：もう問題は修正しました。机上チェックしても工数がかかるだけで、無駄です。
日：・・・

　品質に対する考え方は一日にして習得できるものではありません。日本のやり方をそのままオフショアに押し付けても品質確保するどころか、負担増によるモチベーション低下に繋がりかねません。お互い納得するまで根気よく最適なやり方を見つけるべきです。<