2013年3月に「ソフトウェア開発を『しない』人がスクラムでスクラムを導入する」ための本がASCIIから出版されました。
https://amazon.co.jp/dp/9784048912365
RubyKaigi 2013に参加したときに訳者の角さんと川口さんからもらったので読みました。過去にソフトウェア開発をする人向けのスクラムの本は何冊か読んでいて、実際ソフトウェア開発をする人なので、ソフトウェア開発をする人視点で読みました。実は読んでからしばらく経っているので、最初の方を少し読み返してみたところ、いくつか考えることがありました。まとまっていませんが、書いてみます。
スクラムと開発者
スクラムを導入すると開発者がすばらしくなる、という描写が印象的でした。最初の方の記述なので、メリットを強調するための記述なのかもしれません。この本を読む前までのスクラムのイメージは、「できる人に任せるとうまくいくよ」であって、「できない人でも任せるとできる人になってうまくいくよ」ではなかったので、これまでの印象と違いました。ただ、実際はどうなのかはわかっていません。この本を読むと「できない人でも任せるとできる人になってうまくいくよ」の方な気もします。
P.29
ジェーンが新しいソフトウェア開発手法のことをみんなに伝えると、懐疑的に受け止められた。特に開発チームのメンバーは、受け入れるのに時間がかかった。（中略）しかし、新しいプロセスの経験を積んでいくと、（中略）開発者は、イテレーションで顧客と直接やり取りができるようになった。要求を自分たちで理解して、どうすればうまく実装できるかを考えられるようになった。
途中で止めることは成功か
最初に、ウォーターフォールと比べてスクラムの方がいいよ、というような話がでてきます。わかりやすいからでしょう。
その中に「ウォーターフォールは途中で止めると何も成果をえられないけどスクラム（経験主義のソリューション）では途中で止めてもそこまで作ってきた価値を利用できるからよい」というようなことが書いてあります。（P. 38の「2.2 経験主義は問題を解決するか？」の「ウォーターフォールの問題1」。）
同じようなことで「スクラム（経験主義のソリューション）ではすべてが完成する前から途中まで作ったものを利用できるから利用者に早く価値を届けられるのでよい」ということも言われています1。これはたしかにそうだというのは理解できます。実際にフリーソフトウェアをそのようにリリースしていて、その通りであることを実感しているからです2。
しかし、途中で止めたプロジェクトがその後も有益に利用し続けられるのかというとピンときません。メンテナンスされなくなったフリーソフトウェアをその後も使い続けたいとは思わないからかもしれません。例えば、以前はWebブラウザーとして風博士_(ウェブブラウザ)を使っていましたが、メンテナンスされなくなってしばらくすると新しい環境では動かなくなり、Firefox3に移行しました。フリーソフトウェアの場合、有用なソフトウェアならたとえ元々メンテナンスしていた人たちがメンテナンスしなくなっても他の人たちが代わりにメンテナンスするようになったり、代替となるフリーソフトウェアが開発されます。このような場合は一度は途中で止まったプロジェクトでもその後も有益に利用してきました4。
このように、自分の経験に合わせて考えると、途中で止まってその後メンテナンスされないプロジェクトでも有益に利用し続けられる、ということがピンときませんでした5。
やわらかなマネジメント
スクラムでは開発チームは自己組織化していなければいけません。これは、マネージャー（スクラムマスター）から管理されない代わりに、開発チームは自分たちで考えて決めなければいけないと理解していました。例えば、プロダクトバックログのそれぞれの項目をどのくらいの時間でどうやって実現するかは開発チームが自分たちで考えて宣言し、それを守るために行動する。もし、時間がオーバーしそうならそれの調整も自分たちでする。そのような開発チームだと理解していました。
しかし、その理解は違ったようです。P. 44の「やわらかなマネジメント」には以下のように書いてあります。
プロジェクトの開発チームが自分たちのやり方で進めていたとしても、管理されていないということではない。自己管理に重点を置いて、十分なチェックポイントを作り、不安定・あいまい・緊張がカオスにならないようにする。
開発チームは、自分たちがどうやって行動するかを決めて、それを実現するために行動をするというところまでは理解があっていたようですが、それがうまくいくようにサポートする人が必要だ6ということは理解が違っていました。スクラムマスターは開発チームが自分たちだけでできるようになるまでサポートする、くらいのイメージでしたが、ずっとサポートしているようです。
スクラムはなんでもそつなくこなせる人たちばかり集めなければ（ばかりにならなければ）実現できないやり方というわけではなさそうです。これまで、一部苦手なことはあるけれど他はしっかりできる人を何人かみてきたのですが、そのような人たちには向いていないやり方だと認識していました。なので、「習得は非常に困難」はその通りだろうと理解していました。この「やわらかなマネジメント」もあるなら、最初の認識ほど敷居は高くなさそうです。ただ、習得は非常に困難というのは変わらないでしょう。
まとめ
Software in 30 Daysの最初のところを読み返して考えたことをまとまりなく書いてみました。ここでは、最初の方だけにしか触れていませんが、後半はスクラムでスクラムを導入するということまでやっているので、組織にスクラムを導入してみたいと考えている人は読んでみるとよいでしょう。
-
すぐにはみつけられませんでしたが、たぶん、この本にも書いているでしょう。 ↩
-
例えば、groongaを毎月（30日毎に！）リリースしていて、何人ものユーザーが活用していることを知っています。 ↩
-
本当はIceweasel。 ↩
-
違うプロジェクトに移行していることもありますが、前のプロジェクトを使っていたときに得た知見を引き継いで利用するので、ムダとは感じません。 ↩
-
この本で想定しているCXOとしての経験が足りない気がします。 ↩
-
たぶん、2日でこの機能を実現するためには、1日目では○○まで進んでないといけなそうだね。大丈夫？みたいなことをそれとなく、鬱陶しがられないように聞いたりするのでしょう。違うかしら。 ↩
