2024年11月15日、ファインディ株式会社が主催するイベント「開発生産性Kaigi スタートアップが目指す、開発と事業成長の接続〜価値創造への挑戦〜」が開催されました。

本記事では、キャディ株式会社でDrawer VP of Engineering（以下、VPoE）を務める藤倉 成太さんによるセッション「グローバル開発チームの開発生産性」の内容をお届けします。

■登壇者プロフィール

藤倉 成太(@sigemoto) キャディ株式会社 部門執行役員 VP of Engineering

株式会社オージス総研に入社し、ミドルウエア製品の導入コンサルティング業務に従事。赴任先の米国・シリコンバレーで現地ベンチャー企業との共同開発事業に携わる。帰国後は開発ツールやプロセスの技術開発に従事する傍ら、金沢工業大学大学院（現・KIT虎ノ門大学院）で経営やビジネスを学び、同大学院工学研究科知的創造システム専攻を修了。2009年にSansan株式会社へ入社し、クラウド名刺管理サービス「Sansan」の開発に携わった後、開発部長に就任。16年からはプロダクトマネジャーを兼務。18年、CTOに就任し、全社の技術戦略を指揮。その後VPoE、Sansan Global Development Center, Inc. のDirector/CTO を歴任したのち、2024年1月にキャディ株式会社に入社。

グローバル開発チームで製造業に向き合うキャディ

藤倉：本日は「グローバル開発チームの開発生産性」というテーマで、グローバルでものをつくっていくにあたってどういった考え方をするのが良さそうかということを、私の体験をもとにお話していきたいと思います。 まず自己紹介させていただきます。キャディでVPoEをしている藤倉と申します。普段の登壇ではあまり細かく触れないのですが、今回は私の経験をベースにお話しするので、経歴について触れたいと思います。 新卒で入った前々職の会社で、25歳のときにアメリカのオフィスに出向という形で赴任しました。日本に戻ってきて社会人大学院でビジネスを学び、その後は前職のSansan株式会社でCTOをさせていただきました。今は本業の傍らではありますが、日本CTO協会の理事もしています。 前職では、フィリピンのセブ島に開発の子会社をつくるため、会社の設立から採用、その後の開発マネジメント、組織運営などに携わりました。昨年末に退職し、今年1月からキャディにVPoEとして入社しています。 藤倉：続いて、キャディという会社についてです。キャディは2017年に創業され、現在8期目。ミッションとしては、「モノづくり産業のポテンシャルを解放する」ことを掲げています。 製造業に携わる方々は、日々一生懸命モノづくりに向き合っていらっしゃいますが、現場には多くの課題があります。本来やらなくてもいいことに時間を割いていたり、本当はもっと簡単にできることに難しい問題として向き合っていたりと、そういったものを解消していくことを目指しています。 私たちは今、「CADDi Drawer」というプロダクトを展開しています。「CADDi Drawer」では、図面を中心にドキュメントや受発注の記録、品質系のデータなど、さまざまタイプのデータを製造業のお客様から預けていただき、私たちが持つテクノロジーで解析します。そのなかから新しい価値を見いだして、お客様の仕事の仕方を変えていただく、ひいては新しいスタンダードをつくっていくことを目指しています。 今はまだ「CADDi Drawer」と「CADDi Quote」という2つのプロダクトだけなのですが、今後は「CADDi Drawer」を中心に、「CADDi Quote」のような周辺のプロダクトをたくさんつくり、コンパウンドサービス化していくことを考えています。 藤倉：また、製造業というのはグローバルで見ると2,000兆円を超える規模感で、トップクラスに大きな産業です。大きな市場で多くの関係者がいて、長い歴史のなかで発達してきたこの業界で、新しいものを提案していくというのは、なかなか難易度が高い。そういったところに向き合うため、グローバルでの開発を1つの手段として使っています。 今我々が持っているオフィスは日本、タイ、ベトナム、アメリカで、これらの地域で事業を展開しています。こうした会社で働いている私が、グローバルの開発チームに対して何を考えてきたかというところを、お話しできればと思います。

