この記事はMonstar Lab, Inc. Advent Calendar 2016 11日目の記事です。
モンスター・ラボの濱村です。
プロジェクトマネージャーとして、ベトナムでWEBサービスを開発するプロジェクトを担当しているので、その中で思っていることや試行錯誤していることがあるので、その話を書いてみたいと思います。
キックオフでお互いの期待値を共有する
プロジェクトが始まる前に、現地に飛んでキックオフをする際、自己紹介やプロジェクト概要だけでなく、進め方、つまりはマネージャーが何をメンバーに対し期待し、逆にメンバーが何をマネージャーに期待しているのかについて議論を交わすようにしています。
私は比較的細かくマネジメントする方なので、日々の状況を把握したいですし、トラブルに対し原因をうやむやにされることを嫌います。そのため、
- わからないことはその瞬間に何でも聞き、納得できないことは徹底的に議論すること
- 情報は一人で持たずオープンに共有すること
- 体制変更は納得感を持たせるため、各自に確認を取ってから行うこと
をルールとしました。
Rebuild.fmにも出演されているHigeponさんのブログ にあるとおり、マネージャーにも色々タイプがあるので、まず自分がどんなタイプであるかを明示し、その上で互いの最適なコミュニケーションを理解することは大事だと考えています。
私はSlackの#daily-reportというチャンネルで、毎日互いの状況を報告するようにしています。
人事評価に繋げる1on1 MTG
オフショア開発であろうと、プロジェクトで成果を出したメンバーはマネージャーだけでなく会社からも評価をされるべきです。その評価がメンバーのモチベーションとなるわけですから、私は毎月1回30分程度、1on1 MTGを設けてその場で毎月の仕事ぶりをフィードバックするようにしています。
その後、評価をまとめて拠点のCTOに渡します。これが実際に人事評価につながるかはわかりませんが、多少は役に立ててくれるでしょう。
1on1 MTGは評価のフィードバックの場として有効ですが、他にも普段言えないミスコミュニケーションも防ぐことができます。
やはりチャットなどのオンラインコミュニケーションがメインになれば、知らぬ間に誤解が生まれたり、それが火種となって仕事がやりづらくなったりといったことはあります。そういったトラブルを予防するために、互いの考えを理解する場を設けるようにしています。
徹底的な見える化
日本にいるクライアントもベトナムの開発メンバーも、同じツール（Slack, Redmine）でコミュニケーションを行っています。
私がクライアントからどういう依頼を受け、それをどうメンバーに伝えているか一目瞭然ですし、やりとりをオープンにすることで、文脈を理解してもらい、両者との信頼関係も築きたいという意図があります。
オフショア開発によくある話の、離れているから稼働しているかわからない、という不安もSlackのやりとりを見れば解消です。同じチームだからこそ、しがらみなくオープンに議論していきたいですね。
仕事以外の時間を共有する
仕事以外の時間をどこまで職場のメンバーと共有するか、というのは賛否両論ある話ですが、私は特にリモートのメンバーに対しては共有しておいたほうがよいという考えです。
ベトナムからすれば、全く知らないマネージャーが日本からやってきた、しかもやたらマイクロマネジメントしてくる・・というウザさ。笑 ときにイラっとすることもあるでしょう。この場合、互いの人間性や相手の文化への理解をするには、仕事以外の時間を一緒に過ごすことだと思っています。
私の場合はベトナムの女性の日のパーティで乾杯しまくったり、仕事後にベトナムの市街地をバイクで共にドライブしたりすることがあり、短い出張期間でもコミュニケーションをとることはできたかな、と感じています。
日本に戻っても、何気ない様子をSlackの#randomで話すなど、積極的な雑談を心がけています。
日本人に話す1.3倍くらいの粒度で説明する
ベトナムに長く住んでいる支社長と話していた時に、中学生に物を教えるものだと思って話をした方が良いと言われたことが印象に残っています。私たち日本人はハイコンテキストで話をしがちなので、異文化でビジネス背景も異なるメンバーに対しては、日本人と話す粒度より1.3倍くらいで説明してあげるくらいがちょうど良いかな、と思っています。
中学生は物の例えですが、それくらい相手の理解度を意識して話をしなさい、ということなんだろうなと思います。詳細に説明するのは面倒なこともありますが、それで認識齟齬が起きてリリース間際にあわわ、という事態に陥ることを防げると思えば、大したことではないなと思えます。笑
まとめ
だいぶエモい話になってしまいました。
オフショア開発は「大幅なコスト削減」ができるメリットがあると言われているため、人件費の安い海外の開発チームで開発しているという捉え方をしている方が少なくありません。しかし開発チームを立ち上げる際には負担がかかりますし、短期間で見てみればコストは日本でやってみてもそう変わらなかった、ダメじゃん、ということがあるかもしれません。
そのため評価基準をどれだけコストが抑えられたかどうかではなく、自社同様にサービスのKPIが達成できたか、で開発チームの評価を考えるべきだと思っています。同じ目標をクライアントと開発チームで持てれば、良い成果が生まれるのではないか。日本でやるとすれば当たり前の話、海外のオフショア拠点でも同じできることができると思います。離れていてもちゃんと仕事を任せられるように、互いの信頼関係を作ることが何よりも大事だと考えています。
今後やっていきたいこと
私がいなくても徐々に権限委譲し、クライアントと仕事ができるレベルまで、ベトナムチームのレベルを引き上げたいと思っています。そのためには、
- クライアントのビジネス理解
- その場に応じた適切な対応（緊急時など）
が求められるため、より関係を強固にしていく必要があると考えています。
試行錯誤の途中なので、まだまだこれからです。
補足：ラボ契約を前提とした話です
上記の話は請負ではなく、準委任契約（ラボ契約）の話になります。ラボ契約とはオフショア開発における契約形態のひとつで、ある一定期間（半年〜数年）、特定のエンジニアを確保し自身のプロジェクトを担当させる契約形態です。
したがって、これらの話は「期間内に完成物を納品すること」よりも「より良いチームを作り続けて成果をあげること」が主眼となっています。