2016年の創業後、現在は世界13マーケット、17拠点に事業を拡大し、累計の資金調達額は6,200万ドル（約68億円）を超えるAnyMind Group株式会社（以下、AnyMind）。

同社は、インフルエンサー・クリエイターなどの個人や、メディア・ブランド運営企業向けに、商品企画・生産からEC構築・運用、マーケティング・物流までを支援するプラットフォームを開発・提供する。

そんなAnyMindのサービスを支える7つのプロダクト開発を担うのが、およそ70名から構成されるProduct Developmentチームだ。

同チームでは、スピーディーに成果を発揮することを何よりも重視している。そのため、「チームは小さく」「スプリント（開発サイクル）は1週間で回す」「マネジメントは現場の邪魔をしない」「個人には多めに任せる」「個人よりチームの目標達成にフォーカスする」といった方針のもとで組織づくりを行っているそうだ。

今回は、同社で2021年7月よりManaging Director of Engineeringを務める柴田 幸輝さんに、スタートアップにおける「多拠点・多人種」のエンジニア組織の在り方について、詳しくお話を伺った。

15ヵ国以上から集結。7個のプロダクト開発を支えるチーム

私はもともと日本の広告代理店でエンジニアマネジャーを務めていましたが、海外で英語を使って働ける環境を探していて、2019年1月にAnyMindのバンコク法人に入社しました。入社にあわせて、日本からタイに引っ越したんです。

現在は日本法人に転籍し、Head of Engineeringとして開発チームのマネジメントをしています。プロダクトで実現したい世界を、どういうチーム編成で、どういう技術で実現していくのかを決めることが自分の主な仕事です。

入社当時はエンジニアも20名ほどだったのですが、いまはプロダクトマネージャー等を含めると70名超の開発組織になっています。会社全体でも、従業員数は800人を越えました。

弊社はアジア全域において、ブランドやメディア、インフルエンサーの方々向けに生産・EC構築・マーケティング・物流をワンストップで支援するソフトウェアとサービスを開発・提供しています。

最近では、YouTuberをはじめとするクリエイターの方がプロデュースするD2Cブランドのローンチを、トータルサポートするような事例も増えています。こうしたサポートを提供するためのソリューションをどんどん開発していて、現在は7個のプロダクトがあります。

▼同社で展開中のプロダクト

2021年6月には、D2Cブランド市場における物流課題を解決するプラットフォーム「AnyLogi」をローンチしました。これによって、各国の工場とクリエイターとつなげて、グッズの製造を行い、商品を実際にお届けするところまでをサポートできる形になりました。

▼東京オフィスにある撮影用スタジオ

各国に拠点があるため、働くメンバーの国籍も様々です。プロダクト開発を担うProduct Developmentでも、15ヵ国以上から集まったメンバーが働いています。

現場の意思決定を邪魔しない。「多めに」任せるマネジメント方針

Product Developmentにおいては、エンジニアやプロダクトマネジャーがプロダクトごとにチームを編成し、それぞれが開発を行っています。これを、社内では「縦の軸」と呼んでいます。

それぞれのチームは、多くても15人、少ないチームでは3、4人ほどです。エンジニアって、一人ひとりが独立して動けるわけじゃないんですよね。プロダクトはひとつなので、最終的にはひとつのソースコードにマージする必要がある。人数が増えるとコミュニケーションコストも増え、整合性も取れなくなるので、増えてきたら分割することになります。

一方で、人事や評価は横軸でも考える必要があるので、そこはチームを統括している竹本と、自分の方で見ている形です。

マネジメントに関しては、そもそも多数のプロダクトを抱えるエンジニア組織を束ねることを考えると、「マネージャーが全部見る」というのは無理なんですね。ですから基本的には、現場が何でも決定していくことを良しとする、という大前提があります。

なので、あくまでも現場の意思決定の邪魔をしない、彼らがタスクに集中できるように整える、というサーバントリーダーシップに近いことを意識していますね。

▼15ヵ国以上から集まる、多様性に満ちたProduct Developmentチーム

例えば、開発に用いる技術の選定は、プロダクトごとのテックリードにお任せしています。一番重要なのはプロダクトが目標達成をすることなので、「そのためにあなたが思う最適な技術を組み合わせて成果を出してください」というコミュニケーションです。

結果、サービスごとに全く違う技術を使っていますね。例えばサーバーサイドのプログラミング言語だけでもPython、Kotlin、Golang、Scalaなどがあり、フレームワークもバラバラです。そもそも弊社の事業として、最適な技術やスキルはどんどん変わっていくので、そこはコントロールしない方が良いだろうと考えています。

また、現場のメンバーに対しては「多めに任せる」ことを意識しています。それぞれに任せられる領域にはグラデーションがあると思いますが、そのちょっと先まで踏み込んでいくイメージです。これはマネージャーへの負荷集中を防ぐためと、やる気のあるメンバーに挑戦の機会を与えるためです。

