この国では犬が

本と芝居とソフトウェア

ひとが生きるか生きないか

次の日曜に舞台に出るのだけれど、これが一回きりの公演で、震えている。

僕が所属する劇団は 20 年続いていて、年一回の本公演は基本的に(たぶん、すべて?)書き下ろしの脚本で、再演は一度もない。

今回も、書き下ろし。

よって、今年の台本で僕が演じる人物は、もし僕がその人物を演じなければ、過去にも未来にも、おそらく永遠に存在しない。

ということに今更気づいて、震えている。(公正を期すために言っておくと、部屋が寒いせいもあるかもしれない)

僕は去年の本公演が初舞台で今回が二回目で、去年だって条件は同じだったのだけど、震えることなかったのは、鈍かったのですね。

「その人物を生きなければ」と言いかけたけど、生きるなんてことができると思うのはさすがに思い上がりであって、せめて、精一杯演じようと思います。

その中で、一瞬でも生きられたらいいなとは思う。

でも、決して力んではいけない。意気込んでもいけない。(たぶん)
俳優業は難しい。

公演情報

カラマーゾフのまちわびて」

  • 日時 : 2016 年 11 月 27 日(日) 13:30 開場 14:00 開演
  • 場所 : 府中の森芸術劇場 ふるさとホール(京王線東府中駅から徒歩 10 分ほど)
  • 入場無料

500 人くらい入るホールで入場無料、チケット・整理券等も不要なので、東京近郊の方いらっしゃいましたら、ぜひお気軽にお越しください。
11 月末の東府中駅から府中の森芸術劇場への道は風が冷たくて……いい感じです。

開発者とスクラムマスターを兼任するとつらいし成果も出ない(と思われる)

スクラムチームで開発者をやっていると、開発者としての振る舞いとスクラムマスターとしての振る舞いは違うな、ということを日々痛感します。

開発者をやっていると「スクラムマスターらしい振る舞い」ができない

8 月に認定スクラムマスター研修に参加して、スクラムマスターとして然るべき振る舞いをある程度は理解していると思います。
スクラムマスターの振る舞いはスクラムチームを最大限効果的にする振る舞いなので、開発者とはいえ、できるだけそう努めようとしてみるのですが、開発者として働いていると、それができません。

というより、それをやっていると、開発者としての責任が果たせなくなるので、したくてもできない、というのがより正確かもしれません。

これでは、開発者とスクラムマスターを兼任するとつらいし成果も出ないだろうな、と思います。
幸い、僕のチームでは兼任ではないのですが。

開発者とスクラムマスターの違い

開発者として僕がふだん心がけている振る舞いと、以前参加したスクラムマスター研修で学んだ*1スクラムマスターとしての振る舞いは、日々のそれぞれの場面で、以下のように違います。

場面 開発者としての振る舞い スクラムマスターとしての振る舞い
Daily Scrum 自分の状況や知見を話して共有し、また他のチームメンバーの発話から状況や知見を得る 言語・非言語を問わずチームメンバーのコミュニケーションから状況を把握し、また効果的なデイリースクラムの運用につとめる
Product Backlog Refinement 開発者として PBI への意見や提案・要望を出し、意見交換をしながら理解を深め、自身の考えをもとに見積りを行う プロダクトオーナーと開発者との効果的な意見交換を促進し、メンバーの様子を観察して、限られた時間内で、PBI に対しての学習効果や見積りの正確さのバランスを取りながら、最大限の効果を得ることにつとめる
Sprint Planning コードベースや設計・テスト手法等についての知識を最大限提供しながら、他のチームメンバーの知識も取り入れ、全体として正確で適切に構成された計画の作成につとめる 計画作業の全体を俯瞰し、チームの学習効果や計画の正確さのバランスを取る
Sprint Review 実際にプロダクトを動かしながら説明し、またプロダクトの改善提案を行う 限られた時間内で、プロダクトについて最大の学習効果とすぐれた提案が得られるようつとめる
Sprint Retrospective チームとプロダクトをよりよくするために、何がうまくいっているのか、何が問題なのかといったことを忌憚なく発言し、また他のチームメンバーの発言に耳を傾け、改善のためのアクションに合意する チームが衝突を恐れず意見を交換し、チーム全体で責任を持って改善のためのアクションに合意できるよう導く
日々の開発 開発・テスト・レビューといったタスクに集中して実行する タスクボードの状況や人の動き、会話を観察し、チーム全体として効果的に開発を進められているか、問題やボトルネックがないか探す
全体 開発者としての知識・能力を最大限発揮し、スクラムチーム全体のために有用な意見や考えを主張し、また他のチームメンバーの意見や考えから学ぶ チームのありとあらゆる振る舞いや言語・非言語コミュニケーションを常に観察し、スクラムをより効果的にするために、もっとも適切なタイミングで、もっとも適切な方法をもって介入する

