昨日に引き続き、修正作業。 ここまで書いたところを問題設定の修正に合わせて書き直した。 大変だった。。。
これでやっと2.4節を書ける。
土日はかなり頑張らないとだな・・・
ではまた明日。
スクラムガイドを読み解いてみよう #5
今日はこの勉強会に参加：
スクラムマスターについての部分を読み進めたのだけど、スクラムマスター大変だなw
少し議論になってたのが、スクラムマスターが組織に対してどのような支援を行うかという部分で、「組織へのスクラムの導入を指導・コーチする」「組織へのスクラムの導入方法を計画する」というのが挙げられてたけど、そういうことができないとスクラムマスターじゃないの？っていう話があった。
思ったのは、「役割」としてのスクラムマスターと、「職種」としてのスクラムマスターが混同されてるんじゃないかな、ということ。
本来はスクラムマスターってチーム内での「役割」だと思うんだけど、だとすると上記の仕事はそもそもおかしい。 チームがないところに役割もないわけだから。
ただ、それが「職種」になると話は別で、チームがなくても職種は存在するので、その場合は上記のような仕事も必要になってくるのかな、と。 （それはアジャイルコーチでは？という話もある）
まぁ、本来は「役割」であるのが理想だとは思うけど、スクラムマスターはスクラムに関する専門性が必要になってくるので、それを専門にやる「職種」に自然となってくるのかも。
ところで、これまでスクラムやってなかったところが「スクラムやるぞ」ってなると、部長や課長がプロダクトオーナー、リーダーがスクラムマスター、他メンバが開発チームってなることが多いと思っていて（他の現場のことは知らないけど、前職ではそうだった。もっとも、スクラムとは名ばかりのものだったけど）、パワーバランスがフラットじゃないことが多いと思う。 それをフラットにするためにも「役割」という言葉が使われてると思うんだけど、実際にはそれだけだとなかなかうまくいかないのかな。 外部からスクラムマスターを調達してくれば、そのあたりのパワーバランスが改善されるような気がするので（上の人って内部からの声は聞かないけど外部からの声は聞くと思ってる）、そういう意味でも「職種」であった方がいいのかもしれない。
ではまた明日。
新刊の2.2節を書き途中
新刊の2.2節について、問題設定を少し詰め、プログラムをちょこっと書いた。 これをベースにちょちょいと書けば2.2節が出来上がるはずだけど、おそらくそう簡単にはいかないんだろうな・・・
明日のスライドをまだ作れてないので、このあとちょこっと作りたい。
ではまた明日。
「ふりかえりのProblemが大きすぎる／小さすぎる！どうすればいい？」
今日はこの勉強会をYoutube Liveで視聴。
聞いてて思ったのは、「問いを考える」ってやっぱり重要だなってこと。 適切な問いは適切な解答を促しやすい。
ちょっと思い出したのが、XDDPという要求仕様の手法の話で、要求仕様を抜け漏れなく書き出すにはカテゴリを使うといいよってな話があった。
![[改訂第2版] [入門+実践]要求を仕様化する技術・表現する技術 -仕様が書けていますか?](https://m.media-amazon.com/images/I/51hV6os4M5L._SL160_.jpg "[改訂第2版] [入門+実践]要求を仕様化する技術・表現する技術 -仕様が書けていますか?")
[改訂第2版] [入門+実践]要求を仕様化する技術・表現する技術 -仕様が書けていますか?
- 作者:清水 吉男
- 発売日: 2010/05/01
- メディア: 単行本（ソフトカバー）
この本の是非はおいといて（すごく簡単にいうと「しっかりとウォーターフォールやろうぜ、そのためには要求仕様をしっかり管理するのが重要だよ」っていう本）、このカテゴリを用意するというのはいいアイディアだなと思った。
要求にカテゴリを用意しておくと、思考を誘発しやすい。（ただし、カテゴリに縛られる恐れもあるので、フィードバックをしてカテゴリ漏れがないようにする必要はあり）
— やまいも (@yappy0625) 2011年7月4日
本で書かれてるカテゴリ例だと「表示/UI処理」「入力処理」「変換/制御処理」「出力処理」「保守/診断処理」が挙げられてて、たしかにこのカテゴリそれぞれについて「このカテゴリで必要な仕様は何だろう？」という問いを立てると、漠然と仕様を考えるよりも抜け漏れが少なるなる。
それと同じ感じで、ふりかえりにおいても「いい感じの問い」を引き出しに用意しておくと、カイゼンが促されるのかなと思った。
ではまた明日。
