この国では犬が

本と芝居とソフトウェア

2017 年のふりかえり

生活

2017 年をふりかえります。

年間目標のレビューから。

目標 : 月に 1 冊以上技術書を読む

今年は、以下 15 冊の技術書を読みました。

  • みんなのGo言語
  • M2M/IoTシステム入門
  • レガシーソフトウェア改善ガイド
  • [改訂第3版]Jenkins実践入門
  • The DevOps ハンドブック
  • ユーザーストーリマッピング
  • Lean UX
  • The Nature of Software Development
  • Running Lean
  • リーン顧客開発
  • 初めての自動テスト
  • テスト駆動開発
  • 継続的デリバリー
  • エリック・エヴァンスのドメイン駆動設計
  • おうちで学べる人工知能のきほん

年間 15 冊ということで月 1 冊以上のペースなので、目標達成ということになります。

総括

前半はチームとか組織のことをやってたので、どうしても興味がそっちにいきがちでした。
9 月から異動で役割が開発者になったため、そこから一気に稼いだ感じです。

もともとこの目標は、今年の前半みたいなマネジメント的役割にあっても技術のキャッチアップを続ける……という意味での「月 1 冊」だったので、開発者になった今となっては微妙っちゃ微妙な数字です。
ただ最近は入門書・技術ハウツー本というよりは第一人者が書いた鈍器系の本をしっかり読み込むことが増えてきたので、月 1 冊ペースでも十分着実に学んでいるとも言えます。

とにかく達成してめでたい。

開発職に戻った（しかも新製品開発！）ので最近は開発本をビシバシ読んでいるのですが、なかでも『エリック・エヴァンスのドメイン駆動設計』を読んだのは収穫でした。
自分で言うのもなんですが、今所属している組織にあって「Java で適切なコードをすばやく書くスキル」は割と限界付近まで高まってて、それでもイマイチ価値を出しきれてない感じがしたのでチーム／組織とかプロダクトマネジメントの方に関心が向いていたのですが、コードのレベルでも（あるいは、コードのレベル「から」）まだまだやれることがたくさんあるのだと気付かされました。

関連書籍

技術書かは微妙なところだけどソフトウェア開発関連の本というところでは、以下の 10 冊あたり。

  • アジャイルコーチング
  • 変革の軌跡 世界で戦える会社に変わる "アジャイル・DevOps" 導入の原則
  • カンバン ソフトウェア開発の変革
  • 今すぐ実践！ カンバンによるアジャイルプロジェクトマネジメント
  • The DevOps 逆転だ！
  • The Great ScrumMaster
  • スクラム 仕事が 4 倍速くなる "世界標準" のチーム戦略
  • Mob Programming: A Whole Team Approach
  • リーン・スタートアップ
  • IntelliJ IDEA ハンズオン

スクラムやらカンバンやらの本をほとんど片っ端から読んでる感じで、なんかひどいですね。

以下は再読。

実践していると、再読からも得るものがたくさんあります。

今読んでる本。*1

実践の中にいないと学べないタチなので、開発者やってる今のうちにこの辺のところにどっぷり浸かっておきたい。

近いうち読みたい本。

最近はとにかく買う本を減らしていて、というのは買っても読めてない本がいい加減積み上がりすぎているからなのですが、「買わない」という選択を続けていると、本は世の中に一生かけても読めないくらいたくさんあるのだ、ということを実感して、寂しい気持ちになります。

ただ寂しいというだけではなくて、今読んでいる本は、選んでそれに（時間を）投資しているのだ、ということもひしひしと感じます。

何を選んで、何を選ばないのか、ということに意識的になります。
意識していようがいまいが選んではいるのだから、意識できるようになったのはきっといいことです。

目標 : 月に 5 回以上演技クラスに通う

年間延べ 56 回。

月 5 回ペースだと 60 回になるので、4 回不足でした。
海外出張とか劇団の本公演とかで休んだ分をリカバリできなかった。

とはいえ、一年通してコンスタントに通い続けることができました。
このペースだとさすがに劇的な成長みたいなのを感じることはないのですが、少しずつ色々なことができるようになってきています。

少しずつ。

目標 : 本は月 8 冊、観劇は月 6 回程度（まで）にする

本は、92 冊。

月 8 冊ペースだと年間 96 冊なので、ほぼぴったりです。

観劇は、47 本。

月 6 回ペースだと 72 本なので、だいぶ下回っています。
だいたい月 4 本ペースですね。

なんか、これくらいがちょうどいいんじゃないか、という感じがします。

かわりに何をしたか

この目標には、去年まで時間の大半を注ぎ込んでいたアクティビティを減らして、減らすことで他のことができるようになるはず、という含みがありました。

かわりに何ができたかというと、

  • 演技クラスに通う
  • 鈍器系や英語の技術書を読む
  • 映画を観る

この辺でしょうか。

演技クラスについては、前述の通り。

技術書については、

あたりの（物理的に）重い本を読んだり、

  • The Great ScrumMaster
  • The Nature of Software Development
  • Developer Testing

あたりの英語の（翻訳されていない）本を読んだりすることができました。

一日の中で本を読む時間はある程度確保されているので、冊数を減らすためには、一冊にかかる時間を増やす必要があります。（妙な理路ですが……）
結果として、この辺の読むのに時間がかかる本を読むことが増えました。

というか、実はこれは偶然の結果ではなくて、その辺が狙いの一つだったので、狙いが的中しました。

映画は年間で 20 本弱くらい見ました。
前半よく観たのですが、後半あまり観なくなってしまいました。

どうもやっぱりどこかで映画を信じてないところがあるっぽくて、映画はメジャーエンタメなので仲良くなりたいのですが（ぼくもメジャーになりたい）、なかなか仲良くなれません……。

月 8 冊 / 6 本ってぶっちゃけどうなのか

月 8 冊という読書ペースは、はっきり言ってしんどいです。
読みたい本の多さに対して、スループットが低すぎて。

とはいえ、人としてこれくらいがまともなペース、という感覚もあります。
だから、選んでいく、厳選していく必要があるのだと思います。

ちょっと仕事に傾倒しすぎて、詩とか小説とかをほとんど読めなかったのが大いに反省ポイントです。もっと読みたかった。
来年はバランス取っていきたい。ただ、詩とか小説とかって計画的に読むものでもないので、悩ましいところでもあります。

