Masahiro｜仕組みで育てるマネジメント

元プライム上場企業で18年間、エンジニアリング組織を再設計・AI活用を仕組み化。現在スタートアップで実践中。VPoE・CTOの経験を経て『組織のOS』を整える実践知を発信｜AI時代に管理職が輝く設計を共有 | 相談・壁打ちはDMでお受けしております。

[Masahiro｜仕組みで育てるマネジメント @aligncraft]

同じ時期にAIを導入して、半年後に全く違う状態になっている組織がある。

片方は現場でAIが日常的に使われ、業務の一部がすでに再設計されている。もう片方は「検討中」「試験運用中」のまま、初期と変わらない状態だ。ツールの差ではない。人の差でも、予算の差でもない。

違いは「最初の3ヶ月に何をしたか」に集約される。

・定着した組織は、小さ���成功体験を意図的に設計して現場に見せた
・止まった組織は、大きな活用事例を作ろうとして身動きが取れなくなった
・定着した組織は、失敗を共有する場を作って心理的コストを下げた
・止まった組織は、成果を出してから展開しようとして、成果が出る前に熱が冷めた

AI活用の定着は、ツールの性能より変革の設計で決まる。最初の3ヶ月で「使うと良いことがある」という経験を現場に積ませられるかどうかが、その後の1年を決める。
あなたの組織のAI活用は、今どちらの軌跡を辿っていますか。

[Masahiro｜仕組みで育てるマネジメント @aligncraft]

AI時代のシニアエンジニアは、「教える人」から「設計する人」へ変わっていくと思います。

若手に答えを教えるだけなら、AIでもかなり代替できます。

シニアに求められるのは、
良い問いを立てること。
品質基準を定義すること。
AIの出力を疑う観点を渡すこと。
チームが学習する仕組みを作ること。

これは技術力が不要になる話ではありません。

技術力を、個人の実装から組織の判断軸に変換できる人が、これからのシニアだと思います。

[Masahiro｜仕組みで育てるマネジメント @aligncraft]

評価制度刷新で大事なのは、正しい制度を作ることだけではありません。

抵抗がどこで起きるかを先に予見することです。

誰の期待値が変わるのか。
誰が不利に感じるのか。
マネージャーの判断負荷は増えるのか。
現場に説明できる言葉があるのか。

ここを見ずに制度だけ入れると、運用で崩れます。

AI時代の評価制度も同じです。

AIを使った成果をどう見るのか。
人間の判断をどう評価するのか。

制度刷新は、思想ではなく運用設計です。

[Masahiro｜仕組みで育てるマネジメント @aligncraft]

これは本当にそう。「納得と理解」の違いですね。

[橋本祐造｜RECOMO CEO @yuzo_hashimoto]

社員が納得する経営とは、すべての意思決定に同意してもらうことではない。何を見て、何を優先し、なぜその選択に至ったのかが伝わっている状態である。透明性とは、結論ではなく判断の背景を共有することである。

[Masahiro｜仕組みで育てるマネジメント @aligncraft]

CTO採用が難しいから開発を外注した、というスタートアップは、ほぼ全て失敗します。

ChatworkからkubellへリブランドしたCEO・山本正喜氏が、自身のnote記事で「成功した会社を見たことがない」と語っています。

理由は発注先の能力ではなく、インセンティブ構造の不一致です。システム開発会社は、依頼された仕様を満たすプロダクトを完成させることで売上となる。完成がゴール。一方、スタートアップ側はプロダクトの完成がスタートで、ユーザーへ価値を生み出すことがゴール。

クライアント自身がユーザーでない限り、開発会社はクライアントの意向を満たすことに意識が向き、ユーザー価値の追求にはならない。この食い違いが致命的だと山本氏は指摘しています。

CTO採用から逃げて外注に頼ると、初期コストは下がってもPMFまで辿り着けません。レベニューシェアや資本参加でインセンティブを揃えない限り、外注はうまくいかな���。

