「真実は小説の中にある」という言葉@『最初の人間』

『最初の人間』を岩波ホールで見てきた。
http://www.zaziefilms.com/ningen/introduction.html

厳しい祖母、優しい母、理解ある教師そして、癒しである太陽と海、原作者であるアルベール・カミュの青春と人生を支えた存在への強い思いが優しく表現された映画だった。
独立を目的としたテロに揺れるアルジェリア。
そのアルジェリアにフランス人として生まれ、フランスで有名作家となった主人公、カミュの分身であるジャック・コムルリ。
出身大学でのアルジェリアを支持するスピーチをおこなったものの、会場は荒れる。

アルジェリアの寄り添うことを心に決めつつも、フランス人として名声と富を得た自らの立場とアイデンティティに悩む。
ジャックは、自らのルーツを探すように亡き父のことを調べはじめ、幼い時を過ごした場所を訪ねる。

僕の印象に残った言葉が、ジャックである恩師であるベルナールの言葉だった。
それがタイトルにもした「真実は小説の中にある」という言葉だった。

この言葉はどういう意味だろう。
小説にの中にある真実とは、人びとの生活を描き出すこと、そして、読み手にその生活を想像させ共感させることなのだと思う。

よく言われるが死者の数も多数になれば統計になる。
ようするに問題が大きくなればなるほど、その問題に煩わされ、不幸を背負う人びとの姿は消えてなくなる。

貧困問題、紛争という大きな概念を指す言葉がそうだ。
言葉から、問題の重大さは伝わってくるが、人びとの生活と苦悩を想像させる力はない。

たしかに、マクロな視点は問題を整理し、問題の真の原因を発見する手助けをしてくれる。
一方で、マクロな視点から生み出される解決策は単純化されていることがおおい。
「ここに至っては武力解決もやむを得ない」という言葉はまさにマクロな視点による発想だ。

地域紛争を解決する方法が、武力解決しかない、ということはありえるかもしれない。
ただその地域には生活している人々がいる。
武力による解決によって、生活する人びとは死をはじめとしたあらゆる不幸を背負う。

ベルナールが小説の中に真実がある、というとき、アルジェリアの独立という大きな問題が覆い隠す人びとの存在が描かれることを期待しているのではないだろうか。
アルジェリアの独立は、大きな視点からはアルジェリア人（映画ではアラブ人という言葉が使われていた）とフランス人の対立として捉えられる。
フランス人はフランスを支持し、アルジェリア人はアルジェリアを支持する、という暗黙の前提がある。
その前提では、事実として、フランス人としてアルジェリアに生まれ育った人びとがいることが考慮されていない。
彼らの苦悩は存在しない。

しかし、人びとの生活を描ける小説であるのなら、彼らの苦悩を描き出せる。
彼らのことを知らない人びとが、小説を通じて彼らに共感し、理解する機会を得る。

真実が宿る小説とはそんなものではないだろうか。

この映画を見た後で、奇しくもアルジェリアで日本人も人質に含まれるテロが発生していることを思い出した。
触れなければならないように思えたのだけど、なぜテロが発生したのかの理由、背景を僕は知らない。
人びとの生活がどのようなものなのか、想像もつかない。
ただ、問題への無知と想像力のなさが問題を長引かせる、ということが原因であることがわかるのみだ。
だから語れることがない。

ただ、双方の被害が少なく問題が解決することを祈る。

この前のつぶやきをもう少し深掘ってみた。

先日、

QAをやっている方でJunitテストを書きながらレガシーコードを改善しつつ品質を高めたい方などいらっしゃいませんかー？　現状、Javaのコードが読めなくても、書けなくても、Junitを使ったことがなくても、やってみたいという方はいらっしゃいませんかー？—
おっぴー || ぴーおつ (@_oppy) November 15, 2012

というつぶやきをしたら多数のひとにリツイートしてもらったので、なぜ、あんなつぶやきをしたのかもう少し書いてみたい。

なぜ、あんなつぶやきをしたのか、それは僕達のチームが技術的負債という痛みを抱えているからだ。

そして、技術的負債を解消しつづけるために、ともに開発現場にいてくれるエンジニアをチームが求めているからだ。
技術的な負債が生み出される原因は、エンジニアの技術もさることながら、負債を抱えたプロダクトを産み出すことを許す開発プロセスがあり、さらにその拙劣なプロセスを許す文化があるからだ。

そして、現状のメンバーでは、技術的な負債に対抗できていない。

創業から5年目の会社ということもあり、0を1にするエンジニアは数多くいるが、1になったものを磨き上げる文化はあまり根付いていない。
小さなチームなのでプロダクトの開発に関わったエンジニアが、そのまま運用にも関わっている。
この点は問題を是正するのに役だっているものの、影響は小さく、全く足りていない。
くわえて、「不具合を発見する」という観点でテストコードを書いたり、プロセスを作る力と余裕が不足している。

こうしたチームで、プロダクトの品質を作りこみながら、プロダクトの品質を改善し続ける文化をつくり上げることが新たにチームに来てくれる人に求められることだと思っている。

これは簡単じゃない。
四六時中、品質向上について考えながらチームのメンバーを啓蒙して行ける人ではないとダメだ。
しかも職場を変えて、新しく関係を結ぶ人たちの信頼関係を得ながらだ。
だから、非常にストレスフルな作業になるだろう。

そして、この難しい仕事をやり切るためには「不具合の発見」という観点からプロダクトの品質向上させるためのプロセスと文化をつくり上げるための提案に自信をもつことが必要になるだろう。
僕がQAの人といっているのは、品質ということに関して他のエンジニアより考えを巡らせた経験が多く、自信をもった提案をしてくれるのではないか、という期待があるからだ。

