※この記事は個人の体験と知見に基づいています。
医療的な助言ではないこと、また成果を保証するものではありません。
免責事項の全文はこちらをご参照ください。
「5人までは回せていたのに、10人になった途端、何もかもうまくいかなくなった……」
もしあなたが今、そんな焦りを感じているなら、それはあなたの能力不足ではありません。単に「リーダーとしての戦い方」を切り替えるタイミングに来ているだけです。
エンジニアとして20数年、多くの現場を見てきた私自身、何度もこの「人数の壁」にぶつかってきました。
かつての私は、10人のメンバー全員の動きを把握しようとし、全員の作業状況をチェックし、誰よりも遅くまで残業して「自分が一番働いているリーダー」であろうと必死でした。
しかし、その結果待っていたのは、チームの成長ではなく、メンバーの疲弊と自分自身のパンク、そして避けることのできたはずの「炎上」でした。
10名規模のプロジェクトを安定して回すために必要なのは、新しい管理ツールでも、気合の入った残業でもありません。それは、リーダーがこれまで大事にしてきた「いくつかの執着」を、勇気を持って手放すことです。
今回は、私が修羅場をくぐり抜けて学んだ、リーダーが真っ先に「捨てるべきもの」についてお話しします。
１．導入：なぜ「5名の壁」より「10名の壁」は高いのか
エンジニアとして現場を支えてきた私たちが、初めて「10名規模」のチームを任されたとき、必ずぶつかる壁があります。
それは、「自分の目が届かない領域」が圧倒的に増えることです。 5名までなら、全員のコードをチェックし、全員の進捗を完璧に把握することも根性で可能でした。しかし、10名を超えると、一人の人間が処理できる情報量（認知限界）を超えてしまいます。
ここで多くのリーダーが、かつての私と同じように「もっと頑張らねば」と自分を追い込み、結果としてプロジェクトを炎上させてしまいます。炎上を防ぐために必要なのは、「頑張り」ではなく「捨てる勇気」です。
２．手放すべきもの①：「100点満点の進捗把握」
多くの真面目なリーダーは、プロジェクトのすべてを把握していないと不安になります。かつての私もそうでした。しかし、10名規模のプロジェクトで「100点満点の把握」を目指すのは、リーダーにとってもチームにとっても「毒」でしかありません。
現場リーダーを「うんざり」させていた過去
ある開発案件でのことです。私は進捗が気になりすぎて、案件担当のリーダーが別にいるにもかかわらず、毎日細かく「あれはどうなった？」「この仕様の考慮は漏れていないか？」と直接踏み込んで確認し続けていました。
私の頭の中には「自分が一番仕様を理解しているし、漏れがあったら大変だ」という、一種の正義感がありました。しかし、これは大きな間違いでした。
結果として起きたのは、私の貴重な「リーダーとしての時間」の喪失です。
そして何より、現場のリーダーやメンバーを「うんざり」させてしまったのです。
「どうせ後で細かく聞かれるなら、自分で考えて動くより指示を待ったほうが楽だ」――そんな空気がチームに漂い始め、メンバーの主体性を無意識に奪っていました。
「資料作成」という名の自己満足を捨てる
また、報告資料についても同じです。 以前の私は、すべての進捗を自分一人で把握し、自分一人の手で資料に起こしていました。周りのメンバーに一部の更新を任せればいいものを、「自分でやったほうが正確だし、把握もできる」と抱え込んでいたのです。
毎週の報告会議の前は、資料作成だけで深夜まで残業。これでは、トラブルの予兆を察知するための「脳の余白」など残るはずもありません。
【現場のリアル】「任せる」と「放任」の狭間で
ここで一つ、皆さんに共有したい苦い教訓があります。「任せることが大切だ」と痛感した一方で、「任せた結果、大失敗した」経験も私は持っています。
かつて協力会社のリーダーを信頼し、進捗管理を完全に委ねたことがありました。
しかし、そのリーダーがうまく機能せず、気づいたときには取り返しのつかない遅延が発生していました。結局、私と同僚が現場に介入し、仕様確認から進捗管理まで、大半の火消し作業を自分たちで引き取る羽目になったのです。
このとき痛感したのは、「任せる」ことと「丸投げ（放任）」は全く別物であるということです。
相手のスキルや状況を見極めずに「任せたからよろしく」と背を向けるのは、リーダーとしての責任放棄でしかありません。だからこそ、100点満点の進捗を自分で「把握」しようとする執着は捨てつつも、チームが脱輪していないかを遠くから見守る「観察」の目は残しておく必要があるのです。
現在のスタイル：信じて「任せる」、そして「観察する」
今の私は、以下のバランスで動いています。
- 進捗管理や資料作成は、担当リーダーや詳しいメンバーに一任する。
- 浮いた時間を使って、メンバーの表情や進捗の「停滞」を静かに観察する。
最初は「自分の知らないところで何かが起きているかもしれない」という恐怖がありました。
しかし、執着を手放して「観察」に回ることで、以前よりも早く異変に気づけるようになりました。リーダーが「知らないこと」があってもいい。それは、チームが自律的に動くための「隙間」を作っている証拠なのです。
３．手放すべきもの②：「自分がやったほうが早い」という誘惑
仕様を一番理解しており、技術的な引き出しも多い。そんなリーダーにとって、最も甘く、かつ危険な誘惑が「自分がやったほうが早い」という思考です。
「自分で書き直したい」という葛藤
特にコーディングや設計のレビューをしているとき、この誘惑はピークに達します。 自分が得意とする技術領域であれば、メンバーのアウトプットに対して「観点が抜けている」「そもそも書き方がいまいちだ」と感じることは少なくありません。「これなら、自分でゼロから書いた方が圧倒的に早いし、質も高い」――そう喉まで出かかるのを、私は何度も飲み込んできました。
過去には、一度丁寧に教えたはずのコーディング規約や設計の勘所が、次のアウトプットに全く反映されていなかったこともありました。その時の「残念な気持ち」は、言葉では言い表せません。「結局、自分でやったほうが確実なのか？」という諦めに似た感情が芽生えたことも事実です。
「諦め」から始まる、本当の意味での「任せる」
しかし、ここでリーダーがキーボードを奪ってしまったら、チームの成長はそこで止まります。それどころか、リーダーが実作業に没頭している間、チーム全体を俯瞰する「司令塔」としての機能が失われ、別の場所で起きている火種に気づけなくなるのです。
今の私は、たとえ「自分でやったほうが早い」と思っても、あえてメンバーに任せ、彼らに責任を持ってもらうようにしています。 それは、彼らの成長を願う気持ち半分、そして「自分がプレイヤーに戻ってはいけない」というリーダーとしての危機感半分です。
任せるための「見極め」という非情な仕事
ただし、ここで一つ付け加えなければならない厳しい現実があります。 それは、「誰にでも、何でも任せていいわけではない」ということです。
先日もあるメンバーに対して、「この人には、今の役割は任せられない」という結論に達したことがありました。優先順位の付け方、スケジュール調整の甘さ……。何度チャンスを与え、フィードバックを繰り返しても改善が見られない場合、無理に任せ続けることはプロジェクト全体の「炎上」に直結します。
リーダーが手放すべきなのは「自分がやったほうが早い」という執着ですが、「メンバーの能力を見極め、適切な役割に配置する責任」だけは、絶対に手放してはいけません。
「任せる」とは、単なる放置ではなく、相手の現在地をシビアに見極めた上での、リーダーとしての戦略的な決断なのです。
４．手放すべきもの③：「隙のない完璧なリーダー像」
リーダーは常に正しく、強く、決断を間違えてはならない。 そんな「完璧なリーダー像」に縛られていた時期が私にもありました。しかし、リーダーが隙を見せないチームでは、皮肉なことに「致命的なミス」が隠蔽されやすくなります。
20年前の「こっそり修正」が教えてくれたこと
私はかつて、リリース直前の重大なミスをこっそり修正し、タイムスタンプでバレて猛烈に怒られたことがあります。当時の私は、自分の評価が下がることを恐れ、失敗を「なかったこと」にしようとしていました。
もし今、私のチームのメンバーが同じことをしたらどうなるでしょうか。 リーダーである私が「完璧主義」を振りかざし、失敗を許さない空気を醸し出していたら、メンバーは間違いなく過去の私と同じように「隠す」という選択肢を選んでしまうでしょう。
失敗を開示することで、チームに「余白」を作る
今の私は、自分の失敗をさらけ出すことに全く抵抗がありません。それどころか、あえて自分の「過去の恥ずかしい失敗」をメンバーに話すようにしています。
リーダーが「私も昔、こんな大失敗をして怒られたんだ」「今でも迷うことがある」と開示することで、チームに「失敗しても、正直に言えばリカバーできる」という安心感が生まれます。
この安心感こそが、報告・連絡・相談のスピードを劇的に上げ、結果としてプロジェクトの炎上を未然に防ぐ最大の防波堤になるのです。
リーダーの仕事は「答えを出すこと」だけではない
10名規模のプロジェクトでは、リーダー一人の知恵など限界があります。 「私は完璧ではない。だから、みんなの視点を貸してほしい」 そう言える勇気を持つことで、10人の知恵が結集し始めます。リーダーが「隙」を作ることは、メンバーが入り込み、活躍するための「余白」を作ることでもあるのです。
５．まとめ：手放した先に残る「真の管理」
「手放す」ことは、責任を放棄することではありません。 メンバーを信じ、システムとしてのチームを信じることで、リーダーは「次に何が起こるか」を予測する余裕を手に入れることができます。
あなたが今日、何か一つ「執筆」や「判断」をメンバーに委ね、自分の失敗を一つ笑い話として共有することができれば、そのプロジェクトは炎上という結末を回避する大きな一歩を踏み出したことになります。
