読者です 読者をやめる 読者になる 読者になる

アジャイルサムライ読書会(湯島道場)に参加しました。

7月27日に湯島で行われた アジャイルサムライ読書会 湯島道場 に参加してきました。読書会の詳細については、リンク先にわかりやすい解説がありますのでぜひご覧ください。

アジャイルサムライ−達人開発者への道−

アジャイルサムライ−達人開発者への道−

…といっても、当日は残り10分足らずという状況での駆け込み参加。道場の皆さん、バタバタしていてごめんなさい…。しかしそんな短い時間でも興味深いお話を聞けたので、メモしておきます。

みんな悩んでいる

こうした道場に来る方々ですから皆さんアジャイル開発に興味を持たれているわけですが、やはり共通の悩みとは「どうやって導入するか」のようでした。お客さんを巻き込めない、まわりが無関心…
しかし、そんな中でも悩みを一人で抱え込まず、こうした場で共有することで第一歩が踏み出せるだろう、というお話がありました。たしかに、一人で悩んでいても始まりません。
悩みを共有できる、読書会のような場は貴重だと改めて感じさせられました。

懇親会でのお話

懇親会でもいろいろといいお話があったのですが、思い出せる限りで書いてみます。

  • Manage It ! を並行して読むといい感じ。どちらも実戦系の内容だから
  • SIで元請けの下にいくつも下請けがいると牽制しあってチームがつくりづらい。ぶっちゃけ(チームづくりにその構造が)邪魔という話もあるが、プロジェクトの目的を共有することで足並みを揃えられるかも
  • アジャイル=PANDA(Poor And No Discipline Agile) ちゃんと理解しないままアジャイルという言葉がひとり歩きするのは怖い
  • スカイツリーを先端からも作れるのがソフトウェア開発(自由な発想!)
  • 勉強会にいるすごい人とそうでない人の一番の違いは、申込フォームの参加するボタンを押せるか否か

まとめ(になってないまとめ)

アジャイルサムライ、まだ7章までしか読めていませんがとても良い本です。ふつうの本ではなかなかお目にかかれない「プロジェクトのはじめ方」をはじめ、ソフトウェア開発の奥義をとってもわかりやすくかつ濃い内容で説明してくれます。実践したくなるヒントが多く詰まっている本だけに、読書会の存在は重要だと感じました。
開催してくれた @ShiroKappa さんをはじめとするスタッフの皆様、ありがとうございました。次回は定刻に来る or 早めキャンセルを心がけます (滝汗)。

Manage It! 現場開発者のための達人式プロジェクトマネジメント

Manage It! 現場開発者のための達人式プロジェクトマネジメント

DevLOVE HangarFlight Ruby編「あなたの話が聞きたい。」のこと

きょうから RubyKaigi ですね。行かれる方はお気をつけて。
さて、去る7月6日に RubyKaigi Advent Calendar の一部として DevLOVE HangarFlight - Ruby編「あなたの話が聞きたい。」 を開催しました。詳細はリンク先の DevLOVE 公式ブログを見ていただくとして、ここでは開催に至るまでの経緯とかを書いてみようとおもいます。

はじまり

  • 1月ごろに @bash0C7 さんから RubyKaigi Advent Calendar を DevLOVE でやりたい!というお話があった
  • でも、@bash0C7 さんは RubyKaigi の準備でいそがしい
  • DevLOVE の人だれかやらない?
  • ・・・(手を挙げる)!
  • それじゃ @kakutani さんに紹介するよ

という流れがあって、今年のデブサミでたどたどしい挨拶を @kakutani さんにしつつ、こんなことをやりたいですという話をしたような気がします。はっきりいって緊張しすぎて何を話したか覚えていないのですが、大筋では最終的なイベント内容とずれていなかったような気がします。
たぶん自分の思いとしては、好きな Ruby4tate した人の話が聞きたかったのでした。

わたわた

