nDiki : KPT

事後評価セッション すごい会議 会議 ソフトウェアかんばん アイデア 開発 ホワイトボード コラボレーション ふりかえり 朝会 ソフトウェアプロジェクトマネジメント 情報カード 見積もり アジェンダ ミーティング To Do すごい考え方 ガントチャート 情報共有 適応型ソフトウェア開発 プリント 電話会議 キックオフミーティング 2006年 グループウェア メール 会議室 エクストリーム・プログラミング テープ ストーリーカード

■ すごいKPT事後評価セッション

先週納品を終えてほぼ完了したプロジェクトについて、冷めないうちに事後評価セッションを行う。 「適応型ソフトウェア開発」に触発されて去年から主に自分の担当プロジェクトで導入しているセッションであるが、今回はこれにすごい会議の手法と、@ITの記事*1で紹介されていたKPT法を組み入れて実施してみた。

@ 招待状

参加者には、以下の事前準備をメールでリクエストしておいた。

• 「あなたが、この会議で達成したい事を考えておいてください。」(すごい会議流)
• 各評価対象について「3つの成功点(良かった点)、3つの失敗点」を事前に考えてください。 (「適応型ソフトウェア開発流」)
  • スコープ、スケジュール、リソース、欠陥レベル
  • プロジェクト運営
  • コラボレーション (スタッフ間)
  • 個人・チームとして学習した点
  • その他 (開発手法など)
• 問題点については「どのようにすれば〜(だろうか)」のかたちに書き換えてください。(すごい会議流)
• 良かった点のうち Keep のものがあるかご検討ください (KPT法流)。
• 問題点は Problem です。(KPT法流)
• 問題点について「次にやってみたいもの(Try)」が思い浮かんだらメモしておいてください。(KPT法流)
• 問題点に関係なく Try してみたいものがあれば、メモしておいてください。(KPT法流)
• 注意点 (「適応型ソフトウェア開発流」)
  • 良かった点を必ず書いてください。(すごい会議にも通じる)
  • 成功点、失敗点については3つ以上でも構いません (その際は、成功点と失敗点が同数程度に)
  • 特定の個人を批評はいけません。
• 事前に考えたメモを K・P・T 別にA5〜A4用紙各1枚程度ずつにまとめてプリントアウトして持参してください (発表時間短縮のため)。

@ セッション

メンバは4人。 ホワイトボードをK(Keep)・P(Problem)・T(Try)の3領域に分割。

それぞれ用意してきたプリントをマグネットや、テープでホワイトボードに貼りつける。4人分ぐらいならホワイトボードに貼れたし、前に集って座れば字もだいたい読むことができた。

【Keep】まず最初に成功点について各自発表。「うまくいっている」ことから開始するのはすごい会議流で。 次のプロジェクトで Keep しておきたい点について確認しておく。

【Problem】どのようにすれば〜でそれぞれ発表(すごい会議流)。この形式で表現することで、アイデアが浮かびやすくなる。アイデアが出れば ホワイトボードの Try の領域に書き込んでいく。

【Try】あらかじめ考えてあった Try をそれぞれ発表。

KPTの発表が終わったら、今度は Try をコミットメント化していく。 「担当」と「期日」を明確に設定 (すごい会議流)。

@ 完了

合計90分。ほぼ予定時間とぴったり。 事前に書いてきた内容をホワイトボードに書き込まずに貼りつけるだけで済むようにしたためかなり時間が短縮できた。

今までの事後評価セッションに比べて次のアクションが明確になり、コミットメント化した事で実行する可能性が高まった。 成功点・問題点をそれぞれ発表して確認しあう段階までだった過去の事後評価セッションよりパワーアップ。

• すごい会議で、どの手順で前のどの手順を参照する? 何を記録しておく? (2005-07-07)
• すごい会議はじめての全手順(1/2) (2005-06-30)
• ソフトウェアかんばん「見えない化」 (2006-04-10)
• 「すごい会議」2度目 (2005-06-03)
• すごい会議の正しい手順 (2005-07-04)

