見出し画像

meet CTOsvol.4 強力なプロダクトを支える技術組織づくりの壁

meet CTOsは第一線で活躍する先輩CTOを招き、さまざまな会社やフェーズで経験してきた知見をもとにセッションを行うイベントとなっています。

非連続な成長を遂げるために必要なエンジニア組織の創り方や、成長フェーズごとにCTOが担う役割や直面する課題など、ここでしか聞けないリアルな実体験を語る場となっています。

去る2021年10月22日には「meet CTOs〜vol.4 強力なプロダクトを支える技術組織づくりの壁」と題したイベントを開催し、Repro 執行役員CTOの尾藤正人さんやビットキー VP of Engineeringの山本寛司さん、タイミー 執行役員CTOの亀田 彗さん、Sun*のCTO’sに所属しイベントレジストのCTOも務める池田 大輔、モデレーターとして日本マイクロソフト 南澤 拓法さんの計5名が登壇しました。

各社が考える”強いエンジニア”の条件や、エンジニアの育成・採用、アトラクトし続けるための組織づくりについて議論を深めるイベントになりました。

エンジニアの適性がなくてもCTOは務まる

トークセッションの冒頭では、各登壇者の自己紹介が行われました。

ReproでCTOを務める尾藤さんは、大学在学中にVine Linux SPARC版を開発していた当時は「ビジネスに興味がなく、エンジニアリングだけやっていればいい」と考えていたそうです。

「転機になったのは、サンフランシスコへ語学留学に行った際に出会った山田進太郎(現メルカリCEO)さんでした。インターネットビジネスの面白さを学び、スタートアップに興味を持つきっかけになったんです。そこから、山田さんの立ち上げたウノウという会社に一番初めのエンジニアとしてジョインし、肩書きとしてはCTOという形で『フォト蔵』などのサービス開発に携わっていました」

その後は、起業や複数社の技術顧問を経て成長途中のUUUMにCTOとして参画。
エンジニア組織の拡大を牽引し、同社のIPOに大きく貢献しました。

そして今年6月には、シリーズCラウンドのフェーズを迎えているReproのCTOに就任しています。

これまでさまざまな企業での技術顧問やCTOの経験をしてきた尾藤さんは、「実はエンジニアとしての素養を総合適性テストで見ると、あまり向いていないという結果が出ている」とし、こう語りました。

画像1

「総合適性テストや職務適性などを客観的に分析すると、人との協調性がなく、かつマネジメントの考え方も合致しないような結果が出ているんです(笑)。ただ言えるのは、どんなにエンジニアに向いていなくても、これまで曲がりなりにCTOをやってこれたという事実があるので、文系理系の違いや技術未経験などはあまり気にせずとも、CTOは目指せるということです」

ベンチャーのCTOは3つの要素で構成される

ビットキーのVP of Engineeringを務める山本さんは、もともとロースクールを卒業後、非エンジニアからワークスアプリケーションズへ入社し、ERP製品の開発や評価に従事していました。

画像2

2018年にはビットキーの創業期に参画し、スマートロックのハードウェア開発などを行い、現在はプロダクト開発とエンジニア組織を統括しています。

そんな山本さんですが、「ベンチャーのCTOは主に3つの要素で構成される」と説明します。

①技術責任者
②製品責任者
③エンジニアリング組織/文化/採用

これら要素の得意・不得意や会社として必要か否かという状況に応じて、要素ごとのバランスが異なってくるとのことです。

「私の考えとして、前述の要素のバランスとキャリアのラベルのマッピングは、企業が成熟すると①技術責任者→CTO、②製品責任者→ CPO、③生産性(エンジニアリング組織/文化/採用)→VPoEにロールが分けられると思っています。なので、ベンチャーにおけるCTO/CPO/VPoEは全て広義の意味でCTOになるわけです」

山本さんにとっての一番大きな壁は、最初のプロダクトリリース前のことでした。

ファームウェア開発ロールの漏れに気づき、自身が書いたことのなかったC言語とひたすら向き合い、キャッチアップしながらコードを書いていった苦い経験だったそうです。

