以下の内容はhttps://ozaki25.hatenadiary.jp/entry/2025/11/14/175655より取得しました。


「Agile Japan 2025(2日目)」に参加してきました

感想

  • 個人的に原田さんの講演の「本当に何も変わっていないのか」というところがささりました
    • 昔社内向けの啓蒙をしてた頃によくそんなことを思っていた
    • 数年経った今をみるとちゃんと当時も仲間はいて今につながっていた

AI時代のソフトウェア開発を考える(2025/11版)

和田 卓人さん

  • VibeCodingの誕生
    • 2025/2/3のOpenAI共同創業者のポスト
    • 2025/2/4のTim OʼReillyの投稿
      • The End of Programming as We Know It
    • 2025/5にCloudCodeのMaxプランで定額制に
      • 投機的プログラミングの世界に
    • 機能的合成のみを検証することでレビューを省略しスループットを最大化
  • 2025年の壁
    • 老朽化や担い手の不足で保守不能なシステムが大量に出てくると言われていた
    • VibeCordingでさらに保守が難しいコードを量産するようになった
    • 時間が立って規模が大きくなった時に起きていた問題が短時間で起きるようになった
      • 問題の構造は変わらず顕在化するまでの時間が早まった
      • VibeCodingを続けると数日で問題が起きる
  • ソフトウェア開発者にとってのVibeCording
    • 自分用に自分で作るケースでは革新的
      • 誰かに頼まないとできなかったことが自分でできるようになった
    • 人のためのソフトウェア開発ではそうではない
      • VibeCodingではなくAgenticCoding
      • 15分でウォータフォールを回すみたいな感じ
  • AIとの協業
    • AIと伴走
    • AIに委託
      • 任せて並列に
      • 圧倒的に速い
      • 状況把握の度合いが低くレビューが課題
      • 決定論
      • 非常にスケールする
    • 適材適所で使い分ける
      • コアドメインかどうかとロジックの複雑さ
      • コアで複雑なところは伴走
      • 複雑でないところは委託
  • AIとの伴走のしかた
    • 仕様はAIと対話して作ると良い
      • 人だけが頑張る必要はない
    • 支援するソフトウェアも出てきた
      • Kiroとかspec-kitとか
    • 仕様を議論したらDesignDocやADRとしてAIに保存してもらう
      • ADRなどの一般的な用語を使えばAIはそれを理解してるのでそれに従ってまとめてくれる
      • 浸透しているパターン名を使うのが大切
    • 設計書からタスクリストを生成
    • 各タスクをサブタスクに分割しTDDで進めてもらう
    • TDDでやってもらうことでレビュー不能な量が一度に出てくることを防げる?
  • AgenticCordingの概念
    • 宣言的に理想的な状態を定義しそれを実現してもらうという仕組み
      • Reconciliation Loop
      • ReactやKubernetesのような考え方
  • AIとのコミュニケーション
    • 定性的な指示だとうまくいかない
    • ツールやライブラリもAIを通して使われることを意識しないといけない
    • 自動テストの重要性
      • 自動テストがAIが正しいと判断する根拠になる
    • リポジトリ管理
      • 関連するものが近くにある方がいい
      • モノレポ
      • ドキュメントもプレーンテキストでコードの近くに
    • 振る舞いの健康と構造の変更を分ける
      • 前者は詳細なレビューが必要
      • 後者は振る舞いが変わってなければ詳細に見なくてもいい

アジャイルコーチングの事例 - あなたのRebootは?

天野 勝さん(株式会社永和システムマネジメント)
一條 凌佑さん(株式会社永和システムマネジメント)

  • 進んでいるようで進んでいないチーム
    • リリースまでいけたけどチームとしての成果を感じられていない
  • 振り返りのワークショップ
    • タイムラインx感情曲線
    • SailBoat
      • 次のゴール/自分のチーム/進みを止めるもの/リスク/追い風
      • 問題vs私たい
    • アクションを整理しタスク化
  • 新チーム組成で合宿

1%のご近所さんが心の支えに!〜アジャイル社内普及ご近所さんマップを作ろう〜

原田 聡さん(コニカミノルタ株式会社)

  • 大規模な製造業の体制
    • 人が多く職種も組織も多い
    • 横断テーマは任命制で時限のある集まり
      • 継続的かつ主体性のある枠組みも必要
  • AgileCoE
    • 正式に会社に認められた存在
    • 時限性のある任命制
  • アジャイルコミュニティ
    • AgileCoEが運営
    • 無期限で主体的に加入脱退できる
  • 活動の限界と学び
    • 各所に働きかけても何も変わらないと感じてしまう場面
    • ご近所さんを探せ
  • 本当に何も変わってないのか
    • 変化が小さくて観測しにくいだけのことも
    • 数値で観測できるとも限らない
    • 正統的周辺参加
      • 観察者(周辺) - 見習い(時折) - エキスパート(コアグループ)
      • 人をマッピングしていくとご近所さんマップができる
    • 小さな変化が大きな変化につながっていく

