こんにちは。
他愛のないサービスであればあるほど魅力を感じる、モバイル担当の渋谷です(。・x・)ゝ


みなさんはKPT法というものを行ったことがあるでしょうか?

KPT法とは、プロジェクトなどの【ふりかえり】を行うための手法であり、
  •     Keep     :次回も実践したい
  •     Problem  :改善したい問題点
  •     Try      :次回は挑戦したい
の三つの視点からプロジェクトを整理します。


●KPT法のメリット
  •     問題点が可視化でき、誰でも理解しやすい
  •     やることがシンプルなので誰でもできる
  •     付箋に書くので、口下手や控えめな人からも意見を引き出しやすい。
  •     ホワイトボードなどに全員の視線が集中するので、人vs人ではなく、仲間vs問題、の構図になる
  •     参加者が、良かった点と悪かった点で共通認識を持てる


KPT法のやり方や利点などは、下記のサイトが素晴らしくまとまっております。
@IT:初めてのプロジェクトリーダー(6)



今回は、実際に 当社で行われたあるサーバ移設作業のKPT法を例にして解説してみます。


サーバの移設は約2ヶ月前から準備をしており、インフラ側SEとサービス側SEがそれぞれ2〜4人ほど関わりました。
移設当日は深夜作業となり、予定より移設自体には時間がかかったものの、大きな問題はなく終えることができました。
そして、7月27日弊社会議室にて、サーバ移設作業の振り返り作業を行いました。

●Keep
【Keepは次回も実践したい事】
プロジェクトでうまく行ったことを挙げていきます。
今回はこんな意見が出ました。

  •     『ドキュメント類が早い段階で充実していた』
  •     『IRC(※1)に専用チャンネルがあり、情報共有がスムーズだった』
  •     『週一で行った定例会で認識が統一できた』
  •     『作業メンバ間のコミュニケーションが良かった』


●Problem
【Problemは次回には改善したい事】
プロジェクトで失敗したことや、不備などを挙げていきます。
大事なことは原因を追究することです。
責任を追及するのはやめましょう。
今回はこんな意見がでました。

  •     『Proxyの検証が不十分だった』
  •     『インフラ側とサービス側のエンジニアで、お互いに相手の分野の知識が不足していた』
  •     『作業時間が見積もりよりも長くなってしまった』
  •     『プロジェクト期間が予定よりも長くなってしまった』

●Try
【Tryは次回に行ってみたい事】
今回は出来なかったけど、次回は挑戦してみたいことや、Problemで上がった問題の改善案を書き出してみましょう。
今回はこんな意見が出ました。

  •     『インフラ側とサービス側のエンジニアで、互いの分野の勉強会』
  •     『作業日前日は十分な休息を取る』



KPTを洗い出してみました。
さて、この次は何をすればいいのでしょう?

実は、KPTを洗い出したあと何をすべきか、を解説しているサイトは多くありません。
そのため、KPTをやること自体に満足感を得てしまいがちですが、KPT法を行う本当の目的は、今回のプロジェクトの経験を次回のプロジェクトに生かすことのはずです。


●KPTで良く陥る現象
  •     ・KPTを出したあと、部屋が静まり返る
  •         (KPTを出したはいいが、それをどうすればいいのか分からない)
  •     ・毎回KPTに出てくる Problem が同じ
  •         (問題点が次回に生かされてない)
  •     ・改善案はでるが実行されない
  •     ・KPTをやったことに満足し、終わった後に行動が伴わない
  •     ・Keep Problem Try の項目が多すぎて、結局何をすればいいのか分からない


もし、上記の【良く陥る現象】に該当する項目が一つでもある人は、KPTT法を試されてはいかがでしょうか?


■KPTT法の実践

KPTT法とは、
  •     Keep     :次回も実践したい事
  •     Problem  :改善したい問題点
  •     Try      :次回は挑戦したい事
  •     To Do    :次回までに行う事
の4つの頭文字から成り立つ言葉です。

KPT法に、T (To Do) が追加されてます。


KPT法の問題点として、【具体的な行動を伴わない】というものがありました。
KPTT法は、次回までに行う事 (To Do) が追加されたことにより、【次に行うべき具体的な行動】が明確化でき、参加者全員で共有することができます。


具体的に今回の会議で出てきた ToDo は下記のようなものです。
●To Do
【Keep】の中から、実行可能で次回も絶対に行うべき作業を選び、【ToDo】に追加します。
  •     『早い時期にドキュメントを作成する』
  •     『IRCに専用チャンネルを作る』
  •     『週一の定例会』
【Problem】の中からは、実行可能な改善案を選び、【ToDo】に追加します。
  •     『今回の作業時間を、次回の見積もりに適用する』
【Try】の中からは、実行可能で次回こそは挑戦したい作業を選び、【ToDo】に追加します。
  •     『プロジェクト開始時に、お互いの分野の勉強会を開く』

※KPTTには、【Tryの中からすぐに実行可能なタスク】だけを洗い出して、ToDoへと入れる方法もありますが、今回はふりかえり間隔が長いプロジェクトを想定しているので、この方法を取ります。



ここで大事なことは『実行可能で具体的』な事を選択することです。
あれもこれも、と欲張りすぎると、作業量が多すぎて負担が増え、結局すべて実現できなかった、なんて事態になりかねません。
また、
  •     ・開発期間を長く取る
  •     ・個々の技術力を向上させる
  •     ・人為ミスがないように注意する
こういった意見は、抽象的かつ実現できるとは限りません。
このような抽象的な意見は、具体的な行動に置き換えてみましょう。
    【人為ミスがないように注意する】
        ↓      ↓      ↓
    【今回起きた人為ミスをドキュメントにまとめ、みんなに共有する】


図で表してみると、図1のような感じになります。

図1
0001




ToDoを見てみましょう。
ToDoには今、『次回やればいい』事が全て書いてあります。
言い換えれば、『次回のプロジェクトでは、【ToDo】に書いてあることだけをすればいい』のです。


このように KPTT法を用いると、やるべき作業が明確化されます。



一度お試しあれ〜(。・x・)ゝ


※1 IRCについては、下記参考URLをご覧ください。
    IRC普及委員会 HOME
    LimeChat