「なんとか製品が動くところまでこぎつけて一安心しましたが、人生で一番働いた期間だったと印象に残っています」

会社のフェーズごとに大きな壁が存在する

タイミーのCTOである亀田さんは、自身の大学時代を次のように振り返りました。
「大学時代はアニメーターになりたいと思っていました。そこから、絵が動くのが面白いと思うようになり、ゲーム開発へ興味を持つようになったんです。そして、サービス開発をやってみたいという思いから新卒でピクシブに入社しました」

タイミーへはシリーズAのタイミングで、CPOとしてジョイン。
昨年8月からはエンジニア組織や技術戦略を担うべく、CTOとしてロールを変更して今に至ります。

亀田さんは、スタートアップならではの激しい環境変化への適応に対して壁を感じている部分があると言います。

画像3

「事業をグロースさせるための破壊的かつシャープな意思決定ができなかった時期がありました。また、メンバーに向けても、権限移譲とアライメント調整の塩梅をとるのが難しかったこともあります。日々学びながらCTOとしての役務を担えるよう尽力していますね」

Sun*のCTO’sに属する池田は、大学時代にインターネットと出会い、新卒で大手SIerへ。

電子署名システム日本向けローカライズを担当したのち、ヤフー株式会社にてコマース関連の開発に従事していました。

2011年よりEventRegist(イベントレジスト)」のファウンダーCTOとして参画し、 今年からSun*にも関わっています。

大手SIerや事業会社、スタートアップなどさまざまなフェーズを経験してきた池田は、「会社の規模に応じて、相応の壁が存在する」と述べます。

「エンジニア組織が1~10人のときは、CTOはリーダー兼プレーヤーになることが多く、組織マネジメントよりもとにかくコードを書くことが優先される。開発から保守、運用まで全てこなしながら、とにかく前に進むことだけ考えるような体制になりがちだと考えています。次いで、10〜100人規模になると今度は意思疎通の問題が生じてきます。オンボーディングや部署の役割分担、ドキュメント化、情報共通ツールの整備など、組織マネジメントも重要になってくる。よく起こるのが、保守よりも事業成長のスピードを優先することで、『Dev vs Ops』の構図が生まれ、技術負債が蓄積されてしまうのもこのフェーズの特徴です」

100人を超える規模になると、マネジメントが2階層になり、組織づくりがさらに大変になってくると池田さんは続けます。

「社長のビジョンの共有や事業の状況を全社MTGやクォーターごとの締め会などでしっかりと浸透させられるよう、メンバー一人ひとりに伝えるための工夫と投資が必要になってきます。また、採用や育成、人事評価など人にまつわる課題が多くを占めるので、マネージャーの育成も重要になります。私自身、標準化やルールの明文化、エンジニアのスキル管理などは上手くできなかったので、今日のディスカッションでも学びを深められたらと思っています」

技術力よりも周囲との協調性があるかどうかが大切

ここからはメインのディスカッションのパートに入っていきます。

モデレーターの日本マイクロソフト・南澤さんが、事前にいただいた質問からピックアップした内容をもとに各登壇者へ意見を伺っていきました。

まず最初は「強いエンジニアの条件について」です。
フルスタックエンジニアなどの言葉も昨今は聞かれ、ハイパフォーマーな人材ほど引き手数多な状況となっているわけですが、必ずしも「技術力=強いエンジニア」と言えるかというと、そうでもありません。

会社の求める要件や成長スピード、提供するプロダクトのターゲットなどによっても変わってくるので、一概に定義付けするのは難しいでしょう。

本セッションに登壇の各スピーカーはどのような捉え方をしているのでしょうか。

画像5

尾藤さんは「どんなに優秀でも、なんでも意見を押し通そうと主張が強いタイプの人材は生産性を下げる原因を作ってしまう」と話します。

「個人の技術力やエンジニアリングの知識も大事ですが、どんなに才能が秀でいても、周りと協調しながらやっていけるかが大切になります。

