ぼくの勤め先であるGMOペパボ株式会社では1月から6月が上半期、7月から12月までが下半期という区分です。2017年も明けて「今年もがんばるか〜」と思っていたのが先日のはずなのに、気がつけば下半期が始まっていました。というかすでに7月も下旬ですね…すみませんでした。
ペパボには期ごとに運用される評価制度があって、2017年下半期が始まったので「目標設定やらなきゃ〜」「今期はどうしよっかな」「面談やりましょうか」といった声があちらこちらから聞こえてきます。期初の風物詩です。評価制度についてはすでに様々な場所で語られていて、エンジニアの評価制度について - console.blog(self);の記事に他社のものとあわせてまとめられていたのでリンクしておきます。
2017年1月にペパボの本社事業部のチーフテクニカルリードになりましたで触れた通り、ぼくは今年からひとつの事業部(当時は「本社事業部」でしたが、今では名前が変わって「SH事業部」になりました)のエンジニア組織をいい感じにするミッションを授かっていて、2回目の期初となるこの時期をどのように過ごしたものか考えていました。そして、自分を含むみんなの2017年下半期が最高のものになるようにと、表題にある「成長計画づくりワークショップ」を実施するに至ったので、その顛末を紹介したいと思います。
これまでのふりかえり
ぼくは2015年5月の入社なので、これまでに5回の期末を経験してきました。期末には、その期の評価制度の締めとなる面談があります。そこで、半年間の実績について話したり、得たものや苦労したことなどを整理し、次の半年間につなげるための時間を過ごします。「評価制度」というくらいですから、評価結果も当然あります。各自が自分の目標や実績と自己評価などをまとめた「評価資料」を作成し、面談ではそれをもとに会話を重ね、最終的な評価結果を得ます。
さて、このときにアンハッピーな事態が起こり得ます。被評価者の自己評価と評価者が出す評価にズレが生じることがあるのです。面談等の場で会話を通じて認識のズレを解消できればまだよいですが、場合によっては完全には納得できないまま評価を下されることになるでしょう。これは、被評価者にとっても評価者にとってもうれしくない事態です。
では、なぜこういった事態が発生するのでしょうか？ぼくが見聞きしたケースには、以下のような要因があったように思えます。
- 目指すべき方向が共有できておらず、あらぬ方向に突き進んでしまった
- 評価者が「そっちじゃないんだよなあ」と思ってしまう
- 目指すべき方向はあっていたが、どこまで進めば充分かを共有できていなかった
- 評価者が「もっと進んでほしかったなあ」と思ってしまう
「西に10km以上進んでほしい！」という期待に対して「北に10km」だったり「西に5km」という実績になっている、という状態です。認識のズレが原因で評価が高くならないようだと、被評価者は「せっかくがんばったのに…！」とモチベーションを下げてしまうかもしれませんよね。そんな事態は可能な限り避けたいものです。
なにを隠そう、ぼくは2015年下半期の面談に「自己評価はSです」と臨んで「じゅんくん、そういうことじゃないんだよ」と見事に散りました(？)からね…！ぼくの場合は別にモチベーションを下げることはなくて、フィードバックを受け止めて「たしかにそうだよな〜」と思えたので、よかったといえばよかったですけれども。にしても、期末じゃなくて期初に気付いていれば、もっと有意義な半年間を過ごせただろうとは思います。今にしてみれば。
じゃあ、どうすれば認識のズレによるアンハッピーな事態を回避できるのか？を考えてみましょう。ところで、認識のズレによって失敗する先述のようなケースを見たとき、ぼくは「なんかこの失敗、経験したことある気がする…」と思いました。プロダクト開発に携わっている人なら、もうピンときたかもしれません。
- 顧客が必要としていない機能を開発してしまった
- 顧客が望む機能ではあったが、品質が充分ではない状態でリリースしてしまった
こんな状況に、とっても似ていると感じました。耳も胸も痛いですね…！人はなぜ、よろこばれないお仕事に多大な時間を費やしてしまうのか… ウッッ！っと傷つくのはあとでゆっくりやることにして、ここは歯を食いしばって先に進みます。もしこれがプロダクト開発における問題と同種ならば、よく知られたプラクティスによって問題を回避できる可能性があるのではないか、と仮説を立ててみます。
プロダクト開発の心強いプラクティス
今回ぼくが取り入れることにしたプラクティスは、以下の2つです。
- (1)最高の完成予想図を描く
- Amazon流の開発術では、まずプレスリリースを作る | fladdict でいう「プレスリリース」
- インセプションデッキでいうと「エレベータピッチ」や「パッケージデザイン」
- あるいは、デモするのに充分な「プロトタイプ」
- (2)ピアレビューを行う
(1)によって、目指すべき方向があっているかを事前に確認できます。(2)によって「こうやるともっと先に進めるかも」という発想が促されることを期待します。どちらも、最近のプロダクト開発、ソフトウェア開発の現場ではふつうに実践されているような内容かと思います。むしろ、どうして今まで評価制度の運用には取り入れてこなかったんだろう、と思うくらいで。
成長計画づくりワークショップ
やってみました、ワークショップ。
まず、最高にハイな状態で2017年下半期の終わりを向かえた自分のことを想像し、すべての項目でS評価の自己評価を記入した評価資料を作成します。社内で2回に渡ってこのワークショップをやってみたところ、参加者のみなさんは15〜20分くらいで書けていて、素晴らしいな〜と思いました。イメージをつかんでもらうためのサンプルとして、ぼくの2017年下半期の評価資料をつくって持っていったのですが、ぼくは書き上がるまでに40分くらいかかりました。ぼくだけズルしてごめんね。サンプルとしてわかりやすいものにしたかったので、みなさんよりじっくり取り組ませてもらいました。
みんなの分が出揃ってきたら、それを参加者のみんなでいっしょに見てレビューをします。ワークショップの中では、このレビューのことを「MOD」と呼ぶことにして、みなさんには「じゃあMODをお願いします！」のように呼び掛けました。MODはもちろん、ペパボの企業理念であるもっとおもしろくできるの略です。すんばらしい未来の姿を描くためのワークショップなので、ネガティブなフィードバックよりもポジティブなフィードバックがたくさん出るようにと願いを込めて「みんなでMODしましょう〜」と声をかけていました。
誰かが「こんな成果が出すことができた！」と下半期の実績を語れば「しかも、それをテックブログに書いていてめっちゃよかったよね」と誰かがMODします。「PHP 7.2 へのアップグレードが完了しました」「あれは対応が早かったね、リリースされてから1週間以内でキャッチアップできていてすごかった」や「◯◯をプロダクションに導入できました」「それを見て入社してきた人もいましたよね〜」なんてやりとりもありました。まあ素敵！
ワークショップをやってみて
なんにせよ初の試みなので不安もありましたが、参加者のみんながしっかり乗っかってきてくれて、とっても楽しい時間になりました。「半年後の最高の俺たち」の姿を見ることができたので、なんだか誇らしい気持ちにもなれます。各自、自分の口から「こうなっていました」をみんなの前で表明したことで、もうやるしかないぞ〜という気持ちになってくれたんじゃないかなぁと思います。
「2017年下半期の評価資料」という中間成果物にはけっこうなエネルギーがあって、うちの事業部のエンジニアたちがつくってくれた資料は、他の事業部のエンジニアたちの目にも留まって「え！なにこれ！めっちゃいいことが書いてある」という反応につながりました。そうして、けんちゃんくんさんが CTL を務めるお隣の事業部でも同様のワークショップを開催させてもらうことができました。
2回ともおおいに盛り上がったので、まだまだ改善の余地はあるでしょうが、悪くないワークショップができたと感じています。今日もうちの事業部では、みんなで見た未来を現実のものにしてくれそうな勢いある行動を見かけましたよ。やったね！
まとめ
- 2017年下半期が始まったので、最高の半年間にするためにワークショップを開催してみました
- このワークショップは、もともとあった評価制度をさらによいものにすべくプロダクト開発のプラクティスを取り入れた内容になっています
- 参加者みんなで盛り上がって楽しい未来を見てから現在に戻ってくるので、みんなが元気になるのもうれしいです
- これまでの目標設定は「各個人のもの」か「当人と上長のもの」に留まりがちでしたが、これがチームで共有されてフィードバックしあえるようになるよさもあります
みなさんの現場で成長の加速のために工夫していることなどあれば、ぜひぜひ教えてほしいです。ぼくたちももっともっと成長していきたいので、よさそうなものはどんどん取り入れて自分たちを変えていきたいです。
もしこのエントリを最後まで読んでくれたペパボの人がいたら、ぜひ社内でも共有してください。「自分も成長したいとは思っているけれど、下半期をどんなふうに過ごしたら成長につながるかはまだわかっていない…」そんな人がいたら、そう思えた今が好機です。いつでも話しかけてきてください。もちろん、エンジニアに限らず。きっと力になれると思います。
それでは、2017年の後半戦も楽しんでいきましょう〜！
で 99 円を送金する