中部電力ミライズにおけるアジャイル先駆けプロジェクトが挑む再出発

市場 愛望さん(中部電力ミライズ株式会社)
斉藤 りんさん(株式会社MSOL Digital)
鍾涛さん(株式会社MSOL Digital)

  • チームの課題
    • ビジョンの希薄化
    • 技術負債
    • サイロ化
  • WhatではなくWhyを共有
  • 技術負債に向き合う環境
    • 負債が溜まってモチベーションが下がったり非効率化して負のサイクル
    • 対処するにしても残業してやるしかなかった
    • バックログに作業を入れて明確に取り組めるように
  • サイロ化解消
    • 開発が2チームで独立
    • バックログを1つに統合
    • 上級者と初級者でモブワーク/ペアワーク
    • アウトプットを共有し合うことでのシナジー

大企業の壁を突破せよ!一般社員が仕掛けるアジャイル革命

中村 孝大さん(三菱電機株式会社)
玉置 健太さん(三菱電機株式会社)
乙部 達生さん(三菱電機株式会社)

  • アジャイル文化の取り入れ
    • 新卒でアジャイル開発やってる現場 -> ウォータフォールな現場へ異動
    • アジャイルと言われて抵抗感を持っている人が多い環境
      • どう文化を変えていくか
      • アジャイルという言葉を使わずに変化を起こしていく
    • 組織の現状
      • 情報共有の場がない
      • 横のつながりが薄い
      • 顧客志向の欠如
    • 取り組み
      • TODOリスト(かんばん)
        • 自分が使い始めて見せていく
      • ふりかえり
        • いろいろな手法をやってみる
        • ふりかえりのグランドルールの策定
  • 新人の視点から
    • スクラムチームに入って
      • 技術トークについていけなかったりアジャイル用語もわからない
      • 作業の停滞が露呈する
      • 見積もりが難しい
    • どうしたか
      • とにかく喋って - 振り返って - 改善して - 共有する のサイクル
      • 上手くいかないことを共有する方が結果的に上手くいく環境

ソフトウェア開発現代史: 55%が変化に備えていない現実 ─ AI支援型開発時代のReboot Japan

高橋 裕之さん(ファインディ株式会社)
https://speakerdeck.com/takabow/sohutoueakai-fa-xian-dai-shi-55-percent-gabian-hua-nibei-eteinaixian-shi-aizhi-yuan-xing-kai-fa-shi-dai-noreboot-japan-number-agilejapan

  • ソフトウェア現代史
    • 1960年代日本のものづくりは品質が武器で世界で人気
      • 50年経ってビックテックと呼ばれるようなのは海外の企業
    • 1970年代ウォータフォールが広まる
      • 政府機関が要件に
    • 1980年前後にウォータフォールを改善する手法
      • 日本の製造業を研究しつくしソフトウェアへの応用
    • 1998年インクリメンタルな開発(RUP/ラショナルユニファイドプロセス)
    • 1990年代リスクを小さく刻む文化
    • 2000年代ウォータフォールはアメリカでweb系/スタートアップで使われなくなるが日本は続ける
      • 日本ではソフトウェアを製造業と同じように扱おうとしていた
      • リスク文化の違い(失敗する前提か)

変われない組織で、変わり続けることを選んだ SI企業で続けてきた、現場と管理職の7年間──小さな実践が、組織を動かし始めた

壽山 雄己さん(株式会社テクノプロジェクト)
松本 俊さん(株式会社テクノプロジェクト)

  • 受託の開発
    • 発注側と同じ方向を見て進めるのが難しかった
    • プロジェクトが終わると解散してしまう
    • 「なぜ作るのか」から切り離されてしまう
  • 制約の中でアジャイルを始める
    • ウォータフォール前提の制度
    • リリース日が決まってる
    • できることの中での積み重ねが変化につながる
    • 管理側もどうやったら制度を活かせるかを考え続ける
  • 顧客と地理的距離の離れた案件
    • オンラインでのやり取りが基本
    • 対面でのユーザーストーリーマッピングで共通の認識と信頼を作っていく
      • 一緒に考えていくことが大切
    • その後も同じ目的を見た会話ができるようになった

MUFG×大規模アジャイル 2年目の挑戦と現在地

菅沼 拓也さん(株式会社三菱UFJ銀行)
片山 裕介さん(株式会社三菱UFJ銀行)
大谷 明弘さん(株式会社三菱UFJ銀行)
小杉 実さん(三菱UFJインフォメーションテクノロジー株式会社)
朱田 翼さん(三菱UFJインフォメーションテクノロジー株式会社)

  • スピード改革
    • アジャイルの考え方を適用し組織風土をアップデート
    • 表層だけでなく深層も
    • 価値の生み出し方/仕事の進め方/組織/志向
  • アジャイル変革推進室を2025/1に立ち上げ
    • ITだけでなくビジネス領域も含めた横断チーム
    • プロジェクトとは呼ばない
      • 終りがあるものではない
      • 実践領域と呼んでる
  • これまでの取り組み
    • アンケート
      • 顧客への価値をより早くより大きく
      • 環境変化の先を行く
      • エンゲージメント向上
    • 概ねポジティブな回答
  • 事例
    • 当初見積もり17ヶ月の案件を8ヶ月でリリース
    • MVPを考えて必須なところだけを先に出していくという文化の始まり

