アジャイルとスクラムとは～価値・原則・プラクティス
44.3K Views
April 04, 22
スライド概要
関連スライド
各ページのテキスト
Agile and Scrum – values, principles, practices アジャイルとスクラムとは ～価値、原則、プラクティス～ やっとむ こと 安井 力 スライド公開URL https://is.gd/q7P714 アジャイルコーチ 合同会社やっとむ屋 代表 Copyright© 2021 by 安井力、合同会社やっとむ屋 [email protected]
やっとむ / 安井力(やすいつとむ) 2001年ごろアジャイルと出会い、開発者、チームリーダー、トレー ナー、導入支援と多様な立場で関わってきた。(株)永和システム マネジメントにて2010年頃からアジャイルコーチを主軸として 活動。2014年独立。 著書・訳書 プログラマー Python JavaScript Java C/C++ アジャイルコーチ (プロセス面) チームビルディング 現場導入支援 スクラムマスター支援 ふりかえり アジャイルコーチ (ものづくり面) モブプログラミング テスト駆動開発 テスト自動化 学びのゲームをデザイン、製作、デリバリー 宝探しアジャイルゲーム カンバンゲーム 心理的安全性ゲーム [email protected] twitter:@yattom https://www.facebook.com/yattom https://www.linkedin.com/in/yattom/
今日の内容 • アジャイルな企業の例 • アジャイルとはなんなのか？ • アジャイルの価値・原則・プラクティスとは？ • アジャイルに向き不向きはあるの？ • アジャイルをやってみるには？ 質問歓迎します！
アンケート: アジャイルやスクラムのイメージ • www.menti.com をアクセスして、番号を入力してください • ご自分のアジャイルやスクラムのイメージと近いものを3つ選んでく ださい • 録画視聴の方も手元で書き出してみてください
ある 変わった企業 の話
どこが変わってるの？ • 顧客が毎週やってきて、開発チームと一緒に成果について話す • プログラマーは全員ペアを組んで仕事をする • 毎週納期、でも残業はぜんぜんない • ハイテク人類学者がユーザーを研究する • 地下の広大なオフィス(駐車場を改装)で、座席・デスクが移動自由 • 赤ん坊や動物がいる • 喜びがある (※基本的に2016年時点の話になります)
ハイテク人類学者 High-Tech Anthropologists 他の写真？なにか適当なやつ？ https://www.flickr.com/photos/kitlvcollections/5497319028/
顧客による計画おりがみ
自律的な進捗管理
ペアプログラミング
顧客を巻き込んだデモ ショウ＆テル
すなわち…… 要件定義 プロジェクト 計画 実装 受入テスト ハイテク 人類学者 顧客と 計画おりがみ ペア作業 タスクボード 1週間 ショウ＆テル
MAKE MISTEAKS FASTER 失敗をはやくたさくんしよう
2021年のアップデート • 2020年はファイナンスの危機 • 収益60％ダウン • 一時的な給与カット • 手元資金とPPPローンで乗り切った • 全員リモートワーク • 「リモートで上手くやれる方法を探究するのが楽しみだ！」 • リモートペアプロ • リモートでハイテク人類学 • 紙やホワイトボードの仕組みをデジタル化 • オフィスツアーはバーチャルツアー • 採用インタビューもバーチャルで実施(2021年2月) https://menloinnovations.com/stories/culture/culture-storytelling-joy
またある 変わった企業 の話
ソニックガーデン 株式会社 https://www.sonicgarden.jp/201407_family_trip
どこが変わってるの？ • 家族旅行をする • 全社員リモートワーク • オフィスをなくした • 顧客には顧問プログラマが１人で専任する • 企画から設計、コーディング、運用まですべて • マネージャがいない • 業務ハッカー募集中 • 納品しない受託開発 • プログラマを一生の仕事に
全社員リモートワーク(2016年から) http://getnews.jp/archives/1510240
顧問プログラマ https://www.flickr.com/photos/124247024@N07/13903385550/
https://www.slideshare.net/rootmoon/ss-48797871
https://www.slideshare.net/rootmoon/ss-48797871
https://kuranuki.sonicgarden.jp/2014/11/innoswdev_fse.html
1人ひとりがセルフマネジメント チーム全体がみんなで協力
価値観を共有 小さな組織で個人の価 値を尊重すること 中間に入る無駄をなく して直接つなぐこと 判断に理解と納得を持 ち思考停止しないこと 動くサービスを常に最 高品質で提供すること 小口化し繰り返すこと で持続可能にすること 日々学びを続けて自ら 変化に取り組むこと 情報をオープンにし常 に公明正大であること https://www.sonicgarden.jp/company
変化 試行錯誤 「こうした問題を何とかできないか、一 体何が原因なのかを考え尽くしたとこ ろ…ビジネスモデルそのものに問題が あると分かった」 「もともと私たちはリモートチームを… 目的にしてきたわけではありません。… ビジネスモデルを追究した結果として、 リモートチームで仕事ができるように」 「変化を受け入れる 変化を恐れない 自らの変化を広げる」 https://www.sonicgarden.jp/company
2021年11月24日 12:50 https://www.facebook.com/kuranuki/posts/10216645433762729
デンソー Factory IoT 事例
https://www.creationline.com/clientvoice/case18
概要 • 工場からのデータを収集し、利活用するシステム • コンテナ技術、パブリッククラウドなど、新技術を採用 • 「技術の手の内化」に向け内製と継続開発できる体制の構築 • クリエーションライン株式会社の協力を得て、 スペシャリストをメンバーに迎える ※開示： 講師はアジャイルコーチとしてクリエーションライン社に協力しています
背景と経緯 • 厳しさが増す時代を「第2の創業期」と位置付 け、スピード感をもった「変革」を推し進める • デンソーの “技術の手の内化”と呼ばれる文化 • パッケージを使用し、外部に依頼する形で開 発を進めまた。半年ほどして、スピードという点 では自社開発する形態がベストであると痛感 • 「内製化」推進のため、共にシステムを作り上 げていくパートナーの存在が不可欠 • アジャイル開発を含めた開発・技術ノウハウの 社内への蓄積と人材育成 • アジャイル開発とオープンソースに関するスペ シャリストの存在は、非常に大きくかつ重要
アジャイル開発の採用～活用 目的 • 新技術を導入し、システム稼働 • 開発を継続できる能力の獲得 考え方 • 自社メンバーが、スペシャリストと一緒に、学びながら作る • スペシャリスト主導で技術の検証をしつつ開発する やったこと • スクラムを採用する • 専用のプロジェクトルームを作る • アジャイルコーチを呼ぶ
事例 おわり
余談：事例を聞いてどうするのか • いいことしか書いてない (たいてい) • “その場・その時・その人たち”において上手くいった結果 • 自分の役に立つとは限らないし • 他にもっといいやり方があるかもしれない • 注意: ×やり方を参考にする ○考え方を参考にする • 注意: ×ひとまとまりの事例と捉える ○細かなアクション、多様なアプローチの集合と捉える
事例から学んでみる • アジャイル、スクラムを導入した理由は？ • 他の選択肢はなぜ選ばなかったのか？ • どこにスクラムを適用したか？ しなかった部分は？ 注: 記事中には明記されていません
アジャイルな ソフトウェア開発 とは
2001年 アジャイルソフトウェア開発宣言 私たちは、ソフトウェア開発の実践 あるいは実践を手助けをする活動を通じて、 よりよい開発方法を見つけだそうとしている。 この活動を通して、私たちは以下の価値に至った。 プロセスやツールよりも個人と対話 を、 包括的なドキュメントよりも動くソフトウェア を、 契約交渉よりも顧客との協調 を、 計画に従うことよりも変化への対応 を、 価値とする。すなわち、左記のことがらに価値があることを 認めながらも、私たちは右記のことがらにより価値をおく。 http://agilemanifesto.org/iso/ja/
アジャイル宣言の背後にある原則 私たちは以下の原則に従う: 顧客満足を最優先し、 価値のあるソフトウェアを早く継続的に提供します。 要求の変更はたとえ開発の後期であっても歓迎します。 変化を味方につけることによって、お客様の競争力を引き上げます。 動くソフトウェアを、2-3週間から2-3ヶ月という できるだけ短い時間間隔でリリースします。 (続く) http://agilemanifesto.org/iso/ja/principles.html
ビジネス側の人と開発者は、プロジェクトを通して 日々一緒に働かなければなりません。 意欲に満ちた人々を集めてプロジェクトを構成します。 環境と支援を与え仕事が無事終わるまで彼らを信頼します。 情報を伝えるもっとも効率的で効果的な方法は フェイス・トゥ・フェイスで話をすることです。 動くソフトウェアこそが進捗の最も重要な尺度です。 (続く) http://agilemanifesto.org/iso/ja/principles.html
アジャイル･プロセスは持続可能な開発を促進します。 一定のペースを継続的に維持できるようにしなければなりません。 技術的卓越性と優れた設計に対する 不断の注意が機敏さを高めます。 シンプルさ（ムダなく作れる量を最大限にすること）が本質です。 最良のアーキテクチャ・要求・設計は、 自己組織的なチームから生み出されます。 チームがもっと効率を高めることができるかを定期的に振り返り、 それに基づいて自分たちのやり方を最適に調整します。 http://agilemanifesto.org/iso/ja/principles.html
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/
アジャイルとは
2001年 アジャイルソフトウェア開発宣言 私たちは、ソフトウェア開発の実践 あるいは実践を手助けをする活動を通じて、 よりよい開発方法を見つけだそうとしている。 この活動を通して、私たちは以下の価値に至った。 プロセスやツールよりも個人と対話 を、 包括的なドキュメントよりも動くソフトウェア を、 契約交渉よりも顧客との協調 を、 計画に従うことよりも変化への対応 を、 価値とする。すなわち、左記のことがらに価値があることを 認めながらも、私たちは右記のことがらにより価値をおく。 http://agilemanifesto.org/iso/ja/
2014年 Alistair Cockburn “Heart of Agile” https://heartofagile.com/
Collaborate • 人間どうしが関わり合う • 目標や方向を同じにする • 信頼 Reflect • いったん止まる • データをとらえる • 感情をとらえる Deliver • 価値を人に届ける • 同時にフィードバックを得る Improve • すべて！ • プロダクトをより良くする • プロセスをより良くする
2016年 Joshua Kerievsky “Modern Agile” 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)
安全を必須条件にする • よい仕事の前提条件 • 心理的安全性 • アンゼニアリング (Anzen-eering)
高速に実験＆学習する • よりよいやり方をつねに模索する • 現状が上手くいっていたら、それを壊す • 自分の経験から、相互の知識から、外のリソースから学ぶ • 実験から新たな情報を獲得する
モブプロの実験と改善の例
雑談 • クリエーションライン社の取り組み • https://www.creationline.com/blog/tadahiro-yasuda/31156 • なお講師がアジャイルコーチとして支援しています • Weekly朝会で全社員がお互いに雑談する • たくさんの実験 • • • • 時間設定 人数 メンバー 雑談テーマ • 効果 →
継続的に価値を届ける • ユーザー価値に集中する • 継続的に、頻繁にデリバーする • 毎週～毎日程度 • サービス内容にもよる • 届けた結果を見る • フィードバックを得る • 新たな実験の材料とする
人々を最高に輝かせる • 成果を得るために最も大切なのは人 • 個人と人々 • 最高に輝いている個人・チームが最高の結果を出せる
従来型 ウォーターフォール アジャイル
プロセスや ツール よりも 個人と対話 を 価値とする こういう ちがいを 言ってんじゃ なくて！ まず ひとり一人のことを尊重し考える ここから 考えるように 変わりましょう ってこと！ そして 人々のやり取り、対話、協調を考える
アジャイルなソフトウェア開発の4側面
https://speakerdeck.com/kawaguti/kanban-and-scrum
1994 (GoF) 1986 1999 1995 2003 2001 参考: 1991 - Linux 1996 - Java 1.0 2001 – Windows XP 2002 - .NET Framework 1.0
アジャイルとは？ • 「アジャイルな開発」を実現できるような 人、組織、環境、ビジネスを作ること？ • アジャイルな開発から得た知見を 人、組織、環境、ビジネスに応用すること？ どちらにしても、 開発だけ 運用だけ ビジネスだけ 経営だけ 人事だけ 。。。の話ではない！
アジャイルな開発の特徴 • ビジョンや目標を共有し、全体がそこに向かっている • ルール、プロセス、手法が常に変わり続けている • アウトカム(結果)を重視している • 「そこにいる人びと」ならでは、になっている • 顧客やステークホルダーの信頼を得ている • 市場競争力を維持している • 自主性があり、いきいきして、学び続けている こうした観点からKPI・KGIを選ぶ
アジャイルな人や組織の特徴 • ビジョンや目標を共有し、全体がそこに向かっている • ルール、プロセス、手法が常に変わり続けている • アウトカム(結果)を重視している • 「そこにいる人びと」ならでは、になっている • 顧客やステークホルダーの信頼を得ている • 市場競争力を維持している • 自主性があり、いきいきして、学び続けている こうした観点からKPI・KGIを選ぶ
アジャイルの指標例 • • • • • • 実験の頻度、健全な割合で失敗しているか ビジョンの認知と腹落ち度 顧客やユーザーからのNPS(ネットプロモータースコア) 価値提供の頻度 メンバーの成長と流動性 ソフトウェア開発の場合 • リリースと測定の頻度 • CI、CDの頻度と所要時間 • テストの自動化カバレッジ ※コードカバレッジではなく、テストの自動化カバレッジ • ソースコードの変更頻度(既存コードをちゃんと直しているか)
スクラムの位置づけ • 2000年代後半から、アジャイル移行≒スクラム導入 • アジャイル手法として、66％～81％がスクラムを採用 • https://digital.ai/resource-center/analyst-reports/state-of-agile-report • 書籍、事例、トレーニングなどが豊富 • スクラムアライアンスの認定スクラム研修 • 学習と成長を促す • 自分だけのプロセスを作る • スクラム自体は「軽量なフレームワーク」であり、プロセスではない
開発 ビジネス 経営 人事 ビジョン プロダクトの プロダクトの 価値 価値 長期 世界・世間 組織文化 変化 能力を発揮 能力を発揮 するチャンス するチャンス 差をつける チャンス 常に・あたり まえ スキルアッ プ・チェンジ アウトカム ユーザーに ユーザーに 新たな展開 とっての価値 とっての価値 コアバリュー の不変 現場の声 信頼と実績 フィードバッ クを生かす 現場を信頼 採用より成 長重視 いきいき 運用 フィードバッ クを生かす 三方良し 個々の強み、チームの力、モチベーション、誇り
マインドセットの違い ガチガチマインドセット • 能力 – 不変、背の高さなど • ゴール – 良く見られる • 挑戦 – 避ける • 失敗 - 個人的な問題 • 努力 - 能力がない人がやる • 困難に直面すると – 無力 アジャイルマインドセット • 能力 – 成長、筋肉など • ゴール – 学ぶ • 挑戦 – 受け入れる • 失敗 – 情報を得られる • 努力 – 熟達への道 • 困難に直面すると – 回復力(レジリエント)
アンケート: 自分にとってアジャイルとは？ • ここまでの話から、アジャイルという考え方が自分にどう関わるか、 自分ならどんなところにアジャイルをあてはめたいか、思いついた ことを書いてください。 • 複数回答可です(送信した後で追加できます) • 時間が余ったらおすすめのランチやおやつについて書いてください • 録画視聴の方も手元で書き出してみてください
アジャイル への たどり着き方
価値、原則、プラクティス • 価値 = 究極の目的 • プラクティス = 実際の具体的なやり方 • 原則 = プラクティスがなぜ価値につながるかの説明
お仕事 頑張ってますか？
何のために お仕事 頑張ってますか？
何のため＝価値 • 価値とは ほしいもの • ただでは手に入らない
価値 プログラム 機能 フィーチャ コスト
どれを選ぶ？ B A 価値 コスト C D
価値が大きく 早くできるものから 1 2 3 4 C B D A
コスト≒時間 A D B C コスト
価値は時間累積 A D B 価値 累積価値 C 時間
価値は時間累積 A D B 価値 累積価値 C 時間
大価値短期間＝高ROI 1 2 3 4 C B D A
A A A A A
価値とはほしいもの • 顧客価値 • 情報、リスク対策 • 生産性
早いほうがいい 細かいほうがいい 先のことも考えたほうがいい
プラクティス 原則 価値 イテーレション インクリメンタル リリース計画 累積価値 早く作る 小さく作る 先まで考える ほしいもの ユーザーにとっての価値
簡単 ですね♪
簡単な わけがない 💀
人
人々
こんなに難しいことを実現する 仕組みを作るのは困難 こんなに難しいことを実現する 工夫を作れる人 難しいことを個人に頼らず 維持できるチーム
チームを単位とする 「チーム学習はきわめて重要である。なぜなら、現 代の組織における学習の基本単位は個人ではな くチームであるからだ。…チームが学習できなけ れば、組織は学習し得ない。」 https://www.amazon.co.jp/dp/B071WR7XMH 「チームというものは完成することはないが、それ でも方向性をそろえて、価値を継続的、持続的に 提供するには最善のアプローチだ。チームはやる 気のあるメンバーで構成され、長期的に維持さ れ自律的であるべきだ。」 (英語版から拙訳) https://www.amazon.co.jp/dp/B09MS8BML8/
ハックマンモデル https://note.com/ama_ch/n/nb9deb86337c7
モチベーション3.0 • 自律 • 熟達 • 目的 自分のやり方で集中することで より上手になり、できることも広がり そうして大きな目標を目指せれば モチベーションが上がる
チームによる学習
← 大 パニック 責 任 学習 → 快適 小 低← 能力 →高
← 大 パニック 責 任 学習 → 快適 小 低← 能力 →高
心理的安全 (Psychological Safety) 「チームの心理的安全とは、対人のリスクを取っても安全であるという 、チーム全員の信念である」 “Psychological Safety and Learning Behavior in Work Teams” Amy Edmondson, 1999 Amy C. Edmondson https://twitter.com/amycedmondson 「「心理的安全」とは、関連のある考 えや感情について人びとが気兼ね なく発言できる雰囲気をさす。」
図3. グルー プレベルで 研究した心 理的安全性 の関係
学習する組織 • システム思考 – 全体を考える • メンタルモデルへ意識を向け見直す • 共有ビジョン ― 「自分たちはなにを創造したいのか？」 • チーム学習とアラインメント(合致) • 経営者を含むマネジメント全体の意識変革 『学習する組織』ピーター・M・センゲ
プラクティス 自己組織化 クロスファンクショナルチーム チーム維持の方針 原則 ハックマンモデル チームの学習・成長モデル 心理的安全性 価値 強いチーム 学んで成長するチーム
お仕事 頑張ってますか？
誰のために お仕事 頑張ってますか？
誰が 誰のために お仕事 頑張ってますか？
コミュニケーション
情報帯域
パス＝3本 1人2本 パス＝10本 1人4本 コミュニケーションパス パス＝66本 1人11本
伝言ゲームと 情報劣化
価値を提供するすべてのスキルを一緒に ビジネスも技術もマネジメントも一緒に ユーザーも顧客も開発も一緒に できるだけ少人数で
簡単な わけがない 💀
プラクティス 全員同席 クロスファンクショナルチーム 情報ラジエーター 原則 フェイス・トゥ・フェイス 少人数 ビジネスと開発が一緒 価値 効果的なコミュニケーション
手戻り
技術的負債
機能追加とコスト 価値 時間
利 子 圧 縮 価値 コスト 時間 圧 縮 コスト 時間 技 術 的 負 債 技 術 技術的 的 負債 負 債
技術的負債 • 一時的なメリットを与える(レバレッジ) • 開発したソフトウェアに内在する • 開発の作業効率を悪化させる • 除去作業をしないと取り除けない • 放置すると増殖する
技術的負債 • 不適切なエンジニアリングで発生する • 能力不足 • 圧力、プレッシャー • 考慮不足 • 将来は本質的に予測できない • 「考慮不足」は不可避 • 「キレイ」な状態を… 最初にちゃんとする → 不可能 or どこかで破綻する 維持する → 常時リファクタリングを続ける • 負債をためすぎないうちに返済する • 将来予測 → 変更容易
変更容易性 • 設計がシンプル • 変更箇所と内容が自明 • 依存関係が少ない • 特に隠れた依存関係 • 実装もシンプル • 誰でも安心して変更できる • 自動化したテスト • リグレッション • 常にこの状態を維持する • 厳しい規律 • だんだん難しくなる
品質と規律
簡単な わけがない 💀
プラクティス 原則 価値 CI/CDと自動テスト リファクタリング 開発者発の厳しい規律 ユーザー価値優先 シンプル アーキテクチャ 品質が高いと開発が速い 変更を歓迎する 内部品質と変更容易性
https://speakerdeck.com/twada/quality-and-speed-2020-autumn-edition
プラクティス
プラクティス • Practice = 練習 実践 • HOW • なぜやるのか、なんのためにやるのか • ノウハウではない • 必須でもない 必要性から要請される • 実験の対象 • うまくいくかどうか やってみて改善 • 実際のやり方はみな違う
プラクティスの問題 • 世の中にたくさんある • 意識的にプラクティスを取捨選択する • 環境や人の変化に合わせプラクティスも変える
超基本プラクティス • 朝会 / デイリースタンドアップ / デイリースクラム • 短期間サイクル / イテレーション / スプリント • タスクボード / スプリントバックログ • ふりかえり / レトロスペクティブ
朝会 / デイリースタンドアップ • チーム全員 • 毎日、同じ場所、同じ時間で • 状況と問題を共有する • 立ったまま、15分以内 • 現状を踏まえて計画を見直す https://www.slideshare.net/yattom/project-facilitation-from-hiranabe
イテレーション • 1～4週間程度をサイクルとして、仕事を完成する • 仕事を完成する • 1機能の要件定義、設計、実装、テストまで • できるように仕事を小さく分割する • イテレーション冒頭で計画づくりをし、終わりでふりかえりをする • イテレーションの成果から毎回フィードバックを得る
ふりかえり / レトロスペクティブ • チーム全員 • 仕事のやりかたを見直す • 改善アクションを出す • チームが自分自身で実験する
タスクボード • チーム全員のタスクを見える化 • 状況を日々アップデート • 見れば誰でも全体の様子がわかる • 順調でなければ誰でもアクションできる
朝会、ふりかえりを学ぶ • プロジェクトファシリテーション 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
- 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
スクラムのプラクティス • 3つの役割 • プロダクトオーナー、開発者、スクラムマスター • スプリント、プロダクトゴール、スプリントゴール • 5つのイベント • スプリントプランニング、スプリントレビュー、 デイリースクラム、レトロスペクティブ、リファインメント • 3つの作成物 • プロダクトバックログ、スプリントバックログ、 プロダクトインクリメント
https://www.servantworks.co.jp/resources/scrum_overview_figures/
XP(Extreme Programming)の プラクティス 主要プラクティス • 全員同席 • チーム全体 • 情報満載のワークスペース • いきいきとした仕事 • ペアプログラミング • ストーリー • 週次サイクル • 四半期サイクル • ゆとり • 10分ビルド • 継続的インテグレーション • テストファーストプログラミング • インクリメンタルな設計 導出プラクティス • 本物の顧客参加 • インクリメンタルなデプロイ • チームの継続 • チームの縮小 • 根本原因分析 • コードの共有 • コードとテスト • 単一のコードベース • デイリーデプロイ • 交渉によるスコープ契約 • 利用都度課金
https://speakerdeck.com/kakutani/xpmatsuri2019-keynote
DevOpsプラクティス • アジャイルプロジェクトマネジメント • シフトレフト • ビルドツールチェイン • 自動化 • パイプラインの監視 • 運用容易性 • 継続的フィードバック • 文化変容 https://www.atlassian.com/devops/what-is-devops/devops-best-practices
プラクティスの難しさ: マニュアルではない • 実際にやるのはプラクティス • プラクティスをやるだけでは価値に近づかない • 「なんのため？」と「なぜ？」を意識し続ける • 自分たちがねらっている価値を共有し、理解を深める • 価値に到達する原則について全員で勉強する
プラクティスの難しさ: 練習しないと上達しない • ただやろうとしても、なかなか上手くいかない • 我流になってしまって効果が上がりにくい • 実践(=プラクティス)の中で、繰り返し練習(=プラクティス)する • 繰り返しながら、自分たちで常に見直し続ける × やれているか △ 型通り・お手本通りか ○ 価値に近づいているか • お手本、ガイド、指導者などを活用する
守破離 能、茶道、剣道などの教え 離 破 守 自分自身が独立し、流派を作る、 自らが師匠になる 新たな価値を生み出す 自分なりの試行錯誤をしたり、他流のやり方を取り込んだりする 精神、メカニズム、理論を身につける 師匠につき、言われたとおりのことが完璧にできるよう修練する 基礎を身につける
プラクティスの難しさ: 独立したテクニックではない • プラクティス同士の相互作用がある • 単体では効果が上がりにくい • 同時にたくさん導入すると失敗する、難易度が高くなる • やりやすい、導入しやすい順序がある • ひとつずつ導入する • ちゃんとできるようになるまで、他のことに手を出さない
プラクティス同士の相互作用 朝会 現状 見直し リズム 更新 イテレーション 作る 見返す 次回に 生かす ふりかえり タスクボード 思い出す
https://www.amazon.co.jp/dp/B08711ZCPY
プラクティスの難しさ: 計画通りには導入できない • 期待したようにも、予定通りにも進まない • 予想外の出来事や結果は、自分たちについての新たな発見 • 試行錯誤しながら自分たちについて理解を深めていく • 計画通りに進まないことを計画する • • • • • 全員で計画づくりをする 計画変更を計画に含める 計画変更につながる情報収集を計画する 計画変更の工数が小さくなるよう、計画の詳細度をコントロールする 計画変更の量や回数を指標とする(少なかったら問題)
アジャイルな見積りと計画づくり • アジャイルで計画はたいへん重要 • 必要なだけ計画する • 変化を前提として計画する • 出来上がった計画 よりも 計画づくり を重視する • プランニング・オニオン 参考： 「アジャイルな見積りと計画づくり」 マイク・コーン著 角谷信太郎、安井力訳 https://www.amazon.co.jp/dp/4839924023 EMZERO Vol.3.1(マナスリンク)より引用 http://www.manaslink.com/articles/75
プラクティスの難しさ: 難しい • 難しいので、あきらめがち • 難しいので、簡単な方法を探しがち • 難しいので、自分はいいやと思いがち • 難しいので、非難されがち • 信念と熱意のある人が必要(知識もあるとよい)
新しいことに取り組むのは常に難しい • 信念と情熱のある人が必要 (1 エバンジェリスト) • 小さく試して小さく成功させる (2 小さな成功) • 大きな理想を一歩ずつ実現する (3 ステップバイステップ) • 自分の不足を認めて助けを請う (6 協力を求める) • 先見性のある人を集める (11 アーリーアダプター) • とにかく試してみる (17 やってみる) • 権限ある人に認められる (28 経営層の支持者) • やるといいことがあるという気配で人を引き寄せる (40 成功のにおい) https://www.amazon.co.jp/dp/462108786X
プロセスや ツール や、プラクティス よりも 個人と対話 を 価値とする こういう ちがいを 言ってんじゃ なくて！ まず ひとり一人のことを尊重し考える ここから 考えるように 変わりましょう ってこと！ そして 人々のやり取り、対話、協調を考える
アンケート • 質問として、詳しく聞きたいプラクティスを書いてください • 具体的に導入を検討していたり、やっているけれど困っているなど • 資料で触れていないものでもOKです
アジャイルと 向き 不向き
アジャイルの向き不向き • 効果が期待できるプロジェクト、プロダクト • 能力を発揮する個人の性向 • チームや組織の、ルールや文化
カオス 複雑 込み入った シンプル
ステイシー マトリックス https://logmi.jp/tech/articles/323254
ステイシー マトリックス https://logmi.jp/tech/articles/323254
ワードリー マップ えっ、 そんなこと できるん でっか？ なんで そんなこと してるん でっか？ もうかって まっか ？ On Pioneers, Settlers, Town Planners and Theft. by Simon Wardley http://blog.gardeviance.org/2015/03/on-pioneers-settlers-town-planners-and.html
クネビンフレームワーク 複雑な領域では 探査→知覚→対応 という行動を採る 解決方法は 出現する (Emergent Practice) https://www.slideshare.net/kiroh/ss-14929935
よくある障害 • 上司が理解してくれない • 部下、現場が理解してくれない • 他部門、顧客が理解してくれない • 契約やコンプライアンスの壁がある • 開発スキルが足りない • 既存のコード、システム、サービスがある • 時間がない • 予算がない • 人材が足りない
よくある障害 • 上司が理解してくれない • 部下、現場が理解してくれない よくある！ • 他部門、顧客が理解してくれない 対処し乗り越える対象 • 契約やコンプライアンスの壁がある 障害を発見する • 開発スキルが足りない のがスクラム • 既存のコード、システム、サービスがある • 時間がない • 予算がない • 人材が足りない
マインドセットの違い ガチガチマインドセット • 能力 – 不変、背の高さと同じ • ゴール – 人から良く見られる • 挑戦 – 避ける • 失敗 - 個人的な問題 • 努力 - 能力がない人がやる • 困難に直面すると – 無力 アジャイルマインドセット • 能力 – 成長、筋肉などと同じ • ゴール – 学ぶ • 挑戦 – 受け入れる • 失敗 – 情報を得られる • 努力 – 熟達への道 • 困難に直面すると – 回復力(レジリエント)
アジャイルマインドセット • 実験： 「ガチガチ」と「アジャイル」マインドの2グループ • 簡単な試験を受けてもらう • 次の試験を選ばせる • ガチガチ → 簡単なものを選ぶ • アジャイル → 難しいものを選ぶ • 他の人にアドバイス • ガチガチ → アドバイスしない、嘘をつく • アジャイル → アドバイスする • 2つのグループの違いは？ • ランダムに分けただけ • ガチガチ → 結果をほめられた • アジャイル → 努力をほめられた https://www.slideshare.net/agiledays/linda-rising-the-power-of-an-agile-mindset
アジャイルマインドセット • 実験： 「ガチガチ」と「アジャイル」マインドの2グループ • 簡単な試験を受けてもらう • 次の試験を選ばせる • ガチガチ → 簡単なものを選ぶ • アジャイル → 難しいものを選ぶ • 他の人にアドバイス • ガチガチ → アドバイスしない、嘘をつく • アジャイル → アドバイスする • 2つのグループの違いは？ • ランダムに分けただけ • ガチガチ → 結果をほめられた • アジャイル → 努力をほめられた https://www.slideshare.net/agiledays/linda-rising-the-power-of-an-agile-mindset
障害を乗り越えるアジャイルマインド • 結果を出すのが大事 → 努力するのが大事 • 「頑張ります！」では大雑把 → プロセスや経過、判断や行動を細かく識別、把握する • 小さな失敗をたくさん見つけて情報を得る • 個人の責任、自分の作業を完遂する → チームの責任、全体で価値を完成する • 人は人、仕方ない → 人はつながり、変化する
アジャイルを “やってみる”
Unlearn まなびほぐし
Unlearn / 脱学習 / まなびほぐし • アジャイルに限らず、今までのやり方を変えるときに必要 • 今までのやり方＝今までに学んだことを、いったん脱ぎ捨てる • うまくいくかわからなくても、やってみる • うまくいかないとわかっていても、やってみる • 過程を精緻に分析し、知見を得る • 結果はあまり気にしない • 結果の良し悪しより、予想とのズレに注目する • 新たな学びに向け、今までの知識を壁にしない
学ぶゆとり • 自分で考えるのが大事 • とはいえ、学ぶべきことはたくさん • 個々人、チーム、部署、組織として学ぶ • そのためのゆとりを確保する • ふりかえり / レトロスペクティブの時間 • 仕事の中で実験する時間
超基本プラクティス • 朝会 / デイリースタンドアップ / デイリースクラム • 短期間サイクル / イテレーション / スプリント • タスクボード / スプリントバックログ • ふりかえり / レトロスペクティブ • 「プラクティスは難しい」を忘れずに
ユーザー価値に集中する • プロダクトの価値とエンドユーザーが得る価値を整える • 自分たちの行動、ルール、プロセスを再検討する • ユーザー価値の観点から • 「その仕事はユーザーにどう役立つの？」 • ユーザーを理解する • 観察(ハイテク人類学) • 直接会って話を聞く • ペルソナ
フィードバック • エンドユーザーの反応、要望、ニーズを最優先する • それ以外は調整すべき利害関係者(ステークホルダー) • エンドユーザーからチームが直接情報を得る • 行動分析 • インタビュー • ベータテスター • 情報を持ったチーム自身が決断し行動する • 自身が判断し、行動し、結果を見て、改善する • 上司・マネージャ・他部門・アナリストなどのせいにしない
チームに任せる • 環境を与える • 場所、空間、オフィス • 機材、インフラ • 支援を与える • 他からの介入を防ぐ • 問題・課題を解消する • 信頼する • 放っておく！
組織を変えるか 組織を作るか • 既存の組織、ルール、人の考え方、文化を変えるのは大変 • 新たに組織を作る方が簡単(な場合もある) • 出島的な部署 • 別会社 • オフィスも別にする • ゼロベースで新しいやり方に取り組めるような環境 • フルタイム • 十分な権限 • 報告させない、マイクロマネジメントしない、我慢して任せる
組織を変えるか 組織を作るか • いまある組織を変えたい • 小さく始めて育てる • 1つのプラクティスを小規模に始める • チーム単位(3～10名程度) • 1人では続かない • 周囲が邪魔しないよう守り育てる • あなたも邪魔しないように • 成果が上がってから少しずつ広げる • 『Fearless Change』を参考に
メンローイノベーションズに学ぶ • 社長が最強のビジョンを持つ • XPとデザイン思考(IDEO)をベースとする • やるべきことを決め、できる人を集め、徹底的にやる • そこから新たな工夫、実験、失敗からの学びを繰り返す • 何年もかけて上手になっていく • 情熱 • 権限 • 時間
開発技術の更改 • アジャイル20年の歴史は開発技術の進歩と表裏一体 • アジャイルなソフトウェア開発に最低限必須な技術を導入する • イテレーション単位で開発ができるスキルとテクノロジーを修得する
すでに常識の開発定番技法 • バージョン管理システム • ビルド自動化 • コードの共同所有 • テストの自動化 • 継続的インテグレーション(CI) • 開発環境の標準化 • コンテナ • DevOps
すでに常識の開発定番技法 • バージョン管理システム – 1982年(昭和57年) RCS • ビルド自動化 – 1976年(昭和51年) Make • コードの共同所有 – 1960年代(昭和40年頃) 『プログラミングの心理学』のエピソード • テストの自動化 – 1989年(平成元年) SUnit • 継続的インテグレーション(CI) – 1997年(平成9年) XP • 開発環境の標準化 – 2010年(平成22年) Vagrant • コンテナ – 2000年(平成12年) FreeBSD Jail • DevOps – 2009年(平成21年)
(ちょっとだけ)新しめの当たり前の技術たち • 分散バージョン管理システム – 2005年 Git • ビルド自動化システム – 2011年 Jenkins • コードの共同所有 – 2008年 GitHub • E2Eテストの自動化 – 2004年 Selenium • 継続的デリバリー(CD) – 2010年 書籍”Continuous Delivery” • 開発環境の標準化 – 2010年 Vagrant • コンテナ – 2013年 Docker • DevOps – 2009年
変更可能な設計 • イテレーション単位で機能を完成する • ほぼすべての開発は改修・変更 • 包括的な設計・アーキテクチャ → 変更容易な設計・アーキテクチャ • 要素技術 • • • • オブジェクト指向設計 ドメインドリブンデザイン(DDD) クリーンアーキテクチャ マイクロサービス(MSA)
テスト自動化 • 常に変更するコードの品質を担保し続ける • 手動テストでは早期に破綻する • ソフトウェアの正しさを動作で検証する • レビューなどの手法も併用すべき • 自動化すべき領域を識別する 詳しくはこちらも（宣伝) 講演動画もあります https://youtu.be/vrbMKbdV6xY https://speakerdeck.com/yattom/tesutofalsezi-dong-hua-totesutoqu-dong-kai-fa
継続的デリバリー • 開発作業から本番リリースまでの過程を自動化し、継続実行する • 属人性(人の作業や確認)を減らす • • • • • 手順書 → 自動化する チェックシート → 自動化する レビュー → 機械的チェックや正しさの確認は自動化する テスト → 手順で進めるテストは自動化する リリース作業 → ワンタッチで完結するよう自動化する • 人間性を生かす作業に時間を使う • • • • 議論する もっとよいアイデア、設計、手法を見つける 不要な機能、手順、プロセスを削減する 思いもよらない問題、バグを探索する https://www.amazon.co.jp/dp/B074BQQ96X
技術やツールの権限を与える • チーム自身が、ユーザー価値に最適な技術やツールを選定する • 会社ルール、取引先都合、新しもの好きの誰かなどに振り回されない • 新しい技術やツールに工数を確保する • 調査、学習、実験する時間 • 既存コードを適合させる時間 • うまくいかなかったとき切り戻す時間 • チームの挑戦と成長に価値をおく • 長い目でユーザー価値につながる
いきいきと働く • ユーザー価値に集中する • 大局的プロダクト価値を目標とする • ツール、プロセス、プラクティスに挑戦し、習熟する • 個々人が自律的に能動的に働く • チームとして個人の能力の総和以上の結果を出す • 他からの介入は最低限 • 仕事に「Joy」があふれる
プロセスや ツール よりも 個人と対話 を 価値とする こういう ちがいを 言ってんじゃ なくて！ まず ひとり一人のことを尊重し考える ここから 考えるように 変わりましょう ってこと！ そして 人々のやり取り、対話、協調を考える
individuals and interactions
アジャイルコーチに手伝ってもらう やっとむ / 安井力(やすいつとむ) 2001年ごろアジャイルと出会い、開発者、チームリー ダー、トレーナー、導入支援と多様な立場で関わってき た。(株)永和システムマネジメントにて2010年頃からア ジャイルコーチを主軸として活動。2014年独立。 [email protected] twitter:@yattom プログラマー https://www.linkedin.com/in/yattom/ Python JavaScript Java C/C++ アジャイルコーチ (プロセス面) チームビルディング 現場導入支援 スクラムマスター支援 ふりかえり アジャイルコーチ (ものづくり面) モブプログラミング テスト駆動開発 テスト自動化 学びのゲームをデザイン、製作、デリバリー 宝探しアジャイルゲーム カンバンゲーム 心理的安全性ゲーム https://www.facebook.com/yattom
質問への回答 • Mentimeterのほうに書き込んでください
おすすめ書籍など • 『アジャイル開発とスクラム 第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 • 技術的側面からアジャイルに必須の技法を解説
アンケート: なにをやりたくなりましたか？ • 以上の話を踏まえて、いまやりたいこと、やってみたくなったことを自 由に書いてください。複数回答できます(送信したあと追加で回答で きます) • 時間が余ったら好きな音楽や動画、テレビや映画について書いてくだ さい • 録画視聴の方も、手元に書き出してみてください