カルチャーの進化
プログラムを作ることと組織作りはよく似ている。
fluct CTOが挑むプロフェッショナルが育つ仕組みづくり。

大渡 裕太
Yuta Owatari
株式会社fluct CTO
入社4年目、たった3人で挑んだ「絶対に止められない」システム移行
―新卒でCARTA HOLDINGSを選んだきっかけは何でしたか。
現場のエンジニアたちから感じた「圧倒的な格の違い」です。インターンやイベントで実際に話をさせてもらった際、彼らの姿勢に衝撃を受けました。
10年以上のキャリアを積んだエンジニアが何人もいて、それぞれ尖っているのに、その技術力をひけらかすことが一切ありませんでした。「あなたはどう思うの?」と必ず対等に意見を聞いてくれるし、学生相手でも同じ土俵で向き合ってくれる。引き出しの多さと、一つひとつの言葉から感じられる格の差を感じて「この人たちと試行錯誤できる環境なら、技術的にすごいエンジニアになれる」と確信し、入社を決めました。
― エンジニアにも様々な専門領域がある中で、最初にインフラを選んだのはなぜでしょうか。
実は大学を2年留年していて、当時は2年分のキャリアの遅れをどう挽回するか真剣に考えていました。巻き返すなら自分が得意な領域に注力するしかない。当時の私にとって、それがシステムの土台を支える「インフラ」でした。 この領域だったら周りの人たちよりはできる自信があったので、インフラを軸にしながら幅を広げていけそうなCARTAを選びました。
直感は当たっていたようで、ありがたいことに比較的早い段階で難易度が高く規模も大きいプロジェクトに携われるようになりました。
― 特に印象に残っているプロジェクトを教えてください。
入社4年目に担当したデータセンターからクラウド基盤への全面移行でしょうか。
当時、数百台の自社サーバーで運用していた広告配信システムは、物理インフラ特有の運用負荷や、将来的な拡張性の限界という課題に直面していました。ちょうど世の中にクラウドインフラ(クラウド上でサーバーを調達・利用可能なプラットフォーム)が普及し始めており、弊社でも導入を検討していました。
あるインフラトラブルの際に、わずか1日でクラウドへの移行および仮復旧を成功させた実績から「クラウドなら状況に左右されない圧倒的なスピード感が得られる」と確信を得ました。その後、データセンターの拠点見直しを機に経営陣と事前に合意形成し、クラウドインフラへの全面移行へ舵を切りました。物理インフラに比べてサーバーの調達面でも優位なため、「将来のアジリティ(柔軟さ)を買う」という考え方から至った結論でした。
エンジニアである私たちのミッションは、月間数千億のトラフィックを支える基盤をサービスを1秒も止めることなく最新のクラウド環境へ本格移行すること。止まれば数千社のお客様の収益が消滅するため、絶対に失敗は許されません。
複雑化した構造を一つずつ紐解き、稼働させたまま基盤をそっくり丸ごと入れ替える。まさに「飛行機を飛ばしながら直す」ような前例のないプロジェクトでしたが、私たちは大きなトラブルを起こすことなく、わずか3人のミニマムなチームで完遂しました。
この経験は、今でも大きな自信になっていますね。

