こちらは、ドリコム Advent Calendar 2018 12日目の記事です。
前回は @y05_net さんの Ansible+serverspec-runner+PackerでAWSとGCPに対応したシンプルなマルチクラウドインフラCI環境を構築する です。
アジェンダ
今回話すのは以下の 2 点です。
- 目指すべき目標と具体的なアクションの思いつき方
- 決めたことを文書で表すための手法
①書くことを決める、②書く、この二つができれば目標設定は完成です。これ以上無くシンプルです。
前振りはいいから具体的な内容を！という方は 4. 目標の思いつき方 からどうぞ。
はじめに
はじめまして、クライアントエンジニアをしているじぬです。
エンジニア歴 6 年、元々は Objective-C や Java を用いたスマホネイティブアプリ開発、近年は Cocos2d-x を用いたネイティブゲームアプリ開発をしています。以前はリードエンジニアも経験しています。
ドリコムのアドベントカレンダーを見てくださっている皆様は、開発やものづくりにご興味をお持ちかと思います。とりわけ変態的ハックや鮮やかなマネジメント手法をご期待の皆様、お帰りください（嘘ですまた明日来てください）。
私が担当する本日は、目標設定に関する話をしたいと思います。
皆さん、目標設定好きですよね？
なぜ目標設定なのか
そもそもなぜこのテーマで書こうと思ったのか、を説明します。
きっかけは、チームの若手メンバが目標設定を苦慮していたことです。
振り返れば自分も目標設定が大の苦手でした。設定では丸一日かけて数行しか書けなくてへこむ、振り返りではアピールするほど行動ができていなくてへこむ、ベコベコになる毎日でした。
今では流石に慣れてきているため、参考にできそうな自分の考え方をアドバイスしてみました。
と、ここで気になったことがあります。
おそらく目標設定が得意な人はあまり多くないと思います。特に新卒の方などは、苦手意識がある方も多い印象です。慣れている自分でもそれなりに時間がかかる作業です。また、組織の内部において必要とされるものであり、ビジネス利益という観点でも直接的に得るものはありません。
一方、目標設定がなくなることは基本的に無いと思います。自分は中途入社ですが、これまでの会社でもやり方は違えど同じようなことをしています。また、定期的に必ず発生する作業でもあります。
整理すると、目標設定とは一定数以上のメンバが苦手に感じ、時間がかかり、大きな利益もなく、定期的に必ず発生する作業です。これはどう考えてもボトルネックであり、エンジニアとして効率化を考えずにいられるでしょうか？いえ、いられません（反語）。
そんなわけで本日は、目標設定についての話をしたいと思います。
ドリコムにおける目標設定
ドリコムの目標設定に関連して、 OKR というフレームワークを紹介します。
これは、Objective（目標）と Key Result（具体的な成果）を定義し、組織と個人の目指すべきものを明確にしていく手法です。高い目標を置くことで自分たちの成長を促すとともに、目標達成について定性的、定量的双方の観点で振り返ることで、目標に対して正しく進捗しているかを計測するものです。
ドリコムの場合、まずは社の OKR、次いで部ごとの OKR が共有され、それに基づいて個人の OKR を決めます。個人の OKR とはすなわち、個人の目標とそれを確認する定量的な項目です。細かい認識のズレを防ぐため、具体的な活動である Action Plan（アクションプラン）も合わせて上長と確認します。合意形成ができれば、それを目標に半期を過ごしていきます。
目標の思いつき方
部の OKR は事前に与えられています。それを元に、自分の OKR を設定していきます。このとき、自分は大きく二種類のアプローチを考えます。
ボトムアップ方式
この方式では最初にボトム、すなわちアクションプランから考えていきます。パッと思いつかない場合は、とりあえずやりたいことを列挙していきます。また、もうやりたくない、というネガティブな要望も合わせて列挙すると良いです。
新規イベントを実装してみたい、というポジティブなものから、細かいバグ探しもうやりたくない、といったネガティブなものまで、とにかく書き出していきます。
次に、それらのアクションを実行すれば、どんなことが実現できるかを考えます。例えば新規イベントの実装によってユーザが喜び、ユーザ数が増え、売上が上がるでしょうか。バグ検出をやりたくないから自動化したら人手によるミスが減り、バグがなくなり、空いた対応時間でさらなる新機能を実装できるでしょうか。ここでは夢を描いてください。
OKR の考え方でもありますが、ここは理想的すぎるほどの成果を描いたほうが、難しくもやりがいある目標になります。
次に、この夢と部の Objective を照らし合わせます。いくら素晴らしい夢でも、組織の期待値と合っていなければもたらされる価値は微妙なものになりかねません。書き方なり方向なりを Objective に寄せていきます。慣れていないと、このあたりでハッタリのような不安感があるかもしれませんが、そもそもこの時点では目標設定自体が空想に過ぎないので、強気にいきましょう。
ここまで進めて、部の Objective → 自分の Objective → 自分のアクションプラン、が線でつながっていれば問題ないです。もし違和感があるようであれば、再度アクションプランの調整 → Objective 調整、というループを繰り返しましょう。
流れに問題がなくなれば、最後に Key Result を定義します。
Key Result は Objective の達成を定量的に証明するためのものです。Objective を達成することで何が残るのかを考えます。と言っても、Objective とアクションプランがつながっているのであれば、必然見えてくるものです。つまり、達成したい夢と自分のアクションがリンクできているのであれば、その過程で残るものが Key Result です。
ユーザを喜ばせたいのであれば、その成果はユーザ数や売上で表れるでしょう。手間取る作業をなくしたいのなら、その成果は空き時間の増加や残業時間の減少という形で見えてくるはずです。
Key Result を肉付けすることで、自分のアクションがどういう変化を起こし、結果としてどんな成果をもたらすか、という一連を描くことができるはずです。
トップダウン方式
ボトムアップ方式は、自分がやりたいことを組織の Objective に近づけていきました。こちらは逆に Objective から自分のアクションを割り出していきます。
自分は書きやすさの観点でボトムアップ的に考えることが多いですが、こちらのほうが OKR の意図に近いと思います。目指すゴールから逆算するため、高い目標がたてやすいからです。また、どうしてもやりたいことが思いつかない、という場合もこちらの考え方を試すと良いと思います。
まず部の Objective を、自分なりに噛み砕く（自分の Objective とする）ことから始めます。そのまま流用しても構いませんが、だいたい組織の目標は大きく抽象的なものになっているため、自分の粒度まで落とす必要があります。また、同じような内容であっても自分の言葉で解釈することは有用です。そうすることで、つまり何をするのか、ということを再理解できるからです。
とは言っても、いったん噛み砕くのは雑で構いません。最初は量を出したほうがスムーズに進みます。つまりこういうことか、というのを何パターンも出していきましょう。
書き出したものの中で、自分がアプローチできそうなものをピックアップします。これは Objective なので、高い目標なのはそもそも前提です。多少の無理筋があっても、それを目指すという意識で自分のアクションと紐づけましょう。
次に、雑に書き出した Objective を精査・見直ししていきます。アクションプランも書き出せているはずなので、それも合わせて部の Objective につなげていきます。
これができれば、Objective と自分のアクションがいったんつながったかと思います。あとはボトムアップのときと同じでループしながら修正を繰り返し、部の Objective から自分のアクションまでが紐づけできれば OK です。
文書の書き方
ここまでで、書く内容はおおよそ見えてきたかと思います。次は、実際の文書の書き方です。自分の場合、一から文書を書くことはしていません。その理由はそう、ユーザ目線です。
目標設定におけるユーザ目線
ユーザ目線、大事ですよね。でも何を意味しているのかふわっとしていますね。ふわっとしたままではよろしくないので、もう一歩噛み砕きます。
そもそも目標設定のユーザとは誰でしょう。組織において目標設定とは、ニアリーイコールで評価に用いるものです（OKR は評価を目的としたフレームワークではないですが）。評価者とは自分の上長やその上のメンバです。つまり我々が行う目標設定とは、対象ユーザは自分の評価者であり、目的は自分の評価をスムーズにすることである、ということが分かります。
そうであれば、目標設定の文書自体は評価者のために書くべきです。別にお世辞を言いましょうという話ではありません。読む人間が決まっているのであれば、その対象者が読みやすい、解釈しやすい文書や内容にしましょう、という話です。その方が対象者の手間が少ないですし、何より自分自身の意図が正しく伝えられます。
言葉の選び方
ここで話を書き方に戻します。自分の場合、OKR や社員の要件から単語を抽出して文書を書き起こします。社員の要件とは、組織内における社員の働きの期待値をまとめたものです。つまり、要件とは「会社からの、社員にはこうあってほしいという想い」をまとめたものです。
自分は組織全体の評価を担当しているわけではないため、ここからは推測も混ざった話となります。
評価者が社員を評価する場合、軸となるのは組織の目標に向けてどれだけ動いたか、会社が期待する貢献を果たしたか、という点になるはずです。ここで言う目標とは、組織の OKR で示されています。また会社が期待する貢献とは、上述の要件に示されています。
つまり端的に言えば、OKR や社員要件には「評価」という軸におけるゴールが示されています。示されているのなら、その文言をそのまま使ったほうが分かりやすく、こちらが考える手間も少ないです。
例を示します。
例えば「真摯であること」という目標に対して「他の人をフォローするような優しさをこころがけた」というアピールをします。この場合、評価者には「優しさって真摯なのか？まぁそういう捉え方もあるのか？」という逡巡が発生します。これに対して「他の人をフォローするような真摯さをこころがけた」という書き方をすれば、少なくともこちらが真摯という観点でアピールしたい意図は伝わりますし、単語を考える手間も減ります。あくまで言い方を変えただけですが、これで分かりやすさが向上するのであれば、決して無為に扱うことではありません。
言いたいことは、評価者も人間であるということです。だったら伝えたいことは分かりやすくしたほうが良いです。上述したように双方の手間が少なくなりますし、自分が何を考え何をしたのか、何を伝えたいのか、という情報伝達の確度が上がるからです。
なぜこの話をしたのか
ここまで具体的な方法の話をしてきました。
正直細かいというか、小狡い話をしている自覚はあります。
なぜここまで目標設定にこだわったのか、という話をさせていただきます。
それは一言で言えば、目標設定には価値がないからです。
すみません言い過ぎました。
ですが少なくとも、目標設定自体は価値を生みません。
我々ものづくりを仕事とする人間にとって、価値とはなんでしょうか。
私の考えでは、ユーザに届くもの、こそが価値です。
どんなにきれいな目標設定をしても、どんなに美しいソースコードを書いても、どんなに作業を自動化しても、それ自体が価値となるわけではありません（厳密に言えば同僚や未来の自分というユーザへの価値ではありますが）。
どうすれば手触りの良いアプリにできるのか、不快に感じないようなパフォーマンスを出せるのか、より美しいデザインはできないか、もっと分かりやすい言い方や伝え方はないか。そういった、ユーザに価値を届けるべき箇所で試行錯誤することが、ものづくりの本質です。
目標設定はあくまで、自分たちが何を目指しどう評価をされるのか、といった組織内での話です。もちろん、手を抜いてしまえば自分たちの動きが鈍ってしまうのは事実です。ですが、あくまで本質はユーザへ価値を届けることであり、目標設定はそのための手段であることは認識すべきです。
だからこそ、多くの時間をかけずに、かと言って精度を落とさずに目標設定をこなすことはできないか、ということを今回の主題とさせていただきました。
まとめ
ここまで述べた内容をまとめたいと思います。
- 部の OKR は決まっているので、そこからできることを逆算する
- あるいは自分がやりたいと思っていることから夢を描き、OKR につなげる
- 文書は誰が読むのかを考え、自分への期待値から単語を抽出すると書きやすい
- とは言え、目標設定自体が価値を届けるわけでないことは理解しておく
繰り返しになりますが、我々ものづくりを仕事とする者にとっては、いかにユーザに届ける価値を向上させるか、こそが最も手間と時間をかけるべきことです。
何かに時間をかけるとは、それ以外のことに時間をかけない、ということです。
それ以外の時間をどうやって節約・削減するか、そういった点にも真剣に向き合っていくことが、真摯に取り組むということだと私は考えています。
おわりに
最後まで読んでいただき誠にありがとうございます。
本日は目標設定のやり方と考え方について、私の考えを述べさせていただきました。
今回の内容が、皆様がより良いものづくりをするための一助となれば幸いです。
次回の記事は、青木慎さんの HTML5+JavaScriptのゲーム開発に元Unityエンジニアが挑戦してみました です。
