DevLOVE HangerFlight - Snow Barrage - でFearless Changeについて話してきました。
「ブログに書くまでがDevLOVEです。」大事な事なのでもう一回、「ブログに書くまでが D・e・v・L・O・V・E です。」。講演の中でも2回言ったので、書くよー。
いやー、月食きれいでしたね。東京にいられて良かったです。そのきっかけになってくれたのが、DevLOVE HangerFlightでした。先ほどのエントリの冒頭に、僕は福井に引っ越したと書きましたが、この度「何でもいいから東京に来て話してよ」といわれたので、それだったらFearless Changeの話がDevLOVEに必要だと思うのでさせてください、と提案してこのセッションをやってきました。
DevLOVEで学んだ事を現場 で広めるための48の戦略 をFearless Changeから 学ぼう
48の「戦略」としたのは「パタン」と呼んでもピンと来る人はそれほど多くはないだろう、と思ったからです。あと、当日紹介したのは8つだけです。だからタイトルは釣りですすみません。
今回紹介した選んだパタンは下記の8つです。これらは、組織に新しいアイディアを広めるために最初に必要になる考え方です。
- Evangelist - エバンジェリスト
- Just DO IT - とにかくやってみる
- Test the Water - 味見をする
- Innovator - イノベーター
- Ask for Help - 助けを借りる
- Just say thanks - 感謝を忘れず
- Time for Reflection - ふりかえる時間
- Step by Step - 一歩ずつ
ここに書いてある項目を眺めて、こう思いませんでしたか？「なんかエバンジェリスト以外当たり前の事しかかかれてないな？」って。そうです。当たり前のことなんです。でも組織に新しいアイディアを広められている、と言う声がそれほど多くないのはなぜなんでしょうか？僕が思うのは、当たり前の事でもやれないことってあるよねっ、っていう良く聞く話しか思い浮かばないです。(ただいま2:20。明日になってなんか気づいたら書こう。)
今回のDevLOVEのふりかえりセッションは、結構このセッションと同じ事を扱っていた気がしますし、@sato_shiさんが、その本、読みたい、とおっしゃってくれたのが印象的でした。社長さんなのにね。トップダウンでやろうとしても上手くいかないと嘆かれていました。そう、社内に変化を起こすには、トップダウンもボトムアップも関係ないんです。セッションでは言わなかったけど。
たぶん誰かを巻き込んで変化するためには、そこには「楽しさ」みたいな内燃しやすい燃料を注ぐ必要があるように思う。ゲーミフィケーションなんて分かりやすい例。
DevLOVEに来る人は、現場を変えるために参加する人が結構いるんじゃないかと思ってやってみました。今年、Fearless Changeの著者の一人のリンダさんにお会いできたのは、本当に自分の考え方を変える出会いでした。あの本を書けるような人は、やっぱりどこか違う。Energizeできうる人は、たぶん「自分」よりも「人のために」エネルギーをさける人なのだと思った。否定せず、うまく気持ちを盛り上げ、相手に内燃させられる燃料を注げる人。それがEnergizer。僕もそうなれましたかね。あの時リンダさんに自分が分けてもらったエナジーを、少しずつセッションに参加された方に渡したつもりです。みんなの現場が現場のみんなにとって少しでも良くなるように、頑張っていきましょう。
このセッションは自分一人では出来上がりませんでした。DevLOVE裏方兼本読部の@_oppyさん、本読部で配布したペーパーの翻訳をされている@kawagutiさん、48のパターン名の概要翻訳をされている@yattomさん、DevLOVEの@papandaさん、そして参加してくださったみなさま、どうもありがとうございました。
DevLOVE Spring Bomb 2011をまとめてみた
このエントリはちょっと実験してます。
モジュール指向勉強会でソースコードリーディングを行いました。
先日8/23にDevLOVEモジュール指向勉強会が開催され、一コマ担当しました。その時の資料を公開します。
モジュール指向勉強会-コードリーディングを始める前に-
View more presentations from Hiroki Kondo.
資料の中でソースコードリーディング前に、モジュール化の必要性について話しました。ぶっちゃけていうと、5人で半年の開発案件くらいだと、複数のモジュールに分割する必要なんかないです。日本のソフトウェア開発プロジェクトの少なくとも5割は5人プロジェクトらしいので、すぐにモジュール化を求めているプロジェクトはそんなに多くないんじゃないか、と思ってます。
ただ、そうはいっても世界に視野を移すと、順調にソースコードが増え、システムがどんどん複雑になっています。そのため、アプリケーション層のモジュール化が求められています。これはJavaに限った話ではなく、他の言語、Rails3や、RequireJSとJuicerなんかでもモジュール化を向上する取り組みが行われています。もっと言うと、他の分野のシステムでもモジュール化が進められています。複雑さを軽減させる枠組みとして、分割統治を採用するのは、コンピュータの世界ではよく採用されています。モジュール化はその方針でとりうる一つの形なのです。
さて、実際のソースコードリーディングですが、今回はJAMCircleの中の、ボード定義のエクスポート/インポートを行うクラスを題材にしました。このクラスは、利用ケースがそれほど多くない、と思ったので、TDDでクラスを書き始め、気づいたら一つのクラスとするにはちょっと大きくなりすぎたクラスです。考えようによっては別のモジュールにクラスを移すべきだと感じていました。なので、今回題材に取り上げ、どうやってモジュール分割していくのか、体験する事を題材に進めました。
資料の見方や、ソースコードについて説明し、やってみると、結構みんな手が動きません。後々聞いてみると、構造や振る舞いだけではなく、実際にどう使われるのか、ユースケースを最初に話を聞きたかった、という声が多く有りました。説明が不足してすいませんでした。分からないなりにも手を動かしてみると、解決への糸口に気づく事が有ります。なので、分からない事に気づくため、とりあえず手を動かし、なんでもいいから書いてみるとよいでしょう。
ソースコードを読んだ後、みなでどういう構造にしていったらいいか、意見を交わしました。結構違う視点の話が出てきて面白かったです。出力形式を拡張しやすいよう、ZipFileを継承してみるのはどうだろう、とか、VisitorパターンとStrategyパターンを採用してみるのはどうだろう、とか、他の人の視点がみられて良かったです。
質問への答えをつらつらと書いておこう
@nobusueさんのエンタープライズOSGiのセッションであった質問に対し、自分なりに答えたい事がいくつかありました。当日は@nobusueさんのセッションだったので、首を突っ込むのもなんだかな、と思ったんですが、改めて考えると、知っていたり、やっている事はいろいろあるので、ここで述べさせて頂きます。
モジュールの開発の権限を開発者ごとに分けたい
誰でもモジュールが触れる状態だと、既存のモジュールに意図しないコードが混入し、モジュールの情報隠蔽が行えず、結局うまくモジュール化を保てないのでは？という質問がありました。そもそもソースコードとモジュールは切り離せるので、開発するモジュールとリポジトリを別々にすることもできるし、モジュールに対してコード署名をつけてあげれば改変できないので、解決できると思った。Eclipseの例でまた恐縮なんだけど、最近Eclipseがリリースしているプラグインにはコード署名が着いていて、改変してもそのまま使えない形になってます。コード署名をつける話は、OSGi SpecのSecurity Layerで書いてあったようななかったような。
HELP ME!やります。
なんと。DevLOVE FusionでHELP ME!をやることになりました。
いよいよ今週なんです。土曜日にお時間がある方。ぜひいらしてください。
DevLove2008Bridgeに行ってきたよ!
あまのじゃくなおいらは、レポート書いてください！って言われてないイベントのレポートをまず書くよ。
12/17に港区某所でDevLove2008Bridgeというイベントが密かに行われていました。と言っても参加者は全部で100人越えていたらしい。一角のイベントですね。
僕は読書会のトラックにいました。読書会はアジャイルプラクティスとアジャイルレトロスペクティブの2冊を対象にしたものでした。が、実際は本を読んでいない人でも楽しめるものに仕上がってました。
前半のアジャイルプラクティスセッションは、「みんなの現場にあるできている習慣、できていない習慣を見つけよう」ということで模造紙を二つのエリアに分け、最初の5分間を使ってみんなでペタペタ付箋をはりました。で、時間が来た後は一つ一つの項目を読み上げて、共感するものがあればその付箋にドットをつけていました。(ドットをつけるのは最初なかったんですが、やってて何だか物足りなくなって、あ、そういえば共感してるものに正の字つけてるなぁ。と思って提案したら受け入れてくれた。スタッフの竹本さんありがとう！)
後半のアジャイルレトロスペクティブセッションでは、アジャイルレトロスペクティブにかかれている555とフィルタリングを使って前半の「できていない習慣」で一番話題になった「ノウハウの共有」をするにはどうしたらいいか、を考えてみました。
555はまず、5人の人でグループを作り、紙を5つの枠が出きるように折り曲げます。そして5分間問題について考えてみた結果を一番上に書き、隣の人に渡します。隣の人はそのアイディアをもとにアイディアを考え、書き終えたら右の人に渡す…。というのを5回繰り返せば計25のアイディアができあがります。今回は時間がないので3人の人が3分の時間を使って、ノウハウを共有するアイディアを3つ出してました。
その後フィルタリングを行いました。フィルタリングは全体でいくつか評価軸を出して、その中から4つ、かけるべきフィルタについて話し合って決め、一つ一つのアイディアが当てはまるかどうかを見ていく手法です。
残念だったのは、フィルタリングは時間が短くて、雑になっていたところでしょうか。「みんなの意見は案外正しい」という話もありますが、最初からフィルタリングをみんなで行うのではなく、各々が評価軸ベースでフィルタリングを行い、そこから議論をした方がよかったでしょうね。今回は声の大きい人が決めてしまったように思います。(時間がなかったのでしょうがないでしょうけど。)
で、これって実はメタな視点で眺めてみると、コンテキストの共有していない、違う現場の人の間でKPTをしていたんじゃないかということに気づき、驚いたんですよ。papanda氏他DevLoveスタッフすげー、と。
目的は「レトロスペクティブ(ふりかえり)を学ぶ」ということだったわけですが、「最初に付箋であるテーマに対してペタペタし、書いたことについて説明する」ということはそれだけでその集まりへのコミット感、参加しているよ感を高める効果があるんですね。コンテキストを共有していないが故、話せることだってある訳ですし。(例えばうちの現場では困った人がいてね…的な話など)
今回初参加でしたが、顔見知りの方もちらほらいました。このイベント自体がBridgeになっていたんです。スタッフのみなさま、良いイベントありがとうございました。
