https://ozaki25.hatenadiary.jp/entry/2026/03/07/185014

2026/3/7
https://www.scrumfestfukuoka.org/

初めて言語化できた、非開発業務へのアジャイル適用の意義 -営業支援ダッシュボード構築の実例から-

Moe Marumotoさん(日本生命保険相互会社)
Yui Tachikawaさん(日本生命保険相互会社)

2024年頃日本生命本体でアジャイル推進開始
- ニッセイ情報テクノロジーでは実績あり
- レッドジャーニーの市谷さんが支援に入ったり
まずは日々の業務にアジャイル適用
- 2週間のスプリント
- カンバンでタスク管理
- スクラムイベント
- 短いサイクルを回すことで変化があった
- 外から見た人によさを伝えるのは大変だった
模擬開発でやってみた
- 営業支援のダッシュボードをTableauで作る
- 構成
  - 開発
    - IT部門で採用された人たち
  - PO
    - 現場経験はない
  - ステークホルダー
    - 現場経験豊富なベテラン
    - 忙しい
  - 開発とPOは拠点が離れてる
  - ステークホルダーに気軽に聞ける感じではない
  - ビジネス側の情報が後からITに流れてくる
- 試したこと
  - プルトタイプをベースに会話
  - 短いサイクルで見せていく
- 進めていく中での悩み
  - アジャイル的に正しいのか
  - SMとしてどうやるべきか
  - チームとして何が課題でどう変えていくか
実開発へ適用
- ハピネスナビ
2026/4アジャイルCoE設立
- ルールの整備
- 案件拡大

AI駆動で爆速開発した結果、スクラムを形骸化させた話〜「教会を建てる」目的を忘れたレンガ職人の反省記〜

Kenta Uwagawaさん

受託時代の成功体験
- お客様の期待を超えることが正義だった
- 圧倒的当事者意識で
- これがあれば便利を形にしていき感謝してもらう
AIで作れるようになった
- AIと対話して進めていける
- 動くものがどんどんできる
- ただ、それで何が解決するのかというものができてしまった
- 誰も日常的に使わないきれいな何か
AI駆動開発での対話の省略
- 考えて実装するのサイクルが超高速に
- 超短期間のスプリントを回してるような
- 今まで大事にしていたイベントが省略される
- 教会をたてる感覚ではなく高速にレンガを積む作業になっていた
AI時代だからこそスクラムイベントを再定義
- AI駆動とスクラムの両輪
- 開発は拘束してるがサイクルは変わらない
- 新しい高速なスクラムイベントの再定義

System Fixer-組織へシフトレフトするQAの或り方

やまずんさん(testingOsaka)
https://www.docswell.com/s/55_ymzn/ZPR8G1-scrumfukuoka2026

System Fixerという動き方
- 組織や仕組みの関係性としてのシステム
- 単に戻すのではなく新しく組み直す
事例
- クレーム対応のチェックリスト
  - そのルールは昔からあって誰がオーナーかもわからない
  - その仕組を変えに行く
- 部門を跨いだ問題
  - ある部門が認定しないと問題として扱われない
  - それが問題かどうか判定するのが属人化していて明白でない
  - アホになって何もわからないという場面
  - 現行踏襲したうえで明確さを提案していく
手段を選ばずにシステムを再構築していく
- でも苛烈になりすぎると自分自身も破綻していく
- 自分の道徳心を大事にして照らし合わせて

モブプログラミング再入門 ― AI時代のチーム設計 ―

Takao Oyobeさん(HoloLab Inc.)
https://speakerdeck.com/takaking22/a-re-introduction-of-mob-programming

AIによってボトルネックが人の理解に移った
AI前後での変化
- イメージは、コーディングフェーズが純減してその分はやくなると想定されがち
- 実態は、AIに任せる前後のフェーズでAIのための作業が増えた
  - 仕様書を作りながらではダメでしっかり理解し作らないといけない
  - AIを動かした人にチェックがあるしその後のレビューも今まで通りある
SECIモデル
- 暗黙知と形式知
- 共同化 - 表出化 - 結合化 - 内面化
- 形式知になってる結合化はAIによる代替可
- 表出化と内縁可はAIによる支援可能
- 暗黙知の共同化はまだ人のやること
AIを使っても人が時間をかけているところ
- 暗黙知-暗黙知の人がやるところ
- 今までもコードを書くところがボトルネックになっていたことはなかった
- 昨今抱える問題はAIによって新しく出てきたわけではない
モブプログラミング
- 同じ仕事を同じ時間に同じ空間で同じ環境で
- ドライバー：キーボードをたたく
- ナビゲーター：問題を考える
- 交代しながら進める
- ドライバーが考えて作業するのを見る取り組みではない
- プログラミング以外でやってもいい
  - モビング
  - モブワーク
- 分担作業との比較
  - 分担するための同期する作業も発生している
  - 設計とかレビューとか
  - 認識連れがあったら手戻りもある
  - 誰がやっても同じ結果になるような単純なものならこっちでも
- モブプロは常に同期しながら進める
AI時代のチーム
- チームが2,3人に小規模化
- クロスファンクショナルに
- モブプロがやりやすい環境
  - 人数が少ないから全員の時間を使うという抵抗がちいさくなる
  - いるメンバーで完結できるようになってきている
