nDiki : 事後評価セッション

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

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

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

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

postmortem session

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

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

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

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

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

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

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

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

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

• Subversion の導入
• TeX化

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

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

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

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

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

サーバ移行

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

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

飲み会

すごい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分。ほぼ予定時間とぴったり。 事前に書いてきた内容をホワイトボードに書き込まずに貼りつけるだけで済むようにしたためかなり時間が短縮できた。

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

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

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

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

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

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

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

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

p.s.

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

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

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

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

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

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

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

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

issue tracking

開発中に発生する

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

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

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

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

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

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

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

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

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

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

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

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

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

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

止まらないプログラミング

変に一人で抱えこんで数時間あるいは1日プログラミングを止めてしまうことを無くそうという提案。

• 30分ルール

「30分」のところは15分だったり1時間だったりするかもしれないが、とにかく必要以上に一人で悩んで立ち止まらないようにしようという話。

関係者に確認すれば数分で解決してしまうことも多い。 技術不足とかそういうこととは関係なし。 もしかしたら「そのインタフェース実はまだできてないので結果は適当です」というのを呼び出して結果が合わないと悩んだりしてたりとか。

チームのトータルのスループットを最大にするようにコミュニケーションしよう。

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

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

問題点:

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

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

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

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

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

今日のさえずり: 「なんでパンツはくの?」

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

ふりかえり、あるいは検死

10年前に読んだ「適応型ソフトウェア開発」では事後評価セッション postmortem (検死) session と呼んでいて、なんとなくいつも検死というイメージを持っている。 今日はふりかえりの会があったので参加。プロジェクトのリーダーが冷静にふりかえりをまとめていたのは素晴しかった。

個人的にはコンセプトと倫理観の一致は重要だなと改めて思った。あと、「グループシンク」という用語は始めて学んだ。気をつけるようにしよう。

「人は事後評価に対して過度に批判的になる傾向がある。」(記事)

というのを思い出したのはふりかえりの会が終わった後で、よりニュートラルに聞くべきだったなというのは反省点。おつかれさまでした。