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