Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
AIがコードを書く時代、 あなたの価値は何で決まるか~3年後のエンジニア組織と生存戦略~
Search
Narihara
July 30, 2026
Technology
15
0
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
AIがコードを書く時代、 あなたの価値は何で決まるか~3年後のエンジニア組織と生存戦略~
Narihara
July 30, 2026
More Decks by Narihara
See All by Narihara
余白のフラクタル・デザイン ~ 個人・チーム・組織の連鎖的成長戦略 ~
narihara
1
220
5つのアンチパターンから学ぶLT設計
narihara
2
550
型がない世界に生まれ落ちて 〜TypeScript運用進化の歴史〜
narihara
1
310
Road To「全員リクルーター」 ~新卒採用編~
narihara
0
220
LeSSをはじめて1年 我々はどこから来たのか 我々は何者か 我々はどこへ行くのか
narihara
0
89
組織をドライブさせる「評価」方針 at 20240129_ROSCAFEミートアップ.pdf
narihara
0
99
エンジニアドリブンで事業KPIから着想を得たプロダクトカイゼンを行っている話
narihara
0
380
キャリアにキく目標設定
narihara
0
170
Other Decks in Technology
See All in Technology
tamachi.go 誕生の裏側
rymiyamoto
1
200
ソフトウェアサプライチェーンの構造的リスクとコンテナ環境の保護
kyohmizu
5
900
Eight Engineering Unit 紹介資料
sansan33
PRO
3
8.3k
Sansan Engineering Unit 紹介資料
sansan33
PRO
1
5k
Genie Codeハンズオン応用編
taka_aki
0
140
NANDでも描画したい!
nichica906
3
660
35分でわかるEffective Platform Engineering
nwiizo
5
620
【CEDEC2026】Creative Approaches to Localizing the Dialects and Unique Speech of Umamusume: Pretty Derby Characters in English
cygames
PRO
4
26k
AIで変わるエンジニアの働き方(仮)
naoinaoi
0
490
Rust×eBPFでEDRっぽいものをつくる
sunlife3
2
920
型落ちシンクライアント端末のPoEモジュールを自作したかった話
logica0419
0
400
Sets in Go
ramalho
1
1.2k
Featured
See All Featured
The AI Revolution Will Not Be Monopolized: How open-source beats economies of scale, even for LLMs
inesmontani
PRO
3
3.7k
We Have a Design System, Now What?
morganepeng
55
8.3k
From Legacy to Launchpad: Building Startup-Ready Communities
dugsong
0
310
[RailsConf 2023] Rails as a piece of cake
palkan
59
6.9k
Helping Users Find Their Own Way: Creating Modern Search Experiences
danielanewman
31
3.3k
Lessons Learnt from Crawling 1000+ Websites
charlesmeaden
PRO
1
1.5k
Tips & Tricks on How to Get Your First Job In Tech
honzajavorek
1
710
I Don’t Have Time: Getting Over the Fear to Launch Your Podcast
jcasabona
35
2.8k
Self-Hosted WebAssembly Runtime for Runtime-Neutral Checkpoint/Restore in Edge–Cloud Continuum
chikuwait
0
740
Getting science done with accelerated Python computing platforms
jacobtomlinson
2
450
Hiding What from Whom? A Critical Review of the History of Programming languages for Music
tomoyanonymous
3
1.1k
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
141
35k
Transcript
AIがコードを書く時代、 あなたの価値は何で決まるか 3年後のエンジニア組織と生存戦略 2026.07.24 成原 / スペースマーケット
自己紹介 株式会社スペースマーケット EM 成原 聡一朗 Narihara Soichiro FEエンジニア出身(得意領域はWebpackとか) モヒカン歴17年 趣味は筋トレ、SF小説読書、オリジナルTシャツ作成
(右の写真はカスタムした55キロのダンベル)
自己紹介 SuzuriのURLはこちら オリジナルTシャツはコラージュアートでこんなのを作ってます。
None
マーケットプレイスの紹介 掲載スペースは全国に多数! あらゆるスペースを簡単に貸し借り できる国内最大級のスペースシェア プラットフォーム
None
Spacepadの紹介
Spacepadの導入事例
本題
AIがあなたより速く、安くコードを書くとき 市場は、あなたの「何」にお金を払うのか?
国内外の予測と、語られていない能力 Gartner 2029年までに60%の組織が 小規模「タイニーチーム」体制へ McKinsey 夜間はAIが実装、朝に人間がレビュー 「24時間開発モデル」が稼働 実装はAIへ、人間には「判断」が残る。方向はどこも同じ 国内のキャリア論に並ぶ軸: 上流へ
/ マネジメントへ / スペシャリストへ そこに暗黙的に含まれているのに、名指しされない能力 =「検証力」
1. 今後の組織はこう変わる
ボトルネックは「作る速さ」から「決める速さ」へ これまで 企画 意思決定 実装 テスト リリース 詰まる場所 (ボトルネック)
これから 企画 意思決定 実装 (AI) テスト (AI) 詰まる場所 各所で話されている通り、詰まる場所は消えるのではなく上流に移る リリース
組織は小型チームになる チーム1 正社員2〜3名 + 業務委託 チーム2 正社員2〜3名 + 業務委託 チーム3
正社員2〜3名 + 業務委託 委譲 = マネージャーが認知する課題の抽象度を上げる(タスクではなく方針だけを見る) 測るべき① 意思決定リードタイム (企画着想 → リリース) 測るべき② エスカレーションなしで 完結した意思決定の割合
集中の形も変わる: ゾーンから多重集中へ ピープルウェアの「ゾーン」 一つのことへの深い集中 = 単一タスク時代の最適解 多重集中 複数のAIパイプラインを監督し 全体でひとつのフローに入る ただし、重い判断(ACの妥当性・ドメイン直感)は並列化できない
軽い判断は多重化し、深い判断の時間は死守する ※AC:Acceptance Criteria 受け入れ基準を指す
2. 人間に残る仕事
一年前別の場所で登壇した時の私の見解 着実に「コーディング」の再定義が行われている2025年現在。 今後のエンジニアに求められるスキルは以下3だと捉えています。 1. 創造性: 『問い』の品質を上げる 2. 言語化: 抽象的な事柄の言語化力 3.
審美眼: AI生成物のValidation機構としてのスキル
審美眼について Codexチームが採用で重視する明確な基準の一つは、審美眼やセンスである。膨大なコンテンツの中か らシグナルとノイズを見分けられること。「無限のトークン」を持つ世界で、彼らは低品質なコンテン ツを生み出したくないのである。 『Codex責任者、「誰もが開発者になれる」は非常に悪い考えだと指摘』
では審美眼とは何か? 前述の記事では『膨大なコンテンツの中からシグナルとノイズを見分けられること』と定 義されています。 では、どうすれば膨大なコンテンツの中からシグナルとノイズを見分けられるのでしょう か? ここはレビューという行為にヒントがあります。
レビューの構造について エンジニアならば誰でも経験があるレビュー ここは以下3点で分解できます ドメイン (事業にとって正しいか) 設計 (構造・依存の向き) コードスタイル (命名・書き方)
レビューはこの順番でAIに吸収される それでも、残るものがある ドメイン (事業にとって正しいか) 設計 (構造・依存の向き) コードスタイル (命名・書き方) 仕組み化はできるが 人間の暗黙知・直感に左右される
順に吸収される AIで解決済み
ヴィンテージ古着ECサイトの仕様書 商品登録仕様 Tシャツのサイズ設定 S / M / L / XL
この仕様、何が足りない?
残るのは「検証力」 違和感に気づく サイズが欠けている 関係者に問う 判定可能な条件へ XXLは要らないのか? XXL以上の在庫が 登録・検索できること 直感を仕様の言葉に降ろす力 =
ACを書く力 = 検証力 技術的専門性の賞味期限は体感3〜5年 大量生成の時代、開発の時間を決めるのは生成ではなく検証
AIにタスクを依頼する際ACは重要 人間同士 曖昧な依頼でも 阿吽の呼吸で補完できた AI相手 明文化するしかない ACに書いたことがすべて AIに実装を任せる = 「何をもって完成とするか」の明文化が省略できない
タスクの品質を保つには適切なACが重要
3. 生存戦略
二極化は、働き方の話 判定を持たない工程 (渡されたスペックを消化してEnterするだけ) → AIとの価格競争に負ける 正社員も フリーランスも 判定を持つ仕事 (ACの穴を見破れる) →
複数組織に刺さるポータブルな判断者
スキルシェアリングの時代へ 並列開発の上限は AIではなく人間の認知にある 文脈の引き継ぎコストが AIで急落(仕様・判断履歴の蓄積) → 週3の参画でも更に活躍の可能性が広がる 判断力 × ドメイン
キャッチアップ速度 速い人 = AI検索が上手い人ではなく、仕様の欠落を見つけて人に問える人
明日からやれる3つ 1 いまのチケットの「完成の条件」を自分で書き、実際との差分を見る 2 レビューで「なぜこの設計なのか」を1回聞く 3 判断と根拠を言語化して残す(AIに読ませるドメイン知識のコンテキストとして) この3つは、どんな立場でも明日から始められる
意思決定について 「この機能の受け入れ条件は、どなたが、 どのような背景で、どう決めていますか?」 すぐ答えが返る組織 = 組織としての方向性が明確な組織 ひとつの見立てとして
冒頭の問いへの回答 市場が払うのは 「プロダクトの方針を判断・決定する力」 AIは実装を奪う。 そして判断は人間が奪い合う。
CONFIDENTIAL