CTO採用を検討中の方に、自社チェック用の問いです。

・外注を検討している理由は「CTO採用が難しいから」になっていないか
・外注先のインセンティブは、自社のユーザー価値と揃っているか
・PMFまで責任を持つ技術者が、社内にいるか

答えに詰まる項目があれば、DMで気軽にどうぞ。相談・壁打ち、ゆるくやってます。

[Masahiro｜仕組みで育てるマネジメント @aligncraft]

創業時に「君、CTO」と肩書を配ったスタートアップが、事業が伸びた後に詰む事例があります。

スタートアップ投資・支���に関わる清水氏が、決算が読めるようになるノートの対談で語った典型例です。「わたしCEO、あなたCFO、きみCTO」と、集まってきた人に肩書を配ってしまう。最初はワイワイと始まる。

ところがプロダクトが伸び、調達ラウンドが進むと、VCから「彼はファイナンスを分かっていない」「IPOまでは難しい」と指摘される。CTOも同じことが起きる。しかしリプレース話を表に出して募集できない。「CTO候補募集」と公募すれば、現CTOが「俺がいるじゃないか」と反発します。

仕方なく「本当はあなたの方が実力上ですが、まずは管理本部長として」という入れ方になる。働き始めれば実力差は周りに分かってしまう。降格人事はやりにくい。

学びは2つです。

・創業時に「CxOはフェーズで求められるものが変わる。より適任が現れたら変わってもらう可能性がある」と予め合意しておく
・うまく降りられる創業メンバーを評価する文化を作る。「資本市場との対峙は他の人がやるべき」と自ら言える人

肩書きは、創業時に配るのではなく、フェーズに応じて再設計するもの。

[Masahiro｜仕組みで育てるマネジメント @aligncraft]

入社直後に占いをやらされたCTOの話があります。1年もたずに辞任しました。

テンミリ転職で公開された実録の体験記事です。大手を経てCTOに憧れて、あるスタートアップに参画。入社直後、社長との朝食会で話題のほとんどが占い。組織判断にも占いを使っていた、というものでした。

最初の1on1で「もっと業務の話をしろ」と叱責される。1週間後、社長が全社チャットに突然「社内恋愛禁止」を投稿。1ヶ月後、社長の発言で社員が退職。入社3ヶ月時点で、同期入社9人中6人が辞めました。

社長から最初に求められたのは「採用」。今年30人、来年は新卒を大量採用という計画だったが、エンジニア10人で人件費込み年間1億円規模の投資が必要なのに、資金根拠の説明はなかった。一方で採用計画は週次にブレイクダウンされ、進捗報告を求められた。

失敗の構造は明確です。事業計画も意思決定軸もないまま、CEOがCTOに「採用」「作り直し」を要求し続ける。CTOは経営者の機嫌取りに時間を奪われ、現場は仕様変更に消耗する。

【教訓】CTOは入社前に、CEOの意思決定スタ���ル、事業計画の有無、過去半年の方針変更回数を必ず確認する。違和感は、入社後に消えない。

[Masahiro｜仕組みで育てるマネジメント @aligncraft]

外部からCTOを招聘するとき、いきなり「CTO」の肩書でオファーするのは、ほぼ確実に失敗します。

エンジニア社長の種市貴文氏は自身のnote記事で、CTOで採用してはいけない理由を3つ挙げています。既存エンジニアとの間でハレーションが起きる。入社時点でキャリア上限に達し、モチベーション源が給与だけになる。CTOに求められる役割は組織フェーズで変わるため、適性を見極めずに就任させると双方が不幸になる���

CTO人材紹介のAXC社の記事でも、既存組織がある企業では「CTO候補」として採用し、実績を上げた上で昇格させるのが双方にとって安全だと指摘されています。

実際の失敗パターンはこうです。ビジョン共鳴で外部からCTOを採用。社内エンジニアは「あの人は何の実績で上に立つのか」と不信感を持つ。CTO側は早期に肩書きを得たことで、業務よりも社内政治に消耗し、半年で��係性が壊れる。

