Hatena::ブログ(Diary)

papandaDiary - Be just and fear not. このページをアンテナに追加 RSSフィード Twitter

2012-02-18

はてなブログへ移る

まだ過去のダイアリーデータを移行できないものの、はてなブログに移ります。

The Dragon Scroll

2011-12-18

HangarFlightと、自分の話

SnowBarrageを終えて

 今年のDevLOVEも、HangarFlightで締めることができた。特に、今回は怪我人が出ることはなく

平和に終えることが出来た。多くの裏方の尽力があって企画と運用をやり遂げることができた。

また、年末の忙しい時期にも関わらず、多くの発表者の方々に協力を頂いた。結果として、今回の

HangarFlight SnowBarrageは、DevLOVE過去4年の中で最もたくさんの方々が集まる時間になった。

こういう場を、一人の人間によって、一方的に作ることなんて到底出来無い。関わってくれた、

すべての人に感謝しています。ありがとう、ありがとう。

 例によって、当日業で今回依頼した皆さんの発表を聞くことが出来なかったため、年末年始を

動画鑑賞で過ごしてから、改めて1セッション1セッションに込めた思いを言葉にしたいなと

思っている。

 毎度のことだけれども、ややスケールの大きいDevLOVEをすると必ずといっていいほど、

もう2度やれない、という思いを持つ。当日を迎えるだいたい1週間前には自分を呪う。だけど、

本編を終える、締めに取り掛かる頃にはまたこの時間を作りたいと思い始めている。

渾身会を少し離れたところから眺めていると、その思いが強くなっていく。

 願うことは、この日の場と時間が、誰かの次の何かに繋がることだ。その何かが、またDevLOVE

という場に戻ってくるのを迎えるためにこそ、私はDevLOVEを続けている。その先に行くまでは、

まだまだ止める気にはなれない。

桃の木には、桃が成るものだ

 この1年、2年で身辺の大きな変化を続けているため、どこかの時点で自分のことをまとめて

みたいなと思っていた。今回は、自分が発見したことを他の人に伝えたいという気持ちが、

いつもより強かった。自分が企画するDevLOVEで自分が話す、なんてことは今ままで考えたことも

無かった。しかし、今の自分の話はこの時期を逸してはいけないと思ったから。初めて1枠くれと

言ったんだった。

 これは、その時間に映し出されていた挿絵。

 ところが、挿絵を準備していく間に、また、自分の時間の間際をいよいよ迎える段になると、

いったい自分に何が話せるんだろうという思いがもたげてくる。今でも、こうやって挿絵を

めくっていると、本当に何かを話せたんだろうかと思う。

 かつて、私はデブサミやCommunityでたくさんの先達や仲間から果実を分け与えてもらっていた。

美味しい果実も、苦い果実もあった。自分が今ここに、今の自分として居れるのは、その時々に

口にした果実のおかげだ。自分にも成った果実が、他の人に持って行ってもらえたら。

それが、私の感謝のカタチなのだ。

 人にはそれぞれの果実が成るものだと、半ば自分を言い聞かせるようにして、話をした。

そう、桃の木には桃の実が成る。桃から林檎は生まれない。だから、HangarFlightというのは

それぞれの木に成った果実を寄せ合う場所なんだよね。

 話してみると、言葉に仕切れないことがたくさんあった。ひとつひとつ不器用に言葉にしていく

ことしか出来無い。ただ、大切な何かに迫っている感覚だけは、感じられるのだ。

インセプションデッキで植えつけられた前提をあぶりだす

 HangarFlightでの発表でも話したけど、インセプションデッキがあの時あれば…ということに

気づくことがある。例えば、顧客が開発における要求の、優先事項を決めるという話。

f:id:papanda0806:20111218024625p:image

 何が優先事項となっているかは、顧客が中心となって決める。ところが、顧客がその判断のために

十分な情報を集めているという保証は当然ながら無い。判断のために十分な情報を得ているか

確認する、さらに、仮に情報量が不足しているならばそれを補うよう、顧客側に働きかけるまで

開発側が動くことは、なかなか容易なことではない。なぜなら、自分自身で作っている前提

