CTOをやめようと思っている話✨

CTOをやめようと思う

ただし、今すぐではないです。これを見た社員や投資家の方は、びっくりしないでくださいね。
これは辞めます宣言ではなくて、この1年のMOSHの成長と、プロダクトづくりを取り巻く環境の変化を踏まえて、今後の自分の価値発揮の仕方を改めて見直している、という話です。

そして結論から言うと、最近、こう思うようになりました。
CTOより、CTO以外の方が価値が出る局面が来るかもしれないな〜と

今日はその背景にある、MOSHの現在地と、これからの僕の役割について...の思考を書いてみたいと思います。

ファウンディングエンジニアとしての8年

まず簡単に自己紹介を。
僕はMOSHの創業者の一人で、技術側の一人として担当してきました。気づけば8年半。
肩書きとしてはCTOを任せてもらっていますが、これは前からずっと思っていることとして、CTOという言葉ひとつで役割が定まることはないと思っています。
フェーズ、組織規模、成長戦略、プロダクトの位置づけ。それらが変われば、求められるものは流動的に変わります。

だから僕は、自分の役割を表現するときに好んでファウンディングエンジニアという言葉を使います。
CTOよりも、創業エンジニアと言った方が、役割や振る舞いのイメージが一致しやすいし、僕自身のこれまでの立ち回りにも近いからです。

実際、これまで何をしてきたかと言うと、プロダクトと技術を土台に、事業成長にまつわることをいろいろやってきました。

アーキテクチャの選定や実装はもちろんですが、監視のアラート設定のような最低限の守りも当然いっぱい作りました。闇アラート。ただ、データの整合性を担保する仕組みを完璧に作り切る余裕なんてないので、毎日自分でダッシュボードを見に行きます。毎朝10時の日課です。ここで不整合がないと、いい日。

手動でデータを直す作業も週2〜3回はやるし、サポートへの返信も、多い時は1日20〜30件くらい自分で返していました（今は桁外れの数を専門チームが支えてくれていますが）

今となっては笑い話ですが、創業初期には、特定の端末でしか再現しないバグに遭遇し、ログイン不能になったお客様と僕個人のLINEを繋ぎ、まさにホットライン状態で対応したこともありました。

「今、予約入りました！」「了解です、DB直接書き換えます！」

これを365日体制でやってました。草

夜中だろうと休日だろうと、目の前のクリエイターさんの事業を止めないためにはやるしかない...というほど崇高な思いだったか定かではないですが、だいたい自業自得なので、とにかくここで堰き止めなきゃという気持ちはあり、それが僕のファウンディングエンジニアとしての仕事だと思います。

Pensight社のMAにも関わらせていただきました

2025年、マルチプロダクトへの転換と組織の急成長

そんな時期を経て、今年1年のMOSHは、今までで一番強く成長できた年だったのではないかと感じています。

成長の要素はいろいろありますが、一番大きかったのは戦い方を変えたこと、そして組織が大きく進化したことです。
これまでのシングルプロダクト的な成長だけでなく、複数のプロダクトを組み合わせたコンパウンド価値を提供するマルチプロダクト戦略へ、明確に舵を切りました。

それに伴い、調達が完了し、採用をドライブする中で、組織の形も劇的に変わりました。
これまではストリームアラインドが2チームと、遊撃隊的な1チーム、プラットフォームチームという3.5チーム体制くらいでやってきましたが、今年はフルサイズではないチームも含めつつ、8チームほどが駆動する様相になりました。大企業！

技術面でも、去年まで「やりたくてもなかなかやれない」テクニカルプロダクト（プロダクトを支える共通プロダクト基盤）が、驚くことにどんどん進みました。大抵こういう理想的な話って進まないものですが、進んだ...すごい...

テクニカルプロダクトのイメージ

通知基盤のアーキテクチャ