人にはいろいろな成長の仕方がある、と気付くのが遅かった
―そうして現場の最前線で技術を磨く中で、 ご自身はどのような志向を持つエンジニアになっていったのでしょうか。
当時は、自分の手で完璧にやりきることや技術者として技術力を高めていくことを最優先とする考え方をしていました。
ビジネス側から「こういうことがやりたい」と言われたら、技術的にどう実現するかを考えて作って返す。でもその先にあるビジネス的な価値(どの数字が動くのか、今後事業がどう伸びていくのか、エンジニア組織としてどうレバレッジを生み出すか)にはあまり関心がありませんでした。つまり、視野が技術に閉じていたんです。
また、いわゆるマネジメント側にキャリアを伸ばしていきたいとは思っていませんでした。ビジネスで人と何かをやり遂げる比重よりも「技術者としてプロフェッショナルになる」そういう感覚が強くありました。「エンジニアはコード書けてなんぼでしょ」というか。
― キャリアの中で、意識が変わった転機はありましたか。そのきっかけを教えてください。
自分にとっての当たり前は、他人にとっての当たり前ではない。そう考えるようになったことが転機になりました。
たとえば、私にとっての「普通や当たり前」とは、わからない技術があれば勝手にコードを読み漁り、何時間かけてでも中身を理解してボトルネックやバグを解明すること。それが純粋に楽しかったから、「なぜみんな、こんなに面白いことをやらないんだろう?」と不思議に思っていました。だから当時は、同世代や後輩のエンジニアがキャリアについて悩む様子をみて、「普通にやるべきことをやっていれば、勝手に成長するんじゃない? 」と本気で考えていました。
それだけでは視野が狭いのではないか、と気づき始めたのが入社6〜7年目、確信したのは8年目です。さまざまなプロジェクトや場面を経験する中で自分一人の力には限界があると悟り、人と価値を生むことや人を育てることに徐々に視点が移っていきました。
―自分の技術力を磨くことに加え、人との協働や成長についても関心を持つようになったんですね。
そうですね。同じ組織に長くいると、何度も人の成長を見届けることになります。成長につながるはずの経験を積んだとしても、その伸び幅には揺らぎがある。そのパターンが繰り返されるのを見て、個人に原因があるわけではないと思うようになりました。
ちょうどその頃、先輩との会話の中で「どうやったら良い組織が作れるんだろう?」という問いに出会いました。「良い組織」を今振り返って定義するなら「高い基準と自律性を持つプロフェッショナル集団」とでもいいましょうか。振り返れば、自分自身の成長も、先輩たちとの対話や機会の中で生まれた偶然の中にあったんだろうな、と思っています。そして同時に、今までの組織は、個々の自主性を尊重するあまり、「自律的なプロフェッショナル」への歩みを本人の意志と偶発性に委ねていたことにも気が付きました。
―その課題感はどこから生まれたものだったのでしょうか。
組織づくりに意識が向き出した直接のきっかけは、当時の「現場の危機感」からくるものでした。というのも長く現場を支えてくれたシニアエンジニアが続けて離れ、相対的に若いメンバーの比率が増えていく局面にありました。優秀な人の卓越に頼るやり方には再現性がない上に、それでは組織としての堅牢さに不安が残ります。「どうにかしないと組織として立ち行かなくなるのでは」という危機感がありました。

