説明を受けるのと実際にやってみるのとで大きく違っていて、自分がエンジニアとして将来どうしていきたいかなどのキャリアプランはイメージできてなかったですね。IT業界未経験の立場で入社して、技術のことは分かっていなかったのでがむしゃらにやるしかないと考えていました。ですが、運用業務から設計構築業務に上がっていく必要があるのは明確でした。

エンジニアとしてレベルを上げていくためには、手順書通りのことをやるだけでは不十分です。技術を勉強して、理解して、使って、様々な技術的要件を実現していくことで初めてレベルが上がっていくと考えているため、純粋な技術力を評価できるよう制度設計をしました。なので、当初は運用業務における加点はほとんどなかったわけですが、かといって未経験からいきなり技術力のみを評価されるのは、社員の負担が大きい。そこで、運用業務における力を評価する項目を追加し、技術的な勉強が評価される項目も設けました。

たしかに各技術項目に、勉強して理解している、指示を受けて構築できる、一人で設計構築できる、という風に評価をつけていく項目があり、とにかく勉強をしなければならないと動機付けになる制度になっていますね。エンジニアの勉強と言うと資格のイメージだと思いますが、資格ごとに点数が設けてあって、取った資格がどれだけ自分の評価につながるのかが分かりやすいです。

まず評価をする人が、評価を受ける人より技術力が高い前提で作っています。ネットワークとサーバという技術領域の違いはあっても、ある程度の技術力を持っている人が評価者であれば、その人がどれだけの技術力をもっているのかは分かります。なので、一緒に働いていない場合でも、案件対応をどのように行い、その中でどんな技術を扱ってどんな内容の設計構築をしたかという話を聞いて、各技術項目をそれぞれどの程度の知識、経験をもっているかを数値化する内容にしています。そうすることで、上司の好き嫌いや売り上げが高い低いや現場のお客様からのお話などの曖昧なもので評価が行われることなく、エンジニアとしての価値がどの程度あるかを定量的に表すことができると考えています。

私は実際に上司が同じ現場にいない立場です。最初は運用の現場だったのもあって、人事考課の技術項目の加点が難しい状況でした。なので、資格をとって点数を上げつつ、手当たり次第に興味がある勉強、社内サーバを借りてWebサーバを構築したりAnsibleを触ってみたりして、社内wikiにアウトプットすることをやっていましたね。人事考課の場で、自分が携わってきた案件の話をするのではない手段で自分の技術力を見てもらえるようになって、社内にも自分を売れるようになりました。上司が近くにいないからこそ、普段からしっかりアウトプットする重要さを感じています。

勉強して資格を取ることは会社として奨励していますし、どんどんやってもらいたいのですが、人事考課で意図しているのは得た知識を使って何か行動をする点です。知識があることはエンジニアとして最低ラインで、経験を得て技術が身になることで評価が上がる制度と考えており、大塚さんの例は意図することがうまく伝わったのだなと思っています。

勉強すれば評価が上がる、と言っても設計構築の現場で業務経験を積めないと昇進につなげるのは難しいとは感じています。どうしても経験が反映される部分は大きいので、技術を知っていても実際のネットワークやサーバにどう使われているかを理解していなければ、各項目の評価点を上げていくことはなかなかできないですね。

また、AWSやOpenStackのようなクラウド系の技術についての項目が少なく、評価項目の更新が若干遅いかもしれないとも感じています。サーバやAWS、仮想化基盤、Openstackやコンテナなどが発展している中で、人事考課にはそのあたりの項目がありません。

クラウドの根幹にある技術をしっかり理解している前提で、新しい技術を勉強しても評価されにくい構造になってしまうと、技術のメインストリームに乗り遅れないように努力できる技術者が減ってしまう。難しいのは承知していますが、技術の発展にリアルタイムに合わせながら項目を更新できれば、新しい技術を学ぶメリットが提示できると思います。

エンジニアとして新しい技術を追うことはもちろん重要だと思います。しかし現状、新しいと言われている技術の大半は、既存の技術の上に成り立っているわけです。

