こんにちは、しんざきです。週に一回ファミコン版のイーアルカンフーを遊ぶ習慣がもう15年くらい続いておりまして、そろそろ一度知見を集積しようかと思っているところです。面白いですよね、イーアルカンフー。

この記事で書きたいのは、大体以下のようなことです。

・「評価されやすいエンジニア」とは、「ちゃんと自分の成果を言語化してアピール出来るエンジニア」です

・「アピール」というと苦手意識を持つ人が多いのですが、必要なのは自分を大きく見せることではなく、具体的な達成状況の可視化です

・「自分の成果を言語化出来るか」というのは、日々の仕事で能力を発揮する上でもとても大事です

・成果を言語化する上では、ちゃんと「ストーリー」を考えることも大事です

・ストーリーといっても、別にありもしない物語を作れという話ではなく、組織が持っているビジョンや方向性に合致する成果になっているか、という話です

・特に新人さんには「組織のストーリーに沿った成果の言語化」を意識するようにお願いしています

以上です。よろしくお願いします。

さて、書きたいことは最初に全部書いてしまったので、後はざっくばらんにいきましょう。

まず自分の立場を明示しておくと、しんざきはRDBMSを軸足に色々やるITエンジニアでして、自分で動きながら部下もマネジメントする、いわゆるプレイングマネージャーの立場で20年近く働いています。その為、自分も評価を受けますが、部下の評価もします。割合的には後者の方がだいぶ多いです。

先日はてな界隈で、「評価されるエンジニアの特徴」みたいな話題を見かけました。やはり、社会人にとって「どんな評価を受けられるか」というのは極めて重要なテーマでして、興味を持った方も多いようでした。発端になったのはこちらの記事なのでしょうか。

評価されるエンジニアの特徴とは

本日の題材「評価されるエンジニアの特徴」ですが、私なりの持論を言うのであれば
ズバリ、「贔屓されるエンジニア」だと考えます。
贔屓という言葉、嫌な印象を感じるかもしれません。
でも違います。
贔屓されることは特別なことではなく、誰でも公平に得られる特権です。

で、自分でもこのテーマについて書いておきたくなりました。

当たり前のことですが、評価される為には定められた目標を達成しなくてはいけませんし、目標設定のやり方は組織それぞれ、職種それぞれ、人それぞれです。当然それに伴って必要とされるスキルも違えば、適した働き方も違う為、「評価される方法」を一般化するのは非常に困難です。

とはいえ、色んな組織を見ていると、「評価を受けやすい人」「高く評価されやすい人」に一定の傾向があることも事実でして、何が重要かって

「自分の成果をちゃんと言語化して、組織にアピール出来ているかどうか」

が一番重要です。

いや、言ってしまうと当たり前のことでして、もったいぶるような話じゃないんですけどね。

まず前提として、成果に応じて適切に人員を評価するのはもちろん組織の仕事、マネジメントの仕事です。その為に、組織はきちんと目標管理や成果面談の仕組みを設計しなくてはいけないですし、それを運用しないといけません。その上で、可能な限り、適切な評価を受けていない人、評価に不満を持つ人を減らさないといけません。

「頑張っているのにちゃんと評価されていない人」がいる場合、上司がその状況を把握して、改善しないといけない、という話です。これは当然です。

ただ、それは「上司任せにしておけば勝手に評価してもらえるからOK」ということではありません。

上司の責任を前提とした上で、やはり「成果」というのは自動的に拾い上げられるものばかりではありませんし、数値化出来るものばかりでもありません。

例えばRedmineで全てのタスクが一定粒度でチケット化されていて、そのチケットの消化率がイコール成果になる、ということなら話は簡単ですが、明確に定量化出来るタスクばかりの職場は稀です。

「数値化は出来ないけれどこの先につながる大事な仕事」というのもあれば、「日常的な対応だけどやる人がいなくなると大変なことになる仕事」だってあります。

自分の仕事の出来について、一番把握しているのは自分です。自分で可視化しないと適切に評価してもらえないケースがあるというのも、ある程度致し方ない事実だ、というわけです。

同じ成果をあげているのに、何であいつばっかりが評価されているの？という場合、それは単に「言語化・アピールの能力の差」である場合が多いです。組織で働く以上、成果の言語化やアピールからは逃げられない、という話でもあります。

ただ、「アピール」っていうと、なんか凄く苦手意識を持っちゃうというか、腰が引けてしまう人が非常に多いように感じます。なんだか皆さん、「アピール」を「内実と異なって自分を大きく見せる」ことだと思ってしまい、その為に気が引けてしまう人が多いようなんですね。

評価をする側の視点で言うと、自分を大きく見せる必要などどこにもなく、むしろそういう「飾りつけ」的な意識はノイズで、ただ「評価を受ける際に能動的であって欲しい」というだけなんですよ。単に用意された質問に答えているだけだと、その人がどういう成果を出したのか通り一遍にしか分からないので、自分の言葉で成果を表現するよう意識して欲しいなあ、と。

私に関していうと、アピールにおいて重要なのは

・具体的であること
・能動的であること

の二点だけだと考えます。

「曖昧な言葉を使わず、何をやったのか具体的に分かること」

「聞かれてそれに答える形ではなく、自分で考えてまとめること」

の二点を満たしてさえいればそれで十分だ、と、部下の人たちにもそう伝えています。

「なるべく成果を飾らなきゃ」とか「自分を大きくみせなきゃ」なんてことは一切なく、ただ「やってきたこと」を明確にしてくれさえすればそれがアピールであって、それを拾うのは上司の仕事だ、と。

