Archive for the ‘システム’ Category

ふりかえりで過去の自分とのdiffを取ろう

12月 7, 2015

どうも。 1年ぶりのブログ更新。

それもこれも、すべてはDevLOVE Advent Calenderのため。

本エントリーは、DevloveAdventCalender7日目のエントリーでございます。

昨日のぽざうねさん、 5年前からすこしずつ成長された結果が大きなdiffとして現在、実っておられるようです。

そういえば私事だけど、ちょうど1年前ぐらいに転職をした。

前職ではWeb広告系のシステムのおもに保守と開発、運用をしていた。

再度、「人の役に立つ」という視点でしっかりとしたシステムを作りたい、と思い、ふたたびSI業界に出戻った。

いわゆるWebのベンチャー企業とは180度異なる環境に再度身を起き始めたので、やはり苦戦する部分があった。 そんなときに、自分を奮い立たせるためにできること、それが、過去の自分とのdiffを取ることだ。

具体的には、毎週KPTやYWTをおこなって、過去の自分より自分が成長している部分、学んだことを可視化してながめることだ。

失敗したり、忙しかったり、ストレスが溜まって余裕がなくなったときに、KPTYWTの記録で自分の行ってきたことを眺めると、 自分の過去の行動がすこしずつ自分自身のできることの幅を広げている、できることの質を高めている、という事に気づくことができる。

この気づきが、「明日また、すこしでも前に進もう」とおもわせてくれる。

最近のdiffでいえば、まったく英語を話せない自分が、出展ブースに来てくれた外国の方に英語でサービスを紹介する、ことができた。

以前であれば、めちゃくちゃな英語を恥ずかしがり話すこともできなかった自分が、サービスを紹介する、という目的のために、自分の羞恥心を克服した瞬間だった。

おそらく何も伝わってはいないし、その方とお取り引きするきっかけにもならない。けど、きっと将来、英語圏のどこかの誰かとお仕事を一緒するための一歩になったと思う。

そういえば、AWSやHerokuでスケーラビリティのあるサーバー構成を作り上げたり、Chefでサーバー構築したり、rubyでアプリケーションをつくったり、という経験もできた。

あと、提案書をパワーポイントで作成できるようになった。

KPTやYWTをもちいたふりかえりは、昨日の自分と今日の自分のdiffを可視化することで、自分が前進していると、自信をもっていえるツールにもなる。

ぜひ、お試しあれ。

広告

ビジュアル・コンプレキシティのChapter3を読んでおくといろいろ捗るかも、というはなし。

2月 2, 2014

マニュエル・リマ氏が来日するのですこしでも活かすため事前勉強会を開催した。
この勉強会で、「ビジュアル・コンプレキシティについて理解するには、『ビジュアル・コンプレキシティ』のChapter3にはネットワーク・ビジュアライゼーションについて読むと良いんじゃないか」とアドバイスをいただいたので、再読をした。

たしかに、Chapter3には、

  • 関連する手法と技術
  • 5つの機能
  • 実現するための8つの原則

がまとってまっていて、とくに8つの原則は実践的な内容なので、「どうやって活かすの?」という疑問を持つ人にはおすすめの内容だ。

しっかり読んでも1時間程度なので、読んでおくとビジュアル・コンプレキシティに通底している、ネットワーク・ビジュアライゼーションについて整理することができる。
詳しい内容は本を読むのが一番なので、ざっと要点を引用して紹介する。

関連する手法と技術

ネットワーク・ビジュアライゼーションはさらに大きなくくりとしてネットワーク表現の領域に収まり、研究されている。
そして、ネットワーク表現はおおきくネットワーク・ビジュアライゼーションのほかに、グラフの描写について研究されている。
ネットワーク・ビジュアライゼーションにはグラフ理論、コンピュータグラフィックス、地図製作法が大きな影響を及ぼした。

今日のネットワーク表現は、一般に(グラフ理論に則した)グラフの描写と(情報の可視化に則した)ネットワーク・ビジュアライゼーションの2つの領域で研究が行われている。
p.79

ネットワーク・ビジュアライゼーションに大きく影響を与えたものには、グラフ理論と近年のコンピュータグラフィックの成果のほかに、地図製作ある。(原文ママ)
p.79

ネットワーク・ビジュアライゼーションがもつ5つの機能

ネットワーク・ビジュアライゼーションは、5つの機能を備えることにより、人々との知的好奇心を刺激し、ビジュアルを通じて情報の処理や理解をたすけ、発見を導くことができる。
またビジュアルが新たな研究へ展開するきっかけとして作用することをも期待されている。

