エンジニアのスキルや経験を評価制度や教育制度へと反映
先述した課題の3点について深掘りしていこう。まず1点目の個人の成長。特に大規模プロジェクトではフェーズを区切り、必要な技術を場当たり的に習得することが少なくない。言われたことだけをやる。そのため全体像の理解や体系的な知識の構築が進まない。結果として、設計原則や技術の本質を深く学ぶ機会が減り、長期的な成長が阻害される要因となる。現場でもよくない空気が流れてくる、といった悪循環が生じていた。
そこでスキルロードマップを書いてスキルツリーを整理することにした。現在この仕事をしているなら、次のステップにはこれがある。背景にはどのようなスキルセットが必要かなどを議論するきっかけとなった。
特に会社が成長すると、このスキルツリーで「盛り上がった」という。新しいサービスを開始すると、いろいろなスキルや経験を持つエンジニアが参入するため、異文化交流のようになるからだ。それぞれの専門分野ごとに重要視するスキルや経験が異なるため、新しい世界に触れて「そういえば昔学んだ」「全然知らない（不安）」「教えてあげる」と交流が盛んになる。
例えばセキュリティのサービスを始めることになりセキュリティスペシャリストが入社すると、プログラミング言語しか知らなかったエンジニアたちがセキュリティも学ぶようになる。中には「セキュリティの本質はガバナンスだ」と参考になる文献を紹介する人が現れたりする。「これは会社の制度にしなくては」と、スキル習得や経験を評価制度や教育制度へと反映していくことにした。
しかしここで壁に直面する。当時は、作業量の多さや正確さで個人を評価しようとする空気があった。
マネジメント層も理解する姿勢は示すものの、前提が過去と大きく異なるためか話がかみ合わない。池ノ上氏はトップダウンのアプローチが必要と考え、マネジメント層とIT技術をテーマに議論する場「技術会議」を設定した。
プロダクトのマインドセットでは「建築ではない。子育てなのだ。育てる過程で親の方も育つのだ」と例えたり、メインフレームとクラウドのアーキテクチャの違いであるとか、地道に企業ITについて情報交換したりするなかで、エンジニアへの理解が育まれてきた。
もうひとつ、評価制度でも似たような苦労があった。IT業界では見積もりのなかで単価を設定することがある。そのためか「エンジニアを受注単価で評価しよう」という流れになりかけた。池ノ上氏は「これは悪しき成果主義。これでは会社ではなくなってしまう」と頭を抱えた。
ただ受注単価で考える側は悪意があるわけではなかった。「IT業界の流通革命」を掲げ、多重下請け構造を打開し、国内IT業界を効率化しようとする思いがあるゆえに、受注単価という数字に着目している、という背景がある。
そこで技術力を評価するための議論を重ねていった。技術スタックにおいては技術の幅、深さ、応用力、教える力、ブランド力など重視したいものを洗い出した。同様にロールについてもPM、テックリード、プリセールスなどがあるなか、成長率、引き継ぎ実績、提案力、交渉力、拡大力、リスク管理などを洗い出し、それぞれパラメータ化した。
こうしたパラメータに加えて市場単価の実績を合わせて想定年収の参考値を出す。さらに評価会議の場で当人のキャリアプランや、やりがい、人間関係の重要度などを考慮したうえで、本人が最も輝き、成長できるようにするために評価をフィードバックしていくという流れにしている。