あなたのアジャイルがうまくいかない10の理由〜“Reboot”のための処方箋〜

森實 繁樹さん(株式会社レッドジャーニー)
https://www.docswell.com/s/samuraiRed/5WMQYG-2025-11-13-205802

  • プロジェクトマネジメントがスクラムイベントに組み込まれていない
    • プロジェクト計画をとばしてスプリントイベントを実行してないか
  • 既存ガバナンスを満たす設計になっていない
    • 開発標準やISMSなどは必要なもの
    • それを突破するようなアジャイルの進め方をしていかないと
    • PMBOKを何も意識しないでやってるような現場は危険
  • チーム全員がロールの帽子をかぶりわけるべきことを分かってない
    • SMと開発者兼務してる人が〜とかだけではない
    • どのロールだろうが全員がいろんな視点で考えないといけない
  • 権限の委譲単位は小さくて良いことを分かってない
    • 小さく委譲していくことで受け取る側のハードルが下がる
    • 移譲と委譲の違い
  • 振り返りはマイナスを改善していくことだけではない
    • ProblemからのTryも大事だけどKeepも大事
    • 言語化することで再現性が生まれてよいシナジーができる
  • チームで決めるということは責任者を置かないということではない
    • チームに与えられてるのは実行責任
    • 説明責任は責任者が誰か立つべき
    • チームでやるんだからと丸め込みすぎるのはよくない
  • 専門職にも越境するマインドが必要と分かってない
    • 特定領域が得意な人でも協調して働ける人がいい
    • 専門性しか持たない偏った人ではダメ
    • 他のロールが何を考えてるか知ろうとすることが必要
  • プロダクトのマネジメントにラインのマネジメントを持ち込んではいけない
    • プロダクトとは異なる職能ごとの組織がいるケース
    • 職能の組織でのトップダウンが割って入るのは良くない
  • POはミニCEOなわけではない
  • 生産性の高さとビジネスの成功は比例しない
    • アウトプット - アウトカム - インパク
    • アウトカムの計測は長い目で見ないといけないから難しい
    • アウトプットの目標を高めたところでアウトカムが高まるとは限らない

Agile Japanで描くAI時代の私たち〜16年の軌跡からwith AIへのアップデート

平鍋 健児さん(永和システムマネジメント)
https://speakerdeck.com/hiranabe/phronetic-team-with-ai-agile-japan-2025-closing

  • エクストリームプログラミングの本
    • 社会変革と最初に書いてある
  • 日本でアジャイルがなかなか定着しなかった
  • アジャイルは日本でできるのか
    • 技術的なことは一人でもできる
    • リーダーのプロジェクトなら工夫してチームでもできる
    • 契約やリリースなどが絡んでくると難しくなる
    • 見積書はどう書くのか
      • 工程ごとに出せと言われる
  • 2010年
    • 野中先生が登壇
    • 考える人と演る人を分けるな
  • 2011年
    • Fearless Changeの人が登壇
    • Personal Touch(個人的な気持ち)
    • Emotional Connection(感情のつながり)
  • 2012年
  • 変われたかのか
    • 変わった、変えた
    • でもまだ旅の途中
    • いつでも始めることが大事
  • アジャイルとAIと人
    • アジャイルは人の変化に根ざしてる
      • 数十年の時間で普及してきた
    • 人の変化は遅いし組織の変化も遅い
    • AIは加速度的に世界を変える
  • スクラムと野中先生
    • 最初のスクラムの本
      • The new new product development game
      • バトンパスしてリレーするんじゃなくてみんなでジグザグしながらゴールを目指す
    • SECIモデル
      • 暗黙知形式知
      • 共同化 - 表出化 - 連結化 - 内面化
      • やってみて分かったことを言葉にして馴染んでいく
  • AI as a Team Member
    • AIはアルゴリズムや設計パターンには強い
    • 特定チームのローカルな知識に弱い
    • スクラムのオープンなプロセスにAIを乗せられれば人とわかりあえる?
      • コンテキストとしてAIに知識を渡す
    • 一般的な知識/プロダクト特有の知識/チーム運営の知識
      • 一般的はAIに任せられる
      • 残りの2つの文脈的な知識は与える
        • チームのルールや人の性格なども
    • 形式知/形式知はAIの得意なところ
    • 形式知/暗黙知暗黙知/形式知は今は境界
    • 暗黙知/暗黙知は人がやるところ



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

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