BLOGブログ

オフショア進出ナレッジ
2018.02.27

現場からお届け!弊社ベトナム人エンジニアのスーパープレイ集~BSE編~

こんにちは!
以前、エンジニアのスーパープレイご紹介の記事を公開したところ、「このエンジニアは誰?」「こんなエンジニアと働きたい!」など様々な反響をいただきました。一方「ブリッジシステムエンジニア(以下BSE)のスーパープレイは何かありましたか?」といったリクエストもいただきました。

ということで、今回はこれまで弊社であったBSEのスーパープレイをご紹介したいと思います。

今回も以前と同様にインタビューさせていただいた日本人PMの方にお話を伺いました。
■インタビュー先駐在員様ラボ情報

開発言語 CakePHP、Laravel

データベース MySQL

プロジェクト管理 JIRA

 

- それでは早速ですが、御社ではラボを立ち上げた当初からBSEを入れていたのでしょうか?

はい、立ち上げ当初から1名のBSEに入ってもらっていました。立ち上げ時にエボラブルアジアからBSEをご紹介頂いたこと、これは今思うと本当にありがたい提案でした。結果的に、このBSEの方がラボの業務の半分を担っていたので、彼無しではラボの拡大はあり得ませんでした。彼は日本で8年近く働いていたこともあり非常に能力が高く、一緒に働いていてこちらが学ぶ事が多かったです。

 

- 実際にどのようなところで能力が高かったのでしょうか

彼は日本大手の会社の倉庫管理システムなどをエンジニアとして携わった経験があり、現場レベルでシステム開発のことを理解していたので、色々な要求を仕様にどう落とし込むのかを考えられる能力が高かったですね。

倉庫管理システムは色々な概念があって難しいんです。売上などの金額と密接に関わる事が多い上に、各会社によって独特の概念や業務フローがあったりするので、日本人同士でも理解するのにかなり時間がかかります。在庫でも、引当在庫や有効在庫など、他にも検品など原価管理などとにかく知らないといけないことが多いのです。そういう抽象度の高いシステムを触っていたので、概念レベルの話や複雑なステータスの遷移なんかもスッと理解してくれるのが助かりました。

あまりにも優秀なので、複数の案件を同時に依頼してみたのですが、「やっぱりこれは大変だったかな、、」と思い直し心配になって伺ってみると「日本でやっていた案件のほうが難しかったので大丈夫です」と心強いコメントを貰い、刺激をもらったのを覚えています。もっともっと能力をフルに活かせるような難易度の高い案件をベトナムでやろうという気になりましたね。

 

- なるほど、では実際の業務ではどのようなスーパープレイがあったのですか?

はい、かなり助かったスーパープレイがありました。ラボを立ち上げた当初、私自身BSEはIT知識のある日本語通訳者くらいにしか考えておらず、通訳の仕事を主に依頼していたのですね。ただ、徐々にラボが拡大していくに従って私の管理能力がついていかず、私ひとりにかかる負担がかなり大きくなってしまったことがあります。

 

- 具体的にどんなことがあったのでしょうか?

はい。例えばベトナムにおいての開発ですとエンジニアが開発プロセスを把握していないことがあります。転職が多い為、正しい開発作法が身につかず思い思いのスタイルで開発してしまっている場合があるんです。たとえば、コーディングをしながらデータベースをいきあたりばったりで設計して、出戻り工数が増えてしまったり、なんとか初期リリースまではこぎつけても次回リリースのタイミングで設計変更が多くなりデスマーチ化したり、不明な仕様を確認することなく自分の判断でよしなに作ってしまったり、テスト時にそれが判明してやり直しが多かったり、何日も進捗報告せずに黙々と開発ばかりを進めていて、蓋を開けたら期待したものと違ったり、自分で管理をしようとした分負担がかなり多くなってしまったんです。そこでこのBSEの方にもっとチームを管理してもらうように依頼したところ、作業の効率化が図ることができ楽になったのを覚えています。

 

- 具体的にどのあたりが楽になったのでしょうか?

彼は日本でエンジニアとして開発に携わっていたので日本での開発プロセスへの理解が非常に深かったんです。どんなコミュニケーションを日本人が好むのか、どんな進め方が良いのか、といった点を熟知していたので、進め方に違和感がなく非常にスムーズに開発が進みました。

例えば私の方で「こういうものが作りたい」と要件を伝えると「わかりました。ではまず画面をつくりますのでそこで一度フィードバックして下さい。そのフィードバックが問題なければ、データベースを設計しますので、設計ができたらまたそこでフィードバックをお願いします。その後実装をします。おそらくこのシステムの規模だと〇週間くらいかかりますので、その頃は時間を空けておいて下さい。そのあたりでエンジニアたちからデモをしてもらいますのでそこでフィードバックして下さい。希望納期があればご共有ください。それに合うように簡素化できる機能を簡素化させ、納期優先でやります。他に伝える事がなければ、あとはエンジニア達とミーティングして、仕様詰めや大まかなスケジュールを出すので、他の仕事をされていて大丈夫です。」のような返答が返ってきたことがあります。

これまで半日近くかかってやっていた仕様伝達など、1時間くらいでできてしまい、かなり工数が効率化されたことを覚えています。
さらに日々エンジニアたちの進捗を確認して、進捗報告がない人や怪しい実装の仕方をしている人は翌日注意する、といった要望以上のマネジメントまでしてくれていました。

 

- それは本当にすごいですね。

ちなみにこの成果をもってエボラブルアジアのキックオフイベントのコンテンツ「社内MVP」に推薦した所、最優秀賞であるダイヤモンド賞を受賞していました。トロフィー持って表彰される彼をみて、こんな人と働けるのは凄く恵まれているな」と思ったのを覚えています。

 

- ちなみにラボ立ち上げからすぐにこのような流れで仕事ができたのでしょうか?

いえそういうわけではありません。ラボに参加してもらったばかりのときにはITに詳しい通訳くらいに考えていたこともあり、BSEの方からも私にどこまでも伝えた方がいいかよく分からなかったみたいで、最初の頃はかなりすれ違いがありました。私がしっかりと向き合っていなかったのが原因なんですが・・・。
振り返ってみると、私たちの仕事の進め方や求めることと、BSEが持っている知識をいかにマッチさせて素早くすり合わせられるかがキーポイントだなと思いました。

 

ーなるほど!実際にすり合わせるときはどのようなことを工夫されましたか?

まず最初にすべきなのは、どういった認識のズレがあるのか把握することです。そのために1〜2ヶ月単位の細かい案件をたくさん回すようにしました。そうすることによって要件定義から設計、開発、テストのフェーズ全てを何度も繰り返し、短い間にPDCAを回すことでどこに認識のズレがあるのかを把握することができました。その都度改善を繰り返すことで半年くらいすると、ほぼ阿吽の呼吸で開発ができるようになりました。

 

- やはり中長期を前提としているラボ型だからこそ、こういった知識などを蓄積できるのでしょうか?

そうですね。すぐに成果を求めるのであれば正直、受託開発や社内開発のほうがいいと思います。一方、中長期的に高いパフォーマンスを発揮していく開発組織を作っていくということであれば、やはりラボ型が向いてるのではないかと思います。

 

- なるほど。期間や目的によって受託型・ラボ型を使い分けるのが重要なのですね。今回もご協力ありがとうございました!

こちらこそ。また何かあれば仰ってください。