もっとスキルを伸ばしたいエンジニアのためのカンタン目標設定術

はじめに

はじめまして、さかがみかずと(@_skgm092)といいます。
普段はDX系のサービス開発を担当しています。

この記事はソフトスキルに強みを持っているものの技術力には自信がないエンジニアに対して、
スキル向上を目的とした目標設定術を提唱します。

自分は学生時代にエンジニアの他に法人営業も経験するなど
スキル一本の技術者というタイプではありませんでした。

しかしながら、いまはエンジニアとしてインフラの設計からサーバー開発まで
なんとかやれるようになりました。そのためこのやり方はひとつの答えとなると思っています。

なお、この記事は技術スキル向上に焦点を当てています。
組織をリードするための目標設定・評価のための目標設定・ソフトスキルを磨くための目標設定術は
別のソリューションが必要となるためご了承ください。

サマリー

• あえてスキルレベルの成長に絞って目標を立てよう
• 開発するときにどんなものを作るかイメージして、開発が終わったら振り返って成長に繋げよう
• 鍵となる問いかけは「自分は何を作れるのか」

カンタン目標設定術のやり方

基本的な考え方

スキルの成長は目標を元に振り返りを行い、よりよい行動を行えるように思考や知識を洗練させていくプロセスの繰り返しです。

そのため一連のプロセスは目標設定・実践・振り返り・改善という4つのステップで構成されます。
これは一般的にPDCAサイクルとも呼ばれます。

目標設定

まず1週間や1ヶ月、1スプリントなどの区切りの良い期間で作成するアウトプットを決めます。
「自分は何を作れるようになるのか？」という問いを立ててそのスプリントで作るものをイメージします。
次にそのアウトプットに対して目標を1つ設定します。
設定する目標はプロジェクトにとって必須のものだと決めやすいですが、こだわりたいテーマがあればそれもよいです。
自分の経験からは以下のような目標設定になることが多いです。

• 誰のどんな課題を解決するか
• 完成時期の設定
• アウトプットを通じてどんな状態を実現するか
• 処理すべきスループットはいくらか
• CPUやメモリやコネクションといったリソース効率はどの程度か

目標を定めたら実際の作業に着手します。

振り返り

開発が完了したら、まず振り返りを実施します。

目標設定で定めた目標に対して振り返りを行います。

達成できた場合は要因を分析し、達成できなかった場合は不足点を明確にします。
主な問いかけは以下になります。

• ユーザーの悩みを解決できたか
• 期日に間に合ったか、想定外のスケジュールなどあったか
• 目指したい状態に達したか、近づけているか
• リリース後、レイテンシ・リソース(CPUメモリコネクション)の利用状況は許容範囲内か

振り返りの結果を基に次のアクションを検討します。
同様のプロジェクトへの再挑戦時の改善点と知識の過不足、作業プロセスの改善箇所を明確にします。
主な問いかけは以下になります。

• 同じことをもう一度トライするとしたらどうするか
• 足りていた知識・足りていなかった知識は何か
• 作業プロセスでもっと良くできることは何か

これにより目標設定と振り返りのサイクルが完了です。
これが終わり次第、次の目標設定へと移行します。

大切なメッセージ

スキル成長のためと目的を絞れば目標設定はむずかしくない

エンジニアの目標設定はエンジニアの目標設定は難しい
という記事にもある通り、多くの人がむずかしい課題と捉えている印象があります。

過去には目標管理は技術者にはクソというスライドがバズったりもしました。

これに対して自分は
「エンジニアの実力は作れるものの質と量の総和であり、スキルレベルによって決定される。
不確実な目標に挑戦することで得られる成長もあるが、それは自身でコントロールが難しく結果にばらつきが生じる性質があるため、スキル成長の目標とは分けて考えるべき。」
という考え方を持っています。

これは例えるなら
「野球選手がスター選手になるためにホームラン30本が必要だとしても、その達成は様々な外部要因(チーム状況・ピッチャーのレベル・ボールの反発係数...)に左右される不確実なものです。
しかし目標達成に強いスイング、怪我をしない体作り、強靭な筋出力といった要素は必須であり、まずはそのレベルを目指すべき」
というようなことだと思っています。

自分はこれらをアウトカムとアウトプット、またはスキルと結果という概念で整理しています。

アウトプットは定量的にレベルアップできるが、結果に大きなレバレッジは効かせられない。
一方アウトカムは運ゲーの側面があるが、運がよいと結果に大きなレバレッジを効かせられるものだと思っています。

もちろんキャリアのどこかでアウトカムに向き合う場面の必要になると思いますが、
まずは確実にコントロールできるスキルの向上に焦点を当てた目標設定から始めることで目標設定に対する心理的なハードルを下げられるのではないかと思っています。

最後に

自分は「何を作れるのか」という問いをベースにして
持っている技術をいかにプロダクトに反映するかを意識するようになってから開発が楽しくなってきたように感じています。

はじめにも述べた通り自分は技術好きタイプのエンジニアではありませんが今のような心境になれていることにすこしばかり驚きを感じています。

このドキュメントは自分の中での変化の過程で自然と身についた目標設定の考え方を言語化してみました。

繰り返しにはなりますが目的が変われば目標の使い方も変化します。

自分自身も日々自問自答を重ねながらアップデートを試みています。
皆さんがお持ちの最適解についてもコメント欄でぜひ教えていただければ幸いです。

お読みいただき、ありがとうございました。