2018.5.16

設定した目標を達成できない人、またそのマネージャーに向けて

代表取締役社長 インターン

福本 真士


どうも、未来電子で代表をしております福本です。このアイキャッチで使ってる画像お気に入りなんです。GOuniteの青いキャラクターは知ってますか?「ボン」って名前です。それをデザイナーのアッシュが代表用にと、ボンのジョーカー版を作ってくれました。
 
 
それはさておき、本題に。
今回、CHO(Chief HR Officer)の芹生からブログを書いてくれとリクエストがありました。書くこと自体、無理ではないので「イエス」という返事をしましたが、
 
 
正直、書くことがありません。
 
 
過去、定期的にブログを書いていた時期にも同じ心境になりました。その時は、正直にそれをタイトルで伝えた上で、思いつきで書いてました。
 
 
こんなにも書くことないかって時に無理やり書いたブログ
 
 
しばらくするとまた、こんなにも書くことないかって状態になりました。そしてこれを書きました。
 
 
またきたよ!こんなにも書くことないかって時に無理やり書いたブログ
 
 
で、今もまた同じ状態です。
 
 
また上記の手法をやってやろうかと一瞬頭をよぎりましたが、あまり話したこともない学生も多くなってきたので、何か少しでも読者にメリットがあること、そして代表である自分が日々こんな仕事をしてるんやでってことを書くことにします。

内容をざっくり言えば「人材開発」に近いです。そこに「プロダクトマネジメント」のエッセンスをまぶした様な内容。話を深く理解するために、下記ブログを先に読んでおくと効果的かもしれません。
 
 
若手経営者がオーシャンズ11から学ぶべき「戦略、作戦、戦術、兵站」について
 
 
読みましたか?
 
 
では、始めます。
 
 

設定した目標を達成できない人、またそのマネージャーに向けて

まずはじめにお断りを入れておきます。
 
 
実は、この内容は今回書いたものではないんですよ。
 
 
なぜなら、すでに僕のチームメンバーにこの内容は共有しており、一部メンバーはすでに読んだことがある内容になっています。もし、あなたがGOuniteチームのメンバーの場合、全く同じ内容です。
 
 
すぐ現場に戻ってください。
 
 
ちょっとくらい違う内容あるかもとか思わなくていいです。
 
 
すぐ現場に戻ってください。
 
 
では、本当に始めます。ていうかコピペします。
 
 

改めまして、設定した目標を達成できない人、またそのマネージャーに向けて

自分の備忘録として「設定した目標を達成できない人、またそのマネージャーに向けて」というタイトルで思考プロセスを残しておきます。

プロダクトマネジメントとして、全体のOKRで四半期で向かう方向性を明確にします。各メンバーが責任をもって、持ち場での仕事を計画し、各々計画通りに進められればそれに越したことはありません。しかし、経験もスキルもバラバラなメンバーが集まるチームで、経験が浅いメンバーにとってはKRの達成があまりにも遠く感じたり計画が立てられなかったり、立てたとしても適切に追っかけられないという問題は必ず発生します。それをどう改善していけばいいかを追って説明していきます。
 
 

前提が分からないと理解が進まないので、こんな感じでパラグラフの合間に副音声的に解説していきますね。

前提として、GOuniteチームが次期四半期の目標設定を行うタイミングの話です。また、今後誰かの目標管理を行う人のために、自分の考えをシェアしたので参考にしてねという内容です。

目標管理手法として、GOuniteチームではGoogleでも使われている(と何かで読んだ)というOKRという手法を使っています。そしてGOuniteチームは、外国人のエキスパート人材から新卒まで入っているチームなので、様々な角度から発生してくる問題を、先を見越してしっかりマネジメントしていくぜ的な話になっています。いますでにマネージャーをしてる人には少なからず参考になる部分があるのではないでしょうか。

また、「プロダクトマネジメント」と書いてありますが、よく誤解されるのがプロジェクトマネジメントとの違いです。分かりやすい説明が別のサイトにあったので引用しておきます。

プロダクトマネージャーは、「何を作るか」「なぜ作るのか」に責任を持ち、プロジェクトマネージャーは、「いつまでに作るか」「どうやって作るか」に責任を持つ。

別の言い方をすると、それぞれ下記のような視点の違いがある。

プロダクトマネージャーの視点
・ユーザー課題の解決
・技術的実現可能性
・経済性(ビジネスモデル、4P整合性)

プロジェクトマネージャーの視点
・品質(要件の充足と不具合の少なさ)
・開発コスト
・リリーススケジュール

いずれもプロダクトが世にでるためには必要な役割でオーバラップする部分がありつつも、必要とされるスキルやマインドセットは相当異なる。

プロダクトマネージャーとプロジェクトマネージャーはどう違うのか

 
 

OKRが各メンバーに渡されるまで

