TL;DR
- 自身の成果をアピールするために、1)Before/After、2)自分の寄与度、3)数字的インパクトを過不足なく伝えることが重要
- 説明の冒頭では、課題と解法の全体感と成果を述べ、詳細は後に肉付けすると伝わりやすい
- 課題を伝える際は"誰から見た課題か"を明確にする。課題は解法の前提であるためブレないように
はじめに
技術広報のしゅーぞーです。この記事では、過去100人分程度の成果報告書を読み、気付いた "自分の成果をわかりやすく伝える書き方"をまとめています。
仕事をしていると自身の成果を的確に伝える機会は数多くありますよね。 評価期、転職面接、昇格面談など 評価者に自分の成果をどう分かりやすく伝えるか は自分のキャリアを伸ばす上でとても大事なスキルです。
しかし、自分の頑張りや成果を上手く言語化し、相手に正しく理解してもらうのは簡単ではありません。 特に、経験の浅い若手にとっては、何をどう伝えればよいのか戸惑うことも多いはずです。
今回は、CARTAの若手エンジニアから 「どのように成果を伝えれれば評価者に伝わりやすいか」と質問を受けた際のAnswer社内記事を公開 します。
この記事の前提
中身に入る前に重要な前提です。 必ずご一読ください。
書き手のロールは技術広報
この記事を書いているのは、現役のエンジニアではありません。 元々CARTAでエンジニアをしており、技術広報に転身し、人に伝えることを専業とする立場の人間です。 仕事柄、成果報告を含むエンジニアリングに関する多くの資料を読み、ブログなどのライティングサポートしています。それを知った若手のエンジニアから相談を受けたことが背景にあります。
あくまでも人に伝える職業の立場からどう人に成果を説明すれば伝わるのかのみに焦点をあてて書いています。この記事は、その目的で書いたものであり、「CARTAで評価を上げるためにこうすればいい」と語ったものではありません。
CARTAエンジニア評価制度
もう一つ重要な前提があります。それは CARTAのエンジニア評価制度 です。
CARTAでは 技術力評価会 という独自のエンジニア評価制度を導入しています。その特徴は 事前に設定した目標の達成度ではなく、 事業へのインパクトや貢献度という観点で事後に評価されるのが特徴 です。
具体的には、エンジニア一人ひとりが事業目的達成のために半期で現場で行った行動とその成果を別事業部のエンジニア2名に説明するスタイルです。いわば、転職面接のように、限られた時間で自身の力を的確に伝えなければならない場面と言えます。
この評価会を前に、エンジニアは半期の行動・成果・マインドセットを説明する事前資料(以下、評価資料)の作成を求められます。
また、その資料および評価フィードバックはGitHubで社内公開されています。つまり社内リポジトリにアクセスできる人であれば誰でも読むことが可能です。
今回は、この評価資料をどう分かりやすく書くかを題材に、相手に成果をどう分かりやすく伝えればよいのかについて述べていきます。
前置きが長くなりました。では本編をどうぞ。
評価会資料を読みやすくすることは "本質" なのか
Howの話をする前に"なぜそれを語るのか"について書きます。
前提、CARTAの技術力評価会は、評価会資料がわかりやすくプレゼンが上手いからと評価が上がるような評価制度ではない です。
過去、2年目の私の評価会でそのようなFBをもらったことがあります。
評価会は必ずしもプレゼン能力を評価する場ではないが、うまく伝える能力というのは仕事において大きな武器になるのもまた事実なので、そこが出来るのはポジティブに捉えたい。
それを踏まえた上で思うのは、 だからといって、説明がわかりにくくて良いわけではない ということです。本質的な価値を評価してもらうためには、その本質が過不足なく伝わっていてほしい。わかりにくいのは損です。
私は評価者をやったことないので、あくまで <物事を人に伝える職業> として筋が良さそうな方法を書きます。つまり、これに従ったからと行って評価が上がるとは限りません。正解でも教典でもありません。ただの個人の思いです。
そもそも評価会は何をする場所なのか
評価を受ける側ではなく、評価者の目線で考えてみましょう。
事業における評価は、ビジネスインパクト(変化量と成果)とその人の寄与度をもって判断するでしょう。
よって、私が評価者だったら以下が知りたくなります。
- この半年で起こった Before, Afterの変化
- あなたがその変化において寄与した度合い
- その変化によって生まれた成果(実績、もしくは予測的数字)
つまり
- 変化の前後
- あなたの寄与度
- その数字的インパクト
が伝われば評価可能です。なぜなら事業貢献を見るにはそれが必要だから。
この3要素が過不足なく伝わっていればわかりやすい資料になります。
評価会はそれらを伝えた上で、あなたが頑張った姿勢と考え方を伝える場だと言えるでしょう。それは個人の現状を知る意味の他に、これからの成長を支えるFBを書くために必要な要素です。
前提をどうやって伝えるのか
やっとHowの話。
では、成果やその前提をどのように伝えるのでしょうか？
一番のアンチパターンは最初から詳しく話し(書き)すぎることです。 前提が多すぎたり、いきなり細部を語り始めると混乱します。認知負荷が高いのです。 詳しい話は大枠が分かってから肉付けしていけば良いのです。
おすすめは結論、アピールポイント(あなたが寄与した部分)、Before、Afterをそれぞれ3行にして資料の最初に書くこと です。 その後に詳細を語ります。それを図示すると以下のようなイメージになります。
- なぜ結論が必要かというと、全体像と成果を知りたいから
- なぜBefore, Afterが必要かというと、変化の前後を知りたいから
- なぜアピールポイントが必要かというと、あなたの寄与した部分と注目してほしい部分のサマリだから
です。それらを最初にそれぞれ3行で話します。
すると 読み手に"この人はこういう変化を生んで、こういう寄与をした。どうやらここを評価してほしいらしい"と読み解くための視点を与える ことが出来ます。
これを与えたうえで、詳細を語っていくとスムーズに伝わります。きっと、上記を徹底するだけでかなり伝わりやすくなります。
認知負荷の下げ方については t-wadaさんが出ているラジオ や『プログラマ脳』がおすすめです。
誰にとっての課題なのか
レビューをお願いされた資料では誰から見た課題なのか読み取ることが難しいものがありました。
誰から見て課題なのか、を明確にすることは非常に大切です。 なぜなら課題設定は解法の前提だから です。
いま槍玉に挙げられている課題が
- 組織の課題なのか
- 個人が感じている課題なのか
は切り分けて話したいです。
組織課題でないものに必死に向き合うことは、一歩間違えると「組織の文脈を慮らずにただ独走する人」と判断されかねないためです。
課題が取りうる主語を意識する
誰にとっての課題かによって「解き方の適切さ」は変わってきます。それがはっきりと評価者に伝わらないと"その解き方が適切なのか"さえもうまく伝わらないことになります。
例えば一言に課題といっても
- 事業部にとってすでに認識されている課題
- Bizサイドは認識している課題
- もしくは認識していないが困っている
- Engineerサイドは認識している課題
- 状況を踏まえたうえで個人が感じている課題
など「課題」と言っても様々な主語があります。
課題を定義・言語化し、それを正確に相手に伝えられるスキルは「課題解決能力」の前提となる部分(だと個人的には思うの)です。
特に大切な部分だと思うので大きく紙面を使い伝えました。
CARTAスタッフエンジニアが言う技術力を読んでみようぜ
一端のエンジニアでない人間が語る<技術力>を信用したくはありません。
Lighthouse Studio CTOの @co3k が書いた記事、 CARTA の「技術力」はあなたのイメージする「技術力」ではないかも には
CARTA における技術力は、単なるコーディング能力や技術知識の蓄積を超えたもの。問題の本質を見極め、持続可能な価値を提供するための広範な能力を指す。
とあり
「評価軸」は、「実現力」と「改善力」のふたつの観点から成っています。
と書かれています。
前述した課題についても
実現力 - 何が課題で何が必要と考えたか 課題をしっかり見つめ、精査する こと - 表面的な課題の解決だけではなく、根本的な解決になるよう努力する こと - それらに囚われすぎないようにすること
と明言されています。これはCARTAの文脈を強く含みますが、きっと他社の文脈でも当てはまる要素は多分にあるでしょう。 この観点を踏まえて成果をアピールするともっといいものになると思います。
今回は以上です。
