この記事の途中に、以下の記事の引用を含んでいます。
How do I delegate when I can do it faster myself?
はじめに：「自分でやった方が早い」に悩むすべてのリーダーへ
エンジニアからマネージャーへ。
キャリアの変化のなかで、多くの人がぶち当たる壁があります。
「自分が一番速く、正確にこなせるはず。だからつい自分でやってしまう――」
そんなジレンマに悩むリーダーの葛藤と学びを率直に綴ったのが、今回ご紹介する
Valeria 氏のブログ記事です。
単なる「委譲しましょう」指南ではなく、体験を通じた成長の軌跡と、どうやって技術的な仕事から人や組織を成果に導くリーダーシップへと自分自身をアップデートしたのか。
現場で悩むエンジニアリーダーやマネージャーにとって、多くの示唆が詰まっています。
痛烈な気づき：「速さ」がむしろチームの成長を阻害する!?
Valeria 氏は次のように嘆いています。
“Here’s the paradox: the fact that I could do it faster was precisely the problem. Every time I jumped in to save time, I was robbing them of the chance to develop their own speed, their own judgement, their own mastery. I was optimizing for today’s velocity at the cost of tomorrow’s capability.”
（自分が速くできることこそが問題だった。私が毎回割って入って時間を“節約”するたび、チームは自分のスピード・判断力・熟達を磨く機会を奪われていた。私は今日の速度に最適化して、明日の能力を犠牲にしていた。）
これはリーダーとしての根本的なパラドックスです。
一時的な効率を追い求めるあまり、「育成」「自走」「任せる」という本質を忘れてしまいがちです。
なぜ「速さ」が時に害になるのか。
真の組織力とは何か。
以下、各ポイントを深堀りしましょう。
「全部自分で」は“成長阻害”になる——その本質を解く
1. チームの自律性を奪わないために
自分でやれば速く終わる仕事――確かに短期的には合理的です。
しかし、メンバーから「任せてほしい」と声が上がったとき、それは「自分がリーダーの足かせになっている」という警告です。
特に「技術のスペシャリスト」と「組織のリーダー」は求められる役割が大きく違う。
メンバーの視点を持つ難しさ
リーダー自身の思い込みで「自分がやらないと回らない」「自分のほうが正確」と考えがちですが、実は現場では
「自分たちの裁量を信じてほしい」
「もっと挑戦や判断の機会をほしい」
と考えているメンバーが増えているものです。
2. 短期の「効率」か、長期の「組織力」か
一般的に「委譲は効率を下げる」と誤解されがちです。
ですが、記事が示す通り「今日の効率のために、明日の組織能力を犠牲にしている」ことは、往々にしてあります。
たとえば新人エンジニアの教育を、全部リーダーが「俺がやった方が早い」という理由で代行すれば、メンバーは永遠に育ちません。
結果、リーダー自身が“ボトルネック”になり、イノベーションも持続性も生まれない組織になるのです。
3. 「できる人ほど抱えるアイデンティティの危機」
Valeria 氏が痛感したのは、技術者としてのアイデンティティとの決別です。
“My whole identity was wrapped around being a great engineer. …Who am I now that I’m not coding anymore? Am I still valuable?”
（自分の全てのアイデンティティが、「優れたエンジニア」であることに結びついていた。…もうコードを書かなくなった今、私はまだ価値があるのか？）
この不安。有能なエンジニアほど、マネジメント移行時にここで迷います。
生産性や価値を「自分の手で直接作ること」と短絡的に紐付けてしまいがちですが、それを抜け出すことが、成熟したリーダーへの必須課題なのです。
痛み・葛藤を糧にして「リーダーシップ」を学ぶ道のり
「WTFボタン」になってませんか？
Valeria 氏は自分を“WTFボタン”――困ったときに何でも解決してくれるお助けマン――と表現します。
“One of the developers called me a “WTF Button” – whenever they were stuck, confused or frustrated, they would come to me and … I’d solve it for them.”
（開発者の一人に『WTFボタン』と呼ばれた。彼らが行き詰まった際、私の所に来て、私がすぐに解決する、という役割だった。）
一見「頼られている」ようで、これは“依存”の温床になりかねません。
リーダーの役割は「全問題を肩代わりして解決」ではなく、“メンバー自身が自律的に考え行動できる環境づくり”にあるはずです。
「Fixer」から「ガイド」への変貌
記事中では、「The Phoenix Project」や「The Culture Code」といった名著との出会いをきっかけに、Valeria 氏が「Fixer（なんでも自分で直す人）」から「Guide（成長の伴走者）」へ変化を遂げていく様子が描かれます。
このプロセスは日本の現場でも同様に重要。
例えばメンターが「ただ正解を教えるだけ」では圧倒的に成長が遅れます。
“本人に考えさせ、意思決定を促す”――これが現代的リーダーの真価です。
ステークホルダー・マネジメントの複雑さ
マネジメントの難しさは「チームの内外」にあります。
エンジニアにとっては「技術者同士」だけでなく、顧客・プロダクトマネージャ・デザイナー・セキュリティ担当 etc. …多くの利害関係者との連携が不可欠です。
記事中の
“How was I supposed to manage their expectations? … Clearly at this point coding or technical problem solving was the least of my worries. I spent so much time preparing slides and attending meetings that I barely had time to think about anything else.”
（この無数のステークホルダーと、どうやって向き合えばいいのか？ 技術的な課題どころではなくなり、会議・資料作成に追われていた。）
という記述は、現代のテック企業では“あるある”の現実です。
組織論、目標設定、合意形成…テクノロジースキルだけでは乗り越えられない壁
マネジメントでは「明確な方向性」「分かりやすい目標」「成果に対する説明責任」が求められます。
記事の後半で紹介されているのはSLI・SLOといったデータドリブン指標の導入ですが、それすらも
「なぜこの目標を設定するのか」
「このメトリクスは誰のためのものか」
といった“ビジョン”なしには意味がありません。
批評：「できる人」が陥りやすいワナと、その乗り越え方
物語の筋書きは普遍的ですが、いくつか現代組織への応用・気づきを補足します。
＜1＞「仕組み化」と「人の成長」のバランスを取るには
Valeria氏が最終的に到達した「ポジション委譲」や「ゴールキーパー役の設置」は、いわば“ミドルマネジメントの育成”です。
1人の力に依存する階層構造のままでは、規模拡大にも対応できません。
組織設計のベストプラクティスである「チームトポロジー」や「エンジニアの自律型チーム作り」など、現代的な知見にもつながります。
たとえば日本企業でも、組織拡大・リモートワーク化が進む中で
「目標・責任範囲の明文化」
「ステークホルダーとの“見える化”」
がますます大切になっています。
＜2＞「KPI至上主義」を超えた“文化”の醸成
記事ではスコアやKPI（業績指標）重視の落とし穴にも注意を促しています。
“Without the culture to keep team aligned on the right values, KPIs can lead to disastrous outcomes. …People are complex and multi-dimensional, and reducing them to a set of numbers is compelling, but dehumanising.”
（文化なくしてKPIだけを追うと、壊滅的な事態を招く。…人は複雑・多面的であり、数字だけですべてを測れると思うのは危険で非人間的。）
これはまさに現場の実感でしょう。
“数字で評価しやすい成果”のみ意識すると、創造性や挑戦、他者配慮のインセンティブはどうしても下がりがちです。
OKRや1on1といった文化的な取り組みが世界的に注目されている理由も、まさにここにあります。
＜3＞“会議や資料作成も「新たなエンジニアリング」”
この記事の結びは、とても印象的です。
“Meetings and slides are your new coding sessions. Just as you used to craft elegant solutions in code, you’re now crafting clarity and alignment through communication. The syntax is different, but the goal is the same: turn ambiguity into actionable structure.”
（会議やスライドは新たなコーディングセッション。かつてコードでエレガントな解決を生み出していたように、今はコミュニケーションで明確さと整合性を生み出している。文法は違えど、曖昧さを“実行可能な構造”に変換するという目的は同じ。）
「コミュニケーション」「合意形成」「課題“可視化”」も、れっきとした組織エンジニアリングの一部に他なりません。
古い“管理職＝現場離れた人”像に囚われず、現代的なリーダー像を築く羅針盤として、この視点は有効です。
まとめ：あなたが委譲すれば、未来の“最速”が生まれる
本記事を通じて得られる最大の学びは、
「“自分でやった方が早い”は、単なる自己満足かも知れない」
「自分が一番速いのは、むしろ組織の未来を狭めてしまうことにもなり得る」
という現実です。
リーダー自身が“Fixer”から“Guide”へ。
「やらない勇気」「信じて任せる度量」「自分の手を離れた成長が一番の成果」と捉え方を転換することが、チームにも個人にも長期的な価値をもたらします。
では、どうすればいいのか。
まずは、自分自身の“技術者アイデンティティ”と向き合い、「リーダーの最大成果は“人を伸ばすこと”」と肚を決めることがスタートです。
自分だけが速いチームか。
自分以上の“速さ”を生み出すチームか――
その分岐点は、今日の「委譲への一歩」から始まります。
categories:[society]
コメント