ITエンジニア個人の実績主義について

　しばらくnoteの記事を書かないと、毎月の投稿が途切れるよというアラートが出てきます。そこで、特にきっかけはないのですが、普段から思っていることの１つを書いておきたいと思います。
　話のテーマは、私がITエンジニアとして自分の実績を大切にしているということで、ほかの方にも参考にしていただける部分があるのではないかと思っています。

シェフとITエンジニアの類似性

　一時期、Netflixで『CHEF'S TABLE』（シェフのテーブル）というドキュメンタリーシリーズを観ていました。世界の一流シェフにスポットを当て、毎回1人ずつその来歴と料理の独創性を紹介していくものです。
　これを見ていたときに感じたことの１つが、シェフの業界とITエンジニアの業界は似ているということです。どちらも労働集約的であるため個人の技術力が要求されて人材が流動的である点や、高級店（利益率の高い会社）で働くと収入も高くなる点など。
　世界の一流シェフたちに見習いたいのは、その多くが有名料理学校を好成績で卒業したあとにとにかく高級店に絞って就職活動を行い実務の第一歩を踏み出しているところ。安い定食屋で修行しても高級店のシェフとしての技術が十分には身につかないだろうというのは想像できることで、似たようなものがITエンジニアにもあると感じました。
　自分が数年後にどこでどんな仕事をしたいかを考えてキャリアを積むべきなんだろうなということです。それは収入の差が問題なのではなくて、大手SIerの仕事、サービスベンダーの仕事、情シスの仕事、スタートアップ企業の仕事などはそれぞれ性質が異なるだろうという話です。

業務経歴書に何を書けるか

　私は１つのプロジェクトに長期で入っている関係でしばらく業務経歴書を書いていませんが、定期的に書いたほうがいいなと少し反省しているところです。
　私はもともとはSES社員で、当時は社内評価の基準として統一したスキルシートを用意しないとみたいな議論が社内でありました。スキルシートでの技術力の評価は、社内の評価基準を統一するための手法として正しいと思います。一方で、それは個人としてのオリジナルの価値や特性を表現するには情報の質が薄く不十分であるとも思います。
　実際に求職活動を行うと、まず要求されるのは業務経歴書です。自分が中途採用を担当するとしても、最も重視する情報は業務経歴書だと思います。そこにはその人が実業務として何をやってきたかが具体的に書かれるので、定量的な評価に終始せず個人の特性がしっかり表現されます。
　逆にいえば、自分の技術者としての価値を高めたいとか高い評価を得たいと思ったときに、業務経歴書に何を書けるだろうかという考え方が良い参考になるということです。この半年くらい仕事で何をやって何を達成したのだろうか、と私は定期的に自問します。
　なお、現在の業務とは異なる分野に手を広げたい場合は、ポートフォリオとして提示可能なものを個人製作したり、第三者による評価（資格やコンテストのスコア）を得ることで、業務経歴書に記載できるアピールポイントになります。

日報の習慣

　長期的な話だけでなく、短期的なことにも目を向けると、私は日報（一日単位の業務報告）を大切にしていることに思い当たります。
　もともとは会社員のときに上司から要請されて書いていたものですが、続けているうちに日報を書くという行為それ自体が自分にとって良い作用をもたらしていると感じるようになりました。
　というのも、日報にはその日一日の業務で何をしたかを書くわけですが、それによって自分が業務において何を達成したのかがはっきりと意識されるからです。今日の成果を確認することで、明日の業務をその上に積み上げていくことができ、進捗を捉えるうえでも有用でした。
　運用現場の新人だった頃は、今日はこれを習得したから次の機会にはもう一歩こういったことまで進もうとか、開発の時は今日はこの機能を実装できたので明日はこれに取り組めるとか。
　そして、これらは自分の業務実績を他人に説明する際にとても役に立ちます。そもそも上司への報告書として書いているわけですが、他の誰から聞かれても、毎日仕事で何をやっているのかという問いに明確に答えられるようになります。それがとても大切なことで、自分の技術者としての価値を示して人からの信頼を得るために必要なことだと感じます。

やり遂げたことを増やす

　ここまでで概ね言いたいことを言ってきましたが、個人としての実績を積み上げることが、ITエンジニアの価値を高めることだというのが私の主張です。
　加えて、その実績は単に「やったこと」ではなく「やり遂げたこと」でないといけないということに触れておきます。これはある意味ではレトリックの問題であり、意味付けとアウトプットの重要性の話になります。
　例えば、システムに不具合があって１日調査をしたけれどまだ解決できていないというとき、日報には何を書くでしょうか。そのまま調査していますと書くだけだと、あまり良い内容とは思えません。不具合の再現方法がわかったとか、問題個所の絞り込みがこれくらいまで進んだとか、この部分で修正をかけようと思ったがそれでは対応できないことがわかったとか。具体的にやり遂げたことは何かを書くべきだと思います。
　終わったこと以外は、人に伝わりません。成果を出している風に表現を工夫すると、人に伝えるものとして内容が充実してきます。それが実績を積むということではないかと思います。

実績主義？

　最後に、本記事のタイトルで実績主義という言葉を用いた点について書いておきます。実績と成果とは似たような意味ですが、成果主義という言葉を使ってしまうと、どうしても企業の業績に貢献したかどうかという基準に思えてしまうため、言葉を変えています。
　ITエンジニア（およびその他の技術職）の収入は、業績の良い企業に所属することで上がります。しかし、その技術力は企業の業績を基準に評価されるべきものではありません。つまり技術者としての評価と収入の大小はちょっと質の異なる話なのですが、それをふまえた上でなお、私は技術者としての実績をもとに評価する基準を大切にしたいと思います。
　そもそも私がITエンジニアになったのは手に職をつけて特定の企業に依存することなく生きていきたいという願望からでした。そのために、個人としての市場価値を高める必要があったし、今もかつてより一層強くそれを意識しています。
　同様に個人の技術を磨いて企業に依存することなく企業社会を生きていきたいと希望する人はそれなりに多くいると思っています。でもそのときに、技術を磨くことそれ自体よりも、実績として第三者に提示できるものを多く積み上げることが大切なのだという観点を提示したいと思ったのが本記事になります。
　どこかの誰かの参考になれば嬉しいです。またこの記事も私のITエンジニアとしての自己表現なので、広い意味での実績作りの１つとして残しておきたいと思います。