電通総研 テックブログ

電通総研が運営する技術ブログ

エンジニアのスキルマップ・テックリードへの途

みなさんこんにちは。電通国際情報サービス(ISID) 金融ソリューション事業部の水野です。
これは電通国際情報サービス Advent Calendar 2022の16日目の記事です。

今回は、ISID金融事業部で運用しているスキルマップについてご紹介します。

テックリードとは

実は、ISIDの少なくとも金融事業部にテックリードと言うポジションはありません。
実在するのはチーフアーキテクトと言う職種のみで、各プロジェクトでリードエンジニアやテックリードという仮想的なロールがあるのが実態です。
一時期はフルスタックエンジニアと呼んでいる時期もありましたが、近年このワーディングが好まれない印象なので、大々的に使っていません。
主観ですが、フルスタックエンジニアはインフラ知識/運用系の知識のウェイトが高いエンジニアで、テックリードはソフトウェアアーキテクチャ、Webアプリケーション実装技術寄りのエンジニアという印象を持っているので、フルスタックエンジニアと使い分けても良いと考えてはいます。
フルスタックエンジニアより、最近はフルサイクルエンジニア(1)の方が一般的かもしれません。

アーキテクトやテックリードなどいろいろ呼び名はありますが、以下の職務をこなすエンジニアと定義しています。

  1. システムアーキテクチャ(2)、ソフトウェアアーキテクチャの規定
  2. 技術的な難易度、重要度が高い箇所の実装
    • フレームワーク部分やコア機能の実装など、システムの根幹部分の実装
    • プロトタイピング
    • 技術課題の解消
  3. 技術的な意思決定
    • テクノロジスタックの選定
    • 開発手法、プロセスの策定
    • 品質保証戦略立案(例えばユニットテスト
    • 要件、仕様面の技術的な見地からの判断
  4. 技術系チームの組成、運営、醸成
    • エンジニア育成
    • 守備範囲はアプリケーション基盤チームやインフラチーム
  5. 技術者代表として内外のステークホルダーとの合意形成

クラウド領域を主戦場にするシニアエンジニアは、クラウドアーキテクトと呼んだりすることもありますね。
スキルマップは、上述の職務をこなす為にどの程度の習熟度が必要なのかを測ることを目的としています。

スキルマップ

前提

項目ごとに個別具体的な説明を付与するのは辛いので、以下の前提を置いています。

上記の前提のほか、ISID金融の業務に依存した構成になっている部分もあります。
なお、資格試験と言うと敬遠しがちな方も多いですが、意外と良問が多く、基本的・体系的なITスキルを身に付けるには有用です。
問題もアップデートされており、例えば最近ではクラウド機械学習に関する出題もあり、化石過ぎて実戦で使えない知識と言う訳ではなく、むしろエンジニアなら最低限習得しておくべき素養と考えます。

スキルマップ

補足

ビルド
様々な言語のビルドの仕組み、ツールチェインに関する知見に加え、Bazelと言ったこの先必要になりそうなツールの知識も含みます。

SaaS型C/Iの利活用と運用
最近は専らGitHubActionを利用しています。一方、今後クラウドプラットフォームのC/Iサービス利用の増加も考えられるので、クラウドベンダーのマネージドサービスの知識も含みます。

利用頻度高の言語に対する一定の習熟度
金融事業部ではJava、.NET(C#)が多く、次点でPythonという肌感覚で、これらを利用頻度高に位置付けています。
最近では一定の規模の開発にgoが採用されることも増え、研究開発ではRustの利用も始めました。

依存性低減力
参照が循環していないなど、モジュール依存関係が複雑過ぎないプログラム設計および実装を意味します。
モジュール間の依存性を極力排すことを目的とし、DIコンテナによる実現などが考えられます。

トランスパイル、ミニファイ、広義のビルド、デプロイを中心としたC/Iスキル
フロントエンドのビルド周りは苦手な人が多い印象で、Webpack、Turbopackなどツールチェインの習熟度を含みます。Romeなど新しめのツールチェインの知見も含みます。

近代的なアーキテクチャ
相当に弊社弊事業部の主観に満ち溢れたものですが、例えば Cloudflare workers+D1+Postgres WASMで、CDNエッジサイドだけで何かを実装するみたいなものをイメージしています。

CDN
FastlyやCloudflareなど3rd Partyを含みます。

OCIランタイム
開発ではDockerを利用するケースが多いですが、OCI界隈の動向や各種OCIランタイム実装の知見です。

Kubernetesおよびエコシステム
どのクラウドプラットフォームを使おうとも、Kubernetesが選択肢の一つとして上がる事が普通になりました。
インフラを専門領域とするエンジニアは、周辺エコシステムを含めて深い知識・理解が必要な時代です。

成果物体系構築スキルおよび設計ツール
設計ツールとは、MarkDownを書くエディタや画像描画ツールなどが該当します。
画像描画ツールはdraw.ioが大半ですが、最近ではmermaidも徐々に増えてきています。
アーキテクチャ系ドキュメントを書く際は、アーキチームのみでPlantUMLを採用するケースもあります。
成果物体系に見合った設計ツールを選定し、プロジェクト内で統一します。

運用

上記スキルマップの最下層の項目に対し、個人個人が自己申告でレベルを入力します。
レベル(習熟度)は4段階で、以下が基準です。

  • Lv1 触ったことがない
  • Lv2 業務で触ったことがある
  • Lv3 本質を理解し、使いこなしている
  • Lv4 本質を深淵まで理解し、適切なシーンで応用可能

自己申告したレベルは承認制で、上位技術者あるいは上席がOKならば確定、NGならばフィードバックします。
とは言え、実際これを継続的に運用するのは難しく、課題も多いです。
運用上の課題で私が認識しているものは下記です。

  1. 事業部の全員がレベル設定している訳ではなく、技術系業務が中心の2割程度のエンジニアのみ実施
  2. 年度によっては実施していない
    • これが一番最悪なので、2023年度は絶対にやる
  3. レベル設定は申告ベースのため、主観的になりがち。ただ、上位技術者によってある程度是正は可能
  4. スキルマップの習熟度と技術系のポジションを、具体的にどう結びつけるかの解に至っていない
    • どの領域をどのレベルまで修めればテックリードかなどの基準がない
  5. スキルマップ自体の更新は半年、出来れば3カ月程度で見直したい
    • 個別要素技術に因らず、なるべく普遍的なスキルマップとなるよう志向しているので負荷は軽い

まとめ

テックリードは技術力で現場を牽引するのがミッションですが、技術に詳しい人が担う仮想的な職種であることが多いのではないでしょうか。
非常に重要な役割であるにもかかわらず、インセンティブや裁量の範囲など未定義なケースもあるかと思います。
組織によって「テックリードとは何か」は異なりますが、我々ISID金融ではその重要性を認識しており、可能な限りミッションとスキルセットを可視化しようと試みています。
また、テックリードに至るまでの道のりと、そもそも技術者が習得すべきスキルについての定義も必要と認識しています。

まだまだ道半ばではありますが、今回はスキルマップのご紹介でした。
最後までご覧になっていただき、誠にありがとうございました。

執筆:@mizuno.kazuhiro、レビュー:@yamashita.tsuyoshiShodoで執筆されました


  1. https://netflixtechblog.com/full-cycle-developers-at-netflix-a08c31f83249
  2. クラウドなどのインフラストラクチャを含む、システム全体の構成