そして、コードを書いた経験がなくても良い、というのは、コードを書いている経験よりも「不具合の発見」をすることの経験を重視しているというだけだ。
もちろん、両方を持っている経験と自信をもっているエンジニアのほうがもちろん良いのは言うまでもない。
ただ、そんなできるエンジニアが、今のキャリアを捨て、創業5年目の不安定なベンチャー企業にはいり、技術的負債の返済に時間を費やすということがあまり想像できない。
そんな方に来てもらえるとマジで助かりますが。

ということで、つぶやきを含めてこの話にちょっとでも興味が湧いた方は、酒でも飲みながらはなしませんか。
もちろん、アルコールなしでもいい。
で、実際にどこの会社で何やるの？
どんな人と仕事することになるの？
こうしたことをもっと詳しく話しながら、僕らのチームで一緒に働けるか判断してほしいなと思っている。
もちろん、どんな技術を使っているのか、社会とどのように関わる仕事なのか、こうしたこともお話できればとも思っている。

大切なことだけど、僕には人事権はないのでその場で話が盛り上がったからといって即入社、という事にはならない。
でもどんな奴らとどんなふうな仕事をするのか、それを知ってから実際に入社できるかどうか検討してもらいたい。
そのあとで、給与面などを人事権のある社長とか偉い人と話してもらいたい。
そうすれば、もっと具体的に今のチームにはいって働けるか考えてもらえて、ミスマッチが減るのではないか、と思っている。

なので、興味ある方は、リプライなりDMなりでご連絡ください。
時間はお昼でも、夜でも都合のよいときに、都内でお酒かご飯を一緒しながら仕事のお話をしましょう。
地方の方ならSkypeでお話でもいかがでしょうか。

こちらの要望ばかり書いてしまった。
そもそも、検討に値するか考えるために、会社の概要が知りたい、という方もお問い合わせをいただければ会社の情報や求人情報をお送りします。
ではでは。

@_oppy

物語の外側の気になること@『最強のふたり』

ふたりのうちのひとり。
大富豪の老人、フィリップ。

フィリップはパラグライダーの事故で首から下が全く自由が利かな体になったのだけれど、単身で事故にあったのだろうか。
パラグライダーのシーンでは、彼はインストラクターと一緒に飛んでいたのだけれど、それは体の自由が利かなくなったためなのだろうか。

もしも、フィリップが事故にあった時もインストラクターと一緒に飛んでいたとしたら、そのインストラクターはどうなったのだろうか。
一人は首から下が不髄になるほどの事故だ。
インストラクターも無事であるとは思えない。相当な大怪我をおったかもしれない。
再び空を飛ぶことが恐ろしくなってしまったかもしれない。
事故の責任を取らされて失職してしまったかもしれない。

フィリップの事故に巻き込まれたインストラクターが本当にいたとしたら、ドリスに出会って彼が救われたように、インストラクターにも救われてほしいものだ。
本当にいたらだけど。

ふたりのうちのもうひとり。
黒人移民の子、ドリス。
彼はフィリップはどこで打ち解けたのだろう。
移民の黒人の子と首から下が不髄の大富豪の老人、両者を結びつけたものは一体何だったのだろう。

貧乏と自由にならない体という弱点をお互いに持っている。
そうした弱点をもつ苦労を互いに認めあったり、慰めあったりする場面はあった。
ただ、お互いが自分の弱点についての事実や気持ちを率直に話すのは、すでに心をひらいているからだ。

その前の心を開くきっかけは何だったんだろう。
なにかドラマがあることを期待するけど、一方で、ドラマがあったというわけでもないというものわかる気がする。
毎日の一緒に居つづけることこそが、お互いの心を近づけたという方が説得力がある。

ただ、ドリスがその時まで全く関わりなかった大富豪の家にとどまり続け、介護の仕事を続けられたのはなぜだろうか。
自らが抱えていた貧困を解消したいという動機だろうか。
映画の随所で見られた性根の明るさと優しさゆえだろうか。

その動機はドリスだけの秘密。フィリップも知らないことなのかもしれない。
もしかしたら、ドリス自身にもわからないことなのかもしれない。

『最強のふたり』という映画は実話を元にしている。
だから、ちょっとだけ映画では語られなかった外側の現実がきになった。

借りはコードで返せ、とかを学んだ1年でありましたよ。

先月で転職してから1年がたった。
振り返りの意味を込めて、職場を変えて1年間で実感したこと書く。

僕は元COBOLer（もっと正確に言うとNATURALという言語で開発をしていた）から特定の業者さんが使用するWebサービスをASP提供する会社に移った。
COBOLerがWebサービスに移ったらという苦労話も需要が多いかもしれないけど、具体的にどのような技術や知識を必要としたか、というのは書かない。
強いて言えば、JavaでもPHPでもRailsでもGrailsでもよいから、Linux上でWebアプリを1つでも完成させた経験があると良いのじゃないかと思う。
というか、そういう経験がなかったので、死にかけた。僕は。

ともあれ、おかげさまで、今の職場は楽しいし、やり甲斐のある仕事を楽しんでいる。

◯業務知識重要
転職して一番苦労し、今も悩ましいのは自分の業務知識のなさだ。
業務知識を持たずに仕事はできない。
日々の仕事の優先順位を自分で立てられない。
優先順位を自分で立てられずに働くということは、人に指示されて働くということだ。
人に指示されて働くという状態は、自分をコントロールできないことを意味する。