教訓は3つです。

・初回オファーは「VPoE候補」など段階肩書きで出す
・3～6ヶ月のワークサンプル期間を設ける
・実績ベースでCTOへ昇格する道筋を、入社前に明文化する

肩書きは、入社前に渡すものではなく、実績で取りに行くもの。

[Masahiro｜仕組みで育てるマネジメント @aligncraft]

同じCTOが数年で「動きが悪い」と言われ始める。これは能力低下ではなく、フェーズ変化の構造問題です。

エンジニア社長・種市貴文氏のnote記事「スタートアップCEOがやってしまいがちな失敗す��CTOの付き合い方」が、CEO×CTOの典型トラブル3選を整理しています。そのひとつが、CEOが求めるCTOの役割の変化に、CTOが気づかないパターン。

記事によれば、CTOの役割はフェーズで入れ替わります。
・社員10名以下：寝食忘れてコードを書くスーパープログラマー
・社員50名前後：採用と組織作りに注力する組織マネージャー
・社員100名以上：複数チームを束ね、開発工数の費用対効果を語り、半年〜1年先の開発ビジョンを��すアーキテクト

同じ肩書きのまま、中身が入れ替わる。初期から参画しているCTOほど、求められる役割が変わったことに気づきにくい。CEOがすり合わせを怠ると、互いに「最近違うことを求められる」とすれ違い、最後は退任に至る。

ここまでが記事の指摘です。

※ここからは私見。

この役割転換は、AI時代にもう一段加速すると見ています。生成AIが実装の多くを引き受ける今、CTOの価値は「コードを書く／書かせる」から、AIを前提に組織の生産性をどう設計するかへ移っていく。

そしてそれは技術組織だけの話で終わりません。AIネイティブな組織は、評価制度・等級・採用基準・チーム編成まで含めて作り替えないと成立しない。「AIをどれだけ使ったか」ではなく「AIを前提に成果の出し方をどう再定義したか」が評価軸になる。

つまりこれからのCTOは、技術の境界を越えて人事制度にまで越境する役割になる。越境しないCTOは、数年どころかもっと短いサイクルで「動きが悪い」と言われるようになります。

CTOの「動きが悪い」は、本人ではなく、組織側の期待値の更新漏れ。そしてその更新は、AI時代には人事制度��と巻き取る覚悟が要ります。

出典：種市貴文「スタートアップCEOがやってしまいがちな失敗するCTOの付き合い方」（note）
https://t.co/XCoCJlxfDo

[Masahiro｜仕組みで育てるマネジメント @aligncraft]

技術者は「作る力」に全集中する。だからこそ、契約設計を後回しにする。退任が来たとき、その設計の不在が4年分の成果を一瞬で消す。

Hacker Newsに共有された事例がそのまま教科書になる。21歳でCEOと50/50で共同創業したCTOが、4年間プロダクトを作り、4名のチームを率いた。退任後、CEO側の新株発行で持分は50%��ら25%に希薄化。訴訟費用が回収額を上回り、諦めるしかなかった。

SHAがない共同創業は、在籍中は対等に見える。だが退任した瞬間、株式を持っているだけの外部株主になる。議決権も情報アクセスも失った状態で、希薄化に対抗する手段はほぼない。

私自身、27年間エンジニア組織を見てきて、共同創業や技術パートナーシップの���綻を何度も近くで見てきた。破綻の原因は信頼の崩壊ではなく、信頼だけで設計を省略したことにある。

・SHAは創業初日に結ぶ
・リバースベスティングとクリフで時間軸を設計する
・退任時の買取条件と希薄化制限を契約に入れる

信頼と契約は対立しない。信頼があるからこそ、冷静なうちに設計できる。

[Masahiro｜仕組みで育てるマネジメント @aligncraft]

ビジョン共鳴を理由にCTOを採用したスタートアップが詰む事例は、もはや典型です。

