【失敗事例から学ぶ】オフショア開発のマネジメント心得
株式会社Enlytのベトナム側開発拠点、SupremeTech Co.,Ltd.の上木です。
さて今回は「オフショア開発の失敗から学んだ成功体験」というお題をいただきました。
私が入社してこのかたクライアント様やパートナー企業様のご助力もあってなんとかどのプロジェクトも燃やさずにやってまいりましたが、前職現職と5年ほどオフショア開発に関わってきた中で小さなトラブルは枚挙に暇がありません。
オフショア側にせよ、クライアント側にせよ、人間が運用する以上失敗からは逃れられないわけですが、このブログの読者は後者を想定しているので、今回はクライアント側（発注者）が犯しがちなマネジメントに関わる失敗事例を２つご紹介いたします。
なお実際にあった話をそのまま出すわけにはいかないので、趣旨が損なわれない程度に脚色しています。
目次
オフショア開発に関わる２つの失敗事例
失敗事例①：個々の能力やモチベーション等、チームメンバーの状況を把握できていない
「エンジニアのレベルが低い！」という相談が…
オフショア開発を試みた結果、エンジニアの実力に不満を感じた経験のある方は少なくないと思います。
このプロジェクトではクライアントと弊社のエンジニア数名とがチームを組んでソフトウェア開発を行っていましたが、あるエンジニアのレベルが低く、彼に依頼したタスクだけが終わらないという相談がありました。
確認したところ、そのエンジニアは一緒にアサインされていた他のエンジニアと比べて経験が浅く、作業効率が良くないことが確認できました。
もちろんエンジニア自身も日々スキルを磨き実力の向上に務める必要がありますし、オフショア企業として教育を主導する責務があります。
その意味でこの件はスキルや教育の問題と捉えることができるのですが、一方で、実はマネジメントの問題としての側面もあると見ています。
原因はマネジメント側の状況把握不足
弊社でプロジェクトチームを組む際、原則としてエンジニアだけでなくプロジェクトマネージャー（PM）やビジネスアナリスト（BA）といったマネジメントサイドを担うメンバーのアサインもお願いしています。
日本のIT業界でPMの役割は開発の進捗管理だけでなく、クライアントワークや収支管理を含むプロジェクト全ての管理に責任を持つことが一般的ですが、ベトナムのIT業界におけるPMは進捗管理とチームメンバーのモチベーション管理に特化し、クライアントワークや要件定義はBAが担う役割分担となっています。
このプロジェクトでもPM/BAのアサインをお願いしていたのですが、予算の都合もあってマネジメントサイドはクライアント側が全て担当することになっていました。
そこで改めてクライアントとチームに状況をヒアリングした結果、個々のエンジニアの能力を測ることなく、全員に同じ分量・難度のタスクが均等に割り振られていたことが判りました。
実力の異なるエンジニアに等分したタスクを振れば、結果に差が出るのは必然です。
エンジニアの管理は現地PMやBAに任せるのがベスト
オフショアに限った話ではありませんが、エンジニアは量産型クローン兵ではないので、例えどんなにスキルを上げたとしても全員が均一な生産性を実現することは不可能です。
故にチームで成果を出す必要があり、そのためにはエンジニア１人１人の能力、性格、体調、モチベーションを加味した上でマネジメントすることが大切になります。
しかしオフショア企業との協業経験が豊富なPMでもない限り、海外のエンジニアに対してそこまで踏み込んでマネジメントすることは至難の業です。
１人１人強みの違うメンバーで最大のチームパフォーマンスを達成できるようエンジニアの管理を現地のPMに任せつつ、クライアントとのコミュニケーションをBAを通して行う体制がオフショア開発におけるベストフォーメーションと言えます。
失敗事例②：過剰なマイクロマネジメント
最大のリスクはチームのモチベーション低下
弊社で開発を行う場合、基本的には準委任契約（ラボ型開発）をお願いしています。
準委任契約は成果ではなく稼働に対して課金されるため、１分１秒でも無駄にしたくないという心理から、エンジニアの細かな作業報告をクライアントから求められることがあります。
もちろんオフショア側には稼働状況をオープンにする義務がありますし、クライアント側としても管理を丸投げしていては問題の検知も軌道修正もままなりません。
しかしその一方で、過剰に細かいレポーティングにはデメリットがあることも分かっています。
まずリスクとして挙げられるのは管理コストの増大で、記録・報告するための時間を開発の時間から捻出する必要が出てきます。
しかしこの点は、本当に必要なことであればコストを払ってでも行うべきだと考えます。
それよりも重大なリスクとして考えているのはモチベーションの低下です。
マイクロマネジメントを求めるということは、（意識しているかどうかに関わらず）開発チームの自律性を信用していないという意思表示になります。
するとそれはチーム全体の士気低下に繋がります。
やらされ感が出てしまえば主体性やオーナーシップを損ない、積極的な提案や建設的な問題提起がなくなって言われたことだけを行う（そして言われなければやらない）チームに成り下がる恐れがあります。
「毎日10分単位で誰が何をやっていたか報告してください」その真意と解決策は？
あるクライアントから全エンジニアの稼働を10分単位で報告するよう求められた際はその点を踏まえて膝を突き合わせて話し合ったのですが、よくよく話を聞いてみるとクライアントの現場担当としてもそこまで細かな報告は不要と考えていたが、上長からより効率的な稼働のために改善できることはないかと宿題を出されていた状況でした。
現状を計測することで見えるものもあるのは確かなので、１週間限定で10分単位の稼働を記録することで合意しました。
チームにも計測の目的と期限を明確に説明できたおかげでモチベーションに支障をきたすことなく、測定結果をもとに会議体のスリム化につなげることができました。
オフショア開発を成功させるポイントとは？
オフショア開発成功のポイントは「相互理解」
異なる２つの失敗事例（後者は未遂）ですが、共通して得られるマネジメントの心得があります。
それは「相手を人として見る」ということです。
個々の実力を見ることなくタスクを割り振っても期待した成果は得られません。
一挙手一投足を監視された上で細かく指示されて気持ちよく働けるでしょうか。
相手を自分と同じ人間と見て接していれば、避けられたかもしれない失敗です。
クラスメソッド株式会社が提唱する「モダンオフショア」の中では、オフショアメンバーを「顔の見えないリソース」ではなく「仲間」として見るよう指摘されています。
”現地の開発者を単なる開発リソースとして考えてしまいがちです。しかしながら、プロダクトを開発しているのは数値化できるような単なるリソースではありません。それぞれ個性も違う1人の人間であり、同じ目的のために集った仲間です。”
モダンオフショア開発のすすめ
会社や立場、国籍が異なる上に物理的にも離れた場所で働く人達と同じオフィスで働く同僚とを同様に扱うことは、意識しなければ難しいものです。
また、オフショアチーム側もクライアントの置かれている状況や立場を理解して配慮や提案を行っていく必要があります。
そのためにもお互いに用件だけでなくその背景やゴールを共有し、立場や役割をリスペクトしあえる関係を育みながら、互いのできることを確認して適材適所を図ることが、オフショア開発を成功させるポイントであると考えています。
プロジェクトマネジメントの手法やツールも成功のための大切な要素かもしれません。
しかし手法もツールも人間が使う以上、マインドセットが全てのベースになることは論を俟たないと思います。
ナイーブな話になってしまいましたが、オフショア企業との協業で課題を感じている方々のヒントになれば幸いです。
Enlytについて
株式会社Enlytはベトナムに開発拠点SupremeTechを持ち、これまで50以上の開発プロジェクトを行ってきました。ベトナムと日本のグローバルなチームで、数多くのプロジェクトを成功に導いてきました。
Enlytのオフショア開発は、アジャイル・スクラム開発を採用しています。コミュニケーションの透明化を意識してそれぞれの役割で責任の範囲を明確化しています。クライアントも含めたワンチームとして、フラットな関係で開発を進めることができます。
お客様の納得のいくまで、共に開発させていただき、アイデアを最高のかたちにサービス化いたします。
オフショア開発についてのお悩みやご相談がございましたら、下記ボタンより気軽にお問合せください！
