Archive for the ‘コミュニティ’ Category

境界は大切だ、と根拠を示して説明できる経験を得られる1年にしよう

1月 3, 2015

この投稿は、DevLOVE Advent Calendar 2014 「越境」の58日目(たぶん。。)の記事です。

境界は越えようと思うとき邪魔になるのだけど、これがあるから居心地がいい場が生まれる。
境界がない世界は、本来、交わらないほうがよい人たちや価値観が交わることがある。

たとえば、僕が10代のときからアニメおたくと呼ばれる人たちがいたり、ルーズソックスをはくヤマンバギャルいたりした。
ただ、こういう人たちは僕の日常に姿を表わすことのない人たちで、彼女ら彼らが何をしているか、など興味がなかった。
もちろん、彼ら彼女らも僕の生活には興味がなかっただろう。
だから、お互いのコミュニティは独立が保たれており、似たような背景と価値観、そして言葉が通じる人たちだけの関係性だけで生活が成り立っていた。
この環境は、居心地がいい。
自分の価値観が大きくゆらぎ、不安にさらされることは少ない。
自分にとって不快なものをみて、イライラしたり、その結果として毒づいたり、することも少ない。

最近、クソリプというのがちょっと話題になったけれども、これも境界が曖昧になっているから発生する。
自分の知り合いだけが読むことを前提とした文章が、境界がないばかりに背景も価値観も言葉も異なる人たちに消費されることで起こる。
つぶやく方もからんでゆく方も、境界を意識していないから、自分の表現がどのように消費されるかわからないし、表現されたものをどう消費してよいのかわからなくなる。

だから、そこに境界が存在し、あるコミュニティがあり、そのなかで暗黙に共有される背景や価値観がある空間があると心地よいのだ。

しかし、いまの心地良い人間関係や環境に浸りつづけていると、その状態に飽きる。そして、焦る。
このような状態でいいわけがない、と考えるようになる。
ぬるま湯につかっていることがわかるし、そのぬるま湯がいつの間にか熱湯に変わって自分がゆでガエルになるという危機意識もでてくる。

だから、昨年末、居心地が良いながらも、焦りがある場からぬけだして、働く場を変えた。
さまざまな人たちを師として、またさまざまな現場に学ぶこと目的として。
しかし、自分が学ぶだけでなく、自身がその人たちと現場に価値をもたらすことも目指して。

そして、前職ではいわゆるWeb系のベンチャー企業に勤めていたが、今回はSIを主な事業とする会社に務めることにした。
これも単一のWebサービスを行っている会社にいると、どうしても代わり映えのしないドメイン、技術、メンバーでの開発になりがちだったので、
プロジェクト単位で、異なるドメイン、技術、メンバーと取り組める事業を営んでいる会社を選択した結果だ。

境界を越えたら、そこには異文化と異なる知が存在する。
境界を単なる邪魔者として考えるのではなく、異なる価値を醸成するものとして境界をみつめて、越境することを楽しみたい。

ということで、明日は59日目、rei_mさんです。
今日が抽象的な話になったので、具体的な経験談や抱負を聴かせていただければ嬉しいですね。
よろしくお願いします!

ふりかえりのふりかえり

1月 26, 2014

昨年末、会社自体のふりかえりを会社のメンバー全員(6名)で、ちょっとぼやかした感じのKPTを取り入れて、1年分の

  • 良かったこと・維持したいこと
  • 悪かったこと・やめたいこと
  • チャレンジしたいこと・やりたいこと

の洗いだしと総括をおこなった。
ちなみに1年分だったの4時間程度の時間がかかった。

ふりかえりという名称でこうしたことを行うメンバーもいたのだけど、概ね好評で、
「こんどは、もっと短い時間で頻繁にやりたい」という意見ももらった。

この意見を聴けたので、ふりかえりは有意義であったのだとかんがえているのだけど、自分なりの反省点もあるので書いておきたい。
書いてみたら、いわゆる言い尽くされた注意点なので、基本は大事、ということだったりする。

付箋は強粘着を使おう

壁に貼った付箋が、ハラハラと落ちてくると、議論がとまる。
落ちた付箋を壁にはるのは、ふりかえりにおけるムダな時間の1つだ。

