「塹壕よりScrumとXP」読書メモ (2)

昨日に引き続き「塹壕よりScrumとXP」の読書メモです。自分用なのでまとまっていません。かっこ内は自分の感想です。

スプリント間のコミュニケーションについて

• 「スプリント情報ページ」をつくり、何が起きているかを明らかにする
• URLをメールし、紙に書いて貼り出す
• デモの予定も知らせる
• 「何が起こっているかわからない」と言わせない
• (徹底した情報公開。エンジニアのマインドセットも変更が必要そう・・・)

スプリントバックログ

• スプリント計画ミーティングと、最初のデイリースクラムのあいだにScrum Masterが作成する
  • (この日は遅くなるね！)
• スプリントバックログを書くには、壁のタスクボードがよい
  • (Excelでいろいろ試したあとでの結論らしい)
• ホワイトボードは埋めないほうがよい
• 付箋はテープで貼らないと落ちる
  • (これ、前に id:DiscoveryCoach さんに教えてもらった！)
• タスクボードの要素
  • Not Checkout: スプリントの作業前ストーリと、そのタスク。
  • Checkout: 作業中のタスク。
  • Done: もはや誰の作業も不要なタスク。全タスクがDoneになったストーリーはDoneになる。
  • Unplanned items: 計画外アイテム (?)
  • Next: つぎのスプリントに含めるストーリー？

時間切れにて中途半端ですが、今日はここまで。

「塹壕よりScrumとXP」読書メモ (1)

こんど Henrik さんの CSM を受講するので「塹壕よりScrumとXP」をちゃんと読んだ。

はじめに

• Scrum はフレームワーク。どうやるかまでは教えてくれない。これはぼくの戦争体験談だ (!!)

プロダクトバックログ

• 実現したいストーリーの集まり。Scrum でいちばん重要なもの
• 重要度は一意になるようにつける。あとでPOがソートできるから
• PO (顧客) の言葉でわかるように書くことがだいじ
  • (俺は実装するだけだから、みたいな人ばかりだと無理ってことかな)
• PO が重要度を決め、チームが見積もりを出す。逆はやっちゃだめ
• Excelが顧客にやさしいときもある。ツールの選択は柔軟に

スプリント計画ミーティング

• スコープ、重要度、見積もりという３つの変数について話しあう場
• POが参加してくれない問題をどう解決する？
  • わかりやすく説明して説得する
  • 代理人をたてる
  • 参加できるまで延期する
• 内部品質と外部品質
  • 外部品質はユーザにわかるもの。使いやすさ、操作性の良さなど
  • 内部品質はユーザには見えない。コードの質、テスト結果など
• 外部品質はスコープとして扱える（＝交渉できる）が、内部品質はできない
  • スコープとして扱うと、保守性が下がり、かえってコストが高くなる
  • 例：「これ応急処置でやっちゃおう」
  • POはこのことを学習してくれる
• ミーティングは短く終わらす。タイムボックスをからだで覚える
• スプリントの最適な長さはいろいろ試して決める
  • 決まったら固定する
  • 著者のチームでは3週間だった
  • 長さが決まると快適になってくる。リリース日についても悩まない
• スプリントのゴールを決めるのはむずかしい
  • でも、ないよりはまし
  • 「どうしてこのスプリントを実施しているのか？」をつねに考える
• プロダクトバックログ→スプリントバックログ　への移動
  • ストーリーの大きさでスプリント中にやれる事が決まる
  • だから相対見積もりがだいじ
• スプリントに含めるストーリーが何かはチームが決める
  • POではない
  • 含まれたストーリーが不服な場合、POは他のストーリーのスコープを変えたり、分割したりして調整できる
  • (外部品質を別ストーリーに移したりってこともあるな)
  • (ここが一番「これ応急処置でやっちゃおう」になりそうなので気を付けないと)
• 見積もりはどうやるか
  • 小さいチームなら直感で決められる
  • 見積速度：１スプリントで完了したストーリーの大きさ
  • 稼働人日×フォーカスファクタ＝見積速度
  • フォーカスファクタは前のスプリントを参考にして求められる
• コンピュータ上でストーリーの洗い出しをやっていると、問題点に気づきづらい
• PCをいじってる人以外は、自分が参加してるという意識を持ちづらくなる
• だからインデックスカードを使うお！！
  • Excelからカードを自動生成する (！)
  • チームがホワイトボードにカードをはる
  • カードは重要度順に並べ、タスクに分割し、付箋をはっていく
  • POがExcelに反映する
• ストーリーごとに完了の定義をきめるのはだいじ
  • 厳密なチェックリストより、直感を重視する
