SEN PRODUCT BLOG

千株式会社のエンジニアによるブログ

開発者目線での目標を立てるための考え方

はじめに

エンジニアをやっている、@r9999 です。日夜奔走しながら開発を進め、エンジニアリングマネージャーというポジションで活動しています。よろしくお願いします。

開発をしていく中で、チームメンバーの目標の立て方を一緒に決めていくことをしており、ふと自分が目標を立てるようになった、社会人成りたてのころを振り返ってみました。

当時は、SIer系の企業に所属しており、プロジェクトがある程度進行したころ、突如評価結果の話と、目標を立てようと上長に言われ、「目標って何を立てるんですか?」という質問をし、「サーバーとか立てられるようにするとかあるじゃん」と言われた覚えがあります。

そのころは、AWSやAzureなど気軽にサーバーを立てるような環境もなかったため、メモリ、CPUなどのパーツ購入から始めるのか?と思い、メモリやCPUなどの取り扱いを学ぶという意味はありますが、ただ目指していたのは、今でいうWEBアプリケーションエンジニアだったので、ミスマッチ感を覚えながら実施していました。

と、過去を振り返りながら、目標を立てるときに、どう目標立てればいいの?という悩みを、開発者視点(Engineer、PdM、EMなどのものづくりをしていく人たちとします)で、少しでも解消に繋げられたらと思います。

目標を考えるための前置き

目標を立てるために把握しておいたほうがいいと思っていることは3つあります

  • 自分の能力を把握する
    • やってきたことは何か、どこまで知っているか
  • 自分が目指したい姿を把握する
    • なぜ目指したいのか
  • 目指したい自分になるための必要な知識、経験を把握する
    • 足りない知識、経験は何か

上記の3つを正しく把握していたとしても、他の人がみてもわかってもらえるようにするには、例えば、自分の能力を把握するために、検定試験でスコアを見たり、必要な知識・経験を、こちらの roadmap.sh を参考に、チェックリストのように、できる・できないとつけることで、基礎的な内容は測れます。

ただ、実際の開発していくうえ、サーバー、ソフトウェアの違いなど、様々な要素が重なり、それぞれのスキルを掛け合わせての応用内容になってくると、正確に表現することは難しくなってくると感じます。

目標を立てていくのは難しいと感じながらも、自分自身の能力の伸ばし方や、組織目標と、どのように折り合いをつけていくのかについて、あげていきます。

まず目標とは何なのかを考えてみる

目標の考えかたは、こうありたいと思っている自分自信がどこまでできてきたかの成長を実感、達成感を得たり、モチベーションをあげていくものと考えています。

例えば、マラソンで1kmあたり7分だったのが、5分で走れるようになっていたら、筋力がついてきたことがわかり、成長を実感できます。

なぜ目標を立てるのが難しいと感じてくるのか

さきほどのマラソンを例にすると、5分/kmで限界を迎えていて、いままで取り組んでいた内容では改善できないとなった場合、知識や他の方からの経験があれば、時間を短縮できるようになってきますが、知識・経験がないとどうやればいいのかわからないという状況になり、調べることから始まります。

ただ、この調べるという内容が、知識を得る先がない、周りは誰も知らないなどの状況があると、こうしたらうまくいく?などの試行錯誤をしていく必要があります。いまの世の中は、インターネットなどの調べる手段がありますが、様々な情報があり、「何を信じればいいの?」という迷いやすい状況が生まれていると考えます。

目標をどうやって立てていくのか考えていく

開発者の要素と、自分能力を把握する 

