BLOGS
ブログ
ベテランPM・エンジニアにJIITAKのラボ型開発についてインタビュー
合同会社グラージベンチャーズは、「イノベーションを生み出すスタートアップスタジオ」として新規サービス開発支援や、技術コンサルティング、自社プロダクト事業を展開している。
今回のインタビューでは、建設業界のクラウド型業務管理システムの開発にあたり、JIITAKのラボ型開発サービス（求めるスキルを持つエンジニアチームを一定期間、自社専属チームとして社外に確保する開発体制・エンジニア調達手法）をご利用いただいているグラージ・ベンチャーの衛藤氏と吐合氏からお話を伺った。
合同会社グラージベンチャーズ
左：吐合氏 右：衛藤氏
サービスを知ったきっかけ
まず、JIITAKのラボ型開発を知ったきっかけを教えてください。
（衛藤氏）実はラボ型開発というものがあること自体、知らなかったんです。JIITAKさんがインドを開発拠点にシステム開発をしているというのは以前に聞いたことがありまして。本案件のエンジニア人員で悩んでいた時にもしかして！と思いエンジニアさんを抑えられるか聞いてみたところ、JIITAKさんのラボ型開発サービスの説明を聞き、そこで初めて知りました。 同じエンジニアを固定で抑えられるということを知って凄く良いと思いましたし、長期的にフルコミット出来るというのに魅力に感じましたね。
ラボ型開発を利用する前は、普段どのようにしてエンジニアを確保していたのですか？
（衛藤氏）普段は人員を確保する必要があるときはクラウドソーシングを利用したりして、フリーランスや副業のエンジニアの方を確保しています。 クラウドソーシングで募集すると、エンジニアの方だけでなく営業の方も含め数十件レスポンスが来て、選考判断の基準に達するのは平均2人ほどになりますが、エンジニアさんは見つかりはします。 （吐合氏) 確かに2人くらいになりますね（笑）。 （衛藤氏）なんですが、リモートで参画するフリーランスの方たちはタイムマネジメントが出来る範囲で基本２～3件は案件を掛け持ちしているので、対応が遅くなってしまうことがあるんですよね。掛け持ちしていないと、1つの案件が上手くいかなかった場合にリスクが大きいので、リスク分散する必要があって。それとスキルが高い人ほど需要が高いので掛け持ちをしているという傾向があります。 発注する側からするとスキルが高い人ほどフルコミットで抑えられないという難しさはありますね。逆にフルコミットできる方だと技術面で懸念する点があったりするので、1.2ヵ月先から1/2人月でお願いできるエンジニアさんに基本的に頼みます。
最終的にJIITAKの「ラボ型開発」を利用するに至った決定的な理由はどのようなものでしたか？
（衛藤氏）今回プロジェクトの開発チームを組むに辺り、クラウドソーシングを利用してのエンジニアの確保も検討していたのですが、JIITAKさんのラボ型開発サービスを選んだ理由として1番大きいのは、依頼してからの「開発チームの立ち上げが早いこと」と「同じエンジニアが長期間、継続的にフルコミットできること」です。 継続的な開発であるので、フルコミットが可能であることに加えて、同じ人にお願い出来るので、エンジニアの方のレベル感を把握することが出来るので「マネジメントしやすい」という利点があり、自社の社員をマネジメントするのに準じたマネジメントのやりやすさがあります。
なるほど、ラボ型開発の形態について知った後で、他社のラボ型開発も検討しましたか？
（衛藤氏）実は、ラボ型開発を行う他社さんも比較検討していました。一度ベトナムの会社のラボ型開発サービスを検討して、資料請求をしてお話をしたことがあるんですけど、打ち合わせをした方との日本語での意思疎通が難しかったという経験があります。 日本語と英語以外の言語を話すエンジニアの方との打ち合わせで、間で通訳・翻訳していただく方との日本語の会話が成り立たないってなったときに、もう自分の力ではどうしようもないじゃないですか（笑） ブリッジの方に技術的な内容が上手く伝わらなかった場合は、英語であれば翻訳機を使いながらなんとなく大体説明できますし、プログラムでエンジニアと直接コミュニケーションもできるので、問題なく対処できます。ですが、ブリッジの方を必ず通してエンジニアの方とコミュニケーションを取る場合は、やはりそのブリッジの方の能力に凄く依存するので結構リスクなんですよね、、、 その場合プログラムの中のコメントを日本語で書けば良いのか英語で書けば良いのか分からないし、どっちにしても伝わらないのでプログラミングの中での意思疎通が難しくなります。
なるほど。興味深いです。エンジニア同士での意思疎通は非常に重要ですよね。ちなみに、コミュニケーションにおいて、インドであれば英語でエンジニア同士の意思疎通がとれる利点があると感じていましたか？
（衛藤氏）そうですね。ブリッジの方を通して説明するのが難しい内容であれば、自分が英語を勉強すればどうにかなるじゃないですか（笑） 僕たちも文法的には間違ってるかもしれませんが、中学英語くらい分かれば一応意思疎通出来ると思うんですよ。 その詳細のレベルでエンジニア同士のダイレクトな疎通というのはやっぱり必要なんですよね。 インドでは何かしらの「バックアップの手段」があると思いました。
ラボ型開発を始める前と後では、イメージの変化はありましたか？
（吐合氏) 正直最初はラボ型については分からなかったです（笑）
（衛藤氏）最初は2人のエンジニアがアサインされるだけで、もう一人の方が通訳・翻訳として入られると思っていたのですが、最初の打ち合わせてで人がいっぱい居て（笑）
通訳・翻訳者とは別に、エンジニアのタスクを管理するチームマネージャーが毎回入って進捗や理解度の管理の役割で参加するので、思っている以上に人が多いなと感じさせてしまっていたかもしれません（笑）
（衛藤氏）そこですよね、細かいマネジメントのところを凄いやってくれるところも価値が高いと思いました。 実は、以前別の国のエンジニアさんとお仕事をした際に言語の問題があったんですよ。その方はフリーランスの方で直接やり取りだったので、ブリッジの人がおらず、Google 翻訳などを使いながらコミュニケーションをとっていたんですよね。
開発が進行していくにつれて、次第に共通認識にズレが起こり、意図が伝わっていなかったことがあったので、チームとして同じ理解度で進めていくことには正直不安がありました。でも今回一緒にお仕事をさせていただいて、意思疎通だったり、文化の違いに対しての問題は感じてないですし、日本人の方と行う開発とあまり変わらない感覚でやってます。
（開発メンバー構成図を記載）
今後サービスのご利用を続けていくにあたって、改善点・もう少しこうしてほしいというご意見があればぜひ教えてください。
（吐合氏) そうですね。うーーん、特に思いつかないです。あるとすると一度、弊社のエンジニアと英語での会話が成立していたとしても、確認のために1度翻訳（日本語）を挟みたいと思いました。
（衛藤氏）でもなんかそれって、Slackの中のハウスルール（チャットルール）で、「翻訳をしてもらいたいときは、どういう印を残す」みたいな話なのかなとは思っていて。 なので、JIITAKさんが「他の会社さんはこういうハウスルール/ チャットルールでやってますよ」みたいなものを教えてくれたら、それを参考にやりやすかったりするんですかね。
文化的によく使っている絵文字がその国では違う意味だったらどうしようとか思ったことありました（笑） 良いコミュニケーションの取り方をある程度理解した体制に早めになれれば、みんな喜ぶのかなとは思います。 オフショアのラボ型経験がなかったら、どういう進め方をすると効率的というか上手くいくのかということをクライアント側が分かってないと思うので、そこを「こういう感じにしたらうまくできますよ」っていうのを先に渡せるようにしたらいいと思います。
参考にさせていただきます。クライアントさんであるシステム開発会社側のハウスルール/チャットルールで「やりやすい方法に合わせます」というスタンスではあったのですが、文化的な側面などでチャットのやり取りの方法を想像以上に気にかけていただいていたんですね、、
（衛藤氏）「ラボ型のおススメのコミュニケーションの仕方」みたいなドキュメントを作って渡せばいいんじゃないですか？（笑）
あ、いいですね。（笑）その他に何かご意見はありますか？ここを改善してほしい、こうしてるときこうだったらいいななど。
（衛藤氏）うーん、ほんとに特に思いつかないんですよね。まああれですかね、チームに参画してくれているインドのエンジニアの方ともうちょっと雑談したいみたいなところですかね（笑）
そう思ってらっしゃるとは！確かに、定例ミーティングでもすぐに本題にという雰囲気なので、日常でどんなことしてるのかとか話せるといいですかね。結構シャイでまじめな性格で、コツコツタスクをこなしていきたいタイプの人なんです（笑）
（定例ミーティングの様子）
こんな方にJIITAKのラボ型開発はおすすめ
それでは最後に、JIITAKのラボ型開発をどういった方にお勧めしたいと思いますか？
（衛藤氏）やっぱり、「スピード感」を求めてる/求められてる人・業界がいいのかなと思います。 一番のわかりやすい利点っていうのは「すぐに人を抑えられる」、そしてそこに「はずれが少ない（技術・実行率）」っていうことだと思います。 これって、分かりやすく例えると「Amazonでモノ買う」みたいな話で、あれだけ配送が早かったらもはや自分の倉庫みたいなものじゃないですか（笑） 使いたいときやほしいときに、お金を払えばすぐ手元に届く。
要は、「自社のリソースの一部」みたいに捉えることができるんです。 そこにすごく時間がかかるのであれば、それは自社ではなく全然違う会社という感じになってしまうんですけど、お願いしたらすぐ質の高い状態でもらえるっていうのであれば、もうそれは「自社のリソースの一部」っていう認識になりますよね。 もしそうできてしまえば、「JIITAKさんで人を抑えられるから」っていう見込みで、営業をかけたり、新しい仕事・案件を探すことが可能になります。 それができない状態だと、人を抑えられる確証がないので、クライアントを待たせることになってしまいます。
それに、先ほども話したように技術の高いエンジニアほど仕事を掛け持ちする傾向にあるので、人材を抑えるのが難しいです。 なので、対応してほしいときになかなか見つけられなかったりするんですよね。 そうなると、開発が遅くなったり、抑えられたとしてもフルコミットしてもらえなかったりしてしまいます。 やっぱり、「すぐに返答ができる」という面でも「スピード感」は大事だと思います。
なるほど、Amazon倉庫の例はとてもわかりやすいです。 エンジニア不足の日本の開発環境を力強くバックアップできるよう、より良いソリューション提供に奮闘して参ります。今後とも、よろしくお願い致します。 -- 衛藤氏、吐合氏、本日はありがとうございました。
Miku, Mirei
関連記事
最後までご高覧頂きましてありがとうございました。当ホームページのブログでは、会社に関するニュースや開発事例インタビュー、テクノロジーの最新動向などに関してお届けしています。 今後、インドのビジネス市場についての面白い話題や出来事を知っていただけるようなコンテンツも発信していきます。