以下の内容はhttps://ozaki25.hatenadiary.jp/entry/2025/09/19/163446より取得しました。


「PRODUCT HISTORY CONFERENCE 2025」に参加してきました

AI時代の開発組織と技術戦略の最前線

長瀬 慶重さん(株式会社サイバーエージェント)

  • CyberAgentのAI活用
    • 2023年Copilotを日本で一番使っている会社
    • 2024年〜開発したコード量1.5倍でプルリク数も1.4倍
    • これからは支援ではなく共創
  • 3年後の未来予想
    • 開発生産性
      • 新規は3〜5倍
      • 既存は2〜3倍
    • ミドルクラスの開発業務の7〜8割はAIに置き換わる
  • AIドリブンというビジョン
    • 開発AIエージェントの導入
      • 年間4億投資
      • 4割以上のエンジニアがClaude Code使ってる
      • 7割以上のエンジニアが日常的に使ってる
    • 個人/チームのAI成熟度の評価
      • 個人の開発量
        • コード変更行数
      • チームの習熟度
        • 5段階のAI Coding Ladder
        • コードレベル/タスクレベル/プロジェクトレベル/仕様レベル/全フェーズAIで開発
        • 68のチェック項目
        • 現状は上位と下位の差が大きい
          • 下位を底上げしたい
    • 評価制度のアップデート
      • 会社として理想の振る舞いをしてる人に高い報酬を
      • ジュニア/ミドルは技術レベル
      • それ以上はどうインパクトを与えたか
      • 評価項目
        • 技術力:専門性/戦略性/業務遂行力
          • ここにAIを追加
        • マインド・行動力:オーナーシップ/フォロワーシップ
        • アウトプットからアウトカムさらにインパク
    • リスキリングセンター
    • 採用基準の引き上げ
      • 新卒採用も厳選
      • オーナーシップを持ててやりきれる人材
  • 変化対応力
    • ひとりひとりのオーナーシップ

AI Led Development: コードレビューなしでの開発フローの試みから見えた PdM とエンジニアの役割

島津 真人さん(株式会社Progate)

  • AIでコーディングが効率化されたがレビューが大変に
    • コードレビューをやめて自分でマージできるようにしてみた
  • コードレビューの役割
    • 品質担保
      • QAで担保する
    • 知見の共有
      • 同期の共有会で担保する
  • レビューなしをやってみて
    • デプロイの不安が高い
    • 共有会ではコンテキストを理解しきれないところも
    • ->レビューは再開することに
  • プルリク数やコミュニケーションの増加はなぜ起きてるか
    • エンジニア以外もコードを書いている
    • AIでサイクルを早められたが品質の担保が課題

LLMでソフトウェアエンジニアリングを改善 〜カウシェでの試み〜

池松 恭平さん(株式会社カウシェ)

  • AIコーディングの浸透に向けて
    • コードの90%をAIに生成
  • AI起点のプルリクエストを計測
    • ブランチ名に工夫をしたり識別できるように
    • AI起点にしにくそうなものを分析したり
  • フェーズ全体を見たときに
    • 開発スピードは上がっている
    • デプロイ頻度は変わってない
      • 体感は全体も効率化されてそうなのに
    • 不安定なユースケースで効率化したものを相殺している
      • 参考実装がない新規系は時間がかかってしまうものも
  • 課題のサイズを小さく管理する
    • 実装計画でプルリクエストの単位も定義してそれを読み込ませる
    • 小さい方が安定する
    • レビューもしやすい
    • 自動化や並列化の余地がありそう

AI時代におけるアトミックなプロダクト戦略について

吉田 拓真さん(株式会社スリーシェイク)

  • 各職種でAI活用
    • SRE系はCopilot
      • 領域的にまだフル活用は難しい
      • Terraformの設定作らせても手直し必要だったり
    • 非エンジニアがモック作成でCaludeCode
    • JVM系エンジニアはJunie + Code Assist
    • UI変更やバグフィックスなど小規模開発はDevin
      • 非エンジニアでもPR作れる
    • CSやPdMが問い合わせ調査をDevin
    • 汎用的な開発はGemini + Deep Research
    • 議事録や問い合わせからのissue生成をGeminiで
  • AI活用による変化
    • コミット量は2倍に
    • MVPの作成が高速化しPdMの負担低減
  • プロダクト戦略
    • AIで事業成長が加速するかというとそうでもない
      • 競合も同じように加速している
    • 従来はコンパウンド戦略とか
      • 立ち上げ2,3年を前提に大きめの事業を
    • 今後は3〜6ヶ月で立ち上げできるような事業を並列で
      • イデアの仮説検証を高速化する
      • 少人数で取り組む
      • QA(動作確認)に力を入れる
        • コードレビューなしでのマージも