自分自身が関わってきた、Web / Native Application の要素の一例をあげていきます。

  •  職種、役割(その時の技術・状況に応じて変わっていくので、一例を提示
    • Native Application Engineer(Android / iOS / Flutter / etc...)
    • Web Application Engineer(Frontend / Backend / Fullstack / QA / ...)
    • Designer(UX / UI / Product / Service / ....)
    • SRE 
    • etc ...
  • 事業、サービス(ものづくりとして関わりそうな一例
    • サービス仕様・業務
    • 法律(WEB系:特定商法、景品表示、著作権、個人情報、etc... )
    • 技術(言語:js, java, php, swift, etc... / DB:grahpql, postgres / ホスティング:AWS, Azure, GCP, etc...)
    • etc ...
  • 顧客
    • 国、地域特性(方針、インフラ、
    • 利用者の特性(年齢、性別、家族構成

経験してきた事や、関わりのあった要素をあげただけでも、上記のような内容があり、目標を立てていくにも、何に注目し、何を取り入れていくのかを選んでいく必要があると考えます。

そして、要素ごとに、大枠でもいいので、以下のようにレベル感の区分けをします。

  • 知っている:存在や考え方などの情報を知識として知っている
  • ためしたことがある:知り得た知識をもとに実行したことがある
  • できる:原理原則を理解し、他の人へ説明が可能

自分の能力を把握したら、次は目標をどこにするかを考えていきます。

組織に合わせた目標と、自分の目指したい姿を把握する

自分が好むものは何か?得意なことは何かの自己分析を行い、なりたい役割を選び、役割の中でも、何を優先していくのかを考えていく必要があり、そして、ゴールを立てる必要があります。ゴールを立てる場合は、自分自身が3〜5年後がどうありたいのか、ぼやっとでもいいからイメージをしたうえで、何しておくといいのかを、1年単位でも四半期単位でもいいので、立てておくのが良いです。

目標に到達していなかったとしても、ふりかえりを行い、軌道修正をするなどして、改めていけばよいです。ふりかえりは、KPTやYWTなど自分にあったもので構いません。

そして、組織で目標を立てていくにあたって、組織が掲げている目標が何か?を把握する必要があり、例えば、弊社が提供しているはいチーズ!フォトのサービスでしたら、330万人のユーザー(保護者の方々など)に、子どもの成長を感じてもらえるようにする、などがあり、その目標に向けて自分自身が何に注力していきたいのかを上司と相談し、求められている期待役割と、自分自身があげていきたい役割、能力を合わせていく必要があります。

なぜ、すり合わせる必要があるのか?は、以下のように考えています。

<目標を合わせたときのメリット>

  • 組織として求められている成果を達成し、自分自身が達成したい目標を達成していける

<目標を合わせなかったときのデメリット>

  • 組織として求められている期待役割 を優先すると、自分自身に合わなかった場合、こうじゃない、こうじゃなかったなどの、精神的に辛い状況を受け入れる必要があります
  • 自分自身があげていきたい役割、能力を優先すると、組織として求めるものと合わない場合、利用していただく人への貢献に繋がらなかったなど、組織として達成できない状況に陥る可能性があります。結果、評価はあがりづらい状況となります。
組織で目標を立てる上で誰を意識する必要があるのか

組織では最終的に給与を支払っている経営者・経営層に向けたメッセージとして、自分自身の市場価値があがっている、提供サービスの第一人者として活躍しているなどを魅せていく必要があります。

ただ、自分だけよければよいという話ではなく、組織として活動しているので、所属している組織(部、チームなど)で、どのような行動をとり、サービスにとって、チームにとって、どのような改善活動を行ってきたかなども意識する必要があります。

そして、目標を立てるにあたって、人事評価制度を把握する必要があり、よくある内容だと、以下3点ほどあります。

標準型 現実 加点型
S 一つ上の等級の期待レベル S 等級の期待を上回る S 一つ上の等級の期待レベル
A 等級の期待を上回る A 等級の期待通り A 等級の期待を大幅に上回る
B 等級の期待通り B 等級の期待を下回る B 等級の期待を上回る
C 等級の期待を下回る C 等級の期待を大幅に下回る C 等級の期待通り
D 等級の期待を大幅に下回る D 業務に支障をきたす D 等級の期待を下回る

自分自身の評価設定方法として、各ランク(S~D)に応じて、ここまで実施したら Aにする、という基準を明確にしたうえで、上長とすり合わせていくのがベターと考えています。この基準を設けることによって、評価時期に、お互いの認識ズレが起きないようにしていくことが必要です。※等級そのものは、運営可能な状態であることが前提となります。

評価されている方には、これは持っててほしいなと思う内容

評価とは、貢献度、恒常的に発揮できる能力を明確に把握、格差付け、根拠をはっきりさせる、そして説明責任が必ず伴います。

そして、評価の5原則として考えられるのは以下の要素になります。

  • 評価基準が明確であること
  • 評価基準が理解されていること
  • 評価基準が守られていること
  • 公平であること
  • 評価する側は責任をもつこと

目指したい目標を達成するための知識、経験の道筋を立てる

いま自分がWeb Application Engineer だったとして、サービスを開発していくうちに、プロダクトマネージャーとしてやっていきたい、となった場合、どのようにして目標を作っていくのかを考えていきます。

Dan Schmidt 氏 が提唱した、The Product Management Triangle を参考に、何を決めていったらよいかの洗い出しをしていきます。

 

Figure 3. Examples of the roles that fill each region of white space.

Users < > Developer にあるものをみていくと、Web Application Engineer として培ってきた技術と照らし合わせていきます

<例えばの内容>

  • できること
    • SEO:業績評価するための、BI ツールを用いて、営業支援したな
    • Web Analytics:Google analytics を用いて実施してきたな
  • 伸ばしたいこと
    • Design:ユーザーフローとか考えたことがなかった

※運用まで落としこめてませんが、以下の内容のスキルで構成されていると考えます。

Users < > Developer

Community Management

プロダクト改善のための洞察が得られるコミュニティ構築

ex) A/B、プロトタイプテスト、etc

  • システム性能、UI/UX含めた、フィードバックを得られる環境

  • フィードバックから、新たな発見、デザイン強化に繋げる道筋

Social Media Marketing

ブランド認知度の検討、促進、シェア拡大

ex) PR, WEB/Native app etc

  • “Community Management“ で得られたフィードバック内容を元に、何に価値があるのかを展開する

SEO

ブランド認知に合わせた最適化

ex ) 計測指標 / OKR, KPI (CVR) etc

  • キーワード、競合分析、業界評価

User Research

プロダクトに関わる顧客理解

ex) インタビュー、FAQ、エスノグラフィー調査

