「技術部長として成果を出してきたのに、なぜCTOになれないのか」「CTOになったものの、経営と現場の間でどう立ち回ればよいのか分からない」。私が技術責任者の方々とお話しする中で、向き合ってきた悩みです。

技術のことが分からないわけではない。組織をよくしたいという意思もある。それでも、経営者からは開発が遅いと言われ、現場からは無理な要求を受け入れすぎだと言われる。どちらの事情も理解できるからこそ、簡単に答えが出せなくなってしまうのです。

私は株式会社グロースウェルの代表として、経営者やCTO、VPoE、開発部長、エンジニアリングマネージャーなどの伴走支援をしています。自分自身もCTOとして悩み、判断し、失敗してきました。その経験から伝えたいのは、CTOとしての責任を担うことと、すべてを一人で抱えることは同じではない、ということです。

この記事では、技術責任者が孤独になりやすい背景と、経営・技術・組織の間で成果を出すために、私が伴走の中で大切にしていることをお伝えします。

創業10年の節目に、技術責任者の伴走支援を広げたい

グロースウェルは、今年、創業から丸10年を迎えます。事業を続けてこられたことを振り返ると、単に時間が経ったという以上の意味を感じます。その時々に困っている方が相談してくださり、私たちの関わりに価値を見いだしてくださった。その積み重ねによって、会社の存在を認めていただいてきたのだと受け止めています。

現在の事業は、大きく分けると三つです。一つは経営や組織に関する顧問業。二つ目は、個人や組織へのEQの能力開発の導入。三つ目は、インタビューメディアなどの運営です。

顧問業の中にも、異なる相談があります。会社や事業を立ち上げ、成長させていくための経営相談。成長が鈍化したときに、どこを見直し、次の成長につなげるかという相談。そして、技術責任者自身が、現在の役割を果たしながら次の立場へ進むための相談です。

私のバックグラウンドはエンジニアです。だからこそ、技術部門の責任者が抱える難しさには、当事者として理解できる部分があります。経営者の期待に応えたい気持ちも、無理な開発によって現場が疲弊することを避けたい気持ちも、どちらも他人事ではありません。

中でも、CTOとして力を発揮したいのにうまくいかない方や、次の役職を目指しているのに何が足りないのか分からない方への伴走を、これまで以上に広げたいと考えています。肩書きを得ることだけでなく、その立場で成果を出し、納得して仕事に向き合えるようになることまで支えたいのです。

CTOが難しいのは、技術だけで正解を決められないから

開発に求められる品質、コスト、納期。いわゆるQCDについて、経営と開発現場で重視するものがずれることがあります。

経営者からすれば、必要なものをできるだけ早く、費用を抑えてつくりたい。一方、開発責任者は、障害や不具合を防ぐために品質を確保したいと考えます。そのためには検証する時間が必要ですし、難しい仕事を任せられるエンジニアも必要になる。十分な体制を整えようとすれば、人件費や採用費用も気になります。

ここで、経営者を「品質を理解しない人」、エンジニアを「納期やお金を考えない人」と捉えてしまうと、話が進まなくなります。私がまず整理したいのは、相手が何を守ろうとしているのかです。売上をつくる機会なのか、顧客との約束なのか、システムの安定性なのか。それによって、必要な話し合いは変わります。

例えば、経営者が今月中のリリースを求めているとして、すべての機能が今月必要なのか、先に一部を提供することで目的を満たせるのかでは、選択肢が違います。開発側も「品質のために時間が必要です」で止めるのではなく、何を省くとどんな問題が起きるのかを説明する必要があります。

CTOに求められるのは、経営の要求をそのまま現場に渡すことでも、現場の要望をすべて経営に認めてもらうことでもありません。双方が判断できる材料をそろえ、その会社にとっての選択肢をつくることだと私は考えています。

だから、技術的に正しいことを言っているだけでは、仕事が前に進まないことがあります。「どちらが正しいか」から「何を優先して、何を引き受けるか」へ議論を進める。その役割の難しさが、CTOの仕事にはあります。

AI駆動開発は、開発への期待値も大きく変えた

そこに重なっているのが、AIを活用した開発への期待です。私が相談を受ける中でも、「AIを使えば、もっと早くできるのではないか」という話題が出るようになっています。

これまで人が書いていたコードをAIに任せられるなら、開発はもっと速くなるはずだ。他社は大きく生産性を上げているのに、なぜ自社は変わらないのか。経営者がそう期待する気持ちは分かります。技術を事業の成果につなげる立場として、CTOもその期待から目をそらすわけにはいきません。

