LoginSignup
1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@sk8er_boi_shin(shin)

コードは嘘をつかない――開発者の心理状態がわかる実装パターン

Posted at

目次

  1. はじめに
  2. 相談しづらい環境が生む実装ミス
  3. 精神的負荷が高いと起こる場当たり的な実装
  4. コードレビューで気をつけるべきサイン
  5. リーダー・マネージャーの視点から
  6. まとめ

1. はじめに

エンジニアが書くコードには、そのときの心理状態やチームの雰囲気が色濃く反映される――私はそう考えています。
本来、短時間の相談で解決できるはずの問題が 「相談しづらい環境」 によって不要なコードのコピーにつながることがあります。また、精神的な負荷が高まると 「根本的な解決」 より 「その場しのぎの対応」 を優先してしまい、技術的負債が積み上がる原因にもなります

こうした 「実装の癖」 や 「ミスのパターン」 から、エンジニアの心理状態やチームの課題を読み解くことができるのではないか？
私自身、現場でエンジニアとして働く中で、「このコードはなぜこうなったのか？」と考え続けてきました。そして、相談しやすさや精神的な余裕とコードの書き方には 無視できない相関関係 があることを感じています。

本記事では、私が実際に現場で感じ取ってきた 「コードから読み取れる心理的・組織的なサイン」 について、具体的なコード例とともに紹介していきます。

  • 相談しづらい環境がもたらす実装ミス
    → なぜメソッドをコピーするのか？ ちょっとした相談がなぜ行われないのか？
  • 精神的負荷が高いと起こる場当たり的な実装
    → 精神的に追い詰められたとき、エンジニアはどんなコードを書いてしまうのか？
  • コードレビューで気をつけるべきサイン
    → 相談しづらい雰囲気や負荷の高さをコードから察知するには？
  • リーダー・マネージャーの視点から
    → チームの心理的安全性を高めるために何ができるのか？

🔍 本記事の独自性

本記事では、「コードレビュー時のチェックポイント」や「バグの回避方法」ではなく、エンジニアの心理状態がコードにどう影響するのか？」 という視点から解説します。
このような観点で整理された記事は、あまり多くないのではないでしょうか。

私はこれまで、リーダーやメンバーとしてさまざまなプロジェクトを経験してきました。
その中で 「コードを読むことで、開発者の置かれた状況やチームの課題が見えてくる」 ということを何度も実感しています。

本記事が、コードを見るときの 「新しい視点」 を提供できれば嬉しいです。
また、「自分の現場ではこうだった！」という意見があれば、ぜひ共有していただければと思います。

2. 相談しづらい環境が生む実装ミス

ソフトウェア開発において、「ちょっとした相談をすればすぐに解決する問題」 なのに、
開発者が萎縮してしまっており
結果として 無駄なコードの増加や技術的負債の発生 につながることがあります。

私は現場でこのような状況に遭遇したことが何度もあります。
特に、相談が行われなかった結果として 「コードをコピーしてしまう」 という形で表れることがあります。

本章では、相談しづらい環境が引き起こす典型的な実装ミス をコード例とともに紹介します。

ケース1: 相談すれば1分で済むのにメソッドをコピーする

❌ 問題のコード

既存の共通メソッド CreateParams() を使えば済む場面で、
一部のパラメータを変更する必要があるため 相談せずに新しいメソッドを作成 してしまう。

// 共通のパラメータ設定メソッド
public static Dictionary<string, string> CreateParams()
{
    return new Dictionary<string, string>
    {
        { "key1", "value1" },
        { "key2", "value2" }
    };
}

// ある機能で一部パラメータを変更したかったが、相談せずにコピーして新メソッドを作成
public static Dictionary<string, string> CreateParamsForSpecialCase()
{
    return new Dictionary<string, string>
    {
        { "key1", "value1" },
        { "key2", "specialValue" } // 一部のケースで異なる値
    };
}

このように、コードをコピーしてしまう原因は技術的な問題ではなく、チームの環境にある ことが多いです。

例えば：

  • 「このメソッドの引数を増やしてもいいですか？」と聞けば1分で済むのに、相談せずコピーする
  • 「相談しにくい雰囲気」があると、こうした小さな判断ミスが積み重なり、技術的負債につながる

✅ 適切な解決策