(この場合だと、"顧客は自分が判断するために必要な情報を得ている、という前提")を発見し、それを

揺さぶれるかどうかなのだから。

 ところが、2011年の開発の現場を生き抜く、我々はインセプションデッキを既に手にしている。

インセプションデッキを構築する過程で、このシステム開発で本当に何を優先するべきなのか、

顧客も私たちも含めて、気づくことが出来る。

 最近、ユーザ企業の方と話をしていても、このインセプションデッキの有用性について耳にする。

f:id:papanda0806:20111218024624p:image

 助かった! これで私たちは、ソフトウェア開発において路頭に迷うことはない、と言えれば話は

簡単だが、我々の居るリアルワールドは、本を読みさえすれば明日から使いこなして成果を上げ

られるという程、生やさしい世界ではない。

 実際の案件で適用しようとすると、手が止まることに気づくだろう。あるいは、大コケして手を

出したいと思わなくなるはずだ。インセプションデッキを使いこなすには、相応の練度が必要だと

分かる*1。具体的にはどういうこと?やってみると、分かる。

 とはいえ、状況が変わっているのは確かだ。道具はある。練度を上げながら、探っていこう。

*1:世の中にはインセプションデッキの構築をコーチングしてくれる稀有な会社があるらしいよッ Don't miss it!!

2011-09-22

永和システムマネジメントに入社しました。

f:id:papanda0806:20110922230749j:image

via kakutani


永和システムマネジメントに入社した経緯は140文字では足りないし、それが1200文字になっても

足りなさそうなので、まずは、このあたりでお茶を濁しときます。

大事なことは、私にとってこれから上野で仕事をすることはとてもウキウキで、もう週明けが楽しみ

だってことさ。

海岸沿いのSIerと私

 履歴書を書いていて、思い出したことがあった。

海岸沿いのSIerでデブラブ*1を始めたとき、オで始まりブで終わる集まりの中の人

たちに、妙な嫉妬のような負けん気を持っていて、俺たち(海岸沿いのSIer)だってソフトウェア開発で

名を挙げてやるぜ、なんてことを考えていた。

 ところが、自分の焦点がイマココの現場に移るようになって、

−今なら言語化することができる。僕は、Communityを作りたかったのだ。始めは"会社"の中に作ろうとした。それは一定の成功を収めた。しかし、アウトプットを生み出す行為を共にしないCommunityでは、芯が無くて、いつまで経っても存在として脆いままだ。僕は、自分の居る"現場"をCommnunityにしたいと考えるようになったのだ。だから、 −

だから、会社を境界に分ける意味があまりなくなり(むしろ、他の"現場"の経験や知恵を貸し借りする

という点からは取り払った方がいい)、デブラブはDevLOVEになったし、私は、"海岸沿いのSIer"と

名乗るようになったんだっけ。

*1:社内勉強会として始めたDevLOVE

2011-09-04

学びのプラクティスマップ

先日、とある集まりで出会った方と

「ダイアログは確かに良いものだけど、なかなか次の行動に繋がらないのでは。」

という話をしたところ、確かにそういう面はあるかもしれないとして、なので、

「体験することで、行動に繋がることもあるかもしれない。」

という言葉を返してもらった。

ああ、なるほど、それは昨今よく開かれている「ブートキャンプ」*1を指すの

かもしれないな、と思い、自分たちがどうやって学んでいるのか

整理したくなった。

幸いにして、コミュニティの運営に長く携わっているので、その切り口だと

考え易い。


結果、こういうイメージになった。

f:id:papanda0806:20110904224540p:image

インプットと、アウトプット。机上でやること、実地にやること。

この4つのパラメータの度合いに基づく、4象限で整理してみる。

すると、まず、インプット・アウトプットどちらの面も持ち合わせる

ものがあり、これをインアウトとしてプロットした。


図のとおり、「机上」「インプット」は、本を読んだり、誰かの話を聞いたり

セミナー形式の勉強会もここにあてはまる。

「机上」「インアウト」には、対話、ブレストをはめた。誰かの話を受けて、

そこから自分の考えや見方を出していく。インプット、アウトプットが

同時に起きている。

