スクラムに取り組むことで、何もかもがスクラムチームのもとに明らかになっていき、(プロダクト開発にまつわる)悩みや苦しみを個人で抱えこむといったことはとても少なくなります。*1
あ……、とは言いながら、僕はまだスクラムをやっているわけではなくて、『アジャイルな見積りと計画づくり』や『アジャイルサムライ』を読んで、イテレーティブでインクリメンタルな開発をしていこうよ、という機運のもとソフトウェアを開発している一介の開発者にすぎないのですが、先日、日本で唯一の認定スクラムトレーナーである江端さんが講師をつとめる認定スクラムマスター研修に参加し、世間知にまみれまくった認識を色々とひっくり返されてピュアになり、それなりにスクラムが何なのか理解できたつもりなのが今です。今所属しているプロジェクトで、これからはきちんとスクラムのフレームワークに則ってみようということになり、色々と準備をしています。(というか、徐々に始めています)
スクラムはすべてを明らかにし、悩みや苦しみは共有される
閑話休題。
繰り返すと、スクラムに取り組むことで、何もかもがスクラムチームのもとに明らかになっていき、(プロダクト開発にまつわる)悩みや苦しみを個人で抱えこむといったことはとても少なくなるわけです。
事実、まあまだ完全なスクラムをやっているわけではないにせよ(むしろ、にも関わらず)僕が個人的に管理しているタスクの数(private な Trello のボードにあるカードの数)は、これくらい変わりました。
- 始める前 : 100(±50)件程度
- 現在 : 30 件くらい
もちろん、タスクの粒度が大きくなったとか、単に管理しなくなったとかいうことではなく、消えたアイテムはすべてチームが知るところのタスク、具体的には壁やホワイトボードに貼られた付箋になっています。*2
この調子でいくと、たぶん個人用の Trello のボードは捨てることになるな、と思っています。
あるいは残すにしても、もっとシンプルな Todo リストのようなものになるか。
そして、100件→ 30 件になった現時点で、既に以下のような心境です。
『アジャイルな見積りと計画づくり』スタイルの開発を2ヶ月あまりやってきて、いよいよまともにスクラムに取り組もうかという昨今、あんなにギッチギチだった個人のタスクボード(自分にしか見えないprivateなTrelloのボード)がスッカスカになってきていて、実に清々しい。
— enk (@enk_enk) 2016年8月26日
清々しいんです。
清々しすぎて、いいのかしらという何か罪悪感みたいなものすら覚えます。
個人で何か抱えたときのストレスがヤバイ
とは言いながら、まだほんとのスクラムを始めていないので、ちょいちょい個人タスクみたいになっているものごとがあります。
そんな状況での一幕がこちら。
つらいんですよ。前よりも。
一人で何かを抱えるようなことになると。仕様が明らかになっていない状態で作り始めるようなことをすると。
以前はできたんです。3 ヵ月かかる機能の開発を仕様策定から設計・開発・テストまで、見積りからスケジュール管理まで、全部一人でやってましたよ。もちろん、必要に応じて相談しながらですけど……。
当然のようにやってたんです。まあ、きっと効率はよくなかったのでしょうけど。
かたや見積り 2 時間のタスク。タイムスパンで言っても一日。でつらいとか。
軟弱になっています。明らかに(不明瞭さへの)ストレス耐性が下がっています。
スクラムをやっているチームで育った子はスクラムをやらないチームでやっていけないのでは
そんなわけで、「スクラムをやっているチームで育った子はスクラムをやらないチームでやっていけないのでは」という心配をするに至ります。
正直に言って、自分のことは心配していません。
スクラムじゃない状態も知っているし、まあいざ必要となれば辛く厳しい戦場に戻っていくこともたぶんできます。*3
そういうところへ行っても、辛抱強く働きかけて、徐々にスクラムにしていけば(あるいは、もっとすぐれた別のやり方があれば、それにしていけば)いい、と思います。
でも、スクラムで育った子がいたとして、スクラムじゃないものをスクラムに変えていく方法も知らない、そんな子が、何らかの事情で突然放り出されることになってしまったら。
たとえば、会社が倒産したら?
全然余裕でした
スクラムというのがどういう状態かとてもよく知っているのだから、そういうものを求める組織に行けばいいだけですね。
簡単でした。
ただ、何らかの理由でそうじゃない組織に入ってしまうと、「(そうじゃないものと)比べながら戦略を立てたり説得できない」という点ではやや不利になるかもしれません。
また、そういうものを断固として受け付けそうにない、受け付ける余地のない組織に所属することも慎重に避けねばなりません。
そしてもちろん、ストレスがかかるでしょう。少なくともはじめは。
なんせその(ものごとがチームのもとで明らかになっていない)状態を知らないので、かなり強烈なストレスになるかもしれません。
ただ、結局それを先に味わうか後に味わうかという問題であって、「先に味わう」ことのコスト(生産性の低い時間を過ごすことのコスト)を計算に入れれば、先に味わう方がよい、とう結論は導きがたいように思います。
たぶんこれからの組織はスクラム(的なもの)になっていくはず
そして、スクラムの状態を知っておいたほうがよい、と言えるもう一つの理由が、(現時点でまだまだ多いと思われる)従来型の組織は、スクラムを活用する組織に置き換えられていくだろう、と予測できることです。
かっちりした根拠はないのですが、まあ、そっちの方がいいから、ですね。少なくとも営利組織にとっては。
もちろん、僕が知らないスクラム以外のプロダクト開発方法論はあるのかもしれませんし、ある程度それがスクラムに似ているということもあると思います。
従来型の「アサインされた(あるいは、個人が自主的に作り出した)タスクを抱え込む」スタイルよりも、「明らかにしていく」やり方のほうが優勢になっていくだろう、というのが論旨です。
スクラムをやりながらメンバーを育てよう
当然ながら、スクラムのスタイルによる見習いメンバーへのメリットも数多くあります。
- うまくいくというのがどういうことかわかる
- (単純に知識が少ないことが原因の)しょうもないハマりの時間が減り、どんどん新しいことを学習できる
- 組織やプロダクト、チームの一部だけではなく、初めから全体を意識しながら仕事ができる
- 「適応する」ということがどういうことか身をもって学べる
スクラムそのものはまだ始めていないのであまり多くは思いつきませんが、きっとまだ他にもあると思います。
こういうメリットのことを意識しながら経験の浅いメンバーを育てていくことができれば、きっとそのメンバーの成長にとってとても有意義な毎日になるはずです。
今気づいたのですが、特に最後のが重要で、この「適応する」という能力を持っていれば、たぶんあまりイケてない組織に放り出されることになっても、その人は何とかやっていけると思います。
よかった。
書き始めたときには本気で心配していたので、安心してしまいました。
最後にひと言
僕がこないだ学んだのがたまたまスクラムで、とてもよくできた(僕が知っている数少ない他のものよりもよい)システムだと感じたので「スクラム」という固有名詞を一貫して使いましたが、スクラムが嫌いな人は、別の言葉に置き換えて読んでもらってもよいです。「アジャイル」とかでも。
ただ、それが、人間というものを深く理解して作られたシステムで、ものごとを徹底的に白日のもとにさらして、それを調べ、適応し続けていくようなものであるならば。