Slide 1

Slide 1 text

アジャイル・スクラム 再入門 RSGT2018, CSM研修を踏まえてパフォーマンスをあげる 開発プロセスについて考えてみる 2018/04/12 yo-iida

Slide 2

Slide 2 text

今日のゴール ● アジャイルとかスクラムについて多少知っていて実践もして いる人向け ● アジャイル、スクラムの原点から知ることで再入門する ● 根底にある考え方を知ることで今後の実践の質を高めるよ うになる

Slide 3

Slide 3 text

なぜ根底にある考え方を伝えたいか ● プラクティスを説明している書籍や資料は多いが、根底にあ る考え方を理解できるものは少ない ● プラクティスを実践するだけでは本質的に使えているのか 形骸化しているのかわかりにくい ● 開発プロセスのパフォーマンスをもっと上げられる.. 可能性があるかも?

Slide 4

Slide 4 text

※プラクティスにはほぼ触れません

Slide 5

Slide 5 text

まだ勉強中の内容でもあり、間違いやあいまいな点があると思います 気づいた点があれば付箋にメモしてください あとで議論の時間をとります では早速 →

Slide 6

Slide 6 text

こんな疑問ない? ● アジャイルってなに? ● スクラムってなに? ● なぜアジャイルなの? ● なぜスクラムなの? ● どこから生まれたの? ● なんのためにやるの? ● そうでない場合と比べてどう変わるの? ● どういう関係があるの?

Slide 7

Slide 7 text

アジャイルとは?

Slide 8

Slide 8 text

> agile ● ag・ile /ˈædʒəl/ ● (動きが)機敏な,はしっこい; 〔…に〕機敏で,はしっこくて 〔in〕. ● 頭の回転の早い,機敏な,明敏な. https://ejje.weblio.jp/content/agile

Slide 9

Slide 9 text

agileは形容詞 ● × do agile. ● ○ be agile. → 状態を表す。

Slide 10

Slide 10 text

アジャイルソフトウェア開発 ● 反復型 ● 短いイテレーション ● イテレーションごとに動くソフトウェアをリリースする

Slide 11

Slide 11 text

[対比] ウォーターフォール開発 ● 最後に動くソフトウェアがリリースされる ● 計画主義

Slide 12

Slide 12 text

スクラムの原典 The New New Product Development Game (1986) by Hirotaka Takeuchi and Ikujiro Nonaka https://hbr.org/1986/01/the-new-new-product-development-game ● 製造業における新製品開発手法の論文 ● ラグビーのスクラムチームのように折り重なって製品開発を 進めていくという概念を打ち出した

Slide 13

Slide 13 text

その後・・ ● Jeff Sutherlandによる最初のスクラム ○ 論文を読んで参考になると考えソフトウェア開発に適応して実践した ● Kent BeckによるXP ● その他いろいろな手法が考案された → 当時は総称して軽量ソフトウェア開発と呼ばれていた

Slide 14

Slide 14 text

そして2001年のある日 その界隈の17人が集まってユタ州スノーバードで合宿した そしてお互いのやっていることの共通点を整理して言語化した それが、、

Slide 15

Slide 15 text

アジャイルソフトウェア開発宣言

Slide 16

Slide 16 text

まとめると ● アジャイルとして整理されるよりも前にスクラムの原型は作 られていた ● アジャイル開発という広い概念の中にスクラムやXPが具体 的な手法として存在するが、それぞれの哲学はすこしずつ 異なる

Slide 17

Slide 17 text

アジャイルとスクラムの関係 ● スクラムができて、そのほかの似ている手法も合わせて共 通概念を言語化したのがアジャイル ● アジャイル開発のうちのひとつがスクラムと言われるが、ア ジャイルが言っていることはスクラムの一部でしかない

Slide 18

Slide 18 text

[余談]The New New Product Development Gameの解説 スクラムチームの特徴 ● 不安定な状態を保つ ● プロジェクトチームは自ら組織化する ● 開発フェーズを重複させる ● マルチ学習 ● 柔らかなマネジメント ● 学びを組織で共有する

Slide 19

Slide 19 text

[参考文献]アジャイル開発とスクラム https://www.amazon.co.jp/dp/B00DIM66P0

Slide 20

Slide 20 text

アジャイルに影響を与えている もの

Slide 21

Slide 21 text

さらに過去に遡る ● トヨタ生産方式 ● → リーン生産方式 ● → リーンソフトウェア開発 無駄を徹底的になくす アジャイル手法の開発者はリーンソフトウェア開発から少なから ず影響を受けている ※リーンスタートアップとは別

Slide 22

Slide 22 text

スクラムとは?

Slide 23

Slide 23 text

スクラムとは何か? ● プロダクトマネジメントのフレームワーク ● 自己組織化 ● 経験主義 ● 理解するのは容易だが実践するのは難しい

Slide 24

Slide 24 text

なぜスクラムをやるのか 早期に不確実性へ対応するため 経験から学び確実性の高い動くソフトウェアを少しずつリリースし ていくため

Slide 25

Slide 25 text

スクラムの基本コンセプト ● 透明性 ● 検査 ● 適応 課題を見える化し、検査と適応を短いサイクルで繰り返していくこ とで不確実性を減らしていく

Slide 26

Slide 26 text

