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

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

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

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

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

関連記事

「感謝の言葉を伝える」アクティビティ

少し前、グループでフリカエリとこれからの活動について、半日時間を取って、しっかり議論しました。 夜は、(それまでの活動が一区切り付いたこともあって)打ち上げをしたのですが、そこでちょっとしたアクティビ …

プロジェクトの種々なこと

「プロジェクト」を、前職ではPMO(プロジェクトマネジメントオフィス)的に外から、そして現職で逆に一員として内から見て…と異なる視点を経験しました。その中で感じたことをつらつらと書いてみます。 1:全 …

テーブル設計の指針(備忘録)

最近、DB設計やデータモデリング等のDB周辺について集中して触れることがあったのでテーブル設計における指針を備忘録として書いておきます。 サロゲートキーとナチュラルキー 主キーの設定時に大きく2つの設 …

コツ

最初に行う3つのプラクティスと継続していくコツ

このエントリは? このエントリは達人出版会から出版された電子書籍【開発現場に伝えたい10のこと】で私が書いた内容を許可を得て転記したものです。 2014/01/14(火)にはDevLOVE関西で書き手 …

Professionalと思う3つの振る舞い

DevLOVE Advent Calendar 2012 “Professional”に投稿しました。 「自分にとってのProfessional」とは? 私が考えているProfessionalの定義は …

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