グローバル開発がエンジニアリソース問題の有効な一手に

藤倉：今回この「開発生産性Kaigi」というイベントが、とても魅力的な目的で開催されていると思いました。やはり事業成長や価値創造につなげることが、私たちがものをつくる本来の理由ですし、我々エンジニアがいいものを優れた技術で生産性高くつくっていたとしても、その事業が立ち行かなくなったら意味がありません。そこに対して、どう貢献していくかが非常に重要だと思っています。 一方で、プロダクト開発をしていると、さまざまなエンジニアリソースに関する課題に直面します。例えば、経営側やビジネス側から、もっと開発速度が上がらないのかという要求があったり、優秀なエンジニアを採用したいけれど、日本国内のエンジニア採用が激化していて難しかったりとか。 開発の優先度の話も難しいですよね。技術的負債をどのタイミングで解消していくかといった判断が難しかったりとか。あとは、エンジニア自らが価値探索する時間が取れない、つまり人数が足りないために、プロダクトマネージャーやディレクションの方々が綿密に企画したものを、ただつくるだけの開発チームになってしまっているとか。こうしたリソースの課題に対して、私はグローバルが有効な一手なのではないかと思っています。 藤倉：グローバル開発という言葉の定義をしっかりしておきたいと思いますが、一時期よく聞いた言葉として、東南アジア系の地域を中心とするオフショア開発があります。私はそういったオフショア開発ではなく、国や話す言葉が違っても、自社の開発チームの一員として、主体性を持って同じプロダクトに向き合う人たちのことを、グローバル開発チームと呼んでいます。 先ほど挙げたエンジニアリソースの課題に対して、日本にいる日本語話者のエンジニアだけではなく、海外にいる日本語話者ではない人たちにもチャネルを広げることができれば、当然より多くの優秀な人に出会える確率は上がりますよね。 また、海外に開発チームを設けるメリットとして、戦略的な開発アイテムを優先的にアサインできることも大きいと思っています。例えば、日本国内で急速にグロースしていて、特にエンタープライズ企業に導入を促すためには、今まで以上に高いセキュリティレベルやガバナンス系の機能が必要だという状況があったとします。 もしくは、1社にすごく多くのアカウントを使っていただいていて、その会社に解約されたら困るという状況があったとしますよね。そうなったら、日本国内のエンジニアリソースをそこに一気に集中して、事業的なリスクに備えるというのは、会社として当然の判断だと思います。 そうした時に、日本語が理解できない海外のチームだと、日本の状況がわからないので、そこに対応する開発アイテムにはアサインしにくいですよね。でも、だからこそ日本国内のマーケットの優先度に左右されないチームとして、別の市場に対して戦略的に本来はやっていくべき、緊急度は高くないが重要度は高い開発アイテムを任せられる。そういったものを優先的に担当するのが海外のチームなんだと整理すると、判断を下しやすくなります。 それから、私の持論になりますが、やはりエンジニアはユーザーのマーケットをしっかり理解しているに越したことはないと思っています。その方がいいものをつくれるし、ユーザーの課題をよりシャープに捉えることができるはずです。だとすれば、もし海外のマーケットも狙いにいくなら、グローバル開発チームをつくるいいタイミングだと言えます。 グローバル開発チームなら、日本人よりも現地のビジネスや市場、商習慣、法律などにより詳しいエンジニア集団ができます。さらに、現地にいるセールスやマーケティング、カスタマーサクセスのチームと、直接コミュニケーションしてフィードバックをもらえることも大きなメリットになると思います。

グローバル開発チーム立ち上げに関するリスクへの対応

