オフショア開発において、開発者に対しWhyを伝える事はとても重要です。
では、Whyとは何か。
日本人技術者が、オフショア開発チームへ伝えるべき”Why”を正しく理解していないケースが多いです。
Whyを伝えてくれと言われても…
Whyは状況によって異なりますし、立場や視点によっても異なります。
当たり前のことですが、相対的なものだから難しいのかも知れません。
オフショア開発経験が長い日本人メンバーは、初めてオフショアチームと対峙する日本人技術者に対して、下記のような依頼をします。
「オフショア開発メンバーとコミュニケーションする際には、Whyを伝えてください」
「Whyが伝わっていないと、オフショアメンバーは思考停止してしまいます」
そのとおりですね。これ重要なんです。
でも、Whyを伝えろと依頼された技術者は、オフショアチームに何を伝えれば良いのか、これだけでは理解出来ないのです。
リアルに想像出来ないと言った方が正しいのかも知れません。
なぜ、Whyを伝えなければならないのか
「Whyを伝えて欲しい」と言われたときに、何を伝えればよいのかよく分からない。
そうですよね、最初はそうだと思います。
だから、「なぜ、Whyを伝えなければならないのか」を考えてください。
誰に伝えるの？ → オフショアメンバー
なぜ伝えるの？ → 開発をスムーズに進める為に。。ですよね？
そうか、じゃあ、Whyを伝えないと開発がスムーズに進まないって事ですよね？？
なぜ、スムーズに進まないの？ → 思考停止するから
なぜ、思考停止するの？ → どう考えれば良いかわからないから
「どう考えれば良いかわからない」
これがポイントです。
Whyが伝わっていないと、オフショアメンバーは、どのように検討すれば良いのかが分からなくなります。
その結果、何がオフショア側でも検討すべきことで、何が守らなければならない仕様(指示)なのか、判断できなくなってしまうのです。
日本側が作成する仕様書が、多くの矛盾を抱えているケースを想像してください。
仕様書に矛盾が多く存在する場合、考え方が伝わっていないとオフショアメンバーは混乱し、その結果日本人の具体的な指示だけを守ろうとする力学が働きます。
日本側の仕様書に発生しがちな問題点に関して、こちらのページ（仕様書を書くということ）に記載しています。
Whyを伝えないと起こること
具体的にイメージしていただく為に、もう少し身近な軽い問題に焦点を絞ってみます。
「要件が変わったので、XXXをYYYに変更する必要があります」
↓
「ZZZ機能のXXXをYYYに変更してください」
こういった事を伝えるケースは頻繁に発生すると思いますが、その際”Why”をキチンと伝えていないと何が起きるか考えてみます。
“Why”を伝えずに、「XXXをYYYに変更してください」と指示をすると、ベトナムメンバーは素直に作業を実施します。
しかし、A機能は修正してくれたけど、B機能は修正してくれなった。もしくは、XXXを変更したことにより、AAAもBBBに変更が必要なはずだけど修正されていない。といったことが発生しやすいです。
それならばと、変更が必要な箇所をすべて洗い出してから具体的に指示をしたとします。(指示をどんどん細かくしていく)
完璧に洗い出せていればそれでOKですが、ベトナムメンバーが担当している成果物(例えばソースコード)への影響をすべて洗い出すのは困難な事が多いです。こういった方法でも対応出来ないことは無いですが、今度は作業を依頼している日本人の工数がかかりすぎてしまい、別の問題が発生します。
「指示するのが大変すぎて、なんの為にオフショアに依頼しているのか分からなくなる」
「モグラ叩き的に対応が必要な項目が発生してしまい、収束しない」
ベトナムメンバーからすると、
「指示されたとおりに作業しているだけです」
でも、日本人からすると
「なんでこんな事もわからないんだ！彼らに頼んで大丈夫か！？」
という事になり、プロジェクトの状況はどんどん悪化していきます。
さらに、
「自分でやった方が速いよね」
という力学が働きだすと、手がつけられない状況に陥ります。
開発中に発生するWhy
開発中に発生するWhyは、下記のように伝えてください。
「要件が変わったので、XXXをYYYに変更する必要があります」
↓つづけて
- 「なぜなら、日本人間のコミュニケーションミスでAAAをステークホルダーに事前に確認出来ていなかった為です。申し訳ないんだけど、修正してくれる？」
- 「なぜなら、AAAという想定で設計を進めていたけど、BBBのケースに対応出来ていなかった為です。ちなみにベトナム側ではどう考えてた？」
といった話をした方が良いです。
まず結論”What”を伝え、続けてなぜなのか”Why”を伝えます。
上記の例の場合、なぜ要件が変わったのか、ちゃんと説明するということです。それにより、「どう考えれば良いのか」を明確にします。
よく考えれば人間として当たり前のコミュニケーションなんですが、こういったコミュニケーションが出来る技術者は少ないと感じています。日本人間でやり取りする場合ははっきりとは口にしなくても良かったような事であっても、具体的に話す必要があります。
責任の所在を明確にするのもポイントです。
1.のように原因が日本側(ベトナム側ではどうしようもない)の場合、素直に「申し訳ないんだけど…」と話をした方がスムーズに進みます。
2.のように日越双方考慮が足りていなかったような場合は、責任の所在は日越両方にあると考えます。この場合、ベトナム側ではどう考えていたの？どうするつもりだったの？と聞いてみることが重要です。そうすることで、思わぬ回答をもらい日本側の考慮不足に気がつくケースも多々ありますし、ベトナム側の自走を促すことにも繋がります。
プロジェクト立ち上げ段階のWhy
続けて、プロジェクト立ち上げ段階に、”Why”として何を伝えるべきでしょうか？
こちらも、「どのように考えれば良いのか」を伝える必要があります。
イメージとしては、The Agile Inception Deckが良い参考になります。表題は”The Agile”とアジャイル開発的な表現になっていますが、アジャイルだけではなく、大規模ウォーターフォール開発などでも基本的に適用可能な考え方だと思っています。
“Why”として特に重要なのは１枚めのスライド
「我われはなぜここにいるのか(Why Are We Here?)」
です。
私がプロジェクト立ち上げ段階でベトナムメンバーに”Why”を伝える場合、下記のポイントを意識しています。
- 日本人関係者なら当然認識している前提知識
- 現在のビジネスの状況と戦略的な背景
- なぜこのプロジェクトを立ち上げたいのか(Why are we here?)
これらの事をなるだけ端的に説明します。短ければ短いほど良いです。パワーポイントやKeynoteで数枚程度にまとめるイメージです。
細かい事は記載する必要ありませんし、ベトナムメンバーも別に細かい点が知りたいわけではありません。
「本当にやりたい事はなんなのか？」
それが知りたいのです。
優秀なメンバーであればあるほど「本当にやりたい事を伝えてくれればもっと貢献出来るのに」と心の中で思っています。
当たり前ですが、これらの事をキチンと伝えることで、ベトナムメンバーの視野を広げてください。
