旗振り役で大失敗した話 〜初めてプロジェクトの旗振り役を任された僕が、上司に怒られて学んだ4つの鉄則〜
梅本 海斗はじめに
こんにちは、海斗です。
僕は今、SUKI LABでイベント管理・応募システムの開発プロジェクトに携わっています。
イベント管理、出演者・振付師の管理、電子パンフレットなど、ダンスエンターテインメント業界向けの少し特殊な機能を持ったシステムです。
このプロジェクトで、僕は初めて「旗振り役」を任されました。
スケジュール管理、リソース調整、お客様との折衝、社内メンバーとの連携——いわゆるPM・ディレクター的なポジションです。
今回の旗振り役は大失敗の連続でした。
スケジュールはパンクし、上司には厳しく指摘され、品質面ではお客様に不安を与えてしまい、自分の段取りの悪さに頭を抱える日々。
この記事は、当時の自分と同じように「初めてプロジェクトの旗振りを任された人」に向けた、 僕の失敗と、そこから得た学びの記録 です。
きれいごと抜きで、何をやらかしてしまったのか、そこから何を学んだのかを書きます。
読み終えたあと、あなたが次にWBSを引くとき、上司に相談に行くとき、少しでも違う一手が打てるようになる——そんな記事を目指します。
失敗その1：「願望WBS」を引いた
最初の失敗は、メンバーの稼働可能時間を一切確認せずWBSを引いたことでした。
タスクを並べる前に、リソースを聞くべきだった——後悔しているのはこの一点です。
スケジュールが当初の想定よりタイトになっていることはわかっていたので、僕は「よし、WBSを引き直そう」と意気込みました。
タスクを洗い出し、依存関係を整理し、各タスクに担当者を割り振り、線を引いていく。
一見、ちゃんとPMっぽい仕事をしているように見えます。
でも、ここに 致命的な抜け がありました。
各メンバーの「残業上限」や「実際にどれだけ稼働できるか」を、 一切確認していなかった のです。
僕がやっていたのは、こういうことでした。
- 「このタスクはAさんなら3日でいけるはず」
- 「Bさんはたぶんこの期間空いてるから入れちゃおう」
- 「Cさんはここで巻き取ってもらえばOK」
「ここで間に合ってほしい」という願望 をもとに、線を引いていたんですね。
今振り返ると恐ろしいですが、当時はそれが「スケジュールを引く」ことだと本気で思っていました。
これを僕は今、自戒を込めて 「願望WBS」 と呼んでいます。
タスクは並んでいる。担当者も決まっている。日付も入っている。
一見ちゃんとしたWBSに見える。
でも、 裏付けとなるリソースの数字がどこにもない 。
当然、こんなWBSは現実とすぐに乖離します。
失敗その2：追加依頼に何でも「はい」と答えてしまった
2つ目の失敗は、WBSを引いた後の追加依頼に対して、深く考えずに「はい、やります」と即答してしまったことです。
気づけば当初のWBSは形骸化し、スケジュールはあっという間にパンクしました。
WBS自体は（リソース確認が甘かったとはいえ）一度は引いていました。
でも、進めていくうちにこんな依頼が次々と入ってきます。
- 「ここの画面、もう少し直してもらえる？」
- 「この機能、せっかくだから今回入れてしまわない？」
- 「あ、ついでにこの仕様も見ておいて」
その度に僕は、WBSも見ずに 「はい、やります」「大丈夫です」 と返事をしていました。
でも、追加依頼を引き受けるたびに、当初のWBSとの乖離はじわじわと広がっていきます。
数日後、改めてスケジュールを見直すと、当初引いた線とはまったく別物になっていました。
追加依頼を全部詰め込んだ結果、本来やるべきタスクの工数が圧迫され、すべてが間に合わなくなる ——という典型的なパンク状態です。
ここで僕がやるべきだったのは、「はい」と即答することではなく、 WBSを開いて天秤にかけてから返事をする ことでした。
具体的には、こんな選択肢があったはずです。
- 今のスコープに収まるなら ：影響タスクを確認したうえで受ける
- 収めるためにスケジュール延長が必要なら ：「対応はできますが、納期を◯日延ばしてもよいですか？」と条件付きで返す
- 延長も難しいなら ：「今回は時間が足りないので、次フェーズでの対応にさせてください」と断る
これら3択を、依頼を受けたその場で提示できていれば、WBSは生きたまま使えたはずです。
「はい」と即答することは、相手のためでも自分のためでもなく、ただ判断を先送りしているだけ でした。
失敗その3：上司への「丸投げ相談」
3つ目の失敗は、上司への相談で「困っている」という感情だけを投げ、判断材料を一切渡さなかったことです。
結果、想定外の厳しいフィードバックを受けることになりました。
スケジュールが厳しいと気づいた僕は、慌てて上司に相談をしました。
そこで僕が送ったメッセージはこんなのでした。
「期間がキツキツです。リソースが足りないので、他の方にヘルプに入ってほしいです」
上司からは、されるであろうフィードバックが返ってきました。
「どういうリソースでやるつもりなのか、その前提を伝えないと判断できないよ」
上司の言っていることは100%正しかったのです。
上司の立場から見ると、僕の相談はこう聞こえていたはずです。
- 「キツい」← どれくらいキツい？何時間足りない？
- 「リソースが足りない」← 今のリソースは何で、どこが何時間足りないの？
- 「ヘルプに入ってほしい」← 誰が、何時間、何のタスクに入る必要があるの？
つまり僕は、 判断材料を一切提示せず、「困ってます」という感情と「助けて」という結論だけを丸投げ していたんですね。
これでは上司は判断のしようがありません。
失敗その4：レビューとテストを軽視してバグを大量発生させた
4つ目は、品質面での僕の最大の失敗です。
WBSにテスト工程を組み込まず、相互レビューも結合テストも飛ばし、後半でバグを大量発生させてしまいました。
僕たちは3人体制で開発を進めていました。
役割分担は明確で、それぞれが担当機能を黙々と実装していく——一見、効率的に見えるスタイルです。
でも、ここに大きな落とし穴がありました。
それぞれが「自分のタスクを実装したら完了」として進めてしまい、お互いのコードレビューや、画面横断での結合テストを怠っていた のです。
各人の単体テスト（自分が作った画面が動く、というレベル）はやっています。
でも、
- 他のメンバーが書いたコードを誰もレビューしていない
- 画面同士が連携したときの動作を、第三者の目で確認していない
- お客様が実際に使う「業務シナリオ」での通しテストをやっていない
この状態で開発の終盤に突入してしまいました。
その結果、何が起きたか。
プロジェクト後半になって、バグが大量に発見されました。
しかも、お客様に触っていただくタイミングで、です。
画面遷移するとデータが消える、特定の操作でエラーが出る。
本来であれば社内で潰しておくべきレベルのバグが、お客様の前で次々と発覚してしまいました。
お客様からも、進行や品質に対する不安の声をいただくようになりました。
こちらが信頼を積み上げてきたつもりでも、品質トラブルが続けば、お客様の安心感は一瞬で崩れます。
ここで僕が反省すべきは、現場の3人ではなく、 旗振り役である自分自身 でした。
なぜなら、根本原因は明確だったからです。
WBSに「テスト」と「テスト指摘の改修」のための時間が、まったく組み込まれていなかった
だから、
- 相互レビューの時間
- 結合テスト・シナリオテストの時間
- そこで出た指摘を改修する時間
- 改修後の再テスト時間
これらが、WBS上にも、スケジュール上にも、まったく確保されていませんでした。
「テストする時間がないから、各自の単体確認だけで進めるしかない」——これは、起こるべくして起きた事故でした。
メンバーそれぞれが頑張って実装してくれていたからこそ、なおさら申し訳なかったです。
チームの努力を、品質トラブルという形で台無しにしてしまったのは、PMである僕の設計ミス でした。
旗振り役として学んだ5つの鉄則
この一連の失敗を通じて、僕は5つの鉄則を学びました。
鉄則1：WBSは「タスク × リソース × 工数」がそろって初めて成立する
スケジュールというのは、タスクを並べて線を引けば完成するものではありません。
WBSは、誰が・どれくらい動けて・何時間あるかの3点セットで初めて意味を持つ
タスクと日付だけを並べたWBSは、僕が引いたような 「願望WBS」 にしかなりません。
WBSを引く前に、まずやるべきは「メンバー一人ひとりの稼働可能時間を正確に把握する」こと。
これは絶対に省略してはいけません。
鉄則2：追加依頼は「はい」と即答せず、WBSと天秤にかけてから返事する
WBSを引いた後の追加依頼ほど、PMが冷静さを試される瞬間はありません。
即答の「はい」は判断ではなく、ただの判断の先送り
WBSを引いてしまうと「あとは進めるだけ」と気が緩みがちです。
でも、追加依頼が入った瞬間こそ、WBSを開いて影響を計算するタイミングです。
判断材料が揃ったら、その場で次の3択のいずれかを返します。
- 今のスコープで対応可能 → 受ける
- 対応するには納期延長が必要 → 「◯日延ばせるなら可能です」と条件付きで返す
- 延長も難しい → 「今回は厳しいので次フェーズで対応させてください」と断る
「断る」のはPMの責務です。
依頼者を守るためでもあるので、勇気を持って線を引きましょう。
鉄則3：相談は「感情」ではなく「事実 × 選択肢」をセットで持っていく
「キツいです」「足りないです」「助けてください」——これらはすべて感情と結論であって、判断材料ではありません。
上司に渡すべきは「困っている」ではなく、判断するための材料
上司やチームに相談するときは、最低限この3つをセットで持っていく必要があります。
- 現在の正確なリソース （誰が、何時間動けるのか）
- タスクの優先順位 （何が必須で、何が後回し可能か）
- 具体的な代替案 （自分はこうしたいと思うが、どうか）
判断は上司の仕事です。
でも、 判断するための材料を整えるのはPMの仕事 です。
ここを混同すると、相談がただの「丸投げ」になります。
鉄則4：時間が足りないときほど、「やらないこと」を決める勇気を持つ
PMにとって一番難しいのは、 「やらない」を決めること だと痛感しました。
何かを足すなら、必ず何かを引く——これがリソース有限下の絶対ルール
時間が足りないと、つい「全部やらなきゃ」「念のため全部やっておこう」と考えがちです。
でも、リソースが有限である以上、足し算と引き算をセットで考えるしかありません。
優先順位をつけて、後回しにできるものは後回しにする。
スコープを切って、いま本当にやるべきことに集中する。
これは「サボり」ではなく、 プロジェクトを成功させるための戦略的な判断 です。
「やらないことを決める」——これができるかどうかが、PMの実力を分けるのだと思います。
鉄則5：WBSに「テスト」と「テスト指摘の改修」を必ず組み込む
これは今回、お客様を不安にさせてしまった経験から得た、 何よりも重い教訓 です。
「実装工数」と同じ重みで、「テスト工数」と「改修工数」を見積もる
「実装が終わる ＝ 機能が完成する」ではありません。
品質を担保するためには、最低でも次の工程をWBSに明示的に積む必要があります。
- 相互コードレビュー （自分以外の目を必ず通す）
- 結合テスト・業務シナリオテスト （画面単体ではなく、お客様の使い方で通す）
- テスト指摘の改修工数 （必ず指摘は出る前提で、バッファではなくタスクとして積む）
- 改修後の再テスト （直したら必ずもう一度通す）
ここを省略すると、何が起きるか。
プロジェクト後半に、潰せたはずのバグがまとめて噴出し、お客様の信頼を一気に失います。
スケジュール遅延よりも、品質トラブルによる不信感のほうが、リカバリーがはるかに難しいです。
時間が足りないときほど、テストを削ってはいけません。
むしろテストを死守するために、実装スコープのほうを削るべきだ——というのが、僕がこの失敗から得た最大の学びです。
おわりに
初めて旗振り役を任されたとき、僕は「ちゃんとやらなきゃ」というプレッシャーで頭がいっぱいでした。
その結果、リソースを確認しないままWBSを引き、追加依頼に何でも「はい」と答え、感情だけで上司に相談に行き、テスト工数を組み込まないまま実装を走らせ、お客様を不安にさせてしまいました。
それでも次の一歩が踏み出せているのは、上司のフィードバック、最後まで一緒に走ってくれたメンバーのおかげです。
正直、まだまだ旗振り役としては未熟です。
今回学んだ5つの鉄則も、頭ではわかっていても、次のプロジェクトでまた違う形でつまずくと思います。
でも、 失敗を「失敗のまま」終わらせず、ちゃんと言語化して次に活かす こと。
それが、一歩ずつ成長していく唯一の方法なのかなと、今は思っています。
もし今、初めての旗振りでうまくいかずに悩んでいる人がいたら、ぜひこれだけ覚えて帰ってください。
「タスクではなく、リソースから考える」
「追加依頼は即答せず、WBSと天秤にかける」
「感情ではなく、事実と選択肢で相談する」
「全部やらない勇気を持つ」
「テストと改修を、実装と同じ重みでWBSに積む」
この5つを意識するだけで、きっと景色が変わります。
僕自身、次のプロジェクトでは、まずWBSを引く前に メンバーの稼働可能時間を全員分シートにまとめて共有する ところから始めます。
そして実装タスクと同じ行に、必ず 「レビュー」「結合テスト」「指摘改修」「再テスト」 の4工程を引く。
この2つを、最初の一歩にします。
最後まで読んでいただき、ありがとうございました。
