底辺過ぎてちょっとビビる

26歳からIT業界にいるエンジニアが、まったく成長できてないことを確認するブログ。備忘録的に使いたいとも考えています。

ポストモーテムやってみた

今までプロジェクトの終わりにプロジェクトメンバーで集まって、KPTという作業をまれに行ってきた。KPTとは、KEEP・PROBLEM・TRYの頭文字から取った言葉で要はプロジェクトを終えての振り返り作業のこと。

 

KEEP・・・継続していきたいこと

PROBLEM・・・問題など改善したいこと

TRY・・・取り組むべきこと

 

これらをそれぞれチームメンバーが出せるだけ出して、リストに書き出して残すという作業を行なってきた。チームメンバーが揃って1時間程度時間を使ってリストを残すのだけど、そのリストの寿命は、「Google Driveに格納された時点」で尽きてしまう。つまり、誰もそのリストを後から読み返すことがないのだ。全く意味がない。

 

それを知ってか知らずかわからないが、PMから「ポストモーテムを今後やります」という周知があり、今回からやることになった。

 

ポストモーテムとは

正直、KPTもここの現場に来るまで知らなかったがポストモーテムも単語として全く耳馴染みのない言葉で、最初は何を指示されているのかわからなかった。

 

本来、ポストモーテム(post-mortem)とは「検死」という意味で、転じて終わったプロジェクトの実施報告・振り返りのこと。「じゃあKPTと変わらないじゃないか」という声が聞こえてきそうだが、KPTはチームメンバーがプロジェクトに対してそれぞれ意見を提出するのに対して、ポストモーテムはリードメンバーが一人で振り返りを行い、ドキュメントを作成する。関わる人数が複数人か一人かという違いが大きい。またKPTでは理路整然としたドキュメントは作成しないが、ポストモーテムではドキュメントを作成する。

 

※というのはここの現場だけのルールで、他でどのようにしてるかわからない

 

単純にKPTだとコストがかかる割に成果物として意味をなさないので、ポストモーテムとして作業名目を変えてコスト削減と成果物の両方を得ようというのが目的かもしれない。そのあたりはわからない。

 

どんなドキュメントを作成すれば良いか

 例えば今かかってる工数について改善を考えてる状況とか、業務のやり方(例えばソフトウェアテスト工程)の改善を考えてるとか、人やチームでポストモーテムを実施するのはなんのために?というのがあるので目的に合わせた内容を作成する、というのが最初にあると思う。

 

個人的にはドキュメント自体のボリュームはそんなに多くない方がいい、つまりポストモーテムそれ自体に時間をかけるのはなんか違うのでは?という感覚。コンサルティングじゃないんだから、そんなに大量にページがあってもしょうがないだろう、という感覚なんですけども。

 

具体的には、

  1. 目次
  2. 案件やプロジェクトの概要
  3. 案件やプロジェクトの実施見積もり、工数見積もり
  4. 案件やプロジェクトの実施状況、工数状況
  5. 見積もり時点と実際の状況との差分、乖離の割合比較
  6. 乖離原因
  7. 継続すること、改善したいこと
  8. 作業評価、感想
  9. 当該ポストモーテム自体への第三者からの評価メモ

 

上記のように、多くても10ページといったところじゃないだろうか。これでもページ数的には多い感じもするし、不要と判断できる箇所はページを作成せず、まとめられるところはまとめてしまう方が良いと思う。というのも、ドキュメントを作ることが目的ではなくて、あくまでも振り返り・今後の改善や今実施していることの継続とかそういうことを検討するというか、確認することがポストモーテムをする意味・意義なので。

 

あと、一つの項目に対してあまりダラダラと長い文章を書くのもよくないのではないかと思う。できるだけ端的に(短くできるなら1行レベルでもいいと思う)すべきかな。

 

ポストモーテムを実施した、その後

せっかく共有された知見というか振り返りなので、それをチーム内で共有したい。失敗ならその失敗はなるべく繰り返さないように、成功したことなら、みんなでやっていく。まだ始まったばかりなので、どう活かされたか、については後日報告したい。

 

 

 

 

LEADER's KPT

LEADER's KPT

  • 作者:天野 勝
  • 発売日: 2019/04/11
  • メディア: 単行本
 
ポストモーテム

ポストモーテム

  • 発売日: 2016/07/19
  • メディア: MP3 ダウンロード