では、ネットワーク・ビジュアライゼーション固有の目的は何なのか? 複雑なものの表現は、以下の「記録」「明確化」「表面化」「拡張」「抽象化」という主要な5つの機能によって実現される。
p.80

ネットワーク・ビジュアライゼーションを実践するための8つの原則

8つ原則はいかのとおり。
事前の勉強会でも「そもそもビジュアライゼーションをするプロセスが謎だよね。」などと話していたのだけど、しっかりヒントは本に載っていたのだった。

  1. 質問から開始する
  2. 関連性を探す
  3. 多変量解析を可能にする
  4. 時間を含める
  5. 語彙を豊かにする
  6. グループ分けを顕在化する
  7. 拡大縮小を活用する
  8. 複雑さを管理する

インフォグラフィックは、作成者が説明したいことを閲覧者の理解してもらうのが目的で作られる。
なので、「この図ではこういうことが表現したい」という、作成者の目的が定まっている、という前提がある。

しかし、ビジュアル・コンプレキシティの中で紹介される図は、動的なインタラクションができないためか、「なにを表現したいのだろう」と思わせる図が多い。
そのため、図を作成するときの目的が、「単純に見た目の美しさ、視覚的な快が目的なのか」「なにか発見があったらいいな、という漠然とした目的なのか」という疑問を抱かされる。
とくに、見た目が幻想的な図は、作成意図もまた神秘のヴェールに包まれて徐々にはっきりしてくる、というプロセスをたどるのか、という疑問があった。

上記の8つの原則を見ると、やはり図を作成には目的ありき、であることがわかる。

以上、ざっとChaper3を読んだ結果を引用を含めてまとめた。

最終的に「ネットワーク・ビジュアライゼーションとビジュアル・コンプレキシティの違いってなんだろう?」というのが新たな疑問がうまれた。
また、図を見て発見がある、という経験をすることがあるけど、作成者が故意に閲覧者に発見を促すことは可能だろうか。
ようるすに「発見」を促すためのネットワーク・ビジュアライゼーションの開発のプロセスというのは存在するのか、またそのプロセスというのはどういうものなのか、が疑問としてのこった。

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

8月 4, 2012

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

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

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

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

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

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

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

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

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

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

道標の探し方は、話題になっている『ビジネスモデリングジェネレーション』や『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ユーザーカンファレンス

7月 30, 2012

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などを含めて、開発から運用というプロセスにおいてあらゆる箇所の自働化の中心的なツールになってゆくことが期待されるツールなのだと感じた。

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

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

4月 16, 2012

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

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

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

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

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

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

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

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

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

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

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

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

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

3月 4, 2012

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

だから、実践が大事。

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

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

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

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

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

2月 21, 2012

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

知らず知らずに内に自分の視点や行動は固まっているときづく@DevLOVE

11月 16, 2011

先日12日(土)にDevLOVE&yass合同勉強会「自力で海図を描きだせ!!」に参加した。
http://togetter.com/li/214190
http://kokucheese.com/event/index/19568/

講師の倉貫さん、梅野さんにお話を頂いたあと、「自分たちの10年後の明るい未来」というテーマでディスカッションを行った。

その際にエンジニアと経営者との視点や行動の違いが印象に残ったので、下記にまとめる。

ディスカッションで印象に残った指摘として、「エンジニアは自分を中心に将来を考え、経営者は外側にどのように影響を及ぼすかで将来を考える」というものがあった。

10年後の未来を考えるときエンジニアは「自分はアーキテクトになって」とか「プログラマとして現役でいたい」などのように、「自分がどうなっているか」を中心に未来を考えている。
一方で、経営者は「社会をこのようにしたい」とか「こういう問題を解決していたい」などのように、自分の事業や行いが「世界にたいしてどんな影響を及ぼしているか」を中心に未来を考えている。

こうした視点の違いから、現在の扱いも違ってくる。
10年後を考えるときにエンジニアは「googleはどのドメインで稼いでいるか」「メモリやCPUはどんな進化をしているか」など、現在の情報を集めて分析することで将来を考える。
いうなれば、現在の延長として未来を考えおり、現在は未来を構成するための材料だ。

他方、経営者はすでに自分の理想としての未来を思い描いている。
経営者が思い描く未来には、現在の事実や情報はあまり関係ない。
現在は理想の未来にたどり着くため過程であり、現在取り組むべき問題は理想の未来から逆算して取り出された課題だ。