■ ソフトウェアかんばん

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

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

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

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

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

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

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

まずはこれでスタート。

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

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

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

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

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

■ 乱入OK! コラボレーションタイム

11月末にモノを発送できたプロジェクトの事後評価セッション。 手法は前回と同じくKPT法をとりいれた方法で。

セッションでは「質問したい時に、忙しそうにしていると話かけづらい時がある」という課題があがった。 あ、自分のことね。 忙しいと集中して(あるいは集中しているフリをして)そういう雰囲気を醸し出しているな。

こちらは案外好きな時間に声をかけているのだが、立場というダイオードが入っているのかもしれない。

集中とコラボレーション、どちらも大切。

ということでアイデアとして、時間を決めてその間はアポがはいっていたり極限状況にあったりない限り、チームメンバで御互いに話しかけたら誠実に対応するというルールを作ってみた。 15:00 - 16:00 をその時間に。その日にある程度作業をした後問題が発生した頃で、かつコラボレーション後実行してみる時間を残っている時間はこの時間帯かなと。

トリンプ・インターナショナル・ジャパンの「がんばるタイム」のように、各個人業務の集中時間を設けるという事例は聞いたころがあるが、こういうコラブレーション推奨時間を設けている話はまだ見かけたことがない。 多分いろんなところでやられていると思うのだけれども。

p.s.

基本的にそれ以外の時間には話かけるなということではないので、お間違いなく。

• すごいKPT事後評価セッション (2005-10-07)
• いまいちパッとしなかった「ふりかえり」 (2007-02-28)
• ソフトウェアかんばん「見えない化」 (2006-04-10)
• ソフトウェアかんばん (2005-10-28)
• 紙ベースのファイリング (2005-11-08)

■ 今年のキーワードは「どのようにすれば」 - 私的10大ニュース2005 [ work ]

今年は年明けに技術部の上の人が抜けて、立場が随分と変わった。

@ すごい会議

そんな中「すごい会議」に出会い、仕事に対するマインドもかなり変化した。

• すごい会議
• ソフトウェアかんばん
• KPT法

など、マネジメントの面などでいろいろトライし楽しい1年であった。チームメンバの理解があった事もなによりであった。

@ GTD

個人面では、GTD の導入により溢れる仕事への対応を実践。 完全に自分のものにしたわけではまだなく工夫の余地があるが、この方法のおかげで仕事の漏れを大幅に減らすことができた。

• ソフトウェアかんばん (2005-10-28)
• すごいKPT事後評価セッション (2005-10-07)
• ソフトウェアかんばん「見えない化」 (2006-04-10)
• 私的10大ニュース2004 [ misc ] (2004-12-31)
• 私的10大ニュース2004 [ comp ] (2004-12-31)

■ いまいちパッとしなかった「ふりかえり」

開発プロジェクトの一つが一区切りついたので、時間を作って「KPT ふりかえり」を行ったのだがイマイチ盛り上がらなかった。

問題点:

• Try 項目がカイゼンではなく、To Do に対するアクションになりがちであった。
• Try 項目が Problem 項目の裏返し (～ができていない → ～をする) で、具体的アイデアに乏しかった。

原因としては以下が考えられる。

• 事後評価セッションではなく中間地点なので、細かいタスクに目が向きがちだった。
• ホワイトボードがなかった。

アジェンダで中期的なプロセス改善につながる Try を挙げてもらうように、最初から行っておいた方が良さそうだ。

次回以降「ふりかえり」については工夫の余地あり。

• すごいKPT事後評価セッション (2005-10-07)
• 乱入OK! コラボレーションタイム (2005-12-06)
• ソフトウェアかんばん「見えない化」 (2006-04-10)
• 本社にいた「すごい会議」読者とミーティング (2005-12-20)
• 「すごい会議」2度目 (2005-06-03)