アーキテクチャも変わりました。8年以上共に歩んだサーバーレスアーキテクチャと別れを告げ、ECSで構築し直し、Python+AngularからHono+RR7に刷新。これまでよりもスケーラブルで予測可能な仕組みへの移管を進め、実際にデリバリーされて動き始めています。

誤解のないように言っておくと、サーバーレスアーキテクチャもAngularも素晴らしいものです。実際、この8年間、MOSHはほぼ落ちることなく稼働し続けました。Lambdaを活用したイベント駆動アーキテクチャや分散システムは、難易度こそ高いものの、アプリケーションとデータの疎結合を強制してくれるなど、設計上のメリットも大きかった。

ただ、僕の実力不足や、変化の激しいドメインとの相性もあり、そのポテンシャルを活かしきれない部分が出てきたのも事実です。だからこそ、今のチーム規模とフェーズに合った、より堅牢な基盤への移行を進めています。

プロダクト側も、象徴的な成果があり、その一つがページビルダーです。

世の中には同種の機能はたくさんありますが、ちゃんと使えるものを作り切るのは結構時間がかかるものです。
それをMOSHは、企画からファーストデリバリーまで約3ヶ月、使い込める状態まで含めても4〜5ヶ月くらいで出せました。

担当はエンジニア3人と、兼務のデザイナー・PM、等。
しかも、ただのページ作成ではなくて、MOSHの予約動線に繋がり、在庫や定員をMOSHのDBを参照して動的に振る舞いが変わる。
このドメインがちゃんと繋がっている体験を、小人数で短期間に実現できたのは、組織としての成長が顕著に表れた部分だと思います。既存アセットを流用しない新規よりも、難易度は上がるはずなので。

こうした成果は、当然ながら僕一人の力ではなく、というか僕は何もしてなくて、日々難易度の高い課題に向き合ってくれているメンバー全員の努力の賜物です。本当に、心強い仲間が増えたなと嬉しく思います。

仲間ズ（一部抜粋）

異なるベクトルの優秀さが、掛け算を生む

ただ、今年の変化で一番大きいのは、個別のプロダクトでも、技術基盤でもなく、組織の状態だと思っています。

去年までの体制は、ユニットリード（一般的にはテックリードに近い役割）が各チームにいて、みんなプレイングマネージャとしで回してくれていました。
現実としては、加速よりも止めないだけでパンパンになるし、漏れたものは僕にエスカレーションしたり、分担したりしながらなんとかやってたと思う。

当然重要なフェーズです。ここまで来れたのはこのやり方のおかげでもある。
ただ一方で、スタートアップとして非線形に伸びる（毎年3倍、できれば10倍）を目指すなら、ずっと全員がジェネラルに頑張るだけでは出せない変化もある。

だから、ここ去年あたりからずっと専門性の掛け算を組織でどう作るかを意識していました。

そして今年、それが一気に進んだと思います。結局今年やった一番大きい仕事は「優秀な人の100%を出すためのフォーメーション作り」だと思う...。

何が変わったかをシンプルに言うと採用になります。

もちろんこれまでも、何でもできる、プロダクトエンジニアとして非常にバランスの取れた素晴らしい方々に支えられてきましたが、今年は一度に多くの方がジョインしてくれた。

そこに加えて今年は、特定の領域において圧倒的な深度と再現性を持つ方々が増えました。

• 開発そのものに強みを持ち、長年現場で構築をし続けてきた方。
• 広告やメディアなど、かなりトラフィックの大きなスケールの基盤を実際にさばいてきた方。
• 創業期から関わり、組織をゼロから数十人規模までスケールさせてきた方。
• あるいは、事業責任者としてプロダクトと売上の両方を背負い続けてきた方。

これまでのMOSHにはなかった種類の強みを持つ人たちが、一度に加わってくれた感覚です。

めちゃくちゃハッピーなわけですが、当然こうなると、こうした方々が、今の仲間とうまく合流し、みんなのバリューを骨の髄までしゃぶりたくなるのが人情ですよね。誰一人の価値も無駄にしたくない。いい意味で。

