目標設定奮闘記

この記事は マネーフォワードアドベントカレンダー2021 の18日目の記事です。

はじめに

こんにちは。株式会社マネーフォワードにてエンジニアをしている渡邉拓未です。社内では「たくみん」と呼ばれています。業務ではRailsとVue jsを利用して開発をしています。

さてさて時間はあっという間に過ぎ去り2021年が終わろうとしています。この時期になってくると会社によっては翌年の目標設定の時期だったりしませんか？
最近私は2022年上期の個人目標を設定していました！！
そこで今回は試行錯誤しながら目標を作成する中で、私なりに感じたことや考えたことについて書いていきたいと思います！

とりあえず目標を書き始める

私が目標を考え始めたときの状況を整理します。
すでにチームの2022年のロードマップは作成済みでした。ロードマップから達成するための定性的な目標が与えられ、個々人がそれらを達成するための目標を作成するといった状況です。
私の悪い癖ですが、まずはペンを走らせようと紙に書き出してみました。しかし「〜を頑張る」や「〜を意識する」のような気持ちが前面に出てしまう目標ばかりが思い浮かんでしまいました。
これでは上司が評価する際の基準が曖昧になってしまうだろう。評価の基準を明確化した方がお互い気持ちよく仕事もできるよな。といったことを考えたりしながら謎の時間ばかりが過ぎていきました。そこでこの状況を打開すべく、目標設定のノウハウを色々調べてみることにしました。

目標の目指すべき形を定める

そもそも、私はどんな目標が誰が見ても納得できるような目標になるのかがわかっていませんでした。そこでまずは目標の目指すべき形を決めることにしました。
調べている中で、グーグルをはじめとするさまざまな組織の働き方の先進事例、研究、アイデアを集めたウェブサイトである「re: work」を発見しました。その中では

具体的、客観的、かつ明確な言葉を使用します。目標が達成されたかどうか、客観的に見て明らかであることが必要です。
引用: Google OKRを設定する 目標と成果指標を設定する

目指すべき形はなんとなくですが分かりました。
さらに色々と調べてみると「Smartの法則」といった考え方を発見しました。

「Smartの法則」について簡単に解説をします。

Specific: 具体的であること
Mesurable: 測定可能であること
Achievale: 達成可能性があること
Relevant: 目標と関連があること
Time-bound: 期限があること
参考: Smartの法則とは？5つの基準と、目標を達成するためにすべきことを紹介します

これらを踏まえ、それぞれの観点ごとに考えていけば最終的に目標が目指すべき形に近づくのではないかと思いました。
そこで「Smartの法則とは？5つの基準と、目標を達成するためにすべきことを紹介します」の記事内にあるように、観点をスプレッドシートに書き出して作成していくことにしました。

※「目標: 設定された目標」にロードマップから達成したい定性的な目標を書きます。

目標を目指すべき形に近づける

細かい目標については見せることはできないので、公開できる箇所のみ記載しております。ここからはそれぞれの見出しの観点で目標をブラッシュアップさせていきます。

あいまいな、とりあえずの目標を設定する

これは私が当初考えていた目標になります。
当初の目標は「リリースまでに必要な工程を漏れないようにすすめ、品質が高い状態でリリースを実行する」と書いていました。我ながらかなり良い目標設定だったので結構な自信作ではありました。

Specific(具体的な)：目標が具体的か?

ここでは曖昧な言葉は徹底的に自問自答しながら進めていきます。この時点ですでに曖昧さが露呈しています。まだまだ具体的に落とし込めるような目標であったことがわかります。思考の流れを残すことができるので、相談するときや半年、1年後の振り返りでも有効活用できそうですね。

Measurable(測定可能な)：達成度を測れる目標か?

ここでは、測定可能にするために数値を利用するようことを意識します。今回はリリースした機能の中で「重大な考慮漏れやバグ」の個数を何段階かに分けて評価基準を作成していきました。またここでも「このプロダクトにおける重大な考慮漏れやバグ」について深掘りを行っていきました。

Achievable(実現可能な)：達成可能な目標か?

個人的には1番この観点が難しかったです。達成可能な目標であることを客観的に示す必要があるのですが、自分自身の経験値やデータの比較を示しながら達成可能か否かを線引きするのはなかなか難しいです。ここの内容次第では、目標そのものを見直す必要も出てくるため重要な観点の1つであると感じました。

Relevant(関連した)：目標の達成が自分の利益につながるか?

給料やボーナスが増えるといった金銭インセンティブから、エンジニアであればこの技術を業務で利用できることで自分のスキル向上につながるといった観点でもいいのかなと思います。

Time-bound(期限を定めた)：期限が設定されている目標か?

この観点は自分だけで決めるのは難しいです。ロードマップのようなチームの方針が予め用意されていれば、ある程度全体の動き方が見える化されるため期限の目安はつきやすいです。そうでない場合はある程度半年、1年間を見据えた上でバッファを考えて設定する必要があります。目標達成が成績につながるような場合はチャレンジしづらいと思います。弊社はロードマップが用意されていたので比較的簡単に設定することができました。(感謝しかありません。)

このように各セクションごと深ぼっていき、なんとか目標を設定していきました。実際にフィードバックをもらうべく上司との1 on 1を迎えました。
その中でもらった意見はこちらです。

上司からのフィードバック

全体的にタスクベースの目標になってしまっている。
タスクを実行したことを評価することはもちろんだけど、あくまでもタスクは手段であって別のやり方をやってもいいかもしれない。
ここではどんな状態になっていてほしいのかを考えて欲しいです。
また今回の考え方の中で一つだけ気をつける必要があるとすると、Measurable(測定可能な)：達成度を測れる目標か? 」の観点です。
エンジニアの場合に数値を目標に落とし込んでしまうと歪んでしまう可能性があるので慎重に考えましょう。納期や機能リリースの数を目標においてしまうと、達成するまでの過程がおざなりになったり、ちょっとした変更によって達成できなくなってしまう可能性があります。などといったお声をいただきました。(ありがたし)

まとめ

上司からのフィードバック通り、今回の目標設定は再度考え直す結果になりましたw
ですが、目標設定をきちんとフレームワークに沿って考えていく体験を通して、考える視点をインプットできたことは大変学びがありました。これからもたくさんの目標設定する機会があるので、今回の学びを生かしていきたいです。下半期リベンジするぞ〜！

明日はマネーフォワードアドベントカレンダー🎄19日目はkennygt51さんです！お楽しみに〜