見出し画像

EMの2つの役割 「チームをつくる」と「チームを機能させる」

Datachainのエンジニアリングマネージャの新田です。

エンジニアリングマネージャ (以下EM) は各社で求める役割が違いますが、この記事ではフェーズによって変化するEMの役割について書いてみました。

この切り口から見たときにDatachainのEMが向き合うであろう、ハイグロースなスタートアップでのEMの役割についてもお伝えします。

この記事のサマリー

  • スタートアップはフェーズごとに分けて考える必要なケースがあります。ハイグローススタートアップは、急成長フェーズに入ったスタートアップです。

  • EMは役割が広いため、文脈を決めて議論する必要があります。今回はEMがチームに起こす変化の度合いとスピード感が、チームのフェーズによって変わることに注目しました。「チームをつくる」と「チームを機能させる」ことを推進するEMの動き方にはそれぞれのフェーズによる置くべき軸足の違いがあります。また、それらは短期的な取り組みと中長期的な取り組みによってアプローチ方法も変わります。

  • ハイグローススタートアップな組織の中では、「チームをつくる」と「チームを機能させる」の比率が、通常の会社とは大きく違うことを認識し、EMの動き方を変える必要があります。

  • 私がDatachainに入社したタイミングは、まさにその比率が変わるタイミングでした。ハイグローススタートアップのフェーズに入ったDatachainは、大きな事業に挑戦するために大きく組織の構造が変わろうとしています。

前提にいくつかの要素があり記事が少し長いのですが、ハイグローススタートアップの中でのEMの動き方について考えてみたことをお伝えします。


ハイグローススタートアップのEMとは?

様々なEMの役割や定義がある

EMの役割は広く、様々な領域への期待があります。
だからこそ会社によって期待される役割も違っています。

よくある期待されるマネジメント領域として、4つのマネジメントが表現されます。
ピープルマネジメント、プロジェクトマネジメント、プロダクトマネジメント、テクノロジーマネジメントです。
参考: https://qiita.com/hirokidaichi/items/95678bb1cef32629c317

これらに深さなどと合わせて、各社でのEMの期待定義なども行われています。
タイミーさんの事例:https://productpr.timee.co.jp/n/n0697dfdc6698

汎用的なマネージャに期待される領域の広さの定義もあります。
よくある分け方ではトップマネジメント、ミドルマネジメント、ローワーマネジメントがあり、経営意思決定レベルのマネジメント、横断や複数チーム統合のマネジメント、実務領域で深くマネジメントする関わり方もあります。
チームが大きくなるとミドルマネジメント領域でのEMの振る舞いも必要になってきて、組織の中での結節点としての動き方が変わってきていると感じます。

EMではエンジニアリングマネジメントトライアングルでマネジメント要素を2つ掛け合わせた領域で必要なことも定義されています。EMは専門的な領域とマネジメントと呼ばれる汎用的な領域を相互に繋ぎながら活動する必要があります。
https://github.com/engineering-manager-meetup/engineering-management-triangle

マネジメントIssueとテクノロジーIssue立ち振舞いを変える必要がある事例もあります。
カケハシさんの事例: https://kakehashi-dev.hatenablog.com/entry/2023/10/20/120000

様々な領域に関わり、定義が難しいEMですが、今回の記事では「チームをつくる、チームを機能させる」という2つについて考えてみたいと思います。

そのEMの役割を説明するにあたって、まずはハイグロースなスタートアップの環境を解説します。これはEMの力が強く必要になる開発組織フェーズであり、この2つの特徴的な役割を説明しやすいと考えました。

ハイグローススタートアップとは?

スタートアップと一口で言っても様々なフェーズや状況があります。社員数が数百人を超える未上場のスタートアップもあります。スタートアップ業界も多くの企業が成長し、VCなどからの出資も増え、デッドの活用もされるようになってきて、かなり成熟してきていることを感じます。