チームと協力せずに個人プレーで突き進んでしまえば、ハレーションリスクが高まりますし、事業成長の足かせにもなりかねない。協調性を持って、周囲のメンバーと対話しながらプロダクト開発に携われることが求められると思います」

亀田さんは「いろんなフェーズであっても、アジャストしながらついてこれる人が強いエンジニアだと思う」と意見を述べました。

「プロダクトリリースや資金調達など、色々な時間軸を通してDevOpsを回してきた身からすると、インフラやビジネスモデルに影響を与えるようなことでも、物怖せずに乗り越えられる人材が強いエンジニアの条件に当てはまるのではないでしょうか」

対して山本さんは「フェーズによって異なるものの、最後まで志持ってやり抜く姿勢も大事」という見解を示しました。

「創業期はハードシングスの連続で、辛い時期を経験することも大いにあるでしょう。だからこそ、軽度のハレーションが起こることを躊躇せずに、自分でゴールを決めたものをやりきってしまうような『意思』も重要になってくる。技術の変遷は激しく、常にキャッチアップしなければならないので、自分のバリューに対して確固たる意思を持ち、柔軟に取り組める人が強いエンジニアの候補になると考えています」

画像6

池田も「その会社のビジョンや事業に興味があり、楽しんでやれるかどうかが肝になる。マーケティングやセールス、デザイナーと各方面のメンバーと協調しながら仕事をする姿勢や、人と一緒に働く謙虚さを持つ人材が、会社にとって必要とされるエンジニアになると思う」と語りました。

エンジニア採用は確率論でしかないので失敗はつきもの

また、エンジニア採用についての話題も挙がり、これまでの経験知を共有する形となりました。尾藤さんはエンジニア採用についての考えを次のように吐露します。

「採用はある種、確率論だと思っていて、失敗はつきものだと捉えた方がいい。採用面談の1時間で判断するのは結構難儀なところがあるからです。一方で、いくつか見極めるポイントはあって、技術力に関して面接に来た人へ深掘りしたときに『自分のわからないトピックを、その場しのぎでなんとか乗り切ろうとする人』は、採用しないようにしています。自分ができないこと、わからないことをはっきり言えない人は、組織の中でトラブルの原因になるケースもあるので、Yes/Noがしっかり言えるかどうかは見ていますね。

また、技術に興味のある人は、周辺知識も勉強しているので専門用語を正確に使えますが、理解が浅いと、使い方を間違っていることがある。浅はかな知識ではなく、本気でエンジニアリングをやりたいかどうかも採用時には重要視しています」

池田も「事実と主観的意見を切り分けられない人は採用しないように留意している」と述べました。

画像7

亀田さんは駆け出しエンジニアの採用について、「表面的な機能を作ることに面白みを感じている段階から、プログラミング言語やアーキテクチャに面白みを感じる段階は、に大きなギャップがあると思っておりこのギャップを超えることができそうか?は重視しています。また、何か成果物を作っていても、何かしらのテンプレートから引っ張ってきたような事例が散見されています。そのため成果物のクオリティだけではなく、利用した技術について構造的に説明できるかを大切にしています。」と経験談を話しました。

アトラクトへ繋げるには、エンジニアのキャリア特性を理解すること

続いてのテーマは「エンジニアをアトラクトし続けるために努力していることは?」です。
エンジニアにとっての最良な環境づくりはどのようなものなのでしょうか。

尾藤さんは「前提として、原理原則を理解しておく必要がある」と言います。

「会社で働いたら、数年後に転職するというエンジニアのキャリア特性を理解することがまず第一です。エンジニアはどう考えているのかと言えば、『転職後に自分のスキルと年収がアップしているか』ということに尽きるでしょう。こういう背景を理解しながら、会社で活躍してもらえるような環境を用意することが肝要になってきます。これは私の考えですが、人事制度を作るときは『会社への事業貢献度』と『個人の成長・能力の評価』は50:50がちょうどいいバランスだと思っています」

