サウスポーなエンジニアの独り言

サウスポーなエンジニアが日々感じた、気づいた、学んだことを徒然と書いています。

改善 旧館より 開発プロセス

KPT法を使う場合に気をつけること

投稿日:2008年1月22日 更新日:


 以前、書いたKPT法を実際に1人やプロジェクトの「フリカエリ」で使ってみて感じたことを書きます。

※注意:この記事は旧サウスポーなエンジニアの独り言から移行し一部修正したエントリです。
 
 KPT法の優れている点は以下の3つと思います。

1つ目:サッとできる。

 紙とエンピツがあればすぐにその場でできます。

2つ目:見える化できる。

 付箋紙等を使えば「見える化」されることで、改善される感がより実感できます。

3つ目:ブレストしやすい。

 手軽に行えるので前準備も特に必要なく、みんなでやりやすく、良いブレーンストーミングができる可能性が高くなります。

KPTの難しい点

 逆に「これはKPT法では難しい」と思ったこともありました。
 KPT法では「悪かった点(Problem)」に対し「改善点(Try)」を行いますが、このTryが抽象度が高いぼやけた内容だと「なんとなく」な内容になり、そのアクションリストも曖昧なものになります。
 つまり「Problem」に対する表面的な「Try」でしかなく、『真因』まで分析できていないからです。

 製造業の現場に多い「なぜを5回繰り返す」「なぜなぜ分析」など、考えに考え抜き、その真因を導き出すのが「根本的な改善」というものです。

 ただ、(KPT法に比べ)時間がかかり、また、「なぜ?なぜ??」と突き詰めるのはパワーも必要なのでなかなかそこまで踏み込めないこともあります。

 話を戻すと「Problem」に対する表面的な「Try」を立ててみたところで、その「Try」は的外れかもしれません。

 この手の改善プロセスは、割とすぐに目に見える効果が出ないとしんどくなり、必須でも無い故に「やっぱり無駄なので、止めようよ」となりがちです。
 そのためにも、小さな成功体験で良いので、それを体験する時を導入する時の最初の目標にすることもあります。

 「Keep」も同様で「なぜそれが良かったのか?/良くできたのか?」が分からず、「なぜかな知らないけど偶然出来た」レベルでは、再現性の低い事象となります。
 その結果、習慣として定着せず、安定した高いパフォーマンスを出せなくなります。

 最初からヘビーウェイトなプロセスで深掘りするのもしんどいものですし、そもそも全ての「Problem」に対して必要があるか分かりません。そしてもちろんそんな時間もありません。

 ですので、どれを重点的に深掘りするか「見える化」するためにKPT法を使い、そこから重点的な項目に深掘りの技法を使うのが私にとってはしっくり来る改善のパターンだと感じました。

-改善, 旧館より, 開発プロセス

執筆者:


comment

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

関連記事

「ドッグフードを食べる」意識

先日、あるSIerが発表したプレリリースを読んで、ふと思ったことです。 そのプレスリリースは「こういうソリューション提供できますよ。是非御社で使ってください」というものでした。 #エントリの本質とは関 …

ワークフローシステムが意味がない時

社内にあるワークフローシステムを使って事務処理をしていた時にふと思ったことです。 例えば、開発プロジェクトでサーバなどのハードウェア器機を調達する必要が出てきたとします。 それは、当然個人で買うわけで …

見える化

「可視化」と「見える化」

先日「プロジェクトファシリテーションパーティ2012」に参加してきました。 #参加した皆さん、お話していただいた皆さん、スタッフの皆さん、ありがとうございました! 参加したセッション マルチセッション …

嬉しい言葉「また一緒に仕事をしたいですね」

「またこのチームの皆さんと一緒にプロジェクトをしたいですね!」 システムのカットオーバーを無事に迎えたプロジェクトの打ち上げで、クライアントからこんな言葉をもらえるとすごく嬉しいものです。 こういう言 …

日常の意思決定にも使えるかも…狩野分析法

http://d.hatena.ne.jp/masayang/20071213/1197534511にて狩野分析法というものが紹介されていました。 「Agile開発で~」と書かれていますが、Agile …

ギルドワークスの現場コーチ。
「正しいものを正しくつくる現場を増やす」ことを目指している現場コーチ。認定スクラムマスター(CSM)。
様々な規模のSIerでのシステム開発を経て今に至る。
DevLOVE関西を主催。