• プランニングポーカー
  • チーム全員がストーリーを理解するのを助ける
  • 相互協力できるようになる
• ストーリーを明確にする
  • ストーリーに対する誤解を避けるには、ぜんぶのストーリーについてちゃんと(POのいる場で)話し合う
  • (わかったふりして飛ばすとそこで躓くのは、よくありますね…)
• ストーリーが小さすぎたり、大きすぎるときは要注意
• タスク分割はWF的に感じられる場合もある？
• Techストーリーについて
  • 直接顧客への価値にむすびつかないけど、やらないといけないこと。例えばCIサーバの構築とか
  • 通常のストーリーに組み入れられないか検討してみる
  • 無理そうならTechストーリーを作成。(POは編集できない)
  • Techストーリーの実施によってどのようなメリットがあるのか、POにきちんと説明する
  • POがTechストーリーの重要度を理解できるなら、判断してもらうのがベスト

うーん、盛りだくさんだー。（つづく）

超いまさらですが RubyKaigi2011 に１日だけ参加した感想です

超いまさらですが、下書きが発掘されたので。
今年の 7/16〜18に行われた RubyKaigi2011 に１日だけ参加しました。RubyKaigi にはずっと来たかったので、終わる前に来られてよかったです。
以下、個人的な感想ですが、メモがわりに残しておきます。

• SIerのなかのRubyistが考えるべきこと 素晴らしい講演。グッときました。
• アーロンさんの基調講演。境界についてのたくさんの問題提起。オープニングに相応しい引き込まれる内容でした。道場movieに大受け。
• 「アジャイルサムライ」買えた！「7つの言語、7つの世界」も。matz さんのサイン一番乗り。
• 地下の AgileUXD がとてもおもしろそうでした。試みも、作っているものも。
• 闇RubyKaigi では勢いあまってLTドタ応募してしかも gdgd でごめんなさい。
• 個人的にとても嬉しかったのは休憩時間にかくたにさんが 7月6日の DevLOVE の感想を述べてくださったことです。Rubyコミュニティにはああいった場は少ないから良かったと。ありがとうございます、励みになります。
• IRCでの同時通訳がすごかった。本当にすごかった。
• スタッフの皆様、お疲れ様でした。素敵なイベントを開催してくれてありがとうございました。

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

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

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

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

みんな悩んでいる

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

懇親会でのお話

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

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

まとめ（になってないまとめ）

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

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 さんにしつつ、こんなことをやりたいですという話をしたような気がします。はっきりいって緊張しすぎて何を話したか覚えていないのですが、大筋では最終的なイベント内容とずれていなかったような気がします。
たぶん自分の思いとしては、好きな Ruby で 4tate した人の話が聞きたかったのでした。

わたわた

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

かいさい

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

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

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

無数の開発プロジェクトがあるように、開発の現場に
眠るノウハウや定石もまた、無数に存在するはずです。
これらの経験が、活かされることなく、プロジェクト完了とともに
埋葬されるに任せるのは、あまりにも甲斐の無い話だと思いませんか。
では、具体的にはどうすれば体験を活かすことが出来るのでしょうか。

ということで、鷲崎さん・羽生田さん・本橋さんによる、「パターンマイニング」実践ワークショップを通じてその方法を学ぼう、というのが本イベントの趣旨でした。
ワークショップは「協調型マイニング」という手法で行われました。以下、個人的なメモです。誤り等ありましたらご指摘下さい。

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

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

協調型マイニングとは？

• 数名一組でパターンマイニングを行う手法

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

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

協調型マイニングの実践

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

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

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

感想

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

ソフトウェアパターン

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

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

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

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

大きな課題

• 日本のシステム開発、どうなっちゃうの（和智さん）
• フューチャーセンター について（野村さん）

問いかけと話し合い

1. システム開発の課題って？

• 「ユーザ or 開発者の言葉がよくわからない」
• 組み込みハードを作っているが、ソフトウェアの人と話しが通じないという悩みがある
• 業務システム発注をしているが、仕様を伝えても理解してるのかしてないのかわからず、あとでトラブルになる
• 仮想アイドルが流行ったとき、CGを学ぶ若者に制作を頼んでもイメージがうまく伝わらないことがあった。数値で言えば伝わるが…

2. どこのコミュニケーションがうまくいってない？

• ユーザも開発者も、すべて！
• ユーザ側の意見をとりまとめる人がいないとうまくいかない

3. システム開発にどんな夢がある？

• システムを通じて社会を幸せにしていきたい
• ユーザと開発者の共同作業としていきたい

DDD について（和智さん）

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

DDD と組織論（野村さん）

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

質問タイム

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

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

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

個人的な感想

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