自分がコントロールできないことのストレスは耐え難い。
なんとか自分のコントロールを取り戻す必要がある。

僕にとって自分がコントールできている状態を端的にいうと、自分で自分の仕事の質、量、期日が調整できるということだ。
もう少し具体的に言うと、取り組むべき最重要な課題と期日を自分で決め、期日通りに終了させられる、ということだ。

自分をコントロールするためには、サービスをどのように成長させてゆくのか、を想像できることが重要だ。
なぜなら、今日取り組むべき最重要の課題とは、自分たちのサービスをどのように成長させてゆくのか、という目的にとって最重要な課題だからだ。
そして、自分たちのサービスの成長させてゆくのか、を考えるためには道標が必要だ。
どういったものが道標になるのか、というと有名なった

アップルで働くまで、イノベーションというのは「今にない、新しいものを作ること」だと思ってた。でもそれは違って、イノベーションというのは「未来にある普通のものを作ること」なのです。この違いを理解できるまでかなり時間がかかった。

アップルで働くまで、イノベーションというのは「今にない、新しいものを作ること」だと思ってた。でもそれは違って、イノベーションというのは「未来にある普通のものを作ること」なのです。この違いを理解できるまでかなり時間がかかった。—
Shu Uesugi (@chibicode) February 05, 2011

という言葉が全てであるように思う。

すなわち、今、僕たちのシステムを使って仕事をしている人たちにとって「未来にある普通のもの」こそが僕たちが作っているサービスの道標になるはずだ。
もしくは、その人たちの未来の普通にあるものを支えるサービスと言って良いかもしれない。

道標の探し方は、話題になっている『ビジネスモデリングジェネレーション』や『SubjectToChange』でも知ることができる。
その中で共通しているのは今の普通を知ることだ。
エスノグラフィとか人間観察とか、現状分析とか言われるものかもしれないが、今をくわしく知ることが、未来の普通を描くことのタネになるのだ。

そして、特定の業界に向けてシステムを作るエンジニアにとって今の普通を知ることとは、業務の商習慣や利益構造などについて詳しく知ること、すなわち業務知識を身につけることなのだ。

以前の僕は、受託開発で枯れた技術を使って開発をしていると業務知識に重きをおきすぎる文化が嫌いだった。
自分がコードのバグと格闘している立場にいると、コードが読めなくても書けなくても業務知識があればよい、という考え方には腹が立つことも多かった。
そして、業界の未来を描く、というと山師的でうさんくさい、業務知識というとおかたくてダサいと思っていた。

ただ業務知識をなくすと何も見えなくなる。
今を詳しく見れない人間には、未来の普通を描くことはできない。
エンジニアにとって一番、良い場所は、未来の普通を描ける場所で、サービスなりを構築することに自分の技術力を存分にふるえる場所なのかもしれない。
それが転職して得た気づきの一つだ。

◯経験の質と時間重要
RubyやAgileという言葉に吸い寄せられる人々だったら37signalsを知らない人はいないと思う。
知らない人はモグリじゃないが、損している。
『getting real』や『小さなチーム、大きな仕事』はシステムづくりを仕事にしているなら読んでみるとかっこいい言葉とともに多くのことが学べる。

その37signalsいわく

(前略)仕事依存症は不必要なだけでなく、バカげている。『小さなチーム、大きな仕事』(p.22)

という。
彼らはこの信念のもと働き、そして成功している。

生産性を仮に時間単位で稼げるお金の額(money/hour)とするならば、生産性を上げる方法は、稼げる額を維持するか伸ばしながら、労働時間を減らすことだ。
37signalsは、労働時間を短縮することは生産性を上げること、優れたソリューションを生み出すことに寄与すると考えている。

そんな経験をしていないのでわからないけど、直感的に37signalsの言葉は正しい。
ただ、僕が転職して直面した問題は、時間を減らしながら稼ぎをふやすということは非常に困難、ということだ。

業務知識がなくなったことも関連しているけど、右も左も分からない状態で期日までに目的を達成することがまず非常に難しい。

もちろん、周囲の人達は聞けば助けてくれる。
でもやり遂げるのは自分だ。そして、やり遂げるには自力が必要だ。

そして、自力をつけるためにも時間を投資する必要がある。
学習したい内容に最大限の時間を投資するのだ。
学習の対象が業務知識であり、自社サービスのプロダクトのことであるならば、仕事に時間を投資することは理にかなっている。
ワーカーホリックは馬鹿げているのはわかっているけど、右も左も分からない状況ならどっぷりと仕事につかるのは悪くないと思う。

もちろん、学習の方法は色いろある。
本を読む、写経をする、自分でアプリケーションをつくる、勉強会を開く（もしくは参加する）などだ。
ただこれらの学習方法は、実戦経験の補助に過ぎない。他社の経験の追体験でしかないからだ。
追体験は、仕事のような実践に活かしてこそだ。
結局、実践のための時間が必要になる。

ただ、陥りやすい罠は1つある。
やはり、37signalsがいうとおりだ。すなわち、

仕事依存症者は、ほどよい時間にしか働いていないという理由で、遅くまで居残らない人たちを能力に欠けているとみなす。これは罪悪感と士気の低下をはびこらせる。さらには実際には生産的ではないのに、義務感から遅くまで残るのような「座っていればいい」というメンタリティを生み出してしまう。『小さなチーム、大きな仕事』(p.22)

自分の仕事を果たして、時間通りに帰る。それが普通のことだ。
長時間働いていることは自分で選んでいることであって、人から強制されるものではない。
ましてや他人に強要するものでもない。

