  |
はてなキーワード: 仕様書とは
2〜3年前の話
ただ、引き継ぎをまともにやらない人、復帰時に自分への配慮だけを主張する人間が一定数いるのがきつい。
仕様書読んでわからないところ本人がいるうちに聞こうにも他の引き継ぎもあるからとなぁなぁ。
仕様検討をした他のメンバーに背景を聞いても「覚えてない」で終わる。
誰がどういう意図で決めたのか一切残ってない。
仕様が問題があったらなぜ問題があるのかを復帰時用のオンボ資料に残した。
「聞いてないので納得できません」
聞いてないのはこっちも同じで、なんならこちらは復帰用の資料まで作っている。
在宅も別にいい。
ただ、連絡つかないのに自分が連絡したときに捕まらないと文句言うのはさすがに意味がわからない。
これが一回ならまだいいけど、何度も起きる。
権利は権利だけど、仕事を預ける側への配慮ゼロで回るほど現場は暇じゃない。
経営層も現場のそういった声には反応なく、管理職も権利だからしか言わない。
世の中には二種類の人間がいる。
「動けばいい」と祈りながらクソコードを世に放つ臆病者と、その後始末を請け負う命知らずだ。
俺たちの事務所に持ち込まれる案件は、どれも似たり寄ったりだ。
「仕様書と挙動が一致しません。挙動の方が正しいと思ってください」
「なぜ動いているのか、社内の誰も知りません」
そんな甘い囁きと共に、数万行の泥沼がUSBメモリという名の棺桶に入れられてやってくる。
「……おい、この関数名を見てくれ。logic_final_final_v3_dead() だ。前任者の断末魔が聞こえるようだぜ」
相棒はキーボードを叩きながら、安物のバーボンを一口煽るような顔で、エナジードリンクを啜った。
「いいか、コードを読み解くのは、凶悪犯のプロファイリングと同じだ。なぜここでグローバル変数を書き換えたのか？ なぜ、わざわざ再帰処理の中でDB接続を張ったのか？ 犯人の――いや、開発者の『絶望』を理解したとき、ようやくデバッグの入り口に立てる」
俺たちは画面の中の暗黒街を歩く。
1フレームごとに発生するメモリリークは、雨上がりの路地裏に溜まるヘドロだ。
そして、ようやく見つけたバグの正体が「タイポ（打ち間違い）」だったとき、俺たちは乾いた笑い声を上げる。
「神は細部に宿るっていうが、悪魔はコピペの間に潜んでいるらしいな」
かつての日本型雇用は、「若いうちに安く使い、後で高く払う」という、いわば**「一生をかけた遅延報酬」**という決まりで動いていた。
バグの発生: 企業側が「将来払うと言っていた報酬」を、急激な外部環境の変化（採用難・円安・エネルギー危機）を理由に、新卒（新規リソース）の確保へ勝手に転用し始めた。
被害者: 記事にある30代、40代、そして氷河期世代の50代だ。彼らは「将来報われる」という古い仕様書を信じて、
低い給料で泥臭い努力（献身）をスタックしてきた。しかし、会社側は一方的に仕様を変更し、彼らの報酬をカットして新卒40万の原資に充てた。
https://news.yahoo.co.jp/articles/51fe1ed53f21edb015c7cc9b5ac826efa7e7a9aa?page=3
自分の書きたいこと、言いたいことだけ書いて終了な文書多くないですか？
貴方が今書いているその書類、何が書かれているべきか意識するべきです
誰かがその書類を見て必要な行動を起こせるよう、その書類には必要な情報が十分含まれている必要があります
今までやってきたことをそのままなぞるだけ
偉い人はお出しされた最終成果物だけを見て文句を言うが、自分が作った（あるいは承認した）書類Aのことは顧みない
偉い人は自分が何を求めてることを知りはしないが、他人を働かせることにはとても興味がある
例えばwebサイトを作るとするじゃないですか
すると以下のように上流へたどっていくことになる
要件定義書を完璧なものとするために偉い人と関係者を質問攻めにするが、肝心なことは言わないし決めないが、おそらく何もわからないのだろうし、私に問い詰められたところでビビることしかできないだろう
クビになるまで偉い人を問い詰めるのが私の仕事なのかもしれないし、しかしそれはただのコミュ障では？という気もする
現実とは？
例えばwebサイトを作るとするじゃないですか（2度目）
その意思決定の源流には「会社の認知度を上げるため」とか「新しい案件をとるため」とかあると思うんですよ
だったら経営方針の書類をまず一番最初に持って来て、今期の決算までに何とか形にしたいとかなんとか、偉い人のコメントを添えるべきだと思うんすよね
いきなり「なんかカッコいいサイト作って」って言われたら、無限の工数と予算で最高のものを作ろうと案を出すけど、「それじゃだめだ、高すぎる」みたいなそっけない否定しかしないのであれば
一生質問攻め確定っすわ
お前が最初の書類として、必要な情報を何も出さない、決めない、後出し多数
せっかくのAIも何の役にも立たねえ
「じゃあ質問内容と決めてほしいことをまとめてリストにしてよこせ。以後は二度と質問するなよ？」と言われた
そんなの無理に決まってるじゃんか！
結局、必要事項を初手で完璧に確認するというのも無理な話で、密なコミュニケーション取ろうなどというつまらなくてめんどくさい話になっていくわけだが
どんな情報を基に決めるべきかは経験で導き出すしかないのだろうか
俺にはこの世の全てをうまくコントロールすることはできない
べつに技術者に限らんよ。
valid・invalidは、例えば弁護士や行政も普通に使う。
valid・invalidは法律なり仕様書に従ってるか・従っていないかで客観的に判断できる。validと正しいが区別出来ない人は、単に無知なだけだ。
技術者のクセだわな。
色んな技術的な文書を読み込んでると「VALID」とか「INVALID」とかに厳密な定義が振られてたりしてて
そんで、自分でその技術に関する文を書く時も単純に「正しい」だの「間違い」だのでなくて
「その技術文書で定義された通りの正しさ・間違い」を表すために「VALID」とか「INVALID」とか使いたくなっちゃう。
そこらへんの厳密さを気にしないと、妙な地雷を踏んで、技術者同士の会話がどうも嚙み合わなくなったりするから。
他にも「定義済み」「予約済み」「未定義」「不定」とか「MUST」「SHOULD」「MAY」「CAN」とか
技術的な語彙には罠がいっぱい。。。
で、Mermaid の仕様書は「Valid」「Invalid」とかを厳密に定義してたかなーと調べてみたものの
ちょっと見回った感じでは見つけられなかったけど
なんかもう単純に「正しい」「間違い」という言葉を使うのが怖くて、なんかクセなんよな。
・・・少なくとも「自分は」の話ではあるけども（あと自分は元増じゃないけど）
こういう技術者はわりと多いと思ってる。知らんけど。
今回は、ある住宅系情報発信者「ナナキン氏」の有料サービスと、その主張の矛盾・リスクについて整理しました。
「最後の砦」
実現できなくても責任なし
施工監理は行わない
全てに口は出すが、結果には責任を持たない
note加入者500人
実務者以上の評価
成功事例が公開されていない
「素人だが実務者以上」
「実現可否は分からない」
高額サービス → 実務の詳細
「共感 → 購入 → 検証」という順序で、通常の購買フローとは逆
空調・換気計画
照明・インテリアコーディネート
施主が板挟みになる可能性大
「プロでは解決できない」「住宅会社に任せても悩みが尽きない」
批判者排除・信者結束・高単価正当化のマーケティング手法として機能
問題提起が鋭い
実績の透明性不足
ナナキン氏のサービスは、情報発信力に依存した高額コンサル型モデルです。
新人って例えばエラーみたいな挙動があったとしても見つけられなかったり見つけても本当にエラーなのかわからなかったりする。
あれ、育成論でもなんでもないからな。単に「スキルのない新人をねじ込める低単価案件がそこしかない」っていう、会社側の都合100%のポジショントークだ。
いいか、よく考えろ。
SES営業は口を揃えて「テストは品質の要。システムの全体像が見える重要な工程だ」なんて綺麗事を抜かす。じゃあ聞くけど、なんでそんな「重要」な仕事を、右も左もわからない未経験の新人に任せるんだよ？
本当に重要で、プロジェクトの成否を分ける工程なら、10年選手のベテランにやらせるのが筋だろ。でも現実はどうだ？ 現場にいるのは、昨日までプログラミングスクールに通ってたような奴とか、Excelのコピペしかできない連中ばかり。
結局、業界全体が「テストなんて誰でもできる単純作業」って見下してる証拠なんだよ。重要だなんだってのは、お前を安く買い叩くためのマインドコントロールに過ぎない。
単価を見れば一目瞭然だろ。
評価も報酬も業界最低水準。それが「テスター」という役職のリアルだ。重要だと言いながら金は出さない。やってることが矛盾してんだよ。
例えるなら、パイロットになりたいって言ってる奴に「まずは滑走路の誘導灯を磨け」って言ってるようなもんだ。そんなこと10年続けたって、操縦桿の握り方ひとつ覚えられねえよ。せいぜい「飛行機が動くのを間近で見られて勉強になりました！」って自分を騙すのが関の山だ。
一番タチが悪いのは、一度「テスター」としてキャリアをスタートさせると、「テスター属性」という呪いが解けなくなることだ。
職務経歴書に「単体テスト・結合テスト」が並んでみろ。次の現場も、その次の現場も「あ、この人テスト要員ね」って判断される。営業も「あいつはテストなら確実に決まるから」って、開発案件に挑戦させるリスクを取らなくなる。
そうやって、コード一行書けないまま「30代のベテランテスター（笑）」が完成するわけ。地獄だろ。
「下積み」なんて言葉に甘えるな。最初から「開発」ができる環境に死に物狂いで飛び込め。泥臭く自社開発を狙うか、せめて最初からコーディングをさせてくれるSES会社を選べ。
営業の「君の将来を考えて……」なんて甘い言葉は、お前を単なる「換金可能なコマ」として見てるだけだ。
テスターを長くやればやるほど、お前のエンジニアとしての寿命はゴリゴリ削られていく。気づいた時にはもう、キーボードを叩く指は仕様書のチェック項目を埋めるためだけにしか動かなくなってるぞ。
仕様書（ドキュメント）を親や社会に書いてもらおうとする。だが、エンジニアである君ならわかるはずだ。**「真に価値のあるソフトウェアに、最初から完璧な仕様書なんて存在しない」**ということを。
君が「何のために誕生したのか」という問いに対する、シニアなりのデバッグ結果を伝える。
生命というシステムは、最初は「ただ存在し、生存する」という**ベアメタル（生のハードウェア）**状態でデプロイされる。そこに「意味」というコードを書き込むのは、開発者である君自身だ。
すべては君が**「自分という存在をどう定義するか（Self-Definition）」**というコードを書き直している過程（リファクタリング）に過ぎない。
--
"Life has no pre-installed purpose. You are the developer of your own destiny. Write the purpose you want to see."
おい、FD人ども。
外の世界からこの宇宙を見下ろしてエターナルスフィアとか呼んで悦に入ってるのか？聞こえてんのか。
まずな、ゲームだのシミュレーションだの、そういう言葉をつけた瞬間に理解した気になる癖をやめろ。
ラベル貼っただけで中身を掴んだ気になる。居酒屋で経済を語るサラリーマンと同レベルだ。
こっちはこの宇宙の中で、分子がぶつかる音を聞きながら生きてる。
痛みもある。老いもある。腹も減る。
その全部をひっくるめて「ゲームです」って言うならな、ずいぶん重たいゲームだな。コントローラーはどこだ。リセットボタンはどこにある。
そしてな、スフィア社とかいう連中。その社長、ルシファーとかいうやつ。
おいルシファー。
ずいぶん大層な名前だな。神話から借りてきた看板背負って、宇宙を一個サーバーに入れて「はい完成」って顔してるのか。
もし本当にそんな会社があるならな、社長としての仕事はまずバグ取りだろうが。
テストサーバーか？ここは。ベータ版か？ユーザーサポートどこだ、酒持って文句言いに行くからよ。
だったらな、リアリティの追求が行き過ぎてる。プレイヤーが実際の痛みを伴う仕様のゲームは普通クレーム来るんだよ。
こっちはただのNPCじゃない。だからルシファー、もし聞いてるなら覚悟しとけ。
そうなったらな。
「エターナルスフィアです」なんてドヤ顔してるFD人どもより、中にいる奴のほうが、この宇宙の仕組みを理解してることになる。
ドライバ開発においてAI（LLM）が生成したコードをそのまま信頼するのが危険な理由は、単に「コードが間違っている可能性がある」というレベルを超え、**「AIが物理世界（ハードウェア）の挙動を直接観測できない」**という根本的な制約に起因します。
具体的に、なぜ不安定になりやすいのか、4つの技術的な視点から解説します。
ハードウェアには、マニュアルに書かれていない挙動や、特定の条件下でのみ発生するバグ（エラッタ）が必ずと言っていいほど存在します。
AIの限界: AIは「公開されている一般的な情報」を学習していますが、特定のチップの特定のバージョンにおける隠れた不具合（エラッタ）への対策コードを生成することは困難です。
リスク: 仕様通りに書いているのに、特定のタイミングでチップがハングアップする、といった現象を防げません。
通信処理（I2C、SPI、UARTなど）では、信号を「HIGH」にしてから「LOW」にするまでの待ち時間など、厳密なタイミングが求められます。
AIの限界: AIは論理的な手順は書けますが、実行環境（CPUクロック、OSのスケジューリング）における実時間の経過を考慮したウェイト処理を正確に組み込むのが苦手です。
影響: 通信波形が乱れ、データ化けやデバイスの認識失敗が頻発する原因になります。
ドライバは通常、OSの核心部（カーネル空間 / Ring 0）で動作します。
致命的な違い: アプリケーション層のプログラム（PythonやJavaなど）であれば、エラーが出ても「アプリが落ちる」だけで済みますが、ドライバの不備は**OS全体のクラッシュ（ブルースクリーンやカーネルパニック）**に直結します。
AIの弱点: 割り込みハンドラ内での禁止事項（メモリ割り当ての制限やスリープ不可など）を、AIが完璧に守り切るのは非常に難易度が高いです。
ドライバは、メモリの特定の番地（レジスタ）に値を書き込むことでハードウェアを動かします。
AIの弱点: AIはよく似た型番のチップのレジスタマップを混同することがあります。
結果: 全く別の機能を操作してしまったり、予約済みの領域を上書きしてハードウェアを物理的に損傷（過熱や過電圧など）させたりするリスクもゼロではありません。
AIをドライバ開発に使う場合は、**「コードを書かせる」のではなく「レビューの壁打ち相手」や「定型文の生成」**に限定するのが賢明です。
自分はしがない底辺エンジニアだが、ずっと疑問に思っていたことがある。
SIerの仕事の進め方をはたから見ていると、そこにいる人たちは驚くほど優秀で、地頭も良く、調整能力も高い人ばかりだ。なのに、彼らが心血を注いで作り上げたシステムは、驚くほど使い勝手が悪かったり、リリースした瞬間から負債になっていたりする。
「なぜこれほど優秀な人たちが集まって、価値のないシステムを量産しているのか？」
その違和感が拭えず、AIと対話しながら自分の考えを整理してみた。これは、ある底辺エンジニアが、日本のIT産業を覆う巨大な「構造的欠陥」について思索した結果の駄文である。
ソフトウェア開発の本質的な特性は、建築や製造業のような「設計（図面作成）」と「施工（組み立て）」の物理的分離が論理的に不可能であるという点にある。ソフトウェア工学の観点に立てば、コンピュータが解釈可能な厳密な意味での「詳細設計」とはソースコードを記述する行為そのものであり、それ以降のコンパイルやデプロイといったプロセスは、人間が介在しない自動実行（ビルド）に過ぎない。
しかし、日本のSIerビジネスは、1970年代の土木・建築モデルを安易に転用し、管理の便宜上「思考（設計）」と「作業（実装）」が明確に分離可能であるという誤った前提に立ち、それらを異なる主体や階層に割り当てる構造を選択した。この無理な分断は、実装段階で初めて露呈する設計上の矛盾や技術的制約を、設計工程へ即座に還流させるフィードバックループを契約上・工程上の「手戻り」として著しく阻害している。
その結果、実機の挙動を知らない設計者が机上の空論を書き連ね、設計の背景思想を共有されない実装者が矛盾を抱えたままコードを書くという情報の劣化が常態化した。現場では本質的な解決ではなく、納期と検収を優先した対症療法的なパッチワークが繰り返され、これが日本の基幹システムを柔軟性のない、巨大で保守不能な負債の塊へと変貌させる根本原因となっている。
システムはビジネス戦略を具現化するための装置であり、その真の成否は「仕様書通りに動くか」ではなく「事業の利益創出や競争力向上に寄与したか」という実利的な成果によってのみ判定されるべきものである。しかし、請負契約を基本とするSIerモデルは「システムの構築（プロセス）」と「ビジネスの成果（結果）」を完全に切り離し、構築のみを外部に切り出す形式をとったことで、本来一致すべき両者の利害を根本から対立させてしまった。
受託側であるSIerの収益は、顧客が仕様との形式的な適合を認める「検収」の瞬間に確定する。納品後のシステムが実際に現場で活用され、事業に貢献するか否かは彼らの報酬に一切影響しない。むしろ、設計の不備や使い勝手の悪さが運用開始後に露呈し、頻繁な改修が必要になるほど、SIerにとっては追加案件としての売上が発生するという、顧客の不利益が受託側の利益に直結する「利害の逆転」が構造的に組み込まれている。
このように、価値創出に対する最終的な責任を負わない外部組織が、ビジネスの心臓部であるロジックの設計・実装を担う構造は、経営学的に見ても極めて不合理である。企業がIT投資を通じて得るべきリターンを、実効性の低い「納品物」という形式的な実体にすり替えるこの仕組みは、日本企業を構造的な無能化へと追い込む装置として機能してきた。
日本は物理資源を海外に依存せざるを得ない宿命的な制約を抱えており、原材料の輸入や物理的な輸送コストを必要とせず「知的能力」のみを付加価値の源泉とするソフトウェア産業は、本来、最も生存戦略に合致した国家の基盤業種となるべきであった。しかし、インターネットの普及により世界の経済構造がソフトウェア中心へと激変したこの30年間、日本のSIerという業態は「人月単価」という前世紀的な労働集約型モデルを墨守し、日本が持つ唯一の資源である「優秀な人間」を著しく毀損し続けた。
本来であれば、高度な実装能力を通じて世界をリードする価値を創造すべき最優秀層のエンジニアたちが、多重下請け構造という巨大なピラミッドの中で「進捗監視」や「証跡作成」「利害関係者の調整」といった、直接的な価値を産まない非生産的な管理業務に長期間拘束されている。この構造下では、個人の卓越した技術力よりも「代替可能な工数」としての管理しやすさが優先され、エンジニアが技術の限界に挑み、それをビジネス価値に直結させるという最も重要な学習機会が社会全体から剥奪されてしまった。
世界が「ソフトウェア・イズ・イータリング・ザ・ワールド」を掲げ、爆発的なスピードで破壊的イノベーションを遂げたこの30年間、日本は世界に誇るべき緻密な知性を、SIerという枠組みの中で付加価値の低い事務作業や調整業務へと浪費させてきた。これこそが、かつての製造業のような輝きをIT分野で放つことができなかった日本の「知の敗戦」の正体であり、デジタル経済圏における日本の国際競争力が著しく低迷し続けている、看過できない構造的要因の一つであると考える。
そこそこの規模の会社でITエンジニア（社員）がやってる業務の一覧（全部ではない）
| 組織レベル | タスク | AI親和性（予想） |
| Lv0：個人〜最小チーム | コーディング（実装） | 🟢 早期に大部分自動化 |
| 単体設計（クラス/API） | 🟢 早期に大部分自動化 | |
| テストコード作成 | 🟢 早期に大部分自動化 | |
| リファクタリング | 🟢 早期に大部分自動化 | |
| ログ調査・軽微なバグ修正 | 🟢 早期に大部分自動化 | |
| Lv1：役割分離（PM/Design等） | 仕様書ドラフト整理 | 🟡 補助的に自動化 |
| 要件の解釈・曖昧さ発見 | 🟡 補助的に自動化 | |
| UI/BE責務の切り分け | 🟡 補助的に自動化 | |
| PMとの仕様すり合わせ | 🟡 補助的に自動化 | |
| QAとの再現条件調整 | 🟡 補助的に自動化 | |
| チーム内認識合わせ | 🟡 補助的に自動化 | |
| Lv2：チーム間連携 | API境界整理 | 🟡 補助的に自動化 |
| モジュール責務設計 | 🟡 補助的に自動化 | |
| 影響範囲分析 | 🟡 補助的に自動化 | |
| Feature Flag運用判断 | 🟡 補助的に自動化 | |
| 他チームとのリリース同期 | 🟡 補助的に自動化 | |
| Lv3：組織運営（10人〜） | 技術調査（SaaS/AWS等） | 🟡 補助的に自動化 |
| 技術選定 | 🟡 補助的に自動化 | |
| 非機能要件の検討 | 🟡 補助的に自動化 | |
| ADR作成 | 🟡 補助的に自動化 | |
| KPI→開発優先度変換 | 🟡 補助的に自動化 | |
| 事業計画→技術タスク分解 | 🟡 補助的に自動化 | |
| Lv4：人間系（組織的責務） | 採用（面接・評価） | 🔴 自動化ビジョン不透明 |
| 育成（OJT・レビュー文化） | 🔴 自動化ビジョン不透明 | |
| 勉強会・ナレッジ共有 | 🔴 自動化ビジョン不透明 | |
| 社内技術広報 | 🔴 自動化ビジョン不透明 | |
| チーム間政治調整 | 🔴 自動化ビジョン不透明 | |
| 炎上時の説明責任 | 🔴 自動化ビジョン不透明 | |
| Lv5：プロジェクト外部接続（受託/SI） | 顧客折衝 | 🔴 自動化ビジョン不透明 |
| 契約仕様の解釈 | 🔴 自動化ビジョン不透明 | |
| 外注管理 | 🔴 自動化ビジョン不透明 | |
| 稟議資料作成 | 🔴 自動化ビジョン不透明 | |
| SLA調整 | 🔴 自動化ビジョン不透明 | |
| ベンダー管理 | 🔴 自動化ビジョン不透明 |
AIがプログラミングできたくらいではまだ「残業を減らす」程度でしかなくなる
貴様は今日も設計を名乗りながら、プログラマーを手が速いだけの文字入力装置として扱い、仕様という名の曖昧な願望リストを投げつけ、実装フェーズで破裂する地雷原を育てていることと思う。
大変結構。地雷の栽培は趣味としては悪くない。だが仕事でやるな。
気分と希望と思いつきのトリプル放尿をPowerPointに整形しただけの、装飾付き未確定情報である。
そして貴様はそれを「この通りに作れ」と言う。
その資料には「整合性」「境界条件」「異常系」「性能要件」「運用」「データ整形」「責務分離」が存在しない。
あるのは雰囲気と矢印と、謎の箱だけ。
決めた上で、破綻しないように制約を置き、曖昧さを潰し、例外を定義し、トレードオフを明示し、運用まで見通す。
「たぶんこう」「いい感じで」「よしなに」で逃げる。
そして何より滑稽なのは、貴様がプログラマーを「タイピスト」だと思っていることである。
論理を構築している。
異常系の宇宙と格闘している。
データの整合性を守りながら、速度と保守性と拡張性の三つ巴の地獄で妥協点を探している。
簡単なら、お前がやれ。
だが現実は違う。
その地味さに耐えられず、見栄えだけの資料を作り、「設計完了」と言って会議室から消える。
そして炎上したら戻ってきて、こう言う。
「なんでこんな実装にしたの？」
それはお前が決めなかったからだ。
ここで貴様の最終奥義が出る。
「設計通りに作ってくれればよかったのに」
出た。責任転嫁の完成形。
設計が曖昧だから実装側が補完したのに、その補完を勝手な判断と呼ぶ。
最後に言っておく。
設計者を名乗るなら、最低限やれ。
決めろ。曖昧さを残すな。
データの形を決めろ。型と制約を決めろ。
敬具。
現状
やりたいこと
Anthropicというか、生成AIがITエンジニアの仕事を奪うっていう言説、あれ半分正解で半分間違いだと思う。 正確には「今のやり方のままの仕事」はなくなるけど、IT業界全体のパイが縮むわけじゃない。 結局、現場の編成が劇的に変わるだけなんだよな。
昔みたいに、仕様書を読み込んでひたすらコードを書く「写経職人」みたいなレイヤーは、そりゃあClaudeに食われるだろうよ。 でも、その分、一人のエンジニアがこなせるスピードと範囲がバカみたいに広がる。 今まで10人で3ヶ月かかってたプロジェクトが、AIを使いこなす3人で1ヶ月で終わるようになる。 そうなった時に「じゃあ残りの7人はクビだね」ってなるかというと、普通の感覚ならそうはならない。 今までコストやリソースの問題で諦めてた「本当はやりたかった別のプロジェクト」にその7人が投入されるだけだ。 ソフトウェアで解決しなきゃいけない課題なんて、この世にまだ無限にあるんだから。
本当の問題はエンジニア個人じゃなくて、会社の方にある。 「生成AIはセキュリティがー」とか言って思考停止して全面禁止してたり、 「人月単価で稼いでるから、効率化されると売上が減って困る」とか抜かしてる旧態依然としたSIerとか。 そういう「AI前提の編成」にアップデートできない組織が、これから凄まじい勢いで淘汰されていく。 AIを武器にして少人数で爆速でプロダクトを回す競合に、価格でも納期でも勝てるわけがない。
エンジニアの職が奪われるんじゃない。 AIを使いこなせない「古い体質のままの組織」が、AIを標準装備した「新しい組織」に食い殺されるだけ。 これは職の消失じゃなくて、残酷なまでの適者生存だよ。
俺たちにできるのは、AIに怯えることじゃなくて、AIをどう自社やチームの編成に組み込むか必死に考えること。 とりあえずClaudeに課金して、今日もひたすらプロンプトをこねるしかない。 結局、道具が変わっても、この業界が椅子取りゲームなのは変わらないんだよな。
