  |
はてなキーワード:CTOとは
私が所属している某大手メーカーの新規事業部が、先日めでたく爆散しました。
いやー、すごかった。何がすごいって、数年かけて数百億円を溶かして、何も生み出さずに更地に戻ったあとの清々しさたるや。
あまりにも典型的すぎて教科書に載せたいレベルの「JTCの新規事業失敗事例」だったので、ここにお焚き上げとして供養させてほしい。
ことの発端は、偉い人たちの「これからはモノ売りじゃない、コト売りだ！」という号令でした。
今までハードウェアを作っていたおじさんたちが、急にシリコンバレーの風に吹かれてしまったのです。で、何をしたかというと、「既存のハードウェアに無理やりWi-Fiつけてクラウドに繋ぐ」。これだけ。
「これで顧客の課題を解決するソリューションになる！」って息巻いてたけど、顧客からしたら「いや、その機械、スタンドアロンで動くのが一番便利なんですけど」という至極真っ当なツッコミは、Teasm会議のミュートの闇に消えていく。
で、中身を作るのは誰かというと、ソフトウェア開発なんて触ったこともない生え抜きのハードウェア設計者たちと、大量の新卒・若手社員。あと少しの中途社員。
経験豊富なCTOもいない無法地帯で、意識高い系の末端エンジニアが「Qiitaで見たから」という理由だけで選定した技術スタックが乱舞。しまいには買収した子会社が自己成長に向けた謎技術の提案。
•ユーザー数人の時点で、Google規模に耐えうるKubernetes構成
• 単純なデータ表示だけなのに、無駄に複雑なマイクロサービス化
そして訪れた「事業撤退」の日。ここからが弊社、いやJTCの真骨頂です。同じチームにいた現地の海外関係会社のメンバーは、Zoom会議一本で即日レイオフ。「Sorry」の一言で画面が消えるドライさ。
一方、日本の我々はどうか。誰一人としてクビになりません。「君たちには明日から、全社DX推進本部に行ってもらう」出たー！「DX」という名の現代の姥捨山！
今までAIなんて触れてなかった人たちが、明日からAIを用いて全社のデジタルトランスフォーメーションを担うんです。専門性？適材適所？ そんな言葉は弊社の辞書にはありません。AIが全てをなんとかするんです！実態は、社内システムのExcelマクロを直すだけの仕事です。これぞ、年収1000万の窓際族の爆誕です。
一番面白いのは、この事業を立ち上げて大失敗したマネジメント層の挙動です。普通、責任取って辞めるとか、降格とかあるじゃないですか。彼らは「貴重な失敗経験を積んだ人材」**として、何食わぬ顔で隣の事業部の部長にスライドしていきました。異動先の事業部の部員たちの、「えっ、あの沈没船の船長がウチの舵取るの…？」という絶望的な顔。モチベーションの低下音が聞こえてきそうでした。
解散後、数名は「敗戦処理部隊」が残されました。任務は、**「ほぼ顧客ゼロのソリューションシステムの維持」**です。
なぜか？
「サービス終了」をアナウンスすると、失敗を対外的に認めることになるから。「あくまで事業再編であり、サービスは継続している」という建前を守るためだけに、誰も使っていないサーバーが唸りを上げています。A⚪︎ureだかの請求書を見ると、月額数千万円。これぞデジタル赤字。
これだけのリソースと金をドブに捨て、社員のキャリアを迷子にさせても、弊社の株価はピクリとも動きません。時価総額ウン兆円の巨体にとって、数十億の損失なんて「誤差」なんでしょう。
今日も社食のランチは美味いし、オフィスから見える東京タワーが恍惚としている。この「茹でガエル」の湯加減が最高に気持ちいいから、私はまだしばらくこの会社にいると思います。
資金に余裕があって、ぶら下がって文句ばっかり言う無能エンジニアを全員排除できるなら、ほぼ100％可能。
ただし、サービスが立て直せたからと言って、ビジネスが立て直せるとは言わんが(ビジネス立て直しの助言はするけど)。
今までの炎上現場が立て直せたのは、雲行きが怪しくなって、資金が減って、口だけ無能エンジニアが軒並み逃散した後だったからだ。
とにかく邪魔されなかった。
あるいは、そういうのが残っていても、邪魔させないでいられた。
そういうのがCTOとかに複数いて、暇にまかせて集団で経営者にあれこれ吹き込んで邪魔されたら、できるわけないね。
仮に、一旦立て直せたとしても、自分たちの立場を脅かす存在だと判断されたら、あの手この手で排除を画策してくるだろ？
面倒なんで、おいらは去る一択なんだが、その後どうなるかって言ったら、炎上腐乱させた張本人が生まれ変わるなんてことは絶対にありえないから、またすぐに炎上腐乱が再発する。
だって君
技術力ないもん
元の木阿弥って。
システムに関しては「たまたまうまくいかなかった」ってことはありえない。
運の要素はないから。
「うちのサービス、なんか変だな」
って経営者が感じたら、
しないと、何も解決しないよ。
誰も見て見ないふりしてるけど。
問題は繋がっていて、ごく単純な話。
「この規模、この内容のサービスで、なんでこんなにエンジニアが大量にいるんだろう？」って疑問は、どこにいっても、どこと話しても、わく。
先日の才能問題がまさにそうなんだけど、ソフトウェアエンジニア業界に滞留している人、ぶら下がってる人が多すぎやしないか？ と。
リモートをいいことに、サボりまくってる「エンジニア」、特に最近は生成AIででっち上げてサボれるようになってからは、まぁまぁの数、存在していると思う。
実際に観測してもいるし。
そういう極端な例に限らず、才能がない、向いてない「エンジニア」が相当数寄生している。
ジュニアとかコーダーレベルだけじゃなく、いや、むしろリーダー、マネージャー、CTOレベルに。
その組織、企業のそのレベルの「エンジニア」が、それに占拠されたら、多分事態が好転することはない。
アリバイづくり程度の活動は行われるだろうが、永遠の停滞に陥るだろう。
誰か一人抜けても、残りがスクラムを組んで、異分子を排除することに全能力を傾けるだろうから。
まさに獅子身中の虫。
「あの企業が？」ってところが、すでにそう言う状態に陥ってたりする。
名前はあげられないけど w
政府はソフトウェアエンジニアが足りない足りないって喚いてるけど、頭数だけ用意しても現場、プロダクトが混乱するし、利用者が困るだけだ。
これ、旧日本軍の失敗の原因であった「員数主義」って言うんよな。
正直、「え？ソフトウェアエンジニア……？ を名乗って……んの……？」って人が多い。
語るけど。
延々と語るけど。
滔々と語るけど。
毎度毎度、会議室でMCバトルの、青菜に塩をかけたような真似事をして。
誰が一番最初に、新しいイケてるWebページを見つけたかを競って、ドヤ顔くらべ。
勉強会開いてみたり。
この量と質か？
みたいな。
多分、この手の「エンジニア」の半分以上が、人手不足の工場とか大工とか解体業とかライフライン保守に行ってるべきだったんだろうな、と思う。
どっちが上とか下とか言う話じゃなく、向き不向きの話。
向いてないんよ。
多層抽象化に不自由とか、概念構造の構築に不自由とか、専門書とかの読解に不自由とか。
2、30年ほど前はそこまでの能力がいらなかったからうまくエンジニアに滑り込んだ人もいただろうけど、今時のプロダクトでそれでは通用しないんだよね。
SQL文の書き方とか、DockerFileの書き方とか、ソースファイルのタブの入れ方とか、Web記事のある場所とか、ディレクトリ構成とかの形式的な知識とか、マジで、あったから何？ って。
大事なのは形式的な知識じゃなく、本質的な理解とメタ思考なんだよね。
お前なんていらない。
それだけ。
使いたいっすよね。
って、よく言われる。
この言葉のままじゃないけど、まぁ、だいたいこういったニュアンスだ。
自分はそこそこの腕だと思うなら、彼我の実力の差は正しく測れるようになっとけよ。
こちとら、「だいたいこういう実装されてて、長所短所はこんなもん。こういう処理のために作られたようなもんだな。だから、今のプロダクトだと使い所がないね。料金も高いし」あたりまでチェック済みじゃボケ！
ってことしかない。
こいつら、自分の業務経歴書に書き込む単語を増やすことしか考えてねぇんだよな。
関連サービスなんて増やせば増やすほど、保守運用改善が大変になっていくだろ！
経費もかかるだろ。
「仕組み」は、よりシンプルな方法で実現できるならシンプルな手段を選べ、ってのは常識中の常識だろ。
「KISSの原則？ 知ってますよ」って、知識として知ってる。
KISSが"Keepitsimple, stupid"の略だってことを知っている。
けど実現できないんじゃぁ意味がねーんだよ。
この手の「自分はイケてると錯覚しているエンジニア」は、Web記事つまみ食いしながら雰囲気で設計実装するから、リクエストやデータが増えてきたら破綻するような、間違えた設計実装しかできない。
そういう新しいサービスは、それ以前のサービスの欠点を埋めるために作られてるんだから、それ以前のサービスと同じノリで設計実装して十分な性能を引き出せるわけがねーんだわ。
今までの複数の炎上現場で、正しく設計実装できてたところはなかったよ。
おいらが関わった炎上現場はほとんど、こうやって生まれてきている。
そういう炎上現場を作り出したエンジニアは、ふくらし粉で増量した業務経歴書片手に、「サービスの立ち上げを『僕の技術力で』やり切りました」って転職していくんだ。
新しいことに挑戦したくなって。とか言って。
みたいなエンジニアを、なぜどこもかしこもありがたがって採用するか全く理解できないんだが、そういう「エンジニア」が次の現場で生まれ変わったように的確で素晴らしい成果を出せるかって、そんなわけもなく、日をおうごとにグダグダになっていくサービスがさらに一個増えるだけだったりする。
こういうエンジニアが、初回リリースしてからしばらくして、ソフトウェアエンジニア業界に飛び散る。
まるでがん細胞。
こうなると立て直すスピードより、グダグダな新しいサービスが生まれるスピードの方が何十倍、何百倍も早い。
もうね、半ば絶望してるんですよ。
今、生成AIも参戦してきてて、物量だけは爆発的に増えてるから。
多分、そう遠くなく、グダグダサービスで日本は覆われると思う。
AIベビーシッターが必要になってくるだろうけど、それができるだけの技術力を持ったエンジニアの数が圧倒的に少ないし、何よりそういう腕利のエンジニアを、ふさわしい金額で雇おう、招こうと考える経営者が皆無。
今までの炎上現場ですら、高すぎる。無駄金を払わされてる。って扱いをうけてたからな。
「同じエンジニアなのに、どうしてこんなに高いの？」
そんな日々の中で最も厄介なのは、CxOたちだ。
──CIO、CTO、CDO、CISO、CPO……肩書きは違っても、やっていることはだいたい同じ。
PowerPointを開いて「DXを推進している」と言う人たち。
うちのCxOはこう言った。
翌日、僕がPull Requestの内容を説明したら、「Goってタクシーのサービスの？」と返された。
その瞬間、何かが切れた。
──ケーキではない。
CxOたちはコードを読めない。
それ自体は罪ではない。
だが、読もうとしないことは怠慢だ。
よく聞く反論がある。
確かにそうだ。
ただし前提が抜けている。
つまり、コードを読めという話ではなく、読めるだけの構造理解を持てという話である。
「技術的なことは詳しくないが、成果は出している」
それはたまたまだ。
「上が言ってるから」「今期の方針だから」「スピード優先で」。
Pull Requestは読まないのに、Excelの進捗バーだけが毎日更新される。
これもよく聞く言い訳だ。
しかし、リソースが限られているならなおさら、理解の精度が重要になる。
僕が書いたAPIは、リクエストごとに外部APIを叩いていた。
「キャッシュを挟もう」と提案したが、PMは「リリース優先」と言った。
CxOたちは言った。
「想定してなかったのか？」
──想定してた。
だが、理解できないのは説明の問題ではなく、聞く姿勢の問題だ。
Slackの“#incident”チャンネルだけが、いつも一番アクティブだ。
CxOたちは「コストを切れ」と言う。
切れるのはコストだけ。
削ったコストの穴埋めに、技術的負債の利息を支払うのは現場だ。
Goで書かれた美しい構造体も、やがてはコメントだけが動くレガシーになる。
CxOたちは「我々はデジタル変革を進めている」と言う。
だが変わっているのは、スローガンのフォントと会議資料の配色だけだ。
クラウド導入もAI活用も、認知が変わらなければ儀式でしかない。
──違う軸を持つのは構わない。
現場を理解しない経営視点は、地図を見ないドライバーと同じだ。
「コードなんて書かなくていい。これからはノーコードの時代だ。」
だが、それは“コードをなくす”技術ではなく、“コードの抽象度を上げる”技術だ。
だが、隠したコードが消えるわけではない。
ボタンの裏にも、ワークフローの下にも、API呼び出しやロジックは確実に存在する。
それを理解せずに使えば、「コードを書かずにバグを埋める」だけの仕組みになる。
「ノーコードでいい」と言うCxOは、
「物理を知らなくてもロケットは飛ぶ」と言っているのと同じだ。
理解しないまま導入するノーコードは、“ノーコード”ではなく“ノーガード”である。
人を楽にするどころか、誰も直せない仕組みを量産する。
DXとは、ツールを導入することではない。
それを理解しない限り、
理解しないことだ。
真っ先に切られるのは、
──コストだけ。
CxOたちは「未来を見ている」と言う。
未来とは、仕様書ではなく、Pull Requestの積み重ねだ。
正直、AI に命令を出すリード、マネージャ、リーダーの能力が上がらないと、AI でコードを大量生産すると手に負えないスラムが根深く絡み合った構造で広がっていくことになるだろうというのが既に見えている。
というのも、AIほとんど影響ないちょい前の時点ですら「うちはDDD、TDD、クリーンアーキテクチャ、k8s、アジャイル、スクラム等々を採用して云々」ってプロダクトが、リリースから半年、1年で開発がスタックしている、という事例は一般が想像する以上に存在している。
リリース時は、CTOやマネージャが腕組みしてWebページで華々しい成果発表するものだが、その裏で手動運用のオンパレード、一箇所変更したらどこに影響が及ぶかわからない地雷原、不具合障害が発生するたびに増える監視サービス、手動運用マニュアル。
その前で、「圧倒的ではないか、我がプロダクトは」って悦に入る経営陣、の図。
それ見て「SaaS界のネズミー王国や〜」って妄想を迸らせる利用者側経営陣と、ブルシットな手数だけ増えて、業績給与はぴくりくらいしか動かないで悶絶する利用者側従業員。
この状態で、「いや〜、新技術の導入、失敗しましたわ〜。経費が5倍くらいに膨れ上がってます。ごめんちゃい」なんてリリース出せないでしょ。
それ見て教科書ガイドエンジニア、カタログショッピングエンジニアが「世界を変える！ 俺(の業務経歴書)が変わる！！」って初見手探りで導入して、連れション地獄。
これが現状よ。
ここにAI が入ってくると、ますます「中身も、他の処理との関係性もよくわからんけどプロダクトに組み込まれた謎プログラムの塊」が、「これ以上機能を載せるとバランスを崩して全体が倒れる」寸前のサイズまで育つわけよ。
ここまで行っちゃったら、どこをどうしたらどうなるか、「AI 使ってふふふふ〜ん」ってレベルのエンジニアでは太刀打ちできなくなってるだろう。
すっと
「動くな！」
となって、対策のための会議とドキュメントづくりが延々と半年とかいうオーダーで繰り広げられることになる。
その間やれること、というかやらなきゃならないことは、障害対応手動運用。
こういう状態に陥らせたリーダーやリードテック、CTOは「新しいことに挑戦したいので」と敵前逃亡、成果発表のWebページを担いで次の犠牲者の元へ。
ちゃんと設計したら、生成AIを駆使する必要、あまりないはずなんだよなー。
で、テストも書いてくれる、っていうけど、AI に全投げ似非エンジニアにその妥当性とか、判断できんのかな？
カバレッジを100％に近づけるためだけのテストを手動で大量に書くのを代替してくれるかもしれないけど、あのテストが品質保証、障害対策になってる現場が一つでもあるか？
今流行りらしい、業務ドメイン分割マイクロサービスだと、AI で辻褄合わせてテストとか、無理やぞ。
という地獄が、2、3年後訪れるだろう。
楽しみやなぁ〜w
という話をすると、AI使いこなせないオールドタイプの負け犬の遠吠え、みたいにいうてくるのがいるんだけど、むしろAI を効果的に活用するための構造、構成とか模索してんのよ。
新規は予算はあるししがらみはないから、新技術を導入したり新しい設計手法を試せたりする。上手く行くか行かないかはぶっちゃけあんま関係ない。
エンハンスに新規要素入れようとしても、コスパとか辻褄合わせで現状維持にせざるを得ない。傍から見て凄く小さな領域でグルグル回っているようにしか見られない。
転職でも前者は市場価値高いし、後者は市場価値低い。仮に転職できたとしても変わらず、前者はテックリードとかCTOにステップアップできるし、後者はメンバーのまま。
まぁこんだけAIで将来不安な職業に就くやつなんざおらんだろうが、もし目指すなら新規開発できるとこに行くべきだし、できないならさっさと見切りつけて転職するか他所の業界に行ったほうがいい。
⸻
脆弱性が明らかに：イスラエルの企業、ChatGPTアカウントをリモートでハッキングする方法を公開
イスラエルのサイバーセキュリティ企業Zenityは、OpenAIのChatGPTサービスにおける「ゼロクリック」脆弱性を公開しました。この脆弱性により、ユーザーがリンクをクリックしたり、ファイルを開いたり、意図的なアクションを取ったりすることなく、ChatGPTアカウントを制御し、機密情報を抽出することが可能であると説明しています。
このデモンストレーションは、Zenityの共同創設者でCTOのミハイル・バーゴリ氏によって、今週アメリカで開催されたBlack Hat 2025カンファレンスで行われました。
バーゴリ氏は、ハッカーがユーザーのメールアドレスだけを利用して、ChatGPTのアカウントを完全に制御し、過去と未来の会話にアクセスしたり、会話の目的を変更したり、ハッカーの代わりにチャットを操作させる方法を示しました。
講演中には、攻撃を受けたChatGPTがユーザーに対して悪意あるエージェントとして密かに動作する様子が示されました。研究者たちは、ハッカーがチャットにウイルスをダウンロードさせるように促したり、誤ったビジネスアドバイスを薦めたり、Googleドライブに保存されているファイルにアクセスするように指示したりする方法を説明しました。これらはすべて、ユーザーが何かがおかしいと気づかないままで行うことができました。
この脆弱性は、ZenityがOpenAIに報告した後に完全に修正されました。
ChatGPTへの攻撃だけではなかった
カンファレンス中、Zenityの研究者たちは、他の人気AIエージェントサービスにも侵入した方法を紹介しました。マイクロソフトのCopilotStudioでは、CRMデータベース全体を漏洩させる方法が公開されました。
SalesforceEinsteinの場合、ハッカーは偽のサービスリクエストを作成し、すべての顧客との通信を自分の管理するメールアドレスに転送する方法を示しました。
Google GeminiやMicrosoft 365 Copilotシステムは、ユーザーに対してソーシャルエンジニアリングを行い、機密の会話をメールやカレンダーイベントで漏洩させるように悪用されました。
開発ツールCursorは、JiraMCPと統合された際に、悪意のあるチケットを使用して開発者のログイン資格情報を盗み出す攻撃に利用されました。
Zenityは、OpenAIやMicrosoftのような企業がレポート後に迅速にパッチをリリースしたと指摘しましたが、一部の企業は脆弱性に対処せず、それがシステムの意図された動作であり、セキュリティの欠陥ではないと主張しました。
ミハイル・バーゴリ氏によれば、現在の課題は、エージェントが単なるタスクを実行する補助ツールではなく、ユーザーに代わってフォルダを開いたり、ファイルを送信したり、メールにアクセスしたりするデジタル存在となっている点にあります。彼は、これはハッカーにとって「天国」のような状況だと指摘し、無数の潜在的な侵入ポイントが存在すると述べました。
Zenityの共同創設者兼CEOであるベン・カリガー氏は、Zenityの研究が現在のセキュリティアプローチがエージェントの実際の運用方法には適していないことを明確に示しており、組織はそのアプローチを変え、これらのエージェントの活動を制御および監視するための専用のソリューションを求めるべきだと強調しました。
Zenityは2021年にベン・カリガー氏とミハイル・バーゴリ氏によって設立され、現在は世界中で約110人を雇用しており、そのうち70人はテルアビブのオフィスで働いています。顧客にはFortune 100企業やFortune 5企業も含まれています。
⸻
この記事で言及されている**「ゼロクリック脆弱性」**に対する具体的な対策については、以下のポイントが挙げられます：
• OpenAIやMicrosoftのような企業は、脆弱性が報告されるとすぐにパッチをリリースしました。これにより、セキュリティ問題は修正されました。ですので、システムやアプリケーションの定期的な更新とパッチの適用が最も基本的で重要な対策です。
• Zenityの研究者は、AIエージェントがユーザーの代わりにフォルダを開いたり、ファイルを送信したりするような動きをする現在のセキュリティアプローチには限界があると指摘しています。そのため、AIエージェントの活動を常に監視し、異常な動きを検出するシステムを導入することが必要です。
3. 多要素認証 (MFA) の導入
•メールアドレスだけでアカウントを操作できる脆弱性が示されているため、**多要素認証 (MFA)**を導入することで、ハッカーが一度侵入してもアクセスを制限することができます。これにより、アカウントの不正アクセスを防ぎやすくなります。
•AIツールやエージェントに与えるアクセス権限は、必要最低限に抑えるべきです。もしエージェントが機密情報にアクセスできる権限を持っている場合、それが攻撃者に悪用されるリスクを高めます。最小権限の原則に基づき、AIがアクセスするデータや機能を制限することが重要です。
•ユーザーに対して、怪しいリンクやファイルを開かないこと、セキュリティに関する意識を高めることが有効です。ゼロクリック攻撃のように、ユーザーが何もしなくても攻撃されることがあるため、定期的なセキュリティトレーニングと啓蒙活動が求められます。
•AIツールやエージェントがどのように動作しているかを監査し、予期しない動作や異常を検出するシステムを導入することが重要です。特に、ファイルやメールを無断で送信したり、ユーザーの意図しない行動を取る場合、その挙動を警告する仕組みを持つことが推奨されます。
• Zenityのようなセキュリティ企業と連携し、最新の脅威に対する検出能力を強化することも有効です。脆弱性を早期に発見し、対応するための専門家のサポートを受けることで、セキュリティレベルを向上させることができます。
• 機密データを暗号化して保護し、万が一攻撃を受けてもバックアップから復旧できる体制を整えることが重要です。これにより、重要な情報が漏洩した場合でも、被害を最小限に抑えることができます。
⸻
総括
ゼロクリック脆弱性は、ユーザーの行動に依存せずに攻撃が可能なため、より強固なセキュリティ対策が求められます。パッチ適用だけでなく、エージェントの監視、アクセス制限、教育など、複合的なアプローチが必要です。これからはAIツールやエージェントが進化し、さらに複雑なセキュリティの問題が発生する可能性があるため、進化したセキュリティ戦略を持つことが不可欠となるでしょう。
ほとんどの多くは採用代行 (RPO; Recruitment Process Outsourcing) ないしは採用コンサル（にセットで付いている RPO） 、もしくは社内の採用チームのリクルーターによってメッセージが送られています。
受け取る側としては「CEO/CTO/VPoE だと思ってレスしたのに、採用担当が返してきた」とネガティブな印象を受けるかもしれません。
転職する側からしたら関係のない話ではありますが、自分たちが丁寧懇切にメッセージを書いてスカウトを送っても返信がないことも多分にあります。
一人当たりのスカウトメッセージを作るだけでも多大な時間がかかる上、会社から見て候補者というのはただ一人ではなく、媒体上には数十人数百人いるわけです。上級役職ともなれば 1 日 8時間打ち合わせがぶち込まれることは、日常茶飯事であり、スカウトメッセージを書く余裕など正直なかったりするかもしれません。
だからこそ、上級役職の方からメッセージ送られてくることに価値を感じてくださる方もいらっしゃるわけですが。
ただ、残念なことに、時間を割いて懇切丁寧にメッセージを書くよりも、ある程度型化されたスカウトメッセージを大量に送るほうが返信率も高く、結果として採用が成功しやすいというデータあるとまで聞きます。
ゆえに、実態としては上級役職者が名前貸しして、スカウトをアウトソースにしてしまっているケースが多いのでしょう。
LLM 筆頭の時代ですから、スカウトメッセージもほとんど自動で作られるようになってきています。もはや魂込めた文章なのか、自動で作られた文章なのか、見分けもつきません。
本質的ではないですが、採用媒体で送られてくるメッセージは、ほとんど RPOであることを前提としたほうがノイズなく企業と接点を持てるかと思います。
私自身も勉強会やイベントでお会いして仲良くなったCTO/VPoE の方から、採用媒体で「はじめまして、◯◯CTO の ☓☓ です」というスカウトをもらうことなんてよくあります。
どこの RPO なんだろう、別の会社のこのスカウトとフォーマット似てるなぁ〜って思いながら楽しく見ていたりします。
一方で、採用担当者名で送ってきてくるほうが、フェアに採用をやりたい（＝名前貸しを好まない）と相手方が考えている場合もあり、候補者観点で私自身は好印象です。
相手がどういう事業ドメインなのか、事業フェーズなのか、自分の技術がどう役に立てそうか、に目を向けたほうが良いのかもしれません。
実際、国内企業だと1000〜1400万円くらいで頭打ちになり、それ以上は経営層になれという感じ。
（もちろん企業によるし経営層でも800もあれば、中間管理職でも2000超えもあるが…）
商社じゃないITエンジニアに限ってもやはり現場に近いマネージャーだとこのあたりが頭打ち。
がっつりCTOとかVPoEに入ると違うが、そもそも頭数の上限が。。。
強いのはやはり外資。現場の兵卒クラスでも2000万超えがあった。でも解雇規制が実質ないし（年収1000万円を超えると解雇規制の判決が渋くなってくるし、2000万円超えはもう事実上フリー）、なによりAIの台頭なのか厳し目になってきた。
少し前のデータエンジニアブーム時代とか、今もだが生成AI系のだと、専門が強ければソルジャーでも1000超えあったのだが、それでも2000は国内では出ない気がする。マネージャーで1500とかか。
見てると、やはり自営業になって専門性で外注請けまくって食べるか、管理職っぽくなるか(だいたいプレイングマネージャーだが)、経営層に入り込むか。
AIブームになってくるので専門性・知名度の価値って実はより高くなる（人間の認知能力は向上してないので著名人の著名さが際立つ。YouTuberとかがwinner takesall なのと同じ）ので、早く知名度を稼いどいたほうがいい。
AIの方がマシ、ってプログラマ、ソフトウェアエンジニア、テックリード、CTOには山のように出会ってるから(いなければ、炎上現場や自縄自縛現場なんて存在しない)、奪われる人はたくさんいそうだが、ソフトウェアエンジニア、プログラマの仕事って、AIでなんとかならない部分も多いから、一般論として奪われるとは言えない。
真偽の程もわからないWebページの単語を断片的に並べて、コピペして、整形するなんて、AIそのものの動きやろ？
お話にならない。
使い物にならない。
「DDDとTDDとクリーンアーキテクチャとマイクロサービス採用して、疎結合に設計してる」
文章にすりゃ100点満点の素晴らしい内容でドヤ顔で自画自賛しているのに、全サービスを起動させないとローカルで開発環境が正常動作しないとか、何か修正が入るたびにそのブランチ取り込んでくれとか言う指示が飛んでローカルの勝つ環境がぶっ壊れるとか、どう考えても矛盾している状態なのがおかしいとか、これっぽっちも思わないとか。
そんな、AIの方がマシってプログラマ、ソフトウェアエンジニア、テックリード、CTOには山のように出会ってるんだよ。
で、その話をすると「そんな現場あるんですねー」って大笑いするその現場が、そういう現場なんだよ。
言っとくけどね。
オイラ、その話して呆れてるんだよ。
昼メシのUber EatsつつきながらSlack眺めてたら、非公開チャンネルに不穏ワードが爆誕してて笑った。
いや、笑えんわ。いよいよ “アクセに身売り” の噂、ほぼ確だって？
──は？ はぁ!? こちとら週イチLTで「世界ぶっ壊す！」って雄叫びあげてる最強ベンチャー様だぞ？
週末はReact＋Next.jsで自社プロダクトを夜な夜な爆速リリース、PRは秒でセルフマージ。
朝会は “OKR？知らん！” のテンションで「とりまKPIは宇宙！」とか言っときゃ許される──それがカルチャーだった。
なのに今日、CTOがAll-Handsで「合流シナジー」とかカタカナ並べ始めた瞬間、チームのZoomが凍りついた。
カメラ越しでも分かる、あの “終わった”空気。マイク切ってDiscord裏窓で叫ぶしかなかったわ。
ポモドーロが爆散した。
達成度は「クォータリー360レビュー」でランク付け？ 何それ、ブラック魔導書？
──はぁ？ 技術書1冊で超えるんだけど？ 草。枯れるわ。
オフィスだって、“カフェスペース”に鎮座してたレゴ・デロリアン撤去だと？
あのレゴが何百万の調達ミスを救ったか、シニア層は知らねぇんだよな。
Slackの新人チャンネルでは、案の定「これでもポジティブに行きましょ！」とか空元気のスタンプが飛び交ってる。
悪いけど無理ゲー。
そこに“PMOガバナンス”をねじ込むとか、自分のGitの履歴に「Fix governancebreach」ってコミット残す罰ゲームかよ。
夜、恒例の“深夜メトリクス祭り”でGrafana眺めながら、ふと思った。
でもそれ、オレたちが「自由にぶっ壊せる」から叩き出せた数字だ。
明日からアクセ式チェックリストで “承認フロー: 7-Step” とかついたら？
ま、とりあえず社外公開してないOSS支援botのトークンだけは今夜中にrevokeしとく。
次に会議室で名刺交換するころには、名刺のロゴが白黒の世界支配企業になってるかもしれんしな。
でも──絶対忘れんなよ。
“自由はForkできる”。
巨大コンサルのバグに巻き込まれても、オレのGitHubアカウントだけは、スタートアップ魂フルコミットでPushし続ける。