プロダクトマネージャーは、四半期が終わった時点での目標である「O」と、その目標達成の鍵となる「KR」の設定をします。Oは定性評価で問題ありませんが、KRは測定が可能になるように定量的に把握する必要があります。ここで決まった内容が全体で次期四半期に目指すべき方向となります。プロダクトマネージャーは完成した全体のOKRから、実行ベースでの優先度を決定することになります。
 
 
それから各チーム毎に、チーム全体のOKRを理解してもらい、月毎のOKRをチームメンバー全員に作成してもらいます。各チームのメンバー全員に作成してもらう意図は、各々が描いている優先度のズレを管理者が認識するためです。マネージャーは、メンバー毎のOKRが出来上がったらチーム毎に招集し、自分が作った月別のOKRの提案をメンバーから受けます。そこで優先度のズレを調整し、OKRとして管理者が再設定します。それで出来上がるのが最終決定したOKRです。
 
 

なぜ優先度のズレの調整が大事かというと、2つのレイヤーから物事を考えなければいけないからです。プロダクト(製品)としてはすでに稼働しているので、顧客もいますしサービスをすでに提供しているという側面があります。単に新しい機能を作るという優先度だけではカバーできません。オペレーションが発生しているからです。

サービスに関するほとんどのことはサービスチームがカバーしていますが、サービスチームのメンバーもユーザーの声の代弁者としてプロダクト開発に関わりますし、またプロダクト開発メンバーもサービス提供の中でオペレーションを持っています。リソースが少ないですから、みんなあれもこれもやってます。「いま、一番何が大事なのか」がブレるとテンヤワンヤになってしまいます。だから優先度が大事。これが前提となるプロダクト開発とサービス提供のレイヤー。

そしてその上のレイヤーが、プロダクト開発の中でのレイヤーです。作る側にはクリエイティブとテックの2つのチームがあります。この2つのチームは密接に関わっています。GOuniteは初期段階なのでデザイン・ドリヴンで開発を進めています。単にこんなん作ろうってゴリっと決める話ではなく、リサーチ・ブレスト・コンセプト・意思決定・プロトタイプ・検証・デザインなどの決めなければいけない内容に合わせて効果的なお作法に則って進めます。それが出来てはじめて、テックに引き渡して実装です。

しかし、ここもまたリソースが少ないので、「新しく作る」ことと「一度作ったものの改善」が同時に走っています。これがプロジェクトマネージャーが優先度を管理しなければいけない理由です。

OKRの管理はQiita:Teamを使っていますが、スプレッドシート版をシェアしますね。中身は消していますのでコピーをしてから使ってください。
OKR管理シート

 
 

経験者と経験が浅いメンバーの動き方の違い

次に、完成版OKRから各メンバーにKRが渡されますが、ちょうどこの段階から、経験やスキルがある人とそうでない人の差が生じます。経験者であればこのKRを実現するために、どのような手順で何をしていけばいいのか、その道筋がみえるので自分のやるべきことを計画に落とし込むことができます。そして彼らは計画を実行するために必要な準備を始めます。実行が始まるとすぐさま上手くいかなかったことの問題の把握と改善が始まり、徐々にKRの達成に近づけていきます。この経験者が行う仕事の流れをレイヤーで分解すると、OKRのOが「戦略」。KRが「作戦」。落とし込まれた日々の行動が「戦術」。そして、戦術の実行のために必要な準備が「兵站」と表現できます。
 
 
しかし、経験が浅い人の場合は同じようにやっても上手くいきません。なぜなら、KRの実現のためにまずは自分が知っていること、試したいこと100%の計画にしてしまうからです。そして、試したいこと100%計画が実行フェーズに移り、実際に試して上手くいかなかった時には、「やめる」か「違うやり方に変える」かのどちらかを選択をしてしまいます。おそらくこの時の思考は、「これは意味がなかったからやめよう」や「これよりも、もっとこうやった方がいいんちゃうか」という思考になっていると思います。「これよりも、もっとこうやった方がいいんちゃうか」がなぜダメなのか。それは同じ難易度の戦術が横に広がっていくばかりで、また同じ失敗を繰り返すからです。つまり問題の把握から改善までのPDCAが回っていない状態と言えます。
 
 
これが続けば1ヶ月経った時、何も前に進んでいないという現実だけが残るのです。
 
 

戦略・作戦・戦術・兵站が出てきましたねー。経験が浅い人は、いきなりすんごいことを、やろうとしてしまいます。要は、やるのはええけど、上手くいかんかった時の次のアクションでミスるという話ですね。

 
 

実行する戦術をレイヤーで分解し、難易度を認識してもらう