「相談しやすい環境を作る」ことが、無駄なコードを減らす鍵 になります。

例えば、以下のようなアプローチが考えられます。

方法1: メソッドの引数を増やす 

// 相談した結果、フラグを追加して共通メソッドを拡張
public static Dictionary<string, string> CreateParams(bool isSpecialCase = false)
{
    return new Dictionary<string, string>
    {
        { "key1", "value1" },
        { "key2", isSpecialCase ? "specialValue" : "value2" }
    };
}

これなら、新しいメソッドを作成せずに、既存のコードを活かすことができます。

方法2: パラメータを外部から渡せるようにする 

// 相談した結果、動的にパラメータを受け取るように変更
public static Dictionary<string, string> CreateParams(string key2Value = "value2")
{
    return new Dictionary<string, string>
    {
        { "key1", "value1" },
        { "key2", key2Value }
    };
}

このように、小さな変更を共通化するだけでコードの重複を防げる 場面は多くあります。

コードをコピーする背景にある心理的要因

このような 「コピーして新しく作る」 という行為の背後には、以下のような心理的要因があると考えています。

1. 過去に相談したときに否定された経験がある

  • 相談した際に 「そんなこともわからないの？」 と否定的な反応をされた経験があると、次から相談を避けるようになる。
  • その結果、できるだけ既存のコードに影響を与えず、自分で何とかしようとする ため、コードのコピーが増えてしまう。

2. チーム内の雰囲気が相談しづらい

  • リモートワーク や 席が離れている などの物理的要因で、ちょっとした相談がしにくい。
  • 忙しそうにしている人が多い ため、「このくらいなら自分で判断しよう」 となり、結果としてコピーする。
  • 「ちょっと聞いてみよう」と思ったときに、声をかけにくい雰囲気があると、自然と相談が減る。

3. 実装者が相談すること自体を面倒に感じる

  • 「聞けばすぐ解決する」とわかっていても、仕様や背景を説明するのが面倒 だと感じる。
  • その結果、短期的に楽な方法（＝既存のコードをコピーして新しいメソッドを作る） を選んでしまう。
  • ただし、この方法は後々のメンテナンス性を大きく下げるため、長期的には負担が増える。

このような要因が積み重なると、「相談すれば解決するはずのことが相談されないまま放置」 され、
気づいたときには 無駄なコードが増えてしまっている という事態に陥ります。

相談しやすい環境を作るには？

このような問題を防ぐために、リーダーやマネージャーは相談しやすい環境を意識して作ることが大切 です。
以下のような対策を実施すると、チームの雰囲気が変わるかもしれません。

1. 相談を歓迎する文化を作る

  • 「相談しやすいチーム」を意識して運営する。
  • 些細な質問でもポジティブに受け止め、「よく相談してくれた！」と伝える。
  • 相談したことが マイナス評価につながる と思わせないことが重要。

2. コードレビューで「なぜこの実装にしたのか？」を丁寧に聞く

  • 相談しづらい環境では、コードの変更理由が不明確になりやすい。
  • 例えば、コードレビューで次のように聞くことで、「本当は相談したかったけどできなかった」 背景が見えてくることがある。
    • 「このメソッドを新しく作った理由を聞いてもいいですか？」
    • 「既存の CreateParams() を拡張する案は考えましたか？」

3. 物理的・心理的な「距離」を縮める

  • チャットやミーティングで「気軽に話しかけていい」という雰囲気を作る。
  • 「忙しそうだから話しかけづらい」という印象を与えないように意識する。
  • 例えば、次のような取り組みが考えられる：
    • 「定例の雑談タイム」を設ける（業務外のことも気軽に話せる場を作る）
    • 「コードレビューで必ず議論する時間を取る」（一方的な指摘ではなく、話し合う場にする）

本記事の要点を3行で

  1. 「ちょっと聞けば済む」ことでも、相談しづらいとメソッドがコピーされる
  2. 「相談のハードル」を下げることで、技術的負債の発生を抑えられる
  3. コードレビューは「なぜこの実装になったのか？」を尋ねる場として活用する

3. 精神的負荷が高いと起こる場当たり的な実装