スクラムの構成要素 ● 3つのロール ● 4つのイベント ● 4つの生成物

Slide 27

Slide 27 text

3つのロールの責務 ● プロダクトオーナー ○ プロダクトのROIに責任を持つ ● スクラムマスター ○ プロセスに責任を持つ ● 開発チーム ○ 動くソフトウェアに責任を持つ プロダクトはこれだけで開発できる マネージャーはいらない

Slide 28

Slide 28 text

イベントと生成物 ● 4つだったり5つだったり ● 細かいことはプラクティスの本を読んでください

Slide 29

Slide 29 text

スクラムマスター

Slide 30

Slide 30 text

要素 ● サーバントリーダー ● ファシリテーター ● マネージャー ● コーチ ● メンター ● ティーチャー ● 妨害を取り除く人 ● チェンジエージェント https://www.scrum.org/resources/8-stances-scrum-master

Slide 31

Slide 31 text

やること ● プロダクトオーナーと開発チームの関係を円滑にする ○ 相互のリスペクトを生む ● 完了の定義を管理する ● チームの集中を保つ ● チームに挑戦する ○ 挑戦を促す、高い目標を目指す方向に意識を向ける ○ 失敗させる、失敗から学ばせる ※CSM研修の資料から

Slide 32

Slide 32 text

やってはいけないこと ● 指示や命令 ● 具体的な解決

Slide 33

Slide 33 text

靴紐の例 子供「お父さん靴紐結んで!」 → A: 結んであげる → B: 結び方を教えてあげる

Slide 34

Slide 34 text

Controlledな失敗 たとえば、 「スプリント内にバーンダウンできそうにない」 → スプリントの途中で介入はしない → 失敗させたあとふりかえりを促す ・ストーリーの精度が悪かった? ・割り込みがあった? ・見積もりが甘かった?

Slide 35

Slide 35 text

プロセス改善のサマリ ● 検査と適応 ● 自己組織化を活用 ● 宗教にならない: 信頼し、信頼される ● なんでもやる ● 真剣に取り組むが、深刻にならない ※CSM研修の資料から

Slide 36

Slide 36 text

パフォーマンス向上のために意 識したいこと

Slide 37

Slide 37 text

MTGの質を気にする ● 全員参加しているか? ○ participateしてるか?いるだけは participateではない ● 透明化されているか ○ 議論の前提で情報格差がないか ○ 自分しか知らないことがないか ● 言える化 ○ 「言ったら面倒なことになりそうだから言わないでおくか・・」 とならないような場作り ● 改善のアクションに繋がっているか ○ SMART Goalsの意識

Slide 38

Slide 38 text

自己組織化できているか ● 不確実性を減らすための行動をチームができているか ○ 「ストーリーの受け入れ条件が決まってないから来週ですね〜」 だと進まない ○ 優先順位などの意思決定は POだが、何をどう作るかは開発チームが 決める ● それぞれがオーナーシップを発揮しつつ機能横断的に動け ているか ○ 得意な分野がうまく重なってチームのパフォーマンスが最大化するよ うに動く ● 群がって仕事をする ○ ひとつの場所に集まって仕事を進める (swarming)ことで自己組織化 を推進できる

Slide 39

Slide 39 text

機能横断的なチームとは Aさん Bさん Cさん Dさん Eさん チームで達成 したいこと それぞれの領域がチームで達成したいことをカバーできていない

Slide 40

Slide 40 text

機能横断的なチームとは Aさん Bさん Cさん Dさん Eさん チームで達成 したいこと それぞれの領域がチームで達成したいことをカバーできているが、 接続にコミュニケーションが必要

Slide 41

Slide 41 text

機能横断的なチームとは Aさん Bさん Cさん Dさん Eさん チームで達成 したいこと それぞれの領域がチームで達成したいことをカバーできており、 お互いがお互いのやっていることを把握している

Slide 42

Slide 42 text

サーバントリーダーシップ ● 自己組織化の文脈でそれぞれがオーナーシップを持つこと と同時にサーバントリーダーであるか ○ チームに考えてもらう ○ チームからバランスよく意見を集める ○ チームに対してもフィードバックし、自分へのフィードバックもチームに 求める

Slide 43

Slide 43 text

まとめ

Slide 44

Slide 44 text

まとめ ● アジャイル、スクラムの成り立ち、誰がどういう考えで作り上 げたのかを知るとプラクティスの理解が深まる ● 基本を理解して実践すると、守破離の破と離も実行できるよ うになる ● アジャイルとかスクラムとか意識しなくても自然に改善し続 ける状態がベスト。 目的でも手段でもなく、結果的にそうなることを目指したい。

Slide 45

Slide 45 text

参考になりそうなもの

Slide 46

Slide 46 text

● 「アジャイルは死んだ」以降に残るものは何か -リーンソフトウェア開発を再評価し、自工程 完結で全体観点で改善する - https://qiita.com/kitfactory/items/37b42c0716e1ff1efb28 ● 文献紹介: The New New Product Development Game https://www.slideshare.net/tnoda/the-new-new-product-development-game ● がんばれスクラムマスター https://speakerdeck.com/kazuhideinano/ganbaresukuramumasuta 参考になりそうなもの

Slide 47

Slide 47 text

質疑・議論