多くのカテゴリで言われることですが、成熟してきた業界は細分化して認識をする必要が出てきます。
Webエンジニアも細分化が進み、バックエンドエンジニア、フロントエンドエンジニア、インフラエンジニアから始まり、業界の先頭を走る会社ではQAエンジニア、SRE、スクラムマスター、MLエンジニア、データエンジニア、CREなど様々な職種の細分化が進んでいます。

スタートアップでも、創業まもない5人の会社と数百人で運営されいつでも上場できる力を持つ会社で同じように話をしても、前提条件の違いから議論は難しいでしょう。

そこで、今回は、「ハイグローススタートアップ」に絞って話をしたいと思います。

ハイグローススタートアップは、一言で言えば急成長のタイミングに入ったスタートアップです。
スタートアップ業界が成熟したことで、確からしい成長の道を提示できればVCなどから大きな資金を集めやすくなりました。金ない・人ない・物もないは過去の話で、挑戦に値するファクトを提示すれば大きな資金が集まります。そうすると、お金はあるが人と物がないという状態になるため、急速に組織づくりとソフトウェア産業の場合にはシステムづくりを、大きな資金を使って急速に立ち上げていくことになります。

創業間もない頃は、事業成長の道を試行錯誤する期間があります。すぐにその答えが見つかれば良いですが、通常のスタートアップは数回はピボットするのが一般的です。

スタートアップのフェーズ

試行錯誤のフェーズを超え、少しずつ手応えがある方向が定まり、その成功に必要な機能を加えていく期間を経て、PMF (プロダクト・マーケット・フィット)を迎えます。
急速に事業は成長し、同時にシステムも大きな成長を求められます。そのシステム開発を支える組織にも大きな成長が必要になるという連鎖が起きます。

大きな成長の兆しが提示できればVCから資金を集めることもできて、そのスピードは更に加速します。

このような、1-2年の短い期間に開発組織が数倍になるケースや事業が数倍になるケースをハイグローススタートアップであると考えています。

EMが起こす変化の種類

スタートアップの環境で期待されるEMの動きはその場限りのタスクを捌くだけではなく、EMがいなくなってもそのチームが良い状態を続けられるチームにすることを期待されます。メンバーの育成、開発プロセスの構築、文化の浸透などチームに良い変化を起こします。期待されるマネジメントは管理することではなく、メンバーのベクトルを合わせて強い力にすることです。

具体的には目標を達成するために目線を揃えたり、効率的に働けるようにプロセスを整えたり、課題を解決し、チームを今よりも良い状態に持っていくことです。

チームを良くすると言っても変化のスピードや進め方に種類があります。通常は改善 (improvement)が期待されており、日常のより良いを目指す、ステップアップ を起こします。
しかし、ハイグローススタートアップでは通常の改善の変化だけでは足りません。物事の内容によっては根本的な方法から変える変革 (transformation) が期待されます。チェンジエージェントとなり、ステップチェンジを起こします。ステップチェンジのような大きな変化は一時的に効率が悪くなりますが、それに負けずに変化を起こし切るロジックや胆力が必要です。

ステップアップとステップチェンジ

そして、ハイグローススタートアップでは、チームを作るスピード感の違いも顕著です。チームを作ると言っても5年で30人の組織を作るのと1年で30人の組織を作るのでは実行すべきことが変わります。
起こる変化の量はおそらく変わりませんが、起こる変化の期間が短いため、変化の頻度は数倍になります。
つまり、対応スピードを数倍にしなければ変化に耐えられず、開発のスピードは著しく低下し、事業を推進できなくなってしまう可能性があるということです。

目指す期間が短ければ急角度になる

ハイグロースな組織ではチームの前提がどんどん変わるため、改善だけでは次の良い状態になるまでに次の変化が起きてしまうこともあります。外部の変化を前提とした内部の変化を起こす必要があります。

例えば、通常は年に1-3人がチームに入るくらいのスピードをイメージしますが、ハイグローススタートアップのチームでは毎月新しい人が入社したり、業務委託が参画することが当たり前の状態です。
単に入社に対応すると言う言葉が同じでも、年に1-3人の入社でイメージしている組織と毎月社員が入社して年間で10-20人がチームに入る組織では必要な対応に大きな違いがあります。

