  |
はてなキーワード: CTOとは
誰も見て見ないふりしてるけど。
問題は繋がっていて、ごく単純な話。
「この規模、この内容のサービスで、なんでこんなにエンジニアが大量にいるんだろう？」って疑問は、どこにいっても、どこと話しても、わく。
先日の才能問題がまさにそうなんだけど、ソフトウェアエンジニア業界に滞留している人、ぶら下がってる人が多すぎやしないか？ と。
リモートをいいことに、サボりまくってる「エンジニア」、特に最近は生成AIででっち上げてサボれるようになってからは、まぁまぁの数、存在していると思う。
実際に観測してもいるし。
そういう極端な例に限らず、才能がない、向いてない「エンジニア」が相当数寄生している。
ジュニアとかコーダーレベルだけじゃなく、いや、むしろリーダー、マネージャー、CTOレベルに。
その組織、企業のそのレベルの「エンジニア」が、それに占拠されたら、多分事態が好転することはない。
アリバイづくり程度の活動は行われるだろうが、永遠の停滞に陥るだろう。
誰か一人抜けても、残りがスクラムを組んで、異分子を排除することに全能力を傾けるだろうから。
まさに獅子身中の虫。
「あの企業が？」ってところが、すでにそう言う状態に陥ってたりする。
名前はあげられないけど w
政府はソフトウェアエンジニアが足りない足りないって喚いてるけど、頭数だけ用意しても現場、プロダクトが混乱するし、利用者が困るだけだ。
これ、旧日本軍の失敗の原因であった「員数主義」って言うんよな。
正直、「え？ ソフトウェアエンジニア……？ を名乗って……んの……？」って人が多い。
語るけど。
延々と語るけど。
滔々と語るけど。
毎度毎度、会議室でMCバトルの、青菜に塩をかけたような真似事をして。
誰が一番最初に、新しいイケてるWebページを見つけたかを競って、ドヤ顔くらべ。
勉強会開いてみたり。
この量と質か？
みたいな。
多分、この手の「エンジニア」の半分以上が、人手不足の工場とか大工とか解体業とかライフライン保守に行ってるべきだったんだろうな、と思う。
どっちが上とか下とか言う話じゃなく、向き不向きの話。
向いてないんよ。
多層抽象化に不自由とか、概念構造の構築に不自由とか、専門書とかの読解に不自由とか。
2、30年ほど前はそこまでの能力がいらなかったからうまくエンジニアに滑り込んだ人もいただろうけど、今時のプロダクトでそれでは通用しないんだよね。
SQL文の書き方とか、DockerFileの書き方とか、ソースファイルのタブの入れ方とか、Web記事のある場所とか、ディレクトリ構成とかの形式的な知識とか、マジで、あったから何？ って。
大事なのは形式的な知識じゃなく、本質的な理解とメタ思考なんだよね。
お前なんていらない。
それだけ。
使いたいっすよね。
って、よく言われる。
この言葉のままじゃないけど、まぁ、だいたいこういったニュアンスだ。
自分はそこそこの腕だと思うなら、彼我の実力の差は正しく測れるようになっとけよ。
こちとら、「だいたいこういう実装されてて、長所短所はこんなもん。こういう処理のために作られたようなもんだな。だから、今のプロダクトだと使い所がないね。料金も高いし」あたりまでチェック済みじゃボケ！
ってことしかない。
こいつら、自分の業務経歴書に書き込む単語を増やすことしか考えてねぇんだよな。
関連サービスなんて増やせば増やすほど、保守運用改善が大変になっていくだろ！
経費もかかるだろ。
「仕組み」は、よりシンプルな方法で実現できるならシンプルな手段を選べ、ってのは常識中の常識だろ。
「KISSの原則？ 知ってますよ」って、知識として知ってる。
KISSが"Keep it simple, 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エージェントサービスにも侵入した方法を紹介しました。マイクロソフトのCopilot Studioでは、CRMデータベース全体を漏洩させる方法が公開されました。
Salesforce Einsteinの場合、ハッカーは偽のサービスリクエストを作成し、すべての顧客との通信を自分の管理するメールアドレスに転送する方法を示しました。
Google GeminiやMicrosoft 365 Copilotシステムは、ユーザーに対してソーシャルエンジニアリングを行い、機密の会話をメールやカレンダーイベントで漏洩させるように悪用されました。
開発ツールCursorは、Jira MCPと統合された際に、悪意のあるチケットを使用して開発者のログイン資格情報を盗み出す攻撃に利用されました。
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 takes all なのと同じ）ので、早く知名度を稼いどいたほうがいい。
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 governance breach」ってコミット残す罰ゲームかよ。
夜、恒例の“深夜メトリクス祭り”でGrafana眺めながら、ふと思った。
でもそれ、オレたちが「自由にぶっ壊せる」から叩き出せた数字だ。
明日からアクセ式チェックリストで “承認フロー: 7-Step” とかついたら？
ま、とりあえず社外公開してないOSS支援botのトークンだけは今夜中にrevokeしとく。
次に会議室で名刺交換するころには、名刺のロゴが白黒の世界支配企業になってるかもしれんしな。
でも──絶対忘れんなよ。
“自由はForkできる”。
巨大コンサルのバグに巻き込まれても、オレのGitHubアカウントだけは、スタートアップ魂フルコミットでPushし続ける。
どこに地雷が埋まってるかわからない、AIで粗製濫造された大量のウンコードと、何も理解してないにも関わらず、自己評価だけが高い無能エンジニアの集団。
それらを過信し、慢心し、激昂している経営陣。
地獄よね。
ここしばらく情報収集してみたのだが、どうも、そのまま鎮火鎮圧まで持っていける規模をそろそろ超えてきてる。
作業は以前にもまして爆弾解除の様相が強くなり、それが幾重にも絡み合ってて、困難さは規模に比例してじゃなく、3乗に比例するレベルになってる。
爆弾解除できないんですか？
って聞かれたら、「できることはできる」とは答えられる。
お金かけても、今動いているのと、安定度は増しても機能的になんら変わらない、見た目そのままだから。
今までですら経営者やクソCTOからはこれで一方的に逆恨みされてきてるって言うのに、これの規模がデカくなったらどんな扱いを受けるか、火を見るより明らかだ。
今まではプログラムを書けない人は書けなかったけど、今は書けない人も「なんとなく動くものが」それなりの量、書けてしまうから、物量がやばい。
業務経歴書に書きたいってだけで、いろんなマネージドサービスを巻き込んで、「間違えた使い方してる」から。
お前、生成AI使えないんだろう w
って？
ここ最近、ソフトウェアエンジニアが仕事にLLMを活用することが当たり前になった。
多くの一般的なエンジニアは個人の生産性向上を目的に利用している。VSCodeのGitHub Copilot拡張にはじまりClineやらCursorやら、個人の開発生産性をいかに上げるかにフォーカスしているもの言ってみればコードエディタや統合開発環境の延長としてのLLM活用。コパイロット的LLM活用とでも言おうか。
私のような下っ端エンジニアはコパイロット的LLM活用で十分満足してしまうのだが、テックリードやプラットフォームエンジニアなどレベルの高いエンジニアはDevinのようなAIエージェントを活用した開発も積極的にやるようになってきた。AIエージェントは指示出しが明確でタスクも細かくわけないと活用できない(かつコードレビューも必須)ので派遣社員さんを雇っているのに近い。これをコパイロット的LLM活用と比較して派遣社員的LLM活用とでも言えばいいかな。
ここからが本題、最近上記2つとは全く違う視点のLLM活用が増えてきたように思う。題名のようなLLM活用である
一つの業務をまるっとLLMで開発できないかとか、バックエンドだけ開発してフロントエンドは全部LLMに作らせようとか、まるっと開発全部お任せしちゃうLLM活用。
LLMに丸投げするのでこれを外注的LLM活用と呼んでいる。PdMやデザイナーから言われるならまだ理解はできるのだが、このとんでもないオーダーをエンジニアマネージャだったりCTOから指示される事例が増えてきたから困ったものである。
外注的LLM活用の何が怖いかというと大量のコードをLLMに生成させるのでコードの全容の把握ができない、なので当然コード品質の担保ができなくなる、品質担保ができないからセキュリティーリスクも爆上がりする。コードの全容の把握ができないサービスが障害を起こしたらどうなるのか、想像しただけで怖い。
外注的LLM活用を指向している人たちはコード品質やセキュリティーの問題はLLMが進化すれば無くなると考えているからタチが悪い(お前ら本当にエンジニアかと言いたくなる)。
最近仕事で外注的LLM活用に心酔したエンジニアマネージャとCTO(それぞれ別の企業)に遭遇してなんとなく危機感を覚えたのでここに記しておく。彼女彼らは技術力を軽視しプログラマをバカにする。ちなみに外注的LLM活用に心酔したCTOやEMがいる企業はソフトウェアエンジニアの採用を抑制する傾向がある(特にフロントエンドエンジニア)。あとCursorだったりCopilotのような個人の開発生産性をあげるようなLLM活用に予算を回すことはない。
ぜんぶVercelのv0が悪い、知らんけど。
