技ビス : 技術、ビジネス、スタートアップ

技術、ビジネス、スタートアップに関する情報と話題とアイディアと事例

誰得advent calendar 25日目:戦略と数値管理と組織構造の整合性って難しいよねって話

誰が得するのかわからないadvent calendar 25日目。

年末のぎりぎりになって仕事が増えて作文している場合じゃなくなったので25日目まで飛びました(苦笑)。難易度はそんなに高くなかったけども、人生において「harajuneしか頼れる人が・・・・」案件が未だに発生するのは生き甲斐があるというものですね・・・

以後書くことは実例をもとにしてはいますが、15年分くらいの話を圧縮して書くので特定の組織の話ではないし、サラリーマンで所属している会社の話は辞めるまで書かない主義なのであんまり現職とは関係ありません。

戦略と管理会計と組織構造がイマイチだとどうなっちゃうのかという話

これ、嘘みたいな本当で結構ありがちなんですが、ひとつの製品を作って売っているのに費用がAチームについてて売上がBチームについているみたいなトンチンカンな数値管理している会社というのはまぁまぁあります。もちろん、コストセンター・プロフィットセンターみたいな考え方はあって、意思を持って設計している場合は良いと思うんですがなんとなーくでやっているケースも結構多いように思います。ここ適当でも、決算はできるし納税もできるんで死にはしないという意味で問題が発覚しにくいところではあります。

で、最もイケてないなと思ったやり方してた会社の事例をここで書いてみようかなと思います。

まずわかりやすくダメだったのは、ひとつのプロダクトの売上責任(販売+カスタマイズチーム)と費用責任(研究開発)がすっぱり別れて別々のチームにアサインされてました。なんでダメだったかというと、研究開発側に商品を良くするモチベーションわかないんですよ。さらに、販売+カスタマイズチームが売れない理由を研究開発に求め始めるんですね。もとがダメだから売れないと。

なんでこんなことになるかというと、研究開発側の成果を測れるものがないので、くっそ忙しいと改善なんてものは後回しになるわけです。右から来たものを左に流すことで手一杯。評価もされないような改善活動なんて知らんわけです。さらには、「売れないのは販売がダメだからだろ?もっと工夫したらどうなんですかね?」みたいな話にもなりかねない。

逆に、販売+カスタマイズの側からすると売ってくることしか考えてないので、製品をどう良くするかということを考えないんですね。カスタマイズと言っても御用聞きが中心なので顧客仕様をもとにカスタムするところまでで、それを製品にフィードバックしようとか思わないわけです。こうなると「俺達は頑張っている。売れないのは製品がいけないからだ」みたいな話になるわけでした。

傍から見ていた感想としては、「ぶっちゃけどっちの言い分もまぁまぁ正しくて、そもそも数値管理も組織構造も壊れていて、なんだったら製品戦略も無いので迷走している」という感じなのでした。

戦略はどこにどう投資を張るかという話

企業活動の基本はお金を投資して増やして戻すです。株主は出資金を投じて増やすことを期待するわけですし、社長からするとどこにどう人とお金を張るのかという話ですし、チームだとすると役割分担かもしれないし、個人だとすると仕事をこなす順番かもしれません。いずれにしても、いつどのタイミングにお金・人・時間を使って、それを増やすかという点で共通しています。

どうリソースをはるかの決め方は自由です。気分で決めるというのも無くはないでしょう。正解のない世界です。ただ、最終的に何にいつどのくらい張るのかを意思決定されないといけません。

戦略が実現可能なのかを数値管理・計画する

KPIだなんだかんだと何でも可視化することが推奨される昨今ではありますが、数値管理すればいいって話じゃないんですね。「このボタンの変更でKPIが5%リフトする」vs「このキャンペーンでMAUが5%リフトする」で戦わせてもどっちが正しいかなんてわからんし、いわんやそれがプロダクトにどう貢献するかとかよくわからないわけです。そんな細かい話しててもだいたい議論は混迷します。

