スクラム 仕事が4倍速くなる”世界標準”のチーム戦術
アジャイル開発において切っては切れないような「スクラム」について書かれた本書を読了しました。
今回はそこからの学びや気づきをまとめたいと思います。
もはやICT業界にいてアジャイルという言葉を知らない人はいないのではないでしょうか。
そのくらいアジャイル開発を取り入れたいとしている企業やチームはたくさん存在していると思います。当然私もそのうちの一人で、私の担当システムの開発手法もウォータフォールモデルでの開発を未だに引きずっています。
私個人としてはウォータフォールモデルの開発手法が良くないとは思いません。ですが、現代社会の変化の速さについていくためにはどうしてもウォータフォールでの開発スピードでは追いつけません。ですが、現状が上手くいってることもあり、上司や周囲の関係者もウォータフォールでいいじゃないという感覚です。
課題はわかっているけど、解決策が見つからない。
そんな時に思ったのが「教科書にに帰る」という事でした。
本書はまさにアジャイル開発手法の一つである「スクラム」について書かれた書籍で、アジャイルの生みの親とも言われる方が書いた本です。
ですので、本書を読めばHow(どうやってスクラムを取り入れるか)より、Why(何故スクラムを取り入れる必要があるのか)を教えてくれるのではないかと思い手に取りました。
著者の方が何故スクラムを導入することにしたのか。それをつかめば今の業務にも活かせるかもしれない。そう信じて本書を読みすすめることにしました。
著者について
本書は、ジェフ・サザーランドという方が執筆されています。
元々は米空軍の戦闘機パイロットでした。その後、コロラド大で博士号を取り助教を努めた後に銀行に入行しATMのシステム構築に貢献。
以降、数々のソフトウェア会社でCTOやCEOを務められた中で、プロジェクト管理法の「スクラム」を確立させました。
ICT業界では有名なアジャイル・ソフトウェア開発宣言の執筆者のうちの一人でもあります。
読書からの学びや気づき
ここからは本書から私が学んだこと、気づきを得たことについてまとめていきます。学びベースで執筆をしていますので、必ずしも本書そのままの構成での記載になっていませんのでご了承ください。
ウォータフォールモデルとスクラム
- ウォーターフォールモデルでの進め方の問題点
- ガントチャートを美しく表現することに注力を置きすぎて、プロジェクト(PJ)の問題点に目を向けず、PJが表面上計画通りに進んでいるように見せようとしてしまう
- 経営者が「管理と予測可能性」を求めるためにこのようなことが起きてしまう
- こうした背景から、スクラムは創造性と不確実性を前提にする
- 経営者が「管理と予測可能性」を求めるためにこのようなことが起きてしまう
- ガントチャートを美しく表現することに注力を置きすぎて、プロジェクト(PJ)の問題点に目を向けず、PJが表面上計画通りに進んでいるように見せようとしてしまう
- スクラムでは「決められた期間の中で達成すべき目標を期間ごとに立てる」
- 続けていくことで自分たちのベロシティ(どのくらいスピードでこなせるか)がわかる
- ベロシティを下げる障害物を取り除くことに注力をする必要がある
- 続けていくことで自分たちのベロシティ(どのくらいスピードでこなせるか)がわかる
- Show & Tell「見せて説明する」
- 実際にシステムを使う人達に動かしてもらう
- 社会は待ってくれない
- 顧客の欲しい物がウォーターフォールで作り上げる間に変わってしまう(状況が変化してしまう)
- 「要求に素早く反応できるやり方に転換しなければ、このまま順調に成功し続けることは不可能」
- まずはスクラムを試せ。そこから工夫を加えていく。
- 「要求に素早く反応できるやり方に転換しなければ、このまま順調に成功し続けることは不可能」
- 顧客の欲しい物がウォーターフォールで作り上げる間に変わってしまう(状況が変化してしまう)
- 優れたチームの特徴とは
- 通常と異なる高い目的意識がある(協会や限界を超える)
- 自己組織的かつ自己管理的(主体性がある)
- PJの完成に必要なスキルをすべて備えている(機能横断的)
- 「あなたはどこのチームなの？」と聞いて、今取り組んでいるプロダクトを答えるのであれば良い傾向。その人の専門分野を答える場合には要注意
- プロダクトより専門をアイデンティティとしているのであれば、まだスクラム不足
- 「あなたはどこのチームなの？」と聞いて、今取り組んでいるプロダクトを答えるのであれば良い傾向。その人の専門分野を答える場合には要注意
- ブルックスの法則
- 遅れているPJへの要因追加はPJをさらに遅らせる
- チームは小さくすべきであり、それ以上は脳がさばききれない。最大で9人程度が良い
- 遅れているPJへの要因追加はPJをさらに遅らせる
- 服従の危険
- 業務中に倫理違反を命じられても権威に異を唱える人は少ない
スプリントとストーリー
- スプリント
- スプリントとは「決められた時間の枠」
- 長さを一定にしてどれだけのタスクがこなせるかを把握する
- デイリースタンドアップは15分
- 話すべきことは以下の３つだけ話せば十分
- 昨日何をしたか
- 今日何をするか
- チームの妨げになっていることは何か
- 全員が集まって直接話し、毎回同じ時間に行うことでリズムをもたせる
- 話すべきことは以下の３つだけ話せば十分
- 過大評価されているマルチタスク
- マルチタスクがかっこいい・得意というのは間違い。他の事に手を付けようとする衝動を制御できない
- 半分できたはできていない
- １件に集中し、終わってから次のPJに映るほうが時間は短縮される
- タスクは把握できるサイズに
- 作業の洗出 → 取り組めるレベルに分ける → 仕事量の見積もり を行い把握できるサイズへ
- 優先順位をつけるときには「これから取り組むプロダクトに最も付加価値を与える要素は何か？」を考える
- 実際に作業する人でないと仕事にかかる労力や時間を把握できない
- タスクではなくストーリーを
- 人間は背景があってこそ理解できる
- 「このタスクは誰のための仕事なのか」、「このタスクで何を達成したいのか」、「何故これを必要としているのか」がしっかり伝えられるようにする
- ストーリーは端的に ⇒ 見積もりができるように小さく
- エピック
- コンセプトを包括的にまとめた最初のストーリーのようなもの
- エピックをくだいたそれぞれのストーリーが存在する
- ストーリーが準備できている状態とは
- 「準備完了の定義(INVESTの原則を満たしているか)」と「完了の定義」の両方がなければならない
- INVEST
- Independent ：ストーリーが独立している
- Negotiable ：完全に完了するまでは書き換え可能(交渉可能)である
- Valuable ：顧客やユーザに価値を提供できる
- Estimatable ：規模を見積もりできる
- Small ：見積もりや計画が容易にできる程度に小さい
- Testable ：完了するために合格すべきテストが用意してあること
- 完了の定義
- 何の条件を満たし、どのテストをクリアすれば完了とみなすか
- 人間は背景があってこそ理解できる
幸福と仕事の関わり
- 優れた仕事は喜びに根ざしている
- 喜びに満ちていることが成功の第一歩
- 幸福であることは私達の人生のほぼ全領域において成功につながっている
- 幸福な人は家でも職場でも、人生全般において、そうでない人よりうまくいっている
- 幸福度を測る
- スプリントレトロスペクティブ
- 「完了」できていて顧客からのフィードバックできるものを発表した後に行われる
- レトロスペクティブミーティングで話される議題
- うまくできた点はなにか？
- もっとうまくできたはずの点はなにか？
- 次のスプリントではどこを改善できるか
- 大事なのは犯人探しをするのではなく、プロセスに焦点を当てて見直す
- レトロスペクティブミーティングの鍵は「改善」まで実行することにある
- 改善してこそプロセスに実際の変化が生まれ、次にやるときに前進する
- チームのメンバーを幸せにする要素
- 自分の運命を自分でコントロールできること(主体性)
- 自分が上達しているという実感(スキルアップ)
- 大きななにかに力を尽くしているという感覚(目的意識)
- コネクション(つながり)の重要性
- 職場で他の人とのつながりが充実している人ほど幸福度が高い
- 個人のだめな点を責めるのではなく、その人がそうした行動をとる原因になるシステムの欠点に目を向ける
- スプリントレトロスペクティブ
優先順位
- 優先順位
- リリースは価値のあるものから先に。検討するのは以下の点
- ビジネス上の効果が大きい項目
- 顧客にとっての最重要項目
- もっとも利益につながる項目
- 一番簡単にできる項目
- 最小の労力で最大の価値を生み出す部分は何かを考え、すばやく形にする
- リリースは価値のあるものから先に。検討するのは以下の点
- プロダクトオーナ(PO)とスクラムマスタ(SM)
- PO：チームの生産性を価値としてアウトプットさせる責任を持つ
- POに必要な４要素
- 仕事の領域に精通していること(以下の２つの意味を含む)
- 仕事のプロセスを十分に理解して、何ができるのか、そしてどこからは無理なのかを把握すること
- 仕事の内容を理解して、チームにデキる仕事をどう真の意味での価値に変えられるかをつかむこと
- 決定権を行使できること
- 製品のビジョンはどうするのか、どうそれを達成するのかを決める裁量がなくてはならない
- すべきことは何か、またなぜそれが必要なのかをいつでもチームに説明できること
- 価値を説明できること
- 価値の評価基準を決めることと、生み出す価値を増やしていく責任をプロダクトオーナが持つ
- 仕事の領域に精通していること(以下の２つの意味を含む)
- POに必要な４要素
- SM：仕事をすすめるスピードと、どれだけスピードをあげられるかを担当する
- PO：チームの生産性を価値としてアウトプットさせる責任を持つ
本書を読み終えて
本書を読み終えて感じたのは、アジャイルを学ぶのであればまずこの本を読むべきと思わせるくらい勉強になる本だったということです。
実は私はアジャイル開発を学ぶ研修には何回か参加した事があるのですが、そのような研修では正直に言って内容がHowに徹していて、Whyがわからないことが多かった印象があります。
何故スプリントとして一定の時間を設定しないといけないんだろう、
デイリースタンドアップって何故毎日やらないといけないのだろう、
など、やり方を教わるだけで、根底にある背景がわからなかいためにいまいち身体に入ってきませんでした。
(本書の中でも「タスクではなくストーリーを」と言っていますが、それを身をもって学んだという感じです。)
本書を読むことでスクラムの良さだけでなく、スクラムの個々の手法が生み出された背景や考え方を学ぶことができます。本書を読んだことでアジャイル開発を導入できるのではないかという自身さえ湧き出してきています。
ICT業界に身をおかれる皆様にとっては、読まないほうが損になるというくらいの良書です。他の業界や学生の方にとってもこういったチーム戦術があるんだということを学べます。
事実、本書の最後の方では、異なる業界、しいては学校教育における適用例なども書かれていますので、システム開発にだけ適用できると言う訳ではないことがわかるかと思います。
私もせっかく本書読んだからには、担当チーム内にもスクラムを導入できるように普及活動を開始する予定です。
本当に読んで良かったと、心から思えた一冊です！