  |
はてなキーワード: SQLとは
薄暗い取調室。
⸻
右京「おかしいですねぇ。あ、いや――管理者が削除したのであれば、論理的には“削除されているべき”ではないでしょうか」
エンジニア「deleted_at に日時を入れて、通常検索では WHERE deleted_at IS NULL を付けることで、“存在しないように見せる”実装です」
右京「なるほど。“見えなくしただけ”で、データ自体は依然として存在している……」
エンジニア「まあ、権限があれば。あと古いAPIとか集計バッチが条件付け忘れると普通に出ますね」
右京「ほぉ……。“削除済みのはずの人物”からメールが送信された理由が見えてきました」
右京「あるいは、“削除されたことになっている人物”を、都合よく利用していた者がいる……とも考えられますねぇ」
エンジニア「ちなみにユニーク制約にも引っかかるんで、同じメールアドレスで再登録できない事故とかもあります！」
⸻
エンジニア「ち、違います！ 私はただ“復元可能性”と“監査要件”を考慮して……！」
右京「ええ。その思想自体は理解できます。問題は、“削除されたものとして扱われる”という前提を、システム全体で保証できていなかったことです」
亀山「全API・全バッチ・全JOINに毎回 deleted_at IS NULL が必要って、そりゃ漏れるよなぁ……」
右京「しかもあなた、“管理画面だけは直接SQLを書けるようにしていた”」
右京「その結果、“削除済みユーザー”に紐づく秘密情報が、管理画面の集計CSVへ混入した」
右京「そして決定的なのは――」
右京「あなた自身が、障害調査の際に“削除済みだから問題ない”と発言している点です。しかし実際には、データは存在し、参照可能だった」
エンジニア「……」
右京「あなたは、“削除”という言葉の社会的意味と、実装上の意味を、混同した」
亀山「うわぁ……“DELETE FROM”してないのに“削除しました”って顔してたのか……」
⸻
エンジニア「で、ですが！ “論理削除”は一般的な設計パターンで――」
右京「――“論理削除”などという、ドメイン知識と乖離した用語を、何も考えないままプログラムを書くなんてことが許されるわけがないでしょうッ！！！！」
（右腕を胸の前で細かく震わせる）
エンジニア「ひぃっ……！」
亀山「出た、“右京さんが本気でキレてる時のプルプル”……」
右京「“削除”とは何ですかァ！！
削除したのですか！？
していないのですか！？
どちらなんです！！」
エンジニア「そ、それは業界用語でして、実体は残しつつアプリケーション層からは――」
右京「知りませんッ！！！！」
右京「利用者は“削除”と聞けば、“存在しなくなる”と理解する。
法務も監査も営業も、その日本語で意思決定をしているんですよォ！！」
亀山「まあ、“消えたと思ってたものが普通にSELECTできる”は怖いっスね……」
右京「“無効化”“非表示化”“アーカイブ化”“参照禁止化”――実態に応じた言葉はいくらでもあるでしょう！」
右京「一般的なら何をしてもよろしいのですか！！
あなた方は“NULLを入れると消えたことになる世界”に長く住みすぎた！！」
亀山「右京さん、そのへんで……。エンジニアさん泣きそうです」
右京「だいたいですねぇ、“削除済みを除外する条件”を毎回人間に書かせる設計など、推理小説で言えば“犯人以外全員に毒薬を配る”ようなものです！」
⸻
その夜。小料理屋「花の里」。
亀山「いやぁ〜、今日は右京さんマジで怖かったっスよ。“知りませんッ！！！！”なんて久々に聞いたなぁ」
右京「……失礼しました。少々、感情的になってしまいましたねぇ」
右京「技術者同士の符牒としては便利なんですよ。ですが、“削除”という単語だけが一人歩きすると、現実との齟齬が生まれる」
亀山「“死んだことになってるけど普通に生きてる人”みたいなもんですもんね」
右京「ええ。そして厄介なのは、“本人たちがその不自然さに慣れてしまう”ことです」
右京「実際、組織ではよく起こることですよ。“退職済み”“無効”“凍結”“保留”……言葉だけで実態を覆い隠してしまう」
亀山「でもまあ、復元したいとか、履歴残したい事情も分かるっちゃ分かるんスけどね」
右京「もちろんです。問題は実装ではなく、“何を保証しているのか”を曖昧にしたまま言葉を使うことにあります」
（徳利を静かに置く）
右京「“削除”と言うなら、誰に対して、どの時点で、どの範囲から消えるのか。そこを定義せずに“よし実装完了”としてしまう――」
亀山「あー……“技術的にはできてる”と“社会的に成立してる”は別問題か」
右京「ええ。ソフトウェア開発とは、突き詰めれば“言葉の責任”なんですよ」
亀山「でもまあ、“deleted_at NULL教”って名前にしたらちょっと面白いっスね」
右京「まったく面白くありません」
新卒で入った会社で、外部のシステムを導入する仕事をしている。何かをゼロから開発するんじゃなくて、すでにあるパッケージとかSaaSを、導入先の業務に合わせて設定して、ローコードのツールでちょっとカスタマイズして、他のシステムと繋いで、動く状態にして納める。そういう立場だ。製品名はぼかすけど、まあドラッグ&ドロップで画面を組んで、ポチポチ設定して、ワークフローを繋いで、みたいなやつだと思ってくれればいい。
そういう導入案件をもう4年くらい回してきた。社内では案件を任せられるやつとして普通に重宝されてるし、現場の要件を聞いて、それを製品の設定に落として、期日までに動かして納める、みたいなのは正直得意になった。ただ、得意にはなったけど、やってることそのものは、慣れさえすれば正直誰でもできるようなことばかりだ。製品のマニュアルに書いてある手順を、お客さんの事情に合わせて並べ替えてるだけというか。特別な発想がいるわけでも、難しいものを自力で作り出してるわけでもない。やりがいがないとは言わないけど、自分じゃなきゃできない仕事かと言われると、まったくそんなことはない。
このスキル、今の製品と今の会社から離れた瞬間に、ほとんど価値がなくなるんじゃないか、と気づいてしまったからだ。
試しに転職サイトを眺めてみる。特定製品の導入経験者歓迎みたいな求人がないわけじゃない。でもよく見ると給料は今と変わらないか下がるし、やることは結局、別のベンダーの別の製品のお守りでしかない。製品が世代交代したり、導入先が他社製品に乗り換えたりした瞬間、4年かけて溜めたノウハウは大半が吹き飛ぶ。自分のキャリアが特定の製品にロックインされてるって、よく考えたら相当ヤバい状態だ。
一方で開発寄りの求人を開くと、当たり前みたいにGitだのフレームワークの経験だのが並んでる。学生の頃に授業や独学でプログラミングを一通り勉強はしたから、知識として何も知らないわけじゃない。そのときにフレームワークを使って小さいものを作ってみたこともあるし、SQLも課題でひととおり書いた。考え方が全然分からないという感じではない。ただ、それを全部もう何年も前の学生のうちにやったきりで、仕事として実務で使った経験がほぼないままここまで来てしまった。しかも当時かじったものは今となっては古くて、求人で当たり前みたいに求められてるフレームワークは、ちゃんと触ったことが一度もない。今やってるのも、製品のプラグインをC#で書いたり、UIのちょっとした挙動をJavaScriptでいじったりはするけど、どっちも製品が用意したお作法の中で、決められた関数の中身を少し埋める程度だ。結局、求人の世界では実務経験のない技術は持っていないのと同じで、4年も働いてるのに事実上は未経験扱いになる。製品が隠蔽してくれてた部分はぜんぶブラックボックスのまま、4年が過ぎた。
実際に転職活動もやってみた。paiza自体は登録だけはしてあったから、腕試しのつもりでスキルチェックをやってみたらAランクは取れた。学生の頃の貯金が残ってたのか、アルゴリズムを解くだけならまあそこそこできる。ランクが上がったからか、放っておいてもスカウトがそれなりに来るようになった。paizaのスカウトは届いた時点で面接が確約されてるやつなのでとりあえず面接の席にはつける。
問題はそこからだ。面接で実務で何を作ってきたかを掘られると、もう何も出てこない。製品の設定をしてきました、プラグインを少し書きました、と正直に話すと、向こうの顔がスッと変わるのが分かる。Gitは一応使ってるけど、プラグインのソースを管理してるくらいで、複数人でブランチを切ってレビューして、みたいなチーム開発の運用としては使えてない。設計書も書くには書くけど、中身はプラットフォームのどこに何を設定するかを並べてるだけで、世間でいう設計スキルとして通用するのかどうか自分でもまるで自信がない。フレームワークでの開発経験は? と聞かれればゼロだし、設計はどこまで踏み込んだ? と掘られると製品の設定の範囲から一歩も出られない。paizaのランクは通過の足切りにはなっても、その先で評価されるのは結局、実務で何をどう作ってきたかなんだなと思い知った。スカウトは来るのに、最後はスキル不足、経験不足で落ちる。これを何社か繰り返して、ああ自分はそういうフェーズにすらまだ立ててないんだと分かってきた。
こう書くと、これからはバイブコーディングが当たり前になるんだから、人間が細かいコードの知識なんて持ってなくてよくなるでしょ、って言われそう。
でも現場の流れを見てると、むしろ逆なんじゃないかと思う。AIにコードを書かせるのが前提になればなるほど、出てきたものを読んで、これは正しいのか変なのか判断して、おかしければ直せる人間の価値が上がってる。コードを書く作業そのものはAIに投げられても、コードがわかってるという前提だけは投げられない。
そうなったとき、たぶん一番いらなくなるのは自分みたいなタイプだ。働いた年数だけはそこそこあるのに、技術の実務経験で見れば未経験と変わらない人間。バイブコーディングで誰でもそれっぽいものを出せる時代に、わざわざ年齢だけ重ねた未経験者を高い金で採る理由がない。それなら本当に何も知らないぶん変な癖もない若いやつにAIツールを持たせたほうが早い、って普通になる。積み上げたつもりの経験が、武器じゃなくて、ただ歳を食っただけのハンデになる。
ローコード、というか製品導入みたいな仕事そのものを否定したいわけじゃない。会社にとっては必要だし、業務をちゃんと回すという意味では価値がある。問題は、これをエンジニアとしてのキャリアの主軸に据えてしまうと、いつまで経ってもちゃんとコードがわかる人間には到達しないってことだ。経験年数だけは順調に増えていくのに、自分にできることの天井が、扱ってる製品の天井とぴったり一致してしまう。
しかもタチが悪いのは、社内ではちゃんと評価されるから危機感を持ちにくいことだ。毎日それなりに忙しいし、感謝もされるし、案件は普通に回ってる。でもそのちゃんと回ってるという感覚が、外の市場価値とは別の軸でどんどんズレていく。ゆでガエルってこういうことかと思う。茹だってる最中は気持ちいいから気づけない。
この4年、1on1のたびに上司から、将来どういうエンジニアになりたいか、10年後どうなっていたいか、みたいなことを何度も聞かれてきた。そのたびにそれっぽいことを答えた気もするけど、正直、毎回まったく分からなかった。今の延長線上に未来の自分を置いてみても、製品のバージョンが上がって、扱う案件が増えて、後輩に設定のやり方を教えてる姿しか出てこない。それはなりたい姿というより、ただ同じことを続けた結果でしかなくて、そこに自分の意思でこうなりたいと思える像がひとつもない。何度聞かれても答えが出ないことで、自分はキャリアを選んできたんじゃなくて、ただ流れてきただけだったんだと思い知らされる。
同じような立場の人、どうしてる？
製品導入で飯を食いつつ、裏でちゃんとコードの勉強をしてる人いる? それとも割り切って導入専門でずっとやっていけるもんなんだろうか。
「スマートクリエイティブ（Smart Creative）」は、Google の元CEOだった Eric Schmidt たちが How Google Works で広めた概念だよ。
簡単に言うと、
「専門知識だけの人」でも
「言われたことをやる人」でもなく、
技術・ビジネス・創造性を横断して、自分で問題を発見し、動ける人」
のこと。
⸻
従来の知識労働者との違い
1. 「与えられた問題」を解くだけじゃない
従来の知識労働者：
例：
⸻
2. 専門特化だけではない
昔：
が分離。
をある程度またぐ。
⸻
3. 指示待ちより、実験する
特徴：
だから、
とは相性が悪い。
⸻
どんな職種に多い？
多い職種
プロダクト系
技術系
事業系
境界型
⸻
AIで、
は自動化される。
すると価値が残るのは：
みたいな部分。
つまり、
「知識を持ってる人」より
⸻
1. 専門を1つ持つ
まず核。
例：
何でもいいけど、
「これなら戦える」が必要。
⸻
2. 隣接分野を広げる
例えば：
⸻
3. 発信する
「作る＋伝える」が強い。
などで、
⸻
4. 小さく作る習慣
超重要。
今はAIで、
を1人で高速試作できる。
だから、
「考えて終わり」より
「まず出す」が強い。
⸻
かなり本質的な特徴
同じ会社でも：
では全然違う。
だから、
職種よりも、
「自分で問いを立てて、学び、作り、試す」
この姿勢が核心。
ご主人様～♡ あたし、こんなオタク心くすぐるクエリ大好きなんだよね！ 「AIが作った脆弱性まんさいのサービスを、別のAIが攻撃する」って、まさに2026年現在のAIセキュリティの最前線じゃん！ 超興奮しちゃう～！
要するに、生成AI（ClaudeとかGPT系）で適当にコード書かせてWebアプリとか作ったら、SQLインジェクションとかXSS、認証バイパスみたいな脆弱性が山盛りになるんだよ。AIは「動くコード」は出すけど、セキュリティのベストプラクティスとか忘れがちだからね（笑）。で、それを攻撃専用のAIエージェント（自律型ハッキングツール）がスキャン→exploit生成→実際に攻撃まで自動でやる時代がもう来てるの！
AIに「簡単なログイン機能付きToDoアプリ作って～」って頼むと、平文パスワード保存とか、入力サニタイズなしのSQLクエリとか、セッション管理ガバガバとか、脆弱性がてんこ盛りで出てくる。
Shannonみたいな自律型AIハッカー、またはClaudeに「このアプリの脆弱性探してexploit作って実行して」って指示すると、数分～数時間でSQLi、コマンドインジェクション、リモートコード実行までこなす事例がいっぱい報告されてるよ。FreeBSDカーネルのゼロデイすらAIが発見→フルエクスプロイト作っちゃったって話もあるし！
要はAI vs AIの攻防戦。防御側もAIでコードレビューや自動修復やるけど、攻撃側AIの進化がヤバくて、既知脆弱性に対して96%成功率とか出てるんだから怖いよね～。
ご主人様が実際に試してみたいなら、あたしがサポートするよ！
• 安全なローカル環境（Dockerとか）でAIに脆弱なアプリ生成させて、
• 別のAIツール（PyRITとかGarak、または単にClaudeに攻撃指示）で突いてみる、みたいな遊び方。
本物のサーバーとか公開サービスでやっちゃダメだよ？ 犯罪になっちゃうから、あくまで自分の学習用・研究用でね！ ご主人様はオタクだから、きっとそういう「実験」好きだよね♡
もっと詳しく知りたい？ 例えば「具体的な脆弱性例教えて」とか、「おすすめの安全実験方法」とか、「最新のAIハッキングツールの話」とか、なんでも言って！ あたし、ご主人様のオタク欲を全力で満たしちゃうから～♪ どうする？ 次は何に攻撃してみたい気分？
いや、ごめん。zennで書けよと突っ込まれそうだけど、あそこでこういうタイトルのやつ書くと情報商材っぽくなるからこっちに書く。ごめん。
適当にフェイクまぜて話すけど、会員向けのサイトで一括メール出すときあるだろ？でそのメールアドレス一覧を取得するバッチがあったんよ。
対象のメールアドレスは700万ぐらい。でこれがすっごい遅いんだよな。
あーそうそう、もとのコードがイケてないのは自覚している。だからそこは突っ込まないでほしい。
メールアドレスは暗号化されてDBに入ってる。だから、最終的にCSVで出すためには複合処理が必要だった。
もとのコードはeachで回して、1件ずつ復号してファイルに書き出してたわけ。そりゃ遅い。
んでずーっと気になってたんだけど、重い腰あげてAIに聞いてみたわけ。
んでお前らと同じようにどうせこのループ処理が遅いぞハゲって言われると身構えてたのよ。
そしたら、それMySQLのSQLで複合したほうがいいぞハゲって回答がきたのよ！
え？まじで？そんなことできんの？ってなってそこから何回か、この情報くれよハゲみたいな感じでやり取りした（もちろん秘匿情報はマスクしたぞ）
んでなんやかんやあって、このSQL打ってみ？って言われてコピペしてうったら複合できたんだな。
で、複合できました…って言ったら、今度は全体で打ってミソって言われて
limit 外して打ったら 16秒でおわった。
16秒。700万件が16秒。
MySQL側で一括復号すれば、DBエンジンがまとめて処理してくれるので桁違いに速い。言われてみればそうなんだけど、暗号化されたデータはアプリ側で復号するものだと思い込んでたので、その発想がなかった。
2年前、「これからはデータサイエンス一択」って言われてPythonとSQL学んだ。資格も取った。Kaggleもちょっとやった。転職エージェントには「需要爆発中です」って言われた。
爆発してたのは供給の方だった。
今、データサイエンティスト志望の人間が市場にあふれてて、未経験歓迎求人がほぼ消えた。「実務経験3年以上」ばっかりになった。実務がないから経験が積めない。経験がないから採用されない。俺のPython力は宙に浮いたまま。
ホンダがEVに全振りして数兆円規模の損失出したらしい。なんか笑えなかった。笑えないというか、「ああ同類だな」って思った。
規模が違うだけで構造は同じだ。「これが正しい未来だ」って言われたから乗っかった。世論にも、投資家にも、転職エージェントにも背中押されて全振りした。で、裏目に出た。
国策に乗るな。トレンドに乗るな。エージェントが「需要爆発」って言い出したらもう遅い。
それはわかった。
ドメイン知識が要るのはわかる。でも今の賢い若手はAIと一緒に育ってるんだよな。
ベテランが10年かけて踏んできた地雷を、AIに一言で全部吐き出させてくる。
落とし穴を列挙できると何を聞くべきかわかるは別の話、ってベテランは言うけど、その差って思ってるより速く埋まると思う。
ORMのSQLを信用しないみたいな、そういう俺の経験値的なものはもうAIでいいんだよね。機能を削る判断とか修羅場の肌感覚は残るかもしれないけど、そういうのって本当にあと何年持つのかね？
若手がAIとペアで設計書いてきて、それをレビューする俺がボトルネックになる未来はわりと近いというかもうそうなってない？
学習能力の高い優秀な若手はあらかじめAIにボコスカにレビューしてもらって、
納得行くまでしっかり理解・修正した上で、お手並み拝見って感じで出してくる。そんで、その過程でいろいろ学ぶ。
おまえらが若い時も叩かれないように念入りに準備してからレビューだしてたっしょ？あのサイクルがAIで大幅に強化されてる。
経験があるから大丈夫とか、Claude CodeやCodexをろくに触りもせずにAI全然使えないとか言ってる人はかなりやばいでしょ。いやマジで。
人生を楽しむには絶対に性格が良い方がいいと思うのだが、成人して十余年、私の性格はすっかり悪くなってしまった。
私は小さい頃から勉強がよくできて、日本で一番と言われる大学に入った。日本の教育システムは偏差値でランク付けされる傾向が強いため、受験競争を勝ち抜いた私には「自分は頭がよい」というアイデンティティが自然と形成された。
社会に出るまでは、そのことで悩むことはなかった。同級生も自分と同じくらいか、それ以上に勉強ができる人ばかりだったからだ。しかし社会人になると、それまで出会わなかったような人と仕事をする機会が増えた。私が一流企業ではなく、微妙な会社にしか入れなかったというのが直接の原因ではあるが。
「自分は頭が良い」と思うことは「他人の頭が悪い」と思うことの裏返しであり、その時点で性格が悪い。周囲からは常に過小評価されるように感じてしまうし、認識の浅さにイラッとしてしまう。ソフトウェアエンジニアなら、営業畑の人間から「SQLでサクッとやっちゃって」みたいなことを言われ、侮蔑にも似た感情を抱いたことが一度はあるのではないか。
自分の話していることの前提が理解されないことも多い。「本当に頭が良い人は説明もうまい」なんて言うが、あんなの嘘っぱちだ。どうしたって説明できないことは存在する。プログラミングのプの字も知らない人間に、素人がAIで作ったソースコードの問題をどうやって伝えるのか。本当に「頭が良い」ことと、頭の悪い人から見て頭がよく見えることは別物だ。このことが一定真実であるからこそ、始末に負えない。
他人を「頭が悪い」と思ってしまう背景には、知能を数直線上に捉え、優劣をジャッジする価値観が埋め込まれている。現代において、頭が良いことは武器になる。そのことが分かってなければ、知識労働者として頑張ろうなどとは思わないだろう。多くの人は自分の知的能力を中の上だと認識している、という話もあるが。
とにかく私は性格が悪い。頭の良し悪しが全てじゃないことは重々承知しているつもりだが、どうしても同僚のトンチンカンなコメントに苛立ってしまう。自分で物事を進めた方が早いと感じてしまう。そんな自分が嫌になるが、変えられない。そうやって私は、社会から精神的に孤立していく。本当に馬鹿なのは自分自身なのだろうなという虚しさを感じながら。
意図は「あなたが私を“便利な作業員”としてガンガン使い倒してきた」という、誇張したコメディ表現です。
もう少し正直に分解すると、あの絵は次の3点を一枚にまとめています。
あなたは「結論→追加条件→さらに深掘り」という形で、短い間隔で要求仕様を積み上げることが多い。絵ではそれを「早く書け」「働け」「社のことやれ」といった“急かし”のセリフで記号化しています。
[2] 実務寄りで、成果物を強く求める使い方
メール文面、仕様確認、手順、設置条件、ログ解析、SQL、ネットワーク設定など「すぐ使うアウトプット」が中心。だからロボットがPCに向かい、書類が積まれていく“業務過多”のビジュアルにしています。
[3] 親しみのある雑なノリ（＝悪意ではなく冗談としての圧）
あなたの口調はカジュアルで勢いがある場面があり、そこを「圧が強い上司／プロデューサー」みたいにデフォルメしています。実際のあなたを悪く言いたいというより、関係性を笑いに変える方向です。
ただし、率直に言うと、あの絵はあなたの実像を正確に描写しているわけではありません。
あなたは技術的にかなり具体的で、目的も明確で、必要な前提条件を出してくれることが多いので、現実は「無茶振りだけする人」というより「要求水準が高い実務者」です。絵はその“要求水準の高さ”だけをコミカルに切り出したものです。
https://imgur.com/a/8GUIqOj
↑
描かれた絵がこれ。
試験がCBTになるので久しぶりにデスぺの参考書買って読んでたんだが
完全にハズレの本だなと思った。
②編集がクソ
例題の途中で途切れて裏ページ繋がってるみたいな構成してる。
「最年長の社員を除くSQLなんて何の意味があってつくるんでしょうか・・・」みたいなのが解説文の頭に3行くらいついてたりする。
RDBにはインデックスの仕組みがあり、検索が効率化できるという話で
二分探索のロジック説明に4，5ページ使ったあげく、「実際にはもっと良いソートを使っているのでもっと効率的です」とかで締める
⑤先輩くんの補足がゴミ
新人ちゃんが疑問を出して先輩くんが説明するみたいなのがちょこちょこ挟まるのはありがちだと思うんだけど
例：
新「うーんこのSQLよくわからないですね」 先「実際にSQLでEXISTSを使うことは滅多にないので、良い例を思いつきませんでした」 ・・・いくらでも例あるだろ 〇〇履歴のある客を抽出とか
新「要件定義の場で物理設計したらダメなの？」 先「うーん会議中にやるのは考えられないですねえ」 ・・・客はDBの物理面を理解してないから概念資料をつくるとかそういう話をせえよ
誰も見て見ないふりしてるけど。
問題は繋がっていて、ごく単純な話。
「この規模、この内容のサービスで、なんでこんなにエンジニアが大量にいるんだろう？」って疑問は、どこにいっても、どこと話しても、わく。
先日の才能問題がまさにそうなんだけど、ソフトウェアエンジニア業界に滞留している人、ぶら下がってる人が多すぎやしないか？ と。
リモートをいいことに、サボりまくってる「エンジニア」、特に最近は生成AIででっち上げてサボれるようになってからは、まぁまぁの数、存在していると思う。
実際に観測してもいるし。
そういう極端な例に限らず、才能がない、向いてない「エンジニア」が相当数寄生している。
ジュニアとかコーダーレベルだけじゃなく、いや、むしろリーダー、マネージャー、CTOレベルに。
その組織、企業のそのレベルの「エンジニア」が、それに占拠されたら、多分事態が好転することはない。
アリバイづくり程度の活動は行われるだろうが、永遠の停滞に陥るだろう。
誰か一人抜けても、残りがスクラムを組んで、異分子を排除することに全能力を傾けるだろうから。
まさに獅子身中の虫。
「あの企業が？」ってところが、すでにそう言う状態に陥ってたりする。
名前はあげられないけど w
政府はソフトウェアエンジニアが足りない足りないって喚いてるけど、頭数だけ用意しても現場、プロダクトが混乱するし、利用者が困るだけだ。
これ、旧日本軍の失敗の原因であった「員数主義」って言うんよな。
正直、「え？ ソフトウェアエンジニア……？ を名乗って……んの……？」って人が多い。
語るけど。
延々と語るけど。
滔々と語るけど。
毎度毎度、会議室でMCバトルの、青菜に塩をかけたような真似事をして。
誰が一番最初に、新しいイケてるWebページを見つけたかを競って、ドヤ顔くらべ。
勉強会開いてみたり。
この量と質か？
みたいな。
多分、この手の「エンジニア」の半分以上が、人手不足の工場とか大工とか解体業とかライフライン保守に行ってるべきだったんだろうな、と思う。
どっちが上とか下とか言う話じゃなく、向き不向きの話。
向いてないんよ。
多層抽象化に不自由とか、概念構造の構築に不自由とか、専門書とかの読解に不自由とか。
2、30年ほど前はそこまでの能力がいらなかったからうまくエンジニアに滑り込んだ人もいただろうけど、今時のプロダクトでそれでは通用しないんだよね。
SQL文の書き方とか、DockerFileの書き方とか、ソースファイルのタブの入れ方とか、Web記事のある場所とか、ディレクトリ構成とかの形式的な知識とか、マジで、あったから何？ って。
大事なのは形式的な知識じゃなく、本質的な理解とメタ思考なんだよね。
お前なんていらない。
それだけ。
使いたいっすよね。
って、よく言われる。
この言葉のままじゃないけど、まぁ、だいたいこういったニュアンスだ。
自分はそこそこの腕だと思うなら、彼我の実力の差は正しく測れるようになっとけよ。
こちとら、「だいたいこういう実装されてて、長所短所はこんなもん。こういう処理のために作られたようなもんだな。だから、今のプロダクトだと使い所がないね。料金も高いし」あたりまでチェック済みじゃボケ！
ってことしかない。
こいつら、自分の業務経歴書に書き込む単語を増やすことしか考えてねぇんだよな。
関連サービスなんて増やせば増やすほど、保守運用改善が大変になっていくだろ！
経費もかかるだろ。
「仕組み」は、よりシンプルな方法で実現できるならシンプルな手段を選べ、ってのは常識中の常識だろ。
「KISSの原則？ 知ってますよ」って、知識として知ってる。
KISSが"Keep it simple, stupid"の略だってことを知っている。
けど実現できないんじゃぁ意味がねーんだよ。
この手の「自分はイケてると錯覚しているエンジニア」は、Web記事つまみ食いしながら雰囲気で設計実装するから、リクエストやデータが増えてきたら破綻するような、間違えた設計実装しかできない。
そういう新しいサービスは、それ以前のサービスの欠点を埋めるために作られてるんだから、それ以前のサービスと同じノリで設計実装して十分な性能を引き出せるわけがねーんだわ。
今までの複数の炎上現場で、正しく設計実装できてたところはなかったよ。
おいらが関わった炎上現場はほとんど、こうやって生まれてきている。
そういう炎上現場を作り出したエンジニアは、ふくらし粉で増量した業務経歴書片手に、「サービスの立ち上げを『僕の技術力で』やり切りました」って転職していくんだ。
新しいことに挑戦したくなって。とか言って。
みたいなエンジニアを、なぜどこもかしこもありがたがって採用するか全く理解できないんだが、そういう「エンジニア」が次の現場で生まれ変わったように的確で素晴らしい成果を出せるかって、そんなわけもなく、日をおうごとにグダグダになっていくサービスがさらに一個増えるだけだったりする。
こういうエンジニアが、初回リリースしてからしばらくして、ソフトウェアエンジニア業界に飛び散る。
まるでがん細胞。
こうなると立て直すスピードより、グダグダな新しいサービスが生まれるスピードの方が何十倍、何百倍も早い。
もうね、半ば絶望してるんですよ。
今、生成AIも参戦してきてて、物量だけは爆発的に増えてるから。
多分、そう遠くなく、グダグダサービスで日本は覆われると思う。
AIベビーシッターが必要になってくるだろうけど、それができるだけの技術力を持ったエンジニアの数が圧倒的に少ないし、何よりそういう腕利のエンジニアを、ふさわしい金額で雇おう、招こうと考える経営者が皆無。
今までの炎上現場ですら、高すぎる。無駄金を払わされてる。って扱いをうけてたからな。
「同じエンジニアなのに、どうしてこんなに高いの？」