総じて、開発者はアウトプットを最大化することに集中します。短期的なアウトプットを(ほとんど)一手に担っているのが開発者で、開発者がアウトプットしないと何も生まれません。と同時に、開発者として学習します。これが長期的なアウトプットの増加につながります。
一方、スクラムマスターはチーム全体を徹底的に観察し、データを集め、ここぞというときに、これぞという方法で、わずかなアウトプット(チームへの介入)をします。ときには、あえて(短期的には)チームのアウトプットやムードが悪化するようなことも(推進はしないまでも、許容)します。その結果として、(長期的には)チーム全体のアウトプットが大きく改善します。*2

開発者とスクラムマスターを兼任するのはつらい

チームメンバーとしての振る舞い、行動の指向性はスクラムマスターのそれとは大きく違い、重ならない部分が大きく、開発者とスクラムマスターを兼任してはいけない、と言われることの意味がわかります。
おそらく、開発者とスクラムマスターを兼任する方が、2 つのスクラムチームのスクラムマスターを兼任するよりも難しいだろうな、と思います。

同時に重ならない 2 つの目的を持ちながら生活するのは、なかなか苦しいことです。

開発者とスクラムマスターを兼任しても成果が出ない

それをできるのは一種の能力で、相当鍛えればたぶんある程度はできるようになるのでしょうが、どんなにがんばっても、0.5 人弱の開発者と 0.5 人弱のスクラムマスター分の仕事をするのが最大限だろう、と感じます。

スクラムという仕組みは、そもそもそれをしなくてもすむように設計されています。
であれば、素直にその設計に従い、スクラムマスターをフルタイムの仕事とするのがおそらく賢明です。

補足 : プロダクトオーナーについて

なお、このエントリではスクラムのもう一つの役割であるプロダクトオーナーに触れていませんが、それは僕がプロダクトオーナーの経験がなく、十分な知識もないと考えているためです。
とはいえ、想像するだに、プロダクトオーナーとスクラムマスターとの兼任は、開発者とスクラムマスターとの兼任以上に難儀だろうな、と思います。

*1:僕なりにこう理解したということで、必ずしも研修でこの通り説明されていたわけではないので、異論・反論は歓迎します

*2:と、理解しています。スクラムマスターの役割はあくまでスクラムを最大限効果的にすることなので、必ずしも観察することが最善の手段というわけではないかもしれませんが……。

みんな死ぬ

理屈ではなく肌感覚で、みんなやがて死ぬのだということに支えられて、生きている今が美しいのだという感覚があって、でも肌感覚なのでこれ以上の説明ができないのだけれど、たしかにそういう感覚がある。

短く言うと、みんな死ぬ。
これを当座の座右の銘にしている。

みんな死ぬ、だから生きていられる、とも言える。

死ぬことそのものが嬉しいかというと、そんなことは(少なくとも肌感覚では)まったくなくて、死にたくない。
でも、その死ぬことに救われて生きている。

もし死なないとしたら、(少なくとも今ほどは)生きていたくないだろうと思う。
妙だけど、そう感じるのだから仕方がない。

重要なのはみんな死ぬということで、別に自分だけが死ぬわけではない。
自分だけが死ぬのだったらちょっと寂しすぎるけれど、みんな死ぬ。例外は(知る限り)ない。いい人も、悪い人も、天才も、凡人も、好きな人も、嫌いな人も、家族も、先生も、犬も、猫も、みんな死ぬ。例外なく。

せっかく死ぬのだから、生きている今のことはせめて大切にしよう、と思う。
というより、どうせ死ぬのに、生きている今のことを大切にしてしまう。

妙ですね。
妙だけど、そうしてしまうのだから仕方がない。