自分のはっきりしない思いが形になるまでは、わたしの力不足もあり、かなり時間がかかりました。なんとか最終的には extreme なダブルイベント開催となりましたが、6月に入るころは本当に開催できるのか、プレッシャーで気が気ではなかったのを覚えています。w
ダブルイベントの先輩はこちらです。DevLOVE Birthday! 〜RubyKaigiの帰り道に生まれしもの〜
わたしが余りにもワタワタしていたためか @DiscoveryCoach さんが会場やスピーカの手配、ダイアログファシリテーターとしてのご参加など大幅に手助けしてくださり、@bash0C7 さん、@papanda さんにも助けられつつなんとかアウトラインをつくっていけました。みなさん、ありがとうございます。わたしの人生のほとんどは他人の手助けでできています。
ただ、最初にこのイベントの開催でご相談させていただいた @yotii23 さんには、なかなかまとまらずご迷惑をかけてしまいました…。うまく進められなくてごめんなさい。
また、@changeworlds さんにはわたしが Redmine プラグインをつくったときの話が聞きたい!とお願いした際、いろいろと貴重なアドバイスをいただきました。それは彼の講演にもあった「非忠誠の誓い」にもつながる内容でした。あれがなかったら、いろいろな人の話を聞きたいというわたしの思いは折れていたかもしれません。大きな感謝を。
それから、懲りずに見守ってくれたわたしの家族に、最大の感謝をおくります。

かいさい

そんなわけで(どんなわけで)さまざまな方の手助けがあって無事に開催されたわけですが、もう録画の手配ができなかったことが残念でたまらないぐらい素晴らしい内容でした。こうなると、ビデオカメラが欲しくなりますね(!)。ぜんぶの方に謝辞を書きたいのですが時間が・・・!!ひとまず今日はここまで。

DevLOVE 我々は、現場から学ぶ。 〜パターンマイニングの実践〜 に参加してきました

6月23日に開催された「DevLOVE 我々は、現場から学ぶ。 〜パターンマイニングの実践〜」に参加してきました。

無数の開発プロジェクトがあるように、開発の現場に
眠るノウハウや定石もまた、無数に存在するはずです。
これらの経験が、活かされることなく、プロジェクト完了とともに
埋葬されるに任せるのは、あまりにも甲斐の無い話だと思いませんか。
では、具体的にはどうすれば体験を活かすことが出来るのでしょうか。
ということで、鷲崎さん・羽生田さん・本橋さんによる、「パターンマイニング」実践ワークショップを通じてその方法を学ぼう、というのが本イベントの趣旨でした。
ワークショップは「協調型マイニング」という手法で行われました。以下、個人的なメモです。誤り等ありましたらご指摘下さい。

パターンマイニングって?

  • パターンとは、特定の状況で繰り返しおきる「問題+解決」のこと
  • パターンは名のない質(QWAN)を備えている
  • パターンを知っていれば、同じことで何度も悩まなくてすむ(=これ、前にもあった!)
  • パターンマイニングとは「経験」を抽象化して、パターンを掘り出すこと
  • パターンの効果範囲と効き目はトレードオフ。ある状況に特化しているほどよく効くが、適用できる状況は少なくなる

協調型マイニングとは?

  • 数名一組でパターンマイニングを行う手法
  1. パターンを抽出するドメイン(特定の問題領域)を決める
  2. それぞれの成功体験を付箋に書く
  3. 書いた付箋を貼りながら他の人に説明する。このとき、似ている内容の付箋は近くに貼っていく
    • 初期状況、アプローチ、結果
  4. 似ている付箋どうしからパターンを抽象化できないかみる。できそうなら付箋に書いて貼る
    • 状況、問題、フォース、解決、結果
  5. パターン名をつけてまとめ、全員に発表!

最後の「フォース」というのはスターウォーズ用語で、パターンマイニングの肝となる部分だそうです。説明を聞いたときは正直よくわからなかったのですが、つぎのワークショップで明らかになりました。

協調型マイニングの実践

ここからは5人1組となって、実際にパターンマイニングをやってみました。
講師の鷲崎さんより「お題」がいくつか出され、グループごとにそれを選択します。このお題が前項でいう「ドメイン」となります。ちなみに、私のテーブルでのお題は「転職」でした。他にも「勉強の仕方」「通勤」「読書の仕方」などなど。
あとは前項の手順に従ってみんなでパターンを抽出していきます。

