年末が差し迫ってきたこの時期、次年度計画の立案やKPIの設定に着手されている方は多いのではないでしょうか。
このKPIの設定行動の良し悪しは、一見全く関連が無さそうに見えるシステム開発フェーズに、大きく関わってきてしまいます。本来の目的を見失った結果、KPIを達成しても事業目標が達成できていない……そんなことにならないために、本記事では「KPI設定とシステム開発の関係」について考えていきたいと思います。
1．「KPIの達成≠事業目標の達成」になっていませんか
最初に、本記事での「KPI」という用語の定義を明確にしたいと思います。小学館『日本大百科全書』の「KPI」の項には、下記のように書いてあります。
KPIとは目標達成に向かってそのプロセスが順調に進んでいるかどうかを点検するための、もっとも重要な指標。日本では「重要業績指標」「重要達成度指標」「重要成果指標」と訳されることが多い。
つまり、KPIは「業績」達成が出来ているかどうか点検するための指標ということになります。
「KPI達成＝事業目標の達成」なのは当たり前じゃないか、と思う方は多いのではないでしょうか。しかし、これが当たり前ではなくなる時があるのではないか。これが、本日の一つ目のテーマです。
KPI達成の施策を考える際の“罠”について、具体的な例に基づいて考えていきます。
Z社の例
Z社は、新設ECサイト活用促進による売上向上のために、スマートフォン向けネイティブアプリを開発。スマホアプリのダウンロードによる会員獲得数をKPIとして設定し、レジ前での声掛けに取り組んだ。
しばらくして、店舗より「レジ前にお客様が滞留して困る。何とかしてほしい」という声が多数上がった。そこで、より簡易に会員証が発行できるように、初回登録時の登録必須項目を4項目から2項目に変更。「名前」「SNS認証」の2項目に絞り、「住所」「メールアドレス」の2項目を削除したところ、会員登録者数は1.2倍にすることができた。
さて、これは「成功例」と言えるでしょうか。
会員登録者数が増えていることから、もちろん、一概に失敗とは言えません。しかし「会員登録者数が増えること」が本来の目的であったかどうか、一度思い出してみてください。
本来の目的に立ち戻ってみて考えれば、「そもそもECサイト活用促進による売り上げ向上が目的だったので、この施策による会員数向上がECサイト活用につながったのかの観点で検証がなされない限り、成否の評価ができない」となることが分かります。
ただ、ここで起きている「会員証の発行」という事業目標達成のための“手段”が“目的”にすり替わるということは、実際に様々なところで起きているのではないかと思います。
本来の目的を見失った結果、KPIを達成しても事業目標が達成できていない……そういったことは十分起こり得ることである、ということが言えると思います。
2．手段が目的化した時、開発フェーズで何が起きるのか
引き続き、Z社の例を用いながら「手段と目的のすり替わり」が、開発フェーズで引き起こしていることを考えてみましょう。開発検討の出発点が「レジ前の負担を減らすこと」であった為、本来の「あるべき姿・あるべき顧客体験」が検討されないまま開発に突入してしまっています。Z社の場合、開発フェーズで開発目的の“複線化”が起きています。
施策1．住所・メールアドレスをオミットする。
レジ前での負荷を減らし会員数を増やすことが目的。施策2．登録後に別の手段で住所・メールアドレスを取得する。
ECサイト活用につながるように住所・メールアドレスを取得することが目的。
このようなことは往々にして起こり得ます。本来であれば、Z社は事業目的達成のプロセスを以下のように変更したので、この新たに生まれたプロセスに明確なKPIを設定する必要があるでしょう。
「ECサイトを活用できる状態にする」、つまり、ユーザーに住所・メール登録をしてもらうためには、登録しやすいUI・UXにする以外にも、PUSH通知などで顧客に促したり、クーポン等のインセンティブを発行するなど、様々な手段が存在します。
「もともとは100％の情報を登録してもらっていたから」ということで、プロセスが変更になった後も「100％の情報でユーザー登録してもらうためにどうするか」が議論のポイントとなってしまうと、達成が不可能に限りなく近い為に仕様を決められなかったり、逆に過多な仕様になったり、考慮漏れ等が発生してしまうことになります。
このような“開発に突入してからの迷走”を避けるためには、「変えること」に注目するだけではなく「変えることに伴って“変わる”こと」への考慮を上流工程ですることが重要です。
3．KPI設定は「～とは」を定義するシナリオ作り
「変えることに伴って“変わる”こと」とは、システムとして変わることや、UI/UXとして変わることといった、具体的な“施策”の粒度では不十分です。「事業目的を達成するためのプロセスとして変わっていること」という、抽象度を一段階上げた形で考えていくことが必要になります。
Z社の例では、検討の粒度が「アプリ会員を増やす」「ECサイト活用をできるようにする」といったところに留まっています。「アプリ会員が増えている状態とは？」「ECサイト活用ができる状態になっているとは？」、また結果として「上げるべき売り上げ・利益が上がっている状態とは？」を丁寧に定性・定量で定義し、それぞれに必要な「施策」を設定していくという活動が必要になります。
事業目的達成のためのプロセスが明確になり、一連のシナリオとして成立しており、そのシナリオの成否が判定できるKPIが立っていること。これが開発フェーズに入ってから迷走しないようになっているかを測定する、いわば「開発成功に向けた定性的なKPI」と言えるのではないでしょうか。
プロジェクトの現場では、コストの制約、時間の制約、人の制約から「何かを止める・捨てる」という判断をすることが多くなります。この「やめる」「捨てる」の判断は基準がないと難しい。そしてその基準とは、事業目的達成への関与度であるべきです。
この「止める・捨てる」の判断基準になり得るところまで、KPIは考え抜かれているでしょうか。事業目的達成に向けたシナリオが練られているかは、プロジェクトの成否を決める重要なキーの1つになっているように思います。
次年度の計画を立てる時期こそ改めて、設定されているKPIを見つめ直し、シナリオについて考えてみてはいかがでしょうか。本当に達成したい目的に歩んでいく準備はできているだろうか、精度は高められているだろうか──それらを確かめる、良い機会になることでしょう。
加藤 彰浩
（業務・システムコンサルタント）
株式会社セブン‐イレブン・ジャパンを経て、2006年にベネッセコーポレーションに入社。採点サービスの物流基盤デジタル化プロジェクトを皮切りに、新規サービス立ち上げおよび既存サービスの維持・改訂におけるPM/PMOや商品責任者として、戦略立案から企画推進、システム開発、業務運用構築までを一貫して手掛ける。2022年11月クラスメソッドに参画。prismatixのコンサルタントを担当。
この記事をシェアする
プリズマティクスのサービス
Keyword
Follow Us