AI時代の伴走者 ― デザインエージェンシーの新たな共創のかたち

小山 直樹さん(コンセント)
黒坂 晋さん(コンセント)
森部 綾子さん(株式会社YOUTRUST)

  • AI時代の共創
    • デザインとコンテキストをつなぐ
    • デザインをAIが理解できるように翻訳
    • 画像でもAIは読めるがサイズが大きくなる
    • テキストで伝えられるようにする必要がある
  • デザインエージェンシーができること
    • バウンダリーオブジェクトとして
    • 外からの立場として出せる意見
  • AI時代のプロダクト開発
    • 人が作って人が使うということは続く
    • アウトプットまでの過程にどう意味をもたせるか

デザイナーが挑むAI新規事業—学びと強み

角野 敦史さん(株式会社グッドパッチ)

  • デザイナーによる新規事業
    • 今まではクライアントワーク中心
      • 課題を解いていくことでデザインの力を照明
      • これからはHR領域とAI領域にも注力
    • デザイナーならでは強み
      • 顧客視点の専門性の高さ
      • 思考と実行を両立してアイデアを具現化するまでできる
      • 仮説検証を繰り返す思考の強さ
  • AIを活用したデザインプロセス
    • 従来のデザインプロセス
      • problem - solution - development
    • with AI
      • バイブコーディングでプロトタイプの実装/検証
        • Dify/v0など
      • 課題に対する仮説検証のスピードが速まる
      • problem & solution - development
      • 課題を出したあとすぐプロトタイプまでいける
        • プロトタイプの高速化/並列化
  • AI時代のデザイナー
    • AIがデザインを作ることにはなるかもしれない
    • 事業づくりにデザイナーは必要
    • デザインスキルを持った人の可能性が広がる

データを構造化し、大きな流れを作る ― AI価値最大化のプロダクトマネジメント

川瀬 圭亮さん(Sansan株式会社)
https://speakerdeck.com/sansantech/250919-2

  • データの流れ
    • AI活用のためにデータの質と量に加えて流れも重要な要素
    • データが機能/プロダクト間を流れるようにする
  • データの構造化
    • いいデータがあっても構造化されてないと使いこなせない
    • データを意味ある情報に変換して活用可能にする
    • ニーズに合ったピンポイントなデータを出せるようにする
  • どのように流れと構造化を作るか
    • データが溜まるような設計をする
      • 価値を提供しながら自然とたまるような設計
      • 複数プロダクト/機能でも成り立つように
    • どのタイミングでデータの形式を揃えるか設計する
      • 何も考えずに単にためていくだけではダメ
    • データを入力する行為自体が利用者のメリットになる体験設計

AI時代、変化する役割 。 3つの視点から未来を描く〜プロダクトマネジメント×デザイン×テック〜

兼原 佑汰さん(株式会社Muture)
莇 大介さん(株式会社Muture)
巣籠 悠輔さん(株式会社マルイユナイト)

  • プロダクト開発の変化
    • 昔は依頼と納品の関係でできたものを渡す
    • 今は検証と適用を繰り返して使ってもらえるものを作っていく
    • 今後は使う人が自ら作っていく
  • 開発の変化
    • ボトルネックが書くから読むへ
      • 従来の実装者はレビュアーやマネージャーへ
    • レビューは自分がやるのでクオリティは自分のレベルまでになる
    • AIを使ったアウトプットは自分にとってはインプットになる
      • 学びの場面ではインプットをしたいかアウトプットしたいか意識した方がいい
  • デザイナーの変化
    • デザイナーがどれだけAIを使ってるか
      • コア業務での活用は30%程度
      • エンジニアは60%程度
    • それっぽいものが大量にできてしまう
      • 作業のゴール定義がコーディングと違って曖昧なのでAIを使いこなすのが難しい
      • 外れ値のようなものが必要だがAIにはなかなか出せない
    • AIの扱い方
      • AIがとれない情報をインプットとして人が与える
      • AIが正解っぽいのを固めてくれる
      • デザイナーが外側に広げる
  • 職種の区分け
    • AI以前につけられた職種のラベルにとらわれないほうがいい
    • AIでやれる幅が広がった



以上の内容はhttps://ozaki25.hatenadiary.jp/entry/2025/09/19/163446より取得しました。
このページはhttp://font.textar.tv/のウェブフォントを使用してます

不具合報告/要望等はこちらへお願いします。
モバイルやる夫Viewer Ver0.14