ただ、「AIで開発速度が何倍になった」という情報を、そのまま自社の目標に置き換えてよいのかは、別の問題です。何をつくっていたのか。どの工程を速くしたのか。もともとの開発体制はどうだったのか。比較する前に確かめたいことがあります。

例えば、コードを書く時間が短くなっても、何をつくるかが決まらないままなら、事業に必要なものを届けるまでの時間は別途考えなければなりません。「コードを書く速さ」と「顧客に価値を届ける速さ」を分けて話すことが、期待を具体的にする入口になります。

一方、CTOが難しさばかり説明すると、経営者には「新しいやり方を試す気がない」と受け取られることもあるでしょう。かといって、期待に応えようとして、根拠のない短納期を約束すれば、今度は現場との信頼を失いかねません。

私が大切にしたいのは、期待を否定することではなく、何を試し、何を確かめるのかに変えることです。「全体を三倍速くします」と約束する前に、自社では何が時間を使っているのか、AIをどこに使えば変化を確認できるのかを整理する。その過程も、技術責任者の仕事になります。

こうした期待の高まりの中で、経営と現場の間に立ち、苦しさを抱える方が増えているという印象を私は持っています。これは業界全体の増加を統計で示す話ではなく、私が相談の現場で感じている変化です。だからこそ、個人の努力だけに帰してしまわない支援が必要だと考えています。

上だけでも、下だけでもない。横の部門との関係もある

CTOの板挟みは、CEOとエンジニアの間だけで起きるわけではありません。営業部門からは顧客の要望を早く反映してほしいと言われ、事業部門からは新しい施策を進めたいと言われる。会社の中で、開発に期待する人は一人ではないのです。

経営の要望を優先し続ければ、現場からは「こちらの事情を理解してくれない」と思われるかもしれません。現場の事情を守り続ければ、経営や他部門からは「事業を進める意思が弱い」と見られるかもしれません。どちらかに立てば済む話ではないところに、難しさがあります。

私は、こういうときほど、CTOが誰かの伝言役になっていないかを確認したいと思います。営業が言ったからつくる。社長が言ったから納期を変える。現場が無理だと言ったから断る。それだけでは、判断の基準が共有されず、関係者全員が不満を持ちやすくなってしまいます。

必要なのは、誰の声が大きいかとは別に、何を優先するのかを話せる状態です。今回の開発がどの事業にどう影響するのか。予定を変えるなら何を後ろに回すのか。判断する人は誰なのか。曖昧なまま引き受けず、条件をそろえていくことが大切です。

技術部門のマネジメントを、部下の状態を把握し、仕事を割り振ることだけで考えると、この横の関係が抜けてしまいます。経営との関係、他部門との関係、現場との関係。その三方向を見ながら判断する仕事だと捉えると、必要な働きかけも変わってきます。

すべての人に好かれることを目指す必要はありません。ただ、意見が違っても、なぜその判断をしたのかが伝わり、次の相談ができる関係は残したい。そのための言葉や順番も、伴走の中で一緒に考える対象です。

技術に強いCTO、組織に強いCTO。すべてを一人で担うのか

技術責任者にも、得意な領域があります。技術の選定や設計に強い方もいれば、採用や育成、組織運営に強い方もいます。私自身、CTOという同じ肩書きでも、相談される課題は人によってかなり違うと感じています。

会社によっては、CTOとVPoEで役割を分けています。一方、小さな組織では一人が両方を担い、技術を見ながら採用や評価、メンバーとの対話も進めていることがあります。分けたくても、今の体制では分けられないという事情もあるでしょう。

ここで考えたいのは、「CTOなのだから全部できるべきだ」という前提が、本人にも周囲にも置かれていないかということです。技術の判断、組織の課題、新しい事業の相談、経営への説明を同時に担えば、優先順位をつけなければ時間は足りなくなります。

しかも、目の前の対応だけをしていればよいわけではありません。技術責任者として新しい技術に触れ、動向を学ぶ時間も必要です。インプットを止めたくないのに、面談や会議で予定が埋まっていく。この悩みも、仕事の持ち方と切り離せません。

私なら、最初から苦手分野の克服だけを求めるのではなく、何を本人が担うべきで、どこを別の人と分けられるのかを整理します。すぐに新しい役職を置けなくても、判断を相談する相手をつくることや、任せる仕事を明確にすることは検討できます。

