以下の内容はhttps://ozaki25.hatenadiary.jp/entry/2025/07/18/174518より取得しました。


「Developers Summit 2025 Summer(2日目)」に参加してきました

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

広木 大地さん[レクター]
宮田 大睿さん[エクスプラザ]
及部 敬雄さん[ホロラボ]
小林 真一朗さん[翔泳社]

  • 仕事のスピードを上げるためのマネジメントスキル
    • Cursorでプロジェクト管理
      • AIにスプリントを管理させる
      • バーンダウンチャート作らせたりとかも
    • AIがコードを書くとサイクルが短くなる
      • 1日スプリントが基本になる
      • スプリントが不要になる
      • より小さいチームでより多くのチームになる
    • SECIモデルがAIで加速する
      • 暗黙知->暗黙知だけは代替できない
      • 共同化を人が増やす
      • 人間が集まって体験する時間

AIネイティブ時代のソフトウェア開発、エンジニア組織、そしてエンジニアの未来

京和 崇行さん[カカクコム]

  • プロダクトとしてのソフトウェア
    • コンテンツ以外の要素も個別最適化
    • UIも最適に生成することへシフト
  • エンジニアと組織はどうなるか
    • エンジニアは不要にならない
    • 職種の統合と再編
      • PdMとエンジニア
      • エンジニアもフルスタックに
    • 管理業務はAIに代替
    • ビジョン/戦略を立てるのが人の役割
    • 最終的な意思決定

企業規模から考える技術戦略 ─ 創業ベンチャーCTOが丸井グループに転身して、何と闘ったか

巣籠 悠輔さん[マルイユナイト]

  • 丸井グループ
  • 開発効率が低い要因
    • システムのレガシー化
      • 20年以上刷新されてない
      • モノリスで並列な体制を組みづらい
      • テストに莫大な時間がかかる
    • システム/組織の巨大化
      • 全容を把握できてる人がいない
      • 関係者が多すぎて調整コストが高い
      • ビルド/デプロイに時間がかかる
    • ベンダー依存の開発組織
      • プロパーのエンジニアは0だった
      • 部署ごとに発注/納品のため全体最適化がされない
  • 体制を変える
    • 内製エンジニア組織
      • エンジニアの開発環境
        • 当たり前の開発環境を作るところから
      • エンジニア採用
    • まずはコードレビューをできる体制
      • 少ない人数でも技術的な意思決定に介在できるように
      • メンバーを増やして自分たちで開発するところを増やす
    • AI駆動開発をひたすらおす
  • システムを変える
    • ストラングラーパターンで切り出し
    • 切り出せるところを徐々に新システムへ
    • まずはクライアント部分を新システムへ
      • クラウド移行
      • S3に移行
      • デザインが必要なものはSTUDIOで作成
    • ドメインを切り出したら組織構造もそれに合わせたい

明治エコシステム - 大企業 x マルチプロダクトの戦略と実践 -

木下 寛大さん[Wellnize]

  • 明治の事業課題
  • 明治のエコシステム
    • 共通のID基盤
    • 共通のマーケティング基盤
      • ポイントとかクーポンとか
    • さまざまなデジタルサービスをそれらの上に
    • 独立したサービスがAPIで連携できるように
  • システムと組織の設計
    • システムの設計は分断の設計
      • どことどこに線を引いて分断させるか
    • 望ましいシステムの構造
      • ビジネスの成功につながること
      • それぞれの〜したいの単位で切る
    • 分断された組織の中ではそれぞれが自律的に
    • 分断された同士は対立が起きないように管理
      • 週次で意思決定会議
      • 重要なことは全てそこで共有し決める

ゼロから始めるSREの事業貢献 - 生成AIプラットフォームSREチームの立ち上げと現在地とこれから

中川 伸一さん[LayerX]
https://speakerdeck.com/shinyorke/starting-sre-from-day-one

  • 変わらないこと
    • オブザーバビリティ
      • 可視化/異常検知の効率化
    • トイルの削減
      • 退屈な作業の削減
    • インシデント対応
      • 障害発生の対応と透明感ある振り返り
    • インフラ信頼性向上
      • 高可用性/高スケーラブルな設計
    • コスト/運用最適化
  • 新しく加わったこと
    • 生成AI前提のアーキテクチャ
      • 利用超過を防ぐ設計
    • 新たなAIサービスとLLMモデルの対処
      • 新たなサービスによる要件変更への対応
    • ステークホルダー連携
      • デリバリー全般の説明/可視化
  • 生成AI時代のSRE
    • Cloud Native
    • Cloud Strategy
    • Management
      • テクニカルプロジェクトマネジメント
  • 1人目SREとして
    • チームを知る/チームに入る/チームを作る
    • 信頼を作る
      • 専門家として振る舞うのではなく1人のメンバーとして
    • スモールスタート
      • 成果が出るまで時間がかかるものは避ける
    • 壁を超えていく
      • SREだからみたいに壁を作らない
  • これから
    • 生成AIと共に
    • Bet AI



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

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