今回、参加したメンバーには、

  • 良かったこと・維持したいこと
  • 悪かったこと・やめたいこと
  • チャレンジしたいこと・やりたいこと

を付箋に書いて1人、1人発表してもらった。

今回は、100円ショップで売っている付箋を利用した。
100円ショップの付箋でも、テーブルをつかってやるのなら問題はないが、壁に貼り付けながら行うと粘着力のなさが問題になる。
1番最初に発表した人の付箋は、5,6人目の人が発表している際に粘着力がなくなり、ハラハラと落ちはじめる。

せっかくたくさんの時間をふりかえりに利用するのだから、付箋を貼りなおす時間など貴重な時間を利用してはいけない。
強粘着の付箋はたしかに高いが、見返りは十分にある。

お手本を用意しておこう

とくに付箋の書き方、まとめ方、については、事前に説明をしておくと議論がやりやすので、付箋の書き方についてお手本があると良い。
付箋を使う目的は2つある。
1つは自分の思いついた意見を端的にまとめる、という自分のメモにすること。
もう1つは自分の意見を端的に他の参加メンバーに伝える、という他の人への説明書きにすること。

どんな人でも自分のメモとして付箋を利用することに戸惑う人はいない。
また、自分の意見のメモとして記憶を保管する目的なのだから、利用方法を間違えることはない。

しかし、付箋はその後、意見を発散・収束するためにも利用するので、他の人が読んで意味が伝わるものであることが必要だ。
この方法は、あらためて参加者にお願いしておかないと無視されがちだし、実際、どのように書いたら良いか、という疑問もでてくる。

自分が慣れているとそのつど説明してしまえばいいや、と端折りたくなる部分なのだけど、最初にちょっと手間をかけえておくと、議論も意見の整理にも便利な付箋ができあがり流れによどみがなくなる。

もちろん、参加メンバーが付箋やKPTのような方法に慣れていれば、この項目は不要だ。

こまめにやろう

これが最大の反省点で、ふりかえりは年に1度などと言わずこまめにやる。
ふりかえりは、自分の仕事の仕方や他の人の仕事の仕方、会社のビジネスの状況や顧客の状況など、自らの行動を見直す時間を作ることだ。
そして、行動を見直すことにより発見や反省を行って学習を深める時間だ。

学習の時間はなるべく多く、そして、機会は頻繁であるほうが望ましい。
状況は1週間もすれば変化しているし、変化にはなるべく早く対応したい。

毎日やるか、1週間毎にやるか、毎月やるか、開催頻度は、それぞれが置かれている状況によるだろう。
ふりかえりを行うと約1時間から2時間×人数分の時間がかかる。

この時間を投資して得るものがあるか否か、ここはメンバーをふくめて考えると良いだろう。

ちなみに、毎日ふりかえりを実施したらこれは有用だろうか。
こう聞かれたらぼくは、「有用だ」と答える。
とくに設立したての企業では、仕事や現状にたいするメンバーの考え方や気持ち、状況についてよく知ることができるからだ。
ただ、会議室を用意して、付箋に書き込んで、という方法は時間を取り過ぎるので、別の方法をとるほうが良い。

ぼくは、個人的に手帳を使って簡単にやっている。

おまけ

ちなみに事前に下記のようなメールをおくった。
送ったことでメンバーに良い効果があったかは定かではないが、自分自身の考えが明確になる。

明日のふりかえりについて、遅くなりましたが目的やプログラムの共有を致します。

みなさまには、今年を総括するにあたり、みなさまには下記について準備、ご協力をお願い致します。
・自分がなおしたい!とおもう問題を整理して持ち寄る
・自分がやってみたい!とおもう課題を整理して持ち寄る
・手軽にとれる食事やお菓子
普段はづらいことなどもあるかと思いますが、
あたらめて意見を集める場として、積極的に意見をいただけますと、うれしいです。

目的:
ミッションと方向性を再確認する
会社の良い所と悪い所を共有する
来月からできることをはっきりさせる

アウトプット:
来月からやることリスト