EMが考えるべきは、事業に多くのエンジニアが必要と想定を立てた時に、今いるチームの5人が上手く機能する組織を考えるだけでなく、20人に増えたときに上手く機能する組織とその状態を最速で作るための採用と文化の設計が重要です

チームをつくる、機能させるとは

お待たせしました。ここまで長い前提でしたが、ここからがこの記事の本編です。

マネージャが行うマネジメントには色々な区切り方や関わり方があります。今回はチームを作るタイミングの変化の時間軸で2つに分けて考えてみました。チームをつくることとチームを機能させることです

チームをつくるとは、まだ人がいない状態から人を集めてチームという状態をつくることだと考えています。多くの組織では人は既に集まっている状態からマネジメントが始まることも多いですが、ハイグローススタートアップではまだ何も無い状態からチームをつくることも多くあります。

チームをつくるためには、技術広報、採用活動などの様々な活動も必要ですが、それらの活動を方向づける採用戦略やどのような組織を作るべきか事業戦略からの開発計画へのブレイクダウンが必要になります。

次にチームを機能させるとは、今いるメンバーに今より大きな力を発揮してもらい、チームとしての成果を大きくしていくことです。その場合にひとりひとりの成果を大きくした足し算のチームにするのではなく、ひとりひとりの良さがチームに居るからこそ活きてくるコラボレーションを設計し、掛け算を起こして、個人の成果を超えたチームの成果を作り出すことです

つまり順番としては「チームをつくって」から「チームを機能させる」ことを行うことがEMとして行う作業になります。普通の会社ではチームをつくる業務は人事が中心となって活動したり、経営陣が意思決定して既にアサインが決まったメンバーでチームがつくられているケースが多くあります。

しかし、ハイグロースなスタートアップではチームが次々立ち上がることがあります。事業を複数並列で開発したり、1つの事業で複数の機能を開発するために複数のチームを立ち上げたりします。その場合、経営レベルで個別チームのアサインと採用を調整し切ることが難しくなるため、EM自身がチームを立ち上げるために人事と連携して採用を行い、チームをつくる活動をする必要があります。

つくるという言葉の意味は広く、機能させることもチームをつくることの一部と考えることもできますが、ここではあえて、立ち上げフェーズチームが動くところまでを「つくる」と呼ばせてもらいます。

ハイグローススタートアップではチームをつくる仕事から始まります。そして、機能させることも高速で行わなければなりません。チームのメンバーが集まり、チームが機能する状態に最速で向かうためのキーマンがEMです!

チームをつくる、チームを機能させる

どんなチームを目指すのかを定義し、チームメンバーを自ら集めて、オンボーディングして早期に立ち上げ、力を発揮してもらえるようにチーム活動を改善します。これらのチームをつくり、チームを機能させる仕事をするような、開発組織を中心とした活動を行うことがEMの役割です。

エンジニアであればシステムを作る方を本業としていますし、エンジニアでなければその専門性を理解して社外にいるエンジニアと深い技術の話をすることは難しいです。つまりEM以外の役割のメンバーがチームをつくることに対して思考とリソースを割き、リーダーシップを発揮することは難しいと考えています。

EMだけがこのチームをつくることにリーダーシップを発揮することに集中できます。それではチームを機能させることはどうでしょうか?これらはチームのメンバーが同じ方向を向いて進める状態を目指します。同じ方向を向くための自己組織化されたチームが作られているならばEMの力を集中させる必要はありません。サポートに徹しましょう。
しかし、チームが組成されたばかりのスタートアップのチームでは同じ方向に揃うまでの価値観や開発プロセスの導入がなされていません。システムも不完全状態であり、何を重要視して開発すべきか定まっていないことが多いです。これらを揃えるまでにマネジメントの知識を活用して力を注ぐべきです。

技術知識と同じようにマネジメントにも多くの体系的な知識があり、それらは専門スキルとしてチームの安定や成長を加速させるために活用することができます。もちろん、その知識がなくともチームで改善をすることができますが、無駄な試行錯誤ではなく、王道を試した上で自分たちに合わせた試行錯誤ができた方がチームを高いレベルで良い状態を早く実現できると考えています。