他の人(たち)といて楽しいとき、というか他の人(たち)が楽しそうなときとか、あーみんな死ぬなあ、よかったなあ嬉しいなあ、と思います。
もちろんよかったのは死ぬことではなくて、楽しいことが。死ぬまでの間に、楽しい時間を過ごせたことが。

みんな死ぬ、ということを覚えておくと、このように生きている今のことを少し大切にできます。(不思議なことに)

世界

演劇も、結局、世界に愛してるよと言う方法の一つなのかも、という気がします。

でも、今まで世界と呼んでいたものとこれとのあいだには少しずれがあって、この世界には人間がいる。いるし、必要。

人間の集まりとしての世界に愛してるよと言うためのきわめて効果的な方法が演劇で、人間の集まりとしての世界に愛してるよと言いたくなったから演劇を始めたのだと考えると、じつにしっくりきます。

人間の集まりとしての世界を愛せるようになったら、必ずしもそれを愛せなかった頃にあった「自分が人間であること」との矛盾が解消されて、じつにすこやかです。

このように、生きているとたまにすごくいいことがある。

スクラムをやっているチームで育った子はスクラムをやらないチームでやっていけないのでは仮説

スクラムは、すべてを明らかにするフレームワークです。

スクラムに取り組むことで、何もかもがスクラムチームのもとに明らかになっていき、(プロダクト開発にまつわる)悩みや苦しみを個人で抱えこむといったことはとても少なくなります。*1

あ……、とは言いながら、僕はまだスクラムをやっているわけではなくて、『アジャイルな見積りと計画づくり』や『アジャイルサムライ』を読んで、イテレーティブでインクリメンタルな開発をしていこうよ、という機運のもとソフトウェアを開発している一介の開発者にすぎないのですが、先日、日本で唯一の認定スクラムトレーナーである江端さんが講師をつとめる認定スクラムマスター研修に参加し、世間知にまみれまくった認識を色々とひっくり返されてピュアになり、それなりにスクラムが何なのか理解できたつもりなのが今です。今所属しているプロジェクトで、これからはきちんとスクラムフレームワークに則ってみようということになり、色々と準備をしています。(というか、徐々に始めています)

スクラムはすべてを明らかにし、悩みや苦しみは共有される

閑話休題

繰り返すと、スクラムに取り組むことで、何もかもがスクラムチームのもとに明らかになっていき、(プロダクト開発にまつわる)悩みや苦しみを個人で抱えこむといったことはとても少なくなるわけです。

事実、まあまだ完全なスクラムをやっているわけではないにせよ(むしろ、にも関わらず)僕が個人的に管理しているタスクの数(private な Trello のボードにあるカードの数)は、これくらい変わりました。

  • 始める前 : 100(±50)件程度
  • 現在 : 30 件くらい

もちろん、タスクの粒度が大きくなったとか、単に管理しなくなったとかいうことではなく、消えたアイテムはすべてチームが知るところのタスク、具体的には壁やホワイトボードに貼られた付箋になっています。*2

この調子でいくと、たぶん個人用の Trello のボードは捨てることになるな、と思っています。
あるいは残すにしても、もっとシンプルな Todo リストのようなものになるか。

そして、100件→ 30 件になった現時点で、既に以下のような心境です。

清々しいんです。
清々しすぎて、いいのかしらという何か罪悪感みたいなものすら覚えます。

個人で何か抱えたときのストレスがヤバイ

とは言いながら、まだほんとのスクラムを始めていないので、ちょいちょい個人タスクみたいになっているものごとがあります。

そんな状況での一幕がこちら。

f:id:enk_enk:20160826204917p:plain

つらいんですよ。前よりも。
一人で何かを抱えるようなことになると。仕様が明らかになっていない状態で作り始めるようなことをすると。

以前はできたんです。3 ヵ月かかる機能の開発を仕様策定から設計・開発・テストまで、見積りからスケジュール管理まで、全部一人でやってましたよ。もちろん、必要に応じて相談しながらですけど……。
当然のようにやってたんです。まあ、きっと効率はよくなかったのでしょうけど。

かたや見積り 2 時間のタスク。タイムスパンで言っても一日。でつらいとか。
軟弱になっています。明らかに(不明瞭さへの)ストレス耐性が下がっています。

スクラムをやっているチームで育った子はスクラムをやらないチームでやっていけないのでは