経営者の未来は、現在の事実を積み上げた先にはなく、自分の思いや理想にあるのだ。

もう1つは、エンジニアは行動の前に情報を集めたがる、ということだ。
講師の一人は、「起業をしたいのですが、おすすめの本はありますか」という質問をされたというが、まさにそれがエンジニア的だ。
なにかをやるにつけそのことについて事前知識を持ちたがる、という姿勢は、冷静といえば冷静だが、行動力にかける。

一方、経営者は、起業をしたいと思っならまずは起業してしまう。
当然、前情報が少ない分失敗することもあるだろうが、その経験から学ぶ。
経験と共に学習し、学習した内容を実践投入することで、成功する確率を高めるのが経営者なのだ。

エンジニア的視点と経営者的視点のどちらが優れているか、ということは重要じゃない。
問題は、エンジニアや経営者として働いていると知らず知らずにのうちに視点や行動が固定されていることだ。

今回、エンジニア以外にも営業や経営者など立場や価値観が違う人たちが集まってはなしたことで、自分の考え方や行動が固定しがちなことに気づくことができた。

同じようなコンセプトで第2回も開催してみたい。

朝会ワークショップを楽しんだ@すくすくScrum

10月 2, 2011

2011/09/30(金)にすくすくスクラムに参加してきた。

今回はなぜか前説的なLTをやらせてもらえることになっていたので準備していった。
が、開始準備に手間取ったため、LTが割愛されて本編がスタートすることになった。

悔しいので、slideshareにあげた資料をブログで公開する。
http://www.slideshare.net/KeiOgasawara/ss-9509007

経験上、朝会は毎日やることが重要だ。
名前から「朝」を強調しているようだが、朝にやることにこだわるよりは、毎日やることにこだわるものだ。

不勉強なので、朝会がもともとScrumでいうところのDailyScrumを訳したものなのかは知らない。
が、僕は朝会ではなくてDailyScrumと呼ぶほうが好きだ。特に導入時は。

もしもDailyScrumを訳したものならば、朝会という言葉は、「朝やる」というニュアンスが強すぎるかもしれない。

そのために、導入当初では
・フレックスタイムの職場では朝は人が集まらないからやらない
・予定していた朝の時間にメンバーがあつまれなかったからやらない(昼や夕にはやらない)
という状況が引き起こされることもあったので、個人的には、特に導入時の名称は朝会ではなくDailyScrumのほうを使うと良いと思う。

重要なのは、「朝」ではなくて「Daily」であることだ。
毎日、継続的に15分という短い時間を効果的に使って情報共有をすることを訓練し、実践することがDailyScrumだと考えている。
そして、効果的なDailyScrumをつづけることが、チームをつくる基礎になるよ、と言いたかったLTだった。

あと、会社の社員募集もしたかった。(一部の方にはお話できたけど。)

場の進行は、かいちょーが仕切ってくれて助かった。
今回はなにかと準備不足で、発表資料を直前まで見ることができなかったにも関わらず、会を進めながらスライドを先読みして進行してくれた。

まさにアジャイル、とかいうとあらゆる方面から怒られそうだけれども、その場で最善を尽くそうという姿勢は大事だ。

なによりワークショップが盛り上がったのは、参加してくれた人たちが積極的にしてくれるからだ。
毎回、思うことなのだけれどもすくすくScrumに来る人たちは、その場を大事にするというか、その場をよくするために自分で何とかしよう、と考える主体的な方が多い。

だから、少々、進行や場のセッティングが拙くても、良い場ができてしまう。
本当にありがたい事だ。

と同時に、それに甘えないようにしたい。

LTをやってみてかんがえたこと

9月 18, 2011

最近、Lightning Talks(以下、LTと書く)という催しで話す機会があった。

きっかけは、僕が裏方を務めた勉強会でLTのトーカーを募集したところ、トーカーが集まらなかったことだ。
自分が言いだしっぺの企画の勉強会のコンテンツが成り立たないのは困る。
なにより「人に話してくれ」と図々しくもお願いしているのだから、自分もその輪に加わらないのは無責任すぎる、と考えてやることにした。

それまでは、普段からLTの誘いを受けても「人前で話すのは苦手なので」と断っていたので、僕は多くの人前ではじめてLTをやることになった。
その準備は結構、大変なものだった。

エンジニアという職種でなくても、見栄えの良いスライドを作り、中身のある話を、多くの人の前で、聞き取りやすい言葉と声で話す、という経験は稀有だ。