観劇については、結果として月 4 本ペースでも何となく満足してしまいました。
もっと観たかったかと聞かれれば観たかったのですが、観なけりゃ観ないでなんとかなってしまうというか……。ちょっと意外でした。

といっても、年間 100 本（近く）も観たのは去年だけなので、去年が異常だっただけなのかもしれません。

月 4 ≒ 週 1 というのはわかりやすい数字で、これだけあればそれなりに色々観られるので、来年もこれくらいを目安に観ていけるといいのかなと思います。

目標 : 毎月計画してふりかえる

8 月までやってました。

7 月あたりから仕事とプライベートの計画を統合してやっていたのですが、9 月に異動になって、仕事のスタイルが大きく変わったのにともない、気がつくと個人の計画をやらなくなってしまっていました。
7 月の時点では統合しないメリットがない、と思っていましたが、統合するとこういう事故も起こるのですね……。

目標もおおむね達成できているし、結果オーライかな？　という気もしますが、これは 8 月まできっちりやっていたおかげ（その慣性で達成した）という気もするので、やはりあんまりいいことではないかな。

来年 1 月からは仕事の様子がまた少し変わるということもあるので、新しい計画とふりかえりのやり方を模索していきたい。

目標 : 丁寧に暮らす

会社の移転に合わせて、11 月に引っ越しました。

そして、荒れてます。

ものが多いというのは一因。
右のものを左にやると左が埋まるだけ、みたいな状況なので。

引っ越しに際して本と CD を段ボール 2 箱分減らしたのですが、引越し先で棚に詰め込めるだけ詰め込んだら段ボール 4 箱分残りました。
なんということでしょう。

やるべきことは見えていて、この 4 箱分を何らかの形で部屋から出すことです。
まあ、処分するべきなんだろうな。

既に処分する対象は選定していて、でも全然 4 箱分に至らないので途方に暮れています。
たぶんこのままでは埒があかないので、まずは選んだ分だけでも売ろう。

そうしよう。

まとめ

2017 年も色々なことがあったにはあったのですが、総じて言うと、今いる場所でやることをきっちりやっていたら終わった一年、という感じがします。
悪いことではないのですが、よくもないですね。

いい面を見るなら、やることをきっちりやるのはもう当然のようにできる、ということです。

でも、やることって、なんだ？

かれこれ 10 年近く前からずっと、最大の課題が「自分がどこに行きたいのかよくわからない」ということで、ごまかしごまかしやってきたものの、いい加減年貢の納め時なのでは、という気がしてきています。
世の中誰もが「自分がどこに行きたいのか」わかってるわけでもないのだとは思うのですが、ずっと引っかかっていることなので、何らかのかたちで折り合いをつけたいと、いう気持ちがあります。

たぶん「解決した！」という状態には一生ならないのだろうなとは薄々思いつつも、一歩でいいから先に進みたい。

*1:読みかけは技術書以外も含めると 100 冊以上ありますが近いうちに読了予定のものだけピックアップ……

2017 年上半期のふりかえり

生活

2017 年の上半期をふりかえります。

まず年間目標を一つ一つレビューしてみて、必要なところでは転換できればと思います。

目標 : 月に 1 冊以上技術書を読む

上半期には、以下の 4 冊の技術書を読みました。

  • みんなのGo言語
  • M2M/IoTシステム入門
  • レガシーソフトウェア改善ガイド
  • [改訂第3版]Jenkins実践入門

目標に対しては、ビハインドゲームですが、去年（年間通して 4 冊）に比べると、進歩ではあります。（ちょうど 2 倍のペース）

一方で、プロジェクトとか、組織的なマネジメント、リーダーシップとか、そういう本を 25 冊ほど読んでいました。
去年は、年間通して 19 冊だったので、2 倍以上のペースです。

びっくり。

技術書を読むのは継続、ただし努力目標として

月 1 冊というのは決して高い目標ではなく、目標を下げたくはありません。

一方で、4 月から組織のチームリーダー、プロジェクトのスクラムマスターという役割になって、興味・関心だけでなく、責任という面でもよりチーム・組織的なところの比重が高まっています。そのことが読書数にも反映されています。

なので、技術書を月 1 冊読むのは「努力目標」にします。
今後も月 1 冊以上を目指します。ただし、現時点で存在している 2 冊のビハインドをぜひとも挽回して年間目標達成死守、みたいなことはしない。

チーム・組織的なところへの取り組みが今まさに急務であり続けていて、そちらに取り組む方が現時点では優先だと考えるためです。

目標 : 月に 5 回以上演技クラスに通う

上半期の 6 ヶ月で、延べ 31 回。

31 / 6 = 5 余り 1 で、悪くないペースです。
多少の波はありますが、おおむねコンスタントに通えています。

これは、続ける。

もっとペースを上げたいとか、家での練習ができていないのではとか、気になることもありますが、まずは通い続けることを大切にしたい。

目標 : 本は月 8 冊、観劇は月 6 回程度（まで）にする

まず本は、6 月までで 52 冊、みたいです。（一部読書メーターに記録できないものがあるので、イマイチ正確ではないのですが）

52 / 6 = 8 余り 4 なので、若干はみ出しています。
とはいえ、「程度」を斟酌するなら、おおむね約束を守れているといえます。

他方、観劇はなんと、わずか 27 本、みたいです。（わずか？）

27 / 6 = 4 余り 3 なので、とにかく、上限をだいぶ下回っています。
目標は 6 回「までにする」なので、数値目標の達成度としては、申し分ないです。

では何をしているか

さて、本を減らした、観劇を減らした、そこまではよくて、問題は、減らしたことで何を失い、何を得たか。

まず本については、小説や詩、エッセイなどを読むことがほとんどなくなりました。
仕事の本は「必要」に迫られているので、減らせるのは、そのへんになってしまうのですね。

これは結構寂しいことで、長く続けることではないな、という感じがします。
とはいえ、耐えられないほどではないので、年末までは続けてみようかな。

観劇については、減らしたことで演技クラスに通えているという面もありますし、それから、減らしたことでやや熱が冷めた感もあります。全部観るのはどっちみち無理だしな、というか……。