経験には時間だけでなく、質も関係する。
これも感覚でしかいないけれど、「仕事」という漠然にたいして長時間、投資を行うのは不毛だ。
不毛なことの1つの基準としてルーチンワークに落とし込めたらそれは時間を投資する価値がないもので、自動化の対象だ。
自動化できることを繰り返し自分の時間を投入するのは良い経験ではないし、時間の無駄だ。

また、質という点では人間の限界もあるだろう。
人間の集中可能な時間をこえて仕事に取り組むことは果たして良い経験になるか、ということだ。
たとえば1日8時間しか集中ができないとしたら、それ以上の時間を注ぎ込むことが良い経験になるだろうか。

僕の実感からだと、
・学んだことをメモに残せる
・1週間ないし2週間のイテレーションの計画を立てる時間がある
・週に1度ジムにいき、酒を飲みいける時間がある
これを満たせないとどんなに仕事に時間を投入してもムダになる。
作業のミスや抜けが多くなるし、経験したことを記録しておけないのでやったことを片っ端から忘れてゆく。
ようするに経験が蓄積されていない状態になる。経験をムダにしているのだ。

もちろん、これは僕の場合であって他の人に当てはまるかどうかはわからない。

働き過ぎは37signalsが言うように間違った価値観を生む。
あと、なんにせよ、他人の命令や指示で長時間労働することは馬鹿げている。
もしも、時間を仕事に投資するなら最低でも、その投資に自分が納得している必要がある。

◯借りはコードで返せ
そんなこんなで、一緒に働いている人たちには今もたくさんの迷惑をかけながら仕事をしている。
周りの人たちができるのに、自分がいまいち利益や仕事で貢献できていないのは肩身が狭い。
周囲の人たちに比べてできない自分が情けない。
そういう状況に陥ると、「他の人の邪魔をしちゃいけない」と考えて、優秀な人たちの時間が空くように雑用を巻き取る事を考えたりする。

ただ、それは逃げの思考だ。
よく言われる通り、組織の強さは最弱の部分に依存する。
もしも、組織の開発力を考えるのであれば、自分が底辺かつ成長しないのであれば組織の開発力は上がらないままだ。
組織を強くするためには、自分を鍛え、やることを増やし、質を上げるという正攻法の努力が必要になる。

自分ができなくて周囲の人たちに頼りっきりの状況は非常に情けないし、申し訳ない気持ちにさせられる。
でも、優秀な人たちと働くと自分の実力以上の仕事ができる。
そんな経験は何にも代えがたい。
自分から進んで会社をやめたくはないけれど、やめたほうが会社のためになるのではないか、という非常に悩ましい状況だ。

そんなさなか、いわれたのが

借りはコードで返してください

という言葉だ。

ようするに仕事の借りは仕事で返せ、ということだ。
仕事を進めていると、相手の邪魔をしたり迷惑をかけたり、はたまた時間を作って手伝ってもらったりすることがある。
そんなときには、ありがたいとか申し訳ないとか思う以上に、自分ができることをしっかりやり遂げることが一番の借りの返し方になる。

エンジニアの仕事は単にコードを書くだけではないけれども、仕事のうえので貸し借りや自分に求められる仕事へのコミットの仕方が端的に現れている言葉だと思う。
だから僕はこの言葉が好きだし、実践したいと考えている。

今までの借りはコードで返すのだ。

◯今後やりたいなぁと思うこと
ということで、1年分の借りを今年は返して行きたいと考えている。

Jenkinsのコミュニティってすごいなぁと思った@Jenkinsユーザーカンファレンス

2012/07/29に行われたJenkinsユーザーカンファレンスに参加してきた。
1000人以上の参加登録が行われ、国内で行われるIT系のカンファレンスとしては有数な大きな規模で盛り上がったようだ。
大きなカンファレンスが有志で行われることは、Jenkinsが多くのエンジニアにとって有用なツールであり、また、多くのエンジニアに愛されていることの証拠だろう。

◯優れたツールをつくるコミュニティには貢献の意識が中心にある
川口さんの基調講演ではJenkinsの現状やこれからの取り組みについて聴いた。
話を聞いて考えたのは、
なぜJenkinsが多くのエンジニアに愛されているか
なぜJenkisnのコミュニティは活性化しているのか
ということだ。

この答えは非常に単純で、
エンジニアたちへの貢献を一番に考えた取り組みがなされているから
だろう。
Jenkinsの取り組みとして
- よくある作業をやりやすくするためのUIの見直し
- pluginによりユーザーが好みの機能を拡張しやすくすること
- 頻繁にアップデートができないエンタープライズでの利用者に向けてLTSの用意
など利用者がどこで困るのか、どんな対応をしたらうれしいのか、という点をよくみて対応が進んでいるように感じた。

またJenkinsのおすすめpluginを集めたおすすめpluginパックのようなものを作る予定があるらしい。
Jenkinsはpluginが豊富にある一方で、個人的にはどんな便利なpluginがあるかほとんど把握できていないので、この取り組みは非常に良いなと思った。

1000人も集まるカンファレンスを有志で開催できてしまうほどパワーのあるコミュニティは、Jenkinsという優れたツールに引き寄せられた人たちによって成り立っている。
Jenkinsに引き寄せられるのは、Jenkinsがエンジニアたちに貢献をしているからだ。
そして、Jenkinsが優れたツールであるのは、素晴らしいコミュニティとそこに集まる人たちの貢献があるからだ。