藤倉：とはいえ、海外チームの立ち上げにはリスクを感じるものだと思います。オフィスの設立のノウハウや実績がなく、どれくらいコストがかかるのかわからないとか、言語の壁や文化の違いがあって、組織マネジメントが大変そうだとか。特に会社をつくって人を採用していくとなると不可逆的な、なかなか引き返せない挑戦になるので、そのリスクを取る判断が難しいこともあると思います。 当然ながらリスクはあるのですが、いくつかのテクニックを使えば、そのリスクを小さくする、もしくはそのリスクが取れるリスクだと判断できるようになることは、全然あると考えています。 藤倉：まず1つには、例えば私はこれまでフィリピン、シンガポール、ベトナムと、いくつかの東南アジアの国のメンバーと仕事をしてきた経験があるのですが、地域ごとに英語のレベルが全然違うんですね。フィリピンは、タガログ語と英語が公用語なので、アメリカ英語っぽい上手な英語を話す方が多い。シンガポールには、シンガポール独自の英語もありますけど、流暢に話す方が多いです。 一方で、ベトナムやタイでは、ビジネスレベルの英語と言っても、我々日本人からしてもとっつきやすい英語レベルで留まるケースがあります。なので、ものすごく高いレベルの英語がないと海外でチームをつくれないというわけではない、ということは前提知識として持っておくといいかなと思います。 それから、組織マネジメントの観点で言うと、私は一定の責任がある人が現地に張り付くことが重要だと考えています。日本の会社の文化や哲学を海外で再現させると考えると、やはりそれがよくわかっている日本人が行く必要がある。その担当者を探すのは大変かもしれませんが、逆に言うと、そういう人さえいればマネージできると思います。 どんな国でも、エンジニアとしていいものをつくりたいとか、誇りを持って仕事したいという、その根底にある欲求は変わりません。英語のレベルがそこまで高くなくても、ちゃんと気持ちでマネジメントできますよということも、お伝えしておきたいと思います。 藤倉：そして、開発生産性についてです。特に東南アジアで開発していると、市場の成熟度合いが違うため、自社サービスの開発や運用の経験がない人も多く、経験に差があることがあります。そうした時は、まさにファインディさんが提唱されているような、開発生産性をどう測っていくか、それをどう維持したり向上したりさせていくかという手段が流用できます。 立ち上げ当初は、会社や戦略への理解が足りなかったり、自社サービスの開発経験が足りなかったりして、日本本社のチームと比べて生産性に差があるケースは当然あると思います。ですが、いかに近づけていくかという努力はできると思っています。

質問１「英語のレベルに具体的な基準を設けていますか？」

藤倉：ご質問をいただいたので、回答したいと思います。「語学レベルの設定が難しいと感じています。メンバーとしても、興味はあってもハードルに感じてしまう部分かと。具体的に資格やTOEICの点数などで基準値を設けていたりしますか？」ということですが、あまりしていません。 私自身が、それほど最初から英語ができて海外に赴任したわけではないんですね。新卒で入った会社でアメリカに赴任しましたが、その時は恥ずかしながらTOEICの点数は650点くらいでした。 当時、私をアサインしてくださった役員の方に、英語がどのくらいできるかと聞かれて、TOEIC650点くらいだと言ったら、かなり微妙な反応をされました。でも、「エンジニアリング力と気持ちの強さでどうにかします」と言って、「まぁ行ってみな」と言っていただいた経緯があります。 私は今も全然、英語が上手だとは思っていませんが、中学や高校で勉強した基本的な英文法に少しボキャブラリーを足したら、あとはもう慣れなので。慣れればどうにかなると、私は楽観的に見ていますね。

現地メンバーの声が直接聞けるエンジニアチームをつくる