あと面白いのは、映画を観るようになりました、映画館でも、ビデオでも。
これは、演技クラスに映画好きの人が多いということの影響も大きい。

上半期で 16 本。
映画を好きになると生活の楽しみの幅が広がりそうなので、映画を観るのは続けてみたいなと思います。

目標 : 毎月計画してふりかえる

これはやってます。

目論見どおりで、おおむね目標達成のペースで 6 ヶ月続けてこられています。
検査と適応。

あえて改善点をあげるなら、仕事上の計画と、プライベートの計画を、うまいこと統合できないかな、と思います。
仕事とプライベートをごちゃまぜにしたいということではないんですが、今は仕事は仕事、プライベートはプライベートでそれぞれ計画とふりかえりをしていて、かといってプライベートの中でも仕事に関わることも結構やっているので、トータルで考えたほうが色々とバランスを取りやすくて、両方とももっと充実するのでは、という気がします。

ぼやぼや考えていきます。

目標 : 丁寧に暮らす

正直言って、生活は荒れ気味です。
やや荒れ。

とはいえ、この目標を置いていることで、なんとか健全といえるレベルの生活を保てているともいえます。
相対的に丁寧な暮らし……。

とりあえず、もうすぐ引っ越すかもしれないので、ものを減らしていこうかな。
そろそろ減らしてもよい頃合い。

で、そうやってどこへ行きたいのか

どこへ行きたいのでしょうか。

自分で言うのも何ですが、実行は結構、だいぶうまくなってきていて、あとは目的がともなえば……。

目的を探そうかなあ。

モダンアジャイルに対するざっくりした理解

ソフトウェア

『パターン指向リファクタリング入門』の著者である Joshua Kerievsky が昨年の Agile 2016 の基調講演で発表した、「モダンアジャイル」というコンセプトがあります。

modernagile.org

InfoQ で紹介されていたり、

www.infoq.com

永和システムマネジメントの平鍋さんがまとめ記事を書かれたりしています。

Modern Agile JPanagileway.wordpress.com

モダンアジャイルに対するざっくりした理解

Agile 2016 の基調講演については、transcript 付き（ありがたい！）で全編のビデオが公開されています。

www.agilealliance.org

これを通して見たので、記憶が新しいうちに、「モダンアジャイル」がどのようなものか、現時点での僕なりの理解をごくざっくりとまとめてみます。

モダンアジャイルの 4 つの指導原則

まず、全体像です。

f:id:enk_enk:20170210190050p:plain

モダンアジャイルは、上の図に示された 4 つの指導原則（guiding principles）によって定義されます。

これで全部です。

とても簡潔で、シンプルです。

あえてプロセスを定めない

モダンアジャイルでは、4 つの原則が掲げられている一方で、具体的なプラクティスは一切定められていません。

公式トップページで Joshua Kerievsky の発言として引用されてもいるように、「framework free」です。

Joshua は、スクラムに代表される従来のアジャイルメソッドを、「補助輪だ」と言います。

そして、彼の娘が自転車に乗れるようになった過程を引き合いに、補助輪を使っていると、なかなかうまくならない、と主張します。
彼の娘は、補助輪を外して、「ペダルを漕がずに、まずバランスを取る」ことから始めて、たったの一日で自転車に乗れるようになった。

さて、いきなりですが、これが何を意味するのか、よく理解できていません。

定められたアジャイルメソッド（たとえばスクラム）が、一種の補助輪だ、というのは同意できます。
アジャイルメソッドを使うことによって、アジャイルになることを始めることができます。

あまりにもうまく始められるので、びっくりしてしまうほどです。
そのことは、先日記事にも書きました。

enk.hatenablog.com

さて、アジャイルメソッドが補助輪だとして、はじめからそれを使わないほうがいい、というのがどういうことかがわかりません。

今はスクラムを使っていますが、いずれ、（そのままの形では）使わなくなっていくのかも、という気はしています。
補助輪から始めて、徐々に本物に近づいていけばいいじゃないか、と思います。

ところが、Joshua は、そもそも補助輪は必要ない、と言います。

補助輪なしで指導できる優秀なコーチがいればいい、ということでしょうか……。（Joshua の娘の場合は、それが Joshua でした）

「ソフトウェア」ではなく「結果」にフォーカスする

アジャイルマニフェストは、その日本語訳が「アジャイルソフトウェア開発宣言」であることからもわかるように、よりよい「ソフトウェア開発」の方法を求めて定められたものでした。

agilemanifesto.org

一方、モダンアジャイルは、「結果」にフォーカスすると言います。

これを、僕は「枠を広げて考えよう」ということだと理解します。

「よいソフトウェアを作ろう」とすれば、よいソフトウェアができるでしょう。
しかし、ソフトウェアは作られることがゴールではありません。

ソフトウェアは使われるために作られるのであり、もともとそのソフトウェアで実現したいことがあったはずです。
そして、それはもしかしたら、そもそもソフトウェアで実現する必要のないことかもしれません。

それに、よいソフトウェアができても、ユーザが使うに至らなければ意味がありません。
存在に気づいてもらえなければ。買ってもらえなければ。使ってもらえなければ。せっかく入れた機能に気づいてもらえなければ。必要なときに間に合わなければ。

最高の開発者と最高の開発プロセスで、完璧に構築されたそのソフトウェアの価値はゼロです。

アジャイルとは「作らない」ことだ、とも言われるように、この考え方自体はもともとアジャイルマニフェストにも根付いているものですが、それをより推し進めたのがモダンアジャイルだと言えると思います。

「ユーザを喜ばせる」だけでは足りない

さて、4 つある原則のうちの 1 つめは、「人々を最高に輝かせる（Make People Awesome）」です。

これは、先ほど書いた「ソフトウェアではなく、結果（ユーザの満足）にフォーカスする」ということももちろんですが、それだけではありません。

モダンアジャイルでは、ユーザはもちろんのこと、開発者をはじめとした同僚（営業、マーケティング、……）、見込み顧客、購入の決裁者（えらい人）、などなど、ソフトウェアを取り巻くエコシステムのすべての「人々」を対象として考えます。

Done の定義でも、ベロシティでもなく、それどころか「顧客満足度」でさえなく、「人々を輝かせる」ことにフォーカスすることが本物の成功を導く、という考え方です。

