00:00
今回のテーマは、スタートアップにおけるエンジニアリングチームをいつ分割するのか問題〜です。
スタートアップにおいても、やっぱり組織がスケールしてくるとチームを分割しなければいけない、というのは、どの会社でも出くわす問題だと思います。
この問題について、いろいろな現場でどういった制約があるのか、どういったモチベーションがあるのかといった要素を加えながら、
問題に対してどんなアプローチができるのか、というのを聞いていきたいと思います。
というわけで、ゲストには株式会社カミナシのエンジニアリングマネージャー、宮本大嗣さんにお越しいただきました。
宮本さん、一言、自己紹介いただけるでしょうか。
はい。私、今、株式会社カミナシでエンジニアリングマネージャーをやっております。宮本と申します。よろしくお願いいたします。
よろしくお願いします。
エンジニアリングマネージャーの問題集。
今日は第1回目ということで、このポッドキャストではエンジニアリングマネージャーの皆さんの現場の問題について、いろいろ伺っていきたいと思っています。
早速、宮本さん及びカミナシさんについて伺っていきたいと思うんですけれども、まず最初にカミナシの事業とか、プロダクトについて簡単に教えていただけるでしょうか。
事業としましては会社名と同じですね。カミナシというエンバディエックスプラットフォームと我々は呼んでいるんですけれども、
そちらのSaaSを開発、運用、提供している、そんな事業をプロダクトを運営、運用しておりますと。
ありがとうございます。今をときめく2BのSaaSをやっているってことですよね。
そうだなと思ってます。僕が知る限りなんですけれども、カミナシさんってプロダクトも結構すごいなと思う一方で、会社のカルチャーみたいなところにかなり力を入れてらっしゃるっていうふうに、
いろんな記事だとか、カミナシさんのポッドキャストとかでも知っておりまして、その辺かなりやっておられるんだろうなと思うんですが、
ちょっと突っ込んだ質問したくて、宮本さんがカミナシのカルチャーの中で一番好きなものって何ですかっていうのを聞いてみたいです。
私たちはカルチャーは戦略に勝るという考えをしていくような会社かなと思っているんですけれども、
カルチャ育成の観点で全社員に期待しているバリューというのが5つございます。
ちょっと長くなるので、端的に申し上げると、現場取り分、全開オープン、ベータ版マインド、外向きベクトル、自分リノベーションというもの5つなんですけれども、
その中で個人的には、いろいろ限られた時間で考え尽くしたら、とりあえず後はやってみるという意味合いを持っているベータ版マインドというバリューが個人的には好きだったりします。
03:07
なるほど。ベータ版マインドいいですね。同じ言葉とかはなかなか聞いたことがないので、結構珍しいなと思いつつ、
どのスタートアップでもやっぱりベータ版マインドっていうのって、何か作り込みすぎないだったりだとか、そういうのを示す基準として結構大事だなというふうに思ったんで、いいカルチャーだなと思いました。
そうですね。そんな紙なしで働かれている宮本さんなんですけれども、ちょっと紙なしに至るまでのキャリアみたいなところも少し聞いてみたくて、
エンジニアリングマネージャーをされる前に経営企画とかそちら方面をやられていたみたいなところも聞いたりしているんですけれども。
そうですね。先に申し上げるとコーサルティング会社にいたり、新規事業支援の会社に行ったり、
それこそは事業会社で経営企画のお仕事をしたり、あとコンポリートベンチャーキャピタルとかお仕事したり、結構いろんな職を点々としているんですけれども、
自分で事業をやりたいなと思ってエンジニアリングを覚えたんですが、ちょっと事業の方は自分が情熱を持てなかったり、
そもそもスキルしなさそうだったので一旦諦めて、年齢的にその時30前半だったので、
このタイミングでエンジニアやらないと一生やらないだろうなと思って、そこからエンジニアにチャレンジしたという、そんなキャリアになっています。
上梨に来る前に別のスタートアップでエンジニアとして修行を済ませていただいて、上梨に来てからエンジニアにして頑張ろうと思ったんですけれども、
いろんな会社の状況やら何やらが重なって、エンジニアリングマネージャーとして動くことになったという、そんな流れでキャリアでございます。
なるほど、ありがとうございます。結構いろいろ経験されながら、エンジニアリングっていうところにモチベーションを抱いて転職されて、
手を動かそうと思っていたけど、会社の状況でマネージャーをやっていると結構あるあるかなという気もしましたけれども、
そんな上梨さんでエンジニアリングマネージャーされているというのは、簡単にマネージャーの仕事というところを教えていただけるでしょうか。
はい、そうですね。私たちの会社でのエンジニアリングマネージャー業といいますと、採用活動、技術広報PRということで記事書いたり登壇したり、
あとはマネージャーやっていると申し上げていますが、実際不害修正やら何やらとかも普通にやっているので、普通にコードを書いたりとか。
結構そうですね、タブ書調整などもやっているので、何でも屋さんみたいな感じに少しなっているかもしれません。
なるほど。手を動かす部分もあるっていうことだと思うので、プレイングマネージャーというか、そういう感じでやられてそうだし、
06:07
いろいろ過去の経歴とかもあって、宮本さんがタブ書とのコミュニケーションとか得意だからっていうので、
マネージャー的な立ち位置で他の人がやらないようなことをいろいろ拾って動いてらっしゃるんだろうなというふうに想像しました。
ありがとうございます。
ありがとうございます。ここからもう少し宮本さんが現場で立ち向かわれてる問題っていうところを深掘っていきたいなって思っております。
ちょっと僕自身の考えなんですけれども、エンジニアリングマネージャーっていうのはチームとかエンジニアリングっていうものをマネージしてると考えてまして、
ただそこだけにフォーカスするとちょっと視点が狭くなりがちだという考えも持っています。
チームとかエンジニアリングっていうのを取り巻いている組織っていうものとか事業っていうもの、こういった要素を加えて、
日々の仕事とはちょっと違う視点で問題を見ていくっていうことをこのPodcastではしてみたいなと思ってるんですね。
EMの役割っていうのがチームの成果を最大化することだと思うんですけれども、
チームに影響を及ぼすそういった他の要素、組織とか事業っていう要素を俯瞰的に見ていくと、
自分が戦うべき問題っていうのもよく見えるようになるんじゃないかなと思っているわけなんですね。
いろんな要素で聞きたいんですが、まず初めにちょっとこれからスケールしていくっていうフェーズとかも伺ったりしてるので、
組織についてっていうところから聞いてみたいなと思っています。
そこを捉えるたびに、ちょっと定性的なところとかテール的なところから聞いていくんですけれども、
今の雷のエンジニアリング組織のサイズってどんな感じなんですかね。
そうですね。今は正社員の方が9名で、業務委託の方が6名かなというところで、15名規模の組織サイズでございます。
そのサイズで、マネージャーEMは宮本さんお一人っていう感じなんですか。
そうですね。
なるほどなるほど。15人ぐらいでマネージャー一人って結構大変そうだなっていう印象を持ちますね。
なんか2ピッザよりちょっと大きいぐらいですよね。ちょっとだいぶ大きいのかな。
そうですね。なので、最近は7月から原取さんという方がCTOに着任されたので、
一部の方は原取さんが直接マネジメントされているチームにいらっしゃるという形をとっています。
なるほど。じゃあ15人全員ってわけではないんですね。
そうですね。はい。
でも先ほどのお話だと、宮本さんまだ手を動かされている部分もあるってことなんで、
非常に時間の使い方のバランスが気になるところなんですけれども、
09:00
実際そのプレイヤー業務的なものとマネージメント業務的なもの、これらの打ち分けだったり、
時間の配分としてどれくらいだったりっていうのも聞かせていただけますか。
そうですね。週によって違うというのはあるんですけれども、
マネージャー業務に主に6、7割ぐらい使っていて、
あとプレイヤー業務に3、4割ぐらいというのが平均して慣らしてみると、そういう打ち分けかなと思っております。
なるほど。結構その人数規模をマネージしているEMとしては、
割とプレイヤー業務に時間を使えているなというふうに今思うんですけれども、
何だろうな、うまくプレイングの時間を作るコツとかって何かあるんですか。
そうですね。一応カレンダー上は毎日午前中をブロックしたりしていて、
基本はそこを作業時間に当てるというふうにしております。
ただ他の部署の方の予定とかがいろいろとあって、
午前中に打ち合わせしたいとかっていうことがあったら、
そのカレンダーの枠が削れていくということで、
それで大体作業終わりみたいな先ほどのお話につながっているのかなと思います。
なるほど。カレンダーブロックはめちゃくちゃ汎用的な時間確保の仕方ですよね。
はい。
そうですね。これはまずやりますね。
あと午前中というのも会社にもよると思うんですけれども、
エンジニアがあまり頑張って稼働していない時間だったりするので、
マネージャーの時間としては取りやすかったりもしますよね。
おっしゃる通りかなと思いますが、
やはりビジネスサイドの方は午前中から稼働されていらっしゃるので、
その時間とかのほうが話しやすかったりしますかね。
ただビジネスサイドの方、特にマネージャーとかやってらっしゃる方、
大体カレンダーとかを見ると基本終日待っているので、
そういう場合は大体定例ミーティングとかにして枠を押さえて、
お話しするような感じになっていたりはしているかなと思いますね。
確かに確かに。
プロジェクトを進めていくときとかはミーティングドリブンというかね。
まず定例ミーティングを作って、そのペースで仕事を進めていくみたいなのもありますよね。
そうですね。
マネージャーあるあるですね、その辺は。
そういった形で今マネージメントされている中で、
一方でビジネスも結構伸びていらっしゃるというふうに伺っていまして、
それに合わせて組織もスケールさせていくという、どこにでもある話だと思うんですが、
いうことを宮本さんもミッションとして持たれていると思うんですけれども、
まずスケールさせていくときに、スケールした先のエンジニアリング組織の構造みたいなのって、
12:07
何か今の段階でイメージされているものとか設計とかってあるんでしょうかね。
今って割と一人のマネージャー、あとはエンジニアみたいなフラットな感じだと思うんですけれども、
フラットなままでいきたいのか、それとももうちょっと改装みたいなのを入れるのかとかあると思うんですけどね。
そうですね。
結構まではフラットなチーム分けが望ましいのではと思ってまして、
最近チームトポロジーとか読んでる人とか社内でも増えてるんですけど、
あれでいうストリームアラインとチームといったらいいますか、
一つのチームで一部の機能の開発が全て完結するような、
そんな単位のチームが何個かフラットにできていくと望ましいのかなというのは今なんとなく考えているところですかね。
確かに。まずあれですよね、チームトポロジーすごくいい本ですよね。僕も読みました。
ストリームアラインのチームはプロダクト開発するチームだったら、
そうなってないとスピード遅くなっちゃうだろうなっていうのは身をもって知ってるところだと思うので、
このポッドキャストを聞いている多くの方もそこはうなずくところなんじゃないかなと思うんですけれども、
やっぱりそういうチームをベースに組織構造を設計していくっていうのは、
少なくとも最近はトレンドというかモダンな手法なのかなという気もしています。
ただ、この辺も現場とか会社によっていろんな制約だったりカルチャーだったりなんかあると思うので、
本当これを作っていくのが簡単じゃないなっていう気がしてるんですよね。
というので、もうちょっとカミナシさんでそういったチーム構造をスケールした組織で作っていくために、
どんな問題があるのかとか、そういうのも聞いてみたいなと思っております。
フラットなままチームを増やすにしても、やっぱり1人のマネージャーで見れるチームの数っていうのは限界があると思うので、
マネージャーどうするんですかみたいなところって何かあるんですかね。
そこは結構大きな課題かなとは思ってまして、
今、エンジニアとして活躍されてる方になんとなくマネージャーとか興味ないですかって伺うこともあるんですけれども、
やはりエンジニアあるあると言いますか、自分自身も理解できるんですが、
エンジニアリング楽しいですから、マネージャーそんなに興味ないっていう方が多くてですね。
社内にどなたかに強制でお願いするのも忍びないなと思っていて、
マネージャーの方を外部から採用することも検討しないといけないのかなと思ってるみたいなそんな状況ですね。
そうですよね。なかなかこの組織大きくするときの誰がマネージャーをやるんだ問題って、
15:03
どの組織でも出てくる出くわす問題で。
あと僕も長いことエンジニアやってましたけれども、
マネージャーをやるっていうことは想像してなかったですもんね。
ずっとコードを書いていたいし、設計していたいし、今でもやっぱりたまにシステムの設計とかに関わることありますけれども、めちゃくちゃ楽しいですもんね。
そうなんですよ。自分もたまにソースを回収したりとか、
人手が足りないときに設計したりとか、まだギリギリやらせていただいてるんですけど、やっぱりそっちの方が楽しいですね。
そうなんですよね。その辺は現役でいたいなという気持ちはめちゃくちゃわかりつつ、
ただ一方でビジネスとか組織とかそういうところを何か前に進めていかないといけないという責任感というか、
俺がやらなきゃみたいなふうに、おっさんになったからなのかわかんないですけれども、そう思うところもかなり大きくなってきて、
最近はマネージャー業というのは僕はかなり力を入れてやってるっていうところだったりもしますけどね、
万人に押しつけるものではないなというのはすごく思います。
そうですね。押しつけられてもそもそもパフォーマンス出るのかって言われると、
押しつけられたからしょうがなくやってるみたいにやっぱりどうしてもなっちゃうと思いますし、難しいなと私は思いますね。
そうですよね。そうすると外部から結構ご経験のある方を採用してみたいな方向性、先ほど話されてましたけど、
そういうのが妥当なんですかね。とはいえ採用するのもまた難しいと思うんですけど。
そうですね。やっぱり社内にやりたいという方とかがいらっしゃらない場合はどうしても外部から採用しないと、現実問題難しいですよね。
そうですよね。そういうソリューションになってくるかなとは思います。
一旦ちょっと採用という問題は脇に置いておいて、エンジニアリングマネージャーを何らかの形で増やしますみたいになったときに、
雷さんでというか、宮本さんの観点でといったところで、どんな感じのエンジニアリングマネージャーに入ってきてほしいだったり、
こういう人だったら雷だったり、今のチームでめちゃくちゃワークしますみたいな要件みたいなものってイメージがあったりするんでしょうかね。
そうですね。入ってきてほしいタイプの方でいうと、明らかに私とは違うタイプの方が入ってきていただけると個人的には嬉しいなと思っておりますね。
やはり似たような人ばかりが入ってきてくださると、それはそれで個人的には話しやすかったり、意思疎通を図らなきゃいけない場面ではコンフリクトすることも少ないとは思うんですけれども、
18:05
やっぱり多様性といいますか、こういったやり方もあるんですよっていう事例が増えた方が、もしかしたら今エンジニアリングマネージャーをやりたくないと思っているエンジニアの方も、
こういう方向性だったらやってみたいなみたいな内発的な動機みたいなのが生まれるかもしれないですし、
その違ったやり方がさらに事業を発展させる可能性があるような開発組織を生み出していくというといいんですけど、作っていったりできる余地を生み出しやすいのかなと思っていたりしております。
確かにね、僕の観点でいうとチームとか人っていうのって全く同じ人だったり全く同じチーム、問題が全く同じチームとかってないと思うので、
そうするとそれを解くのも一様なやり方ではないじゃないですか。
やっぱり問題を解く解き方だったりアプローチだったりっていうのは本当に千差万別で、
その引き出しが多い方がより柔軟に組織とかチームにある問題を解決していきやすいと思うので、
そういった意味では単純に持っている引き出しの総数を増やすという意味で全然違うタイプだったり経験を持たれている方が入った方が結果としては良くなるだろうなというのは思いますよね。
そうですね、言うはやすしで採用は難しいんですけど。
採用も難しかったり、違ったタイプの人なんで意見がコンフリクトしちゃったりとかね。そういう難しさは当然あると思うんですけどね。
グリーンにかけない転職裏話ラジオ、略してグリテンラジオは、
転職アプリグリーンの運営メンバーが個人的一押し企業について語ったり、現場で感じる転職や中途採用のリアルについて話す音声番組です。
毎週月曜朝6時更新です。通勤や休憩時間のお供にぜひお聞きください。詳細はカタカナでグリテンラジオと検索してチェックしてください。
はい、なんとなく今ある状態だとか向かっていく方向とかが掴めてきたんですけれども、
じゃあこの組織をスケールさせていくっていう時に、やっぱりマネージャーが絶対考えなきゃいけない問題っていうのが一つあって、
それがチームをいかに分割していくのかっていうテーマですよね。これは本当にどの会社さんでも悩まれている問題なんじゃないかなと思うので、
ここについても上梨さんでどんなことを考えていらっしゃるのか、もしくはすでに取り組まれているのかとかあったら教えていただきたいです。
21:09
そうですね、今まさに絶賛悩んでいるところではあって、決まっていることとしてはシステムのうまく割れるところ、
説明面と専門用語だと言うかもしれませんけど、システムを割る、その割った後のシステムを担当するチームができる、
そのできたチーム間同士でコミュニケーションがそんなに必要なく、そのチーム内で開発から運用まで全て完結する、
エンジニア的な専門用語だと業種度が高いようなチームシステムの単位にしたいっていうところが決まっているところですかね。
なるほど、そうすると今の話だと、チーム当然分けようとしているし、システムの方も分けるというか、逆にシステムの分け方に沿ってチームを分けるっていうような戦略ということですよね。
そうですね、はい。
そうですね、そのシステムをどう分けるのかって、ちょっと組織の話、密接に結びつくんですけれども、よりエンジニアリング観点の話かなと思うので、
そこはちょっと次回また深掘って伺いたいなと思っているので、今回はより組織の方の話にとどめたいなと思っているんですが、
チームを分けるみたいな話をするときに、先ほどのお話だとコミュニケーションのパスが少ないとか、そういうところを検討されている。
この辺の話もチームトポロジーに書いてあることだと思うんですけれども、そういう一般論は僕も徐々に経験の中からも理解しているところがあるんですけれども、
上梨さんの今のプロダクトの作り方っていうか、何だろうな、事業のやり方っていうんですかね。
そういう中で、例えばものすごいチーム感でコミュニケーションしたほうがいいものが作れるって考えてる会社さんもあると思うんですよ。
その辺って上梨さんはそこはきっちり分けて、それぞれ閉じて気持ちよく開発したほうが、分けようとされてるものっていうのはうまく作れそうっていう感触も一緒に持たれてるんですかね。
感触は正直まだ持ててない気がしますね。
どちらかというと、今在籍されていたりする方々の過去の経験とかから、やっぱり一般的には10人未満が良いと言われてますけど、そういったところでチームサイズなどはなんとなく想像されているので、
24:02
上梨という会社内での実感値みたいなものはまだない気がしますね。
これから分けていくってところだと思うので、実感みたいなところは実際やってみてフィードバックを回しながら改善していくみたいなところなんですかね。
そうですね。
なるほど。チーム基本的には分けたほうがいいっていうのは僕も思っていて、小さいチームのほうが仕事しやすいパフォーマンスが出るっていうのはいろんなチームで見てきました。
とはいえ、あんまりネガティブな意見を言うつもりもないんですけれども、やっぱり分けることによるネガティブインパクトみたいなのもあって、この辺もどう考えてらっしゃるのかっていうのも聞いてみたくて、
それが何かっていうと、例えばチームを分けるとコミュニケーションパスが少なくなるように意図することが当然多いと思うんですけれども、
コミュニケーションしないことを良しとしてしまったりだとか、そういう考え方が暗黙的に生まれちゃったりすることも見てきたことがあって、
本当はちょっと話して解決したほうがいいんだけど、チームの中に局所化したような行動原理みたいなものが生まれてしまいがちだなみたいなことも思ったりするわけですよ。
そういうものに対する上梨さん的な、その辺はカルチャー的にOKなんだとか、チーム分かれてて独立してても全然大丈夫なチームだからとか、やってみないとわからない部分もあると思うんですけれども、何かありますかね。
そうですね、多分サイロ化とかそういうワードをよく耳にするので、そのリスクは非常に注視してるんですけれども、仮にチームを分けたときにその中で当時で意思決定をしたりしても問題ないことが、
単歩でいけないシステムの割りみたいなものが前提として今立ってきていて、その前提でシステム割ってチーム割った後にチーム間でコミュニケーションするところは正直まだ考え尽くせてないかなというのが実態なんですけれども、
一応そこは最近先を見越してではないですけど、CTOが主導して定期的に一堂に会して情報交換する場を設け始めたり、
ちょうど最近希望者の方を集めて勉強会みたいなやつとか外部講師の方を呼んでやったりとか、そこで考慮を図ったりとか、そういったチームが分かれてもちゃんと組織全体で情報交換できるような働きかけは徐々に今始めているっていうそんな感じですかね。
27:12
なるほど。じゃあ基本的にはチームを分けていくっていう方向性を持ちながら、さっき話したようなネガティブサイドみたいなものも当然認識されていて、それを補うような施策みたいなところも検討して実際実施されてるっていう感じですよね。
今のフェーズからそれぐらいやられてるのってかなりすごいなという気もしますね。
いきなり必要な場面に迫られてあたふたやるとちょっと間違いそうな可能性もありますし、SaaSを作ってる開発組織は巨大になる傾向があるっていうのは著名な方々もよくおっしゃられてるので、先を見越すとそういった方向性で検討してとか、やれることはとりあえず試しにやる。
先ほどのベータ版マインドではないですけど、そういうのを結構心がけてやってるのかなとは思いますね。
うん、確かにベータ版マインドなところも言われてみればその通りだなという気もしますし、あとチームを分割する問題ってどの会社にも出てくる問題ですし、避けては通れないんですよね。
なので、そこがかつソフトウェアにも結構影響がある逆コンベイ戦略みたいなところもあるので、早めに手を打っておけるなら打ったほうが当然いいので、そこはぜひ私たちも見習いたいなというふうに強く思いました。
はい、じゃあ今日はまず組織のところいろいろ聞かせていただいてありがとうございます。また次回、エンジニアリングとか事業のところを聞かせていただければなと思います。
はい。
今回、第1回目として宮本さんと上梨について伺いました。
率直な感想として、まだそれほどエンジニアリング組織として大きくないんですけれども、でもこれからスケールしていくっていうところに対してすでに手を打ち始めてらっしゃるっていうところが身の引き締まる思いがしまして、スタートアップだからそれはまだ考えなくてもいいみたいなところって思いがしたと思うんですけれども、
やっぱり後々聞いてくる問題っていうのも一方でわかっているので、それってきちんと早い段階から手を打っておくってことはマネージャーとして結構大事だなと思いました。
さて、この番組では感想や質問リクエストなどお待ちしております。番組詳細欄にあるリンクよりお気軽にご投稿ください。
TwitterではハッシュタグEM問題集をつけてツイートしてください。EMはアルファベット、問題集は漢字でお願いします。
そしてApple PodcastやSpotifyのPodcastではレビューもできますので、こちらにもぜひ感想を書いてもらえると嬉しいです。
30:02
お相手は株式会社株区スタイルCOO兼CTOの後藤秀典でした。
