第34回 オフショア成功に必要な「ある特性」
トライアンツコンサルティング
野村隆
2008/2/22
| 将来に不安を感じないITエンジニアはいない。新しいハードウェアやソフトウェア、開発方法論、さらには管理職になるときなど――。さまざまな場面でエンジニアは悩む。それらに対して誰にも当てはまる絶対的な解はないかもしれない。本連載では、あるプロジェクトマネージャ個人の視点＝“私点”からそれらの悩みの背後にあるものに迫り、ＩＴエンジニアを続けるうえでのヒントや参考になればと願っている。 |
この連載では、システム開発プロジェクトにおけるリーダーシップを中心に、「私の視点＝私点」を皆さんにお届けしています。
今回の内容は、リーダーシップトライアングルのCommunicationに関係します。Communicationについては、連載第8回「コミュニケーションはリーダーシップの基礎」を参照いただければと思います。
 |
| 図1 リーダーシップトライアングル。今回は「Communication」に関連する内容を紹介 |
■「まともな日本人」？
皆さんの周りで、オフショア開発は進んでいますか。私の周りでは、最近、オフショア開発を経験したという人が増えています。しかし残念ながら、うまくいかなかった事例が多いようです。
現在IT業界に広がりつつあるオフショア開発の成功に重要なことを、私の経験を基に、リーダーシップトライアングルでいうところのCommunicationという観点から説明したいと思います。
オフショア開発で大事なことといえば、まず「設計書をちゃんと書くこと」です。
よくある悪い例が、お客さまの要求仕様がそれなりには表現されているものの、長々とした文章で、あいまいに書かれている設計書です。例外ケースの記載がない、処理対象のデータボリュームやユーザーの利用頻度などが記載されていないという場合もあります。
これでは、システムの設計書として十分とはいえませんね。そもそもオフショアであっても、国内であっても、外部の組織にシステム開発の仕事を依頼するレベルに達していないことになります。
うまくいかなかった別の例では、設計書における言葉の定義があいまいでした。システム開発においてデータ項目となる「顧客」「お客さま」「取引先」という言葉が同じ意味で使われたり、違う意味で使われたりしていたのです。そのうえ、「顧客」といっても「顧客コード」なのか「顧客名」なのか、明確に分からなかったのです。
私がその点を指摘したところ、担当者はこういいました。「まともな日本人の技術者だったら、そのくらいは文脈で分かるはず」
オフショア先の技術者は、至って「まとも」です。純粋なスキル・経験で見ると、日本人よりも優れている場合が多いくらいです。しかし「日本人」ではないわけですから、「まともな日本人の技術者」という前提条件を満たさないですよね。
このような背景も考慮して、まずは設計書をちゃんと書く、適切な詳細度のレベルで記載して、あいまいさを可能な限り排除することが重要になります。使用言語や環境によっては、UMLなど世界標準の表記法を使うことも考慮に入れた方がいいでしょう。このような設計書改善への努力を怠って、「オフショアはダメだ。できない」と切り捨ててしまっていると、いつまでたってもオフショア開発を成功させることができないのではないでしょうか。
■コミュニケーションで重要なこと
一方、よくいわれるのが、「コミュニケーションの食い違いがオフショア開発を難しくしている」ということです。円滑なコミュニケーションが取れないと、なかなか仕様が伝わらなかったり、オフショア側での作業状況が把握できなかったりと、開発のリスクが高まります。
中国のオフショアでは、オフショア側が日本語をしゃべるケースもあります。しかしインドやフィリピンの場合は、日本の側が英語をしゃべることもあるでしょう。
そうすると語学能力が重要なようにも思えますが、必ずしもそうではないというのが私の意見です。
では、オフショア開発のコミュニケーションでは、何が重要なのでしょうか。この点を解説するに当たり、ERPパッケージを例に取って考えてみましょう。
■ERPパッケージの常識・非常識
欧米では、ERPパッケージはできるだけERPの標準機能（Out-of-Box機能）のみを使い、アドオン（追加開発）を抑えるということが常識のようになっています。欧米のERPコンサルタントにとっては、いかにして標準機能だけでお客さまの業務を実現するかが腕の見せどころなのです。
一方で、日本におけるERP導入プロジェクトでは、お客さまの要求にいかに柔軟に対応できるかが論点となり、アドオンが多くなりがちです。ERPベンダにも、いかに多くのアドオンを実現できるERPパッケージであるかを競っているような側面があります。
つまり、「欧米ではERPの標準機能を使うのが常識」「日本ではアドオンを多く実現することが常識」といえましょう。
ERPがパッケージソフトであることを考えると、テスト済みのERP標準機能を使った方が低コスト、高品質を実現できるという意味で、欧米の常識の方が技術的な視点からは優れているといえるかもしれません。ただ、日本のお客さまが欲しているのはアドオンによる高機能のシステムであるわけですから、このような、いわゆる「べき論」を日本において論じても意味がないことが多いのです。
良しあしの議論は置いておくとして、「欧米と日本とでは常識が異なる」と私は理解しています。
■オフショアのERPコンサルタントvs．日本人プロジェクトメンバー
日本におけるアドオンの多いERPパッケージシステム導入プロジェクトに、設計段階からオフショアのメンバーが参画したと仮定しましょう。
こういう場合に得てして起こることは、オフショアのメンバー、特に「ERPコンサルタント」といわれる人たちが、「こんなに多くのアドオンを実装するのはオカシイ」と日本のプロジェクトメンバーにかみついてくることです。
以下の会話は、私の経験とオフショア経験者から聞いたことを基にした例で、実話ではありません。しかしどこのオフショアプロジェクトでも、以下のような状況になる可能性があると思います。
日本人メンバー（以下、日）「アドオンはお客さまが望んでいること。そもそもプロジェクト開始時に、多くのアドオンが実現できるという理由でこのERPパッケージを選定しているのだから、いまさらアドオンを減らし、プロジェクト開始時点の前提を崩すようなことは受け入れられない」
オフショアERPコンサルタント（以下、オ）「お客さまがアドオンを望むのは理解できる。しかし、お客さまのアドオン要求をいかに減らして標準機能を使ってもらうかが、ERPコンサルタントの腕の見せどころだ。私のこれまでの経験からすると、日本のアドオンの数は尋常ではない。アドオンを減らせば低コスト、高品質となることも分からないのか」
日「日本におけるERPパッケージの使い方自体が、アドオンを前提としてしまっている。大体、プロジェクトがある程度進行した設計段階において、いきなり『アドオンを減らそう』というべき論を展開しても、時すでに遅しなわけですよ」
 |
＠IT自分戦略研究所は2014年2月、＠ITのフォーラムになりました。
現在ご覧いただいている記事は、既掲載記事をアーカイブ化したものです。新着記事は、 新しくなったトップページよりご覧ください。
これからも、＠IT自分戦略研究所をよろしくお願いいたします。
