雑記: エンジニアの目標設定のコツを掴んだかも知れない、少し楽しめたかもしれない

Takahiroです。今回は個人としての投稿になります。

最近、自分自身の目標設定に取り組んでいて、なんとなくそのコツを掴んだように感じています。今回はその気づきを共有したいと思います。

対象読者: 目標設定が苦手だと思っている方々へ。

何かご参考になれば幸いです。

前提: 簡単に自己紹介

現職ではMobileアプリ開発のテックリードをしています。現在は人事評価の役割は担っておりません。前職では数年エンジニアリングマネージャを担当していました。人事評価も経験はしておりますが、自身の目標設定も評価者の目標設定も毎回、試行錯誤をしながら、学びながら取り組んでいました。

なぜ、今回は楽しめたのか？

基本的に「やりたいことベース」で考えるようにしたからです。
「こうだったらいいな」「ああだったら楽しそうだな」「これをやってみたいな」といった視点でやりたい事をピン留めしました。

次に、そのアイデアを実現したときにどんな効果が出るのかを具体的にイメージしてみました。「誰にどんな影響をするだろうか」と想像したり、イメージが沸かない部分は少し時間を使って実際に手を動かして実現性を調べたりしました。

具体的に想像できたとき、一気にモチベーションが高まりました。このプロセスでは、知的好奇心や探究心が刺激されて、自然と行動に繋がった感じがします。

もちろん、単にやりたい事ベースではビジネス観点が抜け落ちてしまいますので、どういったStepで自分の意思（Will）とビジネスを紐付けたかを掘り下げていきます。

Step1: 『解決したい課題』よりも『やりたい事』

目標設定の際に、いきなり「解決したい課題は何か？」と問いかけることは逆効果だと感じました。最初にするべきは「やりたいことを見つける」ことです。しかし、単にやりたい事をやる（Do）だけでは『So What?』になってしまいます。その先を、さらにイメージしていく必要があります。

それをやり切ったら、あなたの周りではどんな事が起こりますか？

この問いかけがすごく重要で、できるだけ具体的にチーム、プロダクト、ソースコードの事を思い浮かべてシミュレーションをします。そうすると『直感的な単なる行動（Do）』が『目指したい状態（Be）』に変換されていきます。

このシミュレーションは少しコツが必要ですが、まずは質よりも量。紙にイメージを描いてみたり、誰かに話して壁打ちしてもらうなど、とにかく頭の中のアイデアや感覚をアウトプットしまくる事が大切だと感じました。

ちなみに、この問いかけは、私がいつもお世話になっているコーチングの講師さんから教わりました。

Step2: ”Be”を明確にする

具体例を記載する為、少しだけ自分自身の話を書きます。以前投稿したこちらの記事がやりたい事の全体像ではあります。

この内容を考えるにあたり、僕はコーチングで壁打ちをして以下を深掘りしました。

なぜスクラムをやりたいのか？
リリース頻度が高まったら何が起こるのか？

結果、全職能で机を囲んでワイガヤ『これいいね！こうしたらもっと良くなるんじゃない！？』とディスカッションしている像が浮かんできました。目指す状態って、そいういう事で良いんじゃないかと思っています。

スクラムイベントをちゃんとこなせば、全職能でワイガヤできる
リリース頻度を高めれば、ユーザーからの反応を元にワイガヤできる

もう少しちゃんとした表現をすると

スクラムは、集合知によるチーム内での学習を促す
リリース頻度は、市場からのフィードバックによる外部要因の学習を促す

そうやって俊敏に状況に適応していけば、事業投資の成功土台が徐々に積み上がっていくのが想像できます。

まとめると、僕が目指したい”Be”は、『内部、外部要因をワイガヤで咀嚼して学びに変える力を持ったチーム』です。その結果、チームが常に成長実感を持ちながら、事業の成功（KPIや売上といったアウトカム）を目指したいです。

ただ、もう少しフランクでも良いかなとも思ってまして

• 仲のいいチーム

• 世界に自慢できる技術を持っている