スケジュール:
13:00 – 13:10 開始の挨拶
13:00 – 13:50 あらためて会社のヴィジョンを考える
休憩
14:00 – 14:50 良かったこと、維持したいことの総括
休憩
15:00 – 15:50 悪かったこと、やめたいことの総括
休憩
16:00 – 16:50 チャレンジしたいこと、やりたいことの総括
16:50 – 17:00 終了の挨拶

現場と現場をつなぐ現場

11月 11, 2013

このエントリーは『DevLOVE Advent Calendar 2013 「現場」』の3日目の記事です。
(更新日付は11日になっておりますが、12日の0時に更新しております。。。)

自己紹介
oppy(おっぴー、ぴーおつ)と呼ばれるWebエンジニア兼COO。それぞれ、経歴は2年半と1年未満で未熟。
Webのアクセスデータを収集、解析してマーケティングなどに活かすWebサービスを渋谷で作っている。
好きなモノはビールとアート。
好きな言語は、JavaとJsとGroovy。

自分にとっての現場
DevLOVE現場甲子園では1回の裏に発表をさせていただいた。
ふりかえっても終始ありきたりな話になってしまい、せっかくお話を聞きに来ていただいた方にはもうしわけないな、と思った。
こういう場では話す側、つまり自分がいちばん勉強ができるのであって、今回も1つの学びを得たのでそれを書いて僕のアドベントカレンダーとする。

発表の際に僕が取り上げたのは、現場と経営の対立と協調だった。
よくわからないが現場と経営はよく対立するものであって、対立することが当たり前と捉えられている。

で、そもそも現場と経営ってなんだろう、という定義に立ち返るとむずかしい。
Devlove甲子園では、
現場:人が手と頭で価値創造する場
経営:お金(の按分)で価値創造する場
と定義してお話をしたんだけど、これだと「人事」や「総務」というお仕事はどこに入るのかわからない(という状態ではなした)。
ま、文系、理系のわけでいうと運動系や芸術系の学問はどっちにはいるのか、という問題に等しい。

DevLOVE現場甲子園で話し終わったあと、ある方と話していた気づいたことがある。
あたりまえなのだけど、エンジニアにはエンジニアの現場があり、経営者には経営者の現場がある。
エンジニアも経営者も、自分の現場で手と頭を使って全力をつくしているわけだ。
ようするに、現場と経営が対立しているのではなく、エンジニアの現場と経営者の現場が対立することがある、という状況の理解しかたが正しい、ということだ。

現場同士の対立を解消するには何が必要だろうか。
ここの答えは変わっていない。
つまり、お互いの現場で「なぜ」を追求しつづけるということだ。
「なぜコードを書くのか」「なぜ会社を運営するのか」「なぜ働くのか」こうした自らの行いに関する根源的な欲求にたいする問いとその答えに忠実な行動が会社というコミュニティを活性化させる。

根源的な欲求に対する問いは、自身の行動を深める。
自らの根源的欲求かが満たす事が出来る場で行動をするとき、人は無駄なく集中した一貫した行動で大きな成果をあげる。
これは、だれでも少しは経験があるはずだ。
たとえば、面白くてたまらない本を読んでいるときなんかはそうだし、きっと、部活なんかでもそんな経験がある人も多いと思う。

しかし、この「なぜ」は人によっても立場によっても異なる。
そして、現場が違い、見るものが違い、同じものを見ても解釈が異なり、それゆえ行動の優先順位が異なる。
そのためにお互いの現場で個別最適化がはかられ、対立が生まれてくる。

しかしながら、この対立、一方はAに向かい、一方はBに向かおうというする意志が引き起こす緊張こそが各々の現場を活性化させる。
お互いの現場の個別最適化が引き起こす緊張が上手く統合され、同じ目的に向かっている状態を生み出すことができているかいないか、
これが対立しているか、協調していないかを区別するものであって緊張は常に保ち続けるものだ。

エンジニアとして、COOとして2つの現場を知る僕の役割は、「翻訳」だ。