ソフトウェア開発では、「精神的余裕の有無」がコードの品質に大きく影響する と私は考えています。
特に、リリース前の追い込みやトラブル対応などで精神的負荷が高くなると、冷静な判断ができなくなることがあり、
その結果として 「その場しのぎの実装」「根本原因を解決しない修正」 が増えてしまいます。

この章では、精神的負荷が高い状況で生じる典型的な実装パターンを紹介し、なぜそうなるのか？ を考察します。

ケース1: その場しのぎのエラーハンドリング

❌ 問題のコード

リリース直前に発生したバグを、急いで対応しようとした結果、場当たり的な修正を行う ケース。

public static void ValidateInput(string input)
{
    string validationMessage = null; // 初期値をnullにしている

    if (!string.IsNullOrEmpty(input))
    {
        validationMessage = input;
    }

    // nullチェックを忘れたため、NullReferenceExceptionが発生
    if (validationMessage.Equals("Error"))
    {
        Console.WriteLine("Validation failed.");
    }
}

このコードの問題点：

  • validationMessage を null で初期化しているため、input が null の場合に .Equals() を呼び出すと NullReferenceException が発生する。
  • 本来なら変数の初期値を適切に設定することで防げるバグ なのに、時間がないために修正が後回しにされがち。

✅ 場当たり的な対応（根本解決にならない）

とりあえず エラーを回避するためだけの対応 をしてしまう。

public static void ValidateInput(string input)
{
    string validationMessage = null;

    if (!string.IsNullOrEmpty(input))
    {
        validationMessage = input;
    }

    // 場当たり的な対策（nullチェックを後付け）
    if (validationMessage != null && validationMessage.Equals("Error"))
    {
        Console.WriteLine("Validation failed.");
    }
}
  • これは一見すると エラーを防げているように見えるが、根本的な解決にはなっていない。
  • もし validationMessage の初期値が null ではなく適切に設定されていれば、そもそもnullチェックは不要だった。

✅ 適切な解決策（根本解決）

根本的に問題を解決するためには、初期値の扱いを見直すとよい。

public static void ValidateInput(string input)
{
    string validationMessage = input ?? string.Empty; // 初期値をnullではなく空文字に

    if (validationMessage.Equals("Error"))
    {
        Console.WriteLine("Validation failed.");
    }
}

この修正によって：

  • そもそも null が発生しない設計にすることで、場当たり的な対応を不要にする。
  • 将来的なメンテナンス性が向上する（新しいバグが発生しにくくなる）。

なぜ精神的負荷が高いと場当たり的な対応になるのか？

私は、精神的負荷が高い状況では、エンジニアは「根本解決」よりも「とりあえず動かすこと」を優先しがち だと考えています。
特に、次のような状況では、場当たり的な修正が頻発しやすいです。

1. リリース直前の追い込み

  • 「もう時間がない」「今すぐ修正しなければならない」というプレッシャーから、短時間で修正できる方法を選んでしまう。
  • その結果、「根本的に見直すのは時間がかかるから、ひとまずエラーを出さないようにする」といった対応になりがち。
  • 例えば、null になる変数の根本的な原因を調査するのではなく、とりあえず null チェックを追加して回避する などの対応が増える。

2. 連続したバグ修正による疲労

  • 何度もバグ修正を繰り返していると、判断力が鈍り、「とにかく目の前のエラーを解消する」ことだけに集中してしまう。
  • 冷静に考えれば適切な修正方法があるはずなのに、精神的な余裕がなくなると「一番手間がかからない方法」で対応しがち。

3. 自責の念による視野の狭まり

  • 「自分の実装した機能でバグが出た」「自分で直さなければならない」 というプレッシャーがあると、他の人に相談する余裕がなくなる。
  • 本来ならチームで議論すれば最適な解決策が見つかるはずなのに、1人で抱え込んでしまう。
  • 自分で原因を見つけて修正しなければならない という思い込みから、「とにかくエラーを消す」ことが最優先になる。

精神的負荷を下げるための対策

このような 「場当たり的な実装を防ぐためには、エンジニアの精神的負荷を下げることが重要」 です。
具体的には、次のような取り組みが考えられます。

1. 「今すぐ動かす」より「後々のことも考える」文化を作る

  • チームのルールとして、「とりあえず動けばいい」ではなく、「後で修正しやすい実装を優先する」 という考え方を浸透させる。
  • 短期的な修正よりも、長期的なメンテナンス性を重視する 文化を作る。
  • 例えば、リリース直前の修正は、必ずペアレビューを行うようにする ことで、場当たり的な修正を防ぐ。