スタートアップ投資・支援を行うシニフィアン社の公開��談で、共同代表は次のように語っています。「素晴らしい経歴の持ち主が現れると、二度とうちには来ないとバイアスがかかり、過剰評価してしまう」。

語られた失敗パターンはこうです。技術バックグラウンドのないCEOが、ビジョンに強く共鳴した候補者をCTOに採用。配属部門の責任者から技術力への懸念が出ても、経営者が押し切る。入社後、胝心のエンジニアリング能力が足りず、プロダクトが進まない。

ここで起きている��は、ある側面の過剰評価と、それ以外の側面の評価の曖昧化です。技術評価ができない領域だからこそ、自分が確信を持てる経歴・人柄・カルチャーフィットで決めてしまう。これが期待値ギャップの本質です。

学びは明確です。CTOの技術力評価は、外部の信頼できる技術者にスクリーニングを依頼する。CEOが面接で確認するのは、過去の技術選定と意思決定の言語化解像度です。

ビジョンは入社後に揃えられる。技術力は揃えられない。

[Masahiro｜仕組みで育てるマネジメント @aligncraft]

CTO や VPoE を採���する前に、ひとつだけ確認したい問いがあります。

「自社の組織課題を、3つに絞って言語化できますか」

「3つ」というのが肝です。10個書ける CEO は多い。1個に絞れる CEO もいる。でも 3つに絞ることが、いちばん難しい。

10個のままだと、求人票が総合職になります。あれもこれもできる人を探すことになり、結果として誰の課題にも刺さりません。1個だけだと、その課題が解けたあとに何を任せるかが消えます。3年単位で活躍してもらう設計になりません。

3つに絞る作業は、優先順位の宣言です。何を後回しにするかを、CEO が腹をくくる作業です。

絞れない理由は、たいてい次の3つのどれかです。

・課題が事象レベルで止まっている(「離職が多い」のままで、構造に落ちていない)
・経営の打ち手と切り離されている(事業計画と組織課題が別文書になっている)
・CEO が手放す覚悟が決まっていない(全部自分で見たいが残っている)

3つに絞れたとき、求人票はほぼ書けています。逆に言えば、3つに絞れていない状態の求人票は、書いた本人にも何を採るか分かっていません。

求人票を書く前に、まず A4 1 枚に課題を 3 つ書く。それが、採用設計の起点です。

「3つに絞る」が難しい方、DMで気軽にどうぞ。整理の壁打ち、ゆるくやってます。

[Masahiro｜仕組みで育てるマネジメント @aligncraft]

@masamichihon 正道さん、その差は確実に開いていくと思います！ 日常の中で「これはこのAIでいけそうだ」という判断を積み重ねている人は、仕事でも任せどころの見極めが一瞬ですね。 判断の速さは才能ではなく、日々の試���回数の積み重ねなのかもしれませんね。

[Masahiro｜仕組みで育てるマネジメント @aligncraft]

CTO と VPoE の違いを、肩書きで定義しても意味がありません。
責任分界で定義しないと、採用後に必ず役割が衝突します。

CEO が採用前に言語化すべきは、次の3点です。

・CTO に残す判断:技術戦略、アーキテクチャ方針、技術的負債の許容範囲、長期の技術投資
・VPoE に渡す判断:組織設計、評価、採用、開発プロセス、マネージャー育成
・EM に任せる判断:チーム運営、1on1、目標設計、短期のリソース配分

この境界が紙の上に書か���ていないまま採用すると、CTO と VPoE は同じ椅子を取り合うか、互いに「それはあなたの領域では」と押し付け合います。優秀な2人を採っても、組織は前に進みません。

責任分界は、人柄や阿吽の呼吸ではなく、設計の対象です。CEO が「この判断は誰が持つか」を一文で書けるようにする。書けない判断があるなら、それは採用前に決めるべき宿題です。

肩書きではなく、判断のリストで定義する。これが、CTO・VPoE 採用の前提条件です。

[Masahiro｜仕組みで育てるマネジメント @aligncraft]

