事業KPIにヒットする開発を実現するために乗り越えたこと

はじめに
そもそも・・・
実際に接続してみて・・・
「事業KPI」と「開発アウトカム」を接続するにあたってのぶちあたった課題
課題①『責任範囲の拡大』
課題②『指標への認識変換』
課題③『BizとDevの協働体制』
おわりに

はじめに

　２度目まして、リンクアンドモチベーションでプロダクトマネージャーを行っている原田です。

（一度目の記事は、こちらになります。）

最近は、日本の情勢が心配になるような出来事が多いですが、皆様いかがお過ごしでしょうか？気候的にもコロナの状況的にもみなさま体には充分にお気をつけください。

　さて、今回も前回の延長戦のようなお話を記載させてもらえればと思います。

そもそも・・・

　前回、「タスク」志向なチームが「ミッション」志向に変わるまでの道のりについて少しお話をさせていただきました。当然、組織の文化を変えていくってとっても大変ですが、大切なのは「何に向けて」変わっていくか、というところです。「ミッション」といえば聞こえはいいですが、要は「行った開発が事業を成長させる」チームになれるか、が大事なわけですね。

　そこで重要になってくるのが、いかに「事業KPI」にヒットする「開発」を行えるか？というところだったんですが、まあここが難しいのなんの。エンジニアの方に「楽しくものづくりしてもらいたい」「作ったものが顧客に届くのを当たり前にしたい」と思いはあるもなかなか実現できない・・・・・みなさまも同じような経験あるんではないでしょうか？

　今回は、同じような悩みを抱えている方のお力に少しでもなれば、と思い記事を書かせてもらいます。今記事は、「よくあるセオリー」的なお話ではなく、どちらかというと、接続するにあたって弊社でおこった苦悩やその乗り越え方といったある種「泥臭い」ところのお話をメインにできればと思ってます。

（弊社CTOの柴戸が、過去にBiz・Dev・経営を結節するために行ったこともこちらの記事にありますので併せて読んでいただくとより解像度が上がると思いますので是非！）

実際に接続してみて・・・

　より「事業成長」のための「開発」をおこなうという文化ができたことによる、メンバー内での議論のレベルや、Biz-Devの協働感がかなりでてきており、過去に比べるとより「顧客に届く」開発や、「事業成長」につながる意思決定ができてきているのではないのかな、と感じます。（まだまだ道半ばですが・・・）

　また、なによりエンジニアが「エンジニアリング」や「ものづくり」そのものを楽しめることが増えてきたのも大きな変化です。実際に、他チームの「継続率の向上」をミッションとしたチームでは、社内で利用している「ヘルススコアの変数になり得るものを自分たちで調べ、そこにヒットするような開発をするようになる」などエンジニア主導で文化が変わってきています。

（開発組織がどのような体制になっているか、は弊社有田があげたこちらの記事をご覧ください！）

「事業KPI」と「開発アウトカム」を接続するにあたってのぶちあたった課題

　さて、前置きはここまでにして、本題に入っていければと思いますが、二つの指標（事業側の指標と開発側の指標）をつなげるにあたっては、大きな課題が以下３つがあったんですね。

①『自分たちが追う責任の範囲』が狭い

②『妥当な目標数値の設定難易度』が高い

③『BizとDevの距離』が遠い

課題だけ見ると、「本当に解決できるの？」とおもいますよね。僕も取り組む当初は思っていましたが、泥臭い活動のおかげで少しずつ解決をしていっています。これらを解決するために行ってきたこと・行っていることをご紹介できればと思います。

課題①『責任範囲の拡大』

　さて、早速一つ目からですが、皆様も経験あるかもしれませんが、なかなか開発チームが営業チームの受注目標やヘルススコアの改善など、事業KPIを意識する機会は少ない・難しいですよね。そもそも、自組織で開発しているものが、事業KPIの何にヒットしているのか？という関心を作るの難しいものです。つまり、「開発チームの責任」と捉えている範囲が「開発」に閉じてしまっているわけですね。

そこで、開発するにあたっての指標となる「開発アウトカム（開発の成果指標）」に「事業KPI」を置くようにしました。例えば、「今機能開発によって、〇〇％の受注ヨミ向上」や「〇〇社のヘルススコアの改善」などですね。そうすることで、開発する際により「なぜこの機能を開発するのか？」の「なぜ？」の範囲を「開発」だけではなく「事業」に意識を持ちやすい状況を強制的に作りました。とはいってもなかなかこれをするには、準備が必要です。

まずは、この指標を入れることを受け入れれる・納得できるチームづくりです。

（詳しくは前回投稿したこちらの記事に記載していますので、お手隙の際にお読みください）

