この国では犬が

本と芝居とソフトウェア

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

パターン指向リファクタリング入門』の著者である 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:こちらは、気づいてここで取り上げましたが、最初は忘れていました

2017 年の目標

2017 年の目標を立てます。

去年は抽象的な目標を立てましたが、今年は一転して具体的な目標を立ててみます。

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

昨年は、チームや組織についての本をたくさん読んで(19 冊)、そういった面で、所属しているソフトウェア開発チームにも貢献することができたと思います。

しかし、一方で、(スクラムやリーンなどのアジャイルプロセス関連を除く)純粋な技術書は 4 冊しか読みませんでした。

直近での一番の伸びしろはチームや組織にある、という意識にはいまだ変わりありませんが、この業界、技術力は磨かないとどんどん錆びていきます。

プログラマとして、また仮にプログラマ以外の役割を果たすとしても、開発組織の一員として、技術力を錆びつかせるわけにはいきません。
そもそも、もう 6 年近くもプログラマをやっていながら、基礎だってまだまだな部分もあります。

だから、技術書を読みます。

わかりやすい指標として、月に 1 冊以上。
最低 1 冊、興味や余裕があれば(もちろん)2 冊以上でも可、です。

色々と積読・読みかけの本があります。
軽くリストアップしておきます。(順不同)

持ってる本だけであっさり 12 冊挙がってしまったのが気になりポイントではありますが……これらの本が読めるのが、楽しみです。

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

12 月から、演技クラスに通い始めました。

月 4 回が基本ながら、特に回数制限はなく何度通っても自由なクラスです。
日、月、火、水の週 4 日で開講されています。(日曜のみ昼夜、それ以外は夜)

せっかくたくさん通える環境なので、たくさん通いたい。
とはいえ、本業もあるので、無理はできません。

だから、ほんの少しだけ背伸びして、月 5 回以上を目標とします。

毎週必ず 1 回、余裕のあるときに追加で 1 回、というペース。
もちろん、それ以上通ってもよし。

がんばります。

本は月 8 冊、観劇は月 6 回程度(まで)にする

やることを増やしたら、何かを減らさないわけにはいきません。
いつでも一日は 24 時間だからです。

色々と工夫のしようはあると思いますが、確実に効果のあるであろうところに手を入れておきます。

本は月 8 冊、観劇は月 6 回程度までにします。

数値は、いずれも前年の 80% を目安にしています。(120 冊 * 0.8 / 12 ヶ月 = 8 冊、91 本 * 0.8 / 12 ヶ月 ≒ 6 本)

「程度まで」という曖昧な言い方は、月ごとの上限は設けず、多少の増減があっても、1 年間で帳尻が合えばよい、というつもりでしています。

本がたくさん読める(読みたい)とき、芝居がたくさん観たい(観るべきものが多い)とき、というのもあるだろうからです。
とはいえ、あんまり偏るとたぶん破綻するので、±1~2 程度を想定しています。

厳選していかにゃならんぞ。

毎月計画してふりかえる

さて、これらの数値目標を立てたはいいのですが、なんとなく生活していると、本当に達成できるか不安です。

だから、毎月計画を立てて、また、ふりかえります。

昨年の後半で、計画の力を信じるようになりました。
本で読んだことも色々ありますがが、スクラムによる開発を経験したことも大きいです。

人は、計画していないことをやるのが苦手。
いざやる段になって何をやるべきか迷っていたら、意志の力を無駄遣いしてしまいます。

根拠を持った計画を立てて、安心してその通りにやる。
結果をふりかえって、改善する。

これをこまめに繰り返す。

こうして書くと基本中の基本ですが、改めて、きっちりやってみようと思います。

ふりかえりと計画は、毎月「最初の休日まで」にやるのがいいでしょうね。
平日に余裕が作れればやってもよし、できなければ、休日の時間を使ってやる。

こういう風に、予めルールを決めておいて、やるときには考えなくてすむようにするのがコツです。(と、スクラムから学びました)

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

