KT 方とはアメリカで考案された論理的思考の手法で、NASA など機関、大手企業に採用されています。
この記事では、そのうち不具合修正に特化した問題分析 (PA, Problem Analysis) についての習得を目指します。
KT 法とは
KT（ケプナー・アンド・トリゴー）法とは、アメリカで考案された問題分析・意思決定・リスク分析などを含んだ総合的な論理的思考の手法です。
日本で知っている人は殆どいないと思います。解説もほとんど見当たらないですね。私も日本ではなく、シドニーで習いました。
強力なツールなのに、あまりしられていないのはとても残念です。
引用にある著書は以下です。英語です。
ポチップ
今回はこの中で一番よく使われる「問題分析 (PA) 」の紹介をします。
申し訳ないですが、習ったのが英語だったため訳語がおかしいかもしれません。
その点ご了承ください。
問題分析 (PA : Problem Analysis)
KT 法の中で一番使われる手法です。問題の原因を見つけ出し、修正することを目的とした手法です。
一言で言えば不具合修正です。
基本的な考え方
今問題が発生しているということは、過去のある時点までは正常だったが、ある瞬間になにかが起こった、と考えます。
そこで、過去の正常だった状態と今の異常な状態を細かく比較していき、その差異 (Deviation) を確認します。
その差異について関係者にインタビューしていき、その差異があった部分に関係する何かが発生してなかったか、を調査・確認していきます。
見つかった差異は「Possible Cause （原因候補）」と呼ばれ、リストします。
通常、差異は複数見つかります。その中でもっとも原因に近いと思われる差異 (Most Probable Cause) を元の状態に戻してみます。
もし問題が解決（もしくは改善）したら、それが原因だということになります。
もし解決しなかったら、次の Possible Cause の部分を戻してみます。
この繰り返しで問題を解決します。
どういったケースで使われるか
私はこれをサポート業務で使っています。お客様のサーバーやシステムで異常が発生した場合の原因特定に使っています。
この手法で、そのシステムについて詳しくなくても原因を見つけてしまう例をいくつも見てきました。とても強力なツールです。
また自分や家族の PC がおかしくなったときなど
とにかく物が故障したときに、隠れた原因を見つけるのに重宝してます。
こういった元の正常な状態にもどしたい、という目的の場合に見えない原因を見つけることが出来る、強力なツールです。
具体的なやりかた
問題を一文にする
いわゆる問題定義です。下記の項目についてなるべく一文で書きます。
- 何に問題が発生しているか
- それのどこが正常状態と異なっているか
- 何をどう観察して異常だとおもったか
そのときに下記の項目に注意して、なるべく具体的に記述します
- What – 何
- Where – 場所、ロケーション、部分
- When – タイミング、時間的にどのように発生しているか
- Extent – サイズ、大きさはどれくらいか
これらの要点を注意しながら書きますが、何度でも書き直し可能です。
むしろ書き直しが発生するのがあたりまえ、くらいに思ってください。
検証や分析が進めばいくらでも変わるのが普通です。
正常な状態と異常な状態を比較分析
次に現在の異常な状態と問題発生前の正常な状態を、下の表の各質問に答えながら、各セルを埋めていきます。
これにより差異を明らかにしていきます。
これも必ずしも全てを埋める必要はなく、途中で Possible Cause （原因候補） が頭に浮かんだら、検証に移って構いません。
検証に失敗したら（問題が解決しなかったら）戻ってきて、また下の表を回答の続きをします。
| 視点 | 異常な状態 (IS) | 正常な状態 (IS NOT) |
|---|---|---|
| What | 何が差異を持っているか？ 差異とは何なのかを記載する | 正常な状態では、それはどうなっているのか？ (What の視点から） |
| Where | 差異が観察できたのは、どの部分か？ もしくは差異が発生したとき、どの部分で観察されたか？ | 本来、その部分はどうなっているか？ (Where の視点から） |
| When | 最初にその差異が観察されたのはいつか？ いつからかんさつされたのか？発生パターンは？ そのシステムが導入されてから最初の発生か？ | その時間に、本来ならどうなっているべきなのか？ (When の視点から） |
| Extent | 差異の発生しているシステムの数は？ 一つのシステムの差異の数は？ 一つ一つの差異の大きさは？ サイズ・数の時間的な推移については？ | その数はゼロであるべきか、それとも少なくあるべきなのか？ サイズについては？ |
差異を見つけてテストし、原因を見つける
原因候補 (Possible Cause) は複数出てきます。これをリストしていきます。
その中で一番「これが今回の原因ではないか」と思われるものから順にテスト（修正）していきます。
ダメだったら次を試していきます。
どれを試すかの判断するのは経験でいいです。
テストを続けていくとそのうち、問題が解決したものが見つかります。それが本当の原因、ということになります。
(スポンサーリンク)
事例
これを使った例をご紹介します。
1. Zoom アプリの画像が停止
去年 (2020年）のことですが、Zoom でウェビナークラスを毎週２，３クラス受けていました。
Windows 10 で受けていたのですが、１週間ぶりにカメラをオンにしたところ、画像が止まってしまいました。
結局そのクラスはカメラ無しで受けたのですが、その後もこのままでは困るので、問題を特定して治そうと思いました。
2. Where を確認して問題を見つけ、修正する
問題自体は「Windows 10 上の zoom アプリのカメラ画像が停止する」という一文になりますが、これを上の表を参考に分析していきます。
What は zoom アプリのカメラ画像ですが、本当にそうでしょうか？
- zoom は自分一人でもミーティングをひらけます。これでやったところ、やはり止まりました。ホストとの接続はなかったはずなので zoom のホスト側の問題ではなく、この Windows10 上の問題であることがわかりました。
- 次に zoom アプリの問題かどうか。カメラを使う他のアプリも確認しましたが、同様に止まりました。なので zoom アプリの問題ではなく、カメラ周りのソフトウェアの問題ということがわかりました。
結局の所、カメラのデバイスドライパーが問題なかった日時よりあとにアップデートされていたことがわかりました。これを以前のバージョンに戻したところ、問題が解決しました。（これを試したときは結構ヒヤヒヤしました）
これは what where when で問題の場所を絞り込んでいった事例になります。
経験とスキルがあるとベター
この事例では簡単に書きましたが、実際のところ OS やソフトウェアのプログラムスキルが無いとここまで特定することは難しいと思います。（多分 Linux で同じことをしようとしたら、出来るとは思いますが時間がかかるでしょう）
ですのである対象についてのある程度のスキルはある方がベターだと言えるでしょう。
また、上の表の質問に答えるだけで掘り下げないという場合が多く、それで「使えない手法」と判断されることもあるようで、残念です。
まとめ：KT法について
- KT法は４つのプロセスをもつ
- Problem Analysis は見えない原因を発見できる
- 問題発生したものと、正常なものとを詳細に比較して、差異を見つける
- 差異を一つ一つ検証して、真の原因を見つけることができる
