オフショア開発に関係しているとよくオフショア開発は品質が十分ではない、という認識を持った人に会う。
ネガティブな印象を持っている人は一度以上は痛い目を見ている方がほとんどだろう。
私もかつてはそういう一人だった。
オフショアで行う開発では多かれ少なかれ、何らかの品質問題が一度は発生する。
これにどう向き合っていったかを記してみる。
それは中国で始まった
私が本格的にオフショア開発に関わったのは中国が始まりでした。
請け負った案件がコスト的にも期間的にもかなり難しいオーダーを突き付けられ、プロジェクトの実行計画段階で当時の社長と困り果てていた私を見越して、既に顧客指定によりオフショア開発を使っていた同僚がオフショア開発を提案してくれました。
以前に韓国の企業となんちゃってオフショア開発をやっていた私はそれほどオフショア開発に抵抗も無く、他に解決策がなかったのこともあり、社長共々この提案に飛びつきやってみようとなりました。
早速同僚に使っていたオフショア企業とコンタクトしてもらい、早々に中国に向かいました。
現地で開発にあたっての協議を行い、初めての本格的オフショア開発がスタートしました。
当時はまだ細かい取り決めの重要性への認識が双方甘く、また社内で開発していたプロセスのまま進めていきました。
中国側からの報告は計画通り、大きな問題はない、QAも順調に消化できている、というものでした。
次第に完成物が上がってきて評価を始めると、開けてびっくりという状態。
関わっていたメンバー全てで問題点の整理を行い、指摘情報として中国側に伝え、オフショアあるあるが大量発動されました。
私を含めた数名が昼夜問わずSkypeでのチャット連絡に張り付き、様々なやり取りを行いました。
すると次第に起きていることが見えてきました。
そもそも目的を把握できていない
中国側のエンジニアにはこの案件の目的が何なのか、達成すべき目標が何なのかがほとんど伝わっていないことがわかりました。
今思えばこの言葉に尽きるが、当時はそのことからくる現状把握ベースによる不足が何かが判っただけの状態でした。
また細かいレベルであまりにも多くの不具合が発生し、同じ目的のコードの亜種がいくつも作られていました。
そう、この時初めて気づいた核心は、我々はシステムという大きな塊を作りたかったが、彼らは設計書に書かれたプログラムを作っただけだったということ。
なのでゴールに対する考え方が全く異なっており、この瞬間にオフショア開発の実態を痛感したものでした。
その後、このギャップはオフショア開発を行う際に一番ケアしなければいけないものとなりました。
襲い掛かるバグの波
その上、数々のあり得ないバグのオンパレードでした。
次々と押し寄せるバグの波に完全に飲まれていました。
これはなぜ起きるのか規則性がなく、また想像困難な状況で突発的に発生していました。
しかもそのバグを発生していたのは中国でもエリートだけが通う一流の中の一流大学を卒業したような秀才達でした。
この状況には当時お手上げ状態となり、これらを防ぐためにすぐできる打ち手として、受け入れ体制を強化し、受け入れ試験を徹底的に行うことでした。
また同時に設計書に対し手を入れました。
気付くだろう、良きに計らってくれるだろう、常識的に判断すればわかるだろう、というものを探り、誤解しないように明示的な記載となるように手を入れました。
文字主体の説明個所にできるだけ絵を取り入れたりもしました。
少し経つとこの活動が効果を出し始め、少しずつ事態は沈静化していきました。
しかし足元を見ると今度は社内のメンバーが疲弊しきっていました。
面倒なコミュニケーション
こうして中国でのオフショア開発は設計書記載への気配りと、受け入れ態勢の強化と慣れによってこなせるようになっていきました。
しかしその間に失った仲間は数知れません。
ただ中国オフショアへの対応策ができたと当時の私は勘違いし、やっていけると信じていました。
その後も中国オフショアを継続し、同じようなやり方で成果を上げていきました。
何も原因分析などができていないまま、対処療法の効率化だけなのに、愚かにもこれで乗り切っていけると思っていました。
そんなある日、中国オフショアで事件は起きます。
中国春節を境に多くのエンジニアが他社への引き抜きにあい、主要メンバーの多くが抜けてしまいました。
せっかく出来上がった来た体制でしたが、属人性が高かったため、一気に安定感を失い崩壊の土俵際まで追い詰められました。
これも一種のチャイナリスクと捉え、1社依存をやめ中国国内に複数のパートナーを構築し、同時期に当時フロンティアと言われていたベトナムにも複数のパートナーを構築しました。
中国のパートナーは元々のパートナーとどこも同じようなレベル、やり方、ノリでした。
おかげで非常にやりやすく、私としては何の抵抗も無く受け入れできていました。
一方、ベトナムのパートナーは言葉が通じにくく、一つ説明するのも大変労力のかかるものでした。
その上、コミュニケーションは必ずコミュニケータを通さなくてはならず、尚且つ伝えたものは必ずベトナム語に翻訳して各メンバーに伝えられていたため、ここまでにかかる時間コストもばかにできないな、と思ってました。
この時中国のパートナーはリーダーやコミュニケータだけではなく主要なメンバーも片言の日本語でコミュニケーションができていました。
またメール等の連絡も簡単なものなら直接やり取りができていました。
そのためベトナムスタイルを非常に煩わしく感じたものでした。
成果物に大きな差
少し時間経つとそれぞれのパートナーからそれぞれ成果物が提示されてきました。
中国のパートナーのものは良くも悪くも想像通りでした。
想定外のバグも漏らさず入れてくれています。
これも含め、何の違和感もなく受け入れできてしまいました。
少し遅れてベトナムのパートナーも成果物を提示してきました。
私はこれを見て驚きました。
完璧ということはありませんが、想像をはるかに超える完成度だったのです。
ちょっとした衝撃とも言えるほどのショックを受けました。
確かにここまでやるのにかなり面倒なやり取りをたくさん行いました。
成果物ができるまでにかなりの時間を使いました。
これまでのオフショア経験のおかげで、質の高いコミュニケーションができていたのかもしれません。
成果物ができた後は、少し指摘修正を行う程度で済み、トータルではかなり時間短縮につながりました。
違いは何だったのか
では中国パートナーが単純に劣っていたのでしょうか？
そのようなことはないと私は思います。
私が接したパートナーは幸い中国・ベトナムとも優良企業でしたので、働く社員も一流大学を卒業しそれなりのキャリアを積んだ人たちやこれからキャリアを重ねていくような有望な人たちでした。
事実難解な仕様を要求してもどちらのパートナーもそれらを高次元で実現してくれました。
では何が違いとして存在していたのか。
それを私はベトナム出張中に見ることになりました。
そのベトナム出張中ではいつものように仕様協議を終え、その後別の打ち合わせのため別室へ移動し、その打ち合わせを行った後元の会議室に戻ってみると、先ほど仕様協議を行ったメンバーが対応協議をしていました。
使っていたドキュメントは私が提示した日本語ドキュメントがベトナム語化されたもので、ところどころに吹き出しなどが追加されたものでした。
それを彼らは私に恥ずかしそうに説明しました。
日本語のわからないメンバーがほとんどで、ベトナム語化したドキュメントで仕様協議の内容を伝えていると。
また途中質問や説明中に話された注釈などを吹き出しにしているとも。
その他メールやQAも同様にやっており、かつ彼らのほうでマスターとなる翻訳版設計書が整備されていて、ここにアップデートを追記してメンテナンスがしてあるとのことでした。
当たり前に感じることかもしれませんが、この活動こそがミスを軽減させていたのです。
間違えにくい母国語で内容の協議をし、結果をドキュメントにしているのでした。
思えば中国では仕様協議の際に日本語のわかるメンバーを中心にやり取りしてますが、メンバー全員が日本語ドキュメントのまま協議に参加し、対応協議の際も日本語ドキュメントで話をしてました。
このことが意味しているのは、日本語の理解が各メンバーへ依存されている、ということです。
これであの想定外のバグが何故出来ていたのかを激しく理解しました。
あのバグの多くは不十分な日本語理解の賜物だったのです。
ベトナム人では漢字が読める人が超少数派となり、この一見デメリットに見えることがメリットというか強みにできていたと言えると思います。
悲しい現実だが
このことは中国・ベトナムの各パートナーに話をしました。
中国のパートナーでこのことを真摯に受け止め対応に取り入れたところは残念ながらありません。
効率性の名のもとに顧客メリットが何かを考えるという基本的なところに行っていないのでしょう。
今日も変わらず日本語ドキュメントで話をしています。
中国国内では日本向けオフショアが完全に時代遅れのビジネスになりつつあるいま、日本語理解度はかつてより低下していると言わざるえません。
ベトナムのパートナーでこのことを自身のアドバンテージとして高めていくための活動に取り入れたところも残念ながらありません。
日本顧客がどこも日本語のわかるSE を希望する、とのことからエンジニアのほとんどに無理やり日本語教育を行っています。
これは中国でもかつてよく見た光景です。
いずれベトナムも自身のアドバンテージを捨て、目先の顧客要望への対応をしていくのでしょうか。
また日本の各企業もオフショアエンジニアに日本語を求めるのはそろそろやめてはいかがでしょうか？
日本語はコミュニケータや一部の管理層に任せて、エンジニアには技術力を高めてもらうほうがメリットがあると思うのですが、、、
結局のところ品質問題とは
オフショア開発の品質対応に関しては不十分な企業が多くあることは事実として存在します。
実力不足と言われても仕方のない企業も少なくないと思います。
ただコミュニケーションの在り様や対応方法を改善できれば、日本語の壁をどうクリアするか、だけではなくメンバーの流動性に対する備えも同時にできることになります。
品質を高めていくには、これまで長年培われた対応メソッドが各社にあると思いますが、これが顧客の要求と合致しているのかをいま一度確認していく必要はあると思います。
品質要件をいくつか上げてこの批准を求めると、工数増をいうオフショア企業がほとんどだと思います。
確かに作業が増えるところは理解できるとは思いますが、そもそも品質とは何なのかを考えているのでしょうか？
それは行ったテストの件数でも、掛けた時間数でもありません（これによってカバーされる部分はあるかもしれませんが）。
そのシステムを何故作るのか、何を求めているのか、何をクリアできれば良いのか、などを正しく理解し、そのために必要なものが何かを見定め、最初に品質要件として正しく顧客と合意していれば問題を極小化できると思います。
後で文句を言われないため、的な理由で行う作業はほとんどが無駄なもののような気がしています。
そしてこれはオフショアの課題ではなく、この対応を行う企業すべてにとって取り組まなければいけないものと思います。