DevLOVE主催の「全員スクラムマスター。」に行ってきました。スライドはSlideshareで公開されており、つぶやきのまとめはこちらだそうです。
アジャイル事例発表2つにダイアログといった流れだったのですが、アジャイルやスクラム導入の苦労話が多かった気がします。今日は、そんな方に贈る言葉を発表のふりかえりとして共有させていただきます。
発表をふりかえる
僕は最近違うことをやっているので、「DevLOVEなら血と汗と涙を流している人が発表するほうがいい!」ということで、最近活動的な@TAKAKING22に発表をお願いしました。彼の発表では、アジャイル導入の苦労とそれに対するアイデアが描かれています。
- 全員がアジャイルやスクラムに協力的ではない。やりたい人だけを集めることのは難しい
- やる段階に入ったとしても、やってくれない人もいる
- スクラムチームを作りたくても、スクラムのロールを割り当てたくても、自分にはそんな権限がない
ボトムアップの苦悩ですね。がんばれ(なげやりに)。特に「やりたくない人をどう扱うか?」ではとても悩むところです。ダイアログでも気がついたのですが、
- やれない環境でやる場合
- やれる環境でやってくれない場合
と、逆の悩みを抱えているので、単純に考えれば1の人と2の人を交換すればいい気がしますね。会社が自分に合わないのと、自分が会社に合わない問題については、判断は難しいですがどっちもどっちでしょう。
話を戻すと、上のようなギャップがあって「ぴったり合わない」ということに気がついたみたいです。これまでのやりかたを分析すると、正攻法を突き進める「王道スクラム」と考えられ、トップダウンや推進チームでもないため「覇道スクラム」も難しい。ではどうするか?
銀の弾丸
僕も@TAKAKING22の発表資料をレビューした時に知ったのですが、有名な「銀の弾丸などない」という言葉の裏には多くのストーリーがあります。Wikipedia調べになり、解釈が間違っていたら申し訳ないですが、ちょっと続きを読んでみましょう。
フレデリック・ブルックス氏はこの言葉が登場する論文を1986年に発表しています。彼は「銀の弾丸」と評し
魔法のようにすぐに役に立ちプログラマの生産性を倍増させるような技術や実践 (特効薬) は、今後10年間 (論文が著された1986年の時点から10年の間) は現れないだろう
と主張しています。そして、銀の弾丸の対処方法を挙げています。
- 購入できるものをあえて構築しないようにするための大市場の利用
- ソフトウェア要件の確立に際し、開発循環計画の一部として、迅速なプロトタイピングを使用すること
- 実行と使用とテストが行われるにつれて、より多くの機能をシステムに追加しながら、ソフトウェアを有機的(系統的)に成長させること
- 若い世代の素晴らしいコンセプトデザイナーを発掘し、育てること。
銀の弾丸の続き
銀の弾丸が話題になってから9年後、氏は改めて『「銀の弾などない」再発射』という論文を発表しています。しかし、「やっぱり銀の弾丸はなかったぽいよ」という発表のようで、「悲観的すぎる」という意見に対し「むしろ楽観的すぎた」と回答しているのがすごい。
そして、今回お伝えしたかった「その続き」は「問題の所在—銀の弾とソフトウェアプロジェクト」にあります。氏は、なぜ特効薬になりえないのかの説明をしながらも、その一方で革新的なアイデアにトライする人たちを忘れていません。
輝かしい進展は見えないが、実際のところそう決めてかかることはソフトウェアの本質からは離れている。多くの頼もしい新機軸 (革新) が着々と進められている。
そして、開発する人や普及に務める人たちにもエールを送っています。
それらを開発、普及、利用するという苦しいが一貫した努力こそ、飛躍的な改善をもたらすはずだ。
最後の言葉こそ、氏の伝えたかったことを表しているのではないでしょうか?
王道はない。しかし、道はある。
帰り道に思ったこと
「全員スクラムマスター。」のダイアログ内で「導入しようとしてもうまくいかない」という経験を語って下さった方がいらっしゃいました。きっと「今よりもっと良くしたい」だけのことなのに、なんでかそれが難しい。
また2016年にブルックス氏が「やっぱり銀の弾丸はなかった」を発表するかもしれませんが、「道は開ける」と信じて、いろいろな道を歩くのが正解のような気がします。
革命的改善をただ待ったり、期待するのではなく、発展的改善を検証する時が来た。
今回のDevLOVEはいろいろ考えさせられる勉強会でした。
*
私がスクラムをやめた理由 – 全員スクラムマスター。@DevLove –