2. 「1人で抱え込ませない」

  • バグ修正を担当した人が疲弊しないように、タスクの分担を見直す。
  • リリース前のバグ修正は1人が集中して担当するのではなく、チーム全体で分担することで精神的負荷を軽減する。
  • 「一人で何とかしなければならない」というプレッシャーを減らすことが重要。

3. コードレビュー時に「なぜこの修正をしたのか？」を聞く

  • 精神的負荷が高い状況では、適切な修正方法を考える余裕がなくなりやすい。
  • コードレビューで「なぜこの修正を選んだのか？」を聞くことで、より良い解決策がないかを議論できる。
  • 例えば、レビュー時に 「この修正の意図をもう少し詳しく教えてもらえますか？」 と聞くことで、場当たり的な修正になっていないか確認できる。

本記事の要点を3行で

  1. 精神的負荷が高いと、短絡的なバグ修正やその場しのぎの対応が増える
  2. タスクの分散と適切な休息が、長期的なコード品質の向上につながる
  3. リリース前こそ、チームでコードを見直す仕組みを作ることが重要

4. コードレビューで気をつけるべきサイン

コードレビューは、バグを見つけるだけの場ではなく、「開発者の心理状態やチームの課題を察知する場」 でもあります。
コードの書き方に次のような 「サイン」 が現れていないか、意識してチェックしてみてください。

🛑 要注意なサイン

サイン 背景にある可能性のある課題 レビュー時に確認したい観点
似たようなメソッドが乱立している 相談しづらい・共通化への抵抗 既存のメソッドを修正する案は考慮したか
バグ修正が局所的で、根本解決がされていない 精神的な負荷が高く、場当たり的な対応 この修正で根本原因は解決されているか？
大きな機能を実装した人が、バグ修正もすべて担当している 自責の念・タスクの偏り 他の人に修正を依頼する余裕はあるか？

本記事の要点を3行で

  1. コードレビューでは「実装の意図」を確認し、相談不足のサインを見逃さない
  2. 似たようなメソッドの乱立や局所的なバグ修正は、チームの課題の兆候
  3. 「なぜこの実装を選んだのか？」という質問が、開発者の思考を整理する助けになる

5. リーダー・マネージャーの視点から

エンジニアのコードには、単なるロジックの良し悪しだけでなく、その時の心理状態やチームの課題が反映される ことが多いです。
特に、「相談しづらい環境」「精神的負荷の高さ」 は、コードの質や開発の進め方に大きな影響を与えます。

リーダー・マネージャーの立場としては、コードをレビューするだけでなく、「なぜこの実装になったのか？」という背景まで考えること が重要になります。
ここでは、「リーダー・マネージャーの視点で何を意識すべきか？」 を整理していきます。

1. 相談しやすい環境を作る

「相談しづらいチーム」 は、実装の質の低下や技術的負債の増大につながることが多いです。
リーダー・マネージャーの立場からは、以下のような取り組みを意識すると良いでしょう。

✅ 相談を歓迎する姿勢を明示する

  • どんな小さなことでも 「相談してくれてありがとう」 と伝える
  • 「聞く側」の態度が相談のしやすさを決める ため、忙しくても余裕を持った態度を示す

✅ コミュニケーションの場を増やす

  • 定例ミーティングとは別に、時間的に余裕があれば雑談ベースの「オープンな相談会」 を設けることも検討する
  • コードレビューを一方的な指摘の場にせず、「相談の延長」として使う

✅ 「なぜこの実装を選んだのか？」をフラットに聞く

  • 相談しづらい環境では、開発者が独断で進めてしまうことがある
  • コードレビュー時に 「この実装方法にした理由を聞かせてもらえますか？」 とフラットに尋ねるだけでも、相談のハードルが下がる

2. 「精神的負荷の高さ」に気づく

精神的負荷が高いと、エンジニアは 「場当たり的な実装」「その場しのぎの修正」 に走りがちです。
リーダー・マネージャーは、「負荷がかかっているサイン」 を見逃さないことが重要です。

✅ コードの傾向から精神的負荷を察知する

