先の投稿で、最適解が機能しなくなりそうな兆候を捉えるために、KPIを利用することを紹介した。
その逆はどうだろう？
つまり、最適解が機能し続けるように、KPIをコントロールする
のはダメなのか？
リードタイムを短縮する行為は正しいか？
誰もが一度は取り組んだであろう、リードタイムのコントロール。
リードタイムとは、依頼の発生から、依頼ごとの提供までの時間のこと。
販売でいえば、受注から製造・納品までにかかる時間である。
このリードタイムが、何らかの理由により通常よりも長くなってしまった。
その結果、在庫管理や生産管理などの最適解が機能しなくなった。
そこで、リードタイムを短くする努力をする。
具体的には、
- 残業などで投入する時間を増やしたり
- 作業スピードを早くしたり
- 作業者にはっぱをかけてとにかく急がせる
なんてことをする。
そして、その結末はどうなるだろうか？
- 無理が常態化し、
- ミスが増え、
- 手戻りが発生する。
その結果、リードタイムはさらに制御不能になっていく。
最適解が機能し続けるようにKPIの改善を試みたら、
逆に、最適解を壊してしまう。
人生いろいろ KPIもいろいろ
一口にKPIといっても、実に色々ある。
試しにAIに質問してみたら、40〜50は簡単に挙がった。
分類方法は様々あるが、性質をベースにすると、以下の４つに類別できる。
- 操作できるKPI（操作変数）
- 状態を表すKPI（状態変数）
- 観測・計算して得られるKPI（観測変数）
- 結果としてのKPI（結果変数）
最適解が機能しなくなる予兆を捉えるのは、３の観測・計算して得られるKPIであり、リードタイムはここに属する。
３の観測変数とは状態や結果を数値として可視化したものであり、KPIの多くがここに属する。
リードタイムの他には、
- 1日あたりの処理件数
- 稼働率
- 中断回数・再作業回数
などが挙げられる。
これらのKPIを直接コントロールしようとすると、リードタイムと同じように酷い目に遭う。
そのことについて、LifeHackを例に見てみよう。
LifeHackと観測変数としてのKPI
LifeHackは、日常生活や仕事の中で発生する様々な課題に対し、ちょっとした工夫により、少しの手間で最大の成果を得ようとする実践的かつ実験的な試みだった。
ちなみに、コロナのパンデミックの前は、LifeHackの取り組みは大変に流行していた。
例えば、以下のような取り組みである。
するべきことが多いのであれば、より多く実行できるように、リードタイムを短縮しようと考える。タスクの実行に要する時間を計測・見積り、無駄を減らして、できるだけ時間をかけないで完了させようとした。
1日の処理件数を増やそうとして、スキマ時間の有効活用を試みた。
例えば、「通勤時間」や「移動時間」にもギチギチにタスクを詰め込んだ。
上司やお客様からの突然の依頼を「割り込みタスク」として忌み嫌い、誰にも邪魔されないように会議室に籠った。また、急な依頼に対しては、今忙しいのでと断るようにしていた。
これらの行為は、観測変数としてのKPIをコントロールしようとしています。
三つの例は、上から
- リードタイムの短縮
- 1日あたりの処理件数の増加
- 中断回数の削減
のKPIを制御する試みである。
果たして、うまくいくのだろうか？
でも、LifeHackにまみれた人なら、よく分かるだろう。
私もそんな一人だ。
そんなことをしていると、疲弊してしまう。
結果として、うまくいかないことが多かった。
- リードタイムを短くしようとして、タスク実行の質が低下した。
自尊心も低下した。 - 処理件数を多くしようとして、１件あたりにかけられる注意力が不足し、散漫になりがちだった。
心が悲鳴を上げた。 - 稼働率を改善しようとスキマ時間を利用しすぎて、休息時間が消滅し、回復のいとまがなかった。
動画を見ても楽しくなく、罪悪感だけが募った。
私がフォローしていたLifeHack界隈でも、鬱になってしまった人は、少なくなかった。
うまくいったLifeHack
でも、LifeHackの全部がダメではなかった。
今でも有効で、使っているものも多くある。
例えば、
- 毎週の定期的なレビュー
- 原則シングルタスクで実行
- 均一なタスクの粒度
といった、LifeHackは今も有効で、大活躍している。
定期的なレビューは、すでに瞬間冷却と瞬間解凍で思考の中断と再開を安心して行える仕組みとして、詳しくご説明した通りだ。
シングルタスクとは、何かを実行する際は同時並行的に複数のことをしないで、一つに集中すること。
これはWIP、仕掛かり量の上限をコントロールすることだ。
タスクの粒度を揃えるのは、１分でできるタスクと様々な調査や調整をして取り掛かるべき重いタスクを一緒に管理しない、考えないということ。
これは、バッチサイズを揃えるということだ。
ここで挙げた３つのLifeHackをKPIに変換すると、上から
- レビュー頻度
- WIP（仕掛かり量）
- バッチサイズ
である。
これらのKPIは先に挙げた４分類の中で、操作することができるKPI（操作変数）に相当する。
操作変数のKPI
もう一度、KPIの４つの分類を確認する。
状態を表すKPI（状態変数）
例：タスク滞留時間*6、集中時間の分断度*7、疲労感・認知負荷、仕掛かり仕事の偏り*8、チームの安定度*9観測・計算して得られるKPI（観測変数）
例：リードタイム、処理件数/日、中断回数、レビュー指摘件数、再作業回数結果としてのKPI（結果変数）
例：売上・利益、顧客満足度、成果物の品質、成功率、評価・信頼
以上のように、操作できるKPIは数多あるKPIの中のほんの一部だ。
私たちは、
コントロールできないものをコントロールしようとする
さらに、
触らなくてもいいものでもコントロールしようとする
そんな誘惑に抗うことができない。
だから、
コントロールできないものに対して、
文句を言ったり、
無理に触ってしまって、さらに状況を悪くしたことに対して
悪態をついてしまう。
天気が悪いことに、文句を言っていませんか？
そのような誘惑を断ち切って、
私たちは、
コントロールしてよいものだけに集中して、適切にコントロールする
べきなのです。
コントロールの対象
繰り返しになりますが、私たちは現状を記述し(AS-IS)、あるべき姿(TO-BE)を微に入り細に入りデザインすることで、成功の確率を高めています。
まずフレームワークを活用して、整理された記述をする。
次にKPIを利用して、計測可能な指標を導入し、最適解が機能するか確認できるようにする。
最適解が機能する理想状態を維持するために、操作可能なKPIをコントロールする。
だが、ちょっと待て。
操作可能なKPIを、どうやってコントロールすればいいのか？
全体像は、フレームワークにより掴んでいる。
状態を記述することは、KPIでできている。
だが、コントロールするには、
「何をコントロールしてよいのか」という対象を
明確に特定しなくてはならない。
そして、対象を特定するには、構造を理解する必要がある。
対象を決めずして、具体的なアクションは不可能だ。
構造を知らずして、効果的なアクションはありえない。
構造を知るにはどうするか？
言い換えると、
「何をいじれば、何がどう変わるのか」 の問題。
次は、この問題を解きほぐす必要があるのだ。
