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

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

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

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

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

関連記事

「モチベーションの源泉:何のために働くのか、転職か起業か」を読んでみて

@kuranukiさんの「モチベーションの源泉:何のために働くのか、転職か起業か」(「Social Change!」より)を読んで… 「サポータータイプ」:7「クラフトマンタイプ」:3かな、私は。RT …

社内でのランチ勉強会

以前、「社内読書会をやってみて」というエントリを書きましたが、今度は社内でやってる「ランチ勉強会」のお話です。 どんなの? 週に1回、(社内の会議室などで)お昼を食べながら、プレゼン+ディスカッション …

マルチスレッド

仕事の振り方が下手な人がいます。 「自分」しかその仕事が出来ないわけでもないのに、それを抱え込んでしまい、気付いた時には「両手いっぱいに仕事という名のボールを抱えて」いっぱいいっぱいになっています。 …

「コンビの成熟度合い」がアウトプットに与える影響

企業にはジョブローテーションがあると思います。部署内での担当替えだけに留まらず、部署間の異動、転勤もあります。 #組織の強さや未来像を意識しているかは分かりませんが…。 適性の見極めやゼネラリスト育成 …

最高のプレゼンテーション―心をつかむ見せ方、話し方[読書感想]

最高のプレゼンテーション―心をつかむ見せ方、話し方 プレゼン = 「パワポ(PowerPoint)を作らな!!」+「本番でのしゃべり!」となるのがだいたいの感じだと思いますが、この本はプレゼン = ( …

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