|
開発者なら誰でも，周囲の高い評価を得られるように全力を尽くします。ただし，どんな行動が周囲に評価されるかは学校教育や社会風潮の影響を受けます。評価の基準となる価値観はそれぞれの国や文化によって様々です。そのため，複数の国で共同分散開発を行うときに，相手に喜んでもらうために一生懸命に努力したことが全く評価されなかったり，最悪の場合，期待したのと正反対の結果になってしまったりする可能性すらあります。
中国オフショア開発もその一例です。中国開発者は発注者である日本側から高く評価されるために自分の価値観に基づいて，様々なサービスを日本側に提供します。しかし，日本側から見れば，それらのサービスは単なる無駄な機能追加であったり，“報連相”（報告，連絡，相談）意識の欠如であったりするに過ぎないことがあります。こうした場合，自分を否定されたと勘違いした中国開発者と，望むような成果を挙げられなかったと失望した日本側との溝がますます深くなり，結果的に中国オフショア開発が失敗に終わりかねません。
今回は，自己反省になる事例を交えながら，システム開発プロジェクトにおける中国開発者の価値観について紹介します。私が来日した当初，価値観の相違で周囲に迷惑をかけて，何回も怒られた覚えがあります。価値観に対する中国開発者の認識を知っておくことで，彼らの努力を理解し，中国オフショアによる無駄と品質低下を防ぎ，開発プロジェクトの成功につながることを願っています。
優秀なレポートよりも動くコードのほうが評価が高い
中国オフショアでは，日本人開発者から「中国開発者は，機能仕様と機能テスト仕様が全く作成できていないのに，いきなりプログラムを書いてしまいます。そのため，結果的に，手戻りが多くなって開発効率が非常に悪くなります」と言う不満をよく聞きます。簡単そうに思えても実はプログラムの様々な個所に影響を与えかねないような機能を開発する場合，その問題はすぐに浮き彫りになります。
－ 実例：文書より動くプログラムを優先する
「A要素からB要素への自動変換の機能を追加してください」。あるとき私は，とある機能の開発を中国側の開発者に依頼しました。
「はい，わかりました」。
「この変換は，C要素の自動変換を参照すればいいです。簡単に見えますが，いろいろな既存の機能に影響を与えるので，様々な考慮が必要になります。ストーリーを詳しく書いてください」。追加開発によるデグレードを恐れて，私は中国側の開発者に警鐘を鳴らしました。さらに念のために，幾つかの既存機能への影響を例に挙げました。
「はい，わかりました」。
「ストーリーにあわせて，テスト・ケースも書いてください。JUnitによるテスト・ケースの自動化が難しいようなら，Excelでテスト・ケースを書いてください」。
「はい，わかりました」。
翌日，私は進ちょくをチェックするために，Wikiに書いてあるストーリーを確認しました。すると，ストーリーとテスト・ケースは次のようになっていました。
「A要素からB要素への自動変換。C要素の自動変換を参照する。既存機能への影響を考慮する必要がある」。
「A要素からB要素への自動変換ができるかどうか。 Yes/No」。
会話の内容をそのまま複写したようなストーリーとテスト・ケースに不安を感じた私は，中国側の開発者を呼びました。
「ストーリーはまだ終わっていないですよね！ 自分がどの程度理解しているかがわかるようにストーリーを書かないといけませんよ。どの既存機能にどのような影響を与えるかを書かないと様々な考慮漏れにつながります！ テスト・ケースもぜんぜんだめです」。
「教えていただいたC要素の自動変換を動かせば，この機能のストーリーがわかりますから，時間をかけてストーリーを細かく書く必要はないと思います。C要素の自動変換機能を動かしたので，新機能の実装はもう終わりました。ちゃんと動いていますよ！」
---
上のような例は，新卒の中国開発者によく見受けられます。社会人になったばかりのときの私を思い出すと，その気持ちはよくわかります。
大学の演習授業では，レポートを必ず提出しなければなりません。ただし，レポートを提出しても，実際に動くプログラムがなければ不合格になる可能性が高くなります。逆に，動くプログラムを先生に見せれば，レポートが多少大ざっぱであっても，努力と結果が認められて，いい評価をもらえます。こうした成功経験があるため，企業に入社後も，書類よりプログラムの作成に時間を割いてしまうわけです。
残念ながら，私が出会った頭の回転が速くてプログラミング能力が優れた中国開発者の中にも，そうした価値観の持ち主が何人かいます。機能仕様を正しく反映できなくても，すぐにプログラムを修正できる自信があるからです。
課題を出した先生が学生の書いたプログラムをチェックする
中国オフショアの場合，「できました」という言葉に対する日中間の認識の差は，しばしば日本人開発者を困惑させます。中国開発者にとって「できました」というのは「機能仕様を忠実に実装し，機能仕様に書いてある項目が動作しました」という意味で，詳細な単体テストや関連テストなど細かいテストを終える前の段階のことです。
－ 実例：開発者は製造に専念し，結果は要求を出した側が確認する
「今回の仕様は難しくないので，私が整理してWikiページに書いておきました。まず読んでもらえますか？ わからないところがあったら教えてください」。 「はい，わかりました」。
しばらくして，仕様理解の進ちょくを確認するために，彼に声をかけました。
「どうですか？ 仕様を理解できましたか？」
「はい，大丈夫です。」
「それなら，テスト・ケースを書いて実装に着手してください」。
帰る前に，彼から「実装が終わりました。受け入れテストをしてください」と言われました。
仕様に基づいて基本動作を確認すると確かに動いています。しかし，明らかに影響を与えそうな既存機能と結合テストをすると，すぐに不具合が現れ，様々なところで例外エラーが発生しました。
「すみません。テストをしましたか？ 基本動作しかできていないのでは，実装が完了したとは言えません」。
「実装というのは，書いてある仕様をプログラムにすることですよね？ ストーリーの内容についてはストーリーを書いた人が一番詳しいのですから，その人がテストする義務があると思います」。
---
学校なら，課題に対する評価を付けるのは先生であって，課題を完成させた学生ではありません。そうした学生意識によって，開発した成果物に対する評価責任（テスト）は開発要求を出した側にあると考えているようです。
中国開発者のほとんどは，大学で情報科学を専攻しています。しかも，教科書に書いてある理論を信奉する人が非常に多いのです。ソフトウエア工学系の教科書に「設計，実装，テスト」と書いてあるので，「実装とは機能仕様を動くプログラムにすることであり，プログラムの品質管理は別の段階の責務」と誤解している開発者が多いようです。こうした認識は，日本人開発者が求めている「動くプログラムとは，単体テストや結合テストを通過し，一定の品質を備えたもの」と大きく異なります。