個別最適化することなく、複数の現場が活性化するには、CEOが示す統一的なビジョンにもとづいた対話が不可欠だ。
しかし、お互いの現場を知らない人たちの言葉は往々にして、相互理解をうまない。
相手の思考や思いへの無知から、相手の考えや価値観を否定することも少なくない。

これは正しい緊張状態ではなく、対立を生みひいてはお互いを尊重する、という言い訳とともにお互いから遠ざかるだけだ。
だからこそ、お互いの現場の言葉が通じあうような場がつくれるように、双方の言葉を翻訳しお互いの言葉が通じする素地を作ることが必要になる。

まずは定性的なデータの共有と解釈を戦わせるところからが始まりだと考えている。
理想的には徹底した議論がおこなわれることだが、まずは、相手の言葉を聞く機会をつくるところからはじめよう。

相互理解の苦労を経ないまま、下手な協調にいたりうまれる慮りは馴れ合いを生む。
お互いが遠慮をして、居酒屋のテーブルに1つだけ残された冷めた唐揚げのように、心配事や問題を扱うような現場同士の関係性ではなく、
冷めて美味しくなくなる前に、熱いうちに自分が平らげてしまう、そんな関係がきっとお互いの現場を活性化する。

エンジニアの現場と経営の現場、どちらも未熟ながら知った人間の現場は、会社というコミュニティに多数ある現場をつなげ、活性化させる現場だったのだ。
そんな気づきをDevLOVE現場甲子園で得た。

ぼくの現場からは以上です。