そんなわけで、「スクラムをやっているチームで育った子はスクラムをやらないチームでやっていけないのでは」という心配をするに至ります。

正直に言って、自分のことは心配していません。

スクラムじゃない状態も知っているし、まあいざ必要となれば辛く厳しい戦場に戻っていくこともたぶんできます。*3
そういうところへ行っても、辛抱強く働きかけて、徐々にスクラムにしていけば(あるいは、もっとすぐれた別のやり方があれば、それにしていけば)いい、と思います。

でも、スクラムで育った子がいたとして、スクラムじゃないものをスクラムに変えていく方法も知らない、そんな子が、何らかの事情で突然放り出されることになってしまったら。
たとえば、会社が倒産したら?

全然余裕でした

スクラムというのがどういう状態かとてもよく知っているのだから、そういうものを求める組織に行けばいいだけですね。
簡単でした。

ただ、何らかの理由でそうじゃない組織に入ってしまうと、「(そうじゃないものと)比べながら戦略を立てたり説得できない」という点ではやや不利になるかもしれません。
また、そういうものを断固として受け付けそうにない、受け付ける余地のない組織に所属することも慎重に避けねばなりません。

そしてもちろん、ストレスがかかるでしょう。少なくともはじめは。
なんせその(ものごとがチームのもとで明らかになっていない)状態を知らないので、かなり強烈なストレスになるかもしれません。

ただ、結局それを先に味わうか後に味わうかという問題であって、「先に味わう」ことのコスト(生産性の低い時間を過ごすことのコスト)を計算に入れれば、先に味わう方がよい、とう結論は導きがたいように思います。

たぶんこれからの組織はスクラム(的なもの)になっていくはず

そして、スクラムの状態を知っておいたほうがよい、と言えるもう一つの理由が、(現時点でまだまだ多いと思われる)従来型の組織は、スクラムを活用する組織に置き換えられていくだろう、と予測できることです。
かっちりした根拠はないのですが、まあ、そっちの方がいいから、ですね。少なくとも営利組織にとっては。

もちろん、僕が知らないスクラム以外のプロダクト開発方法論はあるのかもしれませんし、ある程度それがスクラムに似ているということもあると思います。
従来型の「アサインされた(あるいは、個人が自主的に作り出した)タスクを抱え込む」スタイルよりも、「明らかにしていく」やり方のほうが優勢になっていくだろう、というのが論旨です。

スクラムをやりながらメンバーを育てよう

当然ながら、スクラムのスタイルによる見習いメンバーへのメリットも数多くあります。

  • うまくいくというのがどういうことかわかる
  • (単純に知識が少ないことが原因の)しょうもないハマりの時間が減り、どんどん新しいことを学習できる
  • 組織やプロダクト、チームの一部だけではなく、初めから全体を意識しながら仕事ができる
  • 「適応する」ということがどういうことか身をもって学べる

スクラムそのものはまだ始めていないのであまり多くは思いつきませんが、きっとまだ他にもあると思います。
こういうメリットのことを意識しながら経験の浅いメンバーを育てていくことができれば、きっとそのメンバーの成長にとってとても有意義な毎日になるはずです。

今気づいたのですが、特に最後のが重要で、この「適応する」という能力を持っていれば、たぶんあまりイケてない組織に放り出されることになっても、その人は何とかやっていけると思います。

よかった。
書き始めたときには本気で心配していたので、安心してしまいました。

最後にひと言

僕がこないだ学んだのがたまたまスクラムで、とてもよくできた(僕が知っている数少ない他のものよりもよい)システムだと感じたので「スクラム」という固有名詞を一貫して使いましたが、スクラムが嫌いな人は、別の言葉に置き換えて読んでもらってもよいです。「アジャイル」とかでも。

ただ、それが、人間というものを深く理解して作られたシステムで、ものごとを徹底的に白日のもとにさらして、それを調べ、適応し続けていくようなものであるならば。

*1:何もかもが明らかになることへの悩みや苦しみはあるかもしれませんが……

*2:先述のようにスクラムそのものはまだ始めていないので、モノによってはとりあえず貼ってるだけとかだったりするのですが、いずれスクラムの枠組みに吸収されます

*3:スクラムが厳しくないわけではないですが、別の種類の厳しさです