色々とやたら具体的な目標を立ててきましたが、一年の目標としてはやや細かすぎるようにも感じます。

本来は、大きな目標(戦略レベル)をまず決めて、具体的なやり方(戦術レベル)は都度考えるのが筋でしょう。

ところが、ここ数年、戦略が決まらない!

我がことながら、困っています。
いや我がことなのだから、何とかしなさいよ、という話なのですが。

だから、ひとまず戦術レベルの目標を立てました。

ソフトウェア業をうまくやりたい、というのと、俳優業をうまくやりたい、というのが、少なくとも当面の方向性には違いないので、それに資するような目標を。

また、読書と観劇の数を(あえて)減らす、と決めることで、遊びを持たせようとしています。
戦略を立てるための活動に、また戦略が立ったときにその実行のために、時間を使えるように。

丁寧に暮らす

最後に、目標をもう一つだけ。

丁寧に暮らす。
って、何でしょうね。

この目標だけ、あんまり深く考えていません。
具体的な行動にも落とせていません。

ただ、昨年はちょっとギリギリのメンテナンス度でざっくり暮らしすぎた感があって、そこへの反省とでもいうのか。
丁寧に暮らしてみたらどうなるのだろう、という一種の興味というか。

具体的な方法は、これから考えます。
なんとなく、部屋がすっきり片付いていて、運動、瞑想、野菜 350 グラム、心身ともに健やかな、規則正しい生活を送っている、みたいなイメージを持っています。

まとめ

というわけで、今年は以下の 5 本立てでやっていきます。

  • 月に 1 冊以上技術書を読む
  • 月に 5 回以上演技クラスに通う
  • 本は月 8 冊、観劇は月 6 回程度(まで)にする
  • 毎月計画してふりかえる
  • 丁寧に暮らす

5 つも目標があるというのは多いようですが、一つ一つが小さく、少しずつ関連し合ってもいるので、ちゃんとやればまあ、いけるでしょう。

そういった生活の中で、少しずつでいいので、大きな絵、5 年後、10 年後の目標といったものも描いていけたら、と思っています。

2016 年のふりかえり

2016 年のふりかえりをします。

目標について

まずは、年初に立てた目標について。

enk.hatenablog.com

以下の 2 つの目標を立てました。

  • 全力で走る
  • 手入れして暮らす

かなり大づかみな目標でしたが、結果やいかに。

全力で走る

1 つめの目標は、要するに、こういうことでした。

しばいとソフトウェアのことを、充実してきた心身にまかせて、ビシバシやりたいと思っています。やりたいことがひとつの 2 倍でふたつあるから、余計にリソースを突っ込まなくては、という思いもあります。

芝居とソフトウェア、ということで、それぞれふりかえってみます。

芝居

2016 年は、92 本の舞台を観ました。

2015 年が 63 本だったので、前年対比でおよそ 1.5 倍。

観る本数を増やしすぎた

多いというのはよくやったということか、というと、そうとも言い切れない、という苦い感覚があります。

僕はおおむね以下のような手順で芝居を見に行きます。

  1. 芝居を見る
  2. 折り込みビラにすべて目を通す
  3. ビジュアル、タイトル、作・演出、出演者、場所、チケット代等の観点から、気になったものをピックアップする
  4. 気になったものを並べて、行くものと行かないものに仕分けしてから行くものを予約する

こうやって、観る対象がじわじわと広がっていきます。

他にも友人の誘い・すすめや演劇ライターの記事、ツイッターでの評判をきっかけに観に行くこともありますが、全体の 1 割程度にとどまります。

さて。

この「全ビラチェック」戦略は世界を広げていくためのやり方だったのですが、結果として本数が増えすぎて、一本一本をあまり大切にできなかった気がしています。

チケットを取ったのに、予定を入れ忘れていて見逃してしまったものも、2 本ほどありました。
一度ならず二度までも。大失態。

