nDiki : 事後評価セッション

事後評価セッション (postmortem session)

web

2004年3月29日 (月)

■ [ お仕事 ] プロジェクトの事後評価セッション

スポンサードリンク

本日、担当プロジェクトの納品物件の発送が完了したので、終業時刻前の30分間プロジェクトの事後評価セッションをしてみた。

「成功と問題の両方について議論する。(適応型ソフトウェア開発 p.167)」、「人は事後評価に対して過度に批判的になる傾向がある。セッションが始まる前にプロジェクトについて3つの成功した点と3つの問題点のリストをを作成するように参加者に依頼することで、進行役は、否定的になりがちな傾向を緩和することができる。(適応型ソフトウェア開発 p.168)」

ということで、良い点もきちんと振り返ってみることにした。たしかにそのおかげで、ぐっと建設的なセッションになった感じ。

@ postmortem session

postmortem は検死という意味もある。今回ひとまず検死は避けられたようだ。

◇ Twitter やってます。この記事が気にいったらぜひ twitter.com/Naney の follower になってください。

[ permalink ]

すごいKPT事後評価セッション (2005-10-07)
[ お仕事 ] 事後評価セッション (2004-08-18)
Wrist PDA with Palm OS - Fossil FX2008 (2005-02-14)
ストーリーカード・タスクカードを導入した開発の成果物を納品 (2005-11-30)
今日のさえずり - スイリンがゴッチャしてた (2009-08-09)

[ 3月29日全て ]

2004年5月28日 (金)

■ リリース版完成後の事後評価

前回とは違うプロジェクトで事後評価セッションを提案。地理的に遠い2個所にスタッフが分散しているので、今回は

「成功点、失敗点」をメールで自分のところまで送ってもらる
とりまとめてメーリングリストに投稿
その後適宜コメントをつけてもらう

というスタイルにしてみた。

バグトラッキングシステム導入はかなり好評。問題点は、いつも通りコミュニケーション不足に関するもの。

経営・マネージャークラスにも意見をつのっているのだが、積極的ではないのは残念。長期的な視点では事後評価セッションは重要なのに。

[ permalink ]

メールによる社内コミュニケーションの問題 (2006-04-12)
Gmail へのメールボックス移行で spam 誤判定と転送問題にぶつかる (2007-08-11)
ビジネスメールガイドライン案 (2006-05-05)
すごいKPT事後評価セッション (2005-10-07)
[ Debian ] qmail + vpopmail + fml でポカミス (2004-01-19)

[ 5月28日全て ]

2004年8月18日 (水)

■ [ お仕事 ] 事後評価セッション

プロジェクトを終了したので事後評価セッションを行う。

Subversion の導入
TeX化

が評価された。会社勤めで TeX を使っていられるのは幸せ。

[ permalink ]

Subversion - auto-props (2004-05-18)
TeX と Subversion (2004-04-16)
Rekisa で TortoiseSVN から日本語ファイルの差分表示 (2006-03-23)
プロジェクト関連ドキュメントを TeX で (2004-07-23)
Red Hat Linux 8.0 Box の Subversion アッ... (2004-05-17)

[ 8月18日全て ]

2004年12月31日 (金)

■ 私的10大ニュース2004 [ work ]

今年の大事件、マイブームなど。

@ プロジェクトマネジメント

入社して満3年。今年は随分仕事の内容が変わってきた。トム・デマルコの本を読んでみたり。事後評価セッションを実施してみたり。

@ サーバ移行

DNS サーバ、メールサーバ、Web サーバを一斉入れ換え。Debian GNU/Linux に移行。 RAIDではまる。

RAIDまわりが何かよろしくないようだし、ホスト自体以前デスクトップとして使っていたPCなので安定したものに置き換えたい。

@ 飲み会

[ permalink ]

フォトイメージングエキスポ 2005 (2005-03-18)
[ お仕事 ] OCNエコノミー -> OCN ADSLアクセスIP8「フ... (2004-01-16)
www.naney.org をさくらのレンタルサーバへ移転 (2009-12-23)
今日のさえずり - 部長なのか? (2008-06-10)
Debian GNU/Linux に Hyper Estraier 1.2... (2006-05-31)