貼られた付箋のようす。みなさんの体験を聴くだけでも、かなり勉強になりますね。
スライド説明のときに謎だった「フォース」ですが、ワークショップでの説明によって「この状況、この問題で、なぜその解決を選んだかの理由」だとわかりました。そしてこのフォースを抽出することで、いっけん似ているパターンもさらにブレイクダウンできることが判明したりするのだそうです。
フォースの抽出によって、パターンが真に使えるものに変わるのだな、と感じました。
最後に、すべてのテーブルで結果発表。パターンの名前付けにも個性が。私たちのグループで導出されたパターンは以下のようなものでした。

  • パターン名:めぐりあい
  • ドメイン:転職
  • 状況:自分の将来が不安
  • 問題:新天地を見つけたい
  • フォース:
    • 社内では情報を得にくい
    • 転職エージェントは堅い
    • 社外ならざっくばらんに聞ける
    • コミュニティのことは知っていた
  • 解決:コミュニティで情報を集め、新天地を紹介してもらう
  • 結果:新天地にめぐりあえた

感想

たいへん面白く、そして有益なワークショップでした。これを職場でやってみたらさぞ刺激的でしょう!欲を言えば、他のテーブルの結果が見られるとよいなと感じました。
講師のみなさん、DevLOVEスタッフのみなさん。ありがとうございました。

ソフトウェアパターン

ソフトウェアパターン

ジュンク堂トークセッション「システム開発の未来―システムと組織を同時に変革する―」に参加してきました

2011年6月9日に、池袋ジュンク堂書店 4F 喫茶で行われたトークセッション「システム開発の未来―システムと組織を同時に変革する―」に参加してきました。
エリック・エヴァンスドメイン駆動設計(いわゆる DDD 本)を翻訳なされた和智さんと、フューチャーセンターファシリテータの野村さんによる、参加型対話セッションです。

エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)

エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)

DDD は、ユーザと開発者の共同作業を重要なものとしています。ユーザはしばしば企業であることを考えると、組織変革をテーマにされている野村さんとの対話はとても刺激的なものになるだろうと考え、参加しました。
以下は、わたしの個人的なメモ書きになります。あまりまとまっていませんし、自己流解釈となってしまっている箇所もあると思います。

大きな課題

問いかけと話し合い

1. システム開発の課題って?
  • 「ユーザ or 開発者の言葉がよくわからない」
  • 組み込みハードを作っているが、ソフトウェアの人と話しが通じないという悩みがある
  • 業務システム発注をしているが、仕様を伝えても理解してるのかしてないのかわからず、あとでトラブルになる
  • 仮想アイドルが流行ったとき、CGを学ぶ若者に制作を頼んでもイメージがうまく伝わらないことがあった。数値で言えば伝わるが…
2. どこのコミュニケーションがうまくいってない?
  • ユーザも開発者も、すべて!
  • ユーザ側の意見をとりまとめる人がいないとうまくいかない
3. システム開発にどんな夢がある?
  • システムを通じて社会を幸せにしていきたい
  • ユーザと開発者の共同作業としていきたい

DDD について(和智さん)

  • 「ソフトウェアを作る上で、ビジネスパーソン本当に協力していきたいと思うなら、この本を読みなさい」 by エリック・エヴァンス
  • 顧客のビジネスを理解せよ
    • 顧客の言葉で理解せよ
    • その先にある「モデル」を理解せよ(※顧客がビジネスに対して持っている全体像)
  • ソフトウェアは、モデルに従ってつくれ
  • ソフトウェアは話し合いながらつくれ
    • ソフトウェアは、育てるもの
  • 顧客のビジネス全体のことを考えよ
  • 実装してみるとモデルの矛盾に気づくことがある。ユーザにフィードバックするとよい
  • …という話しは、当たり前のこと。しかし、実践はむずかしい
  • なぜできないのか?
    • 大きなコスト、承認のプロセス(予算、稟議…)
    • それで本当に幸せなシステムができるのか?
  • 開発者が頑張るだけではダメ。ユーザも変わる。
    • 組織に、コミュニケーションを重視する風土が必要

