2026年版 アジャイルとスクラムとは～価値・原則・プラクティス 前後半資料
10.3K Views
April 17, 23
スライド概要
関連スライド
各ページのテキスト
プラクティス Agile and Scrum – values, principles, practices アジャイルな開発とスクラム 原則 価値 やっとむ こと 安井 力 スライド公開URL アジャイルコーチ 合同会社やっとむ屋 代表 https://www.docswell.com/s/yattom/5RX22E-agile-and-scrum-6hrs Copyright© 2021 by 安井力、合同会社やっとむ屋 [email protected] 1
前半 考え方を理解しよう ～価値、原則、プラクティス～ 2
やっとむ / 安井力(やすいつとむ) 2001年ごろアジャイルと出会い、開発者、チームリーダー、トレー ナー、導入支援と多様な立場で関わってきた。(株)永和システム マネジメントにて2010年頃からアジャイルコーチを主軸として 活動。2014年独立。 著書・訳書 プログラマー Python JavaScript Java C/C++ アジャイルコーチ (プロセス面) チームビルディング 現場導入支援 スクラムマスター支援 ふりかえり アジャイルコーチ (ものづくり面) モブプログラミング テスト駆動開発 テスト自動化 学びのゲームをデザイン、製作、デリバリー 宝探しアジャイルゲーム カンバンゲーム 心理的安全性ゲーム [email protected] twitter:@yattom https://www.facebook.com/yattom https://www.linkedin.com/in/yattom/ 3
今日の内容 前半 考え方 • アジャイルな企業の例 • アジャイルとはなんなのか？ • アジャイルの価値・原則・プラク ティスとは？ 後半 導入の仕方 • プラクティスの紹介と取り組み方 • アジャイルに向き不向きはあるの？ • アジャイルをやってみるには？ • アジャイル移行のシミュレーション 質問歓迎します！ 4
アンケート: アジャイルやスクラムのイメージ • www.menti.com をアクセスして、番号を入力してください • ご自分のアジャイルやスクラムのイメージと近いものを3つ選んでく ださい • 録画視聴の方も手元で書き出してみてください 5
ある 変わった企業 の話 6
メンロー イノベーションズ 喜びにビジネス価値を見出す 7
どこが変わってるの？ • 顧客が毎週やってきて、開発チームと一緒に成果について話す • プログラマーは全員ペアを組んで仕事をする • 毎週納期、でも残業はぜんぜんない • ハイテク人類学者がユーザーを研究する • 地下の広大なオフィス(駐車場を改装)で、座席・デスクが移動自由 • 赤ん坊や動物がいる • 喜びがある (※基本的に2016年時点の話になります) 8
9
UXデザイン ユーザー価値 ハイテク人類学者 High-Tech Anthropologists 他の写真？なにか適当なやつ？ https://www.flickr.com/photos/kitlvcollections/5497319028/ 10
顧客による計画おりがみ ほしい順に作る 11
見積りと計画づくり 13
チームの自己管理 自律的な進捗管理 14
バーンダウン スプリントバックログ 15
朝会 16
ペアプログラミング 常に学ぶ コードも知識も共有 17
顧客を巻き込んだデモ ショウ＆テル スプリントレビュー 18
すなわち…… 要件定義 プロジェクト 計画 実装 受入テスト ハイテク 人類学者 顧客と 計画おりがみ ペア作業 タスクボード ショウ＆テル 1週間 19
MAKE MISTEAKS FASTER 失敗をはやくたさくんしよう 20
2021年のアップデート • 2020年はファイナンスの危機 • 収益60％ダウン • 一時的な給与カット • 手元資金とPPPローンで乗り切った • 全員リモートワーク • 「リモートで上手くやれる方法を探究するのが楽しみだ！」 • リモートペアプロ • リモートでハイテク人類学 • 紙やホワイトボードの仕組みをデジタル化 • オフィスツアーはバーチャルツアー • 採用インタビューもバーチャルで実施(2021年2月) https://menloinnovations.com/stories/culture/culture-storytelling-joy 21
2023年のアップデート https://menloinnovations.com/stories/menlo-bits/december2022-menlo-bits-copy 22
https://menloinnovations.com/stories/menlo-bits/january2023-menlo-bits 23
またある 変わった企業 の話 24
ソニックガーデン 株式会社 https://www.sonicgarden.jp/201407_family_trip 25
どこが変わってるの？ • 家族旅行をする • 全社員リモートワーク • オフィスをなくした • 顧客には顧問プログラマが１人で専任する • 企画から設計、コーディング、運用まですべて • マネージャがいない • 業務ハッカー募集中 • 納品しない受託開発 • プログラマを一生の仕事に 26
27
全社員リモートワーク(2016年から) http://getnews.jp/archives/1510240 28
顧問プログラマ https://www.flickr.com/photos/124247024@N07/13903385550/ 29
https://www.slideshare.net/rootmoon/ss-48797871 30
https://www.slideshare.net/rootmoon/ss-48797871 31
https://kuranuki.sonicgarden.jp/2014/11/innoswdev_fse.html 32
33
1人ひとりがセルフマネジメント チーム全体がみんなで協力 34
価値観を共有 小さな組織で個人の価 値を尊重すること 中間に入る無駄をなく して直接つなぐこと 判断に理解と納得を持 ち思考停止しないこと 動くサービスを常に最 高品質で提供すること 小口化し繰り返すこと で持続可能にすること 日々学びを続けて自ら 変化に取り組むこと 情報をオープンにし常 に公明正大であること https://www.sonicgarden.jp/company 35
変化 試行錯誤 「こうした問題を何とかできないか、一 体何が原因なのかを考え尽くしたとこ ろ…ビジネスモデルそのものに問題が あると分かった」 「もともと私たちはリモートチームを… 目的にしてきたわけではありません。… ビジネスモデルを追究した結果として、 リモートチームで仕事ができるように」 「変化を受け入れる 変化を恐れない 自らの変化を広げる」 https://www.sonicgarden.jp/company 36
デンソー Factory IoT 事例 37
38 https://www.creationline.com/clientvoice/case18
概要 • 工場からのデータを収集し、利活用するシステム • コンテナ技術、パブリッククラウドなど、新技術を採用 • 「技術の手の内化」に向け内製と継続開発できる体制の構築 • クリエーションライン株式会社の協力を得て、 スペシャリストをメンバーに迎える ※開示： 講師はアジャイルコーチとしてクリエーションライン社に協力しています 39
背景と経緯 • 厳しさが増す時代を「第2の創業期」と位置付 け、スピード感をもった「変革」を推し進める • デンソーの “技術の手の内化”と呼ばれる文化 • パッケージを使用し、外部に依頼する形で開 発を進めまた。半年ほどして、スピードという点 では自社開発する形態がベストであると痛感 • 「内製化」推進のため、共にシステムを作り上 げていくパートナーの存在が不可欠 • アジャイル開発を含めた開発・技術ノウハウの 社内への蓄積と人材育成 • アジャイル開発とオープンソースに関するスペ シャリストの存在は、非常に大きくかつ重要 40
アジャイル開発の採用～活用 目的 • 新技術を導入し、システム稼働 • 開発を継続できる能力の獲得 考え方 • 自社メンバーが、スペシャリストと一緒に、学びながら作る • スペシャリスト主導で技術の検証をしつつ開発する やったこと • スクラムを採用する • 専用のプロジェクトルームを作る • アジャイルコーチを呼ぶ 41
事例 おわり 42
余談：事例を聞いてどうするのか • いいことしか書いてない (たいてい) • “その場・その時・その人たち”において上手くいった結果 • 自分の役に立つとは限らないし • 他にもっといいやり方があるかもしれない • 注意: ×やり方を参考にする ○考え方を参考にする • 注意: ×ひとまとまりの事例と捉える ○細かなアクション、多様なアプローチの集合と捉える 43
事例から学んでみる • アジャイル、スクラムを導入した理由は？ • 他の選択肢はなぜ選ばなかったのか？ • どこにスクラムを適用したか？ しなかった部分は？ 注: 記事中には明記されていません 44
アジャイルな ソフトウェア開発 とは 45
46
47
48
49
50
? 51
2001年 アジャイルソフトウェア開発宣言 私たちは、ソフトウェア開発の実践 あるいは実践を手助けをする活動を通じて、 よりよい開発方法を見つけだそうとしている。 この活動を通して、私たちは以下の価値に至った。 プロセスやツールよりも個人と対話 を、 包括的なドキュメントよりも 動くソフトウェア を、 契約交渉よりも顧客との協調 を、 計画に従うことよりも変化への対応を、 価値とする。すなわち、左記のことがらに価値があることを 認めながらも、私たちは右記のことがらにより価値をおく。 http://agilemanifesto.org/iso/ja/ 52
アジャイル宣言の背後にある原則 私たちは以下の原則に従う: 顧客満足を最優先し、 価値のあるソフトウェアを早く継続的に提供します。 要求の変更はたとえ開発の後期であっても歓迎します。 変化を味方につけることによって、お客様の競争力を引き上げます。 動くソフトウェアを、2-3週間から2-3ヶ月という できるだけ短い時間間隔でリリースします。 (続く) http://agilemanifesto.org/iso/ja/principles.html 53
ビジネス側の人と開発者は、プロジェクトを通して 日々一緒に働かなければなりません。 意欲に満ちた人々を集めてプロジェクトを構成します。 環境と支援を与え仕事が無事終わるまで彼らを信頼します。 情報を伝えるもっとも効率的で効果的な方法は フェイス・トゥ・フェイスで話をすることです。 動くソフトウェアこそが進捗の最も重要な尺度です。 (続く) http://agilemanifesto.org/iso/ja/principles.html 54
アジャイル･プロセスは持続可能な開発を促進します。 一定のペースを継続的に維持できるようにしなければなりません。 技術的卓越性と優れた設計に対する 不断の注意が機敏さを高めます。 シンプルさ（ムダなく作れる量を最大限にすること）が本質です。 最良のアーキテクチャ・要求・設計は、 自己組織的なチームから生み出されます。 チームがもっと効率を高めることができるかを定期的に振り返り、 それに基づいて自分たちのやり方を最適に調整します。 http://agilemanifesto.org/iso/ja/principles.html 55
Kent Beck Mike Beedle Arie van Bennekum Alistair Cockburn Ward Cunningham Martin Fowler James Grenning Jim Highsmith Andrew Hunt Ron Jeffries Jon Kern Brian Marick Robert C. Martin Steve Mellor Ken Schwaber Jeff Sutherland Dave Thomas http://agilemanifesto.org/iso/ja/ 56
アジャイルとは 57
2001年 アジャイルソフトウェア開発宣言 私たちは、ソフトウェア開発の実践 あるいは実践を手助けをする活動を通じて、 よりよい開発方法を見つけだそうとしている。 この活動を通して、私たちは以下の価値に至った。 プロセスやツールよりも個人と対話 を、 包括的なドキュメントよりも 動くソフトウェア を、 契約交渉よりも顧客との協調 を、 計画に従うことよりも変化への対応を、 価値とする。すなわち、左記のことがらに価値があることを 認めながらも、私たちは右記のことがらにより価値をおく。 http://agilemanifesto.org/iso/ja/ 58
2014年 Alistair Cockburn “Heart of Agile” https://heartofagile.com/ 59
Collaborate • 人間どうしが関わり合う • 目標や方向を同じにする • 信頼 Reflect • いったん止まる • データをとらえる • 感情をとらえる Deliver • 価値を人に届ける • 同時にフィードバックを得る Improve • すべて！ • プロダクトをより良くする • プロセスをより良くする 60
2016年 Joshua Kerievsky “Modern Agile” 61 https://anagileway.wordpress.com/2016/10/07/modern-agile-jp/
人々を最高に輝かせる Make People Awesome • ユーザーや顧客を • 作る人やサポートする人を • どうやって人を「すごい人」 にするか考える 高速に実験＆学習する Experiment & Learn Rapidly • 学びが必須 • 学ぶために実験が必須 • 多くを学ぶため高速に 継続的に価値を届ける Deliver Value Continuously • 人に価値を届けないと なにも始まらない • 早く届ける努力をする 安全を必須条件にする Make Safety a Prerequisite • 安全なら100%発揮できる • 安全なサービスを提供する • アンゼニアリング (Anzen-eering) 62
いくつかの大事な考え方 64
ユーザー価値を届ける(デリバーする) • ユーザー価値に集中する • 自分が受け取る対価ではない • 喜んでもらうことでもない • ガチでユーザーのメリットになるか • 継続的に、頻繁にデリバーする • 毎週～毎日程度 • サービス内容にもよる • 届けた結果もまた大事 • フィードバックと洞察を得る • 新たな実験の材料とする 65
ソフトウェアの品質はいつ決まるのか？〜「Point of Sales」から「Point of Use」へ ソニックガーデン代表倉貫義人のブログ https://kuranuki.sonicgarden.jp/2011/09/post-46.html
アジャイルの「ライトウィング」と「レフトウィング」 2012/9/2 https://blogs.itmedia.co.jp/hiranabe/2012/09/rightwing-and-leftwing-of-agile.html
継続的に、頻繁にデリバーする • ずーっと続ける • 再開発 (追加や変更や修正) • テストと品質保証 • フィードバックを得る • どんどん難しくなる • ユーザー数、アクセス量、データサイズは増え続ける • 市場、関連業種、競合、法令準拠が変わり続ける • 機能増加、システム複雑化、利害関係のややこしい化が続く • 新たな問題に対応し続ける 68
アジャイルは“難しい”仕事に向く • やり方・作り方がわからない仕事 • 誰に何を提供すればいいかわからない仕事 • 最善を尽くしても成功を保証できない仕事 「ベストを尽くす」ためのアプローチ 「達成」は保証しない ヒント: プロダクト開発はだいたい難しい 69
自分(たち)で自分(たち)を改善する 自分自身を客観視・相対化し、評価して、変化を起こす • よりよいやり方をつねに模索する • 自分の経験から、相互の知識から、外部のリソースから学ぶ • 現状に問題がなければ、あえてそれを壊してみる: 成長 ＞ 安定 • 自分自身を使った実験から、自分のことをよりよく理解する • 外を巻き込む実験から、外のことを深く知る 自発的・自律的な活動 70
タスクボードの実験例 • 同一チームの半年間の変化 • 自己理解、プロダクト状況、学習による 71
72
73
74
モブプロの実験と改善の例 75
ソフトウェアは経年劣化する 急ぎの対応 高品質 予期しない仕様変更 OSバージョンアップ 内部 品質 低品質 追加変更が大変で 意図しない問題が すぐ起きる 苦しい領域 gravity 重力 追加変更が容易で 意図しない問題も 起きにくい 安全な領域 詳しい人が退職 新システムと連携 時間
リファクタリングでいいポジションをキープ 追加変更が容易で 意図しない問題も 起きにくい 安全な領域 高品質 内部 品質 低品質 相応の 手間・コストは 必要 追加変更が大変で 意図しない問題が すぐ起きる 苦しい領域 重力に 打ち克つ gravity 重力 時間
内部品質は最高が安上がり • 整った環境での仕事は速くて安全 • 安全に変更できる＝最高速度を出せる • プロジェクトを炎上させるのは、テストではなくデバッグと再テスト • 変更しやすい状況を維持するためのリファクタリング • よりよいプロダクトに変更できるという顧客価値 • 「後で直す」より「いますぐ直す」ほうがだいたい常に低コスト • リファクタリングを後回しにする＝負債を背負い込む アジャイルは作り続け直し続けて 最高の状態を維持する
チームを単位とする 「チーム学習はきわめて重要である。なぜなら、現 代の組織における学習の基本単位は個人ではな くチームであるからだ。…チームが学習できなけ れば、組織は学習し得ない。」 https://www.amazon.co.jp/dp/B071WR7XMH 「チームというものは完成することはないが、それ でも方向性をそろえて、価値を継続的、持続的に 提供するには最善のアプローチだ。チームはやる 気のあるメンバーで構成され、長期的に維持さ れ自律的であるべきだ。」 (英語版から拙訳) https://www.amazon.co.jp/dp/B09MS8BML8/ 79
心理的安全 (Psychological Safety) 「チームの心理的安全とは、対人のリスクを取っても安全であるという、 チーム全員の信念である」 “Psychological Safety and Learning Behavior in Work Teams” Amy Edmondson, 1999 Amy C. Edmondson https://twitter.com/amycedmondson 「「心理的安全」とは、関連のある考 えや感情について人びとが気兼ね なく発言できる雰囲気をさす。」 80
人のココロ • 成果を得るために最も大切なのは人 • 個人および人々 • 最高に輝いている個人・チームが最高の結果を出せる • 機械にできることは任せ、人にしかできないことをする • 生成系AIの時代 ここがどうなるかわからない • AIを含む機械を限界まで使いこなす人になること？ • 落ち着く時間も大事 人間だもの アジャイルは 人の人らしさを生かす考え方 82
従来型 ウォーターフォール アジャイル 83
プロセスや ツール よりも 個人と対話 を 価値とする こういう ちがいを 言ってんじゃ なくて！ まず ひとり一人のことを尊重し考える ここから 考えるように 変わりましょう ってこと！ そして 人々のやり取り、対話、協調を考える 84
いくつかの大事な考え方 • ユーザー価値を最重視する • 早期にリリースし、フィードバックを得て、さらに価値を高める • チームとしての働き方も、テクニカルな技量も、どちらも卓越する • 自分たちで自分たちを改善する • 内部品質を高く維持し、追加変更を速く頻繁におこなう • 人の人らしさを生かし、個々人やその間の対話を大事にする 88
アジャイルと生成AI • 生成AIはプロダクト開発のあらゆる箇所を変えている • バイブコーディング、エージェンティックエンジニアリング、ハーネス エンジニアリング、LLM-as-a-Judge、AI-DLC、…… • 新しいツールや手法にも、変化に柔軟に対応するのがアジャイル • アジャイルな組織ほど柔軟に対応できて……いる？？？ • 2026年現在に、「イチからアジャイルを！」というのは 的外れ感がある • 明確な目的があるなら、やりましょう！ 89
スクラムの位置づけ • 2000年代後半から、アジャイル移行≒スクラム導入 • アジャイル手法として、66％～81％がスクラムを採用 • https://digital.ai/resource-center/analyst-reports/state-of-agile-report • 書籍、事例、トレーニングなどが豊富 • スクラムアライアンスの認定スクラム研修 • 学習と成長を促す • 自分だけのプロセスを作る • スクラム自体は「軽量なフレームワーク」であり、プロセスではない 95
スクラムと人材育成 「スクラムがもたらす最終的な結果、 いわば設計目標は、飛躍的に生産性 を上げるチームの実現にある」p.22 (『スクラム 仕事が4倍速くなる世界標準のチーム戦術』ジェフ・サザーランド、 2015) https://www.amazon.co.jp/dp/4152095423 「メンバーはグループ全体として学習 し、さらに専門を越えて学習する」p.209 (『アジャイル開発とスクラム』野中郁次郎、平鍋健児、2013) https://www.amazon.co.jp/dp/4798129704
スクラムフレームワーク • 1チーム(10人以内)でプロダクトを作る • 1スプリント(1ヶ月以内)でプロダクトの増分(インクリメント)を 完全な品質で完成する • 必要な工程は管理も含めすべてチーム内で担当する (他にも大事なポイントがあるがここでは割愛)
https://www.servantworks.co.jp/resources/scrum_overview_figures/
https://www.servantworks.co.jp/resources/scrum_overview_figures/ 実装 仕様 修正 設計 改善 設計改善 ユーザー ヒアリング 相談 画面 デザイン テスト テスト 自動化 データ ベース デバッグ 1ヶ月以内の スプリント フィード バック
スクラムで成長するメンバー • 1チーム(10人以内) • すべての行程、作業、管理業務をおこなう • 各自の能力を生かし かつ 協力し学び合って プロダクトを作る • マネージャーも、固定したリーダーもいない 役割分担もない • 全員にすべての作業のチャンス • 繰り返し練習して習熟 • 学びと成長の可能性を最大化
知識が生まれて広がる • メンバーからメンバーに • チーム内で発生する学び • 外部から取り込んで、内部で生きた知識にする • コーチとか専門家とかに立ち上げを手伝ってもらうのも大事 • チームから組織に
https://speakerdeck.com/yattom/mob-programming-to-build-teams?slide=46
アンケート: 自分にとってアジャイルとは？ • ここまでの話から、アジャイルという考え方が自分にどう関わるか、 自分ならどんなところにアジャイルをあてはめたいか、思いついた ことを書いてください。 • 複数回答可です(送信した後で追加できます) • 時間が余ったらおすすめのランチやおやつについて書いてください • 録画視聴の方も手元で書き出してみてください 108
アジャイル への たどり着き方 109
プラクティス 原則 価値 110
価値、原則、プラクティス • 価値 = 究極の目的 • プラクティス = 実際の具体的なやり方 • 原則 = プラクティスがなぜ価値につながるかの説明 111
プラクティス 原則 価値 112
お仕事 頑張ってますか？ 113
何のために お仕事 頑張ってますか？ 114
115
何のため＝価値 • 価値とは ほしいもの • ただでは手に入らない 116
価値 プログラム 機能 フィーチャ コスト 117
どれを選ぶ？ B A C D 価値 コスト 118
価値が大きく 早くできるものから 1 2 3 4 C B D A 119
コスト≒時間 A D B C コスト 120
価値は時間累積 A D B 価値 累積価値 C 時間 121
価値は時間累積 A D B 価値 累積価値 C 時間 122
A A A A A 124
価値とはほしいもの • 顧客価値 • 情報、リスク対策 • ※リスクには「いいことが起きる可能性」もある • 生産性 125
短い時間間隔で価値をぐいぐい引き上げる • リリースのたびに価値増大のチャンスがある • 後になるほど知識経験が増え、よい判断ができる • プラスになるチャンスをつかみにいく 126
プラクティス 原則 価値 イテーレション インクリメンタル リリース計画 累積価値 早く作る 小さく作る 先まで考える ほしいもの ユーザーにとっての価値 127
早いほうがいい 細かいほうがいい 先のことも考えたほうがいい 128
簡単 ですね♪ 129
簡単な わけがない 130
コミュニケーション 131
お仕事 頑張ってますか？ 132
誰のために お仕事 頑張ってますか？ 133
誰が 誰のために お仕事 頑張ってますか？ 134
情報帯域で手段を選ぶ 135
フェイス・トゥ・フェイスのコミュニケーション • 原文では「開発チームに向けてや、開発チーム内では」とも • 「ずっと」「毎日」「一緒に」働く • ビジネス＝ユーザー価値を的確にデリバーすること 136
「一緒にやる」というコミュニケーション A = ドキュメントを引き渡す B, C = 一緒にやって伝える スクラムの元となった論文”The New New Product Development Game”より 137
「一緒にやる」というコミュニケーション https://speakerdeck.com/takaking22/a-re-introduction-of-mob-programming?slide=36 138
「ただ話す」という解決策？ • 大規模スクラムのフレームワークLeSS(Large Scale Scrum)の プラクティス • 数十人以上の組織でも、調整の場は不要 ただ話しに行くだけ https://less.works/jp/less/framework/coordination-and-integration 142
リモートのメリットとデメリット メリット • 誰とでもすぐ話せる • マルチチャンネルが使いやすい • Web会議、チャット、ドキュメント共同編集、ホワイトボード、ITS、などなど • 多様性を維持しやすい • モブプログラミングもすぐ実行できる デメリット • 新たに知り合うのが難しい • フェイス・トゥ・フェイスがまだ最高 • 感覚に頼っていた問題発見ができなくなる 143
全員が顔を合わせて話す 毎日一緒に働く ユーザーもエンジニアもビジネスも最初から最後まで できるだけ少人数で 144
簡単な わけがない 145
プラクティス 全員同席 クロスファンクショナルチーム 情報ラジエーター モブプログラミング 原則 フェイス・トゥ・フェイス 少人数 ビジネスと開発が一緒 価値 効果的なコミュニケーション 146
補足: ここで紹介したプラクティス • クロスファンクショナルチーム • 必要なスキルをすべて1チーム内に備えたチーム • ユーザー価値を実現しデリバーするためのすべてのスキル • サポート、デザイン、法務など ― 開発、エンジニアリングスキルに限らない • 情報ラジエーター • 情報を自然に人々に気づかせるような仕組み (ラジエーター＝暖房の熱気を自然と感じるように) • 目立つ場所への掲示、大型モニタに常時表示、プロジェクトのダッシュボード 147
手戻り 148
技術的負債 149
機能追加とコスト 価値 時間 150
利 子 圧 縮 価値 コスト 時間 圧 縮 コスト 時間 技 術 的 負 債 技 術 技術的 的 負債 負 債 151
技術的負債 • 一時的なメリットを与える(レバレッジ) • 開発したソフトウェアに内在する • 開発の作業効率を悪化させる • 除去作業をしないと取り除けない • 放置すると増殖する 152
技術的負債 • 不適切なエンジニアリングで発生する • 能力不足 • 圧力、プレッシャー • 考慮不足 • 将来は本質的に予測できない • 「考慮不足」は不可避 • 「キレイ」な状態を… 最初にちゃんとする → 不可能 or どこかで破綻する 維持する → 常時リファクタリングを続ける • 負債をためすぎないうちに返済する • 将来予測 → 変更容易 153
変更容易性 • 設計がシンプル • 変更箇所と内容が自明 • 依存関係が少ない • 特に隠れた依存関係 • 実装もシンプル • 誰でも安心して変更できる • 自動化したテスト • リグレッション • 常にこの状態を維持する • 厳しい規律 • だんだん難しくなる 154
変更容易性 • SOLID原則、特にSRP＝単一責任原則 • 「あるモジュールを変更する理由はひとつだけ」 • 自動化したテスト • 品質を担保するためのリグレッションテスト • 開発に高速なフィードバックを提供するユニットテスト、スモールテスト • 設計と実装をシンプルにできるスキルと経験 • 経験を積む • 加えて勉強も必要 • チーム全体としてできるようになる • 常にこの状態を維持する • ルールを作り、守る＝完成の定義 (Definition of Done) • チーム内の自律的なピアレビュー • 問題は難しくなり続けるので、チームも強くなり続ける必要がある • 作らない勇気、捨てる勇気 155
https://speakerdeck.com/twada/quality-and-speed-2020-autumn-edition 156
変更容易にしていく技術とチーム • 常に卓越し続け、つねに設計を良くし続ける • 最良のアーキテクチャを自分たちで生み出せるチーム • 既存ルールを守るのではなく、最良の規律を作り実行する人々 157
生成AIがコード書いてくれる世界 生成AIがコードを書くなら、変更容易性は関係ないか？ → 人間が理解しやすいコードは、生成AIも理解しやすい • 生成AIのミスが減る • 対応時間やトークン消費も減る • 「できない」事態になりにくい 生成AIが「機能を壊す」のを、自動テストで防止する → テストの自動化が絶対に必要となる • 特にユニットテストの充実は内部品質の向上につながりやすい 158
プラクティス 原則 価値 CI/CDと自動テスト リファクタリング 開発者発の厳しい規律 ユーザー価値優先 シンプル アーキテクチャ 品質が高いと開発が速い 変更を歓迎する 内部品質と変更容易性 159
品質と規律 160
簡単な わけがない 161
人 162
人々 163
こんなに難しいことを実現する 仕組みを作るのは困難 こんなに難しいことを実現する 工夫を作れる人 難しいことを個人に頼らず 維持できるチーム 164
チームを単位とする 「チーム学習はきわめて重要である。なぜなら、現 代の組織における学習の基本単位は個人ではな くチームであるからだ。…チームが学習できなけ れば、組織は学習し得ない。」 https://www.amazon.co.jp/dp/B071WR7XMH 「チームというものは完成することはないが、それ でも方向性をそろえて、価値を継続的、持続的に 提供するには最善のアプローチだ。チームはやる 気のあるメンバーで構成され、長期的に維持さ れ自律的であるべきだ。」 (英語版から拙訳) https://www.amazon.co.jp/dp/B09MS8BML8/ 165
アジャイルなチームとは • 組織の中にあり、固有のミッションを持っている • ミッション実現に向けた自律的な判断と行動ができる • 独力でミッションを達成する能力と権限を保有する • 実際に100%完全独立しているのは稀 • 主体性を持って、組織内で活動したり助力を獲得したりする • メンバーはチームのミッションを向いて仕事をする • 評価制度もこれに沿っていること ― 個人ではなくチームを評価する • 複雑で、達成が困難かつ不確実なゴールの達成に全力を尽くす • その過程で必要なことを学習し、チームとして成長する 166
モチベーション3.0 自律 熟達 目的 自分のやり方で集中することで より上手になり、できることも広がり そうして大きな目的に向かえるなら モチベーションが上がる 167
方向性が自律を促す 強い 川を 渡りたい 橋を 作れ 川を 渡りたい なんとか しよう 方向性 川を渡りたい んだけどな… 弱い 弱い 自律 強い https://medium.com/@gayathrirao.80/what-agile-isnt-aed90a355400 168
アジャイルなチームとは • 規模が大きすぎない • スクラムでは伝統的に3～10人 • 実際には20人超でも優秀なチームもある • 長期的に存続しメンバーも安定している • ビジネスの要請により許されない環境も多い • 素早く上手にチームとなるため各人のスキルが重要になる • 同一のプロダクトをずっと開発する • プロダクトやサービスのフェーズに合わせ人も入れ替わることが多い • 開発のフェーズではないので注意 169
チームによる学習 171
← 大 パニック 責 任 学習 → 快適 小 低← 能力 →高 172
← 大 パニック 責 任 学習 → 快適 小 低← 能力 →高 173
心理的安全 (Psychological Safety) 「チームの心理的安全とは、対人のリスクを取っても安全であるという 、チーム全員の信念である」 “Psychological Safety and Learning Behavior in Work Teams” Amy Edmondson, 1999 Amy C. Edmondson https://twitter.com/amycedmondson 「「心理的安全」とは、関連のある考 えや感情について人びとが気兼ね なく発言できる雰囲気をさす。」 174
図3. グルー プレベルで 研究した心 理的安全性 の関係 175
学習する組織 • システム思考 – 全体を考える • メンタルモデルへ意識を向け見直す • 共有ビジョン ― 「自分たちはなにを創造したいのか？」 『学習する組織』ピーター・M・センゲ • チーム学習とアラインメント(合致) • 経営者を含むマネジメント全体の意識変革 176
学んで変化するためにふりかえる • 常にもっと効率を高めようとする • 自分たちのやり方を自分たちで見直す 178
プラクティス 自己組織化 クロスファンクショナルチーム チーム維持の方針 原則 モチベーションの源泉 チームの学習・成長モデル 心理的安全性 価値 強いチーム 学んで成長するチーム 179
前半のまとめ 180
プロセスや ツール よりも 個人と対話 を 価値とする こういう ちがいを 言ってんじゃ なくて！ まず ひとり一人のことを尊重し考える ここから 考えるように 変わりましょう ってこと！ そして 人々のやり取り、対話、協調を考える 181
182
183
individuals and interactions 184
質問への回答 • Mentimeterのほうに書き込んでください 186
おすすめ書籍など • 『アジャイル開発とスクラム 第2版』平鍋健児 野中郁次郎 及部 敬雄 https://is.gd/qOh1f5 • アジャイル開発やスクラムの概要や全体像、 企業から見てどういうメリットがあるのか • 『アジャイルサムライ』Jonathan Rasmusson https://is.gd/K9zZf4 • アジャイル開発を実際に始める方法 • 『スクラムブートキャンプTHE BOOK』西村、永瀬、吉羽 https://is.gd/zmKM7q • スクラムの実際のやりかたについて気軽に学べる • 『アジャイルな見積りと計画づくり』Mike Cohn https://is.gd/lBZ6aN • 価値を生み出す計画をアジャイルに作り、進める方法 • 『レガシーコードからの脱却』 David Scott Bernstein https://is.gd/6vAgjt • 技術的側面からアジャイルに必須の技法を解説 188
前半 おわり 189
プラクティス Agile and Scrum – values, principles, practices アジャイルな開発とスクラム 原則 価値 やっとむ こと 安井 力 スライド公開URL アジャイルコーチ 合同会社やっとむ屋 代表 https://www.docswell.com/s/yattom/5RX22E-agile-and-scrum-6hrs Copyright© 2021 by 安井力、合同会社やっとむ屋 [email protected] 190
後半 導入のしかた ～プラクティスの導入から 原則と価値に至る～ 191
今日の内容 前半 考え方 後半 導入の仕方 • アジャイルな企業の例 • プラクティスの紹介と取り組み方 • アジャイルとはなんなのか？ • アジャイルをやってみるには？ • アジャイルの価値・原則・プラク • アジャイル移行のシミュレーション ティスとは？ • アジャイルに向き不向きはあるの？ 質問歓迎します！ 192
やってみよう: • 状況に沿って考えるワークショップ • アジャイルなアプローチを利用するシミュレーション • 自分なりに考えて理解を深める機会です • 講師からのフィードバックもします 193
ユーザー価値を届ける(デリバーする) • ユーザー価値に集中する • 自分が受け取る対価ではない • 喜んでもらうことでもない • ガチでユーザーのメリットになるか • 継続的に、頻繁にデリバーする • 毎週～毎日程度 • サービス内容にもよる • 届けた結果もまた大事 • フィードバックと洞察を得る • 新たな実験の材料とする 194
ユーザー価値のヒント 牛丼屋チェーンだったら？ • 安定した味 • 低価格 • 話題性 運送業者だったら？ • 安全確実な配送 • スピーディな配送 • 長い期日指定 • 取扱困難な荷物の対応 YouTuberだったら？ • 興奮 • 話題性 • 知的刺激 • なごめる オンラインバンキングだったら？ • 利便性 • 低手数料 • 1箇所で済む • 隠しやすい 195
やってみよう: ユーザー価値を探す • 検討したい業種を挙げてみよう • 実際に検討する業種を選ぼう • その業種ではなにがユーザー価値か考えよう グループに分かれてやってみる • 「話し合い」はしなくていい • 思いついたことを「口に出す」それから書く • 「人の言葉」を自分のアイデアのきっかけにする • 悩んだり行き詰まったら「投げかけ」てみる • 人の投げかけに「貢献をつぶやく」 196
やってみよう: クロスファンクショナルチーム • ユーザー価値を提供するために必要な能力、スキルを挙げよう • すべて備えた人材でドリームチームを設計しよう • スキルだけでなく、人格、個性、雰囲気なども考慮しよう グループに分かれてやってみる • 「話し合い」はしなくていい • 思いついたことを「口に出す」それから書く • 「人の言葉」を自分のアイデアのきっかけにする • 悩んだり行き詰まったら「投げかけ」てみる • 人の投げかけに「貢献をつぶやく」 197
プラクティス 198
プラクティス • Practice = 練習 実践 • HOW • なぜやるのか、なんのためにやるのか • ノウハウではない • 必須でもない 必要性から要請される • 実験の対象 • うまくいくかどうか やってみて改善 • 実際のやり方はみな違う 199
プラクティスの問題 • 世の中にたくさんある • 意識的にプラクティスを取捨選択する • 環境や人の変化に合わせプラクティスも変える 200
超基本プラクティス • 朝会 / デイリースタンドアップ / デイリースクラム • 短期間サイクル / イテレーション / スプリント • タスクボード / スプリントバックログ • ふりかえり / レトロスペクティブ 201
朝会 / デイリースタンドアップ • チーム全員 • 毎日、同じ場所、同じ時間で • 状況と問題を共有する • 立ったまま、15分以内 • 現状を踏まえて計画を見直す https://www.slideshare.net/yattom/project-facilitation-from-hiranabe 202
イテレーション • 1～4週間程度をサイクルとして、仕事を完成する • 仕事を完成する • 1機能の要件定義、設計、実装、テストまで • できるように仕事を小さく分割する • イテレーション冒頭で計画づくりをし、終わりでふりかえりをする • イテレーションの成果から毎回フィードバックを得る 203
タスクボード • チーム全員のタスクを見える化 • 状況を日々アップデート • 見れば誰でも全体の様子がわかる • 順調でなければ誰でもアクションできる 204
ふりかえり / レトロスペクティブ • チーム全員 • 仕事のやりかたを見直す • 改善アクションを出す • チームが自分自身で実験する 205
朝会、ふりかえりを学ぶ • プロジェクトファシリテーション http://objectclub.jp/community/pf/ • 朝会ガイド http://objectclub.jp/download/files/pf/MorningMeetingGuide.pdf • ふりかえりガイド http://objectclub.jp/download/files/pf/RetrospectiveMeetingGuide.pdf • 見える化ガイド (タスクボード) http://objectclub.jp/download/files/pf/ManagementBySeeingGuide.pdf • ふりかえりの書籍 • 『アジャイルレトロスペクティブズ』 https://www.amazon.co.jp/dp/4274066983 • 『アジャイルなチームをつくる ふりかえりガイドブック』 https://www.amazon.co.jp/dp/4798168793 206
- http://objectclub.jp/community/pf/
- http://objectclub.jp/download/files/pf/MorningMeetingGuide.pdf
- http://objectclub.jp/download/files/pf/RetrospectiveMeetingGuide.pdf
- http://objectclub.jp/download/files/pf/ManagementBySeeingGuide.pdf
- https://www.amazon.co.jp/dp/4274066983
- https://www.amazon.co.jp/dp/4798168793
ふりかえりの奥深さ • 改善のため • アジャイルとか関係なく改善はしたい • 仕事の手を止める • 落ち着いて話せる • データを見てプロダクトやチームの現状を知る • 自分たちを客観視 • ガス抜き • 新しい着想が得られるかも • その他…… どれもふりかえりの目的 → 単一の目的があるわけではない 207
アジャイルマニフェストにも書いてある 208
効率を高める？ more effective=もっと影響の強い behavior=行動を できるように 209
さまざまなふりかえり手法 • KPT • YWT • タイムライン • 感情グラフ • ファンダンラーン • 象、死んだ魚、嘔吐 • 高い紅茶とケーキのデリバリーをしてみんなで優雅にいただく https://qiita.com/piyonakajima/items/ad3c44d1dc377e41d394
さまざまなふりかえり手法 レジ ア ト ロ ャ スル イ ペク ティ ブズ アジャイル レトロスペクティブズ ふりかえりガイドブック これだけ！ ＫＰＴ ふりかえりカタログ 211
さまざまなふりかえり手法 https://qiita.com/viva_tweet_x/items/b06f56ce83038fc2bb8f 212
ふりかえりの最優先指令(prime directive) 「なにを見つけたとしようとも、我々は以下のことを理解し、強く信じる。 すなわち、関わった全員が、その時点においての知識、スキル、能力、リ ソース、与えられた状況において、最善の仕事をしたのだと。」
やってみよう: 研修のふりかえり • この研修は自分にとってどうか？ 研修の続きをどう過ごしたいか？ • ＋/Δ (プラス・デルタ) • プラス ― よい点、強み、もっとやりたい • デルタ ― 変えること、試してみること、やめること グループに分かれてやってみる • 「話し合い」はしなくていい • 思いついたことを「口に出す」それから書く • 「人の言葉」を自分のアイデアのきっかけにする • 悩んだり行き詰まったら「投げかけ」てみる • 人の投げかけに「貢献をつぶやく」 214
スクラムのプラクティス • 3つの役割 • プロダクトオーナー、開発者、スクラムマスター • 5つのイベント • スプリント、スプリントプランニング、スプリントレビュー、 デイリースクラム、レトロスペクティブ • リファインメント • 3つの作成物 • プロダクトバックログ、スプリントバックログ、 プロダクトインクリメント • コミットメント: プロダクトゴール、スプリントゴール、完成の定義 215
https://www.servantworks.co.jp/resources/scrum_overview_figures/ 217
XP(Extreme Programming)の プラクティス 主要プラクティス • 全員同席 • チーム全体 • 情報満載のワークスペース • いきいきとした仕事 • ペアプログラミング • ストーリー • 週次サイクル • 四半期サイクル • ゆとり • 10分ビルド • 継続的インテグレーション • テストファーストプログラミング • インクリメンタルな設計 導出プラクティス • 本物の顧客参加 • インクリメンタルなデプロイ • チームの継続 • チームの縮小 • 根本原因分析 • コードの共有 • コードとテスト • 単一のコードベース • デイリーデプロイ • 交渉によるスコープ契約 • 利用都度課金 218
https://speakerdeck.com/kakutani/xpmatsuri2019-keynote 219
DevOpsプラクティス • アジャイルプロジェクトマネジメント • シフトレフト • ビルドツールチェイン • 自動化 • パイプラインの監視 • 運用容易性 • 継続的フィードバック • 文化変容 https://www.atlassian.com/devops/what-is-devops/devops-best-practices 220
やってみよう: どのプラクティスを使う？ • 興味・関心のあるプラクティスを教えてください(解説します) • これまでに考えた目的に向くプラクティスを見つけてください • 提供したいユーザー価値 • そのためのチーム • そのチームが学ぶべきこと グループに分かれてやってみる • 「話し合い」はしなくていい • 思いついたことを「口に出す」それから書く • 「人の言葉」を自分のアイデアのきっかけにする • 悩んだり行き詰まったら「投げかけ」てみる • 人の投げかけに「貢献をつぶやく」 222
やってみよう: どのプラクティスを使う？ - 例 協力しやすく なりたい 学習と 知識獲得 遅れを 減らしたい 顧客満足 向上 朝会 スタディセッション バックログ プロダクトビジョン タスクボード モブプログラミング イテレーション フィードバック ストーリーポイント ユーザー インタビュー ふりかえり イテレーション ペアプログラミング バーンダウン チャート ペルソナ テスト自動化 CI/CDパイプライン 223
プラクティスの難しさ: マニュアルではない • 実際にやるのはプラクティス • プラクティスをやるだけでは価値に近づかない • 「なんのため？」と「なぜ？」を意識し続ける • 自分たちがねらっている価値を共有し、理解を深める • 価値に到達する原則について全員で勉強する 224
プラクティスの難しさ: 練習しないと上達しない • ただやろうとしても、なかなか上手くいかない • 我流になってしまって効果が上がりにくい • 実践(=プラクティス)の中で、繰り返し練習(=プラクティス)する • 繰り返しながら、自分たちで常に見直し続ける × やれているか △ 型通り・お手本通りか ○ 価値に近づいているか • お手本、ガイド、指導者などを活用する 225
守破離 能、茶道、剣道などの教え 離 破 守 自分自身が独立し、流派を作る、 自らが師匠になる 新たな価値を生み出す 自分なりの試行錯誤をしたり、他流のやり方を取り込んだりする 精神、メカニズム、理論を身につける 師匠につき、言われたとおりのことが完璧にできるよう修練する 基礎を身につける 226
プラクティスの難しさ: 独立したテクニックではない • プラクティス同士の相互作用がある • 単体では効果が上がりにくい • 同時にたくさん導入すると失敗する、難易度が高くなる • やりやすい、導入しやすい順序がある • ひとつずつ導入する • ちゃんとできるようになるまで、他のことに手を出さない 227
プラクティス同士の相互作用 朝会 現状 見直し リズム 更新 イテレーション 作る 見返す 次回に 生かす ふりかえり タスクボード 思い出す 228
プラクティス導入の順序 タスクボード ふりかえり 朝会 イテレーション 229
https://www.amazon.co.jp/dp/B08711ZCPY 230
プラクティスの難しさ: 計画通りには導入できない • 期待したようにも、予定通りにも進まない • 予想外の出来事や結果は、自分たちについての新たな発見 • 試行錯誤しながら自分たちについて理解を深めていく • 計画通りに進まないことを計画する • 全員で計画づくりをする • 計画変更を計画に含める • 計画変更につながる情報収集を計画する • 計画変更の工数が小さくなるよう、計画の詳細度をコントロールする • 計画変更の量や回数を指標とする(少なかったら問題) 231
アジャイルな見積りと計画づくり • アジャイルで計画はたいへん重要 • 必要なだけ計画する • 変化を前提として計画する • 出来上がった計画 よりも 計画づくり を重視する • プランニング・オニオン 参考： 「アジャイルな見積りと計画づくり」 マイク・コーン著 角谷信太郎、安井力訳 https://www.amazon.co.jp/dp/4839924023 EMZERO Vol.3.1(マナスリンク)より引用 http://www.manaslink.com/articles/75 232
プラクティスの難しさ: 難しい • 難しいので、あきらめがち • 難しいので、簡単な方法を探しがち • 難しいので、自分はいいやと思いがち • 難しいので、非難されがち • 信念と熱意のある人が必要(知識もあるとよい) 233
新しいことに取り組むのは常に難しい • 信念と情熱のある人が必要 (1 エバンジェリスト) • 小さく試して小さく成功させる (2 小さな成功) • 大きな理想を一歩ずつ実現する (3 ステップバイステップ) • 自分の不足を認めて助けを請う (6 協力を求める) • 先見性のある人を集める (11 アーリーアダプター) • とにかく試してみる (17 やってみる) • 権限ある人に認められる (28 経営層の支持者) • やるといいことがあるという気配で人を引き寄せる (40 成功のにおい) https://www.amazon.co.jp/dp/462108786X234
プロセスや ツール や、プラクティス よりも 個人と対話 を 価値とする こういう ちがいを 言ってんじゃ なくて！ まず ひとり一人のことを尊重し考える ここから 考えるように 変わりましょう ってこと！ そして 人々のやり取り、対話、協調を考える 235
アジャイルと 向き 不向き 236
アジャイルは“難しい”仕事に向く • やり方・作り方がわからない仕事 • 誰に何を提供すればいいかわからない仕事 • 最善を尽くしても成功を保証できない仕事 「ベストを尽くす」ためのアプローチ 「達成」は保証しない ヒント: プロダクト開発はだいたい難しい 237
アジャイルの向き不向き • 効果が期待できるプロジェクト、プロダクト • 能力を発揮する個人の性向 • チームや組織の、ルールや文化 238
カオス 複雑 込み入った シンプル 239
ステイシー マトリックス https://logmi.jp/tech/articles/323254 240
ステイシー マトリックス https://logmi.jp/tech/articles/323254 241
ワードリー マップ えっ、 そんなこと できるん でっか？ 都市 計画者 開拓者 なんで そんなこと してるん でっか？ もうかって まっか ？ 入植者 On Pioneers, Settlers, Town Planners and Theft. by Simon Wardley http://blog.gardeviance.org/2015/03/on-pioneers-settlers-town-planners-and.html 242
クネビンフレームワーク 複雑な領域では 探査→知覚→対応 という行動を採る 解決方法は 出現する (Emergent Practice) https://www.slideshare.net/kiroh/ss-14929935 243
よくある障害 • 上司が理解してくれない • 部下、現場が理解してくれない • 他部門、顧客が理解してくれない • 契約やコンプライアンスの壁がある • 開発スキルが足りない • 既存のコード、システム、サービスがある • 時間がない • 予算がない • 人材が足りない 244
よくある障害 • 上司が理解してくれない • 部下、現場が理解してくれない よくある！ • 他部門、顧客が理解してくれない 対処し乗り越える対象 • 契約やコンプライアンスの壁がある 障害を発見する • 開発スキルが足りない のがスクラム • 既存のコード、システム、サービスがある • 時間がない • 予算がない • 人材が足りない 245
アジャイルへの障害 チームによってやり方が違う 企業の文化と合わない 変化への抵抗 アジャイルのスキルや経験不足 リーダーの参画が不十分 マネージャーや経営陣の参画が不適切 https://digital.ai/resource-center/analyst-reports/state-of-agile-report 246
マインドセットの違い ガチガチマインドセット • 能力 – 不変、背の高さと同じ • ゴール – 人から良く見られる • 挑戦 – 避ける • 失敗 - 個人的な問題 • 努力 - 能力がない人がやる • 困難に直面すると – 無力 アジャイルマインドセット • 能力 – 成長、筋肉などと同じ • ゴール – 学ぶ • 挑戦 – 受け入れる • 失敗 – 情報を得られる • 努力 – 熟達への道 • 困難に直面すると – 回復力(レジリエント) 247
アジャイルマインドセット • 実験： 「ガチガチ」と「アジャイル」マインドの2グループ • 簡単な試験を受けてもらう • 次の試験を選ばせる • ガチガチ → 簡単なものを選ぶ • アジャイル → 難しいものを選ぶ • 他の人にアドバイス • ガチガチ → アドバイスしない、嘘をつく • アジャイル → アドバイスする • 2つのグループの違いは？ • ランダムに分けただけ • ガチガチ → 結果をほめられた • アジャイル → 努力をほめられた https://www.slideshare.net/agiledays/linda-rising-the-power-of-an-agile-mindset 248
アジャイルマインドセット • 実験： 「ガチガチ」と「アジャイル」マインドの2グループ • 簡単な試験を受けてもらう • 次の試験を選ばせる • ガチガチ → 簡単なものを選ぶ • アジャイル → 難しいものを選ぶ • 他の人にアドバイス • ガチガチ → アドバイスしない、嘘をつく • アジャイル → アドバイスする • 2つのグループの違いは？ • ランダムに分けただけ • ガチガチ → 結果をほめられた • アジャイル → 努力をほめられた https://www.slideshare.net/agiledays/linda-rising-the-power-of-an-agile-mindset 249
障害を乗り越えるアジャイルマインド • 結果を出すのが大事 → 努力するのが大事 • 「頑張ります！」では大雑把 → プロセスや経過、判断や行動を細かく識別、把握する • 小さな失敗をたくさん見つけて情報を得る • 個人の責任、自分の作業を完遂する → チームの責任、全体で価値を完成する • 人は人、仕方ない → 人はつながり、変化する 250
アジャイルは「達成」を保証しない • いまいるひとびとの力を引き出すチーム主義 • 障害物を発見し乗り越える • 未知や曖昧さを味方につけ前進する 「ベストを尽くす」ならアジャイル 251
アジャイルを “やってみる” 252
Unlearn まなびほぐし 253
Unlearn / 脱学習 / まなびほぐし • アジャイルに限らず、今までのやり方を変えるときに必要 • 今までのやり方＝今までに学んだことを、いったん脱ぎ捨てる • うまくいくかわからなくても、やってみる • うまくいかないとわかっていても、やってみる • 過程を精緻に分析し、知見を得る • 結果はあまり気にしない • 結果の良し悪しより、予想とのズレに注目する • 新たな学びに向け、今までの知識を壁にしない 254
学ぶゆとり • 自分で考えるのが大事 • とはいえ、学ぶべきことはたくさん • 個々人、チーム、部署、組織として学ぶ • そのためのゆとりを確保する • ふりかえり / レトロスペクティブの時間 • 仕事の中で実験する時間 255
超基本プラクティス • 朝会 / デイリースタンドアップ / デイリースクラム • 短期間サイクル / イテレーション / スプリント • タスクボード / スプリントバックログ • ふりかえり / レトロスペクティブ • 「プラクティスは難しい」を忘れずに 256
ユーザー価値に集中する • プロダクトの価値とエンドユーザーが得る価値を整える • 自分たちの行動、ルール、プロセスを再検討する • ユーザー価値の観点から • 「その仕事はユーザーにどう役立つの？」 • ユーザーを理解する • 観察(ハイテク人類学) • 直接会って話を聞く • ペルソナ 257
デリバリーとフィードバック Deliver • 価値を人に届ける • 同時にフィードバックを得る 258
259
トラクション＝車輪が地面を捉える • エンジンがタイヤをまわす • タイヤが地面に触れて推進力を生む 現実にぶつけて初めて価値が生まれる • 地面に触れると • 前進する • フィードバックが得られる • 前進する 260
フィードバック • エンドユーザーの反応、要望、ニーズを最優先する • それ以外は調整すべき利害関係者(ステークホルダー) • エンドユーザーからチームが直接情報を得る • 行動分析 • インタビュー • ベータテスター • 情報を持ったチーム自身が決断し行動する • 自身が判断し、行動し、結果を見て、改善する • 上司・マネージャ・他部門・アナリストなどのせいにしない 261
ユーザーインタビューで気をつけること • 目的を明確に設定する • 探索と検証 • オープンで中立な質問を心がける • 誘導しない • ユーザーの話をしっかり聞く (傾聴する) • 相手が話しやすい環境を整える • 相手の言ったことに合わせて柔軟に、深掘りや確認、共感を示す • 多様な視点を求める • 否定的意見も尊重する • 「根本的な帰属の誤り」に注意 • 非言語コミュニケーションに注意する • 表情、間、身振りなどを観察し記録する 262
プロダクトレビュー • プロダクトへのフィードバックをもらうため、レビューを実施する • スクラムではスプリントレビュー • 実際に使えるプロダクトをデモする • ユーザー価値があるものをレビューする ― 計画、設計、意図、想定ではなく 263
レビューのフィードバック • 気に入った点、素敵な箇所、期待を超えたところ、改善のアイデアなど • 気に入らない点、問題になる点、考慮漏れ、改善のアイデアなど • ネガティブな意見、不足の箇所だけ対応しても良いものにならない • 出席者 (ステークホルダー、関係者) どうしが対話、議論する • なにを考えてるのか、どう思ってるのか、情報の宝庫 • 「OK」をもらうのは間違い • フィードバックとしていちばん情報量が小さい！ • 「真のOK」を出せるのはユーザーだけ 264
フィードバックのためにレビューをデザイン • プロダクトのどの部分？ どういった観点？ 誰から？ どんなフィードバック？ • 新しい機能をユーザーは初見で使えるだろうか • 業務上必要十分なデータ項目か、営業と経理とどちらの業務も大丈夫か • 改善したプログレスバーで「待たされ感」は軽減できたか • ヘルプデスクがユーザーをサポートしやすいか • 社長のお気に召すか • 得たフィードバックについてその場で議論し情報を増やす • 結論がその場で出なくてよい → スクラムならプロダクトオーナーに最終判断の責任 265
チームに任せる • 環境を与える • 場所、空間、オフィス • 機材、インフラ • 支援を与える • 他からの介入を防ぐ • 問題・課題を解消する • 信頼する • 放っておく！ 266
コミュニティに参加する • アジャイル、スクラムは企業や業種を超えたコミュニティによって成立 • 実践するなら、コミュニティへの参加は必須 • やり方や考え方を学ぶ • 近い立場の人から話を聞く、相談する • 自分たちことを聞いてもらい、フィードバックを得る • 有名人、実践者、著者から直接話を聞く機会 • 社内にコミュニティを作るのも大事 コミュニティに参加しないでアジャイルに取り組むのは 植物を水だけで育てるようなもの 芽は出るけどすぐ枯れる 267
案件や顧客を選ぶ アジャイル やりましょう！ • 長年お付き合いのあるお客様 → やめよう • 望まれてない提案は筋悪、勝手にやるのは論外 • 重要案件、納期必達、品質最重要 → やめよう • ちゃんとできるようになってからやろう、練習重要 • 「アジャイルやりたい」というお客様 → よく考えよう • 目的、背景、ほしいもの(ユーザー価値)を聞いてから • 失敗の余地がある、顧客も学ぶ体勢、 新規開拓 → チャンス！ • 社内ツールなどから始めるのも良い 268
組織を変えるか 組織を作るか • 既存の組織、ルール、人の考え方、文化を変えるのは大変 • 新たに組織を作る方が簡単(な場合もある) • 出島的な部署 • 別会社 • オフィスも別にする • ゼロベースで新しいやり方に取り組めるような環境 • フルタイム • 十分な権限 • 報告させない、マイクロマネジメントしない、我慢して任せる 269
組織を変えるか 組織を作るか • いまある組織を変えたい • 小さく始めて育てる • 1つのプラクティスを小規模に始める • チーム単位(3～10名程度) • 1人では続かない • 周囲が邪魔しないよう守り育てる • あなたも邪魔しないように • 成果が上がってから少しずつ広げる • 『Fearless Change』を参考に 270
メンローイノベーションズに学ぶ • 社長が最強のビジョンを持つ • XPとデザイン思考(IDEO)をベースとする • やるべきことを決め、できる人を集め、徹底的にやる • そこから新たな工夫、実験、失敗からの学びを繰り返す • 何年もかけて上手になっていく • 情熱 • 権限 • 時間 271
開発技術の更改 • アジャイル20年の歴史は開発技術の進歩と表裏一体 • アジャイルなソフトウェア開発に最低限必須な技術を導入する • イテレーション単位で開発ができるスキルとテクノロジーを修得する 272
すでに常識の開発定番技法 • バージョン管理システム • ビルド自動化 • コードの共同所有 • テストの自動化 • 継続的インテグレーション(CI) • 開発環境の標準化 • コンテナ • DevOps 273
すでに常識の開発定番技法 • バージョン管理システム – 1982年(昭和57年) RCS • ビルド自動化 – 1976年(昭和51年) Make • コードの共同所有 – 1960年代(昭和40年頃) 『プログラミングの心理学』のエピソード • テストの自動化 – 1989年(平成元年) SUnit • 継続的インテグレーション(CI) – 1997年(平成9年) XP • 開発環境の標準化 – 2010年(平成22年) Vagrant • コンテナ – 2000年(平成12年) FreeBSD Jail • DevOps – 2009年(平成21年) 274
(ちょっとだけ)新しめの当たり前の技術たち • 分散バージョン管理システム – 2005年 Git • ビルド自動化システム – 2011年 Jenkins • コードの共同所有 – 2008年 GitHub • E2Eテストの自動化 – 2004年 Selenium • 継続的デリバリー(CD) – 2010年 書籍”Continuous Delivery” • 開発環境の標準化 – 2010年 Vagrant • コンテナ – 2013年 Docker • DevOps – 2009年 275
変更可能な設計 • イテレーション単位で機能を完成する • ほぼすべての開発は改修・変更 • 包括的な設計・アーキテクチャ → 変更容易な設計・アーキテクチャ • 要素技術 • オブジェクト指向設計 • ドメインドリブンデザイン(DDD) • クリーンアーキテクチャ • マイクロサービス(MSA) 276
テスト自動化 • 常に変更するコードの品質を担保し続ける • 手動テストでは早期に破綻する • ソフトウェアの正しさを動作で検証する • レビューなどの手法も併用すべき • 自動化すべき領域を識別する 詳しくはこちらも（宣伝) 講演動画もあります https://youtu.be/vrbMKbdV6xY https://speakerdeck.com/yattom/tesutofalsezi-dong-hua-totesutoqu-dong-kai-fa 277
継続的デリバリー • 開発作業から本番リリースまでの過程を自動化し、継続実行する • 属人性(人の作業や確認)を減らす • 手順書 → 自動化する • チェックシート → 自動化する • レビュー → 機械的チェックや正しさの確認は自動化する • テスト → 手順で進めるテストは自動化する • リリース作業 → ワンタッチで完結するよう自動化する • 人間性を生かす作業に時間を使う • 議論する • もっとよいアイデア、設計、手法を見つける • 不要な機能、手順、プロセスを削減する • 思いもよらない問題、バグを探索する https://www.amazon.co.jp/dp/B074BQQ96X 278
技術やツールの権限を与える • チーム自身が、ユーザー価値に最適な技術やツールを選定する • 会社ルール、取引先都合、新しもの好きの誰かなどに振り回されない • 新しい技術やツールに工数を確保する • 調査、学習、実験する時間 • 既存コードを適合させる時間 • うまくいかなかったとき切り戻す時間 • チームの挑戦と成長に価値をおく • 長い目でユーザー価値につながる 279
いきいきと働く • ユーザー価値に集中する • 大局的プロダクト価値を目標とする • ツール、プロセス、プラクティスに挑戦し、習熟する • 個々人が自律的に能動的に働く • チームとして個人の能力の総和以上の結果を出す • 他からの介入は最低限 • 仕事に「Joy」があふれる 280
やってみよう: やってみる 281
後半のまとめ 282
プラクティス • プラクティスを選び、実践して上達する • 効果を上げるのは難しいが工夫する Unlearn / 学びほぐし • これまでの知識経験を生かしつつ新しい形に組み立て直す • 現状を変えることへのストレスに対処する アジャイルへの移行はアジャイルに • ユーザー価値を最初に置く • フィードバックを通じて自分自身を知る • いきいきと働けるようになる 283
おすすめコミュニティ • RSGT (Regional Scrum Gathering Tokyo) https://scrumgatheringtokyo.org/ • 日本最大のスクラムイベント。複数トラックで多数のセミナー。チームみんなで参加 したい。毎年1月に開催。有料。現地＆オンライン • スクラムフェス • 各地で開催される現地有志によるスクラムイベント。多数のセミナー。大阪、仙台、 三河(名古屋)、沖縄、福岡、新潟、札幌など。有料。多くは現地＆オンライン • アジャイルひよこ倶楽部 https://agile-hiyoko-club.connpass.com/event/ • 初心者に優しい勉強会。講演と、参加者同士の語らい。無料。オンライン • 製造業アジャイル勉強会 https://beyond-hardware-agile.connpass.com/ • 気軽な勉強会。参加者同士の雑談が中心。無料。オンライン • アジャイルジャパン https://agilejapan.jp/ • アジャイル全般を扱うイベント。内製や発注者向けの内容が多い。顧客と一緒に参 加したい。有料。2022年はオンライン 285
アジャイルコーチに手伝ってもらう やっとむ / 安井力(やすいつとむ) 2001年ごろアジャイルと出会い、開発者、チームリー ダー、トレーナー、導入支援と多様な立場で関わってき た。(株)永和システムマネジメントにて2010年頃からア ジャイルコーチを主軸として活動。2014年独立。 [email protected] twitter:@yattom プログラマー https://www.linkedin.com/in/yattom/ https://www.facebook.com/yattom Python JavaScript Java C/C++ アジャイルコーチ (プロセス面) チームビルディング 現場導入支援 スクラムマスター支援 ふりかえり アジャイルコーチ (ものづくり面) モブプログラミング テスト駆動開発 テスト自動化 学びのゲームをデザイン、製作、デリバリー 宝探しアジャイルゲーム カンバンゲーム 心理的安全性ゲーム 286
プロセスや ツール よりも 個人と対話 を 価値とする こういう ちがいを 言ってんじゃ なくて！ まず ひとり一人のことを尊重し考える ここから 考えるように 変わりましょう ってこと！ そして 人々のやり取り、対話、協調を考える 287
質問への回答 • Mentimeterのほうに書き込んでください 289
アンケート: なにをやりたくなりましたか？ • 以上の話を踏まえて、いまやりたいこと、やってみたくなったことを自 由に書いてください。複数回答できます(送信したあと追加で回答で きます) • 時間が余ったら好きな音楽や動画、テレビや映画について書いてくだ さい • 録画視聴の方も、手元に書き出してみてください 290
おわり 291