ただ、性質の違う強みを持った人たちが集まれば、放っておくと摩擦が起きたり、お互いの良さを消し合ってしまうこともある。
だからこそ、彼らが100%、いや200%のポテンシャルを発揮できるフォーメーションを組まなければなりません。

では、誰がそれをやるのか。

それは、組織の歴史的な文脈を知り、かつ組織構造を変えるための発言力と裁量を持っている人間がやるのが合理的で、今のMOSHにおいて、その役割を担っているのは僕です。

彼らの能力が事業成長に直結するなら、それを阻害する要因を取り除き、掛け算になる場を整えること。
それは僕個人の想いというより、このポジションにいる人間に課せられた、構造的な必然だと考えています。
今年は、そこに一番意識と時間を使ってきました。

領域を分割し自由をつくる

そうした掛け算を生むために、今年一番時間をかけて整理したのが、MOSHのプロダクト戦略実行体制です。

これまでもプロダクト戦略や技術戦略はありましたが、それを実際に前に進めるためのプロダクト開発組織の型が追いついていませんでした。

そこで今回、新しい仲間を迎え入れるタイミングで、全員の力を最大限活かすために必要案、裁量と責任の形を定義しました。

具体的には、プロダクト開発におけるエンジニアリーダーシップを3つの役割に分離しました。

• 新規領域：新しいプロダクトを立ち上げ、フィットする体験まで持っていく

• 既存グロース領域：売上が立つ単位を伸ばし、阻害要因や離脱要因を潰していく

• コンパウンド領域：複数プロダクトの組み合わせで、MOSHならではの体験を作る（横断的な価値）

こうした領域ごとのリーダーを定めることで、これまで経営に意思決定を委ねなければ決められなかったことが、より現場に近いリーダーの判断で進めやすくなると思っています。

リソースアロケーション、評価など、経営判断を求めていた業務が、委譲されるため、意思決定スピードが格段に上がることを期待しています。

これは上下関係を作りたかったわけではありません。むしろ逆で、「この領域の判断はこの人に聞けばいい」「このテーマはこの人が最終的に決める」という状態を、組織の中に明確に作りたかった。

こうすることで、より近い距離にいる意思決定者と会話し、自分の創造性やスキルの発揮がクイックにできる環境が作りたかったのです。

そのため、これらのリーダーには、チーム編成やアサイン、デリバリープランニング、ロードマップのGO/NoGo、技術的負債の判断といった、かなり実務的な権限を有しています。

ここが曖昧なままだと、結局すべての意思決定が一旦村井に集まる状態になってしまう。それを避けるためにこうした改善を重ねています。

オンボーディングという名の摩擦と対話

とはいえ、箱を作れば勝手に回る、なんてことはありません。
実際に入ってくれた一人一人とのオンボーディングは、綺麗な資料を読み合わせることよりも、もっと泥臭い、現場の摩擦をどう解消するかという対話の連続でした。

例えば、今回ジョインしてくれたみんなとの1on1のログを見返すと、最初の頃は本当に細部のアジャストの話ばかりしています。

特に、具体的な技術スタックの選定や運用ルール、プロセス、組織...大体のことにおいて、彼らの知見は僕よりも圧倒的に深かったw

モダンな開発フローの構築や、リリースのブロッカーになりがちなレビュー文化の調整など、現場で起きている理想と現実の摩擦を、一つ一つ会話の中でチューニングしていく時間が、オンボーディングの大半だったように思います。

そうやって細部をすり合わせていくと、あるタイミングから、動きの変化が見え始めます。

体制変更を周知して、実際にメンバーが動き始めると、しばらくして、「今日にも本番環境でステップ配信が動き出しそうです」といったスピード感のある報告が上がってくるようになりびびりました。

