この記事の対象になる方
- システム・開発・生技・保全・製造・購買・営業に携わるすべての社会人
- KPIってなんぞやと疑問を抱いている人
- いろいろ見たけどKPIを表で理解したい人
はじめに
どうも、KPIに翻弄されし末端技術者にこらです。
何を隠そう筆者は、JTCの中で設備導入やシステム導入に向けたKPIを作成し、それを指標に評価を受けてきた人間です。
KPIという言葉は会議で頻出するわりに、いざ作ろうとすると急に空気が重くなります。
品質を入れるべきか。
保全性も見るべきか。
費用対効果はどう表現するか。
そもそもそのKPI、評価のためだけの飾りになっていないか。
このあたりで毎回モヤモヤしがちです。
そこで今回は、発注フローを題材にして、簡易版として最低限ここは押さえたいというKPIの形を整理します。
システム設計のKPIというと難しそうに見えますが、本質はそこまで複雑ではありません。
KPIは、うまくいった感を作るための資料ではなく、仕様漏れと評価ブレを防ぐためのものです。
この記事では、実務で使いやすいように、できるだけ表で、できるだけシンプルにまとめます。
そもそもKPIってなんぞ？
KPIとは、重要業績評価指標のことです。
ものすごく堅い言葉ですが、簡単に言うとそのシステムがちゃんと成功しているかを測るための物差しです。
たとえば発注システムを導入したとして、完成したかどうかを何で判断するのか。
画面ができたから完成なのか。
運用が回ったから成功なのか。
障害が出ても一応使えているから合格なのか。
ここが曖昧だと、評価はすべて雰囲気になります。
こうして、誰も不正解ではないのに、誰も納得しない地獄が始まります。
だからこそKPIが必要です。
KPIを決めておくことで、どこまでできたら合格か、どこが不足なのか、何を改善すべきかが見えるようになります。
なぜシステム設計でKPIが必要なのか
システム設計でKPIが必要な理由は、大きく3つあります。
1．仕様漏れを防ぐため
設計段階では、つい画面や機能ばかり見がちです。
しかし実際には、障害時の復旧性、保守性、運用負荷、費用対効果まで含めてシステムの完成度です。
KPIを入れておくと、こうした見落とされやすい項目を表に残せます。
2．評価を感覚論にしないため
完成度85％と100％では意味が違います。それはそうですよね。
じゃあ何の項目を参照して85％なのか、、、、
その項目が曖昧だと、人によって解釈が変わります。
KPIは、評価を感覚ではなく条件に変える役割があります。
3．関係者の認識をそろえるため
システム案件は、設計者だけで完結しません。
使用部門、保全、管理者、ベンダ、購買、時には営業まで関わります。
KPIがあると、全員が同じものを見て会話できます。
KPIがない設計は、ゴールのないマラソンに近いです。
走ってはいるけれど、どこまで行けば成功なのか誰も分かりません。
KPI（抜粋版）のテンプレはこれ！！
以下は、発注フローを題材にした抜粋版のKPIテンプレです。
パワポで重要項目だけ抜粋して作っておけば、報告会でもさらっと使えるでしょう。
この表のポイントは、品質だけで終わっていないことです。
システムは動けば終わりではありません。壊れにくいか、直しやすいか、予算に見合うか、運用が滞らないかまで見て初めて実用です。
指標の解説
品質
品質のところでは、完成率として85％と100％を分けて持つのがおすすめ。
85％は、主要機能が揃って試運用や関係者確認に入れるラインとして使います。
100％は、残りの細かい仕様や例外対応まで含めて埋め切った最終到達点です。
この考え方の良いところは、完成か未完成かの二択にしないことです。
実務では、まだ100％ではないが評価や運用確認を進めたい場面が多くあります。そのとき85％という中間目標があると、進捗を管理しやすくなります。
また、85％達成日と100％達成日を項目に入れておくと、品質だけでなく納期管理にも使えます。
仕様を満たした数だけを数えるのではなく、いつその状態に到達したのかまで見ることで、設計の進み方がかなり見えやすくなります。
完成率は、単なる数字ではなく、仕様漏れを防ぐための網です。
保全
保全系のKPIは、設計段階で抜けやすいのに、運用が始まると最も効いてくる項目です。
例えば故障(障害)件数。
これは単に少なければ良いという話ではなく、何を障害と定義するかを決めておくことが重要です。
画面表示崩れも障害に含むのか、発注停止レベルだけを含むのかで、意味が大きく変わります。
筆者の考えではバグではなく、システムとして成り立たないものを故障と判断しておきましょう。
MTBFは平均故障間隔、MTTRは平均修復時間です。
ざっくり言うと、どれくらい壊れにくいかと壊れたときどれくらいで戻せるかです。
MTBFは感覚的に1カ月に1回故障が発生するとしたら、多く感じますよね。
そこで2カ月を指標に置いています。
こういう数字の整合性は意外と大事です。KPIは表に書いた瞬間に一人歩きするので、ざっくりでも筋が通っている必要があります。
MTTR30分以内というのは、1時間止まる不具合の場合、そもそも社内の人間で対処できないケースが多いと感じます。発注フローのような業務系システムは、数時間止まるだけでも現場に地味なダメージを与えます。
だからこそ、止まらないことだけでなく止まってもすぐ戻せる時間を設定しましょう。
コスト
コストは、つい最後に雑に置かれがちな項目です。
しかし、導入効果を説明するうえではかなり重要です。
例えば発注フローのシステム化であれば、効果としては以下のようなものが考えられます。
- 手入力時間の削減
- 承認待ち時間の短縮
- 誤発注の削減
- 発注履歴の検索性向上
- 属人運用の低減
これらを何らかの形で数値化しないと、導入後に便利になった気がするで終わります。
逆に言えば、費用対効果の項目を入れることで、システム導入の意義を説明しやすくなります。
使用したフローはこれ！！
フローを見ると、どこで品質を測るか、どこで保全性を測るかが自然と見えてきます。
フローから仕様＆KPIへ落とし込み方
ここが設計KPIのいちばん面白いところです。
KPIは思いつきで置くのではなく、フローの処理と判断から逆算して作ると抜けが少なくなります。
1．ステップごとに仕様を洗い出す
例えばフローはステップに分け、各ステップで求められることを書き出します。
始めの入力ステップであれば「入力必須項目」「添付ファイル」「承認ステップへ進む」などが仕様になります。
フローからこれらを書き出したものが仕様であり、それらの達成率をそのままKPIにします。
2．列をまたぐポイントが仕様になる
承認可否、入力不備の差し戻しなど、システムを経由し列をまたぐ部分はそのまま仕様になります。
例えば自動で承認通知を送るなどがそれになります。
良いKPIは、フローのどこを見て作ったのか説明できます。
他にシステムで使用するKPIをご紹介
抜粋版に加えて、案件によっては次のようなKPIも使えます。
- 応答時間
- 生成データ成功率
- ユーザー教育完了率
- 問い合わせ件数
- 再発障害率
- 手戻り率
全部を入れる必要はありません。
大事なのは、その案件に本当に効くものだけを選ぶことです。
KPIは多ければ多いほど立派に見えますが、運用されないKPIはただの飾りです。
KPIは有識者にバリデーションを受けよう
これはかなり重要です。
KPIを設計者ひとりで決めると、だいたい偏ります。
なぜなら様々なバックグラウンドを持つ人達で作ったほうが多くをカバーできるからです。
開発側だけで作ると開発しやすい指標になり、使用部門だけで作ると理想論に寄りがちです。保全だけで作ると安定性に寄り、管理側だけで作ると費用ばかりが指標になります。
だからこそ、KPIは有識者全員でバリデーションしてもらうべきです。
見てもらうべき相手の例はこんな感じです。
- 使用部門
- 保全部門
- システム担当
- 購買担当
- 管理者
- 必要に応じてベンダ
チェック観点としては、次のあたりが実務的です。
KPIは作って終わりではなく、関係者が納得して初めて使える指標になります。
最後にまとめ
- KPIは、システムが成功したかを感覚ではなく条件で判断するために必要
- 品質・保全・コスト・納期・運用の観点を最低限押さえるとバランスが良い
- 発注フローのような業務フローから逆算すると、KPIはかなり作りやすい
- 良いKPIは、仕様漏れ防止と評価ブレ防止の両方に効く
- KPIは必ず有識者にバリデーションを受け、解釈がズレない形に整える
本記事は学習目的の情報提供です。実際の電気工事・設計・配線・機器選定・部材選定・改造は、法令・社内基準に従い、有資格者および責任者の管理下で実施してください。現場条件により最適解は変わるため、必ずメーカー仕様書・設計基準・安全規程・JISを確認のうえ判断してください。
この記事へのコメント