CTO・VPoE を採用する前に、CEO が見るべき観点は次の3つです。

1. 意思決定の所在
誰が技術選定を決め、誰が評価制度を決め、誰が組織変更を決めているか。今、CEO に集中していないか。

2. 採用要件の出どころ
求人票の要件が、組織課題の言語化から導かれているか。それとも「他社がそう書いているから」になっていないか。

3. 入った後の責任分界
CTO・VPoE・EM・PdM の責任が、紙の上で重なっていないか。重なっているなら、入った人は必ず板挟みになります。

この3点が整理されていない状態で採用に進むと、優秀な人ほど早く違和感に気づきます。半年で退職、または「���待された役割を果たせていない」と評価されて疲弊する。どちらも、本人の問題ではなく設計の問題です。

採用前にこの3点を 1 枚にまとめると、求人票の精度が上がり、面接で確認すべき論点も明確になります。候補者からの逆質問にも、設計者として答えられるようになります。

採用要件は、組織設計の最後に書くもの。

[Masahiro｜仕組みで育てるマネジメント @aligncraft]

DXが失敗するのは、業務プロセスの変更というhowだけを現場に降ろすからだ。

体に染みついたやり方を否定されたと感じれば、現場は反発する。当然である。

・howを先に降ろす → 今までの最適解の否定として受け取られる
・現場は自分たちの仕事の価値を守ろうと抵抗する
・推進側は反発を抑えにかかり、関係がこじれて進まなくなる

最初に降ろすべきは、やり方ではなく数字目標の方だと考えている。

その数字を達成できるなら、やり方は問わない。現場が自分の頭で「この数字、今のやり方では届かない」と気づいたとき、DXは初めて手段として選ばれる。howは降ろすものではなく、現場が選び取るものだ。

皆さんの現場では、DXは目標として降ろしていますか、それともやり方として降ろしていますか？
線引きを変えるだけで、進み方は変わるかもしれませんね。

[Masahiro｜仕組みで育てるマネジメント @aligncraft]

CTO・VPoE 採用に失敗する CEO と、成功する CEO の差は、面接の質ではありません。
採用前に何を整理しているかの差です。

失敗する CEO は、こう考えます。
・優秀な人を採れば、技術組織の問題は片付く
・採用要件は人事と一緒に作ればいい
・役割の細かい話は、入っ���から本人と決めればいい

成功する CEO は、こう考えます。
・組織課題を言語化してから、採用要件を逆算する
・自分が手放す判断と、残す判断を先に定義する
・CTO・VPoE・EM の責任分界を、自分の言葉で説明できる状態にする

入社後に「思っていた役割と違う」と言われるのは、本人の問題ではなく、設計の問題です。役割が定義されていない椅子に、優秀な人を座らせても、組織は動きません。

VPoE 採用が機能している企業に共通しているのは、特別なスカウト網ではありません。CEO が組織設計を自分の言葉で語れることです。語れる範囲だけが、採ってよい範囲です。

採用は、面接ではなく設計で決まる。

[Masahiro｜仕組みで育てるマネジメント @aligncraft]

CTO や VPoE を採用する前に、CEO として次の問いに答えられますか。

・自分が CTO に残す判断は何か
・VPoE に渡す判断は何か
・EM に任せる判断は何か
・人事評価の最終責任は誰が持つのか
・採用要件は、どの組織課題から導かれているか

このうち、ひとつでも即答できない項目があるなら、その状態で採用に進むのは早いです。

「優秀な人が来れば、整理してくれる」という期待は、よくある失敗パターンです。整理する権限の設計こそ、CEO の仕事です。来た人に丸投げした瞬間、その人は組織設計者ではなく、火消し役になります。

採用前に決めるべきは、給与レンジでも肩書きでもありません。決めるべきは、CEO 自身がどこまで関与し、どこから手を引くかの境界線です。境界線が引かれていない椅子は、誰が座っても機能しません。

求人票に書く前に、この5つを 1 枚にまとめてみてください。書けないなら、まだ採用のタイミングではありません。