そこで、経験が浅いメンバーには難易度の高いKRを任せて放ったらかしにするのではなく、さらに細分化された管理が必要になるということです。そして、何を管理していけばKRの実現に近づくのか。そして上記までの問題をどのように解決していくのか、その問題の本質は計画された戦術毎の難易度の認識が足りていないことに起因しています。それを解決するために、現在GOuniteチームでは戦術のレイヤーを3つに分解しています。
 
 
Will(いま、やりたいこと)
Can(いま、できること)
Must(いま、やらなければいけないこと)
 
 
戦術を立てた本人に、この3つのどれかで分類してもらいます。そうするとほとんどのことがWillになっているはずです。特にプロダクト開発のように答えがない仕事の場合はなおさらです。そしてなぜWillが多いとダメなのか。最初の1週間はそのまま実行してもらえば、その理由がすぐに分かります。おそらく見事にWillだけが未達成になっているのではないでしょうか。さらにその結果に対しての次回策を示してもらうと、今回のWillをやめて、新たなWillが登場しているはずです。
 
 
これが上手くいかない原因です。
 
 

Will, Can, Mustの人材評価の管理手法の元はリクルートやったかな?どこか忘れたけど、深く知らんからおそらく正しい使い方はしていないです。目的として、正しい使い方をしたいのではなく、この言葉のニュアンスが難易度の分類に使えそうやったから使っているだけです。別に松竹梅でも守破離でも序破急でも3つで何となく意味が通じればなんでもいいと思います。

 
 
本来、Willで示したことは方向性としては間違っていません。それを深掘りしていく行動が足りていないのです。達成できなかったWillには、達成までの見えないステップがあり、そのステップには一体何が含まれているのか。その分析が必要で、分析の結果生まれた次の戦術の難易度はひとつ下のレイヤーの「Can」になっていなければいけません。そしてCanの実行を支える準備が「Must」になります。それぞれのレイヤーはそのように繋がっています。
 
 
つまり、ひとつの戦術で走り出したらそれがKRに影響を与えるまで、深掘りしてどんどん細かくして、改善していく必要があるのです。そのやり方で1ヶ月走った後には、戦術のMVP(Minimum Viable Product)が完成し、結果的に当初のWillを達成していることになります。言い換えれば、「いま、できること」をしっかり準備をして積み重ねていった先に、本当の「いま、やりたいこと」が存在しています。それはまた「いままできなかったけど、新たにできるようになったこと」とも言えますし、この戦術のMVPで見つけた成功のパラメータこそが、経験が浅かったメンバーを経験者に変えるたったひとつの方法です。
 
 

上手くいかなかったら同じWillの難易度の戦術を出さずに細分化してもらいます。それを実現するためにはどんなステップが潜んでいたのか。当然、分析が必要ですし、そのひとつひとつのステップを追う必要があります。しかし、難易度を下げることで達成可能性も上がりますし、結果的に1ヶ月後のKRの実現可能性が上がるということです。

またMVPという言葉が出てきましたが、これは「顧客に価値を提供できる最小限の製品や、それを使ったアプローチ」という意味。リーンスタートアップに登場しますね。ここでは、最も小さい結果がでるアプローチを見つけるという意味で使っています。

大事なことは、どんなことをどれくらいすればどんな結果が出るのか。それを肌感覚として理解し、自分のキャリアの糧にすることです。
戦術管理シートはこちら。中身を消しただけなので罫線とかめちゃくちゃですが、コピーをしてから使ってください。
戦術管理シート

 
 

まとめ

プロダクトのような答えがないものを追っかけていく仕事だけではなく、どんな仕事にも戦術の難易度は存在しています。それを管理者が適正に見抜き、教え・導き・気づかせてあげることが必要です。そして、メンバーの評価のために両者の間で目指すべきものの認識を完全一致させ、やると決まっていてやったことを「行動評価」、達成できたことを「実績評価」としてメンバーの能力を管理していくことで、確実に良い方向に向かっていきます。
 
 
それでは、私は今日も持ち場でがんばります。
 
 

やると決まっていてやったことは行動評価で、達成できたことは実績評価になる。行動評価が伴っていないメンバーには、タイムマネジメントを実施します。行動をさらに細分化して時間単位で何がブレているか調整していきます。以上、コピペはここまでですね。

 
 

最後に

Noを言うことが仕事であるCEO兼プロダクトオーナーである自分、ビジョンを実現しながら技術的ビジネス的に実現可能な製品を作るプロダクトマネージャーの自分。この2つの役割は相反する存在です。本来、現場に出るべきでない役割の自分が現場におりて、現場にどっぷり浸かるのはやっぱ楽しいなと思いながらも、この役割を任せられる人材の育成が追いついていない自責の念と戦いながら働いています。
 
 
学生のみなさんもまずは社内で経験やスキルを身につけて、評価され、是非GOuniteチームに参加してください。あなたの挑戦を待っています。


この記事を書いた人

代表取締役社長インターン

福本 真士