たくさん観て得たものは色々あった

とはいえ、これだけ観たのだから、もちろん得るものもたくさんありました。

たとえば、友人のすすめで、歌舞伎を何本か観ました。

どれも本当にすばらしかった。

ただ、歌舞伎は、一度切れてしまうと前述の観劇ストラテジーの網から漏れてしまうこともあって、その後観に行くことが結局ありませんでした。

これはぜひ、特別に枠を作って観に行くようにしていきたい。

また、これだけ本数を観ると、さすがに好みの役者や演技・演出のスタイルというものがじわじわとわかってきました。

偉そうにも、役者の良し悪しについて少しはものを言えるようにもなってきました。(あまり言わないようにはしていますが)

俳優業もエンジンがかかってきた

アマチュアの俳優業も引き続きやっています。

今年は、所属する劇団で 2 回め(小さいものも入れると 3 回め)の出演をして、去年よりずっとよくなったと多くの人に言ってもらえました。

いくつか本を読んだことと、劇団での稽古(基礎的なトレーニングはほとんどなく、台本のリハーサルが中心)以外にはほとんど何もしていなかったので、これも舞台の本数を観たというところが大きかったのではないかな、と思います。

スタニスラフスキーの『俳優の仕事』(ロシア語版から新たに訳した未來社版)を第三部まで読み通しました。
これは本当によかった。

いま日本で流通している演技指導法の多くはスタニスラフスキー・システムの影響を受けているのだと思います。(僕がこの 1 年半で見聞きした限りでは)

しかし、スタニスラフスキー・システムが本来意図していたところが伝わらず、間違って(一部が不当に誇張されたり、システムの習得には長い時間がかかることが無視されたりして)伝わってしまう傾向があるように感じられます。

その認識を正せたのは、大きな収穫でした。

また、これがきっかけで、スタニスラフスキー・システム(とメソッド演技)を理解して指導している人のクラスに通い始めました。

余談ですが、クラスの中ではこのクラスの参加者の芝居(エチュードや、一部のシーン)を観る機会があって、これがびっくりするほど面白いので、これからがとても楽しみです。

ソフトウェア

続いて、ソフトウェア業について。

読んだ本

この 1 年間何をやっていたのかは、定量データ(→読んだ本)を見ればよくわかります。

技術書 : 4 冊
チーム・組織・方法論についての本 : 19 冊
その他(技術読み物等) : 4 冊
  • 角川インターネット講座 (10) 第三の産業革命経済と労働の変化
  • IoT とは何か
  • 角川インターネット講座 (1) インターネットの基礎
  • 角川インターネット講座 (2) ネットを支えるオープンソース

スクラムから組織改革へ

いやはや。

並べてみるまで、ここまで偏っているとはさすがに思いませんでした。
ついにここまできたか。

今年に入ったあたりから、いま所属している組織では、自分自身の(個人の)ソフトウェア生産性というか生産技術を高めても、直近では大きな進歩につながらなそうだな~という感覚があって、自然とチーム、組織の問題に興味がフォーカスしていきました。

幸いにも、というか、そういう時期・頃合いだったのでしょうが、組織内でもやり方を変えていこう、アジャイルとかそういうやつまじめに検討してみようという機運が高まってきて、主力製品である DataSpider Servista の新バージョン開発では『アジャイルサムライ』および『アジャイルな見積りと計画づくり』を手引きにしたチームで開発していくことになりました。

そこへもう一つ転機があって、8 月に、チームリーダー*1に誘われて、3 日間の認定スクラムマスター研修に参加します。

これがめちゃくちゃよかった。

そのあとは、スクラムフレームワークにのっとって開発をしています。
しばらく続けて、スクラムチーム(プロダクトオーナー、スクラムマスター、そして開発チーム)全体としてのアウトプットを最大化していこう、というところまではきたと思います。