その裏側では、「この方には、メールの配信改善のような独立したテクニカルプロダクトを見てもらうのが良さそう」とか、「LINE拡張の開発と近いから、こっちのチームに入ってもらう体制にしよう」といった、具体的な人の配置とタスクの切り出しがセットで動いています。

これらは僕がそうして、と言ったというより、現場の解像度が上がったことで、メンバー一人一人の能力の発揮が始まり、自然とそういうパズルが組み上がっていった、という感覚に近いです。
かつてはとにかく拾える人が全部拾っていたようなボールが、適切な場所で、適切な熱量で議論され、前に進んでいる。

その様子を見たときに、ふと冒頭の考えに至ったのです。
「あれ、この状態で僕が承認者として居座り続けることは、むしろノイズなんじゃないか？」と。

なぜCTOがノイズになるのか

なぜなら、冷静に考えてみると、技術的な最前線については僕よりも新しく入ってくれたメンバーの方が詳しいことが多いからです。
僕は8年間、MOSHという特定の文脈に引きこもって開発をしてきました。事業のことは誰よりも知っているつもりですが、世の中のモダンな技術トレンドや、スケーラブルな組織のベストプラクティスについては、外の世界で戦ってきた彼らの方が遥かに解像度が高い。

それなのに、僕には「創業CTO」という、無駄に強い発言力があります。
もし僕が、生半可な知識で「このやり方はどうなの？」と謎の理論を振りかざしてしまったらどうなるか。
周りのメンバーは「いや、今時それはあり得ないですよ」と思っていても、立場上それを指摘しづらいはずです。僕の何気ない一言が、現場にとっては重たい「指示」になってしまい、検討の方向を歪めてしまう。

知識は彼らの方があるのに、権限だけ僕が持っている。
この構造こそが、組織のスピードを落とす最大の「ノイズ」だと思ったのです。

コンテキストという特権を活かす義務

もし、それでも戦略の承認者として僕が必要なのであれば、その役割は続けるべきだと思います。
一方で、戦略実行体制が回り始め、優秀な人たちがそれぞれの判断で前に進めるのであれば、肩書きとしてのCTOは、むしろノイズになる可能性もある。

でも、じゃあもうお役御免かというと、さすがにそんなこともなくて。
古参以外にはしづらい、そしてファウンディングエンジニアだからこそやるべき仕事があるなと、同時に思うようになりました。

それは、「組織の熱量を下げないために、一番自由な人間が、一番面倒なリスクを取る」ということです。

正直に言うと、創業メンバーというのは「やりやすい場所」に置いてもらっているなと感じます。
それは僕が特別優秀だからではなく、単に8年半という歴史的経緯によって与えられた特権のようなものです。
過去の経緯を知っているから不安が少ないし、誰かに気を使ったり、配慮したりする必要も相対的に少ない。
つまり、自分の熱量を発揮することを妨げるものが、組織の中で一番少ないのが僕なんです。

これは創業者に限った話ではありません。組織に長くいる古株のメンバーであれば、誰しもが持っている「コンテキスト」という強力な武器の話でもあります。

一方で、新しく入ってきてくれる仲間は違います。
どれだけ優秀で熱量が高くても、組織にアジャストするコストがかかるし、配慮も必要になる。
組織が大きくなればなるほど、熱量の減衰は避けられません。
極端な話、最初の人が100の熱量を持っていても、組織の摩擦によって次の人には30しか伝わらず、その次には10になることが普通に起こり得ます。

だからこそ、一番摩擦の少ない場所にいる僕が、その特権を発揮しないといけないと思います。
「昔からいる」という時間という変数によってしか得られない特権を享受しているからこそ、新しい人たちを生かすために、誰よりもリスクを取り、熱量を伝播させる義務がある。
ここをやるほうが事業伸びるのではないかと、そう思います。

ラストワンマイルの突破

これまでの僕の「熱量の伝え方」は、採用頑張ったり、組織図を書いたり、戦略を作ったりすることでした。
でも、それができる優秀な仲間が増えた今、僕が取るべき手段は変わりました。