「机上」「アウトプット」には、文章、ブログに整理したり、勉強会で発表側として

話すことが、ここにはまる。人によってはtwitterのつぶやきも。


また、実地の方は、「実地」「インプット」のところで少し悩んだ。

ここは、何らかの観察、例えば、ライブコーディングを観ること等があてはまる。

「実地」「インアウト」は、インプットとしてのテキストがあり、実際に自分で

手を動かしてそれに倣いながら学ぶ、写経がプロットできる。

最後に「実地」「アウトプット」は、一定のガイド等を足がかりにしつつ、

自分の想像を働かせたり、工夫を編み出しながら、アウトプットを作ること。

例えば、DevLOVEで開催したアジャイルサムライの道場では、インセプションデッキの

テンプレートをインプットに、その場で各自で、コンテンツを作るワークを行った。

「実地」「アウトプット」のイメージだ。


ここで、軸を振り返ってみて、気づいたことがあった。

そもそも机上、実地のメリットとは何だろうか。

実地の優位性は理解しやすい。実践に近い体験をすることで、実践の前に失敗どころを

知ることができる。行為の経験値を積むことができる。

机上の方には、時間的コスト的優位性がある。実地するためには、相応の準備が

必要だが、本を読むなら寝ながらでもできる。もちろん、1人でできることと、

複数人でやることでは、そうとも言えないところがあるので、「人数」の軸も入れた

整理が必要かもしれない。


また、横軸の行為の目的について考えてみると、

「インプット」は、ドメインの知識量の底上げにあり、「インアウト」は、

知識の深掘りにあると言える。何かをインすれば、疑問点が湧く。

それをアウトすることで知識を鍛えていく。

「アウトプット」は、発見にある。実際にやってみて、気付いたことはこの行為での

宝だ。新たに気づいたことの裏付けを、他のインプットに求めるなど、

次の行為に繋がる。


そう、ここにマッピングした行為は1つ1つ独立したものとして考えるべきではなく

まずは知識量の底上げをし(インプット)、誰かとそのことについて話をし(インアウト)、

ブログに整理する(アウトプット)など、行為の連続性から生まれる学習効果を

計算するべきだ。このパタンの組合せから新たな発見が生まれる可能性がある。


さて、この整理が何に役に立つだろうか。

例えば、業務アプリケーションの開発でよくある、「顧客業務の理解」について

行為のマッピングを行ってみた。

f:id:papanda0806:20110904224541p:image

ソフトウェア開発という仕事は、学びの繰り返しで構成されるため*2

どういう目的でどうやって学ぶかの整理は、開発現場で役に立つこともあるだろう。

*3

*1http://d.hatena.ne.jp/t-wada/20091219/p1

*2:もちろん他の仕事でも言えることだろう

*3:各象限で挙げたプラクティスは私が1時間程度で考えたものなので、当然ながら、コンテキストに応じて自分で作ってみると良いと思う。

2011-09-03

コミュニティ内でのコミュニケーションをどうデザインするか。

DevLOVEというコミュニティを始めてから、4周目に入っているのだけど、

長らく、コミュニティ内の交流の場をどう実装するかが宿題になっていた。


DevLOVE LINKというメーリングリストがあるがこれはコミュニケーションになって

いなくて、DevLOVEの開催を告知する掲示板の役割になっている。

DevLOVEの裏方*1仲間と話をしていても、メーリングリストというのは、投稿するのに

それなりの敷居があるらしい。

確かに言われてみれば、見ず知らずの人たちがいるところへ、それなりの

意見を投下するのは、少し腹に力がこもるかもしれない。

それにメールのフィードバックは、テンポが遅い。


コミュニティ内のコミュニケーションの場。最初に手応えを感じたのは、

Yammerだった。

https://www.yammer.com/devloveyammer

Yammerは、楽天でも利用されている社内twitterだ。

楽天様、ロフトワーク様のYammer活用事例The Unofficial Yammer Blog

Yammerのいいところは、その機能の豊富さにある。グループを作ることもできるし、

外部の人も招待できる*2"コミュニティ"を作ることも出来る。タグ付けも、Likeも、

揃ってる。

