「丸投げ上司にはならない」と誓った私が、最初のリーダー業務でチームを崩壊させた話

いずくです。今日は、SIerにおける若手PLの仕事の悩みや失敗談を書いていこうと思います。

1. プレイヤーとしての自負と「反面教師」への誓い

SEとして現場に入り、経験を重ねるにつれて、自分の手を動かしてこなせるタスクは確実に増えていきました。

問い合わせの原因の切り分け、システムの設計、テストケースの設計、Fit＆Gap分析、ドメイン知識もあり、大体のことは仮説を立てて検証ができます。正解を見つけて形にするスピードには自信がつき、誰かに質問しないと進まないような場面は激減しました。「意思決定の時だけ上司と会話する」というプレイスタイルが確立し、それは自分の理想とする働き方でもありました。こういう働き方ができるようになると、在宅勤務も自由にできますし　笑

同時に、私はある種の「反面教師」への嫌悪感を抱えていました。それは、適当なチェックリストだけを渡し、「これ、期日までにやっといて」と丸投げする上司やマネージャーの存在です。

私はいわゆる一次受け（プライムベンダー）にいますが、一次受けがそういう態度を取るから、二次請け以降の現場は「指示待ち」になり、結果的に質の悪いシステムがギリギリに納品されて障害が起きる。自分がリーダーになったときは、絶対に現場に丸投げするような真似はしない。無駄な作業で疲弊させないと思っていました。

しかし、いざ自分が案件のリーダー的ポジションに立ち、外部パートナーを動かす側に回ったとき、決して自分が理想としていたようには振舞えませんでした。

2. 良かれと思った「思考の巻き取り」が招いた悲劇

リーダーとなった私が取った行動は、丸投げの逆。つまり「自分がすべての思考を巻き取る」ことでした。

詳細設計の細部
テストケースの大枠と観点一覧
WBSの微細なブレイクダウン
詳細なチェックリスト

本来、一次請けのリーダーが注力すべきは「要件定義」「基本設計」、そして顧客との折衝や社内調整のはずです。それにもかかわらず、私は細かいところまで全て自分で体制とお膳立てを作り、作業者にはそれに沿って手を動かしてもらう体制を目指しました。

どうしてこういう動きをとったのかというと、当時、私はSIer特有の「免責のためのテスト」に強い違和感を持っていたことが理由の一つだと思います。レビュー者が中身を見ずにハンコを押すための「1000ケースの盲目的な打鍵」よりも、システムの仕様とリスクを理解した上で設計された「根拠ある100ケースの打鍵」の方が、絶対に価値がある。前者はレビュー者が圧倒的に楽（何かあっても「全部やった」と言い訳できるから）なだけで、現場には無駄な疲弊を強いる悪習だと思っていました。

だから私は、「現場に無駄な苦労をかけたくない」「合理的に仕事を進めたい」という思いから、テストの観点やイレギュラーケースのロジックをすべて自分で組み立て、厳選した100ケースのリストを作成しました。

※事実を簡単化するために少し変えていますが、まあ言いたいことは上記のような話です。

現場にはただ、このリスト通りに手を動かしてもらえばいい。そうすれば平和に終わるはずでした。しかし、この「過保護なアプローチ」こそが失敗の元凶でした。

2.1 指示の「解像度」が招く罠

人にタスクを依頼する際の指示の出し方には、大きく分けて3つのレベルがあります。

丸投げ（雑すぎる指示）「〇〇画面の設計からテストまでお願いします」コミュニケーションコストは一見低いが、上がってくる成果物のブレ幅が大きすぎて後から大事故になる。
思考の巻き取り（過保護な指示）「〇〇画面の設計から結合テストまでお願いします。仕様の背景はこうで、参考資料はこれとこれです。（リーダー自身が事前に全て調べ上げて、作業のレールを完璧に敷く）」 ※今回の私がやってしまったのがこれです。
いい塩梅（目的の共有と思考の余白）「〇〇画面のテストをお願いします。目的は××の観点を担保することです。参考資料は渡しますが、周辺の仕様や具体的なアプローチは考えながら進めてください」

