🧭

肩書きより“役割”で動くCTO

に公開

お久しぶりです。株式会社 OptFit CTOの荒川です。

前回Zennに記事を出してから、だいぶ時間が空いてしまいました。
https://zenn.dev/optfit_tech/articles/b4377a629feda1

「書こう」と思った日は何度もあったんですが、だいたいその日の夕方に“想定外のボール”が飛んできて、気づいたら金曜日になっていました。(スタートアップあるあるですね……)

そんな中、会社はシリーズBを迎え、事業も組織も次のステージに向けてギアが上がりました。
勢いが出るのは良いことですが、勢いがある時ほど “地に足” が大事です。

今日は、CTOとして最近いちばん強く意識していること――
「肩書きより“役割”で動く」
について、できるだけリアルな実体験をベースに書いてみます。


こんな綺麗なカーブを描きたい


会社のフェーズが変われば、役割も変わる

最初に、この記事で一番伝えたい結論を置きます。

会社にはフェーズがあり、フェーズごとに自分の役割は常に変わっていく。
会社のスケールを第一に考えて、常に自分の役割を理解した上で必要な立ち回りをしていくことが重要。

「CTOだからこの仕事をする」のではなく、
「今の会社のフェーズにおいて、誰がそれをやるのが一番スケールするか」
という基準で動く感覚が大事だと考えています。

現フェーズにおける私の役割は、
最大限のバリューを発揮できるエンジニア組織を作り、現場の一次情報をスピーディに掴み、意思決定の速度と精度を上げ、会社の価値を最大化させる
ことだと考えています。

スタートアップは、役割に線を引いた瞬間に動きが鈍ることが多々あります。
ボールが落ちたり、意思決定が遅れたり、誰も拾わなくなったり。
(そして最後に「なぜかCTOのところに戻ってくる」のも、あるあるです。なぜ。)


シリーズA→Bでの変化:「品質」と「組織として勝つ」感覚

シリーズAからシリーズBに向かう中で、強く変わったと感じたのは以下の2点です。

  1. 求められる プロダクト品質 が一段上がる
  2. 事業を伸ばすだけじゃなく、組織として勝てる形にしないと追いつかなくなる

このタイミングで、私が意識的に増やしたのが 「委譲」 です。

  • エンジニアのマネジメントを、積極的に委譲していく
  • 運用業務を、積極的に委譲していく

ここをやらないと、組織が「個の頑張り」に依存しすぎてしまい、スケールの邪魔になる感覚がありました。


役割を見誤らないために、まず“自分の時間”を棚卸しする

いまの私の時間配分は、ざっくり以下の通りです(現実ベース)。


(運用が5%入っていて「いや、それ自動化しようよ」と自分に言いたい気持ちは、あります。)

重要なのは、時間配分を自覚しないと役割のズレに気づけないということです。
ズレたまま走ると、気づいた時には「なんか疲れてる」「なんか組織が回ってない」という事態になりがちです。


「現場解像度」を高く持つ

スタートアップのプロダクト開発は、待っていたら進まない局面が多いです。
次の会議まで判断を先延ばしすると、現場も開発も止まってしまいます。

逆に、現場の解像度が高いと、その場で判断できることが増える為、
私はできるだけ一次情報を取りに行くようにしています。

  • クライアント先で施設の方と会話し、課題やフィードバックを直接聞く
  • 新規事業では現場に行き、その場で理解を深める

現場に行く最大のメリットは、結局これに尽きます。

「その場で大枠を決めて、開発を進められる」

会議が「意思決定の場」ではなく、「現場で決めた意思決定の最終チェックの場」に変わります。

現場の情報はチームへフィードバックすると強くなる

拾った一次情報は、 エンジニアリング定例 で共有しています。

仕様だけ共有しても実装はできますが、細かい判断がブレることがあります。
しかし、「なぜ必要か」「現場で何が起きているか」まで共有すると、エンジニア自身の判断の精度が高まります。

開発と現場が近いのはスタートアップの強み。
ここは文化として守っていきたい部分です。


(※イメージ)


“機能追加”より、“入れない/機能削除”がプロダクトを太くする

現場からの要望はありがたいものです。だからこそ、確固たる判断基準がないとブレます。

新規機能の実装可否を判断するとき、私はこの3点で見ています。

  1. ビジョン・ミッションからズレていないか(本当に当社が取り組むべき課題か?)
  2. 運用可能で、マスが抱える課題を解決できるか
  3. ビジネスとして、費用対効果が得られるか

「要望があるから作る」を続けると、プロダクトはどんどん細く複雑になり、
逆に、「入れない/機能削除の判断」ができると、プロダクトは太く、強くなります。

そして個人的には、プロダクトに愛着があるからこそ「腹落ちしないものを増やしたくない」という気持ちもあります。(これはわりと本音です)


権限委譲のコツ:タスクじゃなく「責任」を渡す

権限委譲するときに、最低限セットで渡すのはこの3つです。

  • 権限(任せた人が決められる状態)
  • 判断基準(迷った時に戻れる軸)
  • いつでも気軽に聞いていいと思える配慮

特に3つ目の「心理的安全性」が一番大事です。ここが揃うと、任された側も動きやすいし、任せた側も安心して任せ続けられます。

地味だけど効く、“恥ずかしい運用”の委譲

かつて、通知が来たら都度対応するような 「人力前提の運用」 がありました。

  • 1回5分、でも1日2〜3回発生する
  • マニュアル化・自動化できるのに後回しにしている
  • 結果、CTOに属人化している

こういうタスクは、実は会社の成長をじわじわ削ります。
だから、気づいたら早めに現場に渡して、仕組み化していく方が健全です。

(そして、委譲した瞬間にメンバーから「これ自動化しましょう」と言われることもあります。はい。)


最後に

「肩書き」は単なるラベルに過ぎません。
重要なのは、そのフェーズにおいて 「もっとも組織を伸ばす役割」で動くこと です。

シリーズB以降も、CTOという既存の枠には固執せず、会社のミッションである
「AIカメラで人に依存しないビジネスモデルを再構築し、持続可能な社会インフラを築く」
を果たしていきます。

OptFitでは、会社をスケールをさせていく仲間を募集しています。
2026年もよろしくお願いします!

Opt Fit テックブログ

Discussion