いま一度オフショア開発を考えてみる

オフショア開発と一言で言っても、オフショア開発が始まって既に20年を超え、初期のころと現在ではオフショア開発の在り様は大きく変化している。
これまでの経験をもとに、今後オフショア開発をどう考えていくかの参考になればと思い、以下を記してみます。
 

オフショア開発は何故選ばれる?

企業は何故オフショア開発を行うのか。
ITに関連する企業の50%以上がオフショア開発を何らかの形で活用されたとされる現在、いま各企業は何故オフショア開発を選択しているのか。
最も普遍的な理由としてコストメリットの追及があります。
単純に人月単価で1/2や1/3と言われることが多いが、実際はそれほどのコスト削減効果があるわけではないことはやってきた会社は知っていると思います。
コミュニケーションコストが多く必要となり(出張等も含む)、品質維持にかかるコストも多く必要となり、また受け入れ時には気づけなかった様々な不具合に対応する追加コストも馬鹿にできない。
気が付いたらトータルコスト、期間ともに想定以上に嵩んでしまったという案件はかなりの数に及ぶと思います。
その間、自社の社員にはオフショア対応リスクが襲い、疲弊して離脱につながるケースも少なくない。
そこで期待ほどのメリットが本当に得られているのでしょうか。
これを出来ていると答えられる会社はオフショア開発を正しく理解し、オフショア開発を前提としたさまざまな準備が正しく行えている会社と言えます(ここにたどり着くまで様々な苦労を重ねたことと思うが)。
ただしそういう会社ばかりではなく、期待通りにはいってない、もしくはメリットをデメリットが上回っている、という会社も少なくないのでは、と推察しています。
 

よくある勘違い

オフショアベンダーのサイトを見ているとよく「日本品質」的な謳い文句を見かけます。
これについてはいつも違和感を感じています。
「日本品質」っていったい何でしょうか。
日本のベンダーが何か特別なことでもしているのでしょうか。
これまで30年以上この世界にいるがそんな対応を見たことが無い(逆に意味のないドキュメント作成をたくさん見てきたが…)。
それとも日本人技術者が特別優秀なんでしょうか?
申し訳ないがそのようなことは決してないと思います。
なのにこの謳い文句はいつの時代も存在し、今日も多くのサイトに書いてあります。
契約をするときに品質要件をすべて握っているわけだから、仮に成果物がその通り出なかった場合、行うべき品質維持対応が行われていないか、オフショア開発企業にその対応能力が無いということとなり、それがその企業の実力というだけの話です。
確かに品質対応がきちんとできる企業では何か差別化として言いたくなるのはわかりますが、日本国内企業でも品質対応が不十分な企業は普通にありますし、その逆に非常にしっかりやっているオフショア開発企業も存在しています。
なので日本企業が特別優秀なわけでも、オフショア企業が何か劣っているわけではありません。
それぞれの会社の実力を正しく評価して、善し悪しの話かと思います。
 

それでも後を絶たない品質問題の現実

しかしオフショア開発の現場で多くの品質問題が発生しています。
これは現実に起きています。
ではなぜこれが起きてしまうのでしょうか。
一つの理由に収まることはありませんが、多くのケースで起きているのはゴール認識の差だと考えています。
特にコミュニケーションをドキュメントベースで行う場合にその傾向が強い気がします。
必ず設計書でのやり取りは不可避として存在しておりますが、その設計のゴールが元々の要件達成であるという点からぶれてはいけないと思いますが、様々な場面にてそれがぶれてしまっているために起きていることと思います。
要件として「***が出来ること」となっていた場合に、これを達成するために複数のステップを想定したフローを設計し、それぞれのステップを個別に設計していくと思いますが、先ずそもそもこの要件のキャッチアップに問題があるケースが思いのほか多いと感じています。
そして、いくつもの設計書が作られていく過程で、細かいアンマッチが作られてていってしまう。
全てが完璧な推理小説のように結び付けられれば良いですが、実際は環境や実行状況、予期せぬ障害などに引っ張られ、だんだん目的達成から課題克服に近視眼的に目線が足元になってしまい、そんな中設計書上に存在する細かなアンマッチが原因となり結果差異を生んでしまっているかと思います。
また気づけば開発は終わっても当初のゴール目標がクリアされず、なんていう現場も存在しています。
もちろんオフショア側の単純な力不足というケースも少なくありませんし、どんなことでも「出来ます」と答えるオフショア側の問題もあります。
 

