二日目は昨日のパスが使えるので、受付は一瞬。

空調は昨日より効きすぎてなかったけど寒い瞬間はあった。

AIによるエンジニア総プレイングマネージャー時代の思考法～EM×プロダクト開発×アジャイル開発の交差点～

AIエージェントを前提とした時代に開発を進めるうえで重要なマネジメントの視点と技術を知り明日からスキルを伸ばせるようにする

• 仕事のスピードを上げるためのマネジメントスキル

  • コードとドキュメントを同じリポジトリで管理する
    • AIがスプリントの計画から管理まで実施
  • 開発サイクルが短くなる
    • 1日スプリントが基本になっていく
  • より小さなチーム、多くのチームへ
    • 6人x2チームが（1〜3人+AI）x5チームに
      • 人間の人数は変わっていない
    • マネジメントする人間がボトルネックになっていく

• 協働のためのマネジメントスキル

  • SECIモデル
    • 共同化以外（形式知の部分）はデジタルによる支援が可能
  • 真の情報をどう拾って意思決定につなげていくか

• 「マネジメント」のスキルをどう磨くか

  • 今までのやり方が通じないことを認識する
    • 25年前のアジャイル宣言にも対応できていない組織がまだある中でできるのか
    • アジャイルは大前提
  • 枠組みを変えたときにどうするかを考える
  • 磨こうと思うためにはどう考えるか
    • AIで短縮されて空いた時間を活用する

「バグに気づけるなら直せばいいじゃない」──QAエンジニアがAIで開発エンジニア化した話

• ソフトウェア品質を確保するためのアプローチ

  • 開発工程
    • コードレビュー、静的解析、自動テスト
  • テスト工程
    • ユーザビリティテスト、QA

• 開発とQAの分業

  • 意見が対立することも・・

• 開発：そこまで気付けるなら直して

• QA：こちらで修正できたら楽なのに

• QAは発見に価値をおき、開発は修正に注力

• QAエンジニアがAIの力を借りて実装できれば、品質向上と効率化ができるのでは？

• RooCode x Claude Sonnet 4

• Vibe Coding

  • 従来1日〜3日が10〜30分で発見から修正まで完了

• 効果測定

  • RailsからNext.jsへのリプレイス
    • 52.19%生産性向上
    • 追加コスト21万円（Claude API費用）

• 新機能追加フロー

  • 要件定義作成、機能仕様作成、詳細設計作成、実装
  • 各工程でのレビューが重要

• 機能修正フロー

  • チケット確認、修正仕様書作成、実装

• ポイント

  • AIのドキュメントレビューを行う
  • AIの方向性に迷いが出たら、やり直す
  • AIの知っている情報に委ねていく
    • ハルシネーションを避ける
  • 「これは自分が採用したコードだから」という姿勢を持つ

• QAエンジニアと開発エンジニアの垣根が曖昧になってくる。AIをパートナーにできる人材こそが、これからのエンジニア

データ駆動経営の道しるべ：プロダクト開発指標の戦略的活用法

• 指標との向き合い方

  • Effort、Outputは計測しやすいが本来の目的を歪めやすい（Kent Beckの講演から）
    • 計測すること自体は良い
  • Impact、Outcomeを観測する

• 事業目標を把握する

  • Effort、OutputからImpactにつなげることが大切
  • 自分たちが開発しているものの事業目標を改めて確認する

• アウトカムを発見する

  • ディスカバリー手法

• 事業目標（Impaact）とアウトカムを連結

• 確実なアウトカムを発見することは困難

  • 正解がわからないことぉ受け入れ、仮説検証サイクルを高速で回すことが大切

• 優先度を決める

  • 仮説検証を回す際、優先度をつける

• 優先度の算出方法

  • RICEスコア
  • ICEスコア
  • 狩野モデル
  • TAM/SAM/SOM

• 工数を見積もる

  • 優先度を決めるためには、工数が必要
    • どんなに素晴らしい施策でも工数が大きすぎると実現困難