自分の強みを発揮することと、すべてを自分で処理することは違います。役割を分けるための判断も含めて、技術責任者の仕事だと私は考えています。

「経営視点を持ってほしい」と言われたときに考えること

技術部長からCTOを目指している方にとって、「もっと経営視点を持ってほしい」という言葉は、分かったようで分からない要求ではないでしょうか。経営に関する知識を増やせばよいのか。技術の話を控えればよいのか。それだけでは、次の行動につながりません。

私は、経営視点を持つことを、会社がどう売上をつくり、どこにお金を使い、何を選ぼうとしているのかと、自分の判断を結びつけることから考えます。

例えば、受託開発の会社なら、営業が仕事を獲得する難しさを知る必要があります。開発側から見れば難しい条件の案件でも、営業側には競合との比較や顧客との交渉があります。だからといって、無理な条件をすべて受け入れるという意味ではありません。事情を知らないまま相手の判断を否定しない、ということです。

一般の消費者に向けたサービスなら、つくったものを知ってもらい、登録し、使い続けてもらう難しさがあります。マーケティングや事業側が何に苦労しているのかを理解すると、機能の優先順位についても話し合える範囲が広がります。

もちろん、営業やマーケティングの専門家と同じ仕事をすべて担う必要はありません。相手の仕事の難しさを知り、開発側の判断がどこに影響するのかを理解する。その理解を土台にして、自分たちの事情も伝え、事業としての選択を話し合う。技術の専門性を捨てるのではなく、その専門性を会社の意思決定につなげていくのです。

人件費についても同じです。メンバーの成長や成果を報酬に反映したい。その一方で、昇給によって継続的な費用が増えるなら、会社としてその費用を支える価値をどう生み出すかも考える必要があります。単に給与を抑えるという話でも、全員にもっと働いてもらうという話でもありません。

より価値の高い仕事に取り組めているか。やり直しに時間を使っていないか。組織として成果を出せる体制になっているか。開発部門の中だけでなく、事業とのつながりから考えることが大切です。

取締役CTO、執行役員CTO、開発部長など、肩書きにも違いがあります。ただ、肩書きだけで本人の経営視点や能力が決まるとは私は考えていません。自分に何の判断が任され、経営から何を期待されているのかを具体的にすることが、次の役割への出発点です。

CTOになれない理由を、一人で推測し続けない

「自分にはCTOを担える力があると思う。でも、その役割を任せてもらえない」。そのとき、何が評価されていないのか分からないまま、技術力を高めようと努力し続ける方もいるでしょう。

もちろん、技術を学ぶことは大切です。しかし、経営者が期待しているものが組織づくりや他部門との調整なら、技術の勉強だけでは期待との距離が縮まらないかもしれません。努力が足りないのではなく、努力を向ける先が共有されていない場合があります。

ここで必要なのは、自分に足りないものを想像して落ち込むことでも、経営者は分かっていないと諦めることでもありません。「今の役割で評価されていること」と「次の役割で求められていること」を分けて確認することです。

経営者が技術責任者にどのような状態をつくってほしいと思っているのか。その期待に対して、自分は何をしてきたのか。成果が出ているなら、それが相手に伝わっているのか。確認したい論点はいくつもあります。

私は伴走の中で、肩書きだけを目標にしないようにしたいと思っています。CTOになった後、何を担うつもりなのか。どの領域に責任を持ちたいのか。本人の希望と会社の期待が重なるところを見つけないと、役職が上がっても苦しさが増えるだけになりかねないからです。

現在の立場で成果を出すことと、次の立場に向けて役割を広げること。その二つを区別しながら、一歩ずつ進めるための相談相手がいることには意味があります。

相談できないまま、初めての課題が積み重なる

技術責任者は、悩んでいること自体を話しにくい立場でもあります。社長に「うまくできていません」と伝えれば、任せた判断が間違っていたと思われるのではないか。他部門に弱音を見せれば、今後の話し合いで不利になるのではないか。そんな心配が先に立つことがあります。

現場に対しても同じです。メンバーを不安にさせたくない。自分が迷っていることで、組織の方向性まで揺らいで見えるのは避けたい。結果として、上にも横にも下にも、十分に話せなくなってしまうのです。

その状態でも、初めて取り組む仕事はやってきます。評価制度を変える。新しい会議を始める。事業の立ち上げに関わる。役職が上がれば、過去に経験したことだけで仕事が完結するわけではありません。

