※本記事は、ChatGPT/Gemini/perplexityによる意訳+翻訳、情報ソースを活用し、レイアウト調整したものです。
※元記事を見て、内容がズレていないか査読するようにしています。
※感想は、オリジナルです。
原文
Ten Behaviors of Bad Programmers - DEV Community
意訳+要約
悪いプログラマーの10の行動
プログラミングの世界で成功を収めるためには、実は技術力以上に「姿勢」や「考え方」が決定的に重要です。
これから紹介する行動は、“悪意”からではなく、“未成熟な習慣”から発生することがあり、誰でも陥り得ます。
ダメなプログラマーが犯す核となる行動パターン
感情的な判断をしてしまう：
「自分のプログラムに問題なんてありえない」「◯◯はクソだ」「こっちばかり変わる要求どうにかならない？」など。感情が判断を曖昧にし、キャリアにも悪影響を及ぼします。他人（やツール）への疑念を先に持つこと：
「絶対に自分のコードが正しい」「ライブラリにバグがあるはずだ」とすぐ疑ってしまう。まずは自分の理解・調査が先です。実装に飛びつき、問題の本質を無視すること：
要件や目的をきちんと理解せずに実装を始めると、後からバグや仕様ずれが発生します。設計やビジネス背景をまず捉えておくべき。自分の知らないコードをそのまま使うこと：
他人のコードを「コピペ／貼り付け」して理解せず使うと、環境が違うだけで予期せぬ動きに。自分で制御できるコードを書きたい。がむしゃらに働くことを美徳とすること：
効率化や仕組み作りをおろそかにして、ただ時間を使うだけでは成長が止まります。 “賢く”働くことが重要です。待ち姿勢・言い訳・愚痴が多いこと：
開発環境が悪い、要件が変わる、時間が足りない…と文句を並べるだけでは進みません。自分が変える姿勢を持ちたい。職場の内輪もめ／政治を引き起こすこと：
コードで勝てないと責任転嫁・陰口・他者排除…。これでは健全なチーム文化も育ちません。話すことが多く、実力が伴わないこと：
自分の知識を見せつけたり、他人を批判することで空回り。言葉よりも行動・アウトプットを重視したい。固執・こだわりすぎること：
明らかに他に良い手法があるのに「これが自分のやり方だ」と曲げない。柔軟性を欠くと壁にぶつかりやすい。“かっこいい”コードを追い求めすぎること：
他の人が理解しづらい、読みづらい「しゃれた」コード。プロダクトとして大切なのは「読める・保守できる」コードです。
検証
システム開発において、上記の行動が起こりがちな理由
心理的防衛本能と認知バイアス
- 感情的思考や他人・ツールへの疑念は、人間の「自己防衛反応」から生じます。
経験不足による視野の狭さ
- 実装に飛びつく・本質理解を軽視する・コピペ利用などは、開発経験が浅いほど起こりやすい傾向にあります。
- プログラムを書く行為自体が「成果」に見えるため、設計・背景理解を軽んじがちです。
- 過去にうまくいったやり方への過信もあり、柔軟に考える力が育っていない段階では“とりあえず動かす”発想が先行します。
組織文化・評価制度の影響
- がむしゃら労働の美徳化や待ち姿勢／愚痴の蔓延、内輪もめなどは、組織風土が根本原因です。
- 成果より「努力量」や「残業時間」で評価される環境では、効率化より“頑張る姿勢”が優先される。
- リーダー層が「責任逃れ」「他部署批判」などの態度を取っていると、部下にもそれが伝染します。
- チーム間に明確な責任分担や共通ゴールがなければ、政治的闘争（派閥・責任転嫁）が起きやすくなります。
教育・レビュー文化の欠如
- 話すだけで実力が伴わない、かっこいいコードの過剰追求といった行為は、適切なフィードバック機会の欠如が原因です。
- コードレビューや設計レビューが形骸化していると、自己流の「美学」や誤った成功体験が修正されないまま蓄積します。
- 教育・指導者が「なぜそれが良くないのか」を具体的に説明しない環境では、若手が正しい判断基準を学べません。
認知負荷と疲労
- 開発現場はタスク量・変更要求・バグ対応などで常に高いストレス下にあります。
- 人間は疲労すると合理的判断が難しくなり、短絡的思考・感情反応・安易な行動に流れがちです。
- 「本来考えるべきことを考えられなくなる」という状態が、感情的行動や浅い実装判断につながります。
成功・失敗体験の偏り
- 成功経験が少ないと「改善」より「自己防衛」に走る傾向になり、逆に一部の成功に固執する人は「自分のやり方」を変えられなくなります。
- 双方に共通するのは、学びを振り返る習慣の欠如と定期的なフィードバックの不足です。
まとめ
これらの問題は個人の性格というよりも、
- フィードバック文化が弱い
- チーム内で心理的安全が確立していない
- 評価軸が「能力・成果」よりも「態度・見た目」に偏っている
といった「開発組織全体の構造的要因」に起因することが多いです。 したがって、技術教育だけでなくメンタル面の理解・組織構造の改善も必要になります。
チーム内で心理的安全を確保する方法
互いの存在を尊重し感謝を示す
メンバーそれぞれが貢献や意見を認め合うことで、「肯定されている」という安心感が全体に広がり、自己開示しやすくなります。助け合い・相談しやすい関係性の構築
分からないことや悩みを自由に相談できる風土は、失敗や疑問を共有しても否定や批判されないという安全な場で生まれます。1on1の定期面談やメンター制度も有効です。挑戦・失敗を歓迎する姿勢
新しいアイデアや失敗に対して否定するのではなく「挑戦・新奇歓迎」を明言し、失敗を学びとするスタンスを明確にすると、萎縮せずに意見を出しやすくなります。自己開示のリレーやワークショップ
「今までで一番うれしかったこと」などパーソナルなテーマで短時間話すリレー形式のワークショップを行うと、表面的な関係性から一歩踏み込んだ信頼関係が生まれます。
心理的安全性はただの雰囲気づくりではなく、個々が安心して意見を言える土壌を意味し、これがなければ本質的なコミュニケーションもイノベーションも難しいため、現代の成果を出すチームや組織にとって不可欠な要素です。
“心理的安全性を掲げれば安全になる”わけではなく、度が過ぎると“何も指摘できないぬるま湯”になる危険もある。
どのようにバランスをとるかの視点も必要になる。
参考リンク
心理的安全性の高い組織のメリットを解説！ぬるま湯組織にしないためには？
心理的安全性の作り方とは？高める4つの因子と実践方法、事例を紹介
心理的安全性を組織に根付かせる 対話型ワークショップ7選｜対話からはじまる職場改革 │ ビジネスゲーム研究所
心理的安全性はどう作る？高める方法や効果、良いチーム作りのコツなどを徹底解説
感想＋雑記
身に覚えのあることが。。。
いっときの感情にながされてしまうことは、結構あった。
ただ、冷静になったときに嫌気が指すので、自省する習慣自体はあった。
自分もメンバーという立場から、リーダー・上長という存在になって、どうあるべきかは考えることがある。
そうなると、フィードバックの文化、能力成果を見ての評価あたりが重要になってくると思う。
調べると心理的安全性ってのに行き着いたが、どうにも胡散臭く感じるんだよね。。。
たぶん、推進している人が表面的な理解で言動が乖離しており、期待と現実のギャップを何度も経験しているからな気がする。
自分も、実現しようとしても、なかなかできないと思う。限度を超えると爆発すると思う。
自分の会社が自由に発言できる風土かと言われると、“自由に発言できる”とは言い難い雰囲気を感じる。
誰かが発言を引き出すような問いかけや質問を投げないと、議論が深まらない気がするんだよね。
大雑把な問いかけは、意見言いづらくなるし、調べた結果を鵜呑みにして実現するのもダメな気がする。
ここらへんは、自分でも明確な回答がない。
見つけるしかないと思われるが、優れた問いかけやユーモアある質問をする能力が必要なのではないかと感じてる。
結局、聴衆の関心を引いて、物事を考えさせるように誘導させる人が、重要なんだと思う。
ただ、評価されない気がするので、頑張り損になる可能性も高そうだが。
とりあえず、それができるように目指して、各種打ち合わせに参加して考えを深めたい。他者の良い質問の技術を学び、自分自身の問いかけ力向上に活かしたい。