Web Analytics

プロダクトを利用するデータ収集

トラフィックを測定するだけではなく、ビジネスや市場調査、ウェブサイトの有効性の評価と改善

ex) google analytics

Design

プロダクトデザイン

UI/UX Design ギャレットの5段階モデルを参照

ex)

  • story board

  • User Story / User Story mapping

  • Information Architecture Mapping

  • User Flow Map

  • WireFrame / Protype

  • Hi-Fi Design & Mood Board

    • pict gram

    • color

    • typography

    • animation

Design 周りのスキルを上げていく必要があると判断したときは、例えば、UI/UX Designの観点の一つである ギャレットの5段階モデルを参考にしながら、以下のような単位で区切っていきます。

  • 1年目習得 / Hi-Fi Design & Mood Board
  • 2年目習得 / WireFrame / Protype
  • 3年目習得 / User Flow Map

ただ、実際のプロジェクトが始まれば、1年目から3年目まで習得と記載している内容が、すべて求められるようなことはよくあり、どこまで習得すれば、プロジェクトで通じるのか、100点を目指さず、60点習得し、活かしていく必要があるため、will can must のように区切ったり、評価軸のように、S / A / B と区切り、Bまでできたら、OKとしてくのがベターと考えています。

最後に

目標を立てたら、実際にしてきたことに対して、何ができた、できなかったという定期的な振り返りを行いつつ、その中で、できなかったことに対しては、反省はしつつも伸びしろと考えていただき、次に繋げるにはどうするのか?と考え、できたことについては、「ここまで、できたんだ!!!」と大いに自分を褒めてあげましょう!

目標を立てても、様々な要因で思うように進まないことがあり、それを乗り越えて、できたことに目を向けて、成長を実感していきましょう!

参考資料

productlogic.org

github.com

roadmap.sh

roadmap.sh の内容は、半年見ないと内容が随分変わっていたりするので、随時アップデートが必要です。

人事評価の教科書:https://www.amazon.co.jp/gp/product/B019GY29AO