nDiki : B6

128mm x 182mm (JIS)

125mm x 176mm (ISO)

A6 と A5 の間の大きさ(A5 > B6 > A6)。

開発 ストーリーカード タスクカード コラボレーション 書き出す ソフトウェアかんばん B判 ポスト・イット ソフトウェアプロジェクトマネジメント 京大式カード 見積もり すごい会議 ポイント ミーティング キックオフミーティング 見える化 A判 コミットメント・リスト エクストリーム・プログラミング シモジマ 社長 KPT コミットメント 仕様書 ホワイトボード

■ 京大式カード

開発にストーリーカードとタスクカードを利用するスタイルを試験的に導入しようと思いシモジマへいって、B6の情報カードを買ってきた。

無地と京大式と2種類買ってみたが、京大式カードってそういえば何だ? 聞いた記憶はあるが。 この罫線の引き具合がポイントなのか?

「知的生産の技術」を読まねばならないかな?

• 知的生産の技術 - 梅棹忠夫

• ソフトウェアかんばん (2005-10-28)
• WiKicker でソフトウェアかんばん (2007-03-01)
• ソフトウェアかんばん「見えない化」 (2006-04-10)
• Google ドキュメントでソフトウェアかんばん (2008-03-30)
• ストーリーカード・タスクカードを導入した開発の成果物を納品 (2005-11-30)

■ 情報カードを使って高速すごい会議

プロジェクトの後期フェーズのキックオフミーティングをすごい会議スタイルで開催。 もろもろの制約条件があって2時間程度しか時間がとれないので、今日はスピーディに進めたい。 幸い参加者はみなすごい会議慣れしていて、結束力もある。

今までのすごい会議では参加者が「各発言時にホワイトボードに書く」という部分に時間がかかっているようなので、今回は買ってきた情報カードを利用してみることにした。

参加者は計4人。

@ 今回の方法

• 「書いてから発表する」にあたりワークシートに書き出すのではなく、直接B6の無地の情報カードに書く。
• 基本的には1カード、1項目にする。
• B6だと(机に広げるには)大きすぎるので適宜切る。
  • 問題点などを書く時は、情報カードを半分に切って書く。
  • 担当分野を書く時は、情報カードを6つに切って書く。

はっ、速い。

今回はミーティングスペースの都合から前半ホワイトボードが使えなかったこともあり、発表はテーブルの中央に情報カードを披露する形で行うようにした。 ホワイトボードに書く手間だけでなく、立って移動する手間もない。

さすがに時間が短いし参加者が慣れているということで、いくつか手順をはしょろうかと思っていたのだが、結局フルセットやって2時間15分で完了した。

巨大ポスト・イットも使ってみたいけれども、コスト的にもスピード的にもカード式もなかなか良いことを実感。

@ 感じたメリット

• 速い。
• そのままカードが記録になる (後の手順で使える)
  • 担当決定後のコミットメント作成時に参照情報として、問題点カードを適任である担当へそれぞれ渡せる。
• 同じ発言を集めて整理できる。担当分野の抽出も非常に効率的。
• コミットメント・リスト作成時には簡単に日付順に並び換え、挿入ができる。

@ ルール化すると良さそうなこと

• 濃い目で太字のペンで書く。
• 字は大き目に書く。
• 手順名(キーワードでも可)を書く(あとでどれかわからなくなる)。
• 誰のカードかわかるようにする(発言者名、イニシャルなどを書く)。

4人で着席してやるならば、情報カードは最初からもう少し小さいものでもいいかもしれない。

• 「すごい会議」2度目 (2005-06-03)
• すごい会議で、どの手順で前のどの手順を参照する? 何を記録しておく? (2005-07-07)
• すごい会議の正しい手順 (2005-07-04)
• すごくない会議 (2005-06-29)
• 「すごい会議」と問題解決のスコープ (2005-06-15)

■ ソフトウェアかんばん

先週金曜日に参加した総会関連のプロジェクトについて KPT 法を用いた評価セッションを実施。

プログラマ間でのコラボレーションが一つの課題になった。 決して悪い状態ではなく比較的いい感じであるのだが、より良くしていこうというわけである。

またこのプロジェクトはリリースを前にまだ開発要素が目白押しということもあり、その辺りの見通しもより明確にして共有したい。

ということで、今回はあらたにソフトウェアかんばんを使ってみることにした。

よく紹介されている方法はタスクカードを「TODO」「DOING」「DONE」というカテゴリ分けされた壁に貼って見える化する方法である。

今回はこれをちょっとアレンジして実践してみることにした。

• B6 情報カードを使う。
  • この大きさだと書くにはちょうど良さそうだが広い壁が必要になりそうだ。
• エクストリーム・プログラミングのように、まずはストーリーカードを作成する。
  • 今回はベースとなる仕様書の機能を実装する形。ビジネスサイドがストーリーカードを作るという体制にはできないので、開発チームでストーリーカードをおこす。
• ストーリーカードからのタスクカードおこし。
  • 時間の関係から、まずは優先度の高いストーリーカードを選んでこれをタスク化する。
  • タスク化済みのストーリーカードは(tなどの)マークをつける。
• タスクカードのカテゴリは「TODO」「DOING」「CHECKING」「DONE」の4つとする。
• 開発者は TODO タスクカードから1枚カードを選んで署名して DOING へ移す。
• タスク作業完了後「DONE」あるいは「CHECKING」へ移す。
  • 「CHECKING」はチームはタスクを受け持った人が作業完了後、チームでチェックをして欲しい時に入れられるカテゴリ。
  • カテゴリ名はこれでいいかな?

まずはこれでスタート。

実装しなければならないストーリーがたくさんあることを直観的に、他のスタッフにも理解してもらえる。社長も「まだこんなにやることがあるのか」とプロジェクトの状況を理解してくれたようである。

今後であるが、以下の点をまだ行っていないので順次実行していきたい。

• イテレーションの設定
• タスクの見積もり
• ストーリーの見積もり
• 全体の見積もり
• 定期的チェックタイムの設定
• 貼りやすいプッシュピンの入手

[ ソフトウェアプロジェクトマネジメント ]

• Google ドキュメントでソフトウェアかんばん (2008-03-30)
• Joel on Software - 必読書 (2008-08-14)
• 京大式カード (2005-10-26)
• WiKicker でソフトウェアかんばん (2007-03-01)
• ソフトウェアかんばん「見えない化」 (2006-04-10)