CTO代行という肩書きは、いまだに定義が曖昧なまま使われている。「外部のエンジニアが一時的に技術を見る」という理解で依頼してくる経営者も多いが、実態は全く異なる。2021年から2024年にかけて、国内の医療機器メーカーA社でCTO代行を務めた経験をもとに、何を担い、どう動き、どう終わらせるかを具体的に書く。A社は従業員120名、自社開発のクラス2医療機器ソフトウェアを持ちながら、技術組織の責任者が不在という状態で相談を受けた案件だった。この記事は、CTO代行を検討している経営者と、その役割を担おうとしている人の両方に向けて書いている。抽象論ではなく、実際にやったこと、判断したこと、失敗したことを記録する。

最初の90日間：診断と信頼の構築

契約初日から技術判断を求められると思っている経営者は多いが、それは間違いだ。最初の90日間にやるべきことは診断だけである。A社では、既存の開発チーム8名全員と個別に1時間ずつ話した。議題は「現状何が一番しんどいか」の一点のみ。コードレビューの仕組みがない、リリース判断が社長に集中している、QMS（品質マネジメントシステム）の更新が2年止まっている、という三つの構造的問題が見えてきた。技術スタックの評価は90日目以降でいい。人と組織の実態を知る前にアーキテクチャを語っても意味がない。この期間に経営者との信頼も構築する。週次で30分、報告ではなく対話の場を設けた。CTO代行が機能するかどうかは、CEOとの関係の質でほぼ決まる。

医療機器開発特有の制約と技術戦略の接点

A社の主力製品はクラス2の医療機器ソフトウェアであり、薬機法およびIEC 62304への準拠が必須だった。この制約は技術戦略に直結する。たとえば、アジャイル開発を導入したいという要望があったが、IEC 62304のソフトウェア開発ライフサイクル要求と整合させる設計が必要になる。PMDAへの相談記録も設計インプットとして管理しなければならない。一般的なSaaSスタートアップで通用するプラクティスをそのまま持ち込んでも機能しない。A社では、スプリントを2週間に設定しつつ、各スプリント終了時にリスクマネジメントファイルの更新を義務化した。これにより「アジャイルでありながら監査に耐える」状態を2022年4月から実現した。技術戦略は事業戦略と規制要件の両方を起点に設計する必要がある。

採用と組織設計：誰を、どの順番で採るか

CTO代行の最重要業務のひとつが採用である。A社では3年間で技術職を12名採用した。最初に採ったのはフルタイムのQAエンジニアだった。開発チームが品質保証を兼務している状態では、どんな技術改善も効果が出ない。次にアーキテクトを一名。この順番を間違えると採用した人材が機能しない。採用プロセスにおいてCTO代行がやったことは三つ。ジョブディスクリプションを自分で書く、一次面接に必ず入る、そして内定後のオンボーディング設計まで関与する。「採用だけして終わり」にするとその後の組織設計が崩れる。2022年末時点で技術チームは15名になり、この段階でエンジニアリングマネージャーのポジションを新設した。CTO代行が直接見る範囲を意図的に狭めていく設計が、自立した組織をつくる。

経営会議での技術の語り方

A社の取締役会には医療機器の営業出身者が多く、技術トピックの議論が成立しにくい状況があった。CTO代行として毎月の取締役会に出席し、技術議題を三層に整理して提示するようにした。一層目は事業インパクト（リリース遅延が与える売上への影響）、二層目はリスク（規制対応の遅れが引き起こす認証失効の可能性）、三層目が技術の詳細（負債の量、テストカバレッジの数値）。取締役に必要なのは三層目ではなく一層目と二層目の情報だ。技術者出身でないCEOが技術投資の判断をできるようにすることが、CTO代行の重要な役割のひとつである。A社では2023年の予算策定において、技術負債解消のための開発工数をはじめて正式に予算化することができた。これは語り方を変えた直接の結果だった。

失敗した判断とその後の修正

うまくいったことだけ書いても記録として意味がない。A社での明確な失敗のひとつは、2022年前半にCI/CDパイプラインの刷新を優先しすぎたことだ。エンジニアの習熟度を過大評価し、ツールの移行コストを過小評価した。結果として3ヶ月間、開発速度が30パーセント程度落ちた。修正はシンプルで、移行を二段階に分けて既存ツールとの併存期間を設けた。失敗から学んだのは、技術改善のスピードは常にチームの習熟速度に合わせるべきだという当たり前のことだ。CTO代行は組織の外から来るため、自分のペースを組織に強制しやすい。A社の経験で最も気をつけたのはこの点だった。変化のスピードを決めるのは自分ではなく、組織が持てる吸収力の上限である。

離脱の設計：どう終わらせるか

CTO代行の関与には必ず終わりがある。その終わり方を最初から設計しておかなかったことが多くのCTO代行案件で問題になる。A社では契約開始時に「3年後にフルタイムのCTOが就任できる状態をつくる」をゴールとして明文化した。2年目の後半から、CTOポジションの要件定義と候補者探索を並行して進めた。最終的に2024年3月、内部育成した開発リード出身の人物がCTOに就任した。引き継ぎは3ヶ月間の並走期間を設けた。この期間中、意思決定の主語をCTO代行から新CTOに完全に移し、自分はアドバイザーとして週1回の壁打ちのみに役割を縮小した。終わり方が悪いと、組織は依存から抜け出せない。CTO代行の成功は、自分がいなくても回る状態をつくれたかどうかで測られる。

CTO代行を依頼する前に確認すべき三つの問い

A社の経験をもとに、CTO代行を検討している経営者に問いかけたいことが三つある。ひとつ目は「何を解決したいのか」。採用難なのか、技術戦略の不在なのか、開発組織の機能不全なのかで、必要な関与の形が全く異なる。ふたつ目は「フルタイムCTOを採用する前段なのか、それとも永続的な外部リソースとして使いたいのか」。後者を想定しているなら、その設計は慎重に議論する必要がある。三つ目は「経営者がどれだけ技術判断に関与できるか」。CTO代行は経営者の代わりに考えることはしない。技術と事業の接点を一緒に考えるパートナーである。この三つの問いに明確に答えられない状態で契約すると、双方にとって成果が出にくい関与になる。

CTO代行という役割は、肩書きではなく設計の問題だ。何を担い、どう測り、どう終わらせるかを最初に合意できた案件だけが機能する。A社での3年間は、その合意があったから動いた。Pulse Tech Zone Pathでは、技術組織の設計と移行に関する相談を受けている。東京、福岡を拠点とする。