　そして、土台となるチームができたらいよいよ指標を立てていくことになりますが、ここでの一番の注意点は「Uncontrolable（変えられないもの）」な指標にしないこと、です。私が所属しているチームは、「新規顧客の拡大・市場の開拓」をミッションとしているチームなので、営業指標に関わるものを置くことになったのですが、最初張り切りすぎて「受注〇〇社」っておいてしまったんですね。けど、「受注」って一言で言っても必ずしも欲しい機能があれば受注するわけではないので（先方社内での都合や、弊社との関係性など）

掲げた目標を達成できず、チームのモチベーションが少し下がる時期もありました。

　大切なのは、「Controlable（変えられるもの）」な指標を置くことを意識する、ということです。例えば営業に関する指標でも「受注ヨミがどれくらいあがるか？」など「開発が影響を及ぼせる範囲を明確化」した上での指標を立てることが大切です。そうすることで、開発としても指標の達成可能性があがりますし、なにより「顧客がこれをより魅力的に感じるためにはどういう作りにしたらいいだろう？」など、より顧客視点が強まったり事業視点が強まったりするという効果も得られました。

課題②『指標への認識変換』

　２つ目の課題は、『妥当な目標数値の設定難易度』が高いということです。皆様もありませんでしょうか？「この機能で閲覧率上げたいけど実際どれくらい上がるんだろう」「今機能の利用率これくらいいってほしいけどこの数値って妥当な数値なのかな」など。まさに自分たちもここにぶち当たったわけなんですね。

　ここで重要だったのは、指標の捉え方を変える、ということでした。具体的には「指標＝最初から完璧にしなければならないもの」から「指標＝育成していくもの」という転換です。自分も含め、多くの方が「正しい指標で、正しい目標値を、初めから、一発で置く必要がある」と思いこみがちですが、それができるのはなかなかの神業ですね。（できる人がいたらぜひ弟子入りさせてください！笑）

大切なのは「try&errorを繰り返しながら、指標・目標値を共に適正値に寄せていく」という感覚です。スポーツもそうですよね、最初からホームランが打てるわけなくて、練習を重ねていくうちに精度が上がっていく。それと同じ要領です。ある種、適切な指標をおけるようになるための仮説検証を繰り返し、積み上がった学習知で精度を上げていく。その意識が大切です。

　ちなみに弊社では「ムーンショット」と「ルーフショット」という指標を立てる文化が少し前からでき始めましたが、開発チームによってはさらに高みの「ギャラクシーショット（造語）」なんてものを作って、特大ホームランを狙う（見事に失敗していますが笑）チームがいたりもします。

課題③『BizとDevの協働体制』

　３つ目は、「よくあるBizとDevの距離が遠い」問題ですね。上２つを解決できてもここの距離が遠かったら、自分たちが開発できたとしても顧客にデリバリーするまではいかなかったり、Bizサイドから開発物のリクエストくるけど、作ったときのBizサイドの動き方がクリアにできていなかったりなどなど。しかし、事業を成長させるためには、当然開発だけでは難しく、時としてBizサイドとの連携も必要になってくるわけですね。

　そこで我々は、

①Bizサイドとのプロダクトに関する話をする定例の場を持つ

②開発するものの要件定義を一緒にする

③一緒に開発アウトカムを決める

の３つのアクションをとってみました。まず、Bizサイドとの時間を抑え、そこで「どうすればよりよいプロダクトになっていくのか？」というかなり大きめな上段の話から「どのような機能が必要か」などの各論までを話す場を設けました。

「え？そんなことすぐできるの？」「うちは無理だよ・・」と思うかもですが、ここに至るまでには当然簡単な道のりではありませんでした。

非テック企業出身であったこともあるので、まずはしっかりと「開発」というものにどういうことをしているのか・１つの機能開発にどれだけの工程がかかっているか、など「開発」に対しての興味関心や理解を持ってもらえる働きかけを行い続けました。「知らない」が故にできている壁は実はきっと多くあるんだな、と学んだのもこの瞬間です。

　さて脱線してしまっていましたが、プロダクトについて話し合う場を作った後は、一緒に「何を作るのが顧客の課題を一番解決できるのか？」という要件定義もBizサイドと一緒に行うことも併せて始めました。普段、多く顧客に触れているからこその観点などを当然Bizサイドの方々は多く持っていて、実はこの行動によって得られる効果って結構大きいです。逆にBizサイドはBizサイドで、自分たちが欲しいと思っていた機能についての意見ができるので、リリースされた後の「顧客に届ける」アクションへのコミットメントが格段に上がります。

　ここまでくると最後は簡単で、ちゃんとリリース後の目標値も一緒に握る、ということが重要になってきます。大切なのは、「どちらかがだけが責任を負う」ではなく「双方ともに責任を負う」という関係性を作るということがとても大切です。「共通目標」を追う状態を作ることが「協働」に向けた一番重要ポイントです。