【estie CTO岩成氏】マネジメントが事業のキャップにならないために。「事業部CTO制」による組織改革とエンジニアのこれから
Offersでは、あらゆる業界の開発スペシャリストをお招きし、これまでのキャリアや経験を深ぼることで、企業を超えて開発の実践知をつなぐ「#開発の実践知をつなぐ」というインタビュー企画を行っております。
第2回では、株式会社リクルートでエンジニア経験を詰み、学生時代には起業された経験も持つestie CTO岩成氏ををお招きし、これまでのキャリアや現在の組織開発の考え方について深掘りします。
株式会社estie 取締役CTO岩成達哉
松江工業高等専門学校で情報工学を学び、高専在籍時に開発したプログラミング教育教材をもとに東京大学工学部在学中に起業。修士課程修了後Indeed Japanに入社し、ウェブ上の求人募集情報を集めて提供するデータパイプラインの開発に従事。2020年10月にestieへVP of Productsとして参画し、2021年8月にCTOへ就任。開発部門を統括してプロダクト連携の設計や、新規プロダクト開発、プラットフォームづくりを行う。
高専でのプログラミングとの出会い
私がプログラミングを始めたのは遅い方です。島根県の松江工業高等専門学校の情報工学科に入り、プログラミングを始めたのが最初のきっかけでした。
中学生の時に「自分は理数の方が楽しいな」と思ったことがきっかけで、高等専門学校に入学しました。地元の島根県は田舎で中学校の理数科に進学するといえば医者になる人が多いのですが、自分は医者には向いてないと思い医学ではなく工学の道に進みました。
4年生までは授業の1つとしてプログラミングを学んでいたのですが、全国高専プログラミングコンテストというものがあり、初めて授業ではないプログラミングを知って、そこから「ものを作る」ということが楽しいなとプログラミングに目覚めました。
高専では5年生で卒業研究のようなものがあり、そこでは子供向けの教育用プログラミング教材を作りました。ビジュアルプログラミングという、タブレット上にブロックを並べるとプログラミングができるというコンセプトがあるのですが、私がつくったものはボタンを押すとそのプログラムが実行できてロボットが実際に動くものでした。
自分なりに上手くできたこともあり、 ローカルなビジネスプランコンテストに出したところ、学生向けの賞もいただくことができました。その時に使っていたロボットがレゴ®社のマインドストーム®という教育用プログラミングで、コンテストの審査員の方に東京の代理店を紹介していただけることになり、東京の大学進学も重なり、そこから継続してプロダクト作りをやり続けています。
またそれを発展させて学生時代にチームを作り起業しました。そこでは、小学校低学年〜中学生向けにプログラミングの考え方を教えるという事業をやっていました。
プログラミングを学んだからといって、みんながプログラマーになる必要はなく、英語や数学と一緒で、使えたら便利な道具だと思っています。授業を通してそれを教えられたらいいなという想いで立ち上げました。
しかし、高価なハードウェアを使っており、初期導入コストがかかり、当時サブスクリプションモデルがあまりなかった時代なので、マネタイズする仕組みを構築しきれず、事業をスケールさせることの難しさに直面しました。その会社自体はまだありますがチームはゆるゆると解散していきました。
そこから株式会社リクルートのグループ会社に当たるIndeed Japanで3年半ほど、求人関係の検索サイトのソフトウェアエンジニアを経験していて、現職の株式会社estie（以降、estie）はその間副業でエンジニアとして開発のお手伝いを始めた場所でした。副業をしていくうちにだんだん楽しくなってきてestieに入社した、というのが流れになります。
estieに入社した時はVPoEがすでにいたことと、元々私自身が事業やプロダクトを作っていく力を伸ばしたいという思いがあり、最初はVPoPとしてエンジニアリングではなくプロダクト全般を見ていました。その後、プロダクトよりもエンジニアリングに力をいれる必要性が出て、現在は2年半前からCTOをしています。
マルチプロダクト戦略下にて「事業部CTO制」を導入
2020年10月に入社した頃は事業は1つしかありませんでしたが、2022年1月の資金調達時にestieではマルチプロダクト戦略を始め、2つ目の事業を立ち上げました。私がCTOになったのは、その間の2021年8月頃になります。
最初は2つ目の事業の立ち上げを自分でやっていましたが、上手くいかなくて撤退することになりました。ただ、そのプロダクトのコンセプトをピボットしたものを別のメンバーが担当するようになり、2つ目の事業部を立ち上げました。
事業を成長させるためには、事業を深く理解してちゃんと向き合うことが重要ですが、当時の私は既存事業とピボット前の事業の整理を並行して見ていたこともあり、その事業部にはあまりタッチできていない状況でした。このまま私がCTOとして意思決定をし続けてしまうと、しっかり見切れずに自分が事業成長の足止めになりかねないと感じ、「事業部CTO制」を導入することを決めました。
事業部CTO制は、事業部ごとにCTOを立てて、事業部運営に必要な権限委譲を行い、部内で技術的な意思決定をすることで、事業作りのスピードを加速することを目的にしたものです。
事業部CTOと聞くと、新しくポジションを設けたように聞こえますが、私たちにとっては新しい事業部でプロダクト開発をしていたエンジニアリングマネージャーが元々やっていたことに名前を付けただけという感覚です。
名称と定義を作ることで役割を明確に
役割に名称をつけたことにより、キャリアパスが明確になりました。
スタッフエンジニア（技術的な専門知識や経験を保有し、チームやプロジェクトの技術的な方向性をリードする役割を持つ）の役職を設けた時もそうでしたが、スタッフエンジニアという名称がつくことによって、役割が明確になり仕事を任せやすくなりました。周りのメンバーも、「こういうキャリアパスがある。」「こういうことを頼まれるんだ。」というのが分かりやすくなり良かったなと思っています。
事業部CTO制の導入は、それ自体にハレーションが起こることはありませんでした。ですが、役割の定義が抽象的なものに関しては、改めて何を期待し任せるかというのを明文化する必要はあると考えています。
例えば、CTOという役割自体はそもそも誰もが共通認識を持っているため、チームメンバーにすんなり受け入れてもらえたと思っています。しかし、スタッフエンジニアは例える対象がなくアナロジーが効かないため、しっかり定義付けをしていきました。
事業フェーズによって求められる役割も変わる
また、この役割は事業フェーズによっても異なります。例えば、スタッフエンジニアは「技術的に全社の横断課題を解く」ということがわかりやすい一方で、逆に事業部CTOはフェーズによって大きくやることが異なります。
実際に、新しく事業部を立ち上げた時に、3人しかいないようなフェーズにおいて、何するんだっけ？と混乱が生じたこともありました。
今は事業部CTOの役割をフェーズごとに言語化し、1枚のドキュメントにまとめています。例えば、数人の事業部であればマネジメント対象者が少ないため、どちらかというとテックリード的な役割が大きくなります。そこから事業規模も大きくなるタイミングで、エンジニアマネージャーが必要になる。さらに事業が拡大してくと、複数のプロダクトやユニットをみる事業部CTOの存在が必要になっていきます。これが言語化されたことにより、1つのキャリアパスを整理できた状況になったと思っています。
これらの思想の前提として弊社が大事にしてるのは、誰かが組織のキャップにならないようにしたい、ということです。事業部CTOを設けた理由の一つとしても、自分が組織のボトルネックになることへの課題感から導入を決めました。これは、どの職種もマネジメントレイヤーが気をつけるべきことだと思います。
誰よりも事業領域の課題を愛せるか。頼れるエンジニアとは
頼れるエンジニアとは、「任せられている領域について自分よりも考え抜いていること」だと思っています。「この辺ってちゃんと見えてるんだっけ。」とメンバーへ質問することがありますが、その時にちゃんと考えが返ってきて、自分よりも確実に時間を使って考え抜いているな、と思えた時に仕事を任せたいなと思います。
そのためには、事業領域にある課題を誰よりも愛せるか、その課題にある意味でクレイジーになれるかということも必要な要素だと感じています。「エンジニアリングマネージャー」や「エンジアリングなんとか」と名前がついた時に、エンジニアリングだけの側面を見て課題を解決しようとするのでは、少し物足りなさを感じますね。
例えば、開発チームの生産性が劇的に改善したとします。この取り組み自体は素晴らしいのですが、実際にそれが顧客にとって必要のないものだった場合、タイヤが空回りしてる車みたいなものだと思うんです。
そのため、本当の意味でパフォーマンスを発揮するのは、実は自分の領域をはみ出して最大の結果を出す方法を考えられていることだと思います。
実際に今の事業部CTOには、技術課題を解くだけではなく、事業課題としてどういうものがあるのか、なぜこういうものを作るのかというWHY/WHATも含めて、考え抜くことを期待しています。
パーパスへの登り方は、事業部に任せている
estieの場合は、「Whole Product構想」というどういったプロダクト、事業があるかを表した地図のようなものがあります。（下図参照）
しかし、これをどこからどのように創るかというロードマップは厳格には決めていません。 「産業の真価を、さらに拓く。」という会社としてのパーパスはありますが、どういう順番で、どんな方法で達成するのかは、事業部それぞれが考えて目標とする山を登ってもいいようにしています。
パーパス自体が抽象度が高いため、メンバーが言語化できるようにし、自分がいいと思うものをそれぞれが走らせていいといった組織を創りたいと思っています。
株式会社estieの最新会社説明資料はこちら
肩書きの壁を作らず、できることを広げていく
エンジニアはエンジニアリングに限る課題だけではなく、ビジネスまでを含めた「なぜ、何を作るのか」という視点が必要だと考えています。この考え方ができるかどうかで、自分が挑戦できる領域が決まります。実際に、プログラマーではなくソフトウェアエンジニアと呼ぶことにも1つの意味がありますね。領域が大きい方が何でもできて、楽しいはずです。
ただ一方で、エンジニアリングの特に技術部分で、領域に特化するというのもやはり尊いことだと思っています。そのため、そういった夢中になれるというか、どう課題を楽しむかも、エンジニアリング的な考えにおいてやはり重要なのかなと思います。
「エンジニアはHOWを解く」という表現や、「HOWを担当する」という表現があまり好きではありません。私にとってエンジニアとは、どういう課題を、どう解くかみたいに、全部を課題としてとらえその課題を解く人たちなんです。実装を担当しているのですが、WHYやWHATからきちんと考え直し定義をすることで、良いHOWに辿り着けるはずです。
そのため少し概念を広く捉えること、自分の対象領域を広く捉えることが、重要だなと思っています。
- 岩成さんありがとうございました。
[PR] Offersでは、開発者のための副業・転職を支援するサービスを提供しています。転職や副業を考えている方はぜひ、ご利用ください。
また、「リアルな現場を読み解き、明日へのヒントを導く」をコンセプトにconnpassでのイベントも開催中です。 こちらもぜひ、ご覧ください。
この記事が気に入ったらサポートをしてみませんか？