No Time To Sleep

ソフトウェアエンジニアがポエムを書いたり書評を書いたり試したことを書いたり。

『スクラム実践者が知るべき97のこと』を読んだ

f:id:yamat47-thirddown:20210627194407j:plain

今年のゴールデンウィークはコロナやら緊急事態宣言やらがあってじっくり本を読む時間を作れますね。 ということで『スクラム実践者が知るべき97のこと』を読みました。

www.oreilly.co.jp

実践者の皆さんの経験談や具体的なアドバイスが赤裸々に書かれていて、いい意味で教科書的ではない内容をたくさん学べる本でした。 ただし組織によってメンバー構成や組織体制など色々な前提が全く異なるので、大切なのはそれぞれの内容を自分を取り巻く環境に置き換えて考えてみることですね。

そんな感じで 97 + 10 で 107 個のエッセイそれぞれについて自分なりにメモをしながら読んでいたのですが、特に気になったものをいくつかまとめてみます。

No.05 Why からスクラムを始めよ

チームや組織は、スクラムの仕組みに気を取られ、本当の目的を忘れがちだ。顧客、ステークホルダー、自分自身への価値を生み出し、価値を改善すること。普通は、これが目的だ。

まず、自分たちの現在の対策があまりうまくいっていないことや、改善が必要な課題について組織で話してもらう。そして、その制約をどうやったら取り除けそうか、そこにスクラムがどう役に立つかを考える。スクラムが役に立ちそうと腹落ちしてから、スクラムの導入を始める。

この部分を読んで「なぜ自分たちは数ある開発手法からスクラムを選択しているのか」という問いに自分が答えられないことに気付かされました。

一年ほど前、私が今の会社にジョインした頃にはすでにスクラムによる開発が行われており、そこに私も入っていったのですが、これまでこの疑問を抱いたことはありませんでした。 それよりも「スプリントプランニングをよりよくしたい」「プロダクトバックログを整理したい」といった、プロセスを改善していくことにばかり気を取られていて...。

5つめというかなり序盤の段階でガツンと目を覚まさせられました。

No.24 そして奇跡が起こる

スクラム実践者にとって、私が個人的に知っているものの中で一番役立つヒントの1つは、時間やエネルギー、創造性、共感を惜しみなく投資して、チームを本当に良いチームにすることだ。そうすれば、スクラムにおいて良いことが、「ひとりで」に、ほとんど自動的に起こるようになる。...(中略).... すべてのスクラムマスターにとってお気に入りの「チームに任せる」というマントラが素晴らしく機能し始めるのだ。

プロフェッショナルスクラムへの道でも、同じように困難だが必要な一歩がある。チームを育てることだ。誰もどうやってこれが実現できるかを正確には知らない。

素晴らしい日々(本当に素晴らしいです!)のなかでコラボレーション、尊敬、助け合い、友情を育んでいると、予想もできなかった形で奇跡が起きます。

この書籍だったりスクラムガイドをみてみると、よい状態のチームはスクラムマスターの助けがなくとも大きな価値を提供し続けられるようになるようです。 ただそのためにはチームを育てることが必要、とのことでした。

何も確信はないですが、このチーム成長については『ビジョナリーカンパニー2』に出てくる「Good to Great」の考え方が大切な気がしました。

チームをそこそこいい状態ではなく突き抜けていい状態にする必要があり、そうすることで好循環が回るようになる、ということです。 プロセスの改善に目が行きがちですが、それを実行するチームの改善(検査と適応)こそ肝要なのかなと感じました。

No.57 サーバントリーダーシップはまず自分から

支援スクラムマスターの役割の基本部分であることは明確だ。ただし、支援にフォーカスして見ていると、重要な部分が抜け落ちる気がする。そして、私はそこが重要だと思うのだ。

スクラムマスターも同じだ。ほかの人たちを支援することに集中しすぎるあまり、自分自身を忘れてしまうのだ。

私が所属するチームでもこの気はあり、スクラムマスターをしてくださっている方は側から見ていてとても忙しそうです。 奉仕とか利他の心がとても強い方なので嫌な顔せず色々な仕事を引き取ってくださいますが... まさに上で引用したような状態になってしまっているように感じています。

私たちはまだまだ小さな組織なので、そんなスクラムマスターを支えることのできる人は多くありません。 しかし「属人性を下げてとっさのときは対応できるようにする」「たまにはスクラムマスターを代替する」といった自分にできる支援をする気概は忘れてはなりませんね。

スクラムのベストプラクティスから比べると歪な形かもしれませんが、再現性の高い日々を過ごすためにチームとして支援できることはより積極的にしていなかければなと感じました。

No.80 スクラムの6つめの価値基準

人はみな自分自身であることの専門家である。私は自分にそう言い聞かせている。彼らを支援するには、少なくとも彼らを一部でも理解しなければいけない。

私のモットーは、「まず理解に努める」だ。これが、良いスクラム実践者、スクラムマスター、スクラムトレーナー、アジャイルコーチ、そして根本的には良い人間であることに役立つと思っている。

「人はみな自分自身であることの専門家である」という表現はとてもいいなと思いました。 たとえアジャイルだったりスクラムだったりに自分が多少詳しかったとしても、改善しようと働きかけるチームについてはチームを構成するメンバーそれぞれが一番詳しいです。

引用した後半部分の通り、まず徹底的に理解に努めることをなくしてはいい関係を築くことは難しいですね。 これまでも意識していたことではありますが、大切さを再認識できました。

日本語版限定 No.01 まだ分担した方が効率がよいと思ってるの!?

また、「チームでモブプログラミングをやってもうまくいかない」という相談を受けることがある。そのときに決まって聞くことにしているのが、「そのチームは分担作業だとうまくいっているのか?」である。モブプログラミングによって一緒に過ごす時間が多くなることで、関係性やコミュニケーションの問題は特に顕在化しやすくなる。ところが、これらはモブプログラミングの問題ではなくチームの問題である。チームが解決すべき問題が見つかったことをむしろ喜んでほしい。問題が顕在化しにくい分、一緒に仕事をするよりも分担しうまく仕事をすることの方がよっぽど難しい。

この考え方はすっかり抜け落ちてしまっていました。 モブプロに限らずですが、何か新しい手法を試してうまくいかなかったとき、素朴に考えるとその手法に原因を求めてしまいそうになります。 ただ実際は手法ではなくもっと根本の部分にうまくいかなかった原因があった、ということはよくありそうですね...。

振り返りをする際の視点をまた一つ得ることができました。

おわりに

冒頭にも書きましたが、この書籍は自分を取り巻く環境に置き換えて考えてみないと意味がありませんね。 色々と改善に向けたヒントを得ることができたので、小さく試してみます。

上手くいってもいかなくても、会社の開発者ブログで何かしら話せるといいなと想像(妄想)しています。