論理的に説明するのはなかなか難しいものの、この考え方には個人的にとても共感できます。

「必須条件」としての安全

2 つめの原則は、「安全を必須条件にする（Make Safety a Prerequisite）」。

「心理的安全」については、昨年あたりからソフトウェア業界で頻繁に耳にするようになりました。

なので、「ここでも、出てくるか」という感覚です。
もしかしたら、この Agile 2016 の基調講演自体も流行のきっかけの一つだったのかもしれません。

心理的安全はさまざまなところで話題になっており、『チームが機能するとはどういうことか』をはじめとして書籍でも大きく取り上げられるような考え方なので、目新しいことはありません。

個人的にも、こうして数少ない 4 つの原則のうちの 1 つとして取り上げられることに、一定の納得感があります。

「必須条件」という言い方はさすがに伊達ではなくて、講演では、従業員の心理的安全、および顧客の心理的安全について、さまざまな角度からその重要性を強調しています。

Slack が、有料契約をしているのに未使用になっているユーザを見つけたら自動的に返金してくれる、という例には感心しました。
顧客の心理的安全。そうあるべきだ、そうありたい、と感じます。

これでもかというくらい失敗する

3 つめの原則は、「高速に実験＆学習する（Experiment & Learn Rapidly）」。

これは、少し想像すればすぐにわかるように、「安全」と密接な関係があります。
「安全」が「必須条件」として確保されていれば、実験し、失敗し、学習することができます。

Joshua は、失敗しよう、と言っています。本気で。

たとえば、IMVU の例。

3D のシミュレーションゲーム（the Sims みたいなもの）をリリースするにあたって、「移動する」機能をつけずに出してしまう。

するとユーザから「移動したい」という要望が出る。

ならば、ということで、「クリックするとその場所にアバターが（瞬間）移動する」という機能をリリースする。2 日で。
the Sims みたいに「ちゃんと」移動する機能じゃなくて、アバターの位置がひょいと変わるだけの機能なら、2 日でリリースできるわけです。

そしてその「瞬間移動」が大人気になった、というストーリーです。

たまたまじゃないか、という気もしますが、「高速にリリースする」ことがいかに価値を生み出しうるか、ということを、僕はこの例で強烈に感じました。

あるいは、Amazon.com の CEO である Jeff Bezos の例。

Fire Phone は大失敗に終わったわけですが、そのことについてインタビューされた Jeff は、「すぐにもっとずっと大きな失敗をするよ」「失敗が起こることなんてわかっている。むしろ、Amazon が失敗できる場所であることが誇りだ」と（たぶん笑顔で）答えます。

これが強がりではないことは、Amazon の大躍進を見ていればわかります。

モダンアジャイルでは、短期的な成否にとらわれず、長期的に考えて、「積極的に失敗する」ことの価値を強調しています。

届いた価値だけが価値だ

最後の原則は、「継続的に価値を届ける（Deliver Value Continuously）」。

これもフレーズだけ聞けば「そらそうよね」と感じますが、たった 4 つの原則のうちの 1 つであるからには、これこそが極めて重要、ということになります。

たとえば、より多くの機能を開発することよりも。
あるいは、開発計画を予測可能にすることよりも重要かもしれません。

機能の多さや、中長期の見通しを犠牲にしてでも、継続的に価値を届けよ、と言っているのだと理解しています。

なぜかといえば、届けない限りは、それが価値かどうかもわからないからです。

最先端の技術と残業も辞さない努力で、丁寧に開発され、入念にテストされ、（幸運にも）出荷され、さっぱり使われない機能のいかに多いことか。

おわりに

「モダンアジャイル」について、Agile 2016 の基調講演のビデオを見た現時点での僕なりの理解を書いてみました。

あくまでも、これは一個人のざっくりした理解です。
「これがモダンアジャイルだ」というつもりはないので、ご了承ください。

「そうではなく、こういうことでは？」というツッコミは大歓迎です。
何かあれば、コメントでも、ブコメでも、ツイッターでも、ぜひ、お寄せください。

いずれにせよ、このモダンアジャイルというコンセプトをきっかけに、これからのソフトウェア開発（および、価値を生み出す集団の活動すべて！）をよりよくする方法について、議論が深まっていくといいなと思っています。

スクラムで半年開発やってみた感想

ソフトウェア

開発者として、スクラムチームでの開発を去年の 8 月半ばから始めたのですが、この 1 月いっぱいでいったんチームから抜けるので、ざっくりざっくり感想をまとめてみます。

前提として、スクラムには 3 つの役割*1があり、それぞれの役割から見たとき、それぞれの感想があるものと思います。
この感想は、ある一人の開発者から見たものです。

本当によくできたフレームワーク

スクラムは、本当によくできたフレームワークです。

スクラムがそのはじまりからそうだったのか、どうかは知りませんが、少なくとも、2016 年 8 月に認定スクラムマスター研修で教わったスクラムは、

  • 人間という生き物の心理的特性をよく理解し、活用している
  • 薄すぎず、厚すぎず、絶妙なバランスのところでフル活用できるフレームワーク

でした。

スクラムを知ってから、興味を持った関連分野の書籍（主に心理学の研究に根ざしたもの）を読めば読むほど、スクラムがその特性を活かしながら人間の集まりの活動をサポートするように設計されていることを思い知ります。

たとえば、こういった本です。

チームが機能するとはどういうことか ― 「学習力」と「実行力」を高める実践アプローチ

チームが機能するとはどういうことか ― 「学習力」と「実行力」を高める実践アプローチ

スイッチ! ──「変われない」を変える方法 (ハヤカワ・ノンフィクション文庫)

スイッチ! ──「変われない」を変える方法 (ハヤカワ・ノンフィクション文庫)

半年で遠くまで来た

また、この（たったの）半年で進んだ距離を思うと、めまいがします。

  • 本物の「チーム」ができた
  • チームメンバーのさまざまな知見を学んだ
  • チームメンバーにたくさんの知見を共有した
  • 安全を感じながら、敬意を持って意見を交換し合う文化ができた
  • 精神的に健やかになった
  • 残業が減った
  • （おそらく）前回のプロジェクトよりも速いスピードで、前回のプロジェクトよりも価値の高いものを、前回のプロジェクトよりも高い品質で開発した

等々。

