[紅白LTセッション & 2025年ラストMeetup#6]アジャイルをDevOpsする

アジャイルをDevOpsする @samuraiRed

森實 繁樹 株式会社レッドジャーニー Swise株式会社 外部顧問 Pluslab株式会社 外部顧問 国立筑波大学 非常勤講師 （所属ユニット） 侍塊s プロジェクトマネージャ保護者会 ITかあちゃんず （所属（運営）コミュニティ） 日本XPユーザグループ BIT VALLEY –INSIDE保険xアジャイルコミュニティ 人材業界ビジネスアジャイルコミュニティ Agile Tour Yokohama 2

アジャイルとは 「今を認知し、学習を継続していくこと」 3

DevOpsとは 「開発と運用を密接に連携・協力し、自動化された プロセスを通じて開発から提供までのサイクルを 高速化・効率化する文化・手法・プラクティスの総称」 4

DevOpsの前提 小さいマージを繰り返しながら、その中で 必要な確認を行い、実際に動かせるように 要件、案件、タスクの分割が必要 5

さぁアジャイルをDoしよう スクラムをDoするとか もしこれをやるなら一度こちらを見てからにしてください https://www.docswell.com/s/samuraiRed/5WMQYG-2025-11-13-205802 仮説検証するとか いちいちでかいな… 6

• https://www.docswell.com/s/samuraiRed/5WMQYG-2025-11-13-205802

そもそもアジャイルでやりたかったこと 実務に早期に照らしてフィードバックを得ること そして、ユーザーが惑わないで馴染めること つまり、驚き最小の原則 さらに、何かあったらすぐに戻せること バージョン管理をすること 仮説はいつも闇なのでセーブポイントにアンカーをうつこと そのためには検証と納得というプロセスが超重要 だから僕たちは前に進めるし、失敗するのはたったの1決断のみとできる！ 7 即ち、驚き最小且つセーブポイントをステップバイステップで積み上げる

そもそもアジャイルでやりたかったこと 実務に早期に照らしてフィードバックを得ること そして、ユーザーが惑わないで馴染めること つまり、驚き最小の原則 さらに、何かあったらすぐに戻せること バージョン管理をすること 仮説はいつも闇なのでセーブポイントにアンカーをうつこと そのためには検証と納得というプロセスが超重要 だから僕たちは前に進めるし、失敗するのはたったの1決断のみとできる！ 8 即ち、驚き最小且つセーブポイントをステップバイステップで積み上げる

こうするために必要なこと 計画は必要だが、計画は常に正解ではないので、ステップバ イステップで検証と再適用が必要 結果、計画を守らないのではなく、計画を変更するプロセス を回す 計画変更は組織のプロセスとして必ず存在するもの 筋を通すことは社会、組織の常識 9

アジャイルに求められる誤解 「速さ」 10

アジャイルに求められる誤解 速さとは学習のサイクル 学習サイクルの価値＝頻度☓深さ 頻度を高める＝要件、案件、タスクの検証可能最小サイズ化 それは自分たちの”今まで”に対して、相対的な速さに現れる ものであり、絶対的な速さで評価できるものではない 更にいうと、ガバナンスを守るために、あるいは検証期間を得 るために必要な頻度の調整が大きくならざるを得ない現実はあ るわけで、3ヶ月に1回のスプリントも相対的に速いのであれ 11 ば、十分にアジャイルと言える

アジャイルに求められる誤解 速さとは学習のサイクル 学習サイクルの価値＝頻度☓深さ 深さとは検証計画に基づく、確からしさを確認できる度合い 本当に知りたいことがわからないと小さくできない つまり、わからないことをわかりたい単位に分割する必要 があるし、目論見は持っておくほうが ※何もわかっていな くても優先度はつけやすくなる ※何もわかっていないのはデスクトップリサーチや周りにいる人へのヒアリングを含めて実行力と想像力が欠如している 12 可能性を疑ったほうがいいかもしれないけど

閑話休題 なぜ組織はスクラムマスターに救いを求めるのか 13

なぜ組織はスクラムマスターに救いを求めるのか 組織がスクラムマスターを置きたがる理由はわかる しかし、スクラムマスターがいなくてもこれまでやってきたということは、 スクラムマスターのやること定義から始まるスクラムマスターというあり 方には全く納得がいかない 企画部門 役割 PO(PdM) 役割 ScrumMaster 開発・デザイン部門 役割 かつて Devほか 昨今 役割 役割+α 14

なぜ組織はスクラムマスターに救いを求めるのか 組織がスクラムマスターを置きたがる理由はわかる しかし、スクラムマスターがいなくてもこれまでやってきたということは、 スクラムマスターのやること定義から始まるスクラムマスターというあり 方には全く納得がいかない こっち が先！ PO(PdM) 役割 ScrumMaster Devほか 昨今 役割 こっち が先！ 委譲（移譲ではない） 役割+α 委譲（移譲ではない） 15

なぜ組織はスクラムマスターに救いを求めるのか 組織がスクラムマスターを置きたがる理由はわかる しかし、スクラムマスターがいなくてもこれまでやってきたということは、 スクラムマスターのやること定義から始まるスクラムマスターというあり 方には全く納得がいかない PO(PdM) 役割 期限を付けて戻していく ScrumMaster Devほか 昨今 役割 PO(PdM) α ScrumMaster 役割+α 期限を付けて戻していく 役割 Devほか 将来 役割 16

なぜ組織はスクラムマスターに救いを求めるのか 過渡期を含めて、αを定義していくということまでを考えないのであれば、 それはスクラムマスターを”雑用係”と呼んでいるのと大差ないと恥じて ほしい PO(PdM) 役割 期限を付けて戻していく ScrumMaster Devほか 昨今 役割 PO(PdM) α ScrumMaster 役割+α 期限を付けて戻していく 役割 Devほか 将来 役割 17

閑話休題 終 なぜ組織はスクラムマスターに救いを求めるのか 18

アジャイルが求められる領域と制約 「変化が著しい」「答えがわからない」と一般的に言われている いったらほぼ全部じゃないかと思うが…（今日は置いておく） かたや金融商品の設計や基幹システムの構造などは、全体を意識 した積み上げ型で構造的な実行をして然るべき 多くの企業では、法令対応や商品改定プロジェクト等において、デザ インと設計は不可分にプロジェクトとして稟議するものと扱われる （これは情報資産としての管理上の理由が主） 19

アジャイルが求められる領域と制約 しかしながら、変化が著しいのはデザインであり、UXである つまり、商品設計や基幹システムの根幹とデザインは本来は 可分であるべき UXは常に最前線であり、あるいは常に仮説に過ぎない が故に、仮説立てから検証までを頻度高く回す必要がある だからこそアジャイル！ 学び続ける領域と、考えて組み立て続ける領域を2本柱で走らせ られるかが日本企業のガバナンスの頑張りどころとなるであろう20

アジャイルが求められる領域と制約 デザイン領域 計 画 実 行 管 理 ・ 監 視 D A O 計 画 D O 立ち上げ 実 行 管 理 ・ 監 視 計 画 A O D O 実 行 管 理 ・ 監 視 計 画 A O D O 実 行 管 理 ・ 監 視 計 画 実 行 管 理 ・ 監 視 A O D A O O O デザインとシステムの分離に向き合う時代が改めてやってきた！ 計画 実行 管理・監視 Decide 方針決定 Act 実行 Observe 観察 Orient 情勢判断 システム領域 終結 21

まとめ 22

まとめ アジャイルをDevOps的に回していくことで、フィードバック サイクルを相対的に早めながらアジャイルがDoできる フィードバックサイクルには学習と適用が含まれるため、Do していたアジャイルが深化、変化していく これがアジャイルがBeになる（継続的な状態）ということ 要件、案件、タスクを検証可能な単位に小さくして、検証と 適用（セーブポイントへの立ち戻りを含む）のマネジメント を強化することを活かすには、DevOps的な考え方なしには考 23 えられない

まとめ アジャイルをDevOpsしようぜ！ 24

『ゼロからはじめる チームプロジェクトマネジメント』 2026/1/8 インプレスさんより発売します！ チームのみんなで一度読んでみてください！ 25

僕と働きたい人はぜひ雇ってください 26