この流れは、最終的には、開発部門(開発部および品質管理部と呼ばれています)の生産性の問題でさえなくなって、営業・マーケティング・IT・人事総務等々まで含んだ組織全体のあり方の問題になっていくのだろうな、とも思います。

去年までは、あろうことか個人のスループット(アウトプットの量と質)にフォーカスしていたのだから、まったく恐ろしい。

予想の枠を越えるものではありましたが、大きな進歩をした、という実感です。

ただ、さすがに個人的な技術力の研鑽が少なすぎた、というのは確実に反省すべき点で、やや比重を変えていく必要があるとも思います。

目標「全力で走る」についてのまとめ

「全力で走る」という大づかみな目標は、以下のような根拠で立てたのでした。

それから、この一年でだいぶものごとがよく見えるようになってきて、もちろん昔に比べたらということですが、あまり細かく目標を決めたり、管理したりしなくても、うまく走れるんじゃないか、これもたとえですが、うまく行きたいところへ、もし目標を決めるとしたらそうと決めていたようなところ、そのちょっと先くらいのところへ、自然と行けるんじゃないか、という予感があります。

どうでしょうか……。

走れたかな、という感覚はあります。
全力かというと微妙なところで、8 ~ 9 割くらい。よく走った、と言っていいとは思います。

ただ、

もし目標を決めるとしたらそうと決めていたようなところ、そのちょっと先くらいのところへ、自然と行けるんじゃないか

これはどうかな、と言わざるをえない。

1 年前から見て、今自分がいる場所にびっくりすることはありません。
まずまず、着実に進んだね、とは思いますが。

最近読んだ本の多くに書いてあることで、またスクラムフレームワークの根拠の一つでもあると思うのですが、人は計画していないことをやるのが苦手です。

何かやるべきことがあるとして、「(今)やるべきか、やらざるべきか」と考えることで、いちいち意思の力を消耗します。
結果として、成し遂げることの量は少なくなります。

だから、計画をしないというのは得策ではないな、と今は率直に思います。
もっとも、これも試してみて体感したことなので、この一年が失敗だった、とは思いません。

手入れして暮らす

さて、2 つめの目標について。

これは、1 つめの目標「全力で走る」を本当に全力でやるとたぶん生活が荒れるだろうから、壊れないようにしよう、という意図を持って入れたものでした。

壊れなかった

結果としては、生活は壊れていません。

とにかく本が増加傾向なので部屋は少し狭くなりましたが、足の踏み場はありますし、服やその他の消耗品も(使えるお金が多くはないなか)うまく交換・維持できていると思います。
友人関係も壊れていない、と思います。

ただ、特別に改善もしていません。

全体として「やや荒れた」という感覚で、そこそこ走ったことも考え合わせると、可もなく不可もなくだなあ、という評価です。

もっと丁寧にしてもいいのかも

なんとなく、すっきりしません。

もともと維持が目的だったので、いいと言えばいいのですが、もっとちゃんとしていた方が、もっと走りやすくなるのではないか、という気もするのです。

できる人の机は汚いとか、芸術家の部屋が散らかっていたみたいな言説もありますが、そういうこともある、というだけなのではないか。

余計なものはない方が、思考はすっきりします。
散らかった思考の面白さというものは、経験があるのでわかるのですが、整理された思考から生まれるものの価値を認めてみるのもいいのではないか。

思い切って、生活の方針を「丁寧に暮らす」にしてしまってもいいのではないかな、という気もしています。

補遺について

2016 年のはじめには、上にあげた 2 つの目標の他に、あと 2 つのことを考えていました。

社会に目が向いていく

社会に目を向ける、ということについて。

うーん、できたのか、どうか、よくわかりません。
そもそも、社会に目を向けるということがどういうことなのかも、まだよくわかりません。

ただ、徐々に社会に目が向いていくのだろう、ということは思います。

たぶん、人は自分だけのために生きられるようにはできていないのだと思います。(中には、そういう人もいるかもしれませんが)