趣味のゲームで「場を設計することで人の成長を促せる」と気づいた
―その課題感に対して、どう向き合ったのでしょうか。
まずは「どうしたら自律的に動けるプロフェッショナルを再現できるのか、そのための仕組みを作るにはどうすればいいのか」を考えました。その原因は、個人の努力ではなく、組織やその文化や環境の問題だと考えるようになりました。そう思うようになった一つの要因は、実は趣味のゲームです。
MMORPG(複数人でプレイするオンラインRPG)には、ビジネスの組織運営と非常によく似た構造があります。ゲーム内の最高峰の目標をクリアするためには、その場限りの即席チームでは通用せず、長期的なプロジェクトチームを組む必要があります。そこでは、メンバーの「採用」や「育成」、スケジュールなどの「進行管理」が日常的に行われています。
ハードルが高いからこそ、成果だけを求めすぎるとメンバーが疲弊してしまいます。そのため、チームの連帯感を強めるための関係性のメンテナンスや、相互理解を深める場を意図的に組み込みながら、「全員が主体的に楽しみ、かつ実力を高め合える環境」をいかに設計するかがチームの成否を分けます。結果として、ゲームの枠を超えた、ビジネスさながらのリアルな組織マネジメントが不可欠になっていきます。
その経験で得たことを実際に自分が所属している組織とその現場で適用していくことにも関心が移っていきました。
その頃から、それまで一部の人の中で暗黙知だった”高い基準”を組織全体で共有できる言葉にし、誰もが自分の判断のよりどころにできる判断軸として全員で体現できる組織を作ることで、「プロフェッショナルを再現できるのでは?」と考えるようになりました。組織全体に影響を波及させるには、それを統括する立場になるのが近道です。そのためには自分が手を動かして解決するスタイルから、組織が自律的に動く仕組みを作る役割へのロールチェンジが必要でした。
―ここまでのエピソードはマネジメントを志していなかった若手時期と比べると意外な印象です。技術畑から組織の課題に踏み込むことに、抵抗はありませんでしたか。
抵抗はあまりなかったですね。それは岩田聡さんの影響が大きいです。任天堂の社長を務めたスーパープログラマーですね。
ゲーム好きだったこともあって、ある時期から岩田さんのエピソードを読み込んでいました。たとえば、頓挫しかけたプロジェクトを「このままだと2年かかる、自分が0からやれば半年で出来る」と実際に半年で立て直したり、社長になっても社員全員と面談し組織づくりにも本気で向き合っていたり。時間に制約がある状況でも、成果を独力で出すのではなく、まず周囲が働きやすい環境を整え、その上でみんなで成果を出せるようエンジニアとしてリードする様が印象的でした。
岩田さんの 「プログラムを作ることと会社経営はよく似たところがある」という言葉に出会ったとき、「すごいエンジニア」の輪郭が自分の中で広がった感覚がありました。 技術で尖ることだけがゴールじゃない。プログラマーの思考法で、組織や経営にも向き合える。「テクノロジーでカッコつけたいじゃん」と思っていた自分も、岩田さんのエピソードを知って「社長になっても”技術でリードするエンジニア”を体現できるんだな」と思えるきっかけになりました。
ただ、「わかる」と「できる」は違うんですよね。岩田さんの”すごさ”は圧倒的な技術力に支えられています。だから「まずは自分も技術で突き抜けないとその先には行けない」と思っていました。技術力といわゆる人格的な側面の両方が培われるまでに10年近くかかったのだろうな、と今では思います。

自律的なプロフェッショナルを再現して生む場を作る
― そうした葛藤や気づきを経て、実際にfluct CTOに就任したわけですが、どんな過程や想いがあったのでしょうか。
前述したシニアエンジニアが抜けていく状況の中で、技術の中核を長く見続けてきた数少ない一人が自分でした。比較的近い距離で現場と経営の状況を捉えているうちに、「いまこの状況を立て直していけるのは、おそらく自分なのだろう」と思うようになり、自分から開発本部長に手を挙げました。
また、当時はちょうどCARTA HDが立ち上がり、fluct CTOであった鈴木がCARTA HOLDINGSの全社CTOに就任しました。そのため、fluctのCTOは一時的に不在の状態になっていました。とはいえ、fluctの組織内に「次のCTOを立てる」という流れがあったわけでもありませんでした。
本部長を一年ほど務める中で、「この立場にいる以上、自分が組織を統括して、次の世代を生み出すしかない」とハッキリと気持ちが固まっていきました。そこで改めて、自分からfluct CTOを引き受けることを決めました。
―そんな想いの中、CTOとして自律的に動けるプロフェッショナルを再現するために、まず何から手をつけたのでしょうか。
fluctのエンジニアの多くは、新卒で入って事業と一緒に育ってきた人たちです。中途で即戦力を採るだけでなく、新卒入社から育てることも大切にしてきた組織です。だからこそ、人が育つ過程により再現性を持たせること が、組織としての一番のレバレッジになると考えています。
人を変えようとしても変わりません。でも、みんなが立っている土壌を整えれば、人は自分から動けるようになるはずです。だからいきなり人に向き合うのではなく、仕組み側を整えることにしました。
判断軸が明確なら、人は自律的に自分の判断で動けると思っています。小さな組織であれば、たとえ判断軸が暗黙知でも自然と揃います。一方、人数が増えると個々が持つ判断軸のばらつきは広がっていきます。すると、次第に「誰かが決めるのを待ち、自分の持ち場以外には関心が向かない」といった空気に近づいていく。 これは、拡大する組織であればどの組織にも起こり得ます。
だからこそ、共通の判断軸を掲げ、それに沿って自ら考え自ら動く人を増やしていく必要があります。そのためには型どおりのルールではなく、自律的に動く前提を整えるための判断軸が必要です。
―具体的にどのような仕組みを作ったのでしょうか。
まず、fluct Tech Boardという意思決定の場を作ってCTOに集中していた実行のオーナーシップを分散し、各マネージャーやリーダーの役割の輪郭をはっきりさせました。
また、fluctの全エンジニアで共有したい価値基準やコアバリューを決めて公開しています。特に5つのコアバリュー「Be Public」「自ら巻き込む 」「パーツではなくオーナーであれ」「曳光弾を放ち、道筋を照らそう」「歩き続ける」は組織の中ですでに浸透し始めていて、同じ言葉を使い合うことで自律性を培うための判断軸を醸成しています。
上段を決めて敷設するだけでは足りません。価値基準やコアバリューの浸透を担うコンピテンシーリーダーも決め、掲げるだけでなく現場で運用される体制も作っています。また、エンジニア組織全体のふりかえりの機会を以前よりも増やし、一時期は30人近いエンジニア全員と1on1もしていました。個人の成長に寄り添うと共に、対話を増やすことで彼らが立つ土壌をよりよく改善する糧にするためです。
そうやって下地を整え、自己判断できるエンジニアを増やしていくことで、プロフェッショナルが再現して生まれやすい場を作るトライを行っています。