DDD と組織論(野村さん)

  • いまの和智さんのお話、組織論とどう関係ある?
    • ゲーム会社では DDD が当然となっているが、システム開発ではできないことが多いと聞き、何か問題があるのではと思った(参加者の方)
  • 自分自身(野村さん)がこうかなと思ったことをお話します
    • 自社でナレッジマネジメントの研究をしていた。ラベル付け替えではなく、本当のビジネスにしようとした
    • 組織の中の「価値」ってなんなのか?
    • IDEO からは「チームがもっとも大事なことを知っている」というやり方を学んだ
    • しかし、承認のプロセスに阻まれてしまった
    • 会社を変えないと、いいものを世に出すこともできない。→フューチャーセンターへ繋がる
  • フューチャーセンターをやる
    • ゲーム作りのように普段の仕事をする
    • みんなで参加し、アイディアを出しあって手を動かせば「自分ごと」だと思える
    • 「自社のためだけに(商品を)作っていたら、会社は駄目になる」
  • 新しい文化を持ち込まないとダメ
  • 日常で行っている、そのプロジェクトのやり方自体を変えよう

質問タイム

  • 企業の人はフューチャーセンターになぜ来てくれるのか
    • 空間、ファシリテート、方法論のパッケージを求めている
    • コミュニケーション不全は日本の組織の共通課題(縦割り組織、タコツボ化?)
    • 「暗黙の仮定」を壊さないといけない(納期を守らないとクビになる…とか)
  • システムの一部にならない、と決めた人がシステムを変えていくだろう
    • 隣の人がやってるからやる、という人はそのシステムに加担している
    • 辞めるつもりでやる
    • 会社の枠を外して考える。会社のリソースを使ってやろうぐらいの気持ちで。
    • 新しい企業とお会いしたらまず「ゲリラ戦士」をさがしている
    • ゲリラ戦士とは、自分の立場を破壊してでも、組織を変えたいと思っている人
    • 保身しながら会社を変えることはできない
    • ゲリラ戦士を褒めてくれるのは、ゲリラ戦士だけ。でも、トップは見ていてくれるかも…?
  • 会社を変えるための、もうちょっと安全なヒントをもらえませんか?
    • 社長をフューチャーセンターに誘ってみる
    • 「あなたの知識が必要なので、フューチャーセンターに参加してくださいますか」
    • 反応ないなら諦めた方が…
    • 社長の限界は、会社の限界(!)

まとめ - システム開発の未来

  • 基本はコミュニケーション。つかう人と一緒に考えていく
  • ソフトウェアデベロッパは、社会変革者でないといけない

個人的な感想

DDD と組織論は切っても切り離せないものだと感じつつも、それを切り開くための壁は高そうだとも同時に感じました。なので、あえて違う道で DDD を含めた「システム開発の夢」を実現できないのかなぁーと考えてしまいました。
そして、会社ってなんのためにあるんだろうなあ、とも。
和智さん、野村さんを始め、ジュンク堂および翔泳社のみなさま、そして DevLOVE スタッフの皆さん、ありがとうございました。

DevLOVE HangerFlight Spring Bomb に参加しました

昨日の HangerTalks の熱が冷めぬまま、本日 2011/5/21 は DevLOVE HangarFlight - Spring Bomb - に参加しました。
詳細は Togetter をご覧ください。以下は、感想を。

講演の感想

当日は裏方メインで、講演は、やきとりいこと鳥井さん @yotii23 の「はったり活用法 - より高く飛び,そして帰還するために」のみ(司会として)聴かせていただきました。
仕事でお客さんと話すとき、自分の説明できないことを聞かれて慌てるシーンはよくありますが、そのときのベストプラクティスを「はったり」という観点から分析してまとめていて、ちょっと、このユニークな分析は他にはないのではないか、と感じました。また、そのときにはったりを活用する理由が「保身」ではなく「お客さんと良い関係を築き、よいサービスを提供するため」というのも素敵でした。
個人的には、かつて小さい受託システムで、要件定義から運用保守まで全部担当した時のことを思い出しました。。。最新の技術動向に、お客さんのほうが詳しかったりするとかなり冷や汗が出たりしますよね(ははは・汗)。
最後に、DevLOVEからの無茶ぶりを快く聞いていただき、ありがとうございました!!

イベント雑感

