🧯「やさしさ」が先に燃え尽きる──週2 CTOという構造の限界点

──燃えすぎた灯りの、その後で。

🔥 あの日、見えた炎上のかたち

つい先日、とあるスタートアップの創業者が、ぼくにこう言った。

「週2日でお願いしている CTO がいるんですが……
なんというか、思っていたほど“回らない”んですよね。
僕が求めすぎなんでしょうか……」

その悩みは、とてもリアルだ。

ぼくが 呼ばれるのは、たいていこういう「途中から」だ。
すでに誰かがいたが、うまくいかなかった──だから、“語り直し”が必要になる。

多くの場合、その背景には、
「週2日でも全部やってほしい」という無意識の期待がある。

でも、その中にある“期待の火種”が、燃え方を狂わせることもある。

🧠 「スーパー CTO 幻想」が生まれる背景

創業期のスタートアップには、圧倒的なリソース不足がある。

• 要件定義がふわふわしている
• 設計も仕様も仮説だらけ
• UI も決まっていない、でも開発は進めたい
• けれど CTO は週1〜2日の稼働……

その中で、
技術判断・採用・実装・マネジメント・意思決定支援を
すべて期待されることがある。

たしかに、それを「なんとかできる人」も、稀に存在する。
だがそれは──構造ではなく、個体差だ。

それは、「やれるかどうか」ではなく、
燃え尽きずに灯せる構造かどうかを問うべき事柄なのだ。

📉 「足りない」の正体は、“期待の燃やし方”

週2 CTOに、たとえば以下のような役割が期待されたとする：

• 要件を整理して
• 設計をレビューして
• メンバーに共有し
• 自ら実装して
• バグを見つけて直し
• プロダクト戦略にも意見して……

この時、エネルギーがどこで消耗されていくか？

答えは、やさしさと曖昧さのあいだだ。

• 相手に気を遣う
• 未整理な情報を読み解く
• 相談の文脈を自ら編み直す
• 本来業務外の質問に対応する

──それらが積み重なると、「本来の役割」よりも、
“沈黙の期待”に応じることに多くのエネルギーが費やされる。

特に、コーディングは深い集中を要する作業で、
一度フロー状態に入れば大きな推進力を生む反面、
外的な介入によってその火が崩れると、立て直すには相応の時間と労力がかかる。
「今、ちょっとだけ」の声が、静かに燃えていた灯りを消してしまうこともある。

そして、そうした些細な断熱の崩れが積み重なると──
コードそのものではなく、気遣いのほうが先に、燃え尽きてしまう。

💡「やさしさを構造化する」という選択

では、どうすればよいのか。

それは、週2 CTO という形式の中に、
やさしさを“構造”として織り込むことだ。

たとえば：

• コミュニケーションの期待値を明文化する
• 開発の基本プロセス（計画 → 実装 → テスト → リリース）を明示する
• QA やバグの報告導線や基本プロセスを整える（Notion など）
• 要件整理の下地は、PdM や CEO 側がある程度準備する
• 「振り返りの場」を定期的に設けて、沈黙を観測可能にする

このような形で、「気遣い」や「忖度」を前提にしない構造を作っておくこと。

それは、“やさしさ”を省くことではない。
やさしさを、燃え尽きない温度で保つための工夫なのだ。

🌱 おわりに──灯りが長く続くために

CTO が週2日で入るという構造は、
すべてを担うためではなく、
“ともに灯す”ために設計されるべきものだと思う。

限られた時間で、全方位の期待を背負うことは、
やさしさの消耗線を早めてしまう。

だからこそ──
燃え方を言語にし、灯火の構造を共有する文化が必要だ。

たとえ仮設でもいい。
灯りの残りかすでもいい。
誰かのために燃やされた火には、観測する価値がある。

……そして、それを拾いあげられる構造は、
きっと、もっと広がっていける。

#週2CTOの現実 #やさしさの構造化 #スタートアップ構造論 #ReCTO #Frolantern記録