藤倉：ここからはケーススタディとして、これまで私がどのような状況でどのような判断をしてきたかをご紹介できればと思います。まず、前職でフィリピンのセブ島に子会社を設立したときの話です。 当時は、日本国内の事業が成長していて、それに加えて海外への事業展開をしていこうという経営方針がありました。事業的なフィジビリティの確認を含め、まずはシンガポールに拠点をつくり、日本からビジネスメンバーが行ってセールス活動をするなかで、チャンスがありそうだということでタイ、ベトナムにも展開していきました。 この時、日本国内もぐんぐん成長していて稼ぎ頭だったので、日本のチームはそこに集中している状況でした。そこでは、同じオフィスで一緒に働いているビジネス側のメンバーが、お客様の声をたくさん届けてくれていたんですね。 一方で、シンガポールやタイ、ベトナムからのフィードバックは、Slack上に英語で流れていました。しかも、彼らの顔を見たことがなく、熱心にフィードバックをもらっても、なかなかそこに気持ちを向けるのは難しい。その結果、海外のお客様を獲得するため、もしくは利用を深めていただくために必要な機能の開発が、どうしても劣後してしまっていました。 そんな時、海外に開発子会社をつくろうと動き出したわけです。最初に、もちろんリソースがあれば日本国内の案件も含めてやりたいけれど、一番の目的はあくまでも東南アジア、海外のセールスをグロースするための開発チームであると定義しました。 そのため、シンガポールとタイとベトナムのメンバーからの声が直接聞ける、英語を話すエンジニアチームにしたいと考えました。それから、ASEANのセールスの中心がシンガポールだったのですが、地理的に日本とシンガポールの間にフィリピンがあるぞと。そこで現地視察をしながら、首都はマニラなのですが、結果としてセブ島を選びました。 採用もどうにか頑張って、私よりも全然英語が上手なメンバーが集まりました。実際に採用活動を始めるまでには半年間くらいラグがあったのですが、1年半くらいで私が離れるときには40名ちょっとのチームにすることができました。

質問２「海外チームへの仕事の分け方はどうしていますか？」

藤倉：ここで、もう1ついただいた質問に回答しようと思います。「仕事の渡し方にもよると思いますが、質問やレビューなど自分たちの工数が増えるという理由で、日本側のエンジニアが仕事を渡すのを嫌がることもあると思います。どのような仕事の分け方をされていますか？」とのことです。 先ほどもお伝えしたように、自社サービスの開発を経験したことがないとか、日本のチームに比べて後からジョインしているので、どうしてもドメインの理解が浅くなるとか、そういうことはやはりあると思います。でも、日本でも新しく人が入ってきたら教えるじゃないですか。日本で新しい人に対して、なぜその時間を使うかと言えば、きちんとサポートすれば、そのうち独り立ちしてくれると信じているからですよね。 それは海外の人も同じで、独り立ちしますから、きちんと教えてあげることは必要だと思います。海外のチームが徐々に成長していけば、新しく入った海外の人たちに、そのチームのなかでオンボーディングできるようになるので、ずっと教え続けなければならないわけではありません。 英語で伝えなければいけないということが、人によっては心理的なストレスになる場合もあると思うので、日本とまったく同じとは言えないのですが。とはいえ、例えば英語を使ってそこに挑戦したいと思っているような、若くてパッションのある国内のエンジニアの方がいれば、そういう人が中心にサポートしていって、みんながハッピーになるケースもあったりします。 ご質問としては、仕事の分け方をどうしていますかという内容ですが、基本的にはあまり分けたくないと思っています。どの国のどのチームで働いていても、同じことができるようになってほしいというのが、私のスタンスですね。 ただ、例えば本番環境へのアクセスをどうガバナンス的にコントロールしていくかなどは、もちろん考えなければなりません。国が違うことによる事業的な、もしくは地政学的、法律的、技術的なリスクは十分に考慮されるべきで、それによってお願いしにくい仕事が出てくることはあると思います。ですが、基本的には同じことができるようにしたほうがいい、というのが私の考え方です。

自社サービス開発に参加、日本と協働するベトナムチーム

