前書き

皆さま、初めまして。

株式会社リバークレイン プロダクツ本部 プロダクツエンジニアグループ ウェビックサービスチーム所属のながうしです。

自社ECサービス【Webike ショッピング】に関するフロントエンド開発・運用保守、また、ベトナムのグループ会社のオフショア開発チームのタスク管理を担当しています。

基本的なチーム編成イメージ

画像のフロントサポートとオフショア管理の間くらい。

今回スタッフブログを書かせていただくにあたり、オフショア開発メンバーと仕事をする際に私自身が心がけていたポイント、業務を通して学んだことを共有させていただければと思います。

それではよろしくお願いいたします。

※前提として私たちのグループは現地のBrSE(ブリッジシステムエンジニア)、Contar(通訳)という役職のメンバーを通して日本語でベトナムの開発チームとのやり取りを行っています。

オフショア開発

オフショアとは?

オフショアという言葉は英語の【offshore】が語源だそうです。ビジネスシーンでは海外(市場)のという意味合いで使われることが多いイメージです。

IT業界で言うところのオフショア開発はシステム開発業務などを海外の子会社・開発会社に委託することを指しています。

なぜオフショア開発を選ぶのか?

オフショア開発については2点のメリットがあると思っています。

1.人件費の安さ

1点目が【人件費の安さ】です

システム開発費用の内訳はエンジニアの人件費が主な割合を占めています。

この人件費は簡単に表すと

エンジニアの単価 × 作業工数 で算出できます。

この人件費は月単位で表すことが多いです。n人月という言葉を聞いたことがある方がいるかもしれません。

これは【エンジニア1人がnヶ月かかる作業量】または【エンジニアn人が1ヶ月かかる作業量】という意味になります。

エンジニアによって作業できる量は違うのでは???と思ったそこの方。貴方のような勘のいい方が私は大好きです。

日本のエンジニアに比べるとベトナムのエンジニアは単価が安く、結果人件費を下げることでコストの削減ができます。

 

2.開発リソースの確保

2点目が【開発リソースの確保】です

日本に焦点を当てた話になりますが、日本国内でITエンジニアが不足しており開発リソースの確保が難しくなっています。

そこでこの問題を解決するためにオフショア開発を採用するという場合もあるようです。

開発の流れ

システム開発を行う際、大まかに

・起案

・要件の定義

・概要設計

・詳細設計

・開発

・単体テスト

・結合テスト

・リリース

上記の工程がありますが、私たちのグループでは基本的には詳細設計~結合テストまでの工程を委託することが多いです。

後述しますが、設計の段階でどれだけ双方の認識を合わせられるか?開発内容が明確になっているか?で後の開発工程や全体のスケジュールの良し悪しが決まると私は考えています。

オフショア開発時に心がけていたこと

私はベトナムの開発チームと仕事を行う際、以下の3点を心がけています。

1.難しい日本語を使わない

これに尽きます。考えなくてもわかるだろう。そう思った方、全くその通りです。しかし慣れるまではこれが1番大変でした。

日本語特有の言い回し(慣用句、遠回りな話し方)をせず何をどうしたいのか?を簡潔に伝えること。1文を短くして会話すること、ゆっくりと話すように意識すること。

この辺りをとくに気を付けました。過去の失敗として、自分の話した内容が実は伝わっておらずシステム開発のスケジュールに遅れが生じた、想定していたものと異なるシステムが開発・納品されてしまったというものがありました。幸いいずれも大事には至りませんでしたが今でも苦い経験として残っています。

この記事を読んだ方が同じ失敗をしないことを願っております。

2.他の人が見ているところで怒らない

日本人からすると「どういうことだろう?」と思われる方がいると思いますが怒り方によっては私たちが考えている以上に深刻に受け取られてしまうことがあります。

それこそ仕事での失敗に対する指摘に対して反省を促す以前に、屈辱的で侮辱的な扱いを自分はされていると捉えられる場合があります。

その中の行為の1つが【人前で怒る(叱責する)】です。

チームメンバーを怒ることよりも助けられることの方が圧倒的に多いのですが、それでも失敗を指摘しなければいけないことがあります。オンラインでの会話やチャットベースでの業務のやり取りを行っているので基本的にはメンバー個人と私の1対1で良くなかった点、今後の改善方法の検討といった内容を話しています。

3.褒める(評価する)時は他の人が見られるところで行う

これは【2.他の人が見ているところで怒らない】の真逆のことになります。

 

良かったところは褒める!以上!!!

 

.......冗談です。失礼いたしました。

ただこれは全くの冗談というわけではなく納品された成果物を確認してとくに品質が良かった時、厳しいスケジュールの中で開発を完遂してくれた時等自分が助かった、開発を依頼して良かった!と感じたものは素直に伝えるようにしています。何かの効果を狙って実践しているということはなく、強いて言えば感謝の気持ちを素直に伝えることでお互いに気持ちよく仕事ができれば良いなというように考えています。

まとめ

国や言葉は違いますが私たちにとって彼らは同じ仕事をしているチームの一員です。チームワークや仲間意識はもちろんですが、「設計が固まっていないけどベトナムに開発依頼をしてしまおう」「とりあえず依頼を投げてみて問題が生じたらその都度対応しよう」「納期が厳しいけどなんとかなるだろう」というような投げっぱなしかつ無責任なことをしてしまうと相手からの信頼を失ってしまう結果になってしまうかもしれません。この投稿を読んだあなたが今後オフショア開発に携わる時に、この記事を思い出して良い信頼関係を築き、良い仕事をしていただければこれほど嬉しいことはありません。

以上、お読みいただきありがとうございました。