• ソフトウェア開発の工数見積は難しい

  • 毎回新しいものを作るので過去の実績が使いづらい
  • 新しい技術などやってみないとわからない事が多い
  • スキルのばらつきなど人に依存する要素が大きい
  • 計画外の作業が発生することが多い

• 工数見積の精度向上

  • MVPを意識し、スコープを絞る
  • ずれる前提で定期的に再見積もりをする

• 素早くデリバリーする

  • 優先度が高いものからデリバリーしていく
    • アウトカムごとの状況を可視化する
  • フロー効率を最大化する
  • 同時に開発できる数を増やす
    • リソースを増やす
  • 仮説検証サイクルを回せているか
    • アジャイル開発の予実を可視化
  • デリバリー能力を可視化
    • Dora Core Model
  • アウトプット量・スピードを可視化
    • 気づきを得るために使い、プレッシャーを掛けない
  • 機能開発、改善、運用の割合を可視化
    • 技術的負債、トイル、ミーティング
    • 可視化することで把握する
  • 開発体制の最適化
    • ダイナミックリチーミング
    • チームトポロジー

• AI時代に見るべき開発指標

  • Devin導入前5PR/日→7.7PR/日
  • 利用率の可視化、分析
  • PRはAIラベルを付けて可視化
  • モニタリングが必要
    • スピード・量
    • レビュー負荷
  • 指標は今までと同じ

実際の開発案件から見えてきた AI Agentの限界と現場での実践知

キーメッセージ：人

• AI Ageent活用の現状と期待感

  • 複雑な環境やゴールに対して適用しながらタスクを自律的に実行する人工知能システム

• 事例調査AIエージェント

  • 課題：新規ビジネス創出のための事例調査工数
  • ゴール：AIエージェントに夜う自動化
  • 限界：網羅性・正確性が担保できなかった
    • 該当サイトがヒットしない、誤ったサイトの引用
  • 対処法：人のワークフロー細分化、処理フローとして組む

• 安全性評価AIエージェント

  • 課題：製品の安全性の評価をLLMを用いて支援
  • ゴール：複数のAIエージェントが評価結果を出すマルチエージェントシステムの構築
  • 限界：LLMによるスコアの基準が曖昧
    • 評価基準の一貫性の欠如、類似ケースで異なるスコア結果
      • 説明責任が果たせない
  • 対処法：人のスコア基準の細分化・明確化

• ナレッジ検索AIエージェント

  • 課題：質問対応のレスポンス時間
  • ゴール：質・スピードを担保した回答
  • 限界：AI検索情報は二次情報中心
  • 対処法：一次情報（人の経験値など）を蓄積するシステムを整備・構築

• 共通課題と現場での実践知

  • AIエージェントの限界の本質
    • 人が対処する複雑な現実問題にそのままでは対応できない
  • 人のタスク細分化・再現、人の判断基準の明確化、人による所感の把握

• LLMの強み＝自由な出力、弱み＝制御が難しい

  • どのように制御するのかがこれから大事

行政の現場主導で『なんとかする』生成AIプラットフォーム - 等身大の立ち上げストーリー

行政現場でのプロダクト開発

• 従来のやり方：BUY（買う、外注する）

  • BUY→BUILD（内製化）
    • 今は過渡期

• GovTech（読み：がぶてっく）

• 生成AIプラットフォーム

  • BUY&BUILDのハイブリッド

• なんとかしたこと

  • ゼロから仕事を作る
  • 仲間を見つける
  • なんとかしてもらう
  • チームワークでなんとかする

• なんとかする≠なんとかなっている

• 心配事、課題

  • 関心を持ってくれる人の増え方が急すぎ
  • 生成AIへの期待値調整が難しい
  • 将来見積もりが難しすぎる

• みんなで「なんとかする」しかない

  • 結局誰かがやらないといけないなら、自分がやる

