凡庸なエンジニアの成功戦略
Neo's Guest Book にて、
「凡庸な」エンジニアの成功戦略ロードマップについて記事書いてもらえるとうれしいです!
というコメントをいただいたので、考えながら書いてみます。
目次
- 「凡庸なエンジニア」って何?
- 自分は「凡庸なエンジニア」だったか?自分の経歴を振り返る
- 自分が特別ではないと思うところ
- 自分が稀有だったと思うところ
- 自己評価:僕は「割と普通」
- 僕以外のエンジニアはどんな経験をしてきたのだろう?
- 自分が自然と考えていたことの正体
- コレは再現可能な戦略なのか
- 「成功戦略」と呼べるようなモノはあるか
- これから先のことは分からないけど
「凡庸なエンジニア」って何?
「凡庸なエンジニア」ねぇ~。そういう人が成功していくためには、ってことなのかな~。何だろうね~。
「凡庸な」エンジニアの成功戦略ロードマップ
ちょっとこの言葉を整理してみようと思います。
- 凡庸 : 優れた点がなく、平凡なこと
- 凡庸なエンジニア : たぶん、「突出した技能は持ってないけど、平均的な仕事はできる、でもそれ以上のものも別にない」ぐらいの感じ?
- 成功 : エンジニア業を通じての「成功」って何だろうね?高収入になること?働きやすい職場環境にいられること?リストラされるような心配のない、長期安定した会社にいられること?
- 戦略 : 「成功」と呼称する何らかの目標を達成するために、どういう方針でやっていくか
- ロードマップ : 戦略を実現するために、いつ、何をどの順番で行っていくか。具体的な行動計画、工程表
それぞれの単語を、自分はこういう風に受け止めて解釈しました。すなわち、
- 得意な分野とかないけど何となくエンジニア業をやってきた人が、
- 無理なく働けて、それなりに収入を得られて、安定した生活を送れることを目標に、
- どんなことを考えてやっていけばいいか
ってことを話せたらいいのかな?
もしこの解釈がズレてたら、以降の話はまるで無駄なので、その時はまたコメントで教えてください。w
正直なところ、「ロードマップ」なんて具体的なモノを示せはしないので、今回は考え方にフォーカスを当てて書いてみます。
自分は「凡庸なエンジニア」だったか?自分の経歴を振り返る
さて、わざわざこのサイトのゲストブックにこのようなコメントをいただいたということは、受け取り方は2パターン考えられる。
- 「Neo さんって凡庸なエンジニアに見えますよね。これといって目立ったモノがなさそうですけど、そんな調子でどうやって仕事続けてきたんですか?」的な意味
- 「Neo さんって非凡なエンジニアに見えます。でも私は凡人なんです、こんな私はどうやって仕事を続けていったらいいですか?」的な意味
僕は凡庸だと思われているのか?!それとも非凡だと思われているのか!?どっちなんだい!! (© なかやまきんに君)
まぁ他人からどっちだと思われててもいいんですが、自分自身、これまでのキャリアや経験はどれだけありふれていたのか、もしくは特殊なケースだったのか、よく分かっていないのです。元来他人への興味が希薄で、他の人を観察したり考えたりしてきたことがなかったので、自分以外のサンプル数が少なすぎてなんとも言えないのです。
ということで、ココからちょっと長くなってしまいますが、僕がどんなことをやってきたのかを改めて振り返りつつ、「コレってみんな大体そうだよね?」とか「コレってもしかしたら珍しいかも?」みたいなことを整理していこうと思います。
長文が面倒臭い人は、「自己評価:僕は『割と普通』」セクションあたりまで飛ばしちゃってください。
- 僕は1991年生まれ。1997年頃から自宅にあったパソコンを触り始め、1999年にはホームページを作り始めていた
- Strict な HTML、Valid な CSS を書くことに熱心で、無駄な
div要素をどれだけ減らしながら、IE 特有のバグを回避してカラムレイアウトを実装できるか、みたいなことを趣味で追求してた - JavaScript はサンプルコードをコピペするだけで、自分ではほぼ書けないままだった。つまり入社までプログラミング経験ナシである
- Strict な HTML、Valid な CSS を書くことに熱心で、無駄な
- 2009年、偏差値50前後の大学に入学。ド文系で、理系の知識はおろか、数学も勉強してこなかった
- 「情報処理」の共通科目を取ったことはあったけど、当時は紙のテキスト上で2進数の計算をやらされたぐらいで何も覚えてない
- 2011年、大学3年の後半くらいから就活スタートだったかな?やりたい仕事なんて全く考えられなかった
- SE 業の他、飲食業界、楽器屋、カメラメーカー、クルマ関係、商社、広告代理店など、30社以上は選考に進んでいたが、結局内定が出たのが SIer の2社だけだった
- 当時は「SIer」という言葉も知らないまま、プログラマ・エンジニアになった
- 2013年、なんとか内定をもらえた独立系 SIer に新卒入社
- 新人社員研修を通じて Java 7 Bronze 資格を取らされたのが、自分にとって初のプログラミング経験となった
- 初めて配属された案件が、他社によって開発・リリース済みのシステム群を弊社が引き継いで運用保守するという現場だった
- ある会議で「ガワだけの HTML デモページくらいなら、僕作れますけど…」と話したことで、新卒ながら要件定義フェーズから参画することになり、画面設計とか DB 設計とかひとしきりやった。10ヶ月くらいかかってリリースにこぎつけた
- 頑張ってリリースした機能に重大な不具合があり、本番障害対応を経験。原因調査とバグ修正に全部で半年近くかかって苦労した
- 新卒時から同じ案件のまま4年目になると、レガシーな開発環境にイライラしてきた。この当時 Node.js が流行ってきていたので、モダンな開発環境で効率良く仕事するフロントエンドエンジニアになりてぇ、と思い立ち、転職活動を始める
- 2017年、会社員4年目の終わりに別の独立系 SIer へと転職
- 転職してからは3ヶ月とか、長くても半年くらいで別の会社さんの案件に異動、みたいなサイクルでの仕事になっていた
- モダンな技術を活用してフロントエンド開発を経験できて良かったのだが、転職して1年もすると技術的な興味が薄れ始めた。コレから先、何かの分野で専門特化していきたい~とか思えなくなっていた
- 2019年には、お客様担当1人と僕1人という極小の案件がスタート。Docker なんて触ったこともなかったのに急に採用が決まって、開発期間3ヶ月でアプリの実装だけではなく Docker イメージの作成、Kubernetes クラスタの作成、CI/CD 基盤の構築からデプロイまで一気に独学でやることになって、やった
- 気が付いたら炎上案件に「助っ人クラウドインフラエンジニア」として参画させられていた。フロントエンドエンジニアになりたかったはずなのに何故!?と思いながらも、初めて触る Terraform と格闘して、DB 起因のパフォーマンス遅延に協力し、前職で経験があったので WebLogic Server の設定をスクリプト化してあげ、SpringBoot でつまづいてる人をサポートしてあげ、非同期通信後の JSON パースがうまくいかない画面の修正方法を教えてあげ、スマホでのレイアウト崩れを発見してしまいその場で直し方を伝えてあげるなどして (後半フロントエンドじゃねえか!) 1年近く不愉快だった
- 2022年の年明けから半年間、休職
- 2021年に離婚して私生活がキツかったこともあるが、この時期に同時並行して「アジャイル・スクラムで開発すれば何でも出来ると思い込んでる1人のメンバーの暴走」に振り回されて案件が会社史上最大級に大炎上。逃げ出す方法が傷病による休職しかなかったので、そうした
- (2019年の途中から) 2024年終盤までフル在宅勤務ができていたので、やることだけこなして、後はパソコンを付けたまま昼寝してサボるような生活をダマシダマシ続けていた。しかし2025年から通勤がスタート…
- 2025年3月から体調を崩し、2026年2月現在も休職中
- 通勤再開となった案件自体は悪くなかったのだが、在宅勤務が長すぎたのだ。僕の体力が通勤に対応できなかった。診断としては「適応障害・鬱病」だが、それとは別に、大学在学中あたりからの運動不足と遺伝的な体質の積み重ねで、肥満・高血圧となって顕在化している
……えーと、こんな感じです。先月 (2026年1月) 35歳になりました。休職期間もありますが、とりあえず2013年の新卒入社時から2026年2月現在まで、13年ほどシステムエンジニアとして給料をもらって生きてきました。
コレから先の未来のことは置いといて、一旦ココまでで書いた過去の経歴を振り返って、僕は「凡庸なエンジニア」なのか「非凡なエンジニア」に入るのか、正確な立ち位置を見直してみます。
自分が特別ではないと思うところ
- 偏差値50の文系大学出身 … 学校教育によって SE として恵まれていた部分はない
- 未経験新卒で入社 … 仕事を通じて実現したいこととかないし、世の中が許してくれるなら働きたくなどない。業界だって色々エントリーしたけど他に内定がもらえなかったので SIer になっただけ
- 一時期はちょっとあったけど、今は別に技術全般への興味がない … 熱意や情熱で仕事をしてきたワケじゃない
現在の年収は平均レンジの中の上くらい。低くはないですが、1,000万級プレイヤーみたいな成功はしていません。
インターネット上の人気・知名度もロクにありません。2026-02-01 の本サイトの PV 数は 326 でした。GitHub の総スター数を調べてみたら 255 でした。全リポジトリでコレだけです。OSS 活動みたいな貢献もしてないです。
前職でレガシーな環境をなんとか改善するまでには至らず転職して逃げ出したし、炎上プロジェクトもどうにも出来ないまま、休職で離脱した。私生活ではバツイチ。
こんな人に成功戦略を尋ねてみて、良い答えが得られる感じはしませんよね。w
自分が稀有だったと思うところ
「非凡 (一般の人より優れている)」という表現だとなんか合わないので、「多くの人と比べたら、ちょっと珍しいケースかもしれない」と思うことをまとめてみます。
- 小学生時代からホームページを作ってたというのは、この2000年前後という当時、どちらかといえば珍しい方だったと思う
- 「あの頃ってこういうのがありましたよねw」なんつって歳上の先輩上司との会話の輪に混じりやすかったのは、アドバンテージのひとつだったと思う
- 構文的に正しく HTML が書けたとか、IE のバージョンごとに存在した固有のバグとその回避方法を知っていた新卒というのは、珍しかったのではないだろうか
- 新卒時点で「Java や C++ が書けます」といった同期はいたけど、「将来 IE のバージョンを上げても、古いバージョン向けのハックが邪魔せずに正しく動き続ける方法」といった、長期的に安全なコードが書けたのは、現場でより重宝してもらえた点だと思う
これらは子供の頃に好きでやっていたことで、親に強制されたワケでもなく、将来の就職を見据えて計画的に学習したことでもありませんでした。たまたま、入社した業界で既存知識が活かせたというだけです。コレばかりは初期条件の違いでしかなく、もし羨ましがられてもどうしようもないというか…。w
続いて新卒入社してからのポイント。これももしかしたら珍しいケースかもしれませんが、狙ってそうなったワケではなく、受動的なことばかりです。
- 新卒で最初に参画した案件が新規開発系の案件ではなく、稼動中の既存システムを運用保守しながら、そこに機能追加する改修案件であったこと
- 最初の案件で要件定義フェーズから参画し、その機能がリリースできた後の本番障害の原因究明・修正から復旧までを流れで経験できたこと
自己評価:僕は「割と普通」
そんなワケで、個人的な趣味が高じて仕事に活かせたこともあるし、最初の案件は「現場全体の動き」や「将来の変更」といったことまで意識する必要があり、早くから培われた視点もあったとは思います。
しかしこれらは意図して能動的に獲得したモノではないですし、結果・エンジニア歴13年目となった現在の自分を見ても、何か突出した専門家ではないと自覚しています。
割と普通で、まぁ凡庸なエンジニアとしてやってきたんじゃないでしょうか。
僕以外のエンジニアはどんな経験をしてきたのだろう?
元来他人に興味が薄いタイプでしたので、当時は何も考えていなかったのですが、身の回りにいた他のエンジニアがどんな人達だったか、振り返ってみようと思います。
コチラも少々長くなってしまいましたので、「色んな人がいました」というだけで良ければ、次のセクションまで飛ばしちゃってください。
- 新卒で最初に携わった案件は僕以外に若手がおらず、全員13年目・15年目とかそんな感じだった。それぞれが PL・PM といった次のステップに進みつつある中で、僕だけが20代だった
- プロパーである弊社メンバーはそんな感じで、BP さんも経験年数10年以上のベテランが多かった
- 数人規模の小さなシステム開発会社が丸ごとパートナーとして参画していることもあり、「その会社の役職でいえば社長さん、だけどプロパーである1・2年目の僕がその人に指示を出してる」なんて瞬間もよくあった
- あるパートナーの社長さんが言ってた言葉で、「枯れた技術を身に着けておくと、長くおカネになります」というのを覚えている。シェルスクリプトとかデータベースとか UML とか、そういった普遍的なスキルは何十年も重宝される、ということだ
- 同じ案件に4年間いて、1年下、2年下の後輩の OJT をする経験もあった
- 1年下の後輩は、野球部出身、留年してるので実年齢は僕と同じ、プログラミングは未経験だった。何でも素直に吸収して飲み込みが早く、要領が良いタイプだった
- 2年下の後輩はやはりプログラミング未経験者。だがこの子にはまぁ~うまく教えられなくて苦労した。今にして思えば僕の要求水準が高すぎたことが全て悪いのだが、当時3年目の僕の中では、入社以来何かを努力したり苦労したりした感覚がなかったので、「なぜ同じ未経験新卒のはずなのに、こんな簡単なことも出来ないんだ?」とモヤモヤしてしまうことが多かった
この頃はまだ、1社目の1つ目の案件しか知らない状態で、「僕より10歳以上年上!さすがベテラン何でもできる!」か「未経験新卒なら僕と同じだね」の2パターンでしか判断できなかったので、僕の他人への評価は極めて粗かったと思います。
転職してからは、色んな案件を転々としたので、もっと様々な立場の人と出会ってきました。当時「スペシャリスト」の肩書きを持っていた先輩上司の方々だと、こんな感じ。
- AWS 特化型のスペシャリスト
- AWS のプロフェッショナルなんたらみたいな高難易度の資格をいくつも持ってて、AWS に関する情報は何を聞いても答えてくれる。AWS の何のサービスを使ってシステムを構築すればいいか、みたいなアドバイザーをしていた
- 一方で、定例での報告はいつも準備不足でしどろもどろ、お客様からちょっと仕様について質問されたりするとその場で答えられず「持ち帰って確認します」と言うのだけど、後日の連絡も忘れる。「ならしたら『ポンコツ』の方が勝っちゃうのでは…?」と思ってしまうような人だったが、この人が資格をたくさん持ってるおかげで弊社は AWS との提携ができていた
- とにかく黙々とコードを書いて解決する人
- お客様が「CI/CD 環境を作りたいなー」などと言うと、数日の内に動くモノを作り上げてしまう。コードの質は汚くてバグもちょくちょく出すのだが、直すのも早いし、何が起きても「お客様が言った要求仕様どおりになるように」直せてしまうので、お客様からすれば重宝していた模様
- 週に1日出向するだけで、その会社さんから僕の2倍以上の単価をもらっていた
- 政治に長けた人
- いわゆる「3大クラウドサービス」より下の、少しマイナーなクラウドサービスなんかをあえて持ってきてアライアンスを組んだりしていた
- どのお客様先にも「そのエンジニアと特別仲の良い人」が必ず1・2人いて、そのお客様が進言してくれることで「どこぞのよく分からないサービス」でも採用が決まっていた
- そんな風に、各社の人間を操って確実に「業績」を数字として伸ばす人がいた
- 「ファミリー」を作っている人
- 技術的なスキルはまるで持ち合わせていないけど、ツーカーで話が通じる仲となった固定の部下をどこに行くにも連れ回している PM がいた
- その人の名前で「◯◯組」と呼ばれていて、なんとなくコネで同じような案件をずっとやっている感じだった
- 15年近く同じ1案件だけに携わっている人
- ほとんどの人が長くても1・2年で別案件に異動するはずなのに、どうやって15年も同じ案件に居続けてるのかは分からなかった
- 生き字引のようにその会社さんの専門家になっているのかというとそうでもなく、ほとんどのことはよく覚えていなかった
- 「その人でなければならない理由」がよく分からなかったが、とにかくその会社さんの案件しかやってなかった
それぞれ、何らかの秀でた技能、少なくとも苦手ではない分野を活用して、生存していた感じですね。なお、こういう人と一緒に仕事をしたいと思うかどうかは別です。
一方、自分が中途入社した後に関わった後輩・部下でいうと、よく見かけたのはこんなタイプでした。
- 作業に詰まっているのに全く質問できない人
- 「5分調べて解決しなかったら聞きに来て、怒ったりとかしないから」「何に困ってるのか説明できなくても、遠慮なく『とにかく困ってます!』と言いに来て」などと色々な助言をしてみたが、分からないことがあると何時間でも一人でフリーズしていた
- 上司や僕が周囲をブラブラして様子を見ても自分からは言葉を発さない。コチラが「進捗どう?」と聞くと初めて「いやー、ちょっとつまづいててー…」などと話し始めるのだが、自分からは絶対に質問できなかった
- 根拠のない推測を混ぜて作業してしまい、指示から大きくズレてしまう人
- 「なんとなくこうかなーと思って…」という感じで深く考えずに間違えてしまう
- 途中で何かおかしいことに気付いて修正しようとするも、それも自分の頭で考えて直そうとするので結局環境がメチャクチャになり、何も動かなくなってから初めて質問しにくる
それから、経歴のところでチラッと書いた「スクラム至上主義」みたいなタイプは1人や2人ではなくもう少しいて、
- 「設計書を書くのは面倒」「テストコード実装は時間の無意味だ」などと言い、「コードが設計書だ」「コードで説明している」と言い張る
- いざコードを読んでみると、関数名はデタラメ、変数名は1文字だったりして、目的も意図も何も読み取れない
- 本人も時間が経つと自分が何を考えていたのか忘れてしまうらしく、「えーっとー、このコードは~、なんでしたっけねぇ~」とか言う
「自分だったら間違ってもそんな振る舞いは、最初から一度たりとてしないけどな…」と思うような判断ミスや非効率な手法を何度も繰り返し、一向に進歩しない人が多くいました。…もしかしたら、それはそれで、その人なりに何か生存戦略のつもりだったのかもしれませんが、真相は分かりません。
自分が自然と考えていたことの正体
こんな人もいたなー、という記憶を掘り起こしたところで、再び僕の話に戻ります。
能力的には「割と普通」な僕で、エンジニアに積極的になりたくてなったワケではない。仕事やお客様に対する責任感も別になければ、向上心も特にありませんでした。そんな中で、一貫して考えていたことは以下の2点です。
- 自分の中に「分からないこと」「うまく説明できないこと」が存在するのが嫌だった
- 「なぜか分からないけど動く」とか「おまじないのコード」みたいなモノが生理的に気持ち悪かったので、それは何なのか、どこに書いてあったのか、そう書いてあるのが本当なのか、といったことをよく調べていた。コレばかりは生まれ持った性格だと思う
- フロントエンドエンジニアに拘らなかったのも、「フロントエンド専業なので、バックエンドのことは分かりません」とか言いたくなかった、というそれだけの理由
- 「理屈なんか知らなくていいやー」とやり過ごせなかったので、分からない時間が長いとストレスは多かった、でもそういう性格だったから仕方ない
- でもそのおかげで、自分が書くドキュメントやコードには常に理由・意図・目的・参照先・出典が示せた (必ず併記していた) ので、上長はレビューする際に「思考過程がトレースしやすい」とか「要件を満たせているかのチェックがしやすくて助かる」といって褒めてもらえた
- とにかく残業したくなかった。早く家に帰りたかった
- バカみたいなことを言っているが、とにかく仕事そのものが嫌いだったので、早く仕事を終えて「帰っていいよ」と言ってもらえるようにすることを一番の目標にしていた
- 自分なりに考えて作業する → どこかで上長の指示からズレているかもしれない → レビューで指摘が増えてやり直しが発生する → 早く帰れない! ← この仕事の仕方はもうしないことにする
- お客様でも上司でも、積極的に捕まえて質問する → 「いつ・あなたが・こう発言・指示しました」と議事録を書いてメールで送りつけ共有する → そうして生み出された「出典元」「参考文献」を忠実にトレースして設計工程を進める → 誰が見ても「そういうことなら間違っていないね」と分かる成果物が出来上がる → 早く帰れる! ← このやり方で仕事しよう、と決めた
実際のところ、僕がいた現場では「設計書は細かく書け」「議事録はメールで送れ」と指示されていて、そういう仕事の仕方をしろと教育されていたワケですが、言われたからそうするようになったというよりは、僕が嫌なことを避けたいがために編み出された選択の結果が、うまく現場指示と合致していたワケです。
- 「あなたがこう言いましたよね?」作戦は、僕が思考・判断していないので、僕の成果物にミスがあっても僕の責任にならない最強の戦術
- 明らかに僕のミスであるモノについては素直に謝っていたし、「次からは再発防止策としてこんなやり方にしようと思います」と提案していた。感情的に怒鳴るような人もいなかったので、「怒られること」自体への恐怖みたいなモノは僕にはなかった
- 会議でチーム全体が間違った・非効率な手段を採択しようとしている。そのまま決定してしまうと自分にも作業分担が回ってきて残業が増えるから避けたい。しかし自分の発言が発端になると「じゃあお前がやれ」となってそれも残業が増えるから避けたい。そんな時は…
- 直球で意見を言うと「お、なんかお前よく分かってそうだな、じゃあお前やってくれ」となってしまうので、「あれ、それって、以前◯◯さんが□□でやってませんでしたっけ?僕、そのとき議事録書いてたからなんとなく記憶にあるんですけど~」などと、遠回しに指摘して誘導する
- 上長が自分で間違いに気付くまで辛抱強く待つと、自然な流れで「じゃあ以前にもやったことがある◯◯さんに、今回も□□の方法で進めてもらおうかな」といった形で丸く収まる
- 自分だけが責任や仕事を負うこともなく、僕が非効率な仕事を分担させられるルートも回避し、僕は残業せずに済む。ついでにチームとしては作業が円滑に進み、全体最適もとれる
責任回避のための「逃げの姿勢」から取られた戦略ですが、結果的に
- よく人の話を聞いている・マジメだ
- 不明点をおろそかにしない・正確な仕事を心がけている
- 自分がやっている仕事をしっかり説明できる人材である
- よく気が付く、周りや先々のことをよく見ている
という風な評価に繋がり、「責任感が強い」ように思われることが多かったと思います。自分ではそんなつもりはないのにね。
上流から下流まで、開発工程と運用保守行程を同時並行的に、1年の間に一気に経験したことも作用して、「その場しのぎを避ける」「後々のことを考える」ことが自然と習慣化できたとは思いますが、それもまた自分自身のためでした。
- ココで拡張性を考慮して手間をかけておかなかったら、あとで仕様変更を依頼された時に余計に大変になりそうだ。そうなると来年残業することになる、じゃあ今ちょっとメンドくさいけどやっておこう
- → 結果的に技術的負債を増やさずに済む
- 新たな要望を出されたが、未知の領域すぎて工数見積できない!うかつな数字を口走ったらその期間内にやらされて苦労しそうだから、絶対に数字は自分の口から言わずに、上司主体で見積もりしてもらい、自分は何が不明瞭かだけを語ろう
- → 「この通信技術を Linux ではなく Windows Server で実装してる事例が見つからなかったので、僕には工数が見えません」とか正直に言うだけで、工数の盛り具合やその責任は上司のモノになって、僕は責められない
「システムを良くしたい」という思いからそのように考えていたワケではありません。自分の仕事が増えず、残業せずに済むための、合理的で効率的な自己防衛の副次的な作用が、「システムちょっと良くなる」ことに繋がっただけです。
だから僕の中では、「頑張っている」とか「努力した」とか「志を高く持っている」とかいうつもりはなく、当たり前の損得勘定なんですね。苦労して工夫したワケではなく、むしろ怠惰だったからこそ目指すことにした合理性・効率・全体最適の手法でした。
コレは再現可能な戦略なのか
「何かを自分の責任として押し付けられたくない」と思った時に、「とにかく沈黙を貫いてやり過ごす」という手段も、もしかしたら存在するのかもしれません。しびれを切らした上司が「出来ないならもういい、仕事はこっちで巻き取るからお前は帰れ」と言ってくれて家に帰れる可能性もあります。
しかし、僕の中では、それは「より良い選択肢」ではありませんでした。家に早く帰るためには、目の前の問題を先延ばしにするよりも、解決してしまった方が早いし再発しないだろうと思ったのです。自分ではやりたくないから「誰かが言ってました」とかなんとか理由を付けて、遠回しに場をコントロールしようとしました。
- ちなみに、うまく他の人にやらせることが出来ずに自分の仕事になってしまった場合は、再鑑者やレビューアを設けて作業記録を付けながら作業し、それを元に「作業手順書」をこしらえて、「この作業、来週以降も定期的にやることになりそうですから、誰でも間違いなく出来るようにマニュアル作っておきました!共有します!(だから二度と俺に任せんじゃねえぞ…?)」と手を打つことで、自分だけに定常作業が任されないようにしました
- 半分恨み辛みからのマニュアル共有でしたが、それすらも「Neo くんが離任する時に既に作業マニュアルが整備されていて助かった」などと評価されました
コレは特別な才能がないとできないことだったのでしょうか?
幼少期にホームページを作った経験がない人には、到底できないことなのでしょうか?
他人には再現できない、非凡な行動だったのでしょうか?
「成功戦略」と呼べるようなモノはあるか
僕のような現状を「凡庸」なエンジニアと表現すると、「特に優れた点がない」→「ありふれている・どれも普通」という、ネガティブで行き詰まったような雰囲気が漂います。
そこで自分としてはこんな現状を、汎用性が高いエンジニアになった、と表現したいなと思います。すなわち、明らかに特出した肩書きは持っていないけど、弱点があるワケではないし、現場で積み重ねてきた経験は確実に有していることを表明したいのです。
僕はホームページを作ってきたのでフロントエンドは特に興味がありましたが、結局、フロントエンドなどの特定領域で専門性を極めることよりも、専門を一点に閉じないことを選びました。全体が分かっていた方が依然として自分の中では気持ちが良く、精神衛生上ストレスが少ないので、長くこの仕事を続けるためには避けられない選択だったと思います。
コレを良く言い換えれば「フロントエンドに軸を持ってはいるが、全体像を常に把握しており、横断的に設計ができる」エンジニアであるかのように振る舞えるワケです。未経験なこと・知りもしないことをウソをついてそのようにアピールしているワケではないので、堂々とそう言えます。配属させられた現場がたまたまそうだっただけですが、そんな現場の状況と、一応真剣に向き合ってきたとは思っています。
このような捉え直しは、立場や経験の異なる人にも出来ることだと思います。つまり、
- 目立った専門がなく、天才的なエピソードもない
- 能動的に決めたことじゃないので、何ができるか・何をやってきたか、うまく説明できない
- 保有スキルを説明しようとすると、広く浅く散らかったようにみえる
- 何もかもただやらされてきただけ、流行や周囲の流れに沿ってきただけ
なんて言ってしまうと、僕だってそうなのでとても凡庸に見えますが、
- 「でもコレだけは嫌だったから回避するようにしてたなぁ」という点が、実は自分が既に持っていた強みだったり
- 「皆はなぜか苦労してたけど、自分はなんともなかった」という事柄は、個人的な好き嫌いは別として「他の人より要領良く出来るアピールポイント」になったり
といったことは、それなりに経験年数を重ねていればきっと見つけられると思います。
自分の場合は、転職活動を決心した時に、職務経歴書を豪華に書く必要に迫られたことで、こういう捉え直しができたかもしれないです。「正直言うとマジ流されてやってきただけで何の思い入れもないんすけど~」と Doda の転職エージェントに相談して、これまでの案件の内容を淡々と書き起こしてみたところ、「好きではなくても Java は出来る、ASP.NET の実務経験が (1週間だけ) あるっていうのもウソじゃないですよね、もう経験言語複数あるじゃないですか!w」「学ぶことが嫌ではない、っていうの、それ十分強みですよ!」とか言われて、へぇーそうなんだ~、全然自分では実感ないけど~、みたいな、そんな感じでした。
僕が出会ってきたエンジニアの大多数は、「一見して明らかな得意領域が見える」ような人材ではなく、「凡庸で、ありふれた」ように見える人達の方が多かったです。好きなモノ、得意なことが明確で、その領域を得意としているスペシャリストも一部いましたが、基本的には会社は「多くの凡庸なエンジニア」によって構成されていました。それはつまり、凡庸であることはエンジニアの弱点ではなく、多くの人にとっての現実解なのだと思います。スペシャリストだけがエンジニアのなるべき姿ではないと思いますし、そうなれなかったら失敗、というワケではないでしょう。
日々のことだけでいっぱいいっぱいで、技術に興味もないし、成長とかする気ない、SNS でなんか語ってるプロがいるけど全然響かん、でもなんか置いてかれてるような気はする、このままで良いんだろうか、漠然と不安だ、でも何をしたらいいかもよく分からない。
…僕だってそうです。凡庸な我々は大体こんな感じなんじゃないでしょうか。
そんな時って、物事が「点」でしか捉えられなくなっていると思います。まぁそれもしゃーないですよね。知らない会社に出向して、別に好きでもなんでもない業務のシステム開発を任されて、「とりあえず言われたとおりに作って」「炎上してる?人海戦術だ!」「リリースできたなら解散!」というように、意味も文脈も分からないまま、終わらせることだけを求められる仕事が、よくある SIer の仕事の現場だったりしますから、意味なんか分かりっこありません。
でも、毎日に流されながらもちょっとずつ時間を見つけて、自分がやらされきた無意味な「点」に見えていた情報をイイカンジに繋ぎ合わせて、「文脈」と「意味」を見出してみるとどうでしょう。
- それは何のためのサービスであるか
- 誰が使っているか。どういう業界のクセがあるか
- システムが出来た経緯、背景は何だったか
- 今回のシステム開発が、ビジネスやユーザ体験にどう影響するか
- その技術スタックが選定された理由は何か
- (どうせ実際はお偉いさんの「鶴の一声」か、コンサルから薦められたかが関の山で、大層な理由もないんだろうけど)
- なんか古臭いレガシーな構成だとしたら : 過去の実績・既存のメンバーのスキルを鑑みて、限られたリソース内で引き続き保守できる安定した構成を選んだ
- 珍しくモダンな構成だとしたら : これから長く陳腐化しないことを目指した挑戦かもしれない
こんなところを考えて、そのプロダクトの文脈を捉え直せたら、自分がやらされている作業の「意味」も自ずと見えてきます。あなた自身は何も考えてこなかったのかもしれませんが、きっと上層部や会社間ではもっとカッコイイ目標や事業計画をデッチ上げていて、それが現場に下りてきているでしょうから、そういうビジネス的な視点を盛り込んであげると、自分が何をやってきたかという文脈や意味を、それらしく説明できるようになると思います。
- 例えば、フロントエンド : 「画面を作るモノ」ではなく、「エンドユーザが直接触れるインターフェースであるため、仕様の曖昧さや設計漏れを炙り出す役割を担う」と言ってみるとか
- Docker や Kubernetes の採用 : 「流行ってたらしいから」ではなく、「新規学習コストはかかるものの、それまでの環境差分に起因する運用負荷を軽減するためのトレードオフ」なんて表現してみるとか
- クラウド移行 : 「なんかそういう案件が回ってきたから」ではなく、「固定資産扱いとなり初期投資が必要なオンプレと比べて、事業規模に合わせて必要なだけのリソースを使用できるためコストの弾力性が向上するから取り入れた」と言ってみるとか
「Wiki にそう書いてあった」「どこぞのコンサルがそう言ってた」それでいいです。その言葉を持ってきて、自分が口に出して説明しやすい表現・言い回しに噛み砕いて置いておけばいいのです。歯が浮くような企業理念みたいな言葉を心から信じ込む必要などありません。内心は「早く帰れればそれでいい」のままでいいのです。それでも、意味が欠如したまま、ただただ何かをやらされているという虚無感に苛まれるよりは、「コレが私の携わったリフト・アンド・シフト案件でお客様に提供した価値です」とか言える方が、だいぶ印象違いませんか?
これから先のことは分からないけど
僕は昨年2025年から休職していて、会社の規定的には今年2026年の終盤までで休職期間が終わってしまいます。なので今年の年末には「復職」or「無職」or「転職」のいずれかの進路に進んでいることになります。コレまでのキャリアプラン面接で、一度たりとも「3年後・5年後の働く自分像」なんて思いつかなかった人間ですから、約10ヶ月後に自分がどうなっているかすら何の想像も付きません。
当然のように、コレをご覧いただいている他の皆さんの未来も分かりません。
例によって、昨年2025年からの AI の進歩は目覚ましく、何かが物凄いスピードで出来るようになっています。「速く作れる」ことだけが強みだった人、「尖った言語や技術を書けること」だけが強みだった人は、その強みを代替する装置が出てきてしまった可能性は否めません。実際にタイプしてコーディングをするという工程は、もうちょっとしたら「コーディングするのに手使って打つの?赤ん坊のおもちゃみたい (元ネタ:Back To The Future 2 の未来パートより)」なんて言われる時代がすぐ来るかもしれません。
これまで自分がやってきたことと「AI」を単に点で結びつけてしまうと、どうしても「AI が完全上位互換みたいですね」となりそうですが、僕には僕の文脈がありますので、そこに対していかように「先進技術が持つ文脈」「未来に繋がる意味」を組み込んでいくかで、凡庸なエンジニアである僕が、凡庸なりに生きる道が見えてくるのではないかと思っています。