私は「1. 丸投げ」を嫌うあまり、「2. 思考の巻き取り」に振り切ってしまいました。指示は具体的であればあるほど、作業者側が「自分で考える仕事」は減ります。しかしそれは同時に、「指示されたレールから1ミリでも外れた事象が起きた瞬間、現場は思考停止する」という状態を作り出すことと同義でした。

2.2 完璧なリストが首を絞める

そもそも、私が「2. 思考の巻き取り（過保護）」を選んだのは、単なる自己満足だけではなく、そうしなければ「システムの品質が担保できない」と恐れていたからです。

理想を言えば、「3. いい塩梅（目的を伝えて、あとは考えてもらう）」の指示が最もスケールします。しかし現実問題として、「3」のコミュニケーションは、自走できる優秀なメンバーでなければ絶対に成り立ちません。スキルや文脈理解度が読めないパートナーに対して「3」の指示を出せば、意図を大きく外した無惨な成果物が上がってくる可能性がありました。だから私はシステムの質を守るため、相手が自走できなくても品質が担保できるよう、自分が完璧なレールを敷くしかなかったのです。

しかし、いざタスクを展開すると、現場との間に強烈な摩擦が生じました。

私が完璧だと思って渡したリストも、実際の開発環境では想定外のエラーや、リストに記載されていない仕様の矛盾が必ず発生します。その際、現場のメンバーは背景を自分たちで考えていないため、「リストにないエラーが出ました。どうすればいいですか？」と手が止まり、すべて私に確認が飛んでくるようになりました。

指示を明確にしすぎた結果、彼らから「自分で仕様を読み解き、判断する力」を完全に奪ってしまっていたのです。結果的に作業に追われることになり、作業期限が迫る焦りの中、最悪の丸投げをする形となりました。

3. 丸投げの代償：成果物の「ムラ」と自ら手を動かす尻拭い

期日になり、現場からテスト結果が上がってきました。いざ完了したものを見てみると、予想以上にうまくできている部分と、そうではない部分が入り混じった状態でした。

「もうリストの通りにやっといてください」と最後に丸投げしたにもかかわらず、チェックリストに明記された正常系の動作については、驚くほどきっちりとエビデンスが取られていました。彼らは決して不真面目だったわけではなく、与えられた指示の範囲内では忠実に作業をこなしてくれていたのです。

しかし、問題は「そうではない部分」でした。

コンテキストを理解していれば当然気づけるはずの画面の微妙な違和感、あるいはリストの条件から少しだけ外れたパターンのバグ。そうした部分は、スルーされていました。現場に「考える余白」を与えず、ただの作業者に落とし込んでしまった結果、テストの品質に致命的な「ムラ」が生まれてしまったのです。

この状態のままでは、当然リリース（あるいは上席のレビュー）に耐えうる品質ではありません。かといって、この期に及んで現場に背景から説明し直し、再テストを依頼する時間的な猶予も残されていませんでした。

結果として、意図が伝わっていなかった怪しい画面やイレギュラーケースを片っ端から自分で打鍵し直し、不足している品質を自らの手で担保する羽目になりました。

4. なぜ言えなかったのか？「負い目」による品質管理の放棄

しかし、この失敗の根っこは「指示の出し方」だけではありませんでした。もっと泥臭く、情けない2つの原因がありました。

原因1：こちらのミスによる「負い目」から、相手に強く言えなかった

プロジェクトの進行中、私自身にも不手際がありました。顧客との折衝中に要件が急遽変更になり、途中で設計をやり直してもらったり、こちらのQA回答が遅れてベンダーの作業を止めてしまったりしたのです。

現場に迷惑をかけてしまったという強烈な負い目があったことにより、相手のリーダーから上がってくる成果物が微妙だったり、末端メンバーへの展開がうまくいっていなかったりしても、毅然と指摘することができませんでした。