川口さんのお話を聴いていて、Jenkinsというツールとそのコミュニティは、エンジニアたちと良い循環をもった関係を築いており、エンジニアとコミュニティが相互に貢献の意識を持っているからなんだと感じた。

◯buildhiveが素敵
これも川口さんお話で出てきたのでけど、buildhiveというツールが非常に良い。
というかものすごく期待できる。使いたい。
現在、gerritを開発で使っているのだけど、その理由は1つ。
中央のリポジトリにバグを含むコードが入る確率を低くしてくれるからだ。

今回のカンファレンスでもgerritとjenkinsの組み合わせを利用した事例を発表していた方がいた。
その方も話していたけど、gerritを利用すると
- gerritにpush
- Jenkinsによるビルドとテストの実行
- test実行後に人間によるcodereview
- ビルドとテスト、コードレビューをすべてにクリアしたら中央リポジトリにマージ
というフローで開発ができる。
エンジニアたちがpullをするリポジトリには、ビルドとテスト、レビュー済みのコードが入ってることになる。

buildhiveというツールは、githubのpullrequestを利用してこれとほぼ同じことが出来る。
つまり、pullrequestを行ったプログラムにたいしてJenkinsでビルドとテストが実行できる。
そして、ビルドとテストを通過したものをコードレビューをした後に、受け入れるかどうかの判断ができる。

gerritは魅力的な一方で、管理や利用の面で覚えることが多い。
一方で、githubは個人で利用している人も多い人気ツールだ。
おなじことができるなら、githubとbuildhiveのほうが導入が早いかもしれない。
buildhiveがあるならgerrit入らないくなってしまうかも。

余談だけど、設定周りの管理はpuppetを利用している事例をよく聴いた。
名前は知っているけど何ができるかよくわかっていないので、ちょっと勉強してみたい。

◯自働化のキモは適切なジョブの分割
自働化で意識しておきたいこと下記の3つかな、と感じた。
- どこで、何が原因で処理が失敗したか検知しやすくする
- 時間のかかる処理を並列で行えるにする
- 失敗したジョブの再実行しやすくする

これらを達成するコツが適切な単位でのジョブの分割だろう。
というか、上記の3つがジョブを分割する際の指針になるような気がする。

◯Jenkinsを中心にすえて開発からデリバリーまでのプロセスを見直したい
サービスの開発から運用までをやっていると課題になるのは品質だ。
サービスの品質を維持するためには、プログラムのバグを出さないという基本からユーザーや開発に必要なドキュメントの整備まで、ひとつの機能を作ったり改善したりする際に行うべきことは多い。
現状、いわゆる「どのような状態をサービスの出荷条件とするか」というDone定義がチームでまとまりきらず、それによる作業の抜けが起きることがある。
また、やらなきゃいけないとわかっていても何かと言い訳してやらないこともある。

Doneを定義し実行する、という点においては、受け入れテストのレベルで自働化の必要性を感じた。
プログラムがどう動くかだけでなく、どのような目的を達成するか、という観点からテストが書かれて自働化することに加えて、コードのメトリクスをとり、テストの網羅率などをテストの成否の基準に加えたり(たしかCoberturaを利用していた)
単にバグないだけでなく、コードの品質も自働化により担保するなどの取り組みをおこなう。
また、Javaを使っているならJavadocをもとにドキュメントを生成する仕組みもある。

どのような品質のコードで、何が達成され、ドキュメントなどのどのような成果物が必要か、という観点から出荷すべて成果物を定義するきっかけとなるのが受け入れテストなのだ。
そして、Jenkinsにはそれを助けてくれる仕組みが用意されている。
Done定義そのものはチームが考えて決めてゆくものだけれども、Jenkinsを利用して自働化できることに注目することでDoneの定義に含めやすくなる成果物も増えるだろう。

gerritとJenkinsを利用したプロセスの話だと、開発のプロセスが固まるまでは半年ぐらいはかかったということだった。
はじめからモノゴトはうまくいかないし、問題意識があるからてすぐに改善できるわけでもない。
時間を捻出して少しずつ進めて行きたい。

で、そのための手段としてやはりベロシティやバグの発生件数、コードのテストの網羅率など利用価値の高い数値を簡単に取る仕組みを導入したいと考えている。
やはり現状がどうなっているのか、感覚値じゃなくて実測値から判断したい。
そろそろ取り組む余裕がでてくるはずだ。

◯最後に
今回のカンファレンスに参加して、Jenkinsは単にbuildとtestを自働化するツールという印象ではなくなった。
deployなどを含めて、開発から運用というプロセスにおいてあらゆる箇所の自働化の中心的なツールになってゆくことが期待されるツールなのだと感じた。

運営に携わった方々には、大変お世話になりました。
皆様、どうもありがとうございました。

チャラン・ポ・ランタンのライブがおもしろかったのでひさびさにブログを更新してみる

JAZZ ART せんがわ2012というイベントで非常に面白いライブを見てきた。
http://www.sengawa-gekijo.jp/kouen/07423.html

アーティストの名前は、チャラン・ポ・ランタン。

jazzを聴けると思っていたんだけど、どう考えてもジャズじゃない。
あまり音楽を聞かない僕の知識を総動員して考えると、あれは昭和歌謡だった。
普段ほとんど音楽を聞かない僕でも、どこかで聴いたことのあるような懐かしさを感じる音楽と、人間が表には出したがらない自分の心のうちを描いたような詩が印象的だった。

ライブを聞いていると、人間の表に出しづらい心の奥底にある感情をテーマに書かれた連作短編の小説を読んでいる気分にさせられる。