これからの時代、例えばクラウドの主流であるAWSに触れることが当たり前になるかもしれない。しかしAWSの中身を知って、物理的な部分の技術を理解して設計・構築ができる、トラブル対応ができるといったことが、エンジニアに求められていく部分です。AWSの中身を知っていくにあたっては、今の人事考課の技術項目でかなり充足できていると考えています。

AWSの操作ができる、それはそれで価値のあることなのですが、現場に出て仕事をするにあたってはあまり発展性がないんですね。AWSってフォンノイマン型コンピュータをベースにたくさんのサーバが動いているだけなんです。技術変革ではなくサービス提供の仕方が柔軟になったものと捉えていて、技術的に新しい何かを生んだと言うよりは既存技術をうまく使えるようにしたものです。

サーバをどう動かすかがわかっても、サーバの何がどう動いているかの仕組みを理解していないとエンジニアとして価値を出していくのは難しいと思いますね。実際にクラウドに触れるだけの人が現場に入って、トラブルが起きた時に対処できるケースはなかなかありません。トラブルの原因は根幹にあるレガシーの部分なので。今までレガシー部分の仕事をしてきて、クラウドも知っているという人がクラウドを扱う現場で活躍できるので、流行りにぶらされずに根幹の理解を積み重ねた上で新しいものを学ぶ姿勢を持っていてほしいです。

もちろん古くてもう使わないよ、というような技術は評価項目から削っていこうとしています。しかし新しい技術を短絡的に追う形にするのではなく、全体を見た上でエンジニアとしての価値を適切に表現できる項目づくりをしていきたいと考えています。

そうですね。今の内容は、面接の中でよくお話させていただいていることでもあります。世の中的にはクラウドが流行っていますし、弊社にも「クラウドができる人を探している」という要望をいただくことが多いのは事実です。これは単純に「クラウドを操作できる人」が求められているわけではなく、システムアーキテクトとして「適切にクラウドを利用できる人」が求められており、そのためにはクラウドの中身を分かっている必要があると考えています。この中身を知るためにはレガシー部分の知識が必要で、その知識習得のためにLinuCあったりCCNAであったりをやってみてくださいと、よくお伝えしています。中身を知らなくてもパッと使えるクラウドの素晴らしさはあるかもしれないですけど、中身についての知識、経験が伴わないままではエンジニアとしての価値はどんどんなくなってしまいます。

クラウドであろうがオンプレミスであろうが、原理原則としてのプロトコルや処理の仕組みを分かっているからこそ、お客様のシステムを考えられるという点は変わりません。クラウドはお手軽にシステムが構築できることから、処理の中身を考えずしてシステム化ができる点は事実ですが、表面的な話にとどまらず、中身となる原理原則に対しても取り組んでもらうことがエンジニアの価値につながると考えています。

自分もAWSの資格を取りつつ、社内のサーバを借りて、仮想化について調べながらいろいろ触ってみたりOpenStackを作ってみたりしてきたので、三宅さんのお話はすごく分かります。実際にOpenStackを作った後にAWSを触ると、画面とか機能とかサービスが似ているなと感じました。裏側で使われている技術は近しいのかな？と想像と興味が膨らんで勉強が進んだので、クラウドから入ったとしても中身まで理解が進んでいくなら入り口としてはありだと思いますね。

いまの市場的に言えば、クラウド分野の比率がすごく高くなって規模も大きくなっています。そこに合わせて人事考課を作るかと言ったらそうではなくて、エンジニアの価値というものに目を向けると、今の人事考課項目の比重が高いだろうとは考えています。入り口としてクラウドの項目を入れることはありだと考えていますが、いま時点での比重が高くないと考えているので、今はまだ追加しないですね。

ただ人事考課項目を作った元々の発想として、項目は作ったときのままなわけがないと考えていました。設計構築をメインのSES業務として始めたクラスアクトが運用にも手を出した。だから運用業務で培われるスキル項目も追加しましたし、今後の市場全体を見ながらエンジニアとして必要なスキルを選択しながら、内容をアップデートしていくつもりです。