自覚していなかったり、覚えていなかったりするだけで、実際には、もっともっとたくさんのことを学習し、達成したのだと思います。

組み合って進むということ

スクラムは、まさにその名前にも表れているように、チーム全員で組み合って一緒に進むシステムです。

スクラムを、崩さずに、まじめに取り組むと、「チーム内で突出したプレイヤー」は足かせをはめられたように感じることがあると思います。

僕は自分が「突出したプレイヤー」だと言うつもりは微塵もありません。ただ事実として、チームメンバーの中では会社および製品との付き合いが長い方に属しています。そのこともあり、個人の開発生産性という点では、（おそらく）高い方に位置していたと思います。

正直にフラットに言うと、一人でやったほうが（局所的な）生産性／アウトプットの量は大きい、と感じる瞬間は何度もありました。特に最初の頃は。

それでも、スクラムというシステムは、組み合って一緒に進むことをゴリゴリ推してきます。
オーケー、そう言うならそうしよう。

そして結果としては、「チームとしての」生産性が高まった、のだと思います。
さらにその結果として、かつて「一人でやったほうが（局所的には）速い」と感じて、多少のフラストレーションも感じていた僕は、今や満足しています。

スクラムが問うこと

ここに二つの問いが存在しています。

  • 本当に（文字通り）「突出した」プレイヤーは、スクラムのシステムのなかでうまくやっていけるのか
  • 平均より上のプレイヤーが、いよいよスクラムに慣れたとして、「チームの生産性」で満足できるのか

前者については、正直なところ、わかりません。
少なくとも自分はそうではないし、チームの中にもそういう人はいないので。

これについて考えるのは、別の機会に譲ります。

後者については、難しい問題です。
僕は以前から「チームの生産性」に強い関心があって、それが達成された（されようとしており、また、これからさらにそうなっていくであろう）ことに、深い満足を覚えます。*2

しかし、そうでない人はどうか。
僕の考えでは、「チームの生産性」に（深いところで）興味がない人は、原則として「いない」と思います。しかし、（少なくとも、表面的なところでは）「チームの生産性もいいが、個人の生産性の方が大事だ」という人なら、いると思います。

ここで大事なこととして、人の考え方や表明する意見というのは決して「生まれつき」の「絶対的」なものではなく、環境によって変化する、ということがあります。
スクラムによる開発では、メンバーが「チームの生産性」にフォーカスするように組織の文化を育て、評価・報酬を含む周辺制度も設計していくことが重要になるのかもしれません。

スクラムの先はあるのか

さて、たかが半年、されど半年、スクラムで開発をやってきました。

当然、我々のスクラムの活用はまだまだ道半ばなわけですが、ここで少しだけ、「スクラムの外」あるいは「スクラムの先」のことを考えてみます。

「マネジメント」のフレームワーク？

白状すると、8 月に誘われて研修を受けるまで、僕はずっと（5 年くらい）スクラムは「マネジメント」のフレームワークだと思い、なんとなく避けていました。
また、ガチガチのシステムであり、融通が利かない、よって、開発者にとってはつまらない、とも。

結果としては、間違っていました。

スクラムは、「チームの」フレームワークです。
そして、たしかに厳格なルールはあるものの、フレームワークとしてはとても薄く、人をサポートするもので、これを守りながらも、十分な主体性が発揮できます。「楽しい」システムだと言ってしまってもいいと思います。*3

スクラムの外には

スクラムのほかにも、世の中にはさまざまな開発スタイルがあります。

最近活発なのは、リーンスタートアップの基礎ともなっているリーンの考え方、具体的な手法の代表としては、カンバンでしょうか。

余談ですが、2014 年に出た『エッセンシャルスクラム』では、スクラムフレームワークそのものの説明だけではなく、かなりリーン／カンバン的な考え方・手法も紹介されていて、なるほど、と思った記憶があります。

カンバンがスクラムと異なるところは色々ありますが、その大きな部分の一つは、「スプリント（イテレーション）のベロシティ」ではなく「リードタイム」（あるいは、バリューストリーム）に注目する、というところでしょうか。*4
本旨から逸れるので詳細な比較はしませんが、「どちらを採用するのがよいか」という議論がとりあえず可能な程度には、異なっている手法だと思います。

カンバンが注目されるようになったのは、スクラムより後です。
してみると、カンバンがスクラムより優れていたとしても、不思議ではありません。

スクラムの先へ

このとき、自然と「スクラムの先」を考えることになります。

スクラムは本当によくできたフレームワークで、一方、課題もあります。

「スクラムをやっていなかったら、ここにいなかった」と断言できるくらい、スクラムに助けられてここまで来ました。

一方で、このまま「スクラム」を続けた先に何があるのか、いいことか、よくないことか、不透明な部分もあります。

他の選択肢もあります。

『エッセンシャルスクラム』が示したように、スクラムに「スクラムそのもの」には含まれない要素や考え方を組み込むこともできるでしょう。

スクラムは「ルール通り」にやるのがおすすめ

ところで、これまでの話の流れに反するようですが、もし新しくスクラムに取り組むチームがいるとしたら、僕はまずは「ルール通り」にやることを強くおすすめします。

「カスタマイズしたスクラム」ではなく、「スクラムフレームワークで定められたルールを厳格に適用したスクラム」です。

なぜなら、スクラムのよくできた設計、その効果が最大限に発揮されるのが、「ルール通りにやったとき」だと思うからです。

Daily Scrum を毎日同じ時間・同じ場所で欠かさず 15 分以内でやり、
Product Backlog Refinement をスプリントの 10% 以内の時間を使ってやり、
Sprint Planning では PBI を「ロック」し（Sprint 中の PBI 追加はしない）、
スプリント中は Sprint Backlog の上から順に着手・完了させていき（Sprint Backlog に載っていない作業はしない）、
毎スプリントの終わりには Sprint Review と Sprint Retrospective をやって、製品とチームの状態にすばやく適応します。

これをやった感想は、これまでに書いた通りです。

もし、ルールを「都合よく崩して」運用したとすると、スクラムのメリットを引き出せないまま「うまくいかないからやめる」となってしまう危険性がかなり高いのでは、という感覚が、半年やってみての実感としてあります。
なお、研修講師の江端さんという方は、「まずはルール通り 3 ヶ月やってみてから判断すべし」と言っていました。*5