初めての取り組みでは、想定どおりにいかないことがあります。私が難しいと感じるのは、その出来事が施策の検証として扱われず、責任者個人の能力への評価だけになってしまうことです。何が合わなかったのかを整理する前に、「またうまくいかなかった」という印象だけが残る。それを恐れて、新しい判断をしにくくなることもあるでしょう。

周囲から頼られる立場になるほど、分からないと言うことに勇気が必要になるのかもしれません。しかし、経験がないことまで経験があるように振る舞えば、確認する機会を失ってしまいます。自分だけでは見えていない論点があると認め、経験のある相手に尋ねる。その行動を、責任者としての弱さではなく、判断のための行動として捉え直してほしいと思います。

私は、失敗を一切しない方法を提供できるとは思っていません。ただ、始める前に確認すべきことを整理し、進める途中で起きた変化を振り返り、問題が大きくなる前に見直すための相手にはなれます。

何でも話せる知人がいることと、会社の事情を踏まえて具体的な判断を相談できることも、必ずしも同じではありません。守るべき情報を確認しながら、役割や評価に関わる悩みを話せる場を持つこと。それは、責任から逃げることではなく、責任を果たすための準備だと考えています。

私自身も、複数の事業を支えるCTOとして悩んできた

私がこの支援に力を入れたいのは、自分自身がその役割の難しさを経験しているからです。AppBankでは執行役員CTOとして、本体と複数のグループ会社に関わりました。メディア、アプリ、EC、YouTuberのライツマネジメントなど、異なる事業を見ていく経験をしました。

同じ会社の中でも、事業が違えば、必要な開発も、スピードも、関わる人の事情も違います。技術的な判断だけしていれば全体が進むわけではありません。それぞれの事業の状況を踏まえながら、限られた時間の中で何を見るのかを決めなければならず、非常に難しかったと感じています。

うまくいったこともありますが、そうではないこともありました。だから、現在相談に来られる方を、外から正解を知っている人の立場で評価したいとは思いません。その状況で判断する難しさや、言いたいことを簡単には言えない感覚を、まず理解したいのです。

独立後も、約10年にわたり、さまざまな会社の課題に向き合ってきました。プライム上場企業を含む企業の技術責任者や、1,000人以上のエンジニア組織を抱えるCTOの方々の苦労にも触れてきました。ただし、私自身がそのすべての組織を直接運営したという話ではありません。

大きな組織の話を知っていれば、小さな会社でも同じ方法が使えるとも思っていません。会社の規模、事業、体制によって、選べる手段は変わります。経験をそのまま当てはめるのではなく、今の相談者の条件に合わせて使うことが大切です。

これまで私たちが時間を使ってきたのは、その会社が実際に困っている問題です。何をすると前に進み、どこで失敗しやすかったのか。その蓄積を、孤独に判断している方のために使いたいと思っています。

伴走とは、抽象的な助言ではなく、次の行動を考えること

「経営とコミュニケーションを取りましょう」「現場の気持ちを理解しましょう」。それ自体は間違っていなくても、すでに困っている方にとっては、それだけでは足りないことがあります。どう話し、何を確かめ、どこから変えるかを決められないから、相談が必要なのです。

私は、その会社の一員になったつもりで考えたいと思っています。相談者の方と自分が入れ替わったら、今、何をするか。限られた時間、権限、人員の中で、どの順番なら動けるか。そこまで踏み込んで、一緒に考えることを伴走と捉えています。

以下は特定の顧問先の事例ではなく、相談の進め方を説明するための例です。

「開発が遅い」と言われているなら、何が遅いのかを分ける

まず、経営者が何と比較して遅いと感じているのかを確認します。最初の約束より遅れているのか。競合の動きに間に合っていないのか。進捗が見えないため、進んでいないように感じているのか。同じ「遅い」でも、対応すべきことは異なります。

そのうえで、次の面談や会議で伝える内容を整理します。現状の説明だけでなく、何を変えればどこまで対応できるのか、何の判断を経営に求めるのかまで考える。単に「もっと説明する」ではなく、次に話す内容が変わるところまで進めたいのです。

評価制度を変えるなら、制度の前に目的をそろえる

評価項目を整えることだけに目が向いているなら、今回の変更で何を改善したいのかを確認します。成果を報酬に反映したいのか。役割を明確にしたいのか。メンバーの不満を解消したいのか。目的によって、説明の仕方も確認する相手も変わります。