亀田さんは、新しく採用できたVPoEがメインとなってエンジニアリングマネージャー(EM)組織を立ち上げ、キャリア支援やスキルの成長支援で上手くワークしている事例を挙げました。

「タイミーでは、VPoEがフルでピープルマネジメントを担う体制になっています。モチベーション管理やキャリアの観点から1on1を実施したり、壁打ち相手になってもらったりすることで、エンジニア一人ひとりと向き合える体制を整えています。さらにエンゲージメントを高め、いいエンジニア組織を作れるようにしていければと思っています」

また、エンジニアのアトラクト要素として、よく挙げられるのがリモートワーク環境の整備です。

コロナ禍によって、オフィスに縛られずに仕事をするのが一般化しつつありますが、採用に関してはどの程度重要視されるものなのでしょうか。

尾藤さんは「コロナ禍でリモートが当たり前になった今、出社を前提にしてしまえば、採用競争力で劣ってしまう」と説明します。

「私は経営陣とMTGがあるときだけ、週2~3日出社しています。というのも、私だけオンラインで参加しても、コミュニケーションが取りづらく、経営層との意思疎通が図れないからです。でも、出社することをエンジニアに強制するのは違うと思っています。もちろん、オフラインの方がコミュニケーションを取りやすいのは事実ですが、採用のことを考えると、リモート環境を整えるのが必須ですね」

他方で、ビットキーでは出社を基本にしているそうです。

エンジニアが顔を合わせて仕事をすることで、どのような相乗効果が生まれているのでしょうか。山本さんは次のように出社の狙いを語ります。

「ビットキーの場合、ハードウェアとの行き来によってバリューを出す会社なので、扱うプロダクトが実物である以上、出社して対面でコミュニケーションしながら進める方針を取っています。それゆえ、基本は出社を原則(緊急事態宣言下はフルリモート)としていますね。チームみんなで集まることで、コミュニケーションを活発化させ、良いプロダクトをスピーディーに作るために、メンバー同士で肩を組みながら進めるという機運を醸成できていると思います」

CTOは会社にとって有益な資産を作ることにフォーカスする

最後の3つ目は「事業をドライブしていくことと、組織づくり(体制強化)のCTOの割合」というテーマで、議論を深めました。

どちらも非常に重要ではあるものの、比重を置く割合については会社ごとに異なってくるでしょう。

亀田さんは「期初や四半期などのタイミングで経営と認識合わせ、期中に組織運営を考えている」というのを意識しているそうです。

「現在、組織運用に関してはVPoEに移譲できているので、エンジニア組織の方向性の擦り合わせだけ入るようにし、そのほかは事業やプロダクト戦略などの上流部分を考えるようにしています」

画像8

山本さんは「組織づくりにリソースの大半を寄せ、良いプロダクトを作ることに振り切っている」と述べます。

「事業ドライブとプロダクト組織を見る割合は1:9で、プロダクト組織を重点的に見ています。価値あるプロダクトを生み出せるかということに真剣に向き合うことで、ある種いいものを作れば自然とセールスも売りやすくなると思っているからです。エンジニアのキャリアとして3年で転職し、バリューアップしていくのが日本の構造だとすると、ものづくりを通してエンジニアの成長を阻害せず、自己実現をかなえられるような組織づくりを目指したいですね」

尾藤さんは「会社にとって有益な資産を作ることにフォーカスすることが大切」と示し、セッションを締めくくりました。

「個人的には事業部の数値目標は持たない方がいいと思っています。プロダクトの質を高めても売上向上に寄与するとは限りませんし、開発は長いスパンかけて行うことから、中長期目線で物事を考える必要性があるからです。一方でセールスは売りを立てるために、短期的な目標を掲げるため、開発組織とセールスの間で目線が合わなくなってしまう。そういう意味では、マーケター視点やプロダクト思考を持ち、事業をドライブさせることよりも組織づくりを重要視した方がいいのではないでしょうか」

今後もmeet CTOsでは、さまざまなCTOをお招きしたセッションを行っていく予定です。乞うご期待ください。


この記事が気に入ったらサポートをしてみませんか?