はじめに
Scrum AllianceのScrumMaster研修を受けてきました。（資格試験も合格して、スクラムマスターになりました。）
参考：https://www.scrumalliance.org/get-certified/practitioners/csm-certification
トレーナーはMichael.Jamesさん、通訳はAgileコーチの榎本明仁さんでした。
３日間の研修、非常に刺激的で深く学ぶことができました。本当にありがとうございました。
本記事は、以下目的で作成しています。
- 自分自身のスクラムの理解を深める
- 社内メンバーに伝える際の資料
- スクラムマスター研修のダイレクトマーケティング
注意事項
- 語り尽くされている「スクラムプロセス」については触れていません（スプリントプランニングとは・・・とか説明しない）
- 少し踏み込んだ話を書いています。その結果、記事作成者の解釈を多分に含んでいます。
- 正直、体験しないと理解できないことが多いです。（だから、スクラムマスター研修に行こう！）
アジャイルとは何か？
プロセスではなく、「文化・考え方」に相当する。
- 「アジャイルマニフェスト」「アジャイルマニフェストの背後にある原則」で定義された「新しい考え方・文化」
- 「スクラム」以外にも実現方法がある（が、この記事では「スクラム」にフォーカスする）
スクラムとは何か？
ヒトによって定義は異なる。
- アジャイルを実現するためのフレームワーク
※詳細については「スクラムガイド」および「スクラムリファレンスカード」を参照するのが望ましい。
※用語は https://www.ryuzee.com/contents/blog/7137 が分かりやすい
スクラムはなぜ生まれたのか？
「ウォーターフォールが前提としていたものが間違っていた」という経験から発生した。
- 「正確な要求分析」「未来予知めいた計画」なんて誰もできない → 「経験を重視したプロセス」
- 「顧客が望む価値が事前に定義できない」
- エンドユーザーが本当に何を望んでいるのか、最初は誰も分からない（それはエンドユーザーですら）
- 何を望んでいるのかは「徐々に明らかになっていく」もの
- 「人間である以上、"確実な未来予知"ができない」という限界
- 「あなたのカバンは何kgなのか、正確に答えてください」と言われて、100%の精度で答えられる人は居ない。
- 「あなたのカバンと、そこの紙飛行機、どちらが重いか教えてください」と言われたら、基本的には100%の精度で答えられる
- 人間の脳は「そこまで正確には出来ていない」
- タスクバラシをすれば当たり前のようにタスクが漏れる
- 見積もりをすれば必ずブレる
- 顕在化するリスクはだいたい想定外のモノ
- 「顧客が望む価値が事前に定義できない」
- 「責任の明確化」が実はデメリットになる → 「クロスファンクショナルなチーム」
- 「全体のスループットのために、自分のスループットを下げる」ことが、個人にとってデメリットになる。
- 責任範囲を曖昧にすることで、「全体のスループット」にだけ集中する。
- 基本的には個人の責任範囲を定義しない
- 責任範囲を曖昧にすることで、「全体のスループット」にだけ集中する。
- 「誰も責任をとらない部分の発生」による、プロダクトにとってのデメリット
- MECEな責任定義は不可能
- できたとしても、またがった領域は誰が責任をとるのか？
- 「責任の明確化」によって生じる、いびつな組織体制
- 「全体のスループットのために、自分のスループットを下げる」ことが、個人にとってデメリットになる。
スクラムは何を実現するのか？
- アジャイルなシステム開発を実現するにあたっての組織課題の表出
- （表出した課題の解消は、「人」によって成される。「スクラム」が解消するわけではない。）
スクラムの実施において何を価値に置くべきか？
「アジャイルマニフェスト」の補足
- 「ベロシティの向上」よりも「チームの成長」
- 「ベロシティの向上」だけに価値を置くと「限界」が早期に訪れる
- 「チームの成長」の先に「ベロシティの向上」があり、その先に「プロダクトの成功」があるという考え方が望ましい
- 「プロダクトの成功」は当然目指すべきものである点は誤解してはいけない
- 「時間をかけた成功」よりも「スピーディーな失敗」
- 「情報収集」にはそれほど価値は無い
- 「今ある情報で、すぐ作れるプロダクト」から得られた「フィードバックを重ねる」ことが大事
※ここでの「失敗」は、あくまでビジネス観点での話。
スクラムの実践
基本的な説明は、以下に定義されているため、個人的に注意したい点をふれていく。
「ベロシティの向上」よりも「チームの成長」に価値を置く
正確に言えば「短期的なベロシティの向上」よりも「チームの成長」に価値を置き、「長期的なベロシティ向上」を目指すのが望ましい。
「チームの成長」を目指すことを、価値観として共有していないと、弊害が生まれる。それはスクラムが目指す姿ではない。
これによって得られる効果
- 『チーム内での極度の分業による「トラックナンバーの増加」』を防ぐ
- 常に体調不良などによる遅延リスクを抱えることになる
- メンバーが退職したらプロダクト開発が継続できなくなるかもしれない
- 「チームの心理的安全」に意識が向く
- 「ベロシティの向上」だけを意識した場合、責任を明確化させる方向に動きがち（今までそういう考え方が自然だったため）
- 本当のプロダクトの成功を目指すには「心理的安全性」が重要
実現のために注意スべきこと
- PO・SM・開発チームおよび周辺のステークホルダー含めて「価値の優先順位」について認識合わせをしておく
- これは決して簡単なことではない
- 「チーム成長」のためなら、スプリントプランニングで行ったPOとのコミットメントをないがしろにして良い、という訳ではない。
「時間をかけた成功」よりも「スピーディーな失敗」
つい計画をしたくなるが、「まずモノを作る」という「スピードの早さ」は馬鹿にできない。
これによって得られる効果
- あなたが想像するよりも「早く」「高価値な」モノを作ることができる
- これは実体験してもらわないと理解できない
実現のために注意スべきこと
- 「わからないけど、きっとこうだ」で良いのでモノを作る。
- すぐにリーチできる部分であれば確認するのであれば悪くないが、確認に手間取るのは悪手。
- なによりも「作ること」にフォーカスすること
- 「毎スプリント、出荷可能なモノを作る」
- 初回スプリントも例外ではない。
- そのためには、「PBIを薄い縦斬りにする」というPOのスキルも必要
- 「PBIを薄い縦斬りにする」
- ついコンポーネント単位や、工程単位でPBIを作りたくなるが、ぐっと堪える。
-
コンポーネント単位の例：「DBにテーブルを作成する」「Javaでビジネスロジックを作る」「html・cssでフロントデザインを作る」 -
工程単位の例：「設計する」「製造する」「テストする」
-
薄い縦斬りの例：「ログイン画面を表示できる」
-
- 縦斬りにしなければ「出荷可能なモノ」が作れない
- 薄くなければ、スプリントに収まらない
- ついコンポーネント単位や、工程単位でPBIを作りたくなるが、ぐっと堪える。
補足
「一般の人にスクラムを」というビジョンだけで誰も具体的なイメージが無かったのに、30分後には以下ボードゲームを作ることができた。（「30分後に出荷可能なものを作る必要がある」というゴールは共有していた。）
当然、30分クオリティなだけあって、ルールとしては穴だらけ、ゲームとして成立してない。ただ、30分ディスカッションだけしていたとしても、成果物を作る過程でブラッシュアップされたルールほどには至らなかっただろうし、何よりモノは確実に作られていなかった。
不完全ながらもモノがあることで、ユーザーからフィードバックを得られることができる。その「フィードバックを得られる状態」を作ることこそが、非常に大きな効能である。
「フィーチャーチーム」を組成する
コンポーネントチームだと「責任範囲が明確化」してしまい様々なデメリットが発生する。（冒頭に記載した通り）
- コンポーネントチームの例：インフラチーム/サーバサイドチーム/フロントエンドチーム
- フィーチャーチームの例：A/B/Cチーム（いずれもインフラ～アプリまで全部できる）
実現のために注意スべきこと
- 意識的なスキルトランスファーが必要
- 全てのタスクを全員ができる必要はないが、自分の専門に近しいコンポーネントについては積極的に理解する必要がある
プロダクトではなく「ビジョン」を共有する
多くの人は「iPhoneの機能」に惹かれるのではなく、「iPhoneを持った状態でのスマートな生活」に惹かれる。
- ビジョンの例：「月に10年以内に行く」など
これによって得られる効果
- 些末な機能の実装ではなく、本当に提供したいものに全員がフォーカスできる
実現のために注意スべきこと
- ビジョン自体が共感されるものかの確認もアジャイルに行なうこと（一人でキレイなものを作るのではなく、まずみんなと会話しながら作る）
「文化・考え方の変革」のために「組織構造の変革」を行なう
「文化・考え方」は「組織構造」によってもたらされる。
実現のために注意スべきこと
- 「文化・考え方」から変えようすると、だいたい失敗する。
- 「組織構造」から変えることが重要
- スクラム導入前にこの前提について組織マネージャーと合意して置くのが望ましい
- 簡単なことではない
開発チームは「自己組織化されたチーム」を目指す
そもそも「自己組織化された状態」というものがなんなのか、開発チームが深く理解する必要がある。
個人的な定義としては、「目標に対して自律的かつ意欲的に取り組む状態」。
これによって得られる効果
- プロダクトの成功
- チームの成長
実現のために注意スべきこと
- 「自己組織化された状態」を目指すモノだと開発チームが理解している必要がある。
- 自己組織化されていない状態では、「指示待ち」「責任分担」が多発し、アジャイルが生まれた前の状態に戻ってしまう。
- 「チームの責任範囲ではない」という表現が出てきたらおかしい。
- 「自己組織化されたチーム」なのであれば、自己が管轄する責任範囲すら定義し直せるはず。プロダクトの成功のために必要なことをなすべきである。
- そもそもスクラムは「責任範囲に閉じこもる」事による悪影響を避けるための仕組みのため、根本がずれてしまう。
- とは言え、「人事制度上の問題」など、「開発チーム」よりも「組織長」などが動いた方が課題解消に効率的な問題があるのは事実。
- 「自己組織化されたチーム」なのであれば、自己が管轄する責任範囲すら定義し直せるはず。プロダクトの成功のために必要なことをなすべきである。
「ツール」よりも「対面」
ツールがあると、ツール越しのコミュニケーションが増える。
可能な限り対面でのコミュニケーションを重視すべきである。
これによって得られる効果
- 不必要なコミュニケーションコストの低減
実現のために注意スべきこと
- ツールはあくまで補助的な存在であることを共有しておく
- ツールの導入によって「"チケットに書いておいてください"など、本質的には不必要な作業を、多くの人が発生させたがる」ことを理解しておくこと
それぞれの役割・権限
あるべき役割を意識すること
実現のために注意スべきこと
- 開発チーム：「プロダクト開発」に集中する。「エンドユーザーからのヒアリング」も、「チーム間の調整」も、全てが開発チームでできる状況が望ましい。
- プロダクトオーナー：「プロダクトに対するROIの最大化」が責任。基本的にはプロダクトに注力する。
- スクラムマスター：周辺の組織構造も含めて「ヒト」にフォーカスを置く。プロセスだけをフォーカスする役割ではない。
個人の専門性を高める工夫
プロダクトの開発において、コンポーネントでチームを作るのは悪。
ただし、専門性を高めるという点では、コンポーネントなコミュニティを作ることは有用。
これによって得られる効果
- メンバーの「専門性」が高まる
実現のために注意スべきこと
- 社内にこだわる必要はない
- なるべく広いコミュニティに関わる方が新しい知見を得られる
進捗の評価
WBSは作らない。あくまで「動くソフトウェア」だけが進捗足り得る。
これによって得られる効果
- 過度な未来予知作業を避けられる
実現のために注意スべきこと
- スプリントレビューの結果「Doneに辿り着けなかった」としても過度に悲しむ必要はない
- そこから得られた知見が重要なケースの方が多い（「ベロシティの向上」よりも「チームの成長」に価値を置くを忘れずに）
- 「進捗しない状態がずっと続いている」のなら「組織的な課題がある」ということを推測すべきである
- スクラムは何を実現するのか？に記載の通り
現実的な問題
「スクラムの完全適用にあたって未だ答えが出ていない問題」や「スクラム適用にあたって、よく直面する問題」
スクラムが適用できるとはとても思えない
そもそも、なぜ「適用できるとはとても思えない」のか？
その組織上の課題が見えること自体もスクラムの効能と言える。
既存のシステム評価手法とのコンフリクト
既存の評価手法として、「指標値を過剰に重視した評価」が上げられる。
品質・進捗の考え方がそもそも変わってくる。
- 品質
- 既存：ケース密度・不具合密度・収束曲線など
- スクラム：テストケースが十分に上がっているか？テストケースは消化されているか？
- そもそも「エンドユーザに届ける価値」自体が本来求めるべき「品質」である。「不具合が無いこと」だけにフォーカスしすぎるのは本質的ではない。
- 進捗
- 既存：WBSでの定量評価
- 「タスクが消化されているかどうか」であって、「システムがどれくらい作られているか」ではない。
- スクラム：システムがどれくらいインクリメントされているか？
- 実質「エンドユーザーにどれだけ価値を提供できているか？」が指標となり、より本質的である。
- 既存：WBSでの定量評価
上記の考え方はあくまでも一例なので、プロジェクト毎に「品質とは」「進捗とは」というのを定義し、認識共有することが大事。
個人の評価をどうすべきか
「責任を曖昧にする」という方針の結果、個人をどのように評価すべきかという悩みが発生する。
これに対する明確な解答はない。以下は回答例。
- チーム内で差を付けない
- スキルレベルと市場価値から給与を算出する（基本的には市場価値以上とする）
組織自体がコンポーネントになっている
それがために、「フィーチャーチーム」が組成できない。
「フィーチャーチームが組成できないこと」自体は課題ではなく、それによって「効率的な開発ができないこと」「既にコミュニケーションロスが発生していること」が課題。
組織構造自体の解決を本質的には目指すべきだが、難しい場合は、そういった個別課題にフォーカスするのも良いかもしれない。
専任にできない
解決策はない。専任できないことによる弊害を甘くみてはいけない。
スクラムマスターのポジションに限って言えば、複数プロダクトを兼任できるかもしれない。
ただ、開発チームに関しては、専任できるようにチームを組成すること。
学習が推進されない
チームの状況によるが、いくつかの具体案が存在する。
- 対象タスクに必要なスキルが、一番低い人が、そのタスクを行う
- チームメンバーはフォローを行う
- 必ず毎日1時間を学習に当てる
- ペアプロ・モブプロによるスキルトランスファーを促進する
- 必ずしも全てをペアプロ・モブプロでやる必要はない
上司が理解してくれない
「スクラムの適用」に関して、「得体の知れないもの」「宗教じみていて賛同できない」「現状で大きな問題がないのになぜ取り入れるのか？」などで却下される場合。
「なぜ導入してくれないのか」については議論した方が良いが、上長が権威主義的で、部下からの話を聞かないだけなのであれば、外部の研修を活用するのは良い手だと思われる。
- 外部のスクラム研修に行ってもらう。
- LeSS研修は、組織を意識した研修になっているため、組織長には適している。
※直近のLeSS研修：Certified Large-Scale Scrum:Practitioner 3/12-14・・・考案者のBas Voddeさんがトレーナーです。
懐古主義で、「昔からこのやり方で生きているんだ」と言うだけの人には、『「表出した課題」だけで会話する』と言うのも手かも知れない。
- 「スクラム」については触れない（現場では勝手に適用する）
- 「表出した課題」だけで会話する
適切な人数
6〜９人が推奨されているが、「コミュニケーションコストが高い」と感じられるなら、それが分割のタイミングかも知れない。
一般的には、無理に1チームにまとめるのは得策ではない。
ただ状況によっては、以下の「みてね」のように「1チームにまとめる」のが解決策になる場合があるかもしれない。
※参考：みてねのスクラム開発
POとの関係性
POの方が権力が強くなりがちのため、開発チームが適切なサジェストができなくなるケースがある。
- POに限らず、SM、開発チームの全てにおいて心理的安全性が担保されるようにする
- 心理的安全性が確保されていないことで弊害が生じている場合は、外部の力を借りてでもアクションをとった方が良い。
- なるべく深刻化する前に手を打つのが望ましい
※心理的安全性に関する記事
突発タスク
「スプリント中はスプリントバックログに集中する」のが基本原則だが、それが度々破られる場合の話。
- 「関連システムからの依頼が多い」とかなら、そもそもその関連システムも含めて1チームという組成ができないのかを考えてみる
- 実質「コンポーネントチーム」になっていることによる、突発の発生
- 「顧客問い合わせが多い」とかなら、なんとか次スプリントに回せないか？を意識する。
- 本当に急ぎのものは少ない。
- 「急ぎですか？」と聞くと、「急ぎです」と答えられるので、基本的に次スプリントに回すものであるという前提にしておくのが望ましい。
- それ以外の場合は、プロセスないしは組織構造に問題があると思われる。
- スプリントに集中できない時点で、原因を特定すべき。
契約問題
以下順で望ましい。
- 内製化・・・一番望ましい
- (大きな壁)
- 準委任契約・・・苦渋の決断
- (極端に大きな壁)
- 請負契約・・・スクラムが望ましい状況なら、そもそも請負範囲を定義できないはず。
現在の日本の多くの開発ベンダーでスクラムを行うなら、受託開発で準委任契約になるケースが多いはず。
そういった日本の状況の中で、育成コストの考え方や、開発チームの権限など、契約に起因して様々な課題が発生している。
現時点で、明快な解答はまだ無い。ただ、アジャイルマニフェストにある「顧客との協調」を実現するためにも、日頃からのパートナーシップ作りが少なくとも必要。
※一応、IPAが出している契約方針を載せておきます。（載せ忘れてた）
・IPA - 非ウォーターフォール型開発に適したモデル契約書の改訂版を公開
周辺知識
アジャイル
- 「リーンスタートアップ」
- 「アジャイル・レトロスペクティブ」
プログラミング
- 「レガシーコード改善ガイド」
- 「CleanCode」「リファクタリング」「リーダブルコード」
- 「テスト駆動開発」「実践テスト駆動開発」
ファシリテーション
研修の中で触れられたテクニック
- "集中と分散"というテクニック
- 具体例
- 「個人で意見を付箋に書く時間」と「チームでのディスカッション」
- 「スクラムチーム単独の振り返り」と「全てのステークホルダーを集めての振り返り」
- 「1つのプロダクト関係者での振り返り」と「複数のプロダクト関係者での振り返り」
- 集中は、意見を出しやすくするのに適している
- 分散は、話をまとめる・発散させるなどに適している
- 具体例
個人的に意識しているテクニック
- "バイスティックの7原則"：対人援助に関する基本原則
- 個別化の原則：同じ問題は存在しない
- 意図的な感情表現の原則：クライアントの感情表現が自然とできるように、ケースワーカーが意図的に感情表出を行う。
- 統制された情緒関与の原則：クライアントの感情と、ケースワーカーの感情は別の存在である。（心理的負荷にならないように、過度な共感を避ける）
- 受容の原則：クライアントが感じている課題そのものを否定しない
- 非審判的態度の原則：善悪の判断はクライアントが行う。
- SMとしては、スクラムプロセスから外れた場合に関しては「審判的態度」が必要な場面があると思っています。
- 自己決定の原則：クライアント自身が決定を行う。
- 秘密保持の原則：クライアントのプライバシーは保護されるべきである。
さいごに
「スクラムマスター研修はいいぞ」
「いいぞ」と安直な表現をしてますが、多数のグループワークがあり、スクラムを体験して学ぶ感じです。実際に受講してみた感想としては、「これは受講しないと伝わらない！」というモノでした。
記事中に表現しきれてない学びも多いので、ぜひ一度お試しください。
※主催する会社さんや、講師、集まったメンバーによって内容が大きく異なる可能性がありますので、その点はご注意ください。
以上