ただ、これは一種の理想論で（我々は実際にやっているわけですが）、「ルール通りにやろうとしたらクビになる」とか「法律が許さない」といった場合もあるかもしれません。

本当に？

以下のナイスなプレゼンテーションにも示されたように、やり方は色々あります。
「ルール通り」にやるのがおすすめですが、「ルール通りにやろうとする」とき、「ルール通りにやろうと言う」だけが方法ではありません。

ルールを「より厳しく」捉える必要もありません。

スクラムは薄いフレームワークで、ルールの遵守は求めますが、定められていない部分には柔軟に適応してかまいません。

もちろん、より厳しくすることでうまくいきそうだと思えれば、そうしてもかまいません。
僕が所属するチームは、どちらかというとこちらのやり方でうまくいってきたように思います。少なくとも、これまでは。

そして、スクラムの先へ

ルール通りにやった結果、スクラムのいいところがビシバシわかります。

そして同時に、スクラムのイマイチに思えるところも見えてきます。

それは、チームのイマイチなところかもしれません。
その可能性の方が高いと思います。

チームのイマイチなところは、継続的に改善していきます。
するとまたイマイチなところが出てきて……以下繰り返し。

繰り返していくと、いよいよ「ルール通りの」スクラムのイマイチなところが浮かび上がってくるのかもしれません。
その時が、「スクラムの先」を考えるタイミングなのだろうと想像しています。

まとめ

ざっくりざっくりと言いながら、やや語りすぎてしまったようです。

改めてざっくりまとめると、以下の 3 点に集約されるかなと思います。

  • スクラムは本当によくできたフレームワーク
  • 「チームとして組み合って」進むのは楽しいことも多いが、課題も投げかける
  • スクラムははじめはルール通りにやるのがおすすめ、とはいえ、その先もあるのかもしれない

補足 : ここに書かれていないこと

この記事では、あえて触れなかったことや、語り落としたこともそれなりにあります。
気づいていないこともあると思います。

取り上げなかったけれども、とても重要だと考えているトピックの一例を上げておきます。

  • チーム内でのスキルセットの違いについて（特に、テストエンジニアについて）
  • チーム内で平均よりも経験が少ない開発者がどう感じているか
  • 開発者以外の役割（プロダクトオーナー、スクラムマスター）の人がどう感じているか
  • スクラムチーム外との関係について

これらのことについては、また折をみて考えていけたらと思っています。

*1:プロダクトオーナー、スクラムマスター、開発者

*2:一方で、にもかかわらず、当初は「個人の生産性が最大限発揮されないことへの不満」も持っていた、という興味深い事実もあります

*3:これはややセールストーク的で、実際には、楽しいかどうかは、どう取り組むかによる、というのがフェアな言い方だと思います

*4:なお、前出の『エッセンシャルスクラム』でも関連する概念である「WIP」や「作業の手待ち」は紹介されており、相反する考え方というわけではありません

*5:ただここに一つだけ物言いがついて、僕が所属するチームでは Sprint Planning の時間はスクラムガイドに示されたタイムボックスをはみ出しています。詳細が気になる方は わたしたちがスクラムのスプリント期間を 1 週間にし、タスクを 1 時間以下の単位に分割するのはなぜか - Appresso Engineer Blog を見ていただけると幸いです

一年分の余暇をたっぷりつぎ込めば「できます」と言えるレベルになる

生活

※独自研究（チラシの裏）です

なにこれ

僕のこれまでの経験から帰納的に考えると、「一年分の余暇」を「ある活動」に「たっぷり」つぎ込めば、その活動を「できます」というレベルになれる、と言えそうです。

帰省から帰る新幹線の中であまりにも暇だったのでちょいちょいと計算してみた結果、僕がこれまでの短くない人生で達成してきたいくつかのことのそれぞれが「たった一年」でいけるらしい、ということがわかって意外だったので、まとめてみます。

長くなったので先にまとめ

すべて僕の個人的なことなので、人によって違いはあると思います。

※あくまで独自研究です

一年分の余暇をたっぷりつぎ込む

まず、掲題の「一年分の余暇をたっぷりつぎ込む」とはどういうことか、簡単に説明します。

一年分の余暇

平日は平均して 21 時から 24 時の 3 時間、休日は 10 時から 22 時（うち、お昼休みに 1 時間）の 11 時間を余暇として考えます。

一年のうち、平日は 3 分の 2 くらい（240 日）、休日が 3 分の 1 くらい（120 日）でしょう。

すると、一年分の余暇は、

3 時間 × 240 日 + 11 時間 × 120 日 = 720 + 1320 = 2000 時間強

となります。

これが一年間に利用可能な余暇のすべて、つまり「一年分の余暇」です。

たっぷりつぎ込む

実際には、すべての時間を一つの活動に集中して取り組むことは不可能だと思います。

一応、家事などにかかる時間は除いたつもりの数字ですが、外せない用事や体調不良などで、やむをえず多くの時間を消費してしまうこともあるでしょう。

とはいえ、強い意思と習慣の力をフル活用してがんばれば、半分 ～ 七、八割くらいまでならいけそうな感じがします。
これが「たっぷり」です。

「一年分の余暇」を「たっぷり」つぎ込むことで、およそ 1000 時間（かなりがんばった場合） ～ 1500 時間（めちゃくちゃがんばった場合）が確保できることになります。

1000～1500 時間で何ができるか

さて、ここからは、この 1000～1500 時間で何が達成できるか、ということが問題になります。

そこそこの年月を生きてきたので、僕の個人的な経験においてどういうことができてきたのかふりかえれば、ある程度推測できそうです。

弓道

高校の3年間、弓道部にいました。

弓を持つのも初めてで、当然、最初の頃は矢が的に当たりません。
というより、まず弓が引けません。（引かせてももらえません）

うろ覚えですが、初めて的前に立つまでに数ヶ月かかったはずです。（そして、当然、中りませんでした）

3 年生の 8 月に引退するまで、平日 2 時間、休日 3 時間くらいのペースで、ずっと練習しました。 そして、二段を取ったのが（たしか……）2 年生の 12 月。

二段というのは、高校生としては上出来です。*1
「弓道できます」と言っても、まあいいかなといえる実力です。