次の人へ
DevLOVE現場甲子園では誠実かつ安定感のあるまとめ力は主砲級、4番バッターにふさわしい活躍されていました。
TheHiroこと伊藤さんです。
「If your smeeeeell what’s TheHiro is cooking!!!!!」(野球関係なし

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

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

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

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周年、おめでとうございます。
そしてありがとうございます。
来年もきっと素敵なデブサミが開催されると信じています。

HangerFlight〜SnowBarrage〜のおすすめセッションをご紹介

12月 4, 2011

来週末にせまったDevLOVEのHangerFlightの僕的なお勧めセッションを紹介したい。
どれも僕自身や僕の現場を変えてくれそうなお話が聞けると期待している。

まだどのセッションに参加するか迷っている方、参加自体を迷っている方に参考にしてもらえたらうれしい。

<第3機・家永さん>
森の賢者と称される家永さんによる、開発現場のパタン・ランゲージの入門編。
パタン・ランゲージの詳しい内容は下記をご参照いただくとして、エリック・ガンマのデザイパターンのアイデアの原型となったものでもあり、現場への知識への伝播や現場からの学びを得るための有用な方法だ。
http://www.atmarkit.co.jp/aig/04biz/patternlanguage.html

現場を前進させるために、人びとがもっている暗黙知を伝播させることは有効だ。
もしもあるスペシャリストの暗黙知を上手く伝播できるのであれば、現場にいる人たちの成長に大きく寄与するはずだ。
自分自身の学びを活かして現場を変えたい、また現場から新たな学びを得たいと思う人には有用な学びを提供してくれると思う。

家永さんは、昨年もCI(継続的改善)をテーマにお話をいただいている。

僕はこのお話を聞くことができなかったのだけれども、非常に評判が良かった。
その会から約一年、久々の登場でどのようなお話が聞けるか、僕は非常に楽しみにしている。

<第7機・こんぴろさん>
本年のAgileJapanの基調講演を行ったリンダ・ライジングが書いた『FearlessChange』に基づいて、自分の現場を変える方法を参加者で考えるセッションになる模様。
僕がこんぴろさんとお会いするきっかけになっとなったのも『FearlessChange』という本だ。
当時、前職で開発手法としてScrumを導入しようとしていた際に、「Scrumを取り入れたいなら、『FearlessChange』を読みなさい」と紹介されたのが、『FearlessChange』の読書会だった。
2年ぐらい前のことだ。

定期的に開催される読書会に参加しながら、本で読んだ内容やディスカッションした内容を試した結果、事業計画に携わるぐらいにはなった。
事業計画には、開発の将来としてアジャイル開発やRuby、HCDの必要性を盛り込んで発表したと思う。

結局、その後に会社を離れてしまったので道半ば、やり切ることはなかった。
でも、ヒラの自分が、組織の将来を決める計画にたずさわることができたのは、この読書会と『FearlessChange』からの学びを活かした結果だと思う。

自分の現場を変えたい人は、ぜひご参加を。

<第12機・アラさん>
アラさんはMIRAIGENGOというWebサービスに関わるプログラマだ。
http://miraigengo.com/

このMIRAIGENGOというサービスは、体で表現するエスペラント語をコンセプトに作られたサービスだ。
しかも面白法人カヤックの面白ビジコンで最優秀賞を受賞したサービスでもある。
どんなサービスなのかは、下記のURLで動画をご覧いただきたい。
http://matome.naver.jp/odai/2131201594030590501

くしくもHangerFlightの日がサービスのβ版リリース日になる。
講演はその記念ともなるものだと思う。

僕らはプロダクトを開発し、リリースすために悪戦苦闘している。
僕らとは少し立場が異なるものの、独自のWebサービスをリリースに携わり悪戦苦闘したアラさんのお話はきっと僕らの現場にも役立つはずだ。

魂に熱が欲しい方、ぜひ、サービスリリースをやり遂げたプログラマの話を聞きに来て欲しい。

知らず知らずに内に自分の視点や行動は固まっているときづく@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回も開催してみたい。

自分が提供できるもののない勉強会には行けないよね

11月 4, 2011

最近、人が開催している勉強会に参加することが減った。

時間がないとか、自分に刺さるテーマの勉強会がないとか、自分が開催する側に回っているほうが楽しいとか、様々な理由はありそうだが、一番の理由は、「参加しても提供するものがない」と感じているからだと思う。

「提供するもの」といっても圧倒的な知識とか経験だけを意味しない。
そもそも勉強会なのだから知らないことがあって当然だし、明日、翌週の仕事が少しでも前進させるために学びに行っているだから知識や経験の有無は関係ない。

むしろ、知識や経験がないゆえの質問や疑問や悩みも立派に「提供するもの」になる。
とはいえ、それを自分のなかに抱えたままでは意味はない。
その場で質問したり、話したりして参加者と共有することで初めて提供したことになる。

昨今、23区内に限ってもたくさんの勉強会が開催されている。
講師も内容もかなり充実している。
しかも無料だ。

そのため、勉強会に足が運びやすくなったし、参加へのハードルも低い。
加えて、同じような問題意識や悩み、興味を持ったエンジニアと出会うこともできる。
だから楽しい。

しかし、そういう場になかなか足が向かない。

とにかく自分がその場に行くことで「何かプラスな影響が与えられそうだな」と思えない場には足を運ばない。
せめて自分がよい質問ができる、と感じられない場には参加することがためらわれる。

だから、他の人が開催する勉強会から足がとおのいているのは、自分のなかに人に分け与えられる材料がないからなのだと思う。
そう考えると、自分が仕事や自主的な活動でインプットを行うことを優先したくなる。

自分がちゃんとしたものを提供できそうだと思うまで、勉強会には足を運ばない。
そんな態度のほうが、自分にとっても勉強会という場にとってもプラスになる、そんなふうに思っている。

話を聞くだけで質問も出来ず、ただ知り合いや話の合うエンジニアに会いにゆくためだけに参加する。
自分がそんな参加者になるのは、勉強会という場にはマイナスになる。
自分にとっても時間の無駄だ。

とここまで書いたけど、前にもこんなことを書いたような気がする。

なんでこんなことを書きたくなったのか考えてみると、参加したいな、と思う勉強会はあるんだけど、その勉強会にでた自分が提供できる何かをもっていると思えないから参加を悩んでいるからだと思う。

さて、どうしようか。

11月12日(土)に勉強会をやるのでぜひ参加してほしい

10月 29, 2011

たまには、予定している勉強会の宣伝的なブログを書きたい。

11月12日(土)の午後まるまるいっぱい使って勉強会をDevLOVE、YASS合同の勉強会を開催する。
テーマは「エンジニアのキャリアを考える」というものだ。
http://kokucheese.com/event/index/19568/

YASS(Yet Another Seven Seas)は、「もう一つの七つの海から「ITの新たな航路を見つけ出す」」というコンセプトで活動されていて、市原さんという方が主催されている。

エッジの利いた技術力を武器に生きてゆくのエンジニアの理想だとしても、その道を貫くのは簡単ではない。
俗にSIや受託開発会社とよばれる会社は、就職氷河期においてもともとエンジニアを目指していたわけではない人間を大量に受け入れたと言われる。

この背景から「エンジニア」と名乗っていても技術を極めて生きる、ということが幸せにつながる人たちはあまり多くない。
ましてや、「技術的卓越」を標榜するアジャイルな組織に生きることは幸せにつながるだろうか。

また、ゼネコンとも称せられる組織構造のなかでシステムづくりをしてきた結果、エンジニアとして技術力よりも、ネゴシエーションや管理能力が卓越したエンジニアはどのようにいきてゆくべきか。

YASSさんは、こうしたエンジニアの現状を踏まえて、「エンジニアがどのように生きてゆきべきか」を考えるための会をおおく主催されている。

今回は、こうした活動をされているYASSさんと共同で、「エンジニアのキャリアを考える」ことをテーマに勉強会を開催する。
「エンジニアのキャリアをを考える」というと抽象的だけど、「今どんなふうに働きたいか」そして「これからどんなふうに働いてゆきたいか」を考える機会にしたいと思っている。

講師として株式会社ソニックガーデンの倉貫さんとアライドテレシスの梅野さんをお招きして、お二人がどのようなビジネスモデルに携わり、どのようなチームや組織で、どのようなお仕事をされているのか、を話して頂く予定だ。

この勉強会の特徴は、携わるビジネスモデルの違いや組織の違いがエンジニアとしての働き方や生き方にどのように影響するか、を考えられることだと思っている。

ソニックガーデンの倉貫さんは、最近、大きな会社からMBOをおこなってベンチャー企業を立ち上げた方で、一方、梅野さんは国をまたがった開発拠点をつくるという難しい仕事に挑んでいる方だ。

倉貫さんはソニックガーデンというベンチャー企業で組織と言うよりもむしろチームをつくっており、梅野さんは、日本を含めて世界横断的に24時間眠らない開発組織をつくっているという違いがある。

またビジネスモデルも異なる。

組織やチームは、ビジネスモデルによって決まる。
ビジネスモデルとは稼ぐための枠組み、ルールだ。
ルールが変われば成果を出すために最適な組織の形をも変わる。

そして、組織が変われば、その組織を構成するメンバーに対して求められるもの、果たすべき役割もかわる。
役割が変われば行動が変わり、結果、働き方も大切にする価値も変わる。

そのためエンジニアとしてどのように働くのか、どのような能力を磨くのか、自分が所属する組織によって決まる。

お二人のお話は、エンジニアとしてどのようなビジネスモデルに関わると、どのような組織で、どのような能力が求められながら働くことになるのか、を考える良いきっかけになるはずだ。

なにより、最後に予定されているディスカッションには、講師の倉貫さんと梅野さんも参加して下さる予定になっている。
講師の話を聞くだけでなく、聞いた直後に講師とディスカッションをする機会は奏多くないと思う。
話を聞いた直後の疑問に講師の経験や考えを深堀りできるまたとない機会になると考えている。

また、キャリアについて同じように悩んだり、行動していたりする人たちと話しあう場にもなる。
と言うかそういう場にしたいので、自分の仕事の仕方について悩んでいる人、考えている人に参加して欲しいと考えている。

僕自身、今年の7月に転職した。
結果、エンジニアという肩書きは一緒でも仕事の内容も時間もかわった。
仕事で求められることもかわったし、評価されることもかわった。

くわえて、住む場所もかわったお陰で生活もかわった。

ほとんど変わっていないのは、コミュニティ活動に時間を使っていることぐらいだろう。
自分の経験や考えたことは、まだ文章にできるほどまとまっていないけど、これを機会に皆さんとお話しして考えをまとめる機会にしたい。

会場費などが割り勘でお金がかかるけど、中身の濃い会になると思うのでぜひ参加して欲しい。