you88blog

広告とかwebとかプログラミングやら

メニュー 閉じる

カテゴリー: 組織論

施策立案を仕組み化する

よくありがちなメンバーからも施策をあげよう

チームでプロダクトを開発しているとよくメンバーみんなが納得する施策をとか、メンバーみんなで施策をあげようと出ます。一見きれいなことに見えますがこれは個人的には危険な状態だと思います。メンバーの方に施策が向いているからです。開発チームが施策を行うのはユーザーのためであり、チームメンバーのためではありません。そういう意味ではメンバーの納得は必要ないです。

またプロダクト開発は不確実なことの実証実験でもあるので全員納得したのがいい施策とは限りません。むしろ誰か一人の突飛押しもない施策が意外な成果を出したりもします。

僕は昔、こういうみんなで施策をあげようとかの意見が出るとどうも民主主義的な、かつ自分たちがユーザー自身と勘違いしているんじゃないかとちょっと抵抗感がありました。ただ最近は

  • 各人が集中的に施策を出す範囲を分類する
  • 施策出しと優先順位決定を分ける

をし、メンバー全員で施策を出しながら全体ロードマップを逸脱しないで圧倒的な個人が施策を考えるより良い施策立案ができるんじゃないかと思うようになりました。ちょっと今考え、最近うまく言ってるなと思う運用をまとめてみました。

いい施策はgoodな施策でもbetterな施策でもなくbestな施策

まず前提としていい施策とはなにかについてここでの個人的な見解をまとめてみます。単体で見たときたしかにあったほうがいいよねという機能、施策はめちゃくちゃあります。ただプロダクト開発のリソースは限られています。プロダクト開発における施策立案は施策を出すこと自体よりもこの限られたリソースでどの順番で開発していくかのほうが実は選択肢がたくさんあります。

プロダクト開発は便利機能をつけることではない

またプロダクト開発ではユーザーの声などを吸い上げて便利機能をつけていくのが理想ではありません。ユーザーは眼の前のニーズしか気付かないし、プロダクトは何年にも渡って運用されます。プロダクトの開発は事業として捉えて将来的にどういうプロダクトになったらよりユーザーに価値を提供できるかから逆算していくように心がけています。より便利にしていくことと長期的どういうプロダクトにするかから逆算していくのは重なるところもありますが=ではありません。逆に直近の声に偏りすぎると時代の動きに乗れずに時代遅れのプロダクトになる可能性もあります。例えばPCからスマホにwebサービスがシフトしていく中でPCの既存ユーザーの声を聞きすぎて新スマホ発サービスに市場を取られたサービスはこれに当たるかもしれません。

PMとメンバーの見ている情報の差

となったときにPMはより広く、そして長く視野を持たないといけません。そして各実装者、メンバーのやっていることを把握しているPMのほうが各メンバーよりもこの視野は広くなりがちです。逆に視野の深さは各メンバーのほうが良くなります。ここにギャップが生じがちです。例えばプレミアム会員を伸ばすKPIをもったメンバーからはもちろんプレミアム会員を伸ばす開発施策が上がると思いますが新規ユーザーを伸ばすのが全体の優先順位的に高い場合、後者を優先したほうがいいでしょう。しかしプレミアム会員を見ているメンバーがその全体戦略を把握していないときに自分の施策が不当に却下されたように思います。これはどちらが悪いということではなく、全体の中でなにを任しているのかをコミュニケーションできていないからです。

全体像を伝える

なのでPMとメンバーが施策立案で互いに不満を感じるパターンの一つに戦略と戦術で視点が違うというのがあると思います。施策は優先順位が重要で単体で良くてもより良いもの、今やらないといけないことをやります。そしてそれは全体像の見やすいPMの意見と専門分野で深く見やすいメンバーで視点や情報が違うため齟齬が生じます。ここを埋めるためにはPMはメンバーに全体像がなにで今なにを優先順位上位に持ってきているか、他の施策の進捗がどうかを伝える必要があります。

施策の分類とそれぞれどこの人間が一番出しやすいか

どちらが優れているという話ではなくそれぞれが見やすい分野の施策をあげ共有することが大切です。このへんのほうれんそうの大切さは脱出ゲームをするとよりわかりますwまとめると

  • 施策立案は優先順位ぎめが大切
  • その優先順位は全体像が見えている人間がスピーディーにやるべき
  • しかしその全体像、優先順位をメンバーに共有するのも必要
  • PMが戦略、優先順位を各深い施策立案をメンバーにと分ける
  • メンバーに対してどの分野の施策立案をしてほしいか明確に伝える
  • その施策が全体の中でどういう位置づけと考えているか明確に伝える

が大切なのかなと思っています。もうちょい具体的に言うと僕はゴールとなるKPIとその構成要素を書き出し、どの数字、分野の施策を立案してほしいか提示しています。そして各人があげたものを優先順位付けし、開発のロードマップに起こしています。圧倒的な個人がいてもSEOで細かい施策やデザイン面でのUX改善など一人で全部をカバーするのは現実的ではありません。この施策立案はメンバー各人に任せたほうがより詳細に詰めれますし、PMのスキルセットに依存しないので常に専門的なロードマップをしけます。よくみんなで施策立案するとなるとこのプロダクトの施策何がいい?となげがちですがちゃんと全体像と意図を伝え、どこを集中的にお願いしたいかを明確化することによりそういうことじゃないんだよなーを防げます。