それまでの練習期間が、1 年生の 4 月～ 2 年生の 11 月として、20 ヶ月。
例によって平日 2/3、休日 1/3 として、

2 時間 × 20 日 × 20 ヶ月 + 3 時間 × 10 日 × 20 ヶ月 = 800 + 600 = 1400 時間。

一年分の、上限に近い数値になりました。

作曲

僕は、中学の終わり頃からゲームコンポーザになりたくて*2、ちょいちょい DTM で作曲をしていました。

最近は所属する劇団でちょっぴり音響活動を始めたり始めなかったりしていたりもするのですが、まともに曲作った最後は 2011 年の春。
今はリハビリ中です。

わかりやすく、大学に入った 2006 年から、卒業した 2011 年という期間で考えてみます。*3

2006 年春の曲がこちら。

http://download.sound.jp/enick_ymw/s/sus4.mp3

一応、弓道業のかたわら細々とアマチュアの作曲業を営んではいたので、最低限整ってはいますね。

そんで、2011 年春の曲がこちら。

note.mu

もともと、こういう曲が作りたかったんです。
音楽の評価は人それぞれだと思いますが、複雑度とか迫力が増している感じは伝わるかな～と思います。

これができて、ようやく僕は「作曲できます」と言えるようになった気がします。*4

というわけで、問題は作曲業に何時間投入したのか？　です。
これは算出が難しいのですが……。

いくつかの角度から推測した結果、まあ 1000 ～ 1800 時間くらいかな、という結論になります。
いや～これが少ないんですね。仕事にしたいなら、もっとやれよっていう。

あくまで概算ですが、大きく外してはいないと思います。
以下、一応計算式。

仮に毎日コンスタントに 1 時間作曲業にはげんでいたとして、延々 5 年間。*5
365 * 5 = 約 1800 時間。

あるいは、大学生活の間に発表*6した曲がだいたい 30 曲くらいあるのですが、一曲仕上げるのに 平均 30 時間かかっていたものとして*7、さらにボツ曲が同じくらいあると考えて、こちらは平均 5 時間くらいとして。
30 * 30 + 30 * 5 = 1000 時間強。

こんな感じで、500 時間とか、3000 時間とかいうことはまあなさそうだな、という感覚が得られます。*8
上の方の 1800 という数字だと、「たっぷり」の上限である 1500 時間をやや超えていますが、所詮は概算なのでお目こぼしください。

プログラミング

ざくざくいきましょう。

大学を卒業し、夢破れて*9、俗に言う PG/SE の職につきます。

未経験に等しかった一社目入社時からの 1000～1500 時間が取れればベストなのですが、達成したことのデータが乏しい（僕の記憶しかない）ので、（定性データながら）ブログからデータを取りやすい、今の会社での時間で見てみます。

対象は、Java でいきましょう。

学び始めた日は、はっきりと記録されています。

enk.hatenablog.com

これが、入社のおよそ約 3 ヶ月前。
"「リフレクション」というJavaの機能" などというかわいい記述が見られます。

入社前は結局あまり時間が取れず、読み始めた『プログラミング言語 Java』を読み終えたのは入社から 2 ヶ月近くが経った 12 月でした。
これに費やした時間が、ざっくり　10 分 × 650 ページで 6500 分 = 100 時間強くらいでしょうか。

12 月からは、本格的に Java を使った業務に入ります。
業務知識を学ぶ時間や会議等の時間、インフラ周りを触ったり C++ を触ったりといった時間もありましたが、基本的に開発言語は Java なので、（個人的な勉強の時間も含めて）一日 4 時間くらいは Java 業をしていた、と考えてよさそうです。

土日もまあ、どちらかで 4 時間くらいは何なりと勉強してた気がします。
とすると、一週間で 4 * 6 日 = 24 時間、一ヶ月で 24 * 4 週 = 96 時間。

こちらも丸めて 100 時間とすると、1000 時間時点は 9 ヶ月後となり、2014 年 9 月です。
そして、奇しくもこの月に #渋谷java で LT をしています。

enk.hatenablog.com

実は、このときのスレッドダンプの記事がいまだにこのブログのアクセス数の半分近くを稼いでいたりします。

enk.hatenablog.com

「Java できます」というとこの界隈では色々と問題発言になりかねませんが、まあそういう文化の問題を置いておけば、とりあえずは「できます」といってもいいレベルになったのがこの頃かな、と思います。

演劇

最後に、去年……じゃないもう一昨年なのですが、2015 年の 4 月に始めた演劇の話。

こちらは、まだ達成らしい達成はありません。
アマチュアの俳優をやっているのですが、まあ何というか、まだまだです。

とはいえ、2 回（ちょっとした発表機会的なものも入れると 3 回）舞台に立ちました。

劇団の力もあり、来場していただいた方々にはそれぞれに楽しんでいただけたようです。
2 年続けて来てくれた友人も何人かいて、本当にありがたい。

今年の公演です。

www.youtube.com ▲はじめから

www.youtube.com ▲登場シーン、いきなり長台詞っていう

さて、ここまでに投入した時間はというと、ざっくり延べ 500 時間くらいだと思います。

劇団の稽古が基本は週 1 で、一日あたり実質 2 時間程度。
9 月から 11 月は週 2 のペースで、昼から夜やるので一日あたり実質 7 時間程度。

2015 年 4 月から 2016 年 11 月までなので、これだけで、2 * 4 週 * 14 ヶ月 + 7 * 2 日 * 4 週 * 6 ヶ月 = 112 + 336 = 約 450 時間。

これに加えて、自主練をしたり、ワークショップに参加したり、してはいましたが、はっきり言って、全然大した量じゃないです。
ので、仮に 50 時間と見積もって、計 500 時間くらいになります。

本当に本当にまだまだなのですが、とはいえ、500 時間やってこれか、とは思いません。

500 時間やれば、これです。
そしてあと 500 時間やれば、きっと、「演劇できます」……と言えるかどうかはちょっと自信ありませんが、「演劇やってます」と胸を張って言えるだろうと思います。

まとめと補足

新幹線で暇だったから始めてみた考察でしたが、思ったよりもそれらしくまとまって、ちょっとびっくりしています。