- 仕事の中心が開発から理解へ
  - 理解したいのは個人ではなくチーム
  - 一緒にやることで暗黙知も形式知もまとめて共有できる
AIで空いた時間に何をするか
- AIの結果を待ってる時
- AIによって早く終わった時
- 空いた時間で何をするかを空いた時間にチームで考えて実行する
  - チームとして判断し実行していくこと

Syncでつながるアジャイル ― 部署の壁を越えて進化し続けるチームづくり

Hiromi Takahashiさん(Mitsubishi UFJ Information Technology, Ltd.)
https://speakerdeck.com/muit/agile-practices-connecting-and-syncing-beyond-departmental-boundaries

金融システム
- システムのライフサイクルが長い
- データのライフサイクルも長いから
  - 住宅ローンが35年とか
  - 50年の社債ちか
- 銀行統合などの開発需要増に寄る対処
  - 内製では回らないので外注中心に
MUITでのアジャイル開発
- 2014年ころから始動
- 2021頃から大規模システムでも取り組むように
- 2025/2にMUFGでのアジャイル運営を開始
エンタープライズでのアジャイル
- 自己管理型の難しさ
  - POが決めたことをその上位層にひっくり返される
- 3ヶ月とかの長いスプリントに
  - 真の決定権を持った人の声で話してもらう
  - プラットフォームやセキュリティなどの関係者にも参加してもらう
  - その中で2週間サイクルでのチームの活動
アジャイル推進部署
- 採用や評価の見直し
- 研修の企画推進
- 開発プロセスなどのルール
  - 品質評価
  - 権限委譲
社内外コミュニティ
- 社内アジャイルコミュニティ
  - 毎週30分の意見交換/相談の場
- 部長層以上全員へのアジャイル研修
- アジャイルスクラム関連の外部イベントの参加推進
Respect(敬意)/Sync(同期)/Persistence(継続)

契約形態を超えた一体感！業務委託メンバーを巻き込むチームビルディングで自律したチームを創る

Kyohei Somaさん

チームの見えない壁
- 所属会社の異なるメンバーがいるチーム
- 沈黙する対面レビュー
  - 一部の人しか発言しない
  - 知識差で噛み合わない
チームビルディング
- チーム名を決める
  - これまではスクラムマスターの名前でxxさんチーム
- バリューズカード
  - 各人の価値観を知る
- 偶然の出会いを作る
  - 毎日ランダムに席替え
- 業務外でのコミュニケーション
  - チームでランチ
  - 飲み会
チームの変化
- 発言が増えた
- 雰囲気の変化を感じるようになった
学び
- チームの問題を発見分生起することの重要性
- 第三者視点で時間をとって考える

聖域を失う恐怖と向き合う - 恥をポジティブに受け入れるための考え方

Takehiro Nagashimaさん(TOKYOGAS)
https://speakerdeck.com/naga8naga/sheng-yu-woshi-ukong-bu-toxiang-kihe-u-chi-wopoziteibunishou-keru-rerutamenokao-efang

弱みを見せること
- 会話は解決できない問題をお互いに共有し共感し合うこと
- 登壇資料を作るのに苦労話や弱みを入れた方が仲間ができていく
- それがチームで動くことに役立っていく
「いくつになっても恥をかける人になる」
- 電通の人の本
- 責任を追わない限り恥を書くことはできない
- 自分で考えて責任をもってチャレンジできてる証拠
- 迷ったら恥ずかしい方を選ぶ
- 恥という感情をポジティブに受け止める
「嫌われる勇気」
- 人間の悩みは対人関係からくるもの
- 対人関係のゴールは共同体感覚
- 評価の軸を他者の目から貢献感/しょぞくかんへ変える
- 恥と思っても自分は共同体の一員で何か役に立ってる
恥をかく恐怖はある
- 共感やつながりを生むというポジティブな面に来づけるようになった

AI×スクラムの「新・セオリー」を探す旅 — AI推進派の二人が直面した、予想外のジレンマ

Hiroki Hachisukaさん(Newbee inc.)
Yusuke Amanoさん(スクラムフェス仙台)

1.「固定長スプリント」は足枷になり得るのか?
- スプリントより早く作れてしまう
- スプリントのリズムで計画/振り返りをするのは重要
  - 計画づくりは必要なのでプランニングは重要
  - レトロスペクティブで手を止めて方向性が正しいか振り返らないと
- スクラムのお作法を守っている開発より守ってないバイブコーディングをひたすらユーザに見せる開発の方がいいものを作っている
2.「バックログ爆発」とリファインメントの皮肉
- 見積もりをして先の見通しを立てるのに時間をかけてるのはもったいなくなってる
- 受け入れ条件をしっかりかければAIに渡して作れる
3.「職能横断」の完成と、役割の消失
- dev/SM/POの境界が溶けていく
- ポジティブな意味で境界の撤廃
- Ｔ字のように専門性の柱がない状態でやれるのか
- 開発を超えたファンクショナル
  - 営業とか
- 人との接点を最大化する
  - 開発の人数は半分にして他の職種に回した方がいいのでは
- チームしか見れないSMはいらなくなる
  - そのロール入るけど選任するのは手厚すぎ
  - 組織に対する還元もできるような人じゃないといらなくなる