以上最近思っていて僕も気をつけなきゃなーという半分自戒でした。

営業チームと開発チームが仲良くするために大切だと思うこと

広告のアドサーバーの開発を見ていると広告という分野なのでビジネス面と技術面両方見ることが多いです。うちでは営業チームと開発チームがありますが、大抵の会社ではスーツとギークじゃないですがあまり仲良くならない部署同士だと思います。結構この2つのチームのコミュニケーションの設計をどうするかはかなり悩んでいる所で今のところうまく行っているようなきがするので1事例としてまとめてみます。

なぜ仲が悪くなるのか?

いくつか要因はあると思いますが、まずは使っている用語が違うのが大きいと思います。コミュニケーションにコストがかかったり齟齬が生じるので仲が悪くなる。これはすごく分かりやすいけどなかなかビジネス側がプログラミング勉強したり、エンジニア側がクライアントの要望などを把握し切るのは難しいです。僕はつなぐ立場なのでプログラミング勉強したりクライアントとのやり取りを見たりしていますがそれを全てのメンバーがやるのは現実的ではないかと思います。僕はどちらもたまたま好きだったからできたけど。

またKPIが2チームで違うと争いの種になります。例えば営業チームは売上をKPIにしているが開発チームはcv数をKPIにして営業チームは効果とかではなく、とにかく案件を取ろうとして開発チームは効果があがりそうな案件への対応を頑張ったりしちゃいます。このKPI、目標を一致させてアプローチだけ違うという状態にしないといけないのも難しいところです。

3つ目は時間軸の違いで営業チームは直近の案件にもちろん注力しますが開発チームは中長期の効果改善に注力しがちです。直近の案件をテストで使い、新機能を試したい開発と直近の案件でそんなテストなんかせず、現在の機能で確実に効果をあげたい営業チームなんかもよくあるパターンだと思います。

どう対処していくのか?

まず前提として大切なのは別に営業と開発に限ったことではないですが相手の職種を理解しようとする姿勢が大切かと思います。(いきなりエモーショナルなところいきますが)相手チームのKPIや文化、言語の理解をすることが前提。そのうえでやらないといけないのは2チームの目標や言語を統一していくこと。1つ目の言語の違いは用語表を作り、できるだけ2チームの言語を統一する必要がある。

2つ目、3つ目の目標設定は時間軸やアプローチ方法が違っても最終的に同じになる目標を設定しないといけない。

爆弾ゲームがはじまると組織は途端に高コストになる

最近組織運営で気をつけているのが、組織のメンバー同士でタスクの受け渡しをすることである。これが現場判断で適正な人間に回っているのなら良いがそうでない場合、非常に問題だと思っている。これを個人的に爆弾ゲームと呼んでいる笑

どういった事象のことかというと下記2種類あると思っている。

  • 誰がやっても良い評価につながらないタスクを他人に回すことで自分のタスクを減らす。
  • 事前に判断が必要なものを完成後に判断する

前者は分かりやすく悪いので中間管理職と部下、先輩後輩以外は実はしにくい。まあこの2箇所だけでも起こると面倒だなんだが。分かりやすい前者から説明すると基本的に従業員と会社は仕事の結果と給与で契約している。ただ、この結果に置き換えにくいタスクも存在はしているちょっとした雑用などが分かりやすいかもしれない。

こういったタスクは報酬を目的に働いている人からすると魅力的でないため後輩や部下に渡し、評価の上がるタスクを中心にやってしまうかもしれない。そうなるとコミュニケーションコストだけ高くなり、個人で見るとその人のタスク量は減るかもしれないが組織全体でみるとコミュニケーションコスト分コストが増える。

これは明確に上がタスクの割り振りを明示するかそういったタスクも評価内に入れるかをしないと解決が難しい。

ただこれはあまりやると普通に人間関係に問題が出るので実際にはそこまであからさまにする人間は少ないと思う。問題は後者だと考えている。後者がよく起こるのはデザインの発注の場を想像してもらえると分かりやすい。デザインで例えばデザイナーからボタンの位置を事前に確認され、そのときにちゃんと考えずできてから考えようと思ったことはないだろうか?これはシミュレーションするコストをデザインのコストで補おうとしている。

もちろん実際にできてみないとよく分からない案件はあるがそれに甘えて事前に考えないで発注や依頼をするのはコストを組織全体で考えられていないのではないだろうか?これは前者のものより非常に解決が難しい。それを事前に想定できるかは断言できないし、能力の問題もある。ただ自分だったらそこも能力の一つだと思うのであまりに多かったら普通に評価下げるなーという部分ではある。よっぽど評価者が現場を把握し、スキル、状況を把握しないといけないのでそれも難しいのだが。。。

またより難しいのが2部署をまたがるときでこうなるとお互いの部署のリーダーがどっちがやるべきか押し付け合うこともある。自分の部署に無駄なコストを持ち込みたくないからだ。その上で包括的に判断できる人間がいればいいが現場のタスクを2階層上の人間が判断するのは難しい。こういった場合依頼する側がどうしても主導権を握りやすくなる。

解決策としては個人的には個々のタスクで判断するのは諦め、部署ごとのミッションを具体的に制定するのが良いと考えている。どこまでをやってどこまでをしないか。その明示だけなら包括的に見ている人間に確認を促すこともできるはず。

© 2018 you88blog. All rights reserved.

テーマの著者 Anders Norén.