KKDという言葉をご存じでしょうか。日本では古くから、製造業を中心としてKKDが尊重されてきました。しかし、変化の激しい現代社会でKKDに頼りすぎると判断を誤ってしまうという見方も増えてきているのです。
ここでは、KKDの説明、KKDに代わる標準的フレームワーク、これからの時代にKKDがどのように活用されるべきかなどについて解説します。
１．KKDとは？
KKDは日本語の「経験」（KEIKEN）、「勘」（KAN）、「度胸」（DOKYOU）の頭文字を取ってできた言葉で、製造業を中心に職人の技として昔から続いている手法です。
たとえばトラブルが起きたときなどに、長年の「経験と勘」すなわち自身が体験してきた過去の事例を基準に打開策を見つけ、「度胸」によってその施策を実行に移します。
経験に基づく判断の場合、ある程度はうまくいくとされています。しかし仕事が属人化されてしまうことで、結果的に組織にマイナスの影響を与えてしまうといった弊害も考えられているのです。
２．KKD法とは？
KKD法とは、KKDをもとにして工数などを見積もるフレームワークのこと。主にITの分野で使われる機会が多いとされています。しかしKKDのみに頼って問題を処理し続けると、問題が生じる場合もあるのです。
たとえば、基準がないため判断を行う人によって答えが変わってしまったりKKDを持っている人が転勤・退職などで不在になって残されたKKDのない人にリスクが偏ってしまったりというケースが挙げられます。
また、KKDは経験のない事例には対処できません。思い込みによって問題の原因を見落とし、根本的な解決には至れず生産性を下げてしまうといったデメリットも抱えているのです。
３．KKD法以外で見積もりに使うフレームワーク
では、KKD法に頼らずに仕事を進める方法は何でしょうか。プロジェクトマネジメントであればPMBOK、見積もりであればCOCOMOといった、標準化されたフレームワークを使う考え方があります。
COCOMO法
COCOMO法は1981年にTRW社のBarry Boehm氏が提唱したもので、ソフトウェア開発プロジェクトにかかる工数や開発期間などを見積もる手法です。
過去のソフトウェア開発プロジェクトから得られたデータをもとに構築された統計的なモデルで、1995年に「COCOMOⅡ」が、2000年には多数の開発プロジェクトから得られたデータをフィードバックした「COCOMO II.2000」が発表されました。
LOC法
LOCとはソフトウェアの規模を計測する手法で、ソースコードの行数を数えて見積もりを出す方法のこと。
古くから存在する手法で、開発の開始前にあらかじめ標準的な記法（コード規約）を定めておくなどの工夫が必要です。ソフトウェア開発の受発注の基準などで用いられるプログラムの規模の推計などで広く普及しています。
４．KKD法は時代遅れ？
個人の頭の中で完結し、標準化が難しいKKD法は今の時代には合わないという意見もあります。その一方で、標準化された見積もり技法だけでは現場の実態に追いつかないといった声も上がっているのです。
KKD法の重要性を見直し、論理的・合理的な見積もり技法の不足点を補うためにも、KKDを大切にするべきといった考え方も増えてきました。
見積もりの精度を増す
では、標準的フレームワークを用いている場合の落とし穴はいったいどんなもので、そこにKKDをどのように活用するべきなのでしょうか。
たとえば、見積もり法を利用した結果、算出の手順が見えなくなり、担当者は根拠が分からずユーザーに説明することができなくなったというケースがあります。またフレームワークそのものに小さな欠陥があり、結果が異なる場合も皆無ではありません。
こうした状況にて、現場で培ったKKD法を用いると精度を高めることができるとされているのです。
発想の転換とナレッジマネジメント
理論やフレームワークをもとにしたロジカルな思考に、KKD法を用いると発想の転換や促進が可能になるケースは、企業でも多く見られます。過去に培った資源を活かして最大限にその価値を伸ばすことで、生産性向上にもつながるでしょう。
はっきりと明示化するのが難しいメンタルなどといった個人のKKDを、工夫してナレッジマネジメントすると、組織の誰もが、発想のもととなった勘や経験を共有できます。