自分が育った楽しい場を、次の人にも渡したい
―「環境を整える」という、一見すると地味で根気のいる営みにそこまでエネルギーを注げるのはなぜでしょうか。
自分が成長させてもらった環境を、もっとみんなが仕事を楽しめる場所に変えていきたいという責任感があるからです。楽しさを渡すって、ただ「居心地のいい場」を用意することじゃないと思っていて。自分で考え、自分で判断し、自分の仕事に誇りを持てる。そういうプロフェッショナルが育つ土壌ごと渡すことで楽しい場が作れる、そう思っています。
突き詰めると、恩返しみたいなものかもしれません。自分が楽しんだので、後続の人たちも楽しめれば良いな、と。どうせ仕事するなら楽しくやれたほうがいいですよね。
―そのこだわりの根っこには、何があるのでしょうか。
この12年間、自分は今の現場で楽しくやらせてもらってきました。尊敬する先輩たちがいて、挑戦できる環境があって、生の課題と向き合いながら腕を磨ける仕事がありました。
振り返ると、楽しかったのは「自分の頭で考えて動けたから」だと思います。単に与えられたタスクをこなすのではなく、技術で事業を動かす実現者の一人でいられました。そういう人で構成されたエンジニアリングチームは、自然とビジネスサイドからも信用されるようになっていきます。ひとたび信頼や信用が生まれると、チームの力は掛け算になります。
ただ、誰もが放っておいて自然とそうなるわけではなくて、最初は一定のガイドが必要です。だからコアバリューやコンピテンシーリーダーのような仕組みを用意して、まずはそれを指針にしてもらう方が良いと考えました。その先は自分の頭で考えて、自分なりの基準を見つけていってもらう。そういう環境を整えた上で、次の世代と一緒に事業を伸ばしていきたいと思っています。
高い基準を自分たちで決めて、共に乗り越えていく。その営みを繰り返すことで、みんなで楽しみながら 自律的なエンジニア組織になっていけると今は思っていますね。
―AIの登場によってエンジニアの役割や業界の空気感が大きく変わってきていますが、この先さらに激しく変化する時代を「楽しめる」のは、どんな人だと思いますか?
採用面接で必ず聞くのは、「何が面白くてやっているか」ということです。やってきたことそのものよりも、「何が嬉しかったか」「どんな瞬間に満たされたか」といった好奇心や熱量を自慢してほしいと思っています。
好奇心ドリブンでどれくらい動けているかが、熱量に乗っかってきますよね。結局は試行錯誤を楽しめるかどうかだと思います。そういう人たちに楽しい場を引き継ぐ。それが自分にとって「すごいエンジニア」の在り方だと思っています。