「今回はいいのですが、次以降は気をつけてください……」

そうやって曖昧な言葉でお茶を濁していました。本来、スケジュールの迷惑と納品物の品質基準は切り離して管理すべきです。しかし私は、「迷惑をかけた負い目」から逃げるために、リーダーとして求めるべき「品質のボーダーライン」を自ら放棄してしまいました。波風を立てたくないという私の弱さが、チーム全体の規律を緩めてしまったのです。

原因2：ベンダーではなく、「自分」が最大のボトルネックだった

もうひとつの致命的な失敗は、レビューの遅延です。ベンダー側は、画面単位で細かく成果物を上げてくれていました。仕組みとしては、手戻りを防ぐための理想的なやり方をしてくれていたのです。

しかし、受け取る側の私が「詳細設計もWBSも全部自分でやる」と手を動かすプレイヤー作業に没頭していたため、上がってきた成果物を確認する時間が全く取れませんでした。

結果として、2週間に一度まとめて確認するような状態になり、その時にはすでに大量のズレが積み上がっていました。「手戻りを防ぐために細かく出してもらう」体制を作っていたはずが、私自身が一番のボトルネックになってその仕組みを殺していたのです。

5. 2社のベンダーを動かして見えた「慣れ」と「新陳代謝」

当時、案件には2つのパートナー企業が関わっていました。長年の付き合いがあるA社と、今回新しく参画してくれたB社です。

ここでも私は、それぞれのベンダーに対するマネジメントで全く別の失敗と発見を経験することになります。

A社（長年の付き合いがあるパートナー）の場合

関係性が長い分、彼らには彼らの「いつものやり方」が染み付いていました。私は今回、システムの品質を上げるために新しいテスト観点や進め方をA社のリーダーに依頼しました。しかし結果として、彼らはそれを無視し、今まで通りのやり方で進めてきたのです。

ここで本来なら毅然と指摘すべきでしたが、第4章で触れた「迷惑をかけた負い目」や、長年の関係性による遠慮から、私はやり直させること（既存の慣れを壊すこと）から逃げてしまいました。

B社（新しく参画したパートナー）の場合

一方、B社はプロジェクトの文脈を持たないため、最初の説明コスト（コンテキストの共有）は非常に高くつきました。意図を汲み取ってもらうまでのやり取りで疲弊したのも事実です。しかし、一度そこを乗り越えると、彼らは私が提示した新しいやり方をしっかりと守ってくれました。

この経験は、私にとって大きな気づきでした。新しいベンダーを入れることで、これまでのA社との間にあった不文律や単なる惰性や暗黙のルールの危うさに気づくことができたのです。

体制を組むとは、単に「仕事を割り振ること」でも、「自分がすべての思考を抱え込んで現場を作業者に落とすこと」でもありません。

長年のパートナーの「慣れ」に対しては、摩擦を恐れずに新しい基準を要求し続けること。
新しいパートナーに対しては、最初のコミュニケーションコストを惜しまず、コンテキストを丁寧に共有すること。
「相手との関係性や特性に合わせてアプローチを変え、時には耳の痛いことも含めて『要求すべき基準』をコントロールすること」

それが、手痛い失敗を経て私が学んだ体制づくりの秘訣です。

おわりに：プレイヤーの殻を破る

自分で手を動かして、難解な不具合を取り除いたり、美しいシステムを設計できることは、エンジニアとして間違いなく良いスキルだと思います。

しかし、よく言われるように「自分一人で思考を完結させること」に固執しているうちは、自分1人のリソース以上の成果を出すことはできません。また、過剰に現場を守ろうとして思考を奪うことは、チーム全体の出力を下げることと同義です。

自分の持っている知識や勘所を、どうすれば他人が自律的に動ける「レール」に変換できるか。相手にどこまで考えてもらう体制を作るのか。

プレイヤーからその一歩先へ進むための壁は想像以上に高くて苦いものでしたが、この失敗を越えることこそが、組織でレバレッジを効かせるための第一歩なのだと感じています。