各項目のピックアップとしてのまとめは記事の最初に置いたので、そちらで。
結論は、

  • 「一年分の余暇」を「たっぷり」つぎ込んだ（→ 1000 ～ 1500 時間程度を投入した）結果、「できます」と言えるレベルになった経験がいくつもある
    • だから、そういうものなのだと思う
    • 「できます」と言うのがちょっとあれだとしても、少なくとも「やってます」なら胸張って言える

です。

この話の中で一番難しいのは、実際のところ、一年の余暇のうち 1000 ～ 1500 時間もを一つの活動に投入することだと思います。
逆にいえば、本当に 1000 ～ 1500 時間投入できれば、これくらいのことができるようになるだろう、という予測は割と妥当なのでは、と思います。

そして、もちろん、プログラミングの例に見られるように、仕事にしてしまえば 1000 時間なんて一瞬ですね。
いや一瞬ではないですが、まあ普通にやって 1 年はかかりません。

最後に、いくつかこまごまとした補足をしておきます。

1000 ～ 1500 時間の間に何度も「！！」を経験する

この話の中には一つインチキがあると思っていて、というのも、実際に「その活動」をやっている時間以外にも、実は頭は働いています。
ある活動に没頭している時期というのは、だいたいそのことだけを考えています。

音楽をやっていた頃は、曲のことばかり考えていました。
そして、歩いていても、自転車に乗っていても、バイトをしていても、シャワーを浴びていても、あらゆるときに曲想を思いつくことがありました。（だから、常にボイスレコーダーを携帯していました）

現在の本業はソフトウェアエンジニアですが、やはり生活の時間の多くを費やす活動なので、そのことを考えている時間も長くなります。
最近は主に人の問題に興味が向いているので、人のことについて「！！　そういうことか！！」となることが、日常生活のなかで頻繁に起こります。

演劇についても、去年はなかったのですが、今年は公演の稽古をしている期間中、日常生活の中で何度も「！！　あれはそういうことか！！」と気づくことがありました。
もちろん、脚本を読んでいるときや、動きを試してみているときにもそれは起こります。何度も何度も起きて、その都度「これだ！！　掴んだ！」と思ったのですが、終わってみると、全然掴みきれていませんでした。

これらの「！！」は、何度も何度も繰り返し起こります。
逆に言うと、何度も何度も起こって、それでようやくいくらか進んでいた、ということになります。

一度や二度の「！！」は、そのときに感じるほどには大きな一歩ではない、というのが長年の実感で、だから、「！！」が何度も起きるくらい長いこと没頭し続ける必要があるのだと思います。
1000 ～ 1500 時間を 1 年間に凝縮したときに果たしてこれができるか、というのが未知数です。濃度が上がる分、さらに「！！」が起きやすくなる、という可能性も考えられるとは思います。

「意図的な練習」かどうかで時間の質は大きく変わる（と思われる）

時間のことに絞って話をしてきましたが、もちろん質は重要です。

近年 "deliberate practice"（意図的な練習）という概念が注目されているようです。

https://www.google.co.jp/#q=deliberate+practice

あえて深入りせずに極めてざっくり言うと、質の高い練習、ということです。
それを心理学の手法で調査・分析して定義したものです。

僕は『究極の鍛錬』という本でこの用語を知り、以前ブログにも感想を書きました。

enk.hatenablog.com

費やす時間がこの「意図的な練習」になっているかどうかで、成果は大きく違ってくるものと思います。
逆に言うと、僕が今までにうまくやれた分野というのは、（図らずも）この「意図的な練習」にあてはまるような部分があったのかも、とも思います。（未検証ですが）

生存バイアス / 確証バイアスがあるかも

この記事が科学的な記事だと思っている人は誰もいないとは思いますが、念のため。

あくまで独自研究（チラシの裏）です。

生存バイアスがかかっていると思います。

たとえば、僕は小学生の頃剣道を、中学生の頃バスケットボールをやっていましたが、目立った成果は上げられなかったこともあり、取り上げていません。（かけた時間をよく覚えていないというのもありますが……）

確証バイアスもあると思います。

記事を書くなかで、自分が書いたこと（たとえば、「一年の余暇は最大 2000 時間、実質使えるのは 1000 ～ 1500 時間」）に釣られて、無意識のうちに実績の時間を調整しているかもしれません。「一日あたりの時間」とか、記憶に頼っていますし、かなりざっくりなので、どうとでもできると言えば、できます。もちろん、そうしないように気をつけたつもりではありますが……。
剣道やバスケットボールを取り上げなかったこともそうです。*10

この辺の話は、今読んでいる『ファスト&スロー』に詳しく出ています。

ファスト&スロー(上) あなたの意思はどのように決まるか? (ハヤカワ・ノンフィクション文庫)

ファスト&スロー(上) あなたの意思はどのように決まるか? (ハヤカワ・ノンフィクション文庫)

ファスト&スロー(下) あなたの意思はどのように決まるか? (ハヤカワ・ノンフィクション文庫)

ファスト&スロー(下) あなたの意思はどのように決まるか? (ハヤカワ・ノンフィクション文庫)

文章はやや固い（しかも上下巻！　しんどい！）ですが、その分（？）第一人者による一次情報なので、読む価値はあると思います。

おあとがよろしいようで

こういうブログを書いている間にも、刻一刻と余暇の時間は失われていきます。

*1:ひとつ上の三段を高校生で取るのはかなり難しく、県内の同学年にはたぶん一人もいなかったと思います。二段はちょいちょいいます

*2:といっても、「なんとしても絶対になるぞ！」というほどはっきりした意志でもなく、ぼんやりしていたら、結局なれなかったのですが

*3:差し引き 5 年になるのは秘密。

*4:と、作曲を始めてからの通算だと 2000 時間以上いってしまいかねない気がしますが、とりあえず置いといて……

*5:実際にはそんなにまじめじゃなかったと思います。ただ、平均するとそれくらいかも、という気もします

*6:録音して CD にしたもの、およびバンド等の形態で演奏したもの

*7:ミキシングまでやるともっとかかることもありますし、バンド用のラフならもっと短いのですが、まあざっくり平均

*8:ほんと、3000 時間くらいは使えよ、と言いたい

*9:雇ってくれた最初の会社に感謝していますし、結果としてこの仕事でよかったと割と本気で思っています。念のため

*10:こちらは、気づいてここで取り上げましたが、最初は忘れていました