藤倉：ここからは、現職のキャディでの話になります。キャディではもともと2つの事業が並列で存在していたのですが、経営方針がアップデートされ、その2つの事業を統合して、全社で一丸となってバーティカルSaaSの事業に向き合うことになりました。 ベトナムには10名くらいのソフトウェア開発チームがあり、そのチームはもう1つの事業のためのチームという位置づけが強かったんですね。ただ、その統合が発表された今年7月くらいから、ベトナムのメンバーもバーティカルSaaSの開発にジョインしてもらうことになりました。 我々は今、日本だけでなく北米やASEANの事業にも力を入れている状況ですが、日本にも北米にもASEANにも、それぞれの都合や優先度があります。なかなか1つのチームで、それをきちんとハンドルするのは難しいんですよね。 今まだベトナムのメンバーはジョインしてくれたばかりなので、日本のメンバーがサポートしながら自社サービス開発や、キャディならではの開発の文化やスタイルに慣れてもらうフェーズです。ただ、徐々に独り立ちを始めていて、日本側からのアシストを少しずつ薄くしていっています。 藤倉：このベトナムの10名というのが、幸いにもこれまで1年くらい離職者なく同じメンバーで、Manufacturing事業の開発やベトナムならではの開発に取り組んできていたんですね。ここから日本でも思いきり採用のアクセルを踏んでいくフェーズで、であればベトナムでもメンバーを増やしていこうと考えました。 既存の10名は、自社サービスの開発に参加したのは最近とはいえ、キャディという会社の文化や哲学、向き合っている製造業に対しての知識を持っています。なので、彼らを中心として、20人、30人、50人といった体制に、いかに速やかに持っていけるかがテーマだなと。計画上はあまり大胆な数字にはしていませんが、個人的には100人くらいになると、すごいことになるのではないかと思っています。 日本チームとの協働に関しては、今ベトナム側で持ってもらっているのが、機械学習系の解析タスクの一部とプロダクト系の開発の一部。あとはプラットフォームエンジニアリングの部分にジョインしてもらっていて、3つのテーマでそれぞれいい感じにナレッジの共有ができています。 当社の場合は、ベトナムの技術のヘッドが日本人メンバーなので、彼がキャディ本社の哲学や文化を、現地に伝え続けてくれています。ただ、1人だけだと、日本とコラボレーションしていくにあたっての相互理解が難しい部分もあるので、私もできれば四半期に1回くらい、自身で現地に行ってメンバーともっとコミュニケーションしたり、1on1をしたりしていきたいと思っています。 特にプロジェクトが立ち上がっていく時には、日本から中心的なメンバーに1週間でも2週間でも行ってもらって、並走してもらう。そうすると現地のメンバーも嬉しいですし、そうやって相互の信頼を獲得していくようにしています。 また、私たちもまだ手探りの状態で、全部できているわけではないのですが、連携のパターンとしては4つあると思っています。まずは、日本とベトナムのメンバーがワンチームになる体制。そのうえで、マネージャーが日本にいるかベトナムにいるかという2パターンですね。 3つ目が、日本とベトナムがそれぞれスクラムチームとしては独立しているが、それが1つのグループとしてコラボレーションする体制。そして、4つ目はベトナムが独立して、チームリーダーもスクラムマスターもいて、プロダクトマネージャーは日本かベトナムどちらかにいて、自分たちのプロダクトを持っている体制。最後の体制はまだできていませんが、やっていきたいと考えています。 藤倉：最後になりますが、やはり高い目標を掲げて事業の大きな成長をつくっていくなかで、私たち個人が生産的に働いたり、チームとして本質的な価値を考えたり、より付加価値の高いものに集中したりと、いろいろな手段を使いながら、私たちは事業グロースに対して向き合っていくべきだと思っています。 そのなかで、グローバル開発というのは少しハードルが高いように見えますが、こういったものも含めて考えながら積極的に手を打っていけると、さらにいいのではないかと考えています。以上でセッションを終わりたいと思います。ご清聴ありがとうございました。