はじめに

「コーディングができる」ことと「技術的な意思決定ができる」ことは、似ているようでまったくの別物です。 サッカーで「守備が強い」と言っても、1対1の対人守備が得意な選手とチーム連携の守備が得意な選手がいるように、エンジニアにも得意分野の偏りがあります。

この物語では、経歴や年齢だけで「ハロー効果」的に評価され、本来向いていないポジションを任されてしまった技術リードが、現場をどう混乱させたのかを描きます。

暴君と化す技術知識ゼロのテックリード

背景

これは、東京都内にある業界屈指の大手企業のクラウド案件でのことである。

この案件に、50代のベテランフリーランスエンジニアCが参画してきた。
プロジェクトには経験の浅い若いメンバーが多かったため、Ｃがテックリード的ポジションに就任した。

Cはコーディング歴は長く、実装スピードには定評がある。
しかし、インフラの知識やトレンドキャッチアップ、技術そのもの理解度については、正直かなり怪しいという噂がメンバーの間で流れていた。

Amazon S3はNoSQL?

ある日のミーティング。設計担当のエンジニアDが、データ保存先の構成について説明していた。

  • エンジニアD 🙂 「このファイルはAmazon S3に保存する設計です。」
  • テックリードC 🤔 「S3ね、了解。あれはNoSQLだから、柔軟にデータ入れられて便利だよね。」
  • エンジニアD 😳 「……え？ S3はオブジェクトストレージで、NoSQLデータベースとは別物ですが……。」
  • テックリードC 😤 「いや、SQLじゃないんだからNoSQLでしょ。」
  • エンジニアD 😨 （SQLじゃないもの全部NoSQLだと思ってる……？）

テックリードCはS3でのアプリケーションの実装経験があるにも関わらず、S3をデータベースと言い張る始末。

わがままでミドルウェア変更

本番稼働中のWebサーバーについて既存環境はApacheで安定稼働していたが、テックリードCが突然言い出した。

  • テックリードC 😤 「俺はnginxの方が使い慣れてるから、nginxに変更しよう。」
  • エンジニアD 😐 「今Apacheで問題なく動いていますし、変更するリスクの方が大きいのでは……。」
  • テックリードC 😅 「何か問題があったら、Apacheだと俺何もできないよ～。nginxにして。」

明確な技術的理由もないまま、Webサーバーはnginxへ切り替えられることになった。

そして切り替え後。

  • テックリードC 😨 「あれ……？ 俺が作ったWebアプリが動かない……！」
  • エンジニアD 😳 「え、どこが動かないんですか？ エラーログは出てますか？」
  • テックリードC 😖 「分からない！ 動かし方が分からないよ～」
  • エンジニアD 😰 「いや、動かし方が分からないと言われても、状況を教えていただかないと調べようが……」

自分が得意と言っていたのに、いざ変更すると分からないと言い出し、トラブルの詳細を聞いても分からないの一点張りで説明をちゃんとしない。
言い出した変更で他のメンバに迷惑をかけたにも関わらず、テックリードCから謝罪の言葉はなかった。

新しい技術には理由もなく反発

このプロジェクトでは、インフラ構築の効率化のためにIaC（Infrastructure as Code）の導入されていた。

  • エンジニアD 🙂 「うちのプロジェクトでは、IaCで構成管理しているので、設定変更する際はコードの方を修正してから変更をお願いします。」
  • テックリードC 😏 「IaCって一回こっきりでしょ。これに時間かけるの無駄じゃない?」

明確な根拠は示されず、ただ「新しいから」という理由だけでアレルギー反応をしめす。 こうしたやり取りが、IaCに限らず新しいツールやライブラリの提案の度に繰り返された。

コーディング中に自分の知らないライブラリが出てくると、テックリードCは調査すらしようとしなかった。

  • テックリードC 😩 「このクラスの関数の使い方が分からないよ～。」
  • エンジニアD 😐 「公式ドキュメントにハンズオンのサンプルもあるので、少し試してみれば分かるかと……」
  • テックリードC 😒 「面倒だからこのクラス使うのやめる。」

必要最低限の調査すら放棄し、周囲に丸投げする姿勢が常態化していた。

根拠のない「マイナーサービス推し」

クラウドサービスの選定会議でも、同様のことが起きた。

  • エンジニアD 🙂 「このワークロードには、実績も多いこのマネージドサービスが適していると思います。」
  • テックリードC 🤔 「いや、それは皆が使ってるサービスだから負荷がかかって遅くなる。マイナーなサービスの方がいい。」
  • エンジニアD 😳 「……利用者数とサービス自体の性能や可用性は、基本的に関係ないと思うのですが……。」
  • テックリードC 😡 「もし、負荷がかかってサービスが動かなくなったら責任とれんの！！」

具体的な数値やエビデンスは一切示されないまま、感覚と経験則だけで意見を押し通そうとする場面が続いた。 プロジェクトマネージャーが経験の長いテックリードを妄信していたため、Cの案を採用、チームは技術的負債を背負うことに。

解説

テックリードCのような人物が生まれてしまう背景には、「コーディングができる = 技術力が高い = マネジメントやアーキテクチャ判断もできる」という短絡的な評価があります。

サッカーに例えるなら、「守備力が高い」と評判の選手にも、1対1の対人守備が得意なタイプと、チーム全体の連携で守るタイプがいます。
前者を後者のポジションに置いても、うまく機能しないことがあるのと同じです。

コーディング能力、技術知識、そして人をまとめる力は、それぞれ別のスキルセットです。
年齢や経歴、実装スピードといった一部の評判だけで「ハロー効果」的に高く評価し、技術的な意思決定権を持つポジションを任せてしまうと、今回のような現場の混乱を招きかねません。

適材適所の見極めには、実際の言動や判断のプロセスを、短期間でも観察することが欠かせないと言えるでしょう。

おわりに

世の中には、経歴や年齢だけでポジションを得てしまい、実力が伴わないまま現場を混乱させる人が実際に存在します。

こうした人物のフォローに時間を取られ続けることは、AIの台頭が進む今後、エンジニアにとって大きなリスクになっていく可能性があります。 理不尽な現場に見切りをつけ、転職やフリーランスとして独立するなど、環境を変える選択肢を検討してみるのも良いかもしれません。

関連記事