EMに期待する中長期の開発組織戦略

EMには日常の細かなマネジメントだけではなく、チーム全体を見た時にチームメンバーにチーム運営スキルをインプットしたり、効果的なプロセスの構築を進めることも期待されています。EMがアドバイスや意思決定を行うのではなく、チームメンバーがEMに最新技術を伝え、意思決定できる状態を目指します。
チーム運営をチームに任せることで、EMはチームをつくることと、チームをさらに未来に機能させるステップチェンジな方法に思考を使うことができます。

EMには短期的な成果を出すことも求められますが、中長期的な成果はチームが自動的に成果を出せるようにすることもEMには期待されています。

短期 x チームをつくる
・最速でリソースを調達します
・業務委託なども活用しながら、短期的に事業を推進する開発体制を構築します。
・正社員の採用は最低でも半年程度かかるため、即効性はありません。

短期 x チームを機能させる
・チームが機能するように自らが回します
・プロジェクトマネジメントなどを中心に行い、開発プロセスを整備します。

中長期 x  チームをつくる
・チームメンバーを集める
・単純な開発リソースではなく、文化を体現し、より良いシステムと組織を作るメンバーを集めます
・文化作りの場合には基本的に正社員の採用が中心になりますが、契約形態が違っていても文化作りに協力的で興味関心がある人もいるため、契約形態にしばられない思考も必要です

中長期 x  チームを機能させる
・チームメンバーの成長を起こします
・チームが機能するためにマネージャの力は不要です。チームメンバー自身がチームを機能させるための変化を起こせるように自己組織化を目指し、必要な観点を身に着けてもらったり、仕組みを導入します。

それぞれの主要なアプローチ方法

ハイレベルな開発組織の場合、組織のケイパビリティをマネージャが担うのではなく、個々人のエンジニアの力を組み合わせて組織が良いシステムを作るために必要な要素を実現することです。

ハイグロースな組織の中で自分の力を発揮できるエンジニアは、変化に対応する力が必要です。そのエンジニアのフォーメーションを考えるのがチームをつくるEMです。

メガベンチャーや大きな会社では様々な特徴を持つエンジニアを受入可能ですが、資金力も組織として受け入れる体制も強くないスタートアップでは、どんな課題が来ても対応できる汎用的な技術力、未知の問題でも自ら解決する高い自走力、周りに良い影響を与える影響力が必要です。

そしてハイグローススタートアップの組織に必要なのはケイパビリティです。たくさんの量をこなすチームではなく、そのチームだから組めるフォーメーションやコラボレーションを設計して意図的に起こすことです。

ハイグロースなスタートアップのEMに期待される役割

スタートアップでもTry & Errorのフェーズであれば課題が見えてから課題に対応しても間に合います。しかし、ハイグロースなフェーズのスタートアップでは組織問題を発見してから解決しようとすると、組織リソースやケイパビリティ課題に向き合うこととなり、半年以上掛かってしまうようなリソース問題が常に起きてしまう状態もあります。事業にとって最もスピードが重要な時期であるのに半年以上掛かってしまうのは致命的になり得ます

私自身の実感値もありますが、聞いた事例ではSmartHRさんの事例を聞いて同様に組織課題の難しさを感じました。技術的負債の解決のために開発組織の3−4割の力をかけ続け、長い時間がかかったと聞きました。これはハイグロースな事業成長があり、組織的課題にも向き合ったからこそのアクションだったのではないかと考えました。
参照:https://open.spotify.com/show/3JPWoE3HIKaSQ4WO6LPsiZ

私の経験では組織の課題の場合、手を打ってから反応が出てくるのは3ヶ月程度かかると考えています。直接の開発課題であれば直ぐに反応し始めますが、採用活動や組織文化の形成には時間がかかります。課題が現れてから対処していては対応できないないため、先に変化に耐えうる組織に変革する必要があるのです。