それは、「ラストワンマイルを突破する」ことです。

AIの登場で、コードを書く総量は間違いなく増えました。でも、みんなが最後に詰まるのは、影響範囲が読めないラストワンマイルの決断です。
「この古いコードを消して本当に大丈夫か？」「この仕様変更はどこに波及するのか？」
そこには恐怖があり、足が止まります。

でも、僕には8年間のコンテキストがあります。
「あ、それは昔こういう理由で入れたやつだから消してOK」「そこはあの顧客が使ってるから注意」という勘所がある...と思います。ミスるかもしれんけど。

このコンテキストを持った僕が、AIをフル活用して、みんなが躊躇するラストワンマイルを片っ端から突破していく方が、みんなの才能が無駄なことに消費されないのでは？と思っています。

そしてそうやって詰まりを解消していくことは、実はCTOとして組織図をいじるのと同じくらい、あるいはそれ以上に、事業スピードに強烈なレバレッジを効かせられるのではないかと思っています。

• 8年近く触られていないヤバいコードを、新しいリポジトリに移管する。
• 決済のような失敗できない領域で、ロック機構のパフォーマンス改善に挑む。
• 他社連携サーバーのIP切り替えなど、正解のないインフラ移行をやる。

こういうまあまあヒリヒリする場所に僕自身が飛び込み、「あ、ここまでやっていいんだ」「失敗しても死なないんだ」ということを伝えたい。
そうやって熱量をバイラルさせていくことこそが、今のMOSHにおける僕が最も役に立てる仕事なのではないかと思っています。

市場のウィンドウが開いている「今」しかできないこと

今は、100%全員の価値を発揮すべき時です。
それは、今まさにMOSHにとって、そしてクリエイターエコノミーにとって、「市場のウィンドウ」が開いているからです。

10年近くやってきても、こんな時期はなかなかありません、というか初。

今、この瞬間にエネルギーを注ぎ込めば、市場から強烈なフィードバックが返ってくる。
逆に言えば、このウィンドウが閉じている時にどれだけ頑張っても、暖簾に腕押しで、正解も不正解も分からない。

本当に今しかない可能性があります。

この奇跡のようなタイミングに、組織のあらゆる想像力と熱量を注ぎ込んで、市場からの答えを受け取りたい。
そのためには、組織内の摩擦係数を極限まで下げ、全員がリスクを恐れずに挑戦できる状態を作らなければなりません。

そのために、僕自身がどこに身を置くべきか。
多分それは、火傷しそうな場所にある...気がしています。

僕は助けてもらわないと、生きていけない自信があります

結局、言いたいことはシンプルです。

もし、承認者・摩擦係数を下げる人としてのCTOが、組織にとって最大のレバレッジになるなら、僕は喜んでそれをやります。

でも、もしその役割がノイズになり、むしろ僕がリスクのど真ん中に飛び込むことが事業を加速させるなら、迷わずそちらを選びます。

重要なのは、肩書きを守ることでも、CTOらしく振る舞うことでもありません。

今、この瞬間にMOSHの成長率を最大化するために、僕にできることはなんなのか、一番事業が成長する角度はどこなのか。

その問いに対する答えが、今は戦略や承認よりも、探索と実行であり、管理よりもリスクテイクなのかな、と思っています。

誰もやりたがらない面倒な改修、正解のない技術選定、壊れるかもしれない新機能の実装。
そういうちょっと気合いはいるけれど、刺激的な環境で、来年もコードを書きいくことが、今の僕にとってもっとも事業に価値を生む選択だと信じています。

そして、混沌としているけれど可能性しかない今という時間を共にすごしてくれるちょっと変な仲間を、全方位で募集しています！

明日は、そんな愛すべき変な仲間の一人である @d0riven が、クリスマスイヴに相応しいメロディックなポストをしてくれるでしょう。たのんだ