俳優業も、ソフトウェア業も。
自分が楽しむため、生きるためといった目的から、徐々に社会的なものが目標になっていくだろうな、と思います。

無理にそちらを向こうとしなくても。

少し荒らしてみかった

こう思っていました。

今年の目標、特に「手入れして生きる」の方は我ながら実に常識的でまっとうな目標だなと思っていて、それがなんだかつまらないな、ということを少し思います。 「本当は少し荒らしてみたい」と言ったのも、たぶんそういうことです。

今は、思いません。

荒れるときは荒れる。

荒れていない、というのはありがたいことです。
それに、目標だった「手入れして暮らす」のふりかえりでも書いたように、荒れていないからこそ達成できることというのもあるような気がします。

荒れるときには、荒れるでしょう。

だから、わざわざ荒らすことはないな、と今は素直に思います。

目標についてのまとめ

全体として、月並みですが、充実した一年だったな、と思います。

(今思えば)具体的な目標を立てなかったにもかかわらず、よくまっすぐ歩けたな、という感覚です。
運がよかったのかもしれません。

その点、「全力で走る」と言いながら、どこか充電したような感覚もあります。
うーん、まだまだ全力じゃなかったのかな。

一度落ち着いて、これからのことを考えてみたいなと思います。

それ以外のことについて

目標の枠の外のことについて、いくらか書いておきます。

本について。
2016 年は、120 冊読みました。

2015 年が 192 冊だったので、およそ 3 分の 2 ですね。
もともと、数は減らそうと思っていたので、妥当な数だと思います。

とはいえ、これでもまだ少し多いかな、という感覚です。
ついつい、本を読んでしまいます。

本を読むこと自体は悪いことではなく、この 5 年は半分くらいは本の力で生きてきたと言っても過言ではないのですが、本を読むには時間も、お金もかかるというのも事実です。

特に、時間。
もう少し、本以外に時間を使うようにしていきたい、という感覚があります。

芝居

芝居については、目標のところでだいたい書きました。

やはり、スタニスラフスキー・システム/メソッド演技のクラスでがんばってみる、という当面の方向性が決まったのが、何よりも大きな収穫だったかな、と思います。

一方で、地点のようにスタニスラフスキー・システムを(正当に)批判する人たち(そして、そのアウトプットはすばらしい)もいるので、視野が狭くならないようにしよう、ということも思います。

記事一覧

2016 年に書いた芝居関連の記事は、6 本でした。

ソフトウェア

ソフトウェアについても、目標のところで書きました。

技術が好きだと思っていたのですが、どうもそればかりではないようだ、ということがこの 2 年ほどではっきりしてきました。
いや、もちろん技術は好きなのですけど。

これからどうしようかしら。

今年は、JavaOne に会社から 2 人で行かせてもらいました。

参加者の中には JavaOne に往時ほどの盛り上がりが見られない、という感想もあり、たしかにそうなのかも、と感じるところもありますが、それでも、Java プログラマなら行って得られるものはとても大きいカンファレンスだと思います。

Java についての最新の一次情報が得られて、世界の Java コミュニティに触れられる機会。

来年もぜひ、また違ったメンバーも、JavaOne に参加できるといいと思います。

記事一覧

2016 年に書いたソフトウェア関連の記事は、個人ブログ 5 本、会社ブログ 6 本、Qiita 3 本でした。

個人

会社

Qiita

全体のまとめ

全体として、いよいよ熟してきたな、という感じがします。

そういう年代なのでしょう。
第一成熟期、というか。

一方で、俳優業だとか、比較的新しく始めたばかりのこともあります。
それも含めて、これからどうするかによって、色々なことが大きく変わっていくでしょう。

どこへ行こうかな。

今年も、たくさんの人のお世話になりました。
みなさんが、心安らかに新しい年を迎えられますように。

*1:現在のスクラムマスター。当時は『アジャイルサムライ』の用語にのっとって「アジャイルなプロジェクトマネージャ」みたいな呼び名だったような気がします