まず結論
目標があり、それを具体的な指標にしたものがKGIであり、KGIを達成するために取り組むべきことがCSFであり、CSFを見つけるために重要な考え方が制約理論であり、CSFの取組ができているかどうかの指標が、KPIである。
では、うちの部署であったことを交えて、詳しく説明していく。
キッカケ
管理職として、部門目標や部下の個人目標の設定のサポートをするに当たって、KPIの考え方がいまいち腑に落ちていなかったため、こじつけのようなKGI、KPIを設定するようなことがあったので、ちゃんと理解したいと思って、こちらの本を読んだ。
この本を読もうと思ったキッカケは、PIVOTのYouTubeで著者の中尾さんの動画を見たからだった。 KPIマネジメントについて、制約理論に基づいた話をされていて、もっと詳しく知りたいと思った。
まずは制約理論
制約理論に基づいて考えるという話がすごく腑に落ちた。
制約理論は、すごく簡単にいうと、業務プロセスのボトルネックを見つけて、ボトルネックを解消するように動いて、ボトルネックが移動したら、次のボトルネックを解消しようということだ。集中の5段階がある。
- 制約を見つける
- 制約を徹底活用する
- 制約に従属させる
- 制約の能力を高める
- 次の制約に移る
ボトルネックがあるとしたら、すぐに4の制約の能力を高めるを考えてしまいがちだし、そもそも2と3と4の違いについて、ちゃんと理解できていなかった。
そして、今までの目標設定は、1の制約を見つけるという点がなかった。もちろん、関連していることはなにかしらの施策でやろうとはしていたが、明確に「業務プロセスのボトルネックを解消しよう!」という意図はなかった。
前回の失敗
前回は、制約理論に基づいた考え方を取り入れていないから、KGIに関連してそうなアクションとして、AとBとCをやろう!という感じで、やることを多く設定してしまっていた。そのため、目標となるKPIが複数設定される。A、B、Cは、あまり関連がなく、KPIとしてはそれなりに普通に見えるのだが、目標に対する重要度として、Aは40、Bは30、Cは20、残り10はその他、のようになっているため、暗黙の優先度が決まってしまい、Aのほうが重要なので、Aを達成するためにCをやらないのは仕方のないことだ、ということになり、結果、Cがあまり進まないということが起きていた。
1on1をする中でも、確かにAを達成するためにはCは後回しになってしまうよなぁと話しつつも、いつまでも放置されるC。どこかで取り組んでほしいと伝えても、「でもAがあるんで…」と言われ、とはいえ指導する立場でもあるし、個人目標を立てたのは本人なので、しっかりやってほしいという気はしていた。
失敗を踏まえて
今回は、今一度、業務プロセスを分解して考えることにした。システム開発チームなので、以下のようにした。
- 要件定義・要望確認・問い合わせ
- 設計・設計レビュー
- 実装・不具合対応
- 実装レビュー
- リリース前検証・不具合対応
- リリース
ちゃんとボトルネックを計測したわけではないが、皆が抱えている不満点や改善したい点について確認を取りたかったので、アンケートを作成し、メンバーに回答してもらった。ミーティングで聞くと、よく喋る人の意見のみになってしまうのと、他の人の意見の影響を受けてしまうと考えたため。
1. 制約を見つける
様々な意見はあって、どのプロセスでも課題はあったのだが、根本的なところは設計・設計レビューにありそうだった。
もっというと、『設計・設計レビューができる人が忙しい』ということだ。
突発的な問い合わせや、リリース前の不具合の発覚等で緊急の対応を迫られることが多いため、設計・設計レビューに時間を割くことが難しく、設計完了が遅れるため、開発に着手できない、という点。
2. 制約を徹底活用する
制約を徹底活用するというのは、新たな投資をせずに、今あるものを利用するということだ。
- 設計者が集中できる時間を増やすため、会議を減らす
- 設計レビュー待ちを放置しないようにする
みたいなところかなと思う。
3. 制約に従属させる
制約に従属させるというのは、制約以外のプロセスを、制約のために協力するということ。制約理論は、つまり全体最適化の話になるので、各プロセスの1つの生産性が高かったとしても、最も生産性の低いプロセスがその業務プロセスの生産性を決めてしまうので、過剰生産になっているところはその生産の手を緩めて、最も生産性の低いプロセスの生産性を高めることに協力すると、全体としての生産性は向上するということになる。
- 設計者への割り込みを減らすため、問い合わせ対応は設計者以外が行う
- 突発的な不具合対応を減らすため、テストをしっかり行ってからリリース前検証に移行する
4. 制約の能力を高める
これは制約から判断すると「設計できる人を増やす」ということになるのだが、これに関しては一朝一夕にはできない。ましてや、短期で教育するとなると、設計者が育成に関わらないといけないので、設計者が更に忙しくなってしまうので、取り組めない。
ただ、中長期目標としてはこれに取り組まないとボトルネックの解消は行えないので、若手に設計知識・業務知識を習得してもらう必要がある。
- 若手に設計知識・業務知識を付けてもらうために、定期的に勉強会・読書会を行う
CSFの定義が大事!
先に制約理論の話をしてしまったのだが、マジでこれが抜けていた。CSFとはCritical Success Factor(最重要成功因子)の略で、KGIを達成するために最も重要な取組のことを指す。KPIが迷子になっていたのは、CSFを定義することを知らなかったからだと思った。そして、本の中で、KPIはCSFが上手くいっているかの指標ということだった。
目標があり、それを具体的な指標にしたものがKGIであり、KGIを達成するために取り組むべきことがCSFであり、CSFを見つけるために重要な考え方が制約理論であり、CSFの取組ができているかどうかの指標が、KPIである。
目標・KGIについては詳しく書きすぎるとアレなので、一般的によくある形として書くと、
- 目標:機能開発してよりよい製品にする
- KGI:予定機能をスケジュール通りに提供
- CSF:(制約理論に基づいて)設計のリードタイムを短縮する
- KPI:制約を徹底活用、制約に従属させる、制約の能力を高める、に従ったKPIの設定を行う
となるかなと思う。
KPIは信号である
この、KPIは信号であるという考え方によって、ようやく腑に落ちた。これは、つまりAPMやRUMと同じなのだ。アプリの応答速度が遅くなっていたり、CPU負荷やメモリ使用量が上限を迎えそうになっていたら、なにかしらのアクションが求められる。それと一緒なのだ。
こういう分類があるかどうかは分からなくて、私がAIと壁打ちしているときに定義したのだが、KPIには大きく2種類ある。累積型と監視型だ。監視型は更に3つに分類できる。期限型、達成率型、在庫型。
- 累積型KPI
- 売上 3,000万
- 訪問件数 100件
- 監視型KPI
- 期限型:いついつまでに〜する
- 達成率型:◯◯を50%対応する
- 在庫型:◯◯を5件以下にする
これらはそれぞれ独立しているわけでなくて、組み合わせて使うことが殆ど(主に期限型と)。
- 期限型+達成率型:3ヶ月以内に◯◯を50%対応する
- 期限型+在庫型:問い合わせに関する回答を3日以内に0件にする
- 期限型+累積型:1ヶ月以内に訪問件数25件
累積型KPIは開発組織と相性が悪い
世の中でよく見かけるKPIの例が営業系のものばかりだからという言い訳をさせてもらうのだが(このKPIの本でもそうだったが…)、累積型KPIの例が殆どで、あまり監視型のイメージはなかった。そのため、累積型のようなKPIが設定されがちだった。こういうの、身に覚えはないだろうか?
- PRをN件行う
- 問い合わせ対応をN件行う
- ドキュメントをN件整備する
システム運用もやっているから、重篤トラブル0件のようなKPIはあったが、それも累積型の亜種。
上記の問題は、PRの数なんて数えてもあまり意味がないし、問い合わせ対応N件は問い合わせの数が外部依存になってしまうので、そもそも問い合わせが少ないと達成できないこともあり得るし、逆にいっぱいあったとしたら簡単に達成できる目標と言われかねない、ドキュメントについても整備すべきドキュメントが少なければどうしようもない。
監視型KPIは開発組織と相性がいい(はず)
先ほどの制約理論に基づいたCSFに対するKPIを定義すればいい。
2. 制約を徹底活用する、に対するKPI
- 設計レビュー待ちを3日以内に0件にする
3. 制約に従属させる、に対するKPI
- 問い合わせに対して一次対応者で完結:50%
- 設計者を二次対応者として定義し、設計者を保護する
- 実装後に正常系と簡易的な異常系のE2Eテストを開発側で実施:100%
- リリース前検証で不具合発生率を下げて、設計者を保護する
あくまでもKPIは信号であって、目標ではないので、100%とするのは別に悪くない
KPIが悪化したときのアクションを定義する
これもまた、信号だからそりゃそうだよなと思った。黄色信号や赤信号になってから、どうすればいいのか考えるのでは遅すぎる。 活動量が少ないのか、やり方が悪いのか等を見定める必要がある。
監視型KPIによって、正しい状態が定義されるので、信号が緑になるように取り組もうと言える。 そこの打ち手については、適宜ミーティングでKPIを確認して、黄色や赤になっているものについて、どうすればいいかを考えることができれば、良い方向に向かうはず。
まとめ
大事なことなので、再掲。
目標があり、それを具体的な指標にしたものがKGIであり、KGIを達成するために取り組むべきことがCSFであり、CSFを見つけるために重要な考え方が制約理論であり、CSFの取組ができているかどうかの指標が、KPIである。
その上で、開発組織では、累積型KPIは相性がよくないので、監視型KPIを導入し、KPIをスプリントのふりかえりで確認することで、次の打ち手を考えていくことができれば、きっと素晴らしいKPIマネジメントになるんじゃないか!?と思い至った次第です。
実は、まだこれらのKPIで実際に運用したわけではないのですが、個人的にはめちゃめちゃいい落とし所になったなと思っているので、どういうふうに考えてここに至ったかを残しておきたいという気持ちで、これを書きました。
悩めるシステム開発・運用の現場の管理職の方にこの記事を読んでいただけたら幸いです。


























