この記事について

この記事は、aslead Agileの開発チーム「オキザリス」にて行っているアウトプット企画である「チーム「オキザリス」Advent Calendar」の5日目の記事です。

筆者の属性

2017年入社の社会人歴４年目の人間です。
2020年6月より業務にスクラムを取り込んで活動しています。
この記事の執筆時点でスクラム経験はちょうど６ヶ月です。
私のチームには１名アジャイルコーチがおり、週２日ほどの活動日にはいろいろとティーチング・コーチングいただきながら活動しています。

そのほか私が所属しているチームの詳細はオキザリスをご覧いただければと思います。

スクラムマスターを雇う時に聞いてみるとよい38個の質問

こちらのブログに記載されている、
「スクラムマスターを雇う時に聞いてみるとよい38個の質問」について、半年ほどスクラムを実践してきた身として、現在の理解度や自分の考えを整理する意味でこのタイミングで質問の回答を考えてみようと思った次第です。

質問数が多いため、このAdvent Calendarで予定している４回の記事投稿に分けて公開していこうと思います。

実践している方、していない方、アジャイルコーチ・・・など読んでいただいている皆さんのバックグラウンドも多種多様かと思います。
いろいろ思うところはあるかと思いますがご覧いただけると幸いです。

なお、以下の質問をパッと聞かれた体で反射的に思ったことを書いていこうと思います。
熟考するのはまた今度の機会にします。

それではそれぞれ考えていきます

1: アジャイルマニフェストでは「プロセスやツールよりも個人と対話を」といっている。プロセスを守らせるスクラムマスターは、それとは反対のことをしているのではないか？
まず前提としてアジャイルマニフェストでは、プロセスやツールの重要性も認めつつ、相対的に「個人との対話」を重視するとしています。

その点で、「プロセスを守らせる」のは必ずしもアジャイルマニフェストに反しているわけではないと思います。
ただし、目的や意図を伝えようとせず、ただプロセスを押し付けているのであれば、それは問題だと思います。
仮にプロセスに不満や違和感のあるメンバーがいる場合は、しっかりとプロセスの目的を伝えるとともにメンバーが感じている不満や違和感にも耳を傾けて、チームごととして最適なチームのやり方を考えるのがよいと思います。

2: 自分の組織でアジャイルがうまくいっていることを示す兆候は何か？また自分の働きが成功している兆候は何か？
スプリントレビューにステークホルダーが十分に参加してもらえており、フィードバックも活発にもらえているようであれば、アジャイルがうまくいっている１つの兆候ではないでしょうか。
これは、ステークホルダーがスプリントレビューの目的や重要性を認識してくれていることの現れだと思うからです。

チームのベロシティが安定していることと、プランニングに対する達成度も良い兆候のように感じます。
チームのコミットメントや適切なバックログの分割ができていることの現れかと思います。

バックログの見積もりが一致するというのも１つの兆候かもしれません。
しっかりとバックログリファインメントができており、メンバー間での認識のズレが小さいように思います。

3: 追跡しないといけないメトリクスはあるか？もしそうだとしたら何の目的でどのメトリクスを追跡するか？
ベロシティはわかりやすいメトリクスだと思います。
ベロシティが数スプリントを通して安定しているようであれば、チームが安定してせいかを出せているはずだからです。
また、長い目で見た時に徐々にベロシティが上がっているのも、チームが成長している１つのポイントかも知れません。
逆に、変化が怒っていないとすれば、なにか１つカオスを放り込んでも面白いかもしれません。

また、得られたフィードバックの量もスクラムがうまくいっているかの１つの指標になると思います。
フィードバックの量があまりに少ないようであれば、「スプリントレビューでステークホルダーにうまく状況が伝わっていない。」「ステークホルダーがフィードバックすることの重要性を理解していない」「スクラムチームとステークホルダーの間に壁がある」といった状況に陥っているかもしれません。

4: あなたのチームのパフォーマンスは常にコミットメントを達成できておらずベロシティも安定していない。考えられる理由はなにか？そして問題をどのように指摘するか？
常にコミットメントを達成できずベロシティが安定しない理由として、いくつか頭に浮かんだものは以下のとおりです。

• オーバーコミット
  • POのプレッシャー
  • スクラムチームの現状認識が甘い
• 兼務などの理由により突発タスクが頻繁に入ることで予定の作業量がこなせない
• バックログリファインメントが十分になされていないことにより、着手後に見積もりからのズレが大きい