[ 12月31日全て ]

2005年10月7日 (金)

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

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

*1 @IT: 初めてのプロジェクトリーダー(6) 「ふりかえり」でプロジェクトを改善する

@ 招待状

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

「あなたが、この会議で達成したい事を考えておいてください。」(すごい会議流)
各評価対象について「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分。ほぼ予定時間とぴったり。事前に書いてきた内容をホワイトボードに書き込まずに貼りつけるだけで済むようにしたためかなり時間が短縮できた。

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

[ permalink ]

すごい会議で、どの手順で前のどの手順を参照する? 何を記録しておく? (2005-07-07)
すごい会議はじめての全手順(1/2) (2005-06-30)
今日のさえずり - 壊れた金具の代わりに南京錠 (2009-04-14)
「すごい会議」2度目 (2005-06-03)
ソフトウェアかんばん「見えない化」 (2006-04-10)

[ 10月7日全て ]

2005年12月6日 (火)

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

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

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

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

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

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

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

p.s.

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

[ permalink ]

[ 12月6日全て ]

2006年4月10日 (月)

■ ソフトウェアかんばん「見えない化」

チームメンバが重なっている2005年度の2つのプロジェクトがほぼ終了したので、事後評価セッションを開催。

興味深いポイントについて:

@ ソフトウェアかんばんが見えない

今回1つのソフトウェアに対してソフトウェアかんばんを適用した。担当開発者の2人は以前このコンビで別のソフトウェアでかんばんを使用し、コラボレーションが促進したのだが、今回はどうもイマイチであった。

先日のレイアウト変更で、タスクカード/ストーリーカードを貼る(座っている場所から見える)パーティションが無くなってしまったのが敗因と推測されている。

ぐらさん言わく「見えない化」

@ issue tracking

開発中に発生する

モジュール間のインタフェースの問題点(あるいは不明点・疑問点)などの確認/議論の必要なもの
ライセンス関連の問題など意思決定を要するもの

などについて誰かが指摘した後、迅速・確実に処理がなされないことが多かったという意見も多かった。

後半「コミットメント・リストチェックを電子上での各自チェックに切り換え」たことにより、皆が頭を突き合わせて真剣に意思決定する場が減ったのが大きなマイナスだったか。その方式は2月に終了したスタッフが2拠点に分散したプロジェクトで成功した方式で、うまくいったので導入してみたのだが、このチーム向きではなかったようだ。

やはり基本は顔合わせということを実感。

またコミットメントではないけれど、細かい issue を追跡する仕組が必要かなと。ツールに走って issue tracking system 導入して遊ぶという手もあるが、手段が目的になってしまいそうでもある。

どのようなプロセスがチームに向いているのかも含めて、ここはひとまず紙ベースでいろいろ試行してみようと思う。

できるだけシンプルにして、各自が自分の好みのツールと連動して処理していけるようにするようにしたい。

(というか、自分は自分の GTD プロセスとスムーズにやりとりできるようにしたい。)

@ インタフェースを変更するなら、古いのも deprecated 扱いで残して

複数人開発で途中開発者間にまたがるインタフェースの仕様が何回か変更になった。改良のために仕様変更はアリだと思うが、コード変更に愛情が足りなかったため実行できないコードが断続的に発生し、確認のための開発待ちが発生した。

通常開発中のコード内でのこのようなインタフェース変更については

インタフェースを変更する人が、同時に呼出し側のコードも修正してコミットする
しばらくは古いインタフェースを @deprecated で残しつつ、新しいインタフェースを提供する

のどちらかを取りかつ周知をする必要があるが、この辺がうまくできていなかった。次回はうまくやれるはず。

ちなみに「できるだけ早く仕様を決定するようにする」というアイデアも出たが、これはまず守られない。もちろんみんなそれを望んでいるし、そのように努力しようとするんだけれども、最初の時点で完全な仕様を決定できることはほどんどない。仮にその時点で完全でも、数ヶ月後には状況が変わり仕様がふさわしくなくなってしまっていることもある。無理に最初の仕様に固執することの方がデメリットが大きいことも多い。