ところが、DevLOVEではYammerは次第に過疎化した。なぜかだろうか。


人がソーシャルなサービスに費やす時間は、だいたい一定のはずだ。

Yammerだけやっているわけにはいかない。Yammerを利用してもらうためには、

TwitterやFacebookの時間を減らしてもらう必要がある。つまり、それらを駆逐する

ほどの魅力がDevLOVEのYammerに備わっていなければ、振り向いてくれない。

(ゆえに、環境的な制約がかかっていることが多い「社内」においてはYammerは強力だ)


次に、今も検証を続けているのが、Facebookのグループだ。

http://www.facebook.com/groups/devlovepark/

Facebookを訪れる理由は、いくつかあるはずだ。友人の投稿を見るため、お気に入りの

ページを見るため。それらにDevLOVEのグループが紛れ込めば、訪れる機会も増える

はずだ。

いまのところ、Facebookグループは活発にやりとりが生まれている。

ただし、Facebookのグループは本人の否応なしにグループに参加させられる上に、

デフォルトの設定が「投稿があったらメールを受信する」になっていて、活発な

グループだと、大量のスパムを生むことになるので、注意が必要だ。

私もDevLOVEグループを開設するときに、この配慮に欠けた。


コミュニティを運営していると、こういう細かいことを考えることが結構ある。

もちろん、面倒なこともあるけれど、私は元気です。

根本的に、人との関わりが、好きなんだなぁ、きっと。


コミュニティ作りといえば

My quindim went to NAGOYA.

1年前のことだったが、とある事情で東京を離れる覚悟をしたことがあった。

そうなると、DevLOVEをどうするかを、自ずと考えることになる。


DevLOVEというコミュニティは、いろいろな人が船頭役となって活動を行っている。

多様性を保存しながら、結集性も持ち合わせる。相反する状態のバランスを取る

ことに、注意を払ってきた。

だから、パンダが一匹居なくなったとしても、DevLOVEというコミュニティがたちまち

活動を止めることは、ありえない。


ただ、様々な活動は、その躍動と調和を生み出すために、注意を払う必要がある*3

なすがまま、放っておけば良いほど、人の集まりは簡単に成熟しないことを

開発の現場でも、他のコミュニティでも、学んできた。

割れた窓はやがて大きな事件を招くのだ*4


当時のDevLOVEは、大きく3つの活動を行っていた。勉強会の開催と、電子書籍を作る

活動、それからコミュニティで自分たちの活動に必要なサービスを作る。

これらの活動が持続するためには、3人の船頭役が必要なはずだった。

勉強会の開催は、DevLOVEの活動そのものと言っていい。

私は、この船頭にid:quindimを思った。彼は、社内勉強会勉強会という活動を担い、

他コミュニティと共同を張り、現場を前進させるということにとりわけ熱意を持っていた。


結果として、私は東京を離れることはなく、逆に、彼の方が故郷に帰ることになった。

QUINDIMジンジン

7月12日、田町の鳥一代という店で、DevLOVEの有志で彼を送り出す会を催した。

そこで、LTで彼に伝えたように、私は、彼にさようならを言っていないし、これからも

言わない。もちろん、ネットにゆけば彼の言葉を間近で聴くことができる。

ということ以上に、quindimは、いまもDevLOVEというコミュニティの一員なのだ。*5

僕らは、DevLOVE名古屋を開く約束をした。


さて、彼はいつ、外出から戻ってブログの続きを書いてくれるのだろうか。

私はそれを楽しみにまっている。

QUINDIMジンジン


f:id:papanda0806:20110903224839p:image

*1:ところによってはスタッフと呼ばれる人たちのこと。裏方という言葉については http://www.amazon.co.jp/dp/483341919X 参照

*2:Yammerはメールのドメイン単位でクラスタが作られるため企業のメールアドレスだと外部の人はそこに参加できない。

*3:誰か1人が、ではなく、そこにいる誰もが

*4http://ja.wikipedia.org/wiki/%E5%89%B2%E3%82%8C%E7%AA%93%E7%90%86%E8%AB%96

*5:彼からDevLOVEをやめるんだという言葉は聞いてないからね。