技術者なら誰しも、「自分のスキルを活かしたい」「新しい技術を試したい」という欲求を持っています。それ自体は健全な向上心ですし、成長の原動力にもなります。
ただし、その技術選択や実装が**「本当に必要だから」ではなく「自分がやりたいから」**になった瞬間、プロジェクトは途端に自己満足の温床になります。本人は達成感で満たされますが、利用者やチームからすれば「別にそれ求めてないんだけど…」ということも少なくありません。
この記事では、そんな“自己満足技術力”と“本物の技術力”の境界線を整理し、エンジニアとして一歩引いて自分を見直すための視点を気ままに書いていきたいと思います。
目次
1. 自己満足に陥るエンジニアの典型パターン
エンジニアは往々にして、自分の「技術的こだわり」に酔いやすい生き物です。最新フレームワークを試しては「これが最適解」と言い切り、業務要件そっちのけで設計を凝りすぎる。コードの美しさを追い求めるあまり、納期や他メンバーの理解度を置き去りにする。
典型的なのは以下のようなパターンです。
- 「俺、このライブラリ知ってるんだぜ」と言わんばかりの謎アピール
- 実際の利用者が困っていない箇所を“勝手に”高性能化
- 趣味でやるべき実験的実装を本番コードに投入
- 他人が読めないレベルまで難解化したコードに満足する
こういう行動は、自分の中では達成感がありますが、プロジェクト全体から見れば「ただの自己満足」です。
2. 「自己満足技術力」と「本物の技術力」の違い
一見、自己満足に走っている人も技術的には優秀かもしれません。しかし、それと「本物の技術力」は別物です。
自己満足技術力
- 評価基準が自分の中にしかない
- 再利用性やメンテナンス性より“カッコよさ”を優先
- 問題解決より技術披露が目的化している
本物の技術力
- 利用者・チーム・ビジネスの観点から判断できる
- 誰が見ても理解しやすく、変更に強い設計を選べる
- 技術はあくまで目的達成のための手段だと理解している
要は「技術を使いこなす人」ではなく「技術を選びこなす人」が本物の技術者です。
3. “自己満足”から抜け出すための行動指針
抜け出す方法は意外とシンプルです。が、実行できる人は多くありません。
- 目的を明文化する
何のためにその技術を使うのかを一文で説明できなければ、ほぼ自己満足です。 - 第三者レビューを受ける
「カッコいいでしょ？」ではなく「これで十分だよね？」という視点でレビューを依頼する。 - 利用者の声を最優先にする
技術的に完璧でも、ユーザーが困っていなければ優先度は低い。 - “捨てる勇気”を持つ
苦労して書いたコードでも、不要なら潔く捨てる。
4. 技術は目的ではなく手段
技術はあくまで課題解決のための手段です。新しいフレームワークやアルゴリズムに夢中になること自体は悪くありません。ただ、それが**「解決すべき課題」よりも優先される瞬間**が来たら、危険信号です。
例えば、ビジネス上は既存技術で十分なのに、「せっかくだから最新技術でやってみよう」と言い出す。これが繰り返されると、プロジェクトはすぐに迷走します。冷静な技術者は「使えるから使う」のではなく、「必要だから選ぶ」判断ができます。
5. まとめ
- 自己満足技術力は、往々にしてプロジェクトを遅らせる
- 本物の技術力は、目的・利用者・チームを見据えて技術を選ぶ
- “カッコいい”より“役に立つ”を優先する姿勢が重要
技術力は磨くべきですが、それを見せびらかす場は本番コードではありません。
自己満足から抜け出し、本当に価値を生む技術者になるには、まず「自分の技術選択を疑う」ところから始まります。