1つ1つの曲に物語があり、1つの曲ごとに完結している。
そんな1つ1つの曲がつながって、ライブが1つの作品になっているという印象だった。

下記に彼女たちのHPのURLを貼っておいたので確認してほしいのだけど、可愛らしい彼女たちの風貌からは想像できない詩の内容、そして、迫力のある歌声に圧倒されてしまった。

もう一つ、びっくりしたのはアコーディオンの音色。
テレビでしか聴いたことがなかったので、うまい人が弾くアコーディオンを生で聴くととすごく綺麗な音がするんだな、と感心してしまった。

お店にお酒がなかったので、はじめてライブをシラフで聞いたけれど、とても楽しめた。音楽素人の僕が久々に皆に教えて回りたいな、と思ったアーティストに出会ったライブだった。

チャラン・ポ・ランタンが気になる方は下記のHPで情報チェックしてほしい。（というか、たぶん結構有名なんだろう）
今度、フジロックにも参加予定らしい。
http://charan-po-rantan.o0o0.jp/

アジャイルサムライから学んだこと

1ヶ月に聞いたjonathan rasmussonの話で印象に残ったことを書いておこうと思う。

僕が彼からうけた教えは非常にシンプルで、
ルール1：
価値のあるフィーチャーを確実にリリースして信頼を築け
ルール2：
その信頼を決して裏切るな
という2つのルールだけだ。

アジャイルにやる目的というのは究極、価値のあるフィーチャの定期的なリリースだ。

もちろん、アジャイル開発を発祥とするプラクティスを上手く取り入れることは、開発現場が楽しくなったり、良い開発者を育てることができるようになったり、という効果もあるかもしれない。
とはいえ、それらは手段であって目的ではない。

楽しい開発現場は開発に携わる人の士気をあげる。
人が育てられる開発現場はチームのハネムーンナンバーを増やせるし、チームの能力を高められる。
だが、それは価値のあるフィーチャを継続的に生み出し続け、ビジネスとして成功する、という目的を達成するための手段だ。

たとえば、『アジャイルサムライ』で紹介されているインセプションデッキもデッキを作ることが目的ではない。
開発、プロジェクトの目的を忘れないために作成するのだ。
アジャイルにやるためにはたくさんの暗黙知がある。
アジャイル開発は、それらの暗黙知をプラクティスという名称で形式化した。
しかし、それがたくさん現れてきたことで意識的に考慮することが増えたことにより混乱が生じる。

ちゃんと朝会をやっているか、ちゃんとデッキを作っているか。
こうした視点は悪くない。
しかし、「ちゃんと」を判断する判断基準が大切だ。
単に実施されている、アウトプットが作成されている、という確認では意味が無い。
それは読まれない大量のドキュメントを作成する不毛さに似る。

アウトプットがあるか、という表面的な確認が行われていると、手段が目的になる。
そして、目的に近づくために取り入れた手段をこなすだけになる。
本当に目的にとって有用か、を判断せずに。

Jonathanの話を聞いて、限りなく単純化すると見るべきところは2つで良いように思った。
すなわち、
・チーム内で合意されたスコープを溢れさせずにリリースが出来てるか
・会社の業績は伸びているか
の2つだ。

Jonathanの教えをあまりに簡略化しすぎているかもしれない。
けど、彼の話を聴いていて反省したのは「実施したい、実施すべきだ」と思っていること、つまり手段を取り入れることに目を奪われすぎていて、自分の状況をうまく把握できていなかったことだ。
そして、なぜ「実施したい、実施すべき」と思っていたのか、理由を整理しきれていなかったことだ。

スコープを溢れさせずに定期的リリースができ、会社の業績が上向いているなら。
おそれらく、アジャイルにやれている。
そして、プラクティスを取り入れたいと思っているのは、アジャイルにやれている状況を維持するためだ。

アジャイルにやれているか。
という問たいする答えは非常にシンプルだったのだ。

なぜ実践なのかを考えた@ブレスト祭り

2012/03/03にDevLOVEとhcdvalueが合同開催したブレスト祭りに参加した。
http://kokucheese.com/event/index/28198/

「学びの効果を実感するにはどうするか」ということをテーマに、デザイナーとプログラマが出会ってアイデア出しをしたらどうなるか、という主旨で行われた。

最近は特に勉強会を開催する身として、どれだけ自分を含めた参加者が効果的に学べるか、ということに悩んでいたので、このテーマには惹かれるものがあった。

学んだことの効果が実感できれば、たとえば、勉強会で得た知見を実際に会社でも活かしてみようと思える人たちが増えるだろうし、実践者が集まる場所は魅力的な場になるだろうからだ。

この会に参加してあらためて思ったのは、「フィードバックを得ることが学びの効果を実感するには大切だ」ということだ。

フィードバック重要。そのためのアウトプット

なぜフィードバックが重要だとおもったのか。
そのように思った理由は単純で9名？の人たちとブレストをする機会があったのだか、学んだことをアウトプットすることを学びの効果を実感するために重視していたからだ。

方法は、学んだことのリストを作る、とにかく実践、ブログを書く、人に教える、などのよく聞くものが多かった。
なので、方法について目新しい！と思ったのではなく、僕の気づきは、実践やブログ、人に教える、リストを作るという頭の中のものをアウトプットすること通じて「フィードバックを得る」という目的があるのだ、ということだった。

いままで、学んだことを実践する、ということが学習の効果を実感できる1番の方法だし、学んだことの価値を高める1番の方法だろうと漠然と思っていた。