昨日の HangerTalks につづき裏方としての参加となりました。おもしろそうな講演ばかりで耳がダンボになったりしつつも、この場を作っている充実感というのもあり、本当に不思議な体験をしているなあと。いま、我々が体験していることは一体何なんだ? わかりませんがすごい疾走感です。
今回も参加者の方においしいお菓子をいただきました。いつもありがとうございます m(_ _)m

さいごに

スピーカーの皆様、参加された皆様、ありがとうございました。裏方の皆さま、お疲れ様でした。みなさまのフライトの成功を心より願っております。

おまけ

会場で見かけたいろんなでぶっち。

DevLOVE HangerTalks に参加しました

2011/5/20 に開催された DevLOVE HangerTalks 〜空を飛ぶのに、翼の1本や2本折れたところで。〜 に参加しました。
今回は、DevLOVE スタッフである「こしば」さんと「ちゃちゃき」さんのお二人よりお話を聞きつつ、参加者全員で対話を行うというものでした。詳細については、Toggeter をご覧ください。

イベントの雑感

お二人の講演が、いつになく心にしみる内容でした。自分の中の自分にとって重要な問題を、自分の考えで解決していく話。まさに "あなたの話が聴きたい" を地で行く、すばらしい講演でした。最後の参加者ダイアログも含めて。
お二人の、印象に残った言葉です。

  • 希望をなくしたら死ぬしかない。希望さえあれば生きていける。(こしばさん)
  • 今よりよい未来を、大事な人のために。(ちゃちゃきさん)

主観による紹介LTをしました

今回は、お二人のお話の前の「紹介LT」群にまじって、こしばさんの紹介LT をさせていただきました。
といっても、私の「こしば歴」はまだ半年。このようなご紹介をする事におこがましさも感じましたが、それでも、これまでこしばさんと接していて少なからず感銘を受けた部分について、余す所なく盛りこんでみたつもりです。似顔絵が(見ないで描いたという言い訳をもってしても)似てなさすぎる点はご容赦ください。

Developers Summit 2011 のこと

なかなか書けなかったのだが、少しだけ。2/17〜18 に開催された Developers Summit 2011 に参加したときのことを。
デブサミは、今年が初参加である。2010年になるまで私はそもそもこうしたイベントや勉強会などに参加したことがなかった。いや、カンファレンス系のものに出たことはあったのだが、たんなる傍観者の域を出ず、けっきょくすべてのスキルは自習以外では身につかないと考え、興味自体を持つことがなかった。
しかし、2009年のリーマンショックを機会に、IT勉強会に参加。その後、とりつかれたように参加しまくり、あれよあれよというまに、2010年の末にはとうとう DevLOVE スタッフの仲間入りをさせていただいた。
そして KDI 野村さん @nomutaka と共におこなう参加型セッションの企画、帆立て (#4tate) のこと、デブサミ配布しおり の作成。
企画を通して、わたしは徐々にデブサミがどういうものであるのかをおぼろげながらも知ることになった。主催者である岩切 @kohsei さんの想いの強さ、9回もこの奇跡のイベントが続いていること、@papanda さんをはじめとするすでに参加した皆さんの、デブサミに対するそれぞれの想い。
私はそんな想いを感じながらの初参加となった。セッションは以下の 6 つしか聞けなかったけれど、幸せな参加であったと思う。

どれも、素晴らしいセッションだった。地豆の思わず使ってみたくなる素敵な紹介とその場リリース、豊富な経験に裏打ちされた質疑応答が圧巻の「今そこにあるScrum」、世界の広大さを感じたLT大会、容赦ない内容の濃さで攻めるRIA、腹をくくった「アジャイル」の胸が熱くなる話。すくすくスクラムの OpenJam も楽しかった。
そして、最後の 18-B-7 で参加者のみなさんの掲げた色札を数える「野鳥の会」をしながら、わたしは考えた。デブサミは、開発者という人々の「想い」に焦点を当てる、稀有な場であるのだと。
この場を創りだしたスタッフの皆様と、スピーカーの皆様、当日お会いして話をしたすべての参加者の皆様に、感謝。
デブサミを終えて、わたしは今、自分のまわりに横たわる「なぎ」の海で、帆を立てて航海することができるかを模索している。この日を無駄にはしたくない。