コードの傾向 背景にある可能性のある課題 リーダーが取るべきアクション
バグ修正がその場しのぎになっている 精神的に追い詰められ、短絡的な修正をしている 「この修正で根本原因は解決していますか？」と確認する
大きな機能を実装した人が、その後のバグ修正もすべて担当している 責任感が強すぎて1人で抱え込んでいる 「このタスク、他の人と分担できそうですか？」と声をかける
似たようなメソッドが乱立している 相談せずに個別対応してしまっている 「既存のメソッドを修正する案は考えましたか？」と確認する

3. 相談しやすく、負荷を分散するチームづくり

エンジニアが安心して開発に取り組める環境を作るには、「相談しやすさ」と「負荷の分散」を両立させること が重要です。

✅ 「忙しそうだから相談できない」という状況を作らない

  • チームリーダーやシニアメンバーが忙しく見えると、若手は相談をためらう
  • 意識的に「今は相談してOK」というタイミングを設ける

✅ バグ修正を1人に集中させない

  • 大きな機能を開発した人が、その後のバグ修正をすべて担当するのは危険
  • 「担当者 = バグ修正担当者」にしない 仕組みを作る（ペアで対応する、レビュー時に分担を決める など）

✅ 「レビューで対話を生む」習慣をつける

  • コードレビューを「指摘の場」ではなく「議論の場」にする
    「こうした方がいいかも？」→「その理由は？」→「なるほど、じゃあこうするのは？」 という対話を促す
  • 「なぜこのコードを書いたのか？」を質問するだけでも、相談のハードルが下がる

⚠️ もしこの問題を放置すると…

チームの「相談しづらさ」や「精神的負荷の高さ」を放置すると、以下のような問題が発生するリスクがあります。

放置した場合の影響 具体的なリスク
コードの品質が低下する 相談しないまま場当たり的な修正が増え、技術的負債が蓄積する
開発速度が落ちる バグ修正やリファクタリングに追われ、新規開発に割くリソースが減る
メンバーが疲弊する 精神的負荷が高まり、離職率の増加やパフォーマンス低下につながる
チームの信頼関係が損なわれる 相談しづらい環境が続くと、助け合いの文化が消失する

このように、相談しやすい環境を作ることは、単に開発効率を上げるだけでなく、長期的にチームの安定性を向上させる ことにつながります。

本記事の要点を3行で

  1. 「相談しづらい環境」は、コードの品質低下や開発速度の遅れにつながる
  2. 「忙しそうだから話しかけられない」雰囲気を作らないことが重要
  3. コードレビューを「指摘の場」ではなく「対話の場」として活用する

6. まとめ

エンジニアのコードには、単なるロジックの良し悪しだけでなく、その時の心理状態やチームの環境が反映される ことが多いと私は考えています。
本記事では、「相談しづらい環境」「精神的負荷の高さ」がコードにどう表れるのか という視点から、開発現場で見られる実装のパターンを整理しました。

🔍 本記事のポイント

テーマ 発生しやすい実装 背景にある要因
相談しづらい環境 似たようなメソッドが乱立する 相談のハードルが高い・既存のコードを変更するのが怖い
精神的負荷が高い バグ修正がその場しのぎになる 時間がない・リリース前のプレッシャー・連続した修正で疲弊
コードレビューのサイン 一人でバグ修正を抱え込む 自責の念・周囲に頼る余裕がない
リーダーの視点 相談が少なく、メソッドが個別対応になりがち 「忙しそうだから相談しづらい」環境になっている

💡 相談しやすい環境を作ることが、コードの質を向上させる

  • 「相談しやすい環境」 を意識することで、無駄なコードや技術的負債を防げる
  • 「リリース前の精神的負荷」 を下げるために、タスク分担やレビューの仕組みを見直す
  • 「コードレビューは対話の場」 として活用し、開発者が冷静に実装を見直せる環境を作る

📝 最後に

コードレビューをするとき、単に 「このコードは問題ないか？」 だけでなく、
「なぜこのコードが書かれたのか？」 まで考えることで、チームの課題が見えてくることがあります。

私は、コードには 「その時の開発者の心理状態やチームの文化が表れる」 と感じています。
もし「こういうケースもあった！」という経験があれば、ぜひ共有していただければと思います。

1
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?