「こんなに開発タスクをこなして、深夜までリファクタも進めたのに、なぜか評価が上がらない」 「自分より技術力で劣っているように見える同僚が、なぜか上のグレードに昇格していく」 現場でエンジニアをしていると、一度はこうした不満や疑問を感じたことがあるのではないでしょうか。 結論から言うと、どれだけ手を動かして汗をかいていても、「自分自身の満足の範囲」で完結している努力は、組織における評価には結びつきま…
プロダクトの規模が拡大したり、マルチプロダクト展開や共通基盤化が進んだりすると、必ずぶつかるのが「他部署との連携」という分厚い壁です。 開発チーム内のタスク調整であれば、コードやチケットを見れば阿吽の呼吸で進むこともあります。しかし、セールス部門をはじめとするビジネスサイドの上役（責任者・役員クラス）、さらには独自のロードマップを持つ「他プロダクト部門」との折衝となると、難易度は何段階も跳ね上がり…
「アーキテクチャの最終決定は、マネージャーである自分が判断しなければならない」 「休日に障害アラートが鳴ったら、責任者である自分が全部巻き取って対応すべきだ」 「チームの責任者なのだから、難易度の高いトラブルや重要局面はすべて自分がフロントに立って処理すべきだ」 こうした強烈な「〜すべきだ」「〜しなければならない」という【べき論】を背負い、深夜や休日のインシデント対応に一人で駆けつけ、Slackで…
「マネージャーの指示だから」という盾を用意して若手の背中を押す手法は、初期の立ち上がりにおいては極めて有効です。しかし、いつまでもこの「言い訳」というシールドを使い続けていると、若手はいつまでも責任の本当の重さを知らず、組織の中核を担う自律したビジネスパーソンへと脱皮することができません。 マネジメントの真のゴールは、部下に「言い訳」を提供し続けることではなく、最終的にその「言い訳」という名の補助…
「言い訳をするな」 多くのビジネス現場で美徳とされるこの言葉ですが、マネジメントの観点から見ると、実はこれほど若手の行動を縛り付ける呪縛はありません。むしろ、優秀なマネージャーほど、部下が動くための「質の高い言い訳」を先回りして用意しているものなんです。 PIVOTでよい動画が配信されていました。「若者が辞めない理由を分析」という動画です。 この動画で触れられていた「若手に行動の言い訳を作ってあげ…