僕の作ったスライドはすべてが文字の簡単なものだったけど、内容を考えることをふくめてスライド作りには半日程度はかかった。
スライドを作ってからの練習時間は2日間で40〜50分程度は取ったと思う。

たった5分のLTのために結構、時間と労力を割く必要があることが、自分でやってみてわかった。

この初めてのLT以降に、関西でも懇親会の最中にLTをやってみて、いくつか思ったことがあるので書いてみる。

ちなみに、上記の勉強会では周囲の方々の協力もあり、自分を含めて4名でLT大会を行えることになった。
お話いただいた方には、非常に感謝している。

◯はなすのは楽しい

懇親会などのお酒がはいった場では特にだけど、LTは楽しい。

お酒を飲んでいる場合は、気持ちが大きくなっているから自信をもって話しやすい。
また、周囲もかならノリがよくて、好意的に自分の話を聞いてくれるからだ。

お酒のあるなしに関係なく、LTの良いところ、というか、やりやすいところは「質問なし」ということだ。
良くも悪くも言いっ放し、という点が資料を作りやすくしてくれるし、話しやすくしてくれる。

少々、論理的な構成が悪くても変に突っ込まれたりしない。
だから、いろいろ考えているんだけど、ちょっとモヤモヤしていることでも実験的に発言したり、その場で「言いたい」とおもったことを発言しやすい、というメリットがある。

人前で話すことは勇気がいることだ。
失敗したらはずかしいし、だからLTをやる、ということにはすこしばかり気持ちのジャンプが必要だ。

ただ、元来、人間は話したがりだと言われるし、自分の言葉を好意的に聞いてくれる人たちがいる場で話す、という経験ができるLTのトーカーは楽しいと思う。

◯頼まれたら断らない

慣れれば時間はかからないのかもしれないけど、上記の通り僕がやったときはスライド作りを含めて準備には最低、5,6時間はかかった。

勉強会の裏方をやっていると、お話をしていただきたい方に「こんなテーマで話してください」などとお願いすることが多い。
それは同時に勉強会のための準備をお願いすることで、大変なことをお願いしている、という自覚があった。

と同時に、社内勉強会などで自分が資料を用意して話す、という経験は何度がしているから、大変さを理解しているつもりだった。
しかし、それはやはり「つもり」でしかなかったことに気付かされた。

普段、顔を合わせない人たちの前で話をするということは、ストレスもプレッシャーもあるため、準備も念入りになる。
心理的には作業量的にも負荷の大きなことをお願いしているのだな、と改めて思い直した。

そして、勉強会でお話をすることを快く了承してくれる人たちは、オープンマインドで素晴らしい人たちなのだな、と感謝したくなった。

なにより、お願いを断らない人たちがいるからこそ、勉強会を含めた実践者たちの知識を共有するコミュニティが活性化しているのだということも改めて認識した。

僕はなにかについて深く話せるスペシャリストではないのでお話を頼まれることはない。
とはいえ、LTであれば多少は話せることは分かった。
なので、勉強会で講師を引き受けてくれる人たちを少しは見習って、LTを頼まれたときは断らずに引き受けてみよう、と思うようになった。

◯価値を生み出しているか

ただ、断らずに引き受けてみよう、とは思うものの、自分がLTをすることにどれだけ価値があるか、というのは考えたいと思う。

上述したけれども、LTはとくにお酒が入っていると好意的な雰囲気の中で話せるし、その経験は心地よい。
でも、自分が楽しいだけでは、聞いている人にとって価値があるとは限らない。

もちろん、聞いているすべての人にとって価値がある話など、LTに限らず難しい。
とはいえ、LTでも「どんな人」に「どんな行動をとってほしいか」など、テーマや目的を意識して話すことが重要だと思う。

話し手だけが楽しい、というLTをやることに僕は魅力を感じない。
もちろん、話し手の満足を見出すのがLTだ、という意見もあるかもしれないが。

ちなみに僕はあまりLT自体を聞いた回数は多く無いけれど、「面白くない」「無価値だな」と感じたLTに出会ったことはない。
ある人の視点や考えを聞くことは、それだけで無条件に新鮮で勉強になるのかもしれない。

ただ、自分がLTをやるときは、自分の話が誰にとって、どんな価値があるのか、聞き手のことを中心に考えて話したい。

LTに限らず、なにか新しいことをやると勉強になる。

※以下、2011/09/20に追記
TLを見ていたら僕がこのエントリで言いたかったことがずばり言われていた。
こんな長いエントリを書かなくても、問題意識をもっている人は核心をつくシンプルな言葉をもっている。