• なんとかするために「100マイルを完走するためのセオリー」のススメ

  • ハプニングは醍醐味
    • リスクや大変さはあらかじめ織り込んでおく
  • ポジティブ変換機
    • どうせ大変なんで楽しくやる
  • アリの一撃
    • ちょっとした油断が後で大ダメージになる

• 完走するまでの道のりは長い

• 良いことも大変なこともある。後半は基本つらい。

• 無事に完走できれば最高

• もしレース（事業）が失敗に終わったとしても、スタートラインに立ったことには意味がある、と思いたい

SQLアンチパターン第2版 ―データベースプログラミングで陥りがちな失敗とその対策

https://speakerdeck.com/twada/intro-to-sql-antipatterns-2nd

• Vibe CodingとDBまわりの相性

  • 失敗するとリカバリが難しい

• 初版から12年たっての第2版

  • 48ページ増
  • 3つの章と15のミニアンチパターンが追加、1つの章削除
  • コードサンプルがPHPからPythonに変更

• 第1部 DB論理設計のアンチパターン

  • SQLのアンチパターンのみではない
  • テーブルや列、リレーションの設計など

• 第2部 物理設計のアンチパターン

  • テーブルやインデックスの定義、データ型の決定など

• 第3部 クエリのアンチパターン

  • SELECT、UPDATE、DELETEなど

• 第4部 アプリケーション開発のアンチパターン

  • アプリケーションでSQLを用いる方法
  • 25章が追加された
    • ストアドプロシージャに関するアンチパターン

• 第5部 外部キーのミニアンチパターン

• 付録 正規化のルール

• パターンは名前をつけて共通認識することが大事

  • パターン名を用いることで、コンテキストの圧縮ができる

• アンチパターンとは、良かれと思って用いられた方法が、裏目に出てしまうもの

• 愚者は経験に学び、賢者は歴史に学ぶ（ビスマルク）

• 社内読書会の題材に最適

  • 各章が独立しているので、どこからでも参加できる（都合がつかなくて1回欠席しても再参加しやすい）
  • 社内ならではの失敗の共有ができる

脱属人化・ブラックボックス化！チーム全体でインフラを理解する IaC × Observability 入門編

• インフラ運用の課題

  • ウォーターフォールからアジャイルへの変化
    • スピードと複雑化
  • 非効率な運用が続き、変化に柔軟に対応しづらい

• 課題解決のためのアプローチ

  • IaCで自動化：Terraform
  • Observabilityで可視化：DATADOG

• 導入ステップ

  • クラウドネイティブ成熟モデルを踏まえた導入はやりにくい
    • 共通の3ステップに再整理する

• Step1：導入の一歩

  • まず使ってみる
  • 少人数で頑張る

• Step2：チーム展開

  • 共通基盤化を目指す
  • チーム間の成熟度の差がボトルネックになることも

• Step3：全社展開・最適化

  • より高度な運用に向けた取り組み

全方位からソフトウェアをテストしよう！訳者とともに学ぶ、フルスタックテスティングの考え方

• フルスタックテスティング

  • 複数のテストを補完的に組み合わせて、あらゆる側面から品質を検証するための技術・戦略を、体系的に学べる骨太なガイドブック
  • 原著は2022年
  • コラムで現在にアップデートした内容も

• フルスタックエンジニアのイメージ

• フルスタックテスティングは積み重ねというよりは全方位

• ソフトウェアテストにおけるフルスタックとは

  • どのテスト対象についても共通するものがわかって適用できる人
  • いろんな引き出しがあること
    • どうやってテストの切り口を見つけられるか

• 1ヶ月のレビュー期間で、レビューコメント数1826件

• レビューの過程で得られた気付き

  • 専門家に依頼して本当に良かった
    • 日本ではどうなのかといったコメント
    • 用語の統一
      • オブザーバビリティはオブザーバビリティ、アベイラビリティは可用性、など
  • 著者の意見が強めに出ている本
    • レビューコメントとの折衷点を探る
      • 例）モバイルテストにシミュレーターを使うなんてありえない