チームで向き合いゴールを目指す─”とはいえ”シリーズ #13「スクラムの理論　透明性・検査・適応 編」(後編)

“とはいえ”シリーズは、スクラムに取り組む現場で起こる様々な「とはいえ」をピックアップし、それぞれどのようにアプローチしていけばいいのか、レッドジャーニーの経験豊富なアジャイルコーチがざっくばらんに語るシリーズです。

「スクラムガイドにはこう書いてあるし、ブログではこういう事例を見かけるんだけど、とはいえ…」と困ってしまったり、チームで対話しても道筋が見えてこない時、ここでのお話が何か一つでもヒントになれば幸いです。

第13回のテーマは「スクラムの理論　透明性・検査・適応 編」です。後編では、「検査」と「適応」について深掘りしてお話します。

前編はこちら

みんなで探す”ちょうどいい透明性”─”とはいえ”シリーズ #13「スクラムの理論　透明性・検査・適応 編」(前編)

“とはいえ”シリーズは、スクラムに取り組む現場で起こる様々な「とはいえ」をピックアップし、それぞれどのようにア…

redjourney.jp

…とはいえ、実際の現場ではガイド通りには進みませんし、そもそも書かれていないような事態も多々起こります。そうした「とはいえ」に、どのようにアプローチしていけば良いでしょうか。

検査について考える

「検査」の時間はつらい？

中村：
次に「検査」にまつわる”とはいえ”について考えてみたいと思います。

まず、検査というよりも責められている気がしてしまうとか、レトロスペクティブでの発言がしにくいなど、レビューの時間がつらいというお悩みがあるようです。
どうしてこうなっているのかが気になりますね。文化的にこうなのかもしれないし、以前のスクラムでのつらい過去があるかもしれないし。

新井：
この事象を対処するだけでは上手くいかないと思うし、短期的に一気に解消できることではなさそうですね。根本的な原因を探って、そして少しづつ文化を変える、状況を変える手を打っていかないといけないかな。

こうなってしまっている状況がそもそも問題かなと思うので、チームビルディングをするだとか、インセプションデッキを使ってチームの狙いがどこなのか探したり、ご近所さんを探せ※や、俺たちの”Aチーム”※などのワークに取り組んで、立ち返ってみるのもいいかもしれませんね。

　※ご近所さんを探せ：インセプションデッキのワークの1つ。
　チームの周辺にいるプロダクトづくりの関係者や顧客と、彼らの関心ごとを明らかにするプラクティス。

　※俺たちの”Aチーム”：インセプションデッキのワークの1つ。
　チームに必要なスキルやお金、時間について考えるプラクティス。

参加者のコメント：
誰かが状況を攻めるような発言をしてしまっているのでは？

新井：
そうかもしれません。詰問されているように感じているのかもしれませんよね。

中村：
言ってる人は「今週終わるはずだったのにどうしたのかな？」と思っているだけで、そこに誰かを意図的に攻める意味はないかもしれないけれど、聞き手によっては”終わるはずのものが終わらなかった”ということを責められているように感じるかもしれない。言葉遣いがとても難しいですね。

新井：
そうなんですよね。自分に「失敗したな。できなかった。」という後ろめたさが存在するときに今のような発言が出ると、責められているように感じることってありますよね。

中村：
だから、防衛反応として言い訳などが出ることも人間ですから仕方がないと思いますし、かといってそこで「終わってませんけど、なにか？」と開き直るのも違いますよね。チームとして終わらなかったことは事実として、次どうしていくかを考えたいですよね。

新井：
できなかったことは嬉しいことではないけれど、そんなに悪いことではなくて、それをそのまま放置して見なかったことにする方が問題です。そしてこれが発生しているのは、個人ではなくチームや仕組みの問題だと思います。そっと触れないでおこうという空気が流れがちですが、チームとしてきちんと向き合っていきましょうということなんですよね。

中村：
最近私が読んだ本に、こうなったことを責めるのではなく、みんながこの状況になることに加担したと考えてみようと書いてありました。

例えば「1週間前に終わるはずだったのに、終わらなかったのはなぜ？」と聞いている人も、「事前に大丈夫？」と聞くことをしなかった結果こうなることに加担したという考え方なんです。
つまり、”何かをした”もしくは”しなかった”、ゆえに、この状況になることに少しづつ加担したのだから、チームでこの状況に向き合いましょうということです。

新井：
なるほど。加担。いい言葉ですね。プラスの加担もあれば、気が付かなかった加担も、やらなかった加担もありますもんね。

参加者のコメント：
レビュー対象も「〇〇さんがつくったもの」じゃなくて「チームが作ったもの」という見方になれるといいですよね。

中村：
おっしゃる通りです。スプリントレビューでステークホルダーにデモを触ってもらうときにも、作った人以外の人が操作したり、説明したりできるようになっているといいなと思います。
例えば新井さんがつくったものでも、ステークホルダーからの質問には私もお応えすることができる、といったようにね。

新井：
個人という点ではなく、チームという面で向き合っている感じがいいですよね。

”頻繁かつ熱心に検査する”ためのポイントとは？

新井：
では、”頻繁かつ熱心に検査する”ためのポイントは、どんなことだと思いますか？

中村：
テクノロジー面でいうと、やはり自動化とか、エンジニアリングを上手に使うことだと思います。毎回ログを開かなくても、ある程度インテグレーションするとデータが溜まっているといった仕組みを作ったり。あとは、検査する範囲を絞るとか、頻度を見直すといったこともポイントだと思います。

新井：
そうですね。エンジニアリング要素の部分でも人間的な側面でも、関心ごとの濃淡はあると思うので、それに合わせて検査・適応していくということができるといいですね。

中村：
私も昔は、取れるものは全部取ってみることで、自分たちが気づいていない変化や傾向について見えてくると話していました。今でもそれは一つのアプローチなのですが、やりすぎてしまうと検査疲れが起きてしまうこともあります。

ですから自分たちが関心があるもの、大事なもの、または自分が見逃しやすいと分かっているもの、ついつい忘れてしまうものに絞って検査していくのはどうかな？

参加者のコメント：
確かひとつ前の版のスクラムガイドには「検査しすぎて邪魔になったらダメよ」的なことが書いていたと思いますが、自動化の技術が発展したからその注意文言が外されたのかなーと思ってます。

中村：
最近ではいろいろなサービスで自分たちのメトリクス(様々な活動のデータを収集し、計算や分析を加えて、分かりやすくデータ化したもの）を取れるようになっているので、コスト自体は低くなっていると思います。

ただ人間の認知力が追いつかないといったこともあるので、一定以上になると、よく分からないということになることもあるかなと思います。