オフショア開発に欠けているもの

近年ではオフショア企業も開発プロセスにおける上流工程への参画を強くアピールしてくることが多くなりました。
中規模を超えた企業のほとんどが漏れなくその傾向にあります。
確かに単に機能設計という部分だけをみるとそれもアリなのかもしれません。
実際ある程度までは設計対応できるエンジニアをいくつかの現場で見てきました。
ただしそれなりの規模を持つシステムにおいては基盤開発や機能概要の設計などで、十分なアウトプットをできるエンジニアを見たことが私はありません。
これは多くのオフショアエンジニアが経験値よりネットや座学によって得た知見をもとに仕事をしているからだと思っています。
オフショア開発を行う国はITの対応キャリアがまだ浅いという現実があります。
なので「培った」と言える部分がまだ乏しく、知識は基本的にはネットや座学で得たものが中心となっています。
システムには開発に掛けた期間以上に長い運用の期間が存在ます。
その運用時に起きる様々な出来事を対応することで蓄積されるものが少なくありません。
これらが生きた経験と言えるもので、貴重な記憶となります。
日本の昔から続くIT企業では上司や先輩より経験に基づく教育的指導によって、次の世代に蓄積されていきます。
これらが重しとなって開発するものに「深み」が生まれます。
この「深み」こそがオフショア開発には欠けている部分だと常々感じています。
なので彼らとの会話の中心は、要件に対し「こうすれば出来る」というスタンスであり、「こうすべきである」とはならないのです。
また重しに慣れていないオフショアエンジニアの多くは、小うるさい日本人技術者の指摘に対し「この方が効率が良い」という言い訳をしてこのことにあまり向き合おうとしません。
この傾向は最近の日本企業でも若手エンジニアにも当てはまるところがあります。
今後オフショア開発企業でも運用や保守といったシステムのライフサイクルに付き合う技術者が増え、そのような経験値が蓄積されてきたときに、このことを本当の意味で乗り越えられるのかもしれません。
またこのことは所謂老害と紙一重でもあるので、老害とならぬように注意が必要ですね。
 

オフショア開発とどう向き合うか

ではオフショア開発とどう向き合っていくことが望ましいのでしょうか。
私はこれからもオフショア開発は積極的に活用すべき、と考えています。
コストメリット、体制確保(技術確保も含む)という二大IT課題をやり方次第で高次元で両立可能と考えているからです。
ただしそのために上記に記したような「足りていない」ところを正しく理解し、その部分へのフォローを手段として用意することが極めて重要です。
なのでオフショア開発への丸投げは失敗リスクが高すぎて到底お勧めできません。
オフショア開発とは出す側にもそれ相応の対応体制と準備が必要なのです。
またオフショア開発企業には日本法人があるから、ということがよくありますが、このことは案件の成功にあまり大きな効果はありません(伝票処理は楽になりますが)。
オフショア開発を成功に近づけるためにいくつかの秘訣が存在します。
その秘訣とは何か、の前に先ずは何故オフショア開発を行うのか目的を明確に定め、その目的達成に必要な体制。役割を十分に検討し、それが自分たちにとって対応可能なものであること、そしてオフショア開発会社がその開発に適う相手か、についてじっくり吟味してオフショア開発の実施、オフショアパートナーの選定を判断すべきです。
もしこれがよくわからないときなどは、オフショア開発を実際にやっている企業から教えを乞うことは現実的な対応策と言えます。
聞ける相手がいなければ弊社にご相談いただいても構いません。
オフショア開発が本当の意味で効果を発揮し、成果につながるまでにかかる時間と労力はかなりのものと言えます。
少しの教えでも年単位で苦労する時間の削減効果が期待できるかもしれません。
 

さいごに

こうやって書いてみると、20年前と考えることは何も変わっていないことに気づきました。
現在のオフショア開発はスピード感があり、プロジェクトをサポートする様々なツールがあり、以前と比較し対応レベルはかなり上がっていると思います。
様々な対応がまさにダイナミックに行われ、高度な案件を対応するオフショア開発企業も増えました。
しかし多くの案件においてオフショア開発故に横たわっている課題や、本質的な不足はあまり変わっていません。
やはりこの課題を克服するメソッドの有無が成否を分けていると言えます。
我々としてはこの課題への取り組みに寄り添える存在を目指していきたいと思います。