そういった切り口であっても、出発点としては良いと思っています！大切なのは『自分の言葉で語れる "Be" 』です。

『粗探し』は目標じゃない

他社や他人と比較して『これが出来てないから問題だ！我々はダメなんだ！』と頭ごなしに自己否定をする目標ってシンドいと思います。自分が前向きになれる目標を見出す事が大切だと思います。その上で、他社と比較して焦点を当てるべきは「学び」であり、「自己成長に繋がるポジティブな学びを得る」目的での比較をすると良いかと思います。

KPIをエンジニアの目標にする場合は慎重に検討した方が良い

言い方を変えると『コントローラブルな目標を設定した方が良い』ということです。例えば『半年でリテンション率を XX % アップする』という点、エンジニアがどれ程、直接的に影響を与えられるでしょうか。

プロダクトのチーム目標としてKPI掲げ、PdMが責任を取る様な場合は良いかもしれませんが、エンジニアが個人目標として掲げるには難易度が高すぎるケースがあるかも知れません。

ならば、何を目標にするのか？

プロダクトを資産と捉えるならば、エンジニアの本分は『資産の状態をより良くすること』だと思います。以下の記事を参考にさせて頂きました。

自分なりに解釈した大枠は

資産価値を高める（施策をリリースすること）
負債を減らす（開発スループットを下げる要因を除去する）

作り込む施策の資産価値はリリースしなければ分かりません。よって、エンジニアができることは以下の3点くらいなのかなと感じます。

質の高いモノを作る（技術力）
PdMやデザイナーの意図をカタチにする（意思疎通）
チームのボトルネックを解決し続ける（チームワーク）

つまりは『良いチームワークで、良い技術を使う』という事。

『PdMやデザイナーも交えた良いチームになるには？』『良い技術の状態になるには？』という軸を目標にすると、最初は良いかと思います。

Step3: 避けられない”測定”の基準を考える

本当に難しいと思います。色々あるとは思いますが、基本軸は『まず小さく施策を打ち、効果を測定する』事が大原則なのだと思います。

測定→見直しの積み重ね

あくまで例ですが、例えば『SwiftUIの対応範囲を広げたい！』『ソースコードを共通化したい！』『もっとPdMやデザイナーとうまくコラボしたい！』とか色々あると思います。

どれを取ってみても、まずは対応してみて、その後、その仕事を計測してみると良いと思います。

• プロダクト施策の見積もりの調査時間

• 機能追加時のコーディング時間

• コードレビューのリードタイムやコメント数

• Sprint reviewでのフィードバック数やGoal達成率

• 各位がステージングにデプロイした頻度

• etc…

Four Keys や Cycle Timeをツールで計測しても良いと思います。やり方は何でも良いです。計測してみて全く効果が出ないと感じた場合は目標を変えなければなりません。1回で上手くいく事の方が少ないでしょう。

そうやって、『実施→計測→学び』のサイクルを回す事が重要と考えます。

Step4: 施策を見積もってみる

やりたい事がある程度、揃ってきたら、目標をマネージャや上司に説明する前に見積もってみると良いと思います。見積もるためには

• 曖昧さを具体に変える

• 現状（AsIs）と施策（ToBe）のギャップを把握する

• ブレークダウンなど分割する

その上で、『この施策は1週間くらいかなぁ…』と大雑把に見積もってみます。そして、それを基にスケジュールも引いてみます。そうすると『あ、この施策はこんなに時間かけたくないな…』という気づきを得たり、やりたい事が評価期間とマッチして『よし！これならイケる！』と自信を持てたりします。

Last Step: アンラーン

目標を考える上で、一番大変で重要なのは『アンラーン』すること。直感的に『やりたいこと（Do）』から入り、徐々に Be、測定、見積もり を具体化すると、最初の自分の感覚が間違っている事も多くあります。その時に、自分の価値観を変えられるかが重要です。

でも、アンラーンを乗り越えると自分の視野が広り、モノゴトを捉える解像度が上がっていくと思います。

目標設定をする最大の楽しさは『自分自身に変化を起こすこと』なんじゃないかなと思います。