指摘の仕方としては
オーバーコミット → 今までのベロシティを示しつつ、「コミット多すぎるんじゃないの」と伝えてみる
兼務などの理由により突発タスクが頻繁に入ることで予定の作業量がこなせない　→　定常的に入るようであれば、定常的に削られる分を考慮したコミットをする
バックログリファインメントが十分になされていない　→　開発メンバーからバックログを説明してもらうことで理解度を測る

といったことが思い浮かびました。

5: 製品のディスカバリープロセスにスクラムチームは参加してよいか？その場合はどのようにするか？
スクラムチームもディスカバリープロセスに参加していいと思います。
製品にかけられている思いなどに触れることもスクラムチームのモチベーションに繋がると思うからです。
「こうするとより良くなるのではないだろうか。」という視点で意見を伝えるだけでいいと思います。
ただし、最終的にはあくまでプロダクトオーナーが決定権を持ちます。

6: 設計上プロダクトオーナーの役割はボトルネックになる。価値が最大になるよう、どのようにプロダクトオーナーをサポートするか？
悩ましいですね。。。
プロダクトバックログの管理方法や、プロダクトオーナーとスクラムチームのコミュニケーションの場の調整・ファシリテーションなどでしょうか。
よりバックログの中身やスクラムチームとのコミュニケーションに集中してもらい、スムーズな情報の管理・循環のサポートはできそうな気がします。

また、価値の最大化ということであれば、きちんとプロダクトオーナーが優先順位をつけられることが重要になってきます。
優先順位付けに必要な情報の収集なども助けになるかもしれません。

7: どのようにスクラムチームがしかるべきステークホルダーにアクセスできることを保証するか？
当該ステークホルダーにスクラムチームがアクセスしたい理由や、それがスクラムチームにとってどのような意味をもつのか伝えるといったところでしょうか。
その上でしっかり納得していただけるまで働きかける根気強さも時には必要になりそうです。

8: どのように複数の異なる部門にまたがってアジャイルのマインドセットを広げるか？ITじゃないステークホルダーをコーチするのにどんな戦略をとるか？
これまた悩ましい。。。
どのように複数の異なる部門にまたがってアジャイルのマインドセットを広げるかについてですが、以下のような進め方が頭に浮かびました。
１．推進役となってもらえる熱意のある人を見つける（ここが見つからなかったらどうしようか。そのときはまた考えよう）
２．推進役に相談しつつ、その組織で効果がありそうな進め方を検討する
３．それぞれの部門について、導入の施策を実施する

ITじゃないステークホルダーをコーチする戦略については、

• ITじゃないステークホルダーの業務における、開発チームがアジャイルな開発をすることによるメリットを伝える。
• 当該ステークホルダーのサンプル業務を例にスクラムの考えに沿った業務の進め方だとどのように変化し、どのような嬉しさがあるかを説明する

といったことが思い浮かびました。

9: 上級管理職にどのようにスクラムを紹介するか
以下の点を紹介するのが良さそうだと思いました。

• スクラムに出てくるロールやイベントと、それがどのようなものでどういった価値基準に基づいてそのような作りとなっているかを伝える
• 管理職の人に対してどのようにチームがコミットして、透明性を担保するかを説明する（どこを見ればチームの状況がわかるか、そして理解できるようにサポートする）
• 管理職の人に期待することを伝える（スプリントレビューでFBがほしい、チームにある程度の権限をほしい）

10: あなたはすでにステークホルダーにスクラムのトレーニングをしたとする。この考え方を適用しようとする初期フェーズのあと、スクラムの適用を続けることに同僚が激しく抵抗するような障害やハードルにぶつかったとする。このような状況においてどんな戦略を取るか？またどんな経験があるか？
同僚が抵抗をしている理由をまずはフラットに聞いてみるかなと思いました。
また、このときには「スクラムに引き戻そう」という考えではなく「今までのやり方で良くなかったところを改善しよう」という、活動をより良くするための１つのフィードバックをもらう機会だという姿勢で聞くのが大切かと思いました。

まとめ

パッと答えるつもりが、読んでいるうちにいろいろと思いを巡らせてしまいました。
このあたり、反射的にも自分の考えが出るようになるといいなと思いました。
また、現時点の自分の視点での回答のため、今後経験を積んでいくとまた違う回答になるのかと思います。

回答をしながら、スクラムが適している案件なのかどうか、ということをまず先に考えるべきなんだろうなと思いました。
これらの質問は当然スクラムな開発をすることを前提にした質問ではありますが、そもそもアジャイルな開発が適しているかどうかを前段階で考えて置かないと、結果的に「なんちゃってアジャイル」なことになるリスクがあるかなと思いました。

回答については是非もあるかと思います。
ご意見いただけると嬉しいです。