ヒビノログ

KANさんのおよそ3年半ぶりのオリジナルアルバムが届きました。
全9曲入り。

アルバムのブックレットでは、曲ごとに違ったイメージカラーが
割り当てられているんですが、その通り内容もホントに色とりどりで、
KANさんの音楽の世界の幅広さが存分に入ってます。
みんな買えっ。

以下、全曲レビュー（の予定）。
Read the rest of this entry »

いま仕事を一緒にやっている会社の方からの紹介で。

初版が2000年の5月ということで、ITバブルっぽい空気とかミレニアム云々のくだりがところどころに出てきたりするけど、今でも十分に読める。

構成が「創造（企画）」「売り込み」「実行」「退場」の４つに分かれていて、それぞれのフェーズでどう考え、どう動けば、「すごい」プロジェクトになるのか。読む側のココロを掻き立てるような文体で書かれている。

• 勢いほど強いものはないが、勢いほど萎れやすいものもない。
• 最大の敵はぐずぐずすることで、最良の友は締切である
• 美しくないものは、なにかが間違っている
• すごい！きれい！革命的！インパクト！熱狂的ファン！
• つまらぬ喧嘩は買わず、誹謗中傷は聞き流す
• 真剣に遊ぶ
• プロジェクトを口に入る大きさに分ける
• テスト⇒修正⇒再テストを電光石火で繰り返す
• 会議はどんなに長くても15分。議題は「この24時間に起こったこと」「今日やるべきこと」

アジャイル開発の考え方にも通じるところが多々あるなぁと思ったり。

Tracの日本語パンフレット的なものを作りました。

Trac説明資料（Shibuya.trac OSC2010-Spring版）

海外の、特にオープンソースソフトウェアの日本語の情報については、基本的には自力で検索するなどして調べる必要があることが多いです。

好きでやる分にはそれでいいのですが、Tracのようにプロジェクトの見える化を促進するようなツールの場合、プロジェクトに関わるすべての人たち（様々な立場、様々な技術レベルの方々）にもわかってもらわないと意味がありません。

ということは、敷居ができるだけ低い方がいい。

Tracがどういうものか聞かれたとき、あるいは導入を提案するとき、今までは実際に画面を見せながら説明してたのですが、紙の資料があった方が話が早い場合がしばしばあり、もどかしさを感じていました。

今回、OSCでShibuya.tracのお手伝いをするにあたり、ちょうどいい機会だと思ったのでTracの説明用の資料を作ってみました。OSCで実際にブースに来た方々と話すうちにいくつか修正したいところも出てきたのですが、ひとまず公開してみます。

何かありましたらコメントやTwitterでお知らせいただければ。

Trac説明資料（Shibuya.trac OSC2010-Spring版）

あとは簡易マニュアルみたいなものもあるといいんですけどねー。
次回以降の課題ということで。

オープンソースカンファレンス2010 Springで、tracのユーザーグループであるShibuya.tracのお手伝いに行ってきました。

オープンソースカンファレンス2010 Tokyo/Spring

1日目はセミナーがあったりして、特に午後は途絶えないくらいのお客さんが
訪れたようですが、2日目はそこまでではなかったです。
ブースの場所がちょっと残念でしたねー。

とはいえブースに来てくれるのは、現状の仕事の状況やプロジェクトの進め方に何らかのストレスを感じていて、もっとうまいやり方は無いだろうか、と前向きな悩みを持っている方々ばかりで、Tracの持つ機能について興味を持って話を聞いてもらえました。

以下のような話題が多かったかな、と思います。

• Tracって何？
• Tracは既に使えるけどこういう機能は無い？
• MS製品と組み合わせて使いたい（ExcelとかMSProjectとか）
• TracとRedmineとの違い

ビッグサイトや国際フォーラムなどで、展示会スタッフとして自社製品を説明して勧めるような経験は何度かあるのですが、ああいうのとはまた違う感じですね。

Tracがきっかけではあるけれど、同じ悩みや考えを持つ人たちと、現状からより良くするにはどうすればいいか一緒に考えるような、そんなイメージ。

お客さんとの話や、同じくスタッフとして参加されていたかぬさんやゆしさんとの雑談の中でいろんな気づきがあって、とても有意義な一日を過ごせました。皆さまに感謝します。

今回のために作成したTracの説明資料については後ほどアップしたいと思います。
⇒公開しました。

第11回すくすくスクラムに行ってきました。
今回は「ユーザーストーリービギンズナイト」、講師は角 征典さん。

後でまとめたい気もするけど、ひとまずメモを垂れ流しておこう。

• 要求定義で困っていることは？
  進めるにつれて要求が変わる、知識が顧客と作る側で違う、とか。
• スクラムの要求定義は「要求＋ビジネス価値」で考える。
• ユーザーストーリーは３幕構成。
  「（役割）として（性能・機能）が欲しい。それは（ビジネス価値）のためだ」
  ⇒このあたりは「アジャイルな見積もりと計画作り」のおさらい的な。
• 不足分は対話で埋めていく。「言った言わない」にならない土壌作りが大事。
  ⇒簡単なようで難しいけど、やっぱり越えなきゃならない壁。
• 3C（カード、対話、確認）
• 役割のロールをできるだけ詳しく分けるとよい
• ストーリーカードがすごく多くなったら？
  ⇒ストーリーより粒度の大きい「エピック」のまま置いておく
• 「全体は部分の総和ではない」
  ⇒いくつかの機能とか要求に気を取られてると、俯瞰する視点が無くなるときがどうしてもあるんだよね。意識するようにはしてるんだけど。
• 現状どんな不満があるのか？⇒中心的な欲求を探ること。
• 対話的ストーリーを。要求を洗練させていく。
• 質問内容もメモする
• 要件定義を行なう方法として以下のようなものがあるよ
  インタビュー、アンケート、観察、ワークショップ（ストーリー記述ワークショップ）
• （経験的に）ユーザーインターフェース設計は前倒しに行なわなければならない
  ⇒これは同意。何は無くともまず画面を見たがるお客さんはとても多い。
• INVEST
  I:非依存、N:交渉可能（命令ではない）、V:価値、E:見積もり可能、S:手ごろな大きさ、T:テスト可能（＝完了可能）
• 価値はバランス。それはちょうどポテトに付けるケチャップのようなもの。
  少ないのはNGだけどとにかく多けりゃいいってモノでもない
  ⇒これは上手い例えだなぁと思った。
• バグはその場で直す。そうすることで品質を作り込んでいく。
• ユースケースとの違いは？⇒ユーザーストーリーは３行で書けるよ
• 着手したらすばやく作る。

ほかにも参考書籍の紹介とか、部と部の間に挟まれていたちょっとした小話とか、今回主題だったユーザーストーリーのこと以外にも、ホントに収穫の多い勉強会だったです。ああいうしゃべりができるようになりたいなぁ。