数値管理は戦略ありきなんですね。こういう方針で進めていこう、それであればこのKPIをフォローすべきであるというように決めていかないと、そもそもKPIの重要度が決まらないので合理的判断は不能です。声がでかい人がきっと勝つパターンですね。こうならないためにも、まずはハイレベルでの戦略に対する合意が必要になります。

もちろん、あとあと重要なKPIが見つかることもあります。=色々ためしてみて「あれ、意外とこれって重要じゃない?」となることは常に発生します。その時は、一度戦略に立ち返って物事の重要度を議論するべきです。新しく重要そうな数字が見つかったということはなにかしろの戦略上の考慮漏れがあった可能性があります。戦略が変わるとKPIの優先度も変わり自然と新しいKPIを取り込むことができます。

実際、戦略と数値管理は両輪で行ったり来たりします。

戦略と数値の両面から組織をデザインする

組織をデザインするというのは、戦略目標を達成するために重要な数値を実現していくためにデザインされます。その他のアセット(工作機械であるとか、従業員の知識や練度であるとか)や規制(免許がいるとか内部統制とか)の影響も受けるのでシンプルにはいかないんですが、基本は戦略と数値管理にそってデザインすることになると思います。

ここが失敗すると冒頭の例のように、みんな一生懸命働いているのに、本質的な成果が出ず、なんだったら軋轢が生まれることになるんでした。これを防ぐためには、チームや組織ごとのResponsibilityを明確にするとかあるんですが、そのあたりは色んな人が書いているので省略するとして、ここではResponsibilityが全体として充足しているのか・つながっているのか・やバランスが正しいのかという点について強調したいと思います。

組織デザインの超基本的な考え方のひとつとして、誰かのアウトプットは誰かのインプットになるというのがあります。冒頭のイケてない例で言えば、研究開発が作った製品が、販売・カスタマイズにわたって、顧客に届くという流れですね。つまり、ほとんどすべてのチームのResponsibilityはつながっているわけです。QAや経営企画のような側方支援系も、だれかのアウトプットやインプットをスムーズにするという形で寄与していきます。なので、まずどこがどうつながるのかという当たり前のことがつながっているのかということを見る必要があります。

しかし、本当に冒頭のイケテナイ例のresponsibilityはつながっていたのでしょうか?実際のところ顧客フィードバックを製品に反映するという戦略上重要なResponsibilityがどこにもOwnされていないのでした。顧客フィードバックを取り入れることが重要だなんてことは誰でもわかってるわけですが、じゃぁ具体的にどう優先順位を判断するのか・顧客フィードバックが適切に反映されていることをどう確かめるのか、そういうことがすっぽり抜けていたわけですね。

こういう感じなので、結局の所まったく改善が進まないのでした。これは戦略上の欠陥なので、まずはどうやって顧客のフィードバックを取り入れるようにするのかという戦略の修正から入らないとなりません。

そしてこれら全てが整ったとして、最後はバランスです。どこかのアウトプットが異常に強かったりすると後工程が詰まったり、他のチームのアウトプットを毀損する可能性があります。よく言われている例だと、ガンガン広告打てばユーザは増えるけどユーザ体験は損なわれるし、CVRがめちゃくちゃ悪くなっているという自体にもなりかねないです。一方で、物事を加速させるために意識的に人を投入するということもあるかもしれません。いずれにしても、お金・人・施策の量や質はバランスが最後は担保されていないといけません。

戦略と数値管理を組織で実装する

結局は戦略の部分の合意を取れるかどうかというのが大体の場合において重要です。結構、細かい話したがる人多いんですが具体的に何をするかというよりは、何にどのくらい金をはって何を得たいのかというところのほうが大体の場合重要です。その合意があればなんの数字を重要視すべきかというのはある程度明らかになります。

そして、その戦略を実現可能な計画に落とすのが数値管理です。戦略がワークしている様子をどうやって図るのかを明らかにします。時として、数値の状況から戦略を修正することも考えねばなりません。

そして、その数値をどう組織に実装するか。ここが最後の難関です。戦略と重要な数値がわかっていれば自ずとなすべきことがブレークダウンされ、組織構造にもそれが反映されていく・・・はずではあるんですが、なかなかそこはストレートに行かないところが悩みどころですね・・・・