つまり、今ある組織課題だけでなく、将来の組織課題に向けて時間を使う必要があります。急成長のスタートアップは自明な課題を解決する小さな改善では間に合わないため、3ヶ月後、半年後に起こる将来を目指して変えていく必要があります

組織の”人数の急拡大”は本来であれば分かりきっているアンチパターンにあえて踏み込み、それでいて成立させる力が必要です。組織の全てが上手く行っているわけではなく、組織の改善と拡大を同時に進める必要があり、それが事業成長の最速を実現するために必要なことだと考えています。

これらの背景を元に、ハイグローススタートアップのEMはチームをつくるための時間が大きく必要になります。これは集計値ではなく、完全な私の感覚値ではありますが、その比率の半分くらいはつくることに投入しなければ、組織のケイパビリティのための採用や組織変化が足りないと感じています。

急成長を目指すとチームをつくるために必要な活動が多く必要

ちなみに私はこの大きな事業のための組織づくりの計画を立て推進するために、ほとんどの時間を採用と組織づくりに向けて活動をしています。

ほとんどをチームをつくるための活動に使っている

私達はスタートアップです。未来のことだけに取り組むだけでなく、今ある成果も達成しなければ未来もありません。目の前のことにも取り組まねばならない。半年後のことにも取り組まねばならない。技術がわかるマネージャ自身がそれらのバランスを取り、目指す組織の状態を定義して推進する必要があります。

他の職種のマネージャとエンジニアリングマネージャの違い

チームをつくる、機能させるだけでは、EMだけでなく他の職種のマネージャも同じでは?と感じた人もいるかも知れません。

組織を通して成果を最大化するという観点ではどの職種のマネージャも同じだと考えています。
しかし、EMはチームをつくり、機能させるだけでなく、システムも作り、機能させる必要があります。つまり2つの大きなことに責任を持ち、中長期戦略を考える必要があります。このチームとシステムの2つを管理することは他のマネージャとは大きく特性が異なっていると考えています。

これについて言及すると記事が長くなってしまうため、今回の記事ではこれ以上は深く触れませんが、こちらについて反応があるようでしたら、次回以降の記事でこれらの違いについても書くことができればと考えています。

もし次の記事にも興味を持って頂ける場合には、このnoteやTwitterのアカウントをフォローして頂ければと思います。

Datachain公式 note
https://note.datachain.jp/

Datachain公式 X
https://x.com/datachain_jp


組織が急成長するDatachainのEMに求められる面白さ

ここまでのEMの前提の役割や期待を踏まえて、ここからはDatachainのEMについてお伝えしたいと考えています。

DatachainはTry & Errorで技術の基礎開発を行い、グローバルでも認められる技術的な強みを持つようになりました。そして今、大きな事業にチャレンジして実用化するためにスピードを上げていきます!一言で言えばハイグロースなフェーズへ突入しようとしています!

巨大なインパクトを目指す事業

今回Datachainではブロックチェーン技術を活用し、ステーブルコインを利用した国際送金のシステムを作ろうとしています。

現在、法定通貨によるクロスボーダー送金の市場は、2022年時点で182兆ドル(約2京8,000兆円)という莫大な規模があります。そして、ステーブルコイン市場は2028年に、現在の15倍以上となる400兆円以上の市場規模に成長すると予想されています。

1つの会社が単独で実現することは難しい事業ですが、Datachainは国内の3メガバンクと共に推進できることや日本の銀行が国際送金するときに標準的に使われている世界でデファクトの1つである機関と共にこの開発を進めることになっています。

今回 Datachainでは多くの銀行が海外送金時に利用しているシステムへのAPI接続が認められ、世界で初めてステーブルコインを利用したシステムを作り、実運用を目指します。このような機関と共に取り組めることはグローバルレベルで見ても圧倒的なアドバンテージとなっています。

この大きな事業のチャレンジについて詳しく知りたい場合はCEOの久田さんのこちらの記事をぜひ読んでください。
https://note.com/hisata/n/n004c3e4fbec1

グローバル前提でのスピード戦

