はじめに
さて、デブサミDay2のセッションレポートをまとめていきます。
Day2からは、例年通りエンジニアリングに焦点を当てたデブサミです。
僕らになじみのあるデブサミですね。
Day1のDev x PMではエンジニアとプロダクト・プロジェクトマネージャとの協働から、このAI時代におけるそれぞれの役割などが語られました。
多分Day2からの参加の方も沢山いらっしゃると思いますが、Day1から参加していた身としては、Day1とDay2・3は別物ではなく、地続きとなっていたと思います。
Day1で語られた「これからのエンジニアには、PMとしての知見や立ち回りがより一層求められる」。
さぁではDay2ではそれはなぜなのか？AIによってコードをほぼ書かなくていい時代に、僕らエンジニアはどう生きるのか？
そんな事が語られたように思います。
というわけで、セッションメモを元に振り返っていきたいと思います。
受講セッション
- AI時代の仮説思考と仮説行動
- Google Antigravity と Gemini CLI を活用した AI エージェントファーストな開発の始め方
- AIとデータでエンジニア組織をエンパワーする
- バイブコーディングの罠：開発者が知るべきセキュリティの急所
- チームを増やしても、なぜ開発は速くならないのか？― LeSS × SPACE × AIで見えた、生産性を阻害する構造と打破した壁
- AI ネイティブ組織への変革:ビジネスとITの統合が拓く未来 AIで“はたらく”をアップデートする人材業界パーソルキャリアのリアル
- Vibe Coding起点での新機能開発で「あすけん」が乗り超えた壁 ～PdM&エンジニアの新たな共創プロセス～
- 「おとうさん、AIが発達したらクビじゃない？」──47歳、生涯エンジニア宣言。
- 「作りたい」を実装する個人開発の技術と情熱！見て聞いて触れるリレーセッション
Vibe Codingの光と影：「動くPRD」と「本番実装」の巨大な壁
光
- PdMなど非エンジニアが数時間で動くものを作ることが出来る
- ユーザー検証用の動くPRDとして機能
- 自然言語で構築が可能、数時間でデプロイ可能
闇
- Vibe Codingで生まれたものをそのまま本番流用すると・・・
- TTFT（Time To First Token）が遅い
- エラー調査ができない（ロギングができていない）
- リーダブルなコードではない
- 結果、 「通常2人月で終わる作業が6人月に膨れ上がる」 事態に
- AIが作るプロトタイプには「細かい仕様設計」や「非機能要件（保守性やパフォーマンスなど）」が考慮されていない。
現場で起きた例を紹介いただきましたが、恐らく、プロダクトに関わる多くのエンジニアが身に覚えのある、生々しい話だったのではないでしょうか。
確かにAIは開発のやり方・スピード感を大きく変えましたが、やはりそこには光と闇がまだ存在していて、脳死で利用・本番リリースできるものはありません。
とはいえそれをどうすれば出来るだけ本番リリースに耐えるものにできるか、あるいは動くPRDから本番リリースへ至るまでを如何に短縮できるか、そこにまたエンジニアの存在価値、役割があるのだと改めて感じました。
この後他の話にも通じるところはありますが、AIは基本的に指示していないことはやりません。指示していない部分は、なんとなく良しなにやってくれるだけです。
僕らはこの巨大で強力な武器の性能や特性を理解し、正しく使っていく必要があります。
AIを迷わせないための「暗黙知の明文化（ルール化）」
- コンテキスト不足で起きる弊害
- 不正確な情報
- 情報の欠落
- 不要な情報
- 明文化の仕組み
- Gemini.md / SKILLS.mdなどに明文化し、AIに読み込ませる
- 基本ルール
- 暗黙知・技術スタック
- やってはいけないこと
- 判断基準
- Gemini.md / SKILLS.mdなどに明文化し、AIに読み込ませる
- プロセス（計画）に時間をかける
- AIを迷わせないために、いきなりコードを書かせない
- 「実装プランを作成・検討させる（計画に時間をかける）」ことが重要
- 組織的な言語化
- PjMやPdMによる言語化や、ADR（アーキテクチャの決定に至る議論の記録）を残すなど、「いかにデータ化しておけるか（コンテキストエンジニアリング）」が問われる
- 組織の暗黙知をなくしていく
- これまでも当たり前に存在していた「計画書」「アジェンダ」「手順書」
- 人間同士の汲み取り（なんとなく察する）を無くす
- 当たり前の事を当たり前にやる
僕らはこれまで人間を相手に仕事をしてきましたが（いや、これからもそうなんですが笑）、人間同士、言葉と言葉の間を読み、動いていくという状況は当たり前のように存在していて、何ならその能力が高い人は優秀と評価されていたりもします。
しかしAIを相手にすると、それは逆転する。
AIももちろん汲み取ってはくれますが、そこには何の保証もなく（人間相手もそうなんですが）、むしろ如何に相手に推測させないで、言語化し指示できるか。
察する側ではなく、指示側の能力こそが問われますね。
しかしながら、ここまでを見ても、エンジニアの役割が「コードを書く」から、「仕様検討し、実装計画を作り、指示を出す。そしてそれを評価し、最終判断をする」へ変わってきているのが分かります。
明らかに役割が変わっているのがわかりますし、エンジニアに問われる能力がよくわかりますね。
コーダーから「監督者」へのシフトとセキュリティ（反脆弱性）
- AIがセキュリティコードを書かない
- 指示にないことは書かない
- セキュリティの欠如は目に見えない（動けば正しく見える）
- 結果として、認証なしAPIやデータアクセス制御の欠如（Tea事件での72,000件漏洩など）を招く
- 開発環境への脅威
- MCP（AIエージェントが開発者と同じ権限で動く機能）の脅威
- CamoLeak（環境変数の漏洩）
- AIツール自体が攻撃経路になり得る
- 個人のスタンス転換
- コーダーから「監督者」へ
- AIのコードを即座に受け入れない
- 静的解析や秘密鍵スキャンなどのツールで「ループを閉じる（検証する）」
- 禁止よりも安全を
- ガードレール
- CI/CDでの自動検出（MTTGの短縮）
- サンドボックスによる環境分離
- npmのスクリプト実行無効化
- ガードレール
暗黙知をなくし、計画を練って実装させる。
その際に、指示していなかったセキュリティや非機能要件は、良しなにやってはくれますが、それが求められているラインを超えているかはわかりません。
エンジニアはこれらの監督者となり、きちんと評価して責任を持って届ける必要があります。
そのための工夫もまた、エンジニアらしい発想でいいですよね。
仕組みでカバーしていく！
人間の本質的価値：Whyを問い、判断し、責任を取る力
- AIにできること
- 膨大な知識
- 高速処理
- 傾向の抽出
- できないこと
- 指示の背景の理解
- 責任を取ること
- 暗黙知を持つこと
- レビューにおける役割
- AIが担うレビューは「作業（構文チェックなど）」
- 人が担うレビューは「判断（要件との整合性が取れているか）」
- 人間の最終防衛ライン
- これまでの経験から生まれる「なぜ必要かを問う力」
- 判断し、責任を取る力
これこそが、AI時代を生き抜く（クビにならない）エンジニアのコアスキルになる
まさに、Day1のDev x PMというテーマで感じた、実装者としてのエンジニアではなく、プロダクトの中でのエンジニアとしての価値、役割を現していると思いました。
AIにできない、いわゆるロングコンテキストの部分を人間が理解し、ショートコンテキストによって生まれたアウトプットを人間が判断する。
これはこのプロダクトにとって必要か？それを考えるためにはなぜ必要か、を遡る必要があり、経緯を踏まえて判断し、AIの作ったものを取り込んでいく。
その責任は人間にある。
これは前にも書いたのですが、これから必要になる人材は、この「責任を取る（取ろうとする）人」、ですね。
まとめ
さて、Day2のセミナーレポートは以上になります。
Day1もそうですが、話題はAI一色ですね。
AI活用はこの数年で当たり前の状態になり、その差はどんどん開いていきます。
こういったイベントに参加すると、各社各人、様々な活用をされていて、とても参考になりますね。
また、いくつかセッションを受けてみて見えてくる共通点なんかもあって、きっとそれがコアなものなんだろうな、とも思っています。
（このレポートは共通点にしぼってたりもします）
現時点での、AIの性能や特性を正しく理解し、その力をフルに発揮させるためにどういった使い方をするか。
また、そんな時代におけるエンジニアは、どうあるべきか。
普段感じていた事が、ここで一気に解像度が上がった気がします。
エンジニアに求められるのは、より本質的なものになっています。
課題解決能力と言ってもいいかもしれないですね。
課題解決のため、何が必要なのか、なぜ必要なのか。作り出したそれは、本当に課題解決できるものなのか。
AIを良き相棒とし、この時代を切り抜けていきましょう！