制度をつくった後に、現場から予想外の反応が出ることも考えなければなりません。どんな懸念がありそうか、何を先に話しておくかを一緒に考える。実行した後も、反応を材料に次の手を考えます。

私が具体的な提案を大切にするのは、自分の言葉に責任を持ちたいからです。ただし、情報が足りないのに断言したり、相談者の意思を置き去りにしたりすることとは違います。なぜその方法を勧めるのか、どんな前提で考えているのかを示し、現実の結果から見直すことも含めて関わりたいと思っています。

提案を受けた方が、その言葉を持って社長と話し、現場に説明し、実際の行動を変えるかもしれません。だからこそ、「一般的にはこうです」で終わらせたくないのです。自分がその方の立場でも、同じ提案を実行できるか。実行した後、何が起こりそうか。そこを考えずに、耳当たりのよい言葉だけを渡すことはしない。その姿勢で関わりたいと思っています。

組織の問題を掘り下げると、感情が関わっていることがある

技術や制度の話をしていたはずなのに、掘り下げると、相手への不安や不信感が大きな影響を持っていることがあります。私は、組織の問題を考えるときに、この感情の側面を見落とさないようにしています。

「CEOに説明しても無駄だと思っている」「あの事業責任者とは、できれば話したくない」「部下に任せたいが、失敗されることが心配で手を離せない」。こうした状態では、情報や仕組みを整えるだけでは、次の行動に移れないことがあります。

例えば、相手への嫌悪感が強くなっていると、提案の内容を検討する前に拒否したくなるかもしれません。評価への不安が強ければ、確認すべき問題を抱えたまま、できると言ってしまうこともあるでしょう。その反応を本人の性格の一言で片づけず、どんな感情が判断に関わっているかを見たいのです。

私がEQを活用するときは、感情をなくすことを目指していません。自分が何を感じ、何を心配しているのかを捉え、その感情と考えを合わせて、行動を選べるようになることを大切にしています。

「相手が嫌いだから話さない」ではなく、嫌だと感じていることを認めたうえで、仕事として何を確認する必要があるかを考える。「怒ってはいけない」ではなく、何が大切にされていないと感じたのかを整理して伝える。感情を無視せず、それだけで行動も決めないということです。

もちろん、組織の問題がすべて感情に原因を持つわけではありません。役割が曖昧なことや、要求に対して人員が足りないことを、本人の気持ちの問題に置き換えるべきではないと思っています。仕組みと関係性、考えと感情の両方を見ることが、私の伴走の特徴です。

AIも活用しながら、一人で抱えなくてよい働き方へ

私は、AIを使うことと、人に相談することを対立させたいわけではありません。考えを整理するときにAIを活用することもあれば、誰かとの対話で自分の考えを確かめることもある。使えるものを使いながら、責任ある判断につなげればよいと思っています。

そのうえで、人として提供したいのは、その方の状況を継続して知り、前回の判断がどうなったのかまで一緒に考える関わりです。うまくいったときだけでなく、期待どおりにならなかったときにも、次の対応を考える。私は、そこまでを自分の役割として引き受けたいのです。

自分の悩みを整理して伝えることは、簡単ではないと思います。技術の話をしたいのか、経営との関係を相談したいのか、自分のキャリアを見直したいのか、本人にもまだ切り分けられていないことがあります。最初からきれいな相談内容になっていなくても構いません。

「このままでよいのか」「今の立場で何を変えるべきか」「CTOとして、もっと力を発揮したい」。そうした言葉から、その人が置かれている状況を一緒に整理していきたいと思います。

支援の料金についても、継続して相談する選択肢として検討していただけることを大切にしています。一律に高い、安いと伝えるよりも、何を相談でき、どのように関わり、どこまでを支援するのかを理解していただいたうえで判断してほしいと考えています。

CTOやVPoEとして孤独を感じている方。技術部長やマネージャーから、次の役割を目指している方。私は、その方がすでに持っている経験や強みを活かしながら、目の前のミッションと、その先に実現したいことの両方に向き合う支援を続けていきます。

責任を持つことと、誰にも頼らないことを同じにしなくてよい。私自身の成功も失敗も、これまでの支援で蓄積した経験も、そのために役立てたいと思っています。

グロースウェルでは、CTO・VPoEをはじめとする技術責任者の伴走支援・メンタリングを行っています。今、何に困っていて、どうなりたいのか。まずはそのお話を聞かせてください。