まあ、この辺は組織によって、上司によって考え方は変わるのかも知れないですが。少なくともしんざきの職場ではそうやっている、という話です。

その上で、成果の可視化について、私が部下の皆さんにお勧めしていることが、二点あります。

一つは、「この仕事の成果はどう言語化出来るか」ということを、仕事に手を付ける前に考えておくこと。

もう一つが、「成果を言語化する時、その成果のストーリーを考えてみる」こと。

まず一点目、「成果の言語化」をタスク開始の時点で意識しておくというのは、私自身が昔先輩から言われたことで、普段仕事を進めていく上でもとても重要です。

この仕事をやり遂げた時に、自分はどんな言葉で組織に成果報告出来るかな？ということ。自分がどのように組織に貢献したのか、説明の仕方を考えておくこと。

これまた当たり前の話ですが、仕事をする上では、その仕事のゴールが明確になっていないといけません。目隠しをした状態で全力で走れる人は稀ですし、自分が何の為に仕事をしているのか、よく分からない状態で全力を出せる人も多くはありません。

で、成果というのは、要は「どんなゴールにたどり着いたか」という意味なので、仕事のゴールが明確になっていれば、そのゴールを言葉にするだけで「成果の言語化」になるわけです。

逆から言うと、「成果を明確に言語化出来ないタスク」というのは、「具体的にゴールを明示出来ないタスク」「なんの為にやっているのか、というのが曖昧なタスク」とほぼイコールの意味になるので、タスク自体の解像度、落とし込み具合が低い可能性があるんですね。

これはタスクを実施する側が悪いわけではなく、タスクを振る側がきちんとしたタスク振りを出来ていない、ということでもあります。

気づくことが出来れば、指摘することも出来ます。「このタスク、目的とゴールが明確になっていないようなんですが」と最初の時点で確認しやすく、そこから仕事の深掘りにもつながっていく。そうすると、仕事自体の可視化も進んで、能力も発揮しやすくなる。

「成果の言語化」を意識しておくと、明確になっていないゴールに気づきやすい。だから、「この仕事の成果をどう言語化するか」を考えておくことが重要。まずはそういう話です。

二つ目、「成果を言語化する時、その成果のストーリーを考えてみる」こと。

一般に、アピールが上手い人と下手な人の最大の差は、ここにあるような気がしています。

単に達成したタスクを並べるだけだと、それは「やったことリスト」の作成に過ぎず、仕事の目的も明確になりませんし、評価する側にも響きません。同じ内容でも、そこにストーリーがあるかどうかで、受け取る側の理解度、納得感はまるで違ってきます。

ストーリーっていうとなんだか大袈裟ですが、別に何かありもしないお話を作らないといけないということではありません。「組織のビジョンや大目的の中で、自分がやった/やっている仕事はどんな位置づけにあり、自分の仕事はそのビジョンにどう貢献出来ているのか」ということを考えるのが、そのまま「ストーリー作り」になります。

RPGの戦闘を考えればわかりやすいと思います。ただ敵が出てきて、その敵と一戦一戦戦うだけだと、さしてプレイヤーの記憶には残りません。しかし、「苦労に苦労を重ねてたどり着いた、死ぬほど難しいダンジョンの最後の一戦」ならどうでしょう？あるいは、「物語の初期から登場していたライバルとの、雌雄を決する為の戦い」ならどうでしょう？

どんな組織にも、その組織なりの理念とか、ビジョンとか、ミッションというものがあります。それはもちろん利益創出かも知れませんし、社会貢献かも知れませんし、顧客に何かを楽しんでもらうことかも知れません。

で、どんなに小なりといえど、組織で働いている以上、一人一人の仕事は何かしらの形で組織の大きなミッションの一部になっています。

保守運用は大きく考えればシステムを維持して顧客に貢献する為、経理事務は会社組織を維持してミッション達成の足場を作る為、検証環境の構築は会社の技術力を向上させてアウトプットの質をあげる為。何かしらの紐付け方で、「組織のミッションにどう貢献しているのか」という流れは言語化出来るわけです。

一つ一つの成果を、「この成果は、大きく考えると会社にどう貢献しています」「全体としては、私は組織のミッション達成にこんな役割を果たしました」というストーリーに基づいて味付けすると、評価する側に対する説得力がマシマシになります。「この人がいないとどう困るのか」ということが具体的に可視化される、ということでもあります。

「会社の理念なんて何の役に立つんだ？ただのお題目だろ」という人がいれば、多分私は「いや、評価面談の時にめっちゃ役立ちますよ」と応えると思います。

「私はちゃんと組織に貢献出来ているよ」というストーリーを形作る為に、こんなに大事なものはありません。

「組織のミッションはこうですが、その中で自分のこの仕事はこういう風に貢献しています」というストーリーをちゃんと組み立てることが、評価を受ける上では非常に重要、という話でした。
長くなりました。

評価というものはする側も受ける側も面倒くさいものですが、それでも働く上では必須のことでもあり、一方様々な面で不満がたまりやすいところでもあります。

組織としても個人としても、なるべく納得感の高い評価を実現していただいて、みんながいい感じに働けると素敵だなあ、と心から考える次第なのです。

今日書きたいことはそれくらいです。

【著者プロフィール】

著者名：しんざき

SE、ケーナ奏者、キャベツ太郎ソムリエ。三児の父。

レトロゲームブログ「不倒城」を2004年に開設。以下、レトロゲーム、漫画、駄菓子、育児、ダライアス外伝などについて書き綴る日々を送る。好きな敵ボスはシャコ。

ブログ：不倒城

Photo：Nadim Merrikh