技術広報のKPIとKGI、技術広報の問題と課題
こんにちは、緑川です。
「技術広報はKPIを設定するのが難しい」という話をよく耳にします。それはその通りだと思いますし、数値の指標は組織によって事情が異なると思いますので、インターネット上に皆が納得するようなKPIはないんじゃないかと思います。それよりは「これが正しいKPIだ」と自分で信じて動けるのが大事な気がしますので、今回は少しでも正しいと信じられるようなKPIについて自分の考えをまとめておきます。
技術広報のKPIとKGI
「技術広報としてKPIをどうするか?」というのは上記の通りよくある話で、検索すると結構な数の記事が出てきます。記事の中で、KPIとして書かれる項目は以下のようなものがあります。
技術ブログの投稿数
イベントの開催数
SNSのフォロワー数
サイトのPV/UU
いずれかをKPIに設定している方も多いのではないでしょうか? 実際に私も「技術ブログを週1回投稿」「イベントを月1回開催」をKPIにしている時期がありました。ただ、これって本当に正しいKPIだったのか? というのが今回の記事の発端です。
KPIの定義
まずはKPIの定義を確認してみましょう。
わかりやすいですね、というよりこれが既に問いの答えになっているのですが、KPIというのは目標達成に向かっての「物事の経過」なんですよね。その観点で見ると、上記の「技術ブログの投稿数」や「イベントの開催数」はどこに向かう経過なのか不明です。
もし「noteのスキを100個集める」と言うのが目標でありゴールでしたら「技術ブログの投稿数」はKPIになると思います。なぜなら記事を投稿すればするほどスキは増えていくからです。
しかし、技術広報として意図している目標はおそらくそうではなくて「テックカンパニーとして、週に1回技術ブログを投稿し、技術力の高さをアピールして、採用につなげる」といった具合のものが目標になるのではないでしょうか? そうなると「技術ブログの投稿数」というのはKPIではなくKGI(Key Goal Indicator)なんですよね。「週に一回技術ブログの投稿」がKGIとなると、KPIは「エンジニア5人に執筆依頼する」とか「ブログネタを10個考える」とかになると思います(適当ですが)。
何かに向かっていく経過で出てくるのがKPIであって、KPIの先にはゴールがあり、そのゴールがKGIです。何を言いたいのかと言いますと、KPIを考える際はKGIも一緒に考える必要があり、二つで一つとした方が良いというのがまとめです。
ここをごっちゃにして考えると何がまずいのかと言うと「やるべきタスク」があいまいになっちゃうんですよね。
例えば、「勉強会を10回開催する」というのをKPIにすると、やるべきタスクは何が設定されるのでしょうか?
他社との打ち合わせの数? 企画の提出?エンジニアへの声がけ?それぞれを何を何回ほど設定するべきなのでしょうか? そうではなく、KGIを「勉強会を10回開催する」とすると、「3人に1人くらいは協力してくれるので、エンジニア30人に声をかけよう」とか、「5社声かければ、1社は共催してくれるので、50人の技術広報に声をかけよう」とかがKPIになりそうです。
ただ「勉強会を10回開催する」というのがKPIでも、目標次第ではいいと思います。例えば、KGIが「タレントプールにエンジニアを100人集める」とかだったら悪くないですよね。勉強会を開けば、プールが溜まっていくので。
問題と課題
似たような話題で「問題」と「課題」があります。問題と課題についての解説は記事がけっこうあるのでググって欲しいのですが、次の記事は両方の違いだけでなく、使い分けができないと起きる失敗についても解説しているのでおすすめです。
簡単に書くと、問題というのは「現時点」が「理想の状態」に行けないような何かしらの障害がある状態のことを指します。理想の状態というのが「技術ブログが毎日更新され、多くの人が習慣的にブログを毎日見にくる」とします。そうなると「社員が技術ブログを毎日書いてくれない」というのが問題になりそうですね。
課題というのはその問題を解決するために行うことを指すので、要は課題というのはタスクに近くなります。「社員が技術ブログを毎日書いてくれない」という問題に対して行えることは、「技術広報を雇うための募集を考える」とか「技術ブログを書くメリットを周知する」とか「締切のアラートをならす仕組みを作る」とかがあり、これらが課題になります。では、課題とタスクの違いはなんやねんという話になりますが、それはこの辺りの記事を読んでいただくと参考になるのではないかと思います。
こちらもKPIとKGIの違いのように、問題と課題の2つをごっちゃにしてしまうと、問題解決のための行動に注意がいかなくなり、考慮漏れが起きるので問題解決が難しくなる恐れがあります。他にも個人的にはコミュニケーションミスが起こったり、方針と行動と評価がブレたりする恐れがあると思います。
終わりに
今まで特に意識していなかった言葉の理解ですが、ちゃんと理解することでプロジェクトの解像度を上げれることが多くなったと思いますので、これらを意識することはわりとおすすめです。
ちなみに私の場合、最初に与えられたKPIにエンジニア80人と話すというのがありました。いま思えばゴールはなかったのですが、ちゃんと目標を持って行えばよかったです。
この記事が気に入ったらサポートをしてみませんか?