Upgrade to Pro — share decks privately, control downloads, hide ads and more …

10 min de Scrum 2021

10 min de Scrum 2021

「10分でスクラム」スクラムをほかの人に伝えたくなったときに、私は何をしたか。
https://confengine.com/conferences/scrum-fest-mikawa-2021/proposal/15918/10

Scrum Fest Mikawa 2021

A64ac825509279a770c13c6fc517f11a?s=128

Yasunobu Kawaguchi
PRO

October 02, 2021
Tweet

Transcript

  1. 10分でスクラム

  2. 川口 恭伸 かわぐち やすのぶ Twitter: @kawaguti アギレルゴコンサルティング株式会社 シニアアジャイルコーチ 株式会社ホロラボシニアアジャイルコーチ 一般社団法人スクラムギャザリング東京実行委員会

    代表理事 一般社団法人 DevOpsDays Tokyo 代表理事
  3. アギレルゴコンサルティング株式会社 株式会社ホロラボ 所属企業両方で、 スポンサーさせて いただいております

  4. 10分でスクラムとは https://www.slideshare.net/kawaguti/ 20110118-scrum-10-mins 2011年1月にスクラムの共 同開発者のJeff Sutherland 博士とGabriele Benefield さんによる日本初の認定スク ラムプロダクトオーナー研修

    (CSPO)の後に、カッとなっ て作った資料。
  5. 10分でスクラムとは https://www.publickey1.jp/blog/11/10_5.html Innovation Sprint2011で の野中先生、Jeffさん、東証 宇治さんなどの発表を記事に していただいた、PublicKey 新野さんにご紹介いただき、 結構読まれました。

  6. Innovation Sprint http://innovationsprint.com 平鍋さんと、ピークワン前田 さんとで企画した、初めての スクラム大きなイベント。よ しおかさん仲介で品川シーサ イド楽天タワーの朝会会場を お借りして開催。野中先生と ジェフを会わせるイベント。

  7. 当時のスクラム事情 日本国内での通訳付きの認定スクラ ムマスター研修(CSM)の開催数はま だ数回(私の観測範囲では4回とか)。 私はXP祭り、オブジェクト倶楽部に 参加してました。 2009年から始まったすくすくスク ラムには常時30人以上集まったりし てました。

  8. 私のスクラム事情 2008年のXP祭りでScrumを 知り、懇親会でCSM取得した 林栄一さんと知り合い、 2009年から予算が取れて社 内試行。スクラムマスターは 同じ部署にいた、江端一将さ ん。一緒にすくすくスクラム を立ち上げて、会社の会議室 で開催しました。

    Bas Voddeさん Jim Coplienさん 2009年にBasさんのCSMを受 講し、2010年末にJim Coplien さんのCSMをオーガ ナイズしました。
  9. 先行者の言葉 2008年のデブサミで栃木の 関将俊さんのセッションに参 加。すでに8年アジャイル開 発をやっている関さんから、 社内でなにかを始めるときに 大事なのは「信頼貯金」だと いうアイデアを聞く。あれ、 しまった、やれてないのは自 分のせいじゃん。

  10. 私のプロダクト 自分が絡む二つのチームでス クラムをやってみました。一 つは新規開発・新しいチーム。 ニュース配信の仕組みに画像 を追加するというもの。ス テークホルダが3,4 部署に絡 まっていて、実現していな かったのを簡易な仕組みで実

    現。運用負担も軽減。
  11. 私のプロダクト2 もう一つは既存のインフラ運 用者を引き継いだもので、デ プロイの自動化を実現するだ けでなく、定期的なスケ ジュール(=スプリント)と緊 急リリースのフローを作り、 チームメンバーが自律的に要 望を受けられる仕組みにしま した。

  12. 私はどうしたかった? それまで難しかった「引継 ぎ」をやらなくていい仕組み を手に入れ、メンバーは育っ ている感じ。作っているもの も安定稼働して会社の収益を 支えている。これを続けるた めには、正当化も必要。みん ながスクラムやれば、もっと やりやすくなるに違いない。

  13. すくすくスクラム 社外にもスクラムを普及させ たい江端さんが立ち上げたい ということに協力。会議室を とるとかビデオ撮るとか、そ ういう作業をだいたい手伝い ました。MS長沢さんにサイ ト作っていただいたり、日経 ソフトウェアさんにも取材し ていただきました。

  14. 勉強会カンファレンス 2009年に勉強会カンファレ ンスのスタッフをやりました。 どうやったら企業の場所を借 りて勉強会やるのかとか。 よしおかさん、岩切さんとは ここで出会っています。 https://gihyo.jp/news/report/ 2009/06/0802

  15. XP祭り 2009年まで実行委員長だっ た倉貫さんが、実行委員の公 募制を提案したことを受けて、 2010年1月の実行委員会の 募集を立候補して、引き受け ました。すくすくスクラムを やっている会社の会議室で第 一回ミーティング。 https://enterprisezine.jp/iti/

    detail/2676
  16. AgileUCD 研究会 2009年にAgile Conference に初めて参加す るにあたって、興味のあった 人間中心設計(UCD)とAgile の関係について樽本徹也さん に教えを請うところから始 まった勉強会。Jeff

    Patton について注目したのもここか ら。 https://enterprisezine.jp/iti/ detail/2676 ※樽本さんは古田一義さんに紹介していただき ました。次のセッションは古田さんとやります。
  17. スクラムギャザリング東京 2011年10月に第一回のスク ラムギャザリング東京を開催。 キーノートは Henrik Knibergさんと Jeff Patton さん。今、考えてもベストメ ンバーだったと思います。熱

    気あふれたカンファレンスに なりました。今年のセッショ ン公募は10/15まで! https://confengine.com/conferences/ regional-scrum-gathering-tokyo-2022
  18. できることの積み重ね 「おそらく確実にできるこ と」の要素を思い浮かべて、 その組み合わせだけで、いま やりたいなーと思っているこ とをうまいこと実現できない だろうか。ほかの人が見過ご していそうな新しい結合がな いだろうか?社会に貢献でき るところはないか?

  19. ハイキュー!! 14巻より • 烏野高校の精神的支柱であり、 守備の要(かなめ)である主将の 負傷退場の穴を埋める、 二年生のリーダー。 • スキルも経験も統率力も主将には 遠く及ばない、レギュラーでもない

    ことを自認しながら、チームのために 尽くした。 • 基本を思い出すこと。練習の通りに やること。全員がベストを尽くすこと。 自分で考えること。 「バタバタしない。 良いジャンプは、良い助走から。」
  20. イノベーターにならない 一方で、Fearless Change にあるとおり、新しいことを 追いかける人、イノベーター にはなってしまうと、「また 新しいことをやっている」と いうレッテルをもらって、 放っておかれることになるの で、とにかく継続できること

    を低燃費でやり続けたい。
  21. 10分でスクラム https://www.slideshare.net/kawaguti/ 20110118-scrum-10-mins 2011年のCSPO研修は会社 からも5人受けてもらうこと ができました。社内の予算や 私の働き分で枠作って。受講 後、一人が「うちではできな いと思います」と打ち明けた ので、カッとなって一晩で

    作ったのがこのまとめ資料。
  22. ということで 初代の10分でスクラム

  23. None
  24. None
  25. None
  26. None
  27. None
  28. None
  29. None
  30. None
  31. None
  32. None
  33. None
  34. None
  35. None
  36. None
  37. None
  38. None
  39. None
  40. None
  41. None
  42. None
  43. None
  44. None
  45. None
  46. None
  47. None
  48. None
  49. None
  50. None
  51. None
  52. None
  53. None
  54. None
  55. None
  56. None
  57. None
  58. None
  59. None
  60. None
  61. None
  62. None
  63. None
  64. None
  65. None
  66. None
  67. None
  68. None
  69. None
  70. None
  71. めざしたこと https://www.slideshare.net/kawaguti/ 20110118-scrum-10-mins 相手に説明するときに、自分 なりのまとめ資料を作ってみ る。特定の相手に向けて資料 を作れば、どんな内容が響き そうか、一歩一歩検討ができ る。説得ではなく、情報を提 示する。相手を動かすのでは

    なく、理解を高めてもらう。
  72. スクラムが見直しをせまっていること 1. とりあえず期限決めましょう 2. 相手に約束させて履行を迫る 3. 一人でやった方が早い 4. まだ見せられません 5.

    まだ時間あるからもうちょっと 6. なんのためにやってるんだっけ? 7. 誰のせいかを明確にする 8. 管理だけを仕事にする 9. 現物を見ないで進める
  73. 竹内野中論文(1986)が示した マネジメントスタイル • Type A NASAのウォーターフォール型 • 要求、分析、設計、実装、試験と、 順に次の工程の部署に引き渡される •

    Type B 富士ゼロックスのサシミ型 • 前工程と後工程が同席する • Type C ホンダのスクラム型 • 一時は全工程が同席する Jeff SutherlandはこのType Cから、 自らのフレームワークの名前を とった。 https://www.infoq.com/presentations/The-Roots-of-Scrum/
  74. コマンド&コントロールを打ち破る • 旧来の企業では、戦略は中央で作られる • それぞれの現場で、創発的な戦略が自己 組織される • 分散化された認知とアクション • スクラムチームは、

    自己組織化を許されなければならない • 自働的 Autonomous • 卓越的 Transcendent • 他家受粉 Cross-fertilization • チームは自らの仕事を選択する • それぞれの個人は自らの仕事を管理する • マネジメントを排除する 竹内野中 https://www.infoq.com/presentations/The-Roots-of-Scrum/
  75. https://www.infoq.com/presentations/The-Roots-of-Scrum/ 多様な観点 • 職能横断チーム (クロスファンクショナル) • スクラムチームは(すべての職能を)持つ。 プロダクトの知識、業務分析、UIデザイ ン、ソフトウェアエンジニア、品質保証 •

    さらに進んだスクラムではもっとステー クホルダーを巻き込む ー 経営陣、顧客、 インストール担当、サポート担当
  76. プロダクト バックログ 顧客が求める機能の 優先順位付きリスト スプリントバックログ スプリント内で完成させる機能 機能をより小さなタスクに分解する 新しい機能 スプリントの 終わりにデモする

    毎日15分のミーティン グを行う。 スクラムマスターは3 つの質問をする 1)昨日なにを達成しま したか? 2)ゴールを満たすため に障害になっているの は? 3)明日までになにをた 達成しますか? https://www.infoq.com/presentations/The-Roots-of-Scrum/ スクラムスプリントサイクル
  77. 不確実性が要求する 経験主義的プロセスコントロール • 入力 • 要件 • 技術 • チーム

    • 制御 • プロセス • 出力 • 漸進的にプロダクトが変化 https://www.infoq.com/presentations/The-Roots-of-Scrum/
  78. https://www.infoq.com/presentations/The-Roots-of-Scrum/ トヨタウェイ : Learn by Doing 張富士夫 : 代表取締役社長 2002

    • 私たちが一番重視するのは、実際に実践し、 行動すること アジャイル原則#1 • わかっていないことはたくさんある。だから 「とにかくまずやってみよう」アジャイル原則#3, #11 • 自分の知識の少なさに気づき、自分の失敗に 直面して、もう一度やり直し、2回目の試行で また別の失敗に気づく。そしてもう一度やり 直す。アジャイル原則#11, #12 • 絶え間ない改善によって、より高いレベルの 実践と知識に至る。アジャイル原則#3
  79. トヨタウェイは 冗長性と失敗を許容する • 生物の進化のような創発的プロセスでは、 失敗が生まれる • 早めに失敗し、頻繁に失敗して、 素早く学習し、急速に進化する • 創発的なソリューションに向けた、

    合理的で効果的なアプローチは、 大事故を引き起こす https://www.infoq.com/presentations/The-Roots-of-Scrum/
  80. https://www.infoq.com/presentations/The-Roots-of-Scrum/ スクラムを進化させる Type A, B, Cのスプリント • Type A スプリントで部分的なものしか

    作れないかもしれない • Type B 徐々にオーバーラップさせる • Type C すべてを一つのチームで 自分たちのやり方を現地現物で見つめ、 自分たちで進化させていくのがスクラム。 自分で考えるメンバーを作り、守り、鍛えていく。
  81. https://scrumguides.org/ スクラムの定義のアップデート 『スクラムガイド』 • コミュニティの意見を採り入れて わかりにくい表現をなくしたり、 必須のルールのみを残して、 ベストプラクティスは外し、 ルールブックとして再定義 •

    2020年版で主要なワードが大きく 変わったので、認定を受ける方や 最新の動向を確認したい人は 読んでみてください。
  82. ということで 今日の10分でスクラム

  83. スクラムマスター プロダクトオーナー 開発者(たち)

  84. プロダクトオーナー • プロダクトのビジョンを持ち、育てる。 • ビジョンを達成するためのロードマッ プを考え、提示する。 • 開発チームと協力して、着手可能な仕 様としてプロダクトバックログを作成 する。

    • ステークホルダーやエンドユーザーと 話す。 • 予算を確保する。 • ROIが高くなるようプロダクトバック ログの優先順位をつける。
  85. • 自己組織化して仕事を進める。 • 全員がプロダクトに貢献する。 • 必要な能力をチーム全体でカバーする。 • プロダクトバックログを理解し、 優先順位に従って出荷判断可能な プロダクトインクリメントを仕上げる。

    • プロダクトバックログの各項目に サイズの見積もりをつける。 開発者(たち)
  86. スクラムマスター • スクラムのプロセスがうまく機能する ように、あらゆる手を尽くす。 • チームの集中を妨げる妨害を排除する。 • チームの行く手を阻む障害を取り除く。 • チームに改善をそそのかす。

    • チームの自己組織化を尊重する。 • プロダクトオーナーが機能していない ときは、指導する。 • 指示しないサーバントリーダー。
  87. プランニング スプリント (作業時間) レビュー レトロスペ クティブ スプリント

  88. プランニング スプリント (作業時間) レビュー レトロスペ クティブ スプリント

  89. プランニング • プロダクトバックログを理解する。 • バックログ項目はチームが見積もる。 • チームの実力(ベロシティ)からみて、 どこまで行けそうかを測る。 • 行けそうなところまでのバックログアイ

    テムを完成させるために、チームがどう 動くかを考える。 • よく考えたらダメっぽいなら、もう ちょっと減らす。
  90. スプリント (作業時間) • 集中して仕事をする。 • プロダクトバックログの順番通りに 完成させる。 • やり方はチームが考え、自律して進める。 •

    なるべく多くのバックログアイテムを 出荷判断可能にする。 • どうやると終わるか(完成の定義)は だんだん拡張する。 • 毎日同期し、再計画する = デイリースクラム
  91. レビュー • 動くソフトウェアを利害関係者に デモする。 • 利害関係者に意見をもらう。 • できなかったことがあれば報告する。 • 技術的負債について話す。

    • ロードマップを俯瞰する。 • マーケットの状況を共有する。 • 追加バックログ項目があれば足す。 • この方向で進めることを合意する。
  92. レトロスペ クティブ • なにをやったか話す。 • レビューでどんな意見が 返ってきたか話す。 • 技術的負債について話す。 •

    よかったことや反省点を話す。 • どうしたらもっとよくなるか話す。 • 困ったことがないか聞く。 • アイデアがあれば出す。
  93. デイリー スクラム • 毎日15分以内、立って話す • 3つの質問、昨日やったこと、今日 やること、足を止めているもの • 同じ時間、同じ場所。自動的に。 •

    リーダーへの報告ではない。全員が 自己マネジメントする。 • 問題解決より、見える化優先。 • 残りのスプリントの作業を再プログ ラミングする。
  94. ToDo WIP Done プロダクト バックログ スプリント バックログ 障害リスト

  95. プロダクト バックログ • 優先順位付けされた機能や対応項目のリスト。 何を提供するか(What)。 • ROIが最も高まるように優先順位付けされ、 開発チームは上から順に届ける。 • 各項目の規模は開発チームが見積もる。

    • スプリントで完成した項目の規模の合計が ベロシティ。次も同じくらいいけると考える。 • 開発チームはスプリントごとに、 どうやって実現するか(How)を考え、 スプリントバックログに落とし込む。
  96. ToDo WIP Done スプリント バックログ • スプリントごとに、チームが作成し たタスクリスト。 • プロダクトバックログの上位の項目

    を優先順位に従って届けるための、 開発チームの作業リスト。 • 完成の定義を守る。 技術的負債を溜めない。解消する。 • チームはタスクに群がって作業し、 アグレッシブに終わらせていく。
  97. 障害リスト • チームの進行を妨げる障害をリストにする。 スクラムマスターにとってのバックログ。 • デイリースクラム、レトロスペクティブ などで発見され、まずチームが解決する。 • だれにとってもオープン・正直に。 •

    障害は誰のせいでもない。解決できそうな 課題だけを出すような忖度はしない。 • 障害を一歩一歩取り除いていく。 = 改善 • 解決できないときは組織の問題として 助けを求める必要があるかもしれない。
  98. バックログ リファインメント • 定期的に時間をとって、次回以降の スプリント向けのプロダクトバック ログを見直しておく • 見積もりをアップデートする • 細かくなってないものを分割

    • 直近3スプリント分は十分に細かく • 先のことは書いておくが細かくしな い • スプリント中にやるが、スプリント の集中を乱さない
  99. アジャイルな見積りと計画づくり スクラム普及の立役者の一人、 マイク・コーンのプランニングに 関する名著。 なぜ時間ではなくポイントで見積も るのか?なぜ私たちは計画に失敗す るのか?プロダクトバックログや、 プランニングポーカーに関して最も 詳しく論じられている。 スクラム

    ジェフ・サザーランド博士がいかに してスクラムにたどり着いたのか、 詳細に語られた一冊。ジャーナリス ト出身の息子、JJサザーランドが 大きく貢献をしている。ビジネス書 としてスクラムを押さえるために重 要な一冊。野中・竹内論文にどのよ うに出会ったのかも、細かく書かれ ている。 スクラム現場ガイド スクラムアライアンスの初期の マネージングディレクターであ るケン・ルービンの包括的な スクラム解説書。分厚く、詳細 に書かれている。 エッセンシャルスクラム スクラム適用を長年行ってきた ミッチ・レイシーによる 現場で起こる問題に対応する 実戦的なガイドブック。 ScrumMaster the Book 薄い本だが、スクラムマスター の長い道のりを論じている。ま ずチームのコーチングやメンタ リングを行うこと。チーム運営 の罠はどこにあるか。チームを 越えた組織開発の必要性。