はじめに
この記事はラクスアドベントカレンダーの11日目の記事です。
皆さんが技術的なこと書いてる中恐れ多いんですが、私はオフショア開発のコミュニケーション面で気を付けたことについて書いてみようかなと思います。
というのも、社会人2年目でこれからバリバリソースコード書いてやるぜ！！って意気込んでいたところでオフショアのチームに入ることになりました。
好奇心旺盛なのでもはやワクワクしながら始めたのですが、ノウハウがなさすぎるので最初はかなり苦戦…。
なので、これからオフショアやブリッジSEをやる人たちに、どんなことを実践していくと良いのか、
何か伝わるようなものを残せたらなぁ…と思い記事にします。
(どちらかと言えば感想文だと思います。)
弊社のオフショアチームについて
弊社では、いくつかあるうちの3商材にオフショアチームが存在します。
私のチームは日本側で現在4人、現地の10人を超えるオフショアメンバーの管理をしています。
稼働や生産性の管理、案件の供給、納品物の確認などがメインの業務です。
生産性も高い値を保持していて、納品物の品質もぐんぐん上昇しています。
私の先輩、上司たちの取り組みの結果ではありますが、その中で意識したほうがいいことをいくつか教わりました。
その中でも未だに感じる生産性の下がる原因「認識齟齬」にフォーカスを当ててお話ししようと思います。
暗黙の了解？なにそれ美味しいの？
最初に書いたんですが、私はまだ2年目のペーペーです。
そんな私が最初にぶち当たった壁は「コードレビュー」でした。
そもそも自身の携わっている製品のコード規約を1から10まで網羅しているわけではない。そんな状況でコードレビューをするとどうなるでしょう。
そう、コード規約にも載っていない「暗黙の了解」が横から殴ってきます。
規約通りだ！大丈夫！
そう思って通そうとするとこれはこうの方がいいです。みたいなのが出てきます。
そういったものをいち早くキャッチアップするのが最初のハードルでした。
今は引っかかったときに調べるノウハウが自分の中でできたので、なんとか、たまーーーーにコードレビューをしています。
ただ、これはコードレビューに限った話ではないのですが、オフショア開発に関わる人、いや、もはや社会人全員に考えてほしいことがあります。
暗黙の了解なんてものは捨てろ
さっきまでは暗黙の了解を把握するのが大変だ～なんて言っていましたが、今はできるだけそんなものは排除するよう意識するようにしています。
自分が暗黙の了解を作り出してしまうことが多々あるのです。
暗黙の了解っていうものはそもそも日本人的感覚だったり、その場にいたから知っていることだったりで、異文化の人間からするとなんなのそれ！？となってしまうものです。
下手に日本語が通じすぎてしまうことも相まって、認識としてその部分が抜け落ちてしまいます。
そこで私が大事にしていることは一度自分がバカになることです。
小学生になりきる
一旦小学生になってください。
変な意味ではないです。
まず依頼内容を文章化してみます。
不具合の起きている画面の洗い出しをしてください。
下記を実施お願いします。
・全画面の打鍵
・製品Aの全画面の打鍵をリスト化してください。
・リスト内容をこちらでレビューします。
・テンプレートのテスト
・添付したファイルの翻訳をお願いします。
・テンプレートのテストの実施をお願いします。
これが最初に思いついた依頼文です(記事用に内容はそれっぽく書いています)
日本人的感覚であれば「モンキーテストやってどの画面のどの項目を触ったかリストアップして、その結果を渡すんだな～テンプレートのテスト項目書に沿ってテストして、その結果も渡せばいいんだな～」なんて感じでなんとなく始められそうですヨネ。
でも、依頼文に書いていない暗黙の了解が含まれている気がしませんか？
通じないとは限りませんが、そこから齟齬が起きて、いざ返ってきたら「あれ、依頼した内容とちょっと違う…」なんてこともあり得ます。
だから、この文章を小学生の自分が読んだらどう思うかを考えて文章を付け足しましょう。
専門的な単語(技術的な言葉)は調べるしかないし意図が伝わらなくなってしまうので使うのはしょうがないでしょう。
書き換えた文章はこちら。
不具合の起きている画面の洗い出しをしてください。
下記を実施お願いします。
・全画面のテスト
・製品Aの全画面でモンキーテストをしてください。
・テストした画面名と、テストの結果をリストにしてください。
・リスト内容はこちらでレビューします。
・テンプレートのテスト
・添付したファイルの翻訳をお願いします。
・テンプレートのテストの実施をお願いします。
・テスト結果がOKの場合
・ファイルの○○を更新してください
・テスト結果がNGの場合
・ファイルの××を更新してください
・バグチケットを起票してください。
こんな感じです。
明確にどんなことをすればいいのか、してほしいのか、かなり分かりやすくなったと思います。
実際にこんな感じかな～で見えていなかった部分も明確化されました。
一度小学生になって一つ一つの文章に「なにすればいいの？そのあと何するの？」と問いかけましょう。
これで説明不足による手戻りや、確認の工数が一気に削れると思います。
再翻訳をかける
ついつい丁寧になるように物を伝えようとすると、それもまた認識齟齬につながります。
品質向上テストをしていただきたいです。
この文章、パッと見違和感ないんですヨネ。日本人の悪い癖。
依頼というよりは願望です。優先度の高いタスクでこの文言を出すと違和感バリバリ。
英語にするとどうでしょう。
翻訳かけてみます。
「I want you to do a quality improvement test」
再翻訳します。
「品質改善テストをしてほしい」
いや～間違っちゃいないんだけど、依頼として弱い…。
もう少し熱感高めに言ってみます。
品質改善テストを行ってください
これを翻訳。
「Please do a quality improvement test」
再翻訳をすると「品質改善テストを行ってください」
変わらないですね。
意味をとっても、丁寧さをとっても、願望ではなく依頼になりました。
翻訳してからメンバーに伝わることを考えて、先に直訳したらどのような意味合いになるのか考えることも大切です。
一つの文章には一つの意味を
A機能のパフォーマンスの劣化が懸念されているため、検証をして、修正方針をレポートしてください
この文章には3つの動作が含まれています。
例えなので比較的複雑な文章ではないですが、やはり意味を持たせすぎている気がしますね。
こういう文章は箇条書きにしてしまうのがいいでしょう。
・A機能のパフォーマンスの劣化の懸念があります。
・パフォーマンス検証をしてください。
・検証結果から、修正方針をレポートとしてあげてください。
冗長に見えなくもないですが、翻訳は容易になりました。
おわりに
書き終わって読み直してみたら国語の教科書のようになってしまいました。
ただ、自分の言ったことがそのまま伝わらず、意訳になってしまうこともあります。
同じ日本人相手でも意識すべき内容だとは思いますが、
特に、言語の違う人達に正しく伝えて生産性を上げていくための秘訣なのかな～と思う日々です。
自分がオフショア業務をやるよとなってとりあえずネットを泳いでみましたが、あまりこれだ！って記事に出会えませんでした。
私のようにエンジニア歴が浅い人が、オフショア管理をやる！ってなった時の参考に少しでもなればと思います。
もっと力をつけてテクいことを書けるよう精進します。。。