でも、なんで「実践が1番なのか」という点について深く考えたことはなかった。

しかし、今回いろんな人達のお話を聞いてそれがようやく理解できた。(ような気がする)
実践は頭の中に入れた理論や知識、人の経験と再び出会う機会であり、フィードバックをつうじて理論や知識の再解釈が行う機会になるからだ。

たとえば、人に教えることが学びの実感につながるのも、その行為を通じたフィードバックがあるからだ。

人に教えるときに自分の学びの深さについて実感したり、学びが深まるのは、「何を教えるか」「どう教えるか」などを考えて教材を作っている時だ。

そして、教材を作っている時というのは、内的に自分の学びの深さについてフィードバックをかける効果がある。
たとえば、自分が知っていると思っていることに穴があって、教科書などを調べ直す、ということは結構ある。
もちろん、教えている最中に質問されて答えられない、ということで自分の無知に気づくこともある。

教えるという機会は、自分の知識に自身が能動的に問い直し、問いの結果を通じてフィードバックをかけること機会でもあり、第三者から学びのついてフィードバックを受ける機会でもある。

学びの効果を実感するためにはフィードバックが必要であり、フィードバックをうけるための1番の方法が頭の中にある知識や知見をアウトプットすることなのだ。
そして、実践にはその知識を自分の状況に合わせて再解釈する機会がある。

だから、実践が大事。

とはいえ、実践のハードルは高い。

なので、「すぶり」ができる場が必要だ。
すぶりは、模擬的な体験を通じて学びを活かす場だ。
そして、失敗をしても良い場所だ。
それは、Wikiでいうところのsandboxのようなものだ。

勉強会のワークショップなどはまさにそんな場だと思う。
ワークショップは準備は大変だけど得るものが大変多い。
なので、機会があったらどんどん参加したいし、参加してもらいたい。

今回の企画は、講師の石井力重さんに非常にお世話になりました。
懇親会でもずっと貴重なお話を聞かせて頂きました。
ありがとうございました。

デブサミには僕に必要な言葉があふれていたので燃料もってかえってきました

今年もデブサミに参加した。
http://codezine.jp/devsumi/2012
そのなかで印象に残った言葉について書きたい。
なお、正確にメモを取ったわけではないので、発表者の方の言葉は正確ではないし、差異があると思う。

・人は忘れる生き物です(デブサミオフィシャルコミュニティから選出のLT大会2012：　及川 卓也さん)
この言葉を聞いて思い出したのは、自分が昨年の7月に転職をしたきっかけ、を忘れていたことだ。
僕が転職を決意したきっかけは、昨年の3月11日に東日本大震災だった。
あの日の地震は僕が生きてきて経験したことのないものだったが、当時、千葉に住んでいた僕の生活に致命的なダメージを追わせるものではなかった。

僕があの地震で転職したいと思ったのは、地震後のTwitterのTLを見ていたからだ。

僕のTLには震災という不測の事態にたいして、「ああしたい、こうしたい」「ああすればよいのではないか」という思いや考えを実行できるエンジニアたちがあふれていた。
当時、彼ら、彼女らの行動が英雄的な行為は輝いて見えた。
そして、一方、エンジニアという肩書きを持ちながら何もできない自分の無力を感じた。

もちろん、日本の多くのエンジニアが、あんな行為ができたわけじゃない。
ただ、震災直後の自分のTLに僕はエンジニアの原点を見たのだと思う。
つまり、必要なモノがないなら作れ。そして、必要な人に情報システムをつうじて価値を届ける。
不測の事態にありながら、エンジニアとしての本質を体現した人たちに憧れて、少しでもこの人たちに近づきたい、そう思ったから前の会社を辞める決意をした。

僕がなぜ今の会社で働いているのか、その原点となった体験を思い出させられた言葉だった。

・あらゆる制約がなくなったとして「アジャイルに」できるの？(アジャイルマニフェスト ディケイド：角谷 信太郎さん)
今まさにこの問いに答えることが出来る状態にある。
そして、「できてません」と答えなければいけない状態にある。

そもそも前の会社ではアジャイルにやるための下準備に悪戦苦闘していた。
「Scrumの要素を会社の開発に取り入れるためにはどのように組織にアプローチすればよいか」
「社内に勉強会の文化を根付かせるためにはどうすればよいか」
こうしたことを考えて社内の人達と情報交換したり、会社内での仕組みづくりをしていた。

それらはアジャイルにやるために必要なことかもしれないし、システムを作ることには必要なことかもしれない。
でも、うまくいけないど「アジャイルにやれるのか」という問いに真っ向から答えるものではないと感じている。

「何を作ればよいか」という問いに的確に答えることが重要だけれども、それを「どううまくつくり上げるか」という問いに答えることも重要だ。
アジャイルにやることはこの2つの問いに答えることだ。
しかし、「どううまくつくり上げるか」という部分に苦戦し、「何を作ればよいか」という部分に達せない。
それ実力がないからだ。

アジャイルにやるためのあらゆる制約をなくした場に行くことで、あらためて自分にアジャイルにやるための実力が無いことに気付かされる。
「何を作ればよいか」を求めるための知恵や方法も、「うまくつくり上げる」ための技術力も欠けていることに気付かされる。
それは、「上司が、同僚が、親会社が」という言い訳のある世界では、辿り着くことのない現実だった。

理論を知ること体現をすることの間にある溝の深さを知ることがまず大事だ。
そこから全てが始まる。

「アジャイルにやれんのか」
この問いとの競争だとあらためて覚悟させられた言葉だった。

