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?

【文献検証】「先輩のコード、バグってるけど言えない…」若手PLを苦しめる沈黙の正体と、エゴレス・プログラミングの処方箋

1
Posted at

はじめに:押されてしまう「LGTM(Looks Good To Me)」

「このロジック、エッジケースで確実に例外を吐くな…」
コードレビュー中、明らかな不具合(バグ)の種を見つけてしまったあなた。しかし、そのプルリクエスト(PR)の作成者は、自分より30歳も年上で、システムの隅々まで知り尽くしている「神のようなシニアエンジニア」でした。(まじでどの会社でもこんな人いますよね)
「もしかして、私の勘違いでは…?」
「ここで指摘して先輩のプライドを傷つけたら、今後のプロジェクトが回らなくなるんじゃないか…?」
心臓の鼓動が早くなる中、数分間カーソルを彷徨わせた後、あなたは結局そっと「LGTM」ボタンを押してしまいました。
若手プロジェクトリーダー(PL)やテックリードが必ず直面する、この「格上のエンジニアに指摘ができない」という地獄の構造。
これは単なる個人の「勇気」の問題ではありません。ソフトウェア工学とマネジメントの古典的理論を紐解くと、そこには明確な「組織的・心理的なエラー」が存在します。
今日は先人たちの知恵を借りて、この沈黙の正体を暴き、若手PLが生き残るための処方箋を提示します。

沈黙の正体1:最大化された【対人リスク】と失われた心理的安全性

「チームにおいて、他のメンバーが自分が発言することを恥じたり、拒絶したり、罰をあたえるようなことをしないという確信」
(エイミー・エドモンソン『恐れのない組織──「心理的安全性」が学習・革新・成長をもたらす』より)

Googleの調査(プロジェクト・アリストテレス)でも有名になった「心理的安全性」。
シニアエンジニアに指摘ができない若手PLは、まさにこの安全性が欠如した状態にあります。
エラーを見つけた時、あなたの頭をよぎるのはシステムへの影響ではなく「無知だと思われる恐怖」「プロジェクトの進行を邪魔すると思われる恐怖」という、強烈な【対人リスク】です。
「先輩を怒らせたらどうしよう」という恐怖が、システムの品質保証という本来の目的を完全に凌駕してしまっているのです。

沈黙の正体2:「私=コード」という呪縛【エゴレス・プログラミングの欠如】

「自分の書いたコードを私物化せず、コードを見る側も見せる側も『自分の方が優れている』といった自尊心を捨て、純粋により良いものを作る」
(ジェラルド・M・ワインバーグ『プログラミングの心理学—または、ハイテクノロジーの人間学』より)

1971年にワインバーグが提唱した「エゴレス(無我の)・プログラミング」。
この概念が示唆するのは、多くのエンジニアが**「自分が書いたコードに自分の人格(エゴ)を投影してしまう」という致命的なバグ**を持っている事実です。
指摘しづらいシニアエンジニアは、無意識のうちに「コードへの指摘=自分への攻撃(人格否定)」として受け取ってしまうオーラを出しています。だから若手は「先輩自身を攻撃している」ように感じてしまい、口をつぐむのです。(コードは化身ともとれる)
ワインバーグの十戒にある「人ではなくコードを批評せよ – コーダーには優しく、コードには厳しく」。これが失われている状態です。

若手PLとシニアが実践すべき「仕組み化」

では、この構造的エラーに若手PLはどう立ち向かえば良いのでしょうか。勇気を振り絞るのではなく、「仕組みとルール」でエゴを排除する3つのアクションを提唱します。
1. 主語を「私」から「客観的ルール(We Message)」に変える
「(私が思うに)〇〇さんのコードはおかしいです」ではなく、機械やチームの決まりを主語にします。
・「〇〇先輩、ここの実装ですが、チームのコーディング規約だとこうなっているので、合わせてもらえますでしょうか?」
機械やルールを間に挟むことで、対立構造を「あなた vs 私」から「私たち vs 課題」へと変換します。(これもなかなか難しいことかもですが、自分を守る盾になります!)
2. 疑問形(ティーチング依頼)で指摘を包む
「ここ、バグってます」と断定するのではなく、教えを請う姿勢をとります。
・「先輩、私の理解不足かもしれないのですが、この変数にNullが渡ってきた時の挙動について、意図を教えていただけませんか?
エゴを刺激せず、事実確認から入ることで、相手に「あ、しまった」と気づかせる余白を与えます。(京風にいきましょう)
3. シニアエンジニアへ:あなたの「隙」がチームを救う
もしこれを読んでいるあなたがシニアエンジニアの立場なら、思い出してください。あなたの書くコードは当然素晴らしい。しかし、あなたの最も重要な仕事は「若手がノータイムでマージリクエストに『直してください』とコメントできる空気」を作ることです。
わざと小さなミスを残して、「〇〇君、ここバグ見つけてくれて助かったよ!サンキュー!」と称賛する。
その「意図的な隙」とエゴレスな姿勢こそが、チームの心理的安全性を高め、結果としてシステム全体を堅牢にする最強のデバッグツールなのです。

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
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?