nDiki : 事後評価セッション
事後評価セッション (postmortem session)
2004年3月29日 (月)
[ お仕事 ] プロジェクトの事後評価セッション
本日、担当プロジェクトの納品物件の発送が完了したので、終業時刻前の30分間プロジェクトの事後評価セッションをしてみた。
「成功と問題の両方について議論する。(適応型ソフトウェア開発 p.167)」、 「人は事後評価に対して過度に批判的になる傾向がある。セッションが始まる前にプロジェクトについて3つの成功した点と3つの問題点のリストをを作成するように参加者に依頼することで、進行役は、否定的になりがちな傾向を緩和することができる。(適応型ソフトウェア開発 p.168)」
ということで、良い点もきちんと振り返ってみることにした。 たしかにそのおかげで、ぐっと建設的なセッションになった感じ。
postmortem session
postmortem は検死という意味もある。 今回ひとまず検死は避けられたようだ。
2005年10月7日 (金)
すごい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年12月6日 (火)
乱入OK! コラボレーションタイム
11月末にモノを発送できたプロジェクトの事後評価セッション。 手法は前回と同じくKPT法をとりいれた方法で。
セッションでは「質問したい時に、忙しそうにしていると話かけづらい時がある」という課題があがった。 あ、自分のことね。 忙しいと集中して(あるいは集中しているフリをして)そういう雰囲気を醸し出しているな。
こちらは案外好きな時間に声をかけているのだが、立場というダイオードが入っているのかもしれない。
集中とコラボレーション、どちらも大切。
ということでアイデアとして、時間を決めてその間はアポがはいっていたり極限状況にあったりない限り、チームメンバで御互いに話しかけたら誠実に対応するというルールを作ってみた。 15:00 - 16:00 をその時間に。その日にある程度作業をした後問題が発生した頃で、かつコラボレーション後実行してみる時間を残っている時間はこの時間帯かなと。
トリンプ・インターナショナル・ジャパンの「がんばるタイム」のように、各個人業務の集中時間を設けるという事例は聞いたころがあるが、こういうコラブレーション推奨時間を設けている話はまだ見かけたことがない。 多分いろんなところでやられていると思うのだけれども。
p.s.
基本的にそれ以外の時間には話かけるなということではないので、お間違いなく。
2006年4月10日 (月)
ソフトウェアかんばん「見えない化」
チームメンバが重なっている2005年度の2つのプロジェクトがほぼ終了したので、事後評価セッションを開催。
興味深いポイントについて:
ソフトウェアかんばんが見えない
今回1つのソフトウェアに対してソフトウェアかんばんを適用した。 担当開発者の2人は以前このコンビで別のソフトウェアでかんばんを使用し、コラボレーションが促進したのだが、今回はどうもイマイチであった。
先日のレイアウト変更で、タスクカード/ストーリーカードを貼る(座っている場所から見える)パーティションが無くなってしまったのが敗因と推測されている。
ぐらさん言わく「見えない化」
issue tracking
開発中に発生する
などについて誰かが指摘した後、迅速・確実に処理がなされないことが多かったという意見も多かった。
後半「コミットメント・リストチェックを電子上での各自チェックに切り換え」たことにより、皆が頭を突き合わせて真剣に意思決定する場が減ったのが大きなマイナスだったか。 その方式は2月に終了したスタッフが2拠点に分散したプロジェクトで成功した方式で、うまくいったので導入してみたのだが、このチーム向きではなかったようだ。
やはり基本は顔合わせということを実感。
またコミットメントではないけれど、細かい issue を追跡する仕組が必要かなと。 ツールに走って issue tracking system 導入して遊ぶという手もあるが、手段が目的になってしまいそうでもある。
どのようなプロセスがチームに向いているのかも含めて、ここはひとまず紙ベースでいろいろ試行してみようと思う。
できるだけシンプルにして、各自が自分の好みのツールと連動して処理していけるようにするようにしたい。
(というか、自分は自分の GTD プロセスとスムーズにやりとりできるようにしたい。)
インタフェースを変更するなら、古いのも deprecated 扱いで残して
複数人開発で途中開発者間にまたがるインタフェースの仕様が何回か変更になった。 改良のために仕様変更はアリだと思うが、コード変更に愛情が足りなかったため実行できないコードが断続的に発生し、確認のための開発待ちが発生した。
通常開発中のコード内でのこのようなインタフェース変更については
のどちらかを取りかつ周知をする必要があるが、この辺がうまくできていなかった。 次回はうまくやれるはず。
ちなみに「できるだけ早く仕様を決定するようにする」というアイデアも出たが、これはまず守られない。もちろんみんなそれを望んでいるし、そのように努力しようとするんだけれども、最初の時点で完全な仕様を決定できることはほどんどない。仮にその時点で完全でも、数ヶ月後には状況が変わり仕様がふさわしくなくなってしまっていることもある。 無理に最初の仕様に固執することの方がデメリットが大きいことも多い。
止まらないプログラミング
変に一人で抱えこんで数時間あるいは1日プログラミングを止めてしまうことを無くそうという提案。
- 30分ルール
「30分」のところは15分だったり1時間だったりするかもしれないが、とにかく必要以上に一人で悩んで立ち止まらないようにしようという話。
関係者に確認すれば数分で解決してしまうことも多い。 技術不足とかそういうこととは関係なし。 もしかしたら「そのインタフェース実はまだできてないので結果は適当です」というのを呼び出して結果が合わないと悩んだりしてたりとか。
チームのトータルのスループットを最大にするようにコミュニケーションしよう。
2007年2月28日 (水)
2013年11月12日 (火)
今日のさえずり: 「なんでパンツはくの?」
2013年11月12日
- 08:25 「なんでパンツはくの?」
- 08:28 終身免許。 http://flic.kr/p/ht8L9c
- 09:30 SNS にある友人のグループ分け機能、友人・同級生・同僚といった社会的分類ではなくて「なぜその人とつながっていたいか」で分けてみると面白いかも。
- 12:30 「オジチャンは刑務所入ってるの。ウッソー。」 (@ キッチンひまわり（移動販売）) http://4sq.com/1blCikq
- 14:56 午前中に postmortem session (事後評価セッション) 内容の共有をしていただきました。チーム外にきちんとシェアして組織全体で学ぼうというのとても素晴しいです。参考にします。
- 18:19 食べログ使ってみるのに価格.comID 取得した。
- 18:25 「食べログ会員登録(初期設定)が完了いたしました!」画面で即プレミアムサービス登録(月額315円/税込)全面誘導すごいな。
- 18:30 次、食べログレビュアー登録した。
- 18:56 食べログ、 SNS だった。 http://bit.ly/17l1O8n
- 19:12 食べログ、ネットスターフィルタリングカテゴリは「大カテゴリ 趣味」「小カテゴリ 食事・グルメ」だった。
- 19:14 部署内で統計勉強会中。
- 19:57 食べログアプリは SNS アプリじゃなかった。
- 24:16 Revolver でコミュニティ作ってみた。 https://naney.rvlvr.co/
- 24:32 Revolver です。 こんにちはこんにちは。 https://naney.rvlvr.co/media/16951372 #naney
- 24:46 Android 版から。 WebView 的な。 https://naney.rvlvr.co/media/16951386 #naney
- 24:52 iOS 版から。 UIWebView 的な。 https://naney.rvlvr.co/media/16951393 #naney
- 25:12 Revolver アカウントは1つだけれど、 コミュニティ毎にログインするというのがちょっと新鮮。 https://naney.rvlvr.co/media/16951405 #naney
2014年9月29日 (月)
ふりかえり、あるいは検死
10年前に読んだ「適応型ソフトウェア開発」では事後評価セッション postmortem (検死) session と呼んでいて、なんとなくいつも検死というイメージを持っている。 今日はふりかえりの会があったので参加。プロジェクトのリーダーが冷静にふりかえりをまとめていたのは素晴しかった。
個人的にはコンセプトと倫理観の一致は重要だなと改めて思った。あと、「グループシンク」という用語は始めて学んだ。気をつけるようにしよう。
「人は事後評価に対して過度に批判的になる傾向がある。」(記事)
というのを思い出したのはふりかえりの会が終わった後で、よりニュートラルに聞くべきだったなというのは反省点。おつかれさまでした。
About Me
Naney (なにい)です。株式会社ミクシィで SNS 事業の部長をしています。
About nDiki
nDiki は1999年1月に始めたコンピュータ日誌を前身とする Naney の Web 日記(兼パーソナルナレッジベース)です。
#nNote タグがついている記事は他の記事に比べて、より断片的・未整理・不完全なちょっとしたノートです。まだ結論に至っていない考えなども含まれます。頻繁/大幅に更新したり削除したりすることがあります。
※本サイトの内容は個人的見解であり所属組織とは関係ありません。
Other Notes
ナレッジベースアプリケーション Obsidian で書いているノートの一部を notes.naney.org で 公開しています。
nDiki by WATANABE Yoshimasa (Naney)
Powered by DiKicker