・課題管理はコミュニケーション・ツールです(仕事のバトン、渡っていますか？ – プロジェクト管理におけるコミュニケーション基盤作り：鈴木雄介さん)
うえの２つの言葉とは違ってメタな話ではない。
今の仕事の課題に活かせる言葉と感じて印象に残った。
実際のお話は、JIRAを中心としたお話だったのだけど、僕としては学びが多いお話だった。

今の会社では課題の管理にredmineを用いている。
redmineをタスク管理とか課題管理とかイシュー管理とかさまざまに呼ぶ人がいるのだけれども、使用する目的はなんだろうか。

僕はこの言葉を聞くまで勘違いをしていて、redmineのチケットは自分のタスクの進捗を管理するものだと考えていた。
だから、備忘録というか自分が忘れたくない作業を考えなしに、登録していた。
また、書く内容も読む人がいる、という前提ではなくて、自分が理解できる程度の作業ログを記載するという使い方をしていた。

でも本当は情報共有のためのredmineのチケットはある。
だから個人的なタスクもすべてチケット化してぽんぽんと放り込んではいけない。
自分と一緒に仕事をしているチームメンバーに知ってほしいタスクをチケットにするほうがよい。
そして、チケットに書かれる内容もチームメンバーに知ってほしいこと、知りたいとことを書いたほうがよい。

デジタル化されたredmineのチケットは検索もできるし、gitとの連携もできる。
だから課題やタスクの情報を他の情報と結びつけながら集積、使用することに向いている。
こんなに便利なツールなのだから、コミュニケーションを活性化するためのツールとして上手く使って行きたい。

あと、課題を管理する前に時間の管理をまずやりなさい、という言葉も耳に痛かった。

・人の話の価値は自分が決める
正直、今年のデブサミには「行きたい！」という強い気持ちがわかなかった。
仕事を中心にやりたいことが山積みなのに、それを横目に人の話を聞いて何になるのか。

でも足を運んでその考えが間違っていたことに気づいた。

人の話を聞くことの価値は自分が決めるのだ。
前の舞台にたって話す人は大勢の聴衆に向かって話している。

心にひびく言葉がみんな同じではないし、自分でも時期が違えば同じ言葉に同じ価値を見出せるかわからない。
でも、経験に基づいた発表者たちの言葉には、自分の状態がどんなであってもその状態にあわせて価値を感じ取ることができる。

だから、自分がダメでも、絶好調でも、必死でも、腑抜けていても、その時、自分に必要で自分の心に残る言葉が発見できる。
みんなもそのときだけ、自分だけの言葉を探しにデブサミゆくといいと思う。

・ありがとうとおめでとう
@koseiさん、10周年、おめでとうございます。
そしてありがとうございます。
来年もきっと素敵なデブサミが開催されると信じています。

無題

そもそも、美術作品を見ていると「パッと見てスゴイな！」と思ったり、「いいな！好きだな！」と感じたりすることがある。
これは頭の中で何かを考えたわけでなく、脊椎反射と云うか作品にたいする解釈を挟まない感覚によるものだ。

美術作品を生んだ作家、生まれた時代背景、なにより作家自身が作品に対してこめた思いなどを知ることなく、作品そのものを見てどう感じるか、そして、その作品に価値を感じるかを判断することを「審美派」、一方で審美派が無視しているものを考慮して、作品の価値を判断しようとするのが「教養派」と誰かが本で、言っていた。

僕が中学や高校までに受けてきた教育では審美派的な美の価値を多く説かれていた。
作品は考えすぎずに自らの思うままに作ればよいし、作品の価値も「自分がその作品を見て何を思ったか」を基準に決めて良いのだといわれていた。

作品の美は言葉による説明を必要とせず、必然的ににじみ出てくるものだし、多くの人々はその美を理解できるのだ。
こうした考え方は間違っていないよう思うのだけれど、この立場に立っていただけでは理解出来ないことも多い。
僕にとっては、パブロ・ピカソのキュビスムの作品がそうだった。彼の作品が美しく、価値があるというのは「よくわからない」ことだった。

そんな、僕がピカソという有名な芸術家の作品の価値を理解できたのは、大学に入ってからだ。
図像学という講義を受講して絵には見方というものがあり、多くの人たちはルールに従って作品の価値、つまり美を理解しているのだと知った。

美は作品と自分との関係だけから湧き出るのではなくて、多くの人々は共有しているルールによって共有され、支えられている。
だから、作品を見ただけでは、その作品の美をとらえることはできない。
ルールを知り、ルールに沿った価値基準においてどの程度、価値が高いのかを説明しなければ作品の美は多くの人には伝わらないし、共有されない。

特に現代アートでは「なんだこれ？」という作品に出会うことが多い。
ポンッと目の前に置かれたなんだかよくわからない作品は、「何を表現したいのか」「なぜ価値があるのか」という見た目では表現しきれていない価値の説明を必要とする。

そうした作品に何がしかの説明があればいいだけれど、ないものも多い。
特に異国の美術館だとキャプションが読めないので、作品と自分との関係のなかで美を理解するという難行に挑まなければいけない。

このように考えると美には国境が存在していて、翻訳が必要であり、美術鑑賞は体感的な経験じゃないのかもしれない。

むしろコードの美をとらえるのと似ているかもしれない。
コンテキスト、意図がわからなければその美と価値が理解出来ないという点において。
そして、美をとらえるにはたくさんの美しいものを見るという経験と自分の創造物の美を主張する人は「なぜ美しいのか」を説明しなければならない、という責任がある点も。