多めに任せると、もちろん失敗することもありますが、大きな事故に繋がらないようなフォローはしつつ、軽微な失敗は起こるものと考えて、ロールバックできるようにするなど品質は担保できるように調整しています。

スプリントは1週間。素早く作って素早く直せるシステム設計も

また、弊社はまだ新しく変化の激しい分野でプロダクト展開しているため、とにかく素早く作って素早く直せることを重視しています。

例えば、開発におけるスプリントは1週間で回しています。以前は2週間だったのですが、「Instagramの仕様が変わったからこういう機能を作りたい」となったときに、そこから次のスプリントに入れるとリリースまで3週間くらいかかるんですよね。これでは遅いなという体感があり、1週間にしたんです。

これはプロダクトの特性の問題で、特に1週間だからすごいということではないと思っていますが、短いサイクルでスプリント回すために工夫していることはあります。

例えば、Domain Driven Design（※）の考え方に近いのですが、「すぐ直せば大丈夫」という領域と、そうではない領域を設計の段階でしっかり分けることです。

※ソフトウェアの設計手法のひとつ。大規模なひとつのシステムとデータベースで構築するのではなく、業務にとって適切で独立したシステムに分割し、共通言語を用いて開発を進める。

具体的には、各プロダクトが持っているデータを「更新するところ」と「表示するところ」でロジックをきっちり分けています。データ更新はクリティカルなので丁寧にテストをしますが、データ表示であればすぐに直せるので、まずはスピード優先でリリースする…といった形です。

場当たり的に開発するのではなく、このデータはこういう振る舞いをするべきだ、ということをしっかりみんなで議論しながら進めています。

我々の事業特性上、FacebookやInstagramの仕様変更によってプロダクトが変わっていくので、どんな画面でもきっちり動くことより、スピードが求められる部分もあります。そこで、ある程度割り切って考える必要もある…ということですね。

スタートアップだからこそ、個人よりチームの目標達成にフォーカス

加えて、弊社はまだまだスタートアップなので、過程を大事にするよりは「いま」結果がほしいということがあります。シンプルにスピードを出して、成果を重視しなければ生き残れないですよね。

さらに、開発チームが多国籍で色々なカルチャーを持っているので、それぞれの能力ややる気に応じて細かく調整していくのは現実的に難しいです。なので、「これが一番大事なこと、それ以外は何をやってもいいですよ」という形で統一の目標をわかりやすくフォーカスするようにしています。

自分たちでコントロールできないゴールは意味がないので、技術的な目標は、あくまでもビジネス的な目標とは切り分けています。具体的にはプロダクトマネジャーが「この3ヶ月で達成すること」をゴールとして定めますが、「◯◯の機能を作ってリリースする」といったものが大半です。

このチーム目標を達成することを最優先としているので、そこから先のメンバーの個人目標はほとんど具体化していません。そもそも落とし込むのが難しいですし、「個人目標は達成したからいいよね」で終わりにしてほしくなくて。

やはりスタートアップで成果を出すことに注力する必要があるからこそ、チームの目標を常に意識してほしいと考えています。そのために一体感を持って、協力し合うことが大切ですね。

従って評価に関しても、基本的にはプロダクトごとの達成度が基準になります。テックリードやマネジャー相当であればプロダクトの達成度がそのまま評価になりますし、メンバーの評価においては、全員の平均値がプロダクト達成度と同等になるようにしています。

基本的に、評価もメンバーの仕事の邪魔をしないようにありたいなと思っていて。チームとしてうまく回っているのであれば、全員を評価してあげたいので、チームの成果がまず前提になる形にしています。

とは言え、それだけではない個人差の部分もあるので、メンバーに関しては定性的に個人のパフォーマンスを判断する要素もあります。また、半期に一度のピアレビューを評価のダブルチェック的に使ったり、定期的な1on1で不満を吸い上げたり、といった仕組みを設けています。

社内外に向けて、AnyMindの技術力を伝えていきたい

もともと弊社は経営と開発の距離がとても近く、経営的なビジョンやメッセージがしっかり開発チームに伝わってきた…という背景があります。それが、5年でこれだけ事業を成長させてきたスピード感につながっていると思っていて。

ただ、どうしてもプロダクトマネージャーに情報が偏ってしまう部分もあるので、今後はいま以上にビジネスに詳しいエンジニアを育てていきたいなと思っています。

先ほどお話しした、Domain Driven Designを推奨している理由に「ビジネス理解をすることで、より仕様変更に対応しやすい設計を行えること、新しく入るメンバーも素早く業務ロジックを理解することが出来ること」があります。そこがAnyMindの今の状況に合っていると思っていますので、今後もより推進していきたいですね。

また、会社としてよりプロダクトを前面に出していきたいと思っています。AnyMindのビジネスが伸びていることは伝わりつつありますが、プロダクトや技術面についてはまだまだです。今後は「技術的にもイケてるんですよ」ということを、社内外に向けてしっかり発信していきたいですね。（了）