CEOの久田さんのnoteにもありましたが、グローバルでのアドバンテージを有効活用しながら事業を開始するためにはこの1年が勝負です。そのためには組織も相当な速さで立ち上げる必要があります。

とはいえ、求められるエンジニアは数の勝負ではなく、ハイレベルなエンジニアを集めなければ作ることが難しい開発システムになっています。小さく立ち上げる事業ではなく、立ち上がって早々に1兆円レベルの決済が動くことも夢ではないシステムであるため、堅牢なシステムを作るエンジニアが必要です。

ハイレベルなエンジニア組織を最速で作り、ハイレベルなエンジニアが働きやすい環境を作り、事業を推進するのがEMの役割です。
今だからこそできるハイレベルで面白いチャレンジです!

既存のチームとこれからのチームの両輪を動かす

ハイレベルな技術文化は既にあり、未知のチャレンジを価値に繋げる探索を行ってきました。
これからはユーザーに届く形で実用化する組織を強化し、推進することが必要です。

今までの組織の価値を変えようとするのではなく、新しい価値をプラスしてより強い組織にしたいと考えています。

既存の組織と新しい組織の両輪を動かすためには多くのEMが必要です。特に新しい組織を立ち上げるためには開発組織を推進する責任を持つEMが重要になっており、まずは3つのポジションを最優先でEMを募集しています

1.個人ユーザー向けプロダクト 開発チーム EM
・分散型取引所、インターオペラビリティを活用したトークン交換基盤の開発
・開発フェーズは半年後にプロダクトを本番環境へ正式リリースを目指す

2.クロスボーダー送金基盤構築 開発チーム EM
・ステーブルコインを活用した国際送金基盤
・開発フェーズはまだエンジニアは1人もおらず、これから開発チームを立ち上げる

3.ブロックチェーン 開発チーム EM
・ブロックチェーン開発領域でチーム横断的に活動する
・R&Dのエンジニアは多くいるが、技術を活用した実用化にあたり、採用と活躍を専門領域で推進する

現在の開発体制の計画では、中長期的に専門領域ごとのEMが必要になる予定で、トータルで7人のEMを募集する予定です。

多くのEMと共にチームをつくる (募集EMは将来も含めたイメージになっています)

開発組織の文化を作るフェーズで大きなインパクトを目指しませんか?

このインパクトがある大きな事業にチャレンジするには、チームのコアとなるメンバーが足りません。
今はまだエンジニアが10人弱の小さな会社ですが、これから1年待たずに2倍3倍の組織にする必要があります。

DatachainはチームをつくるEMが必要です!ハイグロースの大きな変化に対応し、中長期に発生する課題に向けて先手で組織をリードし、文化を作るEMを求めています!今までにないグローバルスケールのインパクト x 組織の立ち上げフェーズ x 小さな組織で大きな裁量でのEMのチャレンジがあります。

難しさと面白さは表裏一体です。この難しいチャレンジを自分の活用できる面白い環境と感じる人は是非Datachainでこの大きなチャレンジを一緒にしませんか?

開発組織を一緒に作っていくエンジニアリングマネージャやテックリードを積極的に募集しています!

採用ポジション一覧
https://www.datachain.jp/ja/careers

カジュアル面談からになるので、まずは話を聞いてみたい方もこちらから気軽に応募をして頂ければと思います。

私はぜひワクワクする開発組織をつくっていきたいと考えています。
大きな事業達成を目指すだけでなく、スタートアップの中で1番ワクワクできる開発組織を一緒に作っていける人を待っています!

Datachainのどんなところがワクワクしているか興味を持っていただけた方は私のこちらの記事もぜひ読んでください
https://note.datachain.jp/n/n9807113172e5


エンジニアリングマネージャ 新田


今回の大きな事業を実現のために採用ウェビナーを行います!
大きな事業実現のためにワクワクする開発する組織を作りたいと考えています。興味がある方はぜひ下記URLから登録をお願いします!

2024年9月19日(木)19:00 - 20:00 https://us06web.zoom.us/webinar/register/WN_n0-oNce_ScmOgDh3rW5-2g#/registration