🤛

エンジニアを一瞬で破壊する秘孔

2023/09/04に公開

いきなり読者を限定させるタイトルですいません。。

秘孔(経絡秘孔)とは、北斗の拳に登場する衝撃を与えることで、内部から肉体を破壊するツボのこと。作中でも描かれるが、逆に人体を強化させる秘孔もある。

長らくエンジニアを続けていると、自分自身やまわりのエンジニアを見ていて、同じ場面でも伝え方ひとつで相手を傷つけたり、逆に感謝されたりもある。

それはエンジニアのツボ(秘孔)の場所や突き方によって、もたらす結果だと思う。
それらの秘孔を知っておくことで、メンバー同士で傷つけたり、新しくリーダーを任される人の負担を少しでも減らせられればと思い執筆してみた。

ただし、全体的にリソースはない(あっても知らない)ので、筆者の個人的見解だと思ってほしい。

Slack編

朝イチの指令

とくにリーダーになりたてで張り切って朝早く来て、エンジニアがその日スムーズな仕事ができるように、「xxしてください」「xxxしないでください」と書き立てると、エンジニアのモチベーションは破壊される。

命令というのは、誰でも不快に感じるもの。
ただでさえ不快な朝、眠い目をこすりながらすする朝のコーヒーを、泥水のように感じさせかねない。

「グッ」と我慢して、デイリースクラム(朝会)に持ち込むとよい。

短文の百裂拳

相手を説得したいときに、細切れ投稿でスレッドを埋める。

Slackなら、相手の入力欄に永遠のごとく「入力中」が表示され続け、反論しようにも、とうの昔にそのフレーズはスレッドに埋もれてしまっている。

これを受けたエンジニアは溜まったもんではない。全身から血を吹き出して内部から破壊される。
そう、もはや暴力である。

開発業務編

マイクロマネジメント

エンジニアの顔を見るたびに進捗を確認するのはやめたほうがよい。リーダーが、「チームで成果を出すこと」 に躍起になり、作業を急き立てるようなマイクロマネジメントは、相手の尊厳を破壊する。

カンバンを見れば進捗はわかるし、未着手でも急ぎでなければ、DSやバックログリファインメントで残ったタスクを確認すればいい。

ちゃぶだい返し

設計やクラス名・メソッド名を考えたりと、思想が衝突するときはよくあること。リーダーもエンジニアの成長を願ってつい「考えてみてください」と、誘う言葉を使いがちだが、その後フィードバックのない指示は、相手をただ不安に落とすだけになる。

結局、コードレビューまで進んだり、設計レビューの段階でちゃぶ台がえしされると、相手の努力を破壊する。

マイルストーンをこまめにきって、フィードバックを繰り返すほうが良い。逆に、細かい指示出しはマイクロマネジメントと同様、考える芽をつむので人は育たない

コードレビュー編

IMO, MUST などのプレフィックスをつけない

会社内のヒエラルキーや技術格差のある関係でコードレビューが行われると、プレフィックスをつけないと、圧倒的な強制力を感じてしまう。

レビューイに判断できるスキルがあれば問題ないが、経験値の少ない新人エンジニアは、打ち返された球の数に自信を破壊される。

https://note.com/su_k/n/nf23ab5c6dba2

伝えたいことがより伝わりやすくなるのでおすすめです。

チームのレビューのルールが決まっている場合は合わせるべきだが、伝える側から受ける側の解釈を手助けする意味で、プレフィクスはあったほうが良い。

そして、もちろん「レビューを甘くしろ」という言っているわけではない。
あくまで、伝え方を工夫する。

マージ後に指摘コメントする

人は完璧ではないので、レビューで見落としたり approve 後に時間をおいて「そういば・・」と観点に気づく場合はある。

しかし、それが何度も何度も繰り返されると、レビューが通ったときの達成感は破壊されていく。

やり直してほしいことは、純粋に新しいチケットを切って、対応してもらう。そのほうが、エンジニアは新しい気持ちでタスクと向き合える。

ミーティング編

「補足としては〜」と、つい口をはさむ

説明ベタなエンジニアが一通りの説明を終えるまでに、うずうずして被せるように「補足としては〜」と言いたくなるが、我慢したほうが良い。

被せられた側は、自分の話しは重要じゃないと否定され、自己肯定感を破壊される。

もしかしたら、最後に言おうとしているかもしれないし、プロダクトオーナーやチームから質問がきて答えることになるかもしれない。

「補足」は、最後の最後を待って伝えるほうが、明確だし、発表者からも感謝される。

参加しないミーティングへのダメ出し

普段参加しないミーティングの議事録を読んで、ネクストアクションが物足りなくても、ダメ出しするのはやめたほうがいい。

出席者に意思決定権がないと印象づけられ、チームの心理的安全性は破壊されてしまう。

気になるなら素直にミーティングに参加するか、主導してネクストアクションの再検討を行うべきである。

日常会話編

「逆に」「じゃなくて」「だったら」の否定から言葉をはじめる

これは自分の意見を全否定された気分になり、自尊心を破壊される。
言っている側は、ほとんど口癖なので意識して「いいですね」「知らなかったです」と、肯定的な言葉を放つように心がける。

そのうえで「こういうやり方もありますよ」と、別の案を提示するほうが遥かに相手を動かしやすい。

「成長してるね」が口癖

褒める行為は大切ですが、「成長している」のような表現は、意図的に相手を低く見ている印象を与えかねない。「若い=プライドが低い」と思うのは軽率で、褒めていても相手のプライドを破壊している場合がある。

「作業が完璧だね」とか、「爆速じゃん」など、よりナチュラルに行動を評価するほうが受け手は喜ばれる。

最後に

大なり小なり、人と人が働けばイヤなこともされるし、言ってしまうこともある。

それが同じメンバー同士なら大きな問題にならないが、ヒエラルキーがあると様々なハレーションを生み出しかねない。ただ、どんなエンジニアもいつ何時、リーダーを任されたり、逆にエンジニアではない方が開発チームを率いることもある。

そのときに、エンジニアの秘孔を知っておくことで、1人でも多くの人を破壊から守ることができれば幸いである。

では。

Collections

Discussion