個人の生産性は青天井、そんな時代のエンジニアはチームに何をなすべきか

AI活用 LT祭り ─ あの人・あの会社のAI活用事例のLT資料です
https://supporterz-seminar.connpass.com/event/397967/

Transcript

1. 個人の生産性は青天井 そんな時代のエンジニアは チームに何をなすべきか 2026/07/28 AI活用 LT祭り ─ あの人・あの会社のAI活用事例 株式会社TOKIUM Webエンジニア 坂上 晴信
2. 突然ですが… みなさんは覚えていますか？ 2
3. 最早懐かしさすら感じる、象徴的な記事 公開日: 2025/02/26 公開日: 2025/03/13 あれから約1年半、コーディングエージェントはソフトウェア開発のあらゆる現場で 当たり前に使われるようになった 3
4. 現代のソフトウェア開発の様子：PdE Confより 今年9月開催の Product Engineering Conference のプロポーザルを見てみると… 職能固定の体制を廃止 全員が全部やる、1人1案件の 体制に2ヶ月間チャレンジ 営業・CSが直接開発の 当事者になる 仕組みを作る 通常6名のプロジェクトを PdM 1人で本番リリース 出典：fortee.jp - Product Engineering Conference 2026 プロポーザル一覧 全206件のうち、28件が「チームの縮小 or 解体」「非エンジニアの開発への関与」に言及 → 従来の開発のあり方が破壊される事象が、当たり前のように発生する世界線になった 4
5. 現代のソフトウェア開発の様子：TOKIUMより TOKIUMにおいても「非エンジニアの越境」という形で、これまでの開発のあり方の破壊的な 変革が起きている PdM Figma Makeでプロトタイプを爆速で作り、 開発・営業双方に方向性を明示 議事録をHTML化して共有するWebアプリを 自作 → 社内に広め、情報共有を高速化 デザイナー Figmaのデザインをフロントエンドコードへ 変換するAgent Skillを作り、実装を爆速化 Vercel上のプロトタイプにデモツアー機能を 実装 → 営業チームの武器として提供 どちらも僕がリードするチームでの実例 AIを使いこなす優秀なメンバーと働けて、とても幸せ！ 5
6. しかし、ふとこんなことも感じる このプロジェクト、実は PdMとデザイナーだけで回る説 6
7. しかし、ふとこんなことも感じる エンジニアとして、自分の貢献余地は 残されているのだろうか？ 7
8. 今日話すこと 非エンジニアが越境を重ね、生産性を青天井に伸ばす時代に、 エンジニアはチームに対して 何をなすべきか 、僕の実践を踏まえて言語化し、共有 プロダクトが安定して動く基盤づくり プロジェクトが安定して回る基盤づくり チームが安定して継続する基盤づくり 2026年もAIに振り回された僕のような方に向けて、残りの1/3をどのような心持ちで過ごすべきか ヒントを与えられたら良いな！と思います 8
9. 自己紹介 / リアルのすがた 坂上 晴信 Harunobu Sakaue 経歴 1995年生まれ。東京の離島・伊豆大島出身。 エンジニア → DevHR（= 開発組織専任の人事）→ エンジニア ⚫︎ 2016年 3月 東京高専 情報工学科卒 ⚫︎ 2016年 4月 株式会社TOKIUM 入社 Android/Webエンジニア ⚫︎ 2023年 1月 DevHRにロールチェンジ 育成・組織づくり・採用広報 ⚫︎ 2025年12月 再びエンジニアにロールチェンジ Webエンジニア ⚫︎ NOW! 9
10. 自己紹介 / インターネットのすがた にしこりさぶろ〜 @subroh_0508 好きなもの Kotlin / アイドルマスター / ラブライブ！ Kotlin本体へのContribute経験、Kotlin Festへの複数回の 登壇経験アリ。DevHR時代も趣味でKotlinを書き続け、 "200名収容の会場で技術登壇をした人事" になった。 プライベートでは、アイマスPとライブライバーを兼任。 『シャニマス』三峰結華と『蓮ノ空』村野さやかが 人生のロールモデル。 10
11. 前提: いま作っているもの 2つの外部サービスに挟まれた 新規プロダクトを、ゼロから立ち上げている 外部サービス イベントの発生源 利用者 Webhook 1件も落とせない 重要イベント いま作っている 新規プロダクト データ連携 既存基幹システム レガシー / 変更コスト大 日々の操作 / 参照 同期・非同期の使い分け、冪等性の確保、外部サービス固有の値を考慮したテーブル設計 etc. 「一筋縄ではいかない要素が、特にシステムと運用の設計フェーズに数多く存在する」 システム 11
12. プロダクトが安定して動く基盤づくり 「他の人が使うソフトウェアの開発」において、専門家のコミットは未だ必須 個人開発、あるいは PoCレベルのものは誰でも作れる → お客様からコンテキストを直接回収できる人が作るのがベスト 一方で、数万人・数千社の利用を前提とした開発では、まだまだ専門家の知識と経験が必要 → 専門家でないと、特に システム設計・インフラ構築 の領域で落とし穴に無限にハマる → AIは知識こそ無限だが、トレードオフの判断が苦手（オーバーエンジニアリングしがち） Takuto Wada @t_wada · Follow Vibe Coding は「自分だけが使う、自分がいちばん欲しい ソフトウェアをだれでも作れるようになった」ことが革 命的かつ真骨頂なのであって、他の人が使うソフトウェ アを作ることには（少なくともまだ）向いてないと思い ます 3:46 AM · Jul 25, 2025 4.3K Reply Copy link Read 6 replies Coding は「自分だけが使う、自分がいちばん欲しい “ Vibeソフトウェアをだれでも作れるようになった」ことが革命的かつ 真骨頂なのであって、他の人が使うソフトウェアを作ることには （少なくともまだ）向いてないと思います 12
13. プロダクトが安定して動く基盤づくり でも自分、システム設計やインフラ構築、やったことないです このまま淘汰されるのを待つしかないんでしょうか…？ 大丈夫！僕も、今の規模のWebサービスのシステム設計・インフラ構築は人生初だ！ AWS分からなすぎて泣きそうだけど、AIと先輩エンジニアのおかげでどうにかなってるぞ！ システム設計・インフラ構築の経験が積めるチャンスは、全力で掴みにいく どちらも 不可逆性の高い意思決定 が求められ、事業成果に直結しやすい 新規PJ発足・組織改編等をきっかけに、これらの業務が経験できそうなら迷わず手を挙げる 「明らかに手に負えない」と感じた場合も、 まずはAIと壁打ちしながら意見をまとめ、 その後先輩のエンジニアにレビューしてもらう 手順を踏むと、スムーズに進みやすい 13
14. プロジェクトが安定して回る基盤づくり AIが全てのコードを書く世界において、必要なのは 「品質評価の基準・仕組みを構築する」 ことと 「ノイズを減らすために規約・指針を整備する」 ことの2点 ※結合テスト前なので、現在は後者に注力 仕様書のフォーマット策定 AIレビューの指摘数が減少 実装前にズレ・漏れに気づく 非定型なドキュメントを効率よくリファクタする 実装計画をIssueに残す AIの思考過程が記録に残り 非効率な箇所を特定できる AIを賢くしたいなら、まずは人間の改善ループから 人間相互レビュー要否基準 なぜ必要かを明文化 した結果 人間承認なしでのマージ増 Pull Request、AIレビューだけでマージしてOK？ 多くのエンジニアが試行錯誤中の領域、 キラキラした他社の発信に振り回されない ことが大事 14
15. チームが安定して継続する基盤づくり 社内で「参考にすべき先行事例」と評価されているが… 実態として、エンジニア歴5〜10年の経験者が複数名投入 されている贅沢な状況 チーム・組織を長く存続させるには、 AIネイティブ世代（= 手書き実装を知らない世代） を 「手書き実装で育った経験者と同じ水準で意思決定ができる」レベルまで育てる 必要がある AIのアシストを活かし、 責任のある判断を任せて 質の高い経験学習を早期からたくさん回す とよい？ ※今週のスプリントから実践！早く僕を Disrupt してくれ！ AIが当たり前の組織で エンジニアはどう育つか 15
16. まとめ 非エンジニアでもソフトウェアを作れる時代になったが、 我々エンジニアの失業は、まだまだ先 になりそう エンジニアが作るべきは、プロダクト・プロジェクト・チームが 安定して動き続けるための「基盤」 AIの進化によって生まれた 全く新しい課題 に向き合い続けるのは 大変だが、間違いなく血肉になる 大変な時代ですが、 お互いがんばりましょう！ 16
17. 情報発信中！ 資料公開＆技術発信は公式Xから 本日のスライドは公式Xで公開！ 開発チームの技術やイベント情報を 発信中、フォローお願いします！ @TOKIUM_Dev 17