答えに詰まる項目があったら、DMで気軽にどうぞ。相談・壁打ち、ゆるくやってます。

[Masahiro｜仕組みで育てるマネジメント @aligncraft]

CTO・VPoE を採用するとき、最初に書くべきは求人票ではありません。
先に書くべきは、CEO 自身が手放す判断のリストです。

CEO が何を手放さないまま採用要件だけを整えても、入ってきた人は意思決定の入り口で詰まります。技術選定、評価、��用、組織再編。判断権限が CEO のままなら、CTO・VPoE は実質「上���係」になります。

求人票に「裁量を持って組織を作っていただきます」と書く前に、CEO 自身が答える問いがあります。

・自分はどの判断を、いつまでに手放すのか
・手放した判断に、どこまで口を出さないと決めるのか
・任せた人の判断と自分の判断がずれたとき、誰の判断を優先するか

ここを言語化しないまま採用すると、優秀な候補ほど早く違和感に気づき、半年以内に離れます。残った人は、肩書きはあっても権限のない椅子に座り続けることになります。

VPoE 採用が成功する企業は、求人票が良いのではありません。CEO が手放す範囲を、自分の言葉で定義できている企業です。

採用要件の前に、手放しの設計から始める。

[Masahiro｜仕組みで育てるマネジメント @aligncraft]

CTOがCHRO及びCAIOを兼ねるのは、単なる人事異動ではない。

メルカリが今日発表した「HR for an AI-Native Company」は、採用・評価・組織設計をAI前提で作り直すという宣言だ。

AI活用の浸透と組織変革を同じ人間が担う。それは、誰を採り、どう評価し、何を基準に意思決定するか、すべてをAI前提で設計し直さなければ組織が変わらないと判断したからだ。

「AIツールを入れたら次は組織を変える番」ではない。評価・採用・責任分界が変わらない限り、個人の生産性は組織の出力に繋がらない。

皆さんの会社では、採用要件にAI時代の観点はいつ入りましたか？

[株式会社メルカリ @mercari_inc]

メルカリは、執行役員 CTO Japan Businessの木村俊也が2026年6月1日付で最高人事責任者（CHRO：Chief Human Resources Officer）および最高AI責任者（CAIO：Chief AI Officer）に就任することをお知らせいたします。

木村は、CHRO 兼 CAIO 兼 CTO Japan Businessとして新たに掲げるビジョン「HR for an AI-Native Company」のもと、AI戦略と人事戦略の責任者を一体化し、働き方、意思決定・承認プロセス、組織構造、リソース配分といった人と組織の運営基盤をAI前提で再設計することで、AI-Native Companyへの変革を加速させてまいります。

また、新体制のもとAI-Native人材の採用も本格的に強化してまいります。

プレスリリース：https://t.co/C7dwIyqPrI
CHROメッセージ：https://t.co/lWsyfW7e6d

[Masahiro｜仕組みで育てるマネジメント @aligncraft]

CTO や VPoE を採用すれば、技術組織の課題は解決する。
これは、成長企業の CEO がもっとも陥りやすい誤解です。

���秀な人を採っても、何を任せる組織なのかが定義されていなければ、機能しません。採用は、組織設計の結果として現れる行為です。順序が逆転すると、必ず詰まります。

CEO が採用前に整理すべきは、次の3点です。

1. 自分が手放す判断と、残す判断
2. CTO・VPoE・EM の責任分界
3. 採用要件が、どの組織課題に紐づいているか

ここが曖昧なまま採用すると、新しく入った人は「何でも屋」になります。責任範囲が定義されていない椅子に、優秀な人を座らせても、組織は動きません。半年で違和感が生まれ、1年で離脱、というパターンは珍しくありません。

技術組織がスケールしない原因の多くは、能力ではなく構造の問題です。採用要件は、組織設計の最終成果物として書かれるべきものです。

採用は、設計してから動かす。これが、CEO の最初の仕事です。