![見出し画像](https://assets.st-note.com/production/uploads/images/71712466/rectangle_large_type_2_bc529295157e42dc6568c17e1c89d60e.png?width=1200)
CSP-SM受けてみることにした そのxに向かって「新しいスクラムチームを始める時にすべき責任」
ここまでのあらすじはここから
3.4 新しいスクラムチームを始める時のチームやステークホルダーに対するスクラムマスターの責任を5つあげよ
チームとステークホルダーのコミュニケーションを確立する
ステークホルダーからのプレッシャーに対してチームを守る
アジャイルな価値観をステークホルダーに理解してもらう
働き方の共通認識を作るのをサポートする
意義・目的をすり合わせるサポートをする
コミュニケーションを確立する
●説明
新しいスクラムチームを立ち上げる時は、開発チームだけでなくPOやステークホルダーとのコミュニケーションも重要です。関係者が多ければ多いほど、
誰が
何を知っていて
何を決められるのか
を知ることは重要になります。
決められる人のいない会議や、知っている人のいない会議はフロー効率の観点でムダが多くなります。集まった全員で決まったように見えたそのアイディアも、決済者や有識者の一言により変更になることは多いと思います。
チーム内、チーム外、プロダクトチーム全体のコミュニケーションを円滑にしなければいけません。
それぞれのメンバーの意図を汲み取り、プロダクトに反映させる必要があります。
そうすることで、多様性がありフロー効率が高く価値を提供できます。
●具体例
あるプロダクトで、フェーズ割りや組織構造での分業を推進するメンバーがプロダクトをリードしていました。フェーズを分断するやり方と、チームを分業するやり方で進め、ステークホルダーの状況や状態をつかめていませんでした。
その結果3ヶ月のプロジェクトの1ヶ月が過ぎた時点で根幹となる仕様が変更になり、プロジェクトは振り出しに戻ることになりました。
その後は、スクラムチームが主導で部分最適にならないように細かなコミュニケーションを促進した。各部の期待値を揃えることや、どのタイミングでコミュニケーションを取るべきかを整えた。ただの情報交換ではなく、関係性にもフォーカスしてコミュニケーションをとっていきました。
スクラムマスターとしては、各チームのコミュニケーションの障壁を取り除くためにそれぞれのチームの稼働状況と優先度の把握をしました。さらには、プロジェクトや業務知識の濃度についても把握しました。
それぞれのチームでそれぞれの心地よいコミュニケーションを図るためです。
全体最適を目指し、より良いプロダクトづくりに集中しなくてはいけません。
プレッシャーからチームを守る
●説明
新しいスクラムチームは、それぞれに期待値が違います。
中には、入社して間もないメンバーがいるかもしれません。そのメンバーは、いち早く自分の存在価値を証明するために躍起になってしまうかもしれません。これは、自分の価値証明をしなければいけないというプレッシャーです。
他には、当たり前に存在するものですが、納期のプレッシャーがあります。ステークホルダーの要求事項を期間内に達成しなければいけません。これは、とても視野が狭くなる時限的なプレッシャーです。
どこかの誰かが決めた、理不尽な納期により、プレッシャーをかけられている可能性もあります。
「品質第一」という、わかるようでわからないミスが許されない完璧を求められるプレッシャーがあるかもしれません。
●具体例
プロダクト開発が始まった最初にしたことは以下です。
届けたい価値の確認
機能として外せないものの確認
リリース日の確認
リリースに対する必須度の確認
1と2を確認することで、プロダクト開発における優先順位が決まります。
この優先される機能のために開発しなければいけない付随機能も決まるはずです。
これがなければリリースが不可能だという何かの機能に対してボリュームが大きすぎれば、さらに優先度や機能に対する価値判断をする必要があります。
3と4に対しては、設定されている根拠がないことが多いです。
誰かが決めたルールであることもあります。もしくは、誰かの評価のための部分最適として強く推進されていることもあります。
この4つの項目を押さえることで、優先度と必達のプレッシャーから柔軟に回避する余白が生まれました。
もちろん、プロダクト開発としてこの後に拡張や修正ができることも各種ステークホルダーと理解と合意をしなければいけません。
この前提のすり合わせの成果により、何が必要でそれがどの段階までに必要なのかの認識の擦り合わせが出来ました。必要な段階で、必要なだけ開発を行う事ができました。
アジャイルな価値観の啓蒙
●説明
アジャイルの理解や認識もばらつきがあります。
「アジャイルをやればとにかく早く終わる」
「何度でも変更可能で好きな時に好きなことができる」
「スプリントを使っているからアジャイル」
など。
アジャイルのしたいことは、
「アジャイルな価値観を実践すること」
「プロダクト中心の顧客への価値提供にコミットする文化になること」
だと思っています。
そのために、できることを少しづつカイゼンできるプロセスや組織構造を作らなければいけません。
●具体例
「コップの注ぎ口を上に向ける」という表現があるように、必要性を感じるからこそ知識として取り込んでくれると日々のスクラムマスターの実践の中で感じます。
新しいスクラムチームが、スクラムをフレームワークとして使用することに心から理解があるかは分かりません。
ステークホルダーにしてみれば、スクラムやアジャイルという手法などは方法論にすぎません。その投資にリターンが望めてこそ採用するはずです。
啓蒙にあたってのすることは以下です。
今回のプロダクトの目的を確認:課題意識のすり合わせをします
アジャイルに進めることで得られる共通認識を得ます:なぜ有期的な進め方をしないのか
変更の容易性
優先度の高い価値を提供を行えること
プロジェクトではなくプロダクトベースのため、カイゼンを繰り返すこと
そのために協力をしてほしいこと:表面的なコミュニケーションではなく、チームとなる必要があること
これをすることで、手段としてのアジャイルではなく、価値提供のためのアジャイルの下地ができます。
働き方の共通認識を作る
●説明
プロダクトに対しての多様性を受け入れるための話は多く存在すると思います。しかし、それぞれのメンバーに対して働き方の多様性が存在すべきことは忘れられがちだと感じます。人生の段階において、今が働くことが最優先なメンバーがいます。逆に、今は落ち着いて仕事以外の事柄に時間を使いたいメンバーがいます。メンバー中心にできないようなプロダクトの事情もあるかもしれません。
そうした中で、最初の基準となる共通認識を作ることは重要です。
●具体例
具体的にはワーキングアグリーメントの作成です。
いわゆるインセプションデッキのようなものを大々的に作るのは私は好きなタイプではないです。
しかし、個々の働き方やキャリア像を知り、より有意義な開発環境を作っていくことはスクラムマスターの責任だと感じます。
言い出せない環境になる前に、それぞれのメンバーの意思を確認し、全体にとって受け入れることが可能な合意を形成する必要があります。
家庭の事情などを考慮し、私のチームでは
始業時間は特に決めない
デイリーは11:45-12:00
休みは積極的に取れる
というような合意を作りました。
プロダクトの状況により完全な自由は手に入らないかもしれません。
しかし、そこの調整をし、価値提供はしていくことがプロダクトチームそれぞれの責任です。
意義・目的をすり合わせる
●説明
新しいスクラムチームが発足された時、その人の強いプロダクトへの意志によりプロダクト開発に参加することは少ないように感じます。
開発行為自体へのモチベーションが高いことは容易に存在します。
スキルアップの場として、参画する際のモチベーションは高くなります。
最も多いパターンは、たまたまリソースとしてアサインされることでしょう。(体感)ただそれは、モチベーションが低いということと同義ではありません。
プロダクトの意義・目的のすり合わせが行われることで、下記のような効果が見込まれます
意義・意図を感じてプロダクト開発に取り組める。単純なモチベーションアップ
プロダクトの意義・目的を把握することで、そのゴールに向かった発言や行動につながる
●具体例
意義・目的が共有されず、単純にプロダクト開発に参画した場合にありがちなのは部分最適です。セクションや工程での個人の成功にだけ集中してしまいます。例えば、自分の作業を終わらせるために優先度の高い他のチームの作業を後回しにしてしまう。工程や役割が違うからという理由で、自分の貴重な意見を出さずにいることなどです。
とにかく簡素で明解なUX求めるターゲットに対して、自分の中のリッチな知識を導入して、自分の考える美しいプロダクトを作ろうとしているメンバーがいました。ターゲットも達成したい機能も、そのリッチさを求めてはいません。何よりも早く利用できる事が必要で、プロダクトとしての使い勝手の実証もされていない段階です。
さらにその理想のために多大な工数を使うことを主張していました。
プロダクトチームとステークホルダー全員を集め、このプロダクトに対する目的や意義を説明し、顧客に提供すべき価値について説明をしてもらいました。
そうすることで、プロダクトの向かう先とそれに向かったアクションが決まりました。一つ一つの作業や会議がより有意義に進められる結果となった事象です。
まとめ
どの事柄も、スクラムマスターだけが気づきうることではないと感じる。
しかし、人間関係やプロセスの部分でよりよくプロダクト開発を進める存在として、スクラムマスターがプロダクトチームに対して責任を持っていくべき内容だと思います。
この5つのみが責任の全てではないと思いますが、私の中で重きをおいている部分はこの5つが中心になっていそうです。