見出し画像

飲み会の幹事を任せるとプロジェクトマネジメント力がわかる

すてぃお

プロジェクトがうまくいかない原因の多くは、技術的な問題ではなくて、
プロジェクトの進行管理ができていないことだと思ってます。

もう少し具体的にすると、「どこで想定外のことが発生しそうか？」ということを事前に予測できているかどうかが、プロジェクトの成否を分けます。

飲み会の幹事を任せてみると、その人のプロジェクトマネジメント能力がよくわかるなと思って、書いてみます。


「飲み会やります」と言うのは簡単です。でも実際にやるとなると、こんな工程があります。

これを見て「大したことないでしょ」と思う人と、「いろいろ考えることあるな」と思う人がいますが、前者は幹事をやったことがないか、よほど素晴らしい環境でしか幹事をやったことないのではないかと思う。

飲み会で起きるトラブルを想像できるか

飲み会の幹事をやったことがある人なら、こんなトラブルを経験したことがあると思う。

日程調整のトラブル

  • 候補日を出したのに誰も返信しない

  • 「どの日でもいいです」と言っておいて、決まった後に「その日は無理でした」と言う人がいる

  • 日程調整したけど全員が参加できる日程が存在しなかった

店選びのトラブル

  • 個室を予約したつもりが半個室だった

  • アレルギーのある人がいることを当日知った

  • 場所がわかりづらくて、迷う人が続出した

当日のトラブル

  • ドタキャンが発生

    • 「あ、今日だったの？」という人もちらほら

  • 遅刻する人が多く、開始時間になっても人が全然集まらない

会計のトラブル

  • 現金を持っていない人がいた or 現金しか持ってない人がいた

    • 細かいお金を持ってなくて、お釣りを渡せないなど…

  • 立て替えたけど1ヶ月経っても支払われない

  • 払ったフリをして払わない人が出てくる

これらのトラブルを事前に想像できるかどうか。想像できれば対策が打てます。想像できなければ、当日になって慌てることになります。

プロジェクトでも同じことが起きている

プロジェクトでも同じです。
「この機能を作って」と言われたとき、実際には以下のような工程があります。

そして、それぞれの工程でトラブルが起きうります。

要件整理のトラブル

  • 「こういう意味だと思ってました」という認識のズレ

  • 後から「これも必要だった」と追加要件が出てくる

  • ステークホルダーによって言うことが違う

技術調査のトラブル

  • 使おうと思っていたライブラリがメンテナンスされていない

  • 本番環境では動かない制約が見つかる

  • ライセンスの問題が発覚する

実装のトラブル

  • 想定より複雑で時間がかかる

  • 既存コードとの整合性が取れない

  • パフォーマンスが出ない

デプロイのトラブル

  • 本番環境と開発環境の差異で動かない

  • マイグレーションに時間がかかる

  • ロールバックできない

これらのトラブルを事前に想像できるかどうか。想像できれば、スケジュールにバッファを積んだり、事前に確認したり、代替案を用意することができます。

共通認識を取るべき3つのこと

プロジェクトを始める前に、以下の3つを共有しておくと良い。

1. どういう工程があるか

まず、そのプロジェクトにどんな工程があるかを洗い出す。漏れがあると後から「これもやるの？」となる。

飲み会で言えば、「店を予約するだけでしょ」と思っている人と、「日程調整から精算まで全部やる」と思っている人がいたら、認識がずれている。

プロジェクトで言えば、「コードを書くだけでしょ」と思っている人と、「要件整理からリリースまで全部やる」と思っている人がいたら、同じように認識がずれている。

最初に工程を書き出して、「これで全部ですか？」と確認する。これだけで後からの手戻りがぐっと減ります。

2. どういう順番でやるか

工程の順番も重要です。並行してできるものと、前の工程が終わらないと始められないものがあります。

飲み会で言えば、日程が決まらないと店の予約ができない。でも、候補の店を探しておくことは日程確定前でもできます。

プロジェクトで言えば、設計が終わらないと実装が始められない。でも、技術調査は設計と並行して進められることもあります。

依存関係を整理しておくと、「今何を待っているのか」「今何ができるのか」が明確になります。

3. どこでトラブルが起きそうか

工程ごとに「どんなトラブルが起きそうか」を予測しておく。

飲み会で言えば、「この人は遅刻しがちだから、集合時間を15分早めに伝えておこう」「現金で払う人が多いからお釣りのための現金を多めに持っておこう」といった予測です。

プロジェクトで言えば、「この部分は既存コードが複雑だから時間かかりそう」「外部APIを使うから、仕様変更のリスクがある」「この人は他のタスクも抱えているから、レビューに時間がかかるかも」といった予測です。

トラブルを予測できていれば、それが起きたときに慌てないで済みます
。「想定内です」と言えるし、想定内なら対策も打つことができます。

認識がずれると何が起きるか

共通認識が取れていないと、こんなことが起きる。

飲み会の場合

  • 「もう店決まった？」「まだ日程調整中です」

  • 「なんでそんなに時間かかるの」「候補日出しても誰も返信くれなくて...」

  • 「会費高くない？」「飲み放題つけたらこうなりました」

  • 当日に「え、今日だったの？」という人が現れる

プロジェクトの場合

  • 「もうできた？」「まだ要件整理中です」

  • 「なんでそんなに時間かかるの」「想定より複雑で...」

  • 「そこまでやるとは思ってなかった」

  • 「そこはやらなくていいと思ってた」

  • リリース直前に「これも必要だった」と言われる

どれも、工程の認識がずれていたから起きる問題だ。そして、トラブルが予測できていなかったから、対処が後手に回っている。

トラブル予測ができる人とできない人の違い

トラブル予測ができる人とできない人の違いは何か。

経験の差もあるが、それだけではないと考えています。同じ経験をしても、そこから学ぶ人と学ばない人がいます。

トラブル予測ができる人は、過去のトラブルを「運が悪かった」で終わらせない。「なぜ起きたのか」「次回どうすれば防げるか」を考えています。

飲み会で現金を持っていない人がいたら、「あのひとのせいだ」で終わらせずに、「事前に精算方法を伝えておこう」「PayPayでももらえるようにしておこう」と対策を考えることができます。

プロジェクトで想定外の問題が起きたら、「想定外だったから仕方ない」で終わらせずに、「なぜ想定できなかったのか」「どうすれば想定できたか」を考えることを積み重ねることによって、トラブル予測能力を高めていきます。

事前に15分話すだけで変わる

工程の共通認識を取って、トラブルを予測するのに、そんなに時間はかかりません。

ホワイトボードに工程を書き出して、順番を確認して、「ここでこういうトラブル起きそうですよね」と話す。15分もあればできちゃいます。

飲み会なら、幹事を任せる前に「参加者こんな感じで、予算これくらいで、日程調整から精算までよろしく。現金持ってない人多いかもしれないから気をつけて」と伝える。これで10分もかかりません。

15分を惜しんで、後から何時間も「なんでこうなった」「聞いてない」という会話をするのは、本当にもったいないです。

「当たり前」ができていないプロジェクトが多い

「そんなの当たり前でしょ」と思うかもしれない。

でも実際には、これができていないプロジェクトがとても多いです。

工程を洗い出さずに「とりあえずやって」と言う。順番を決めずに「並行して進めて」と言う。トラブルを予測せずに「問題が起きたら対応して」と言う。

そして問題が起きると「なんで事前に言わなかったの」と言われてしまう。

後手後手に回ってしまうことで余計に時間を使ってしまうのです。

飲み会の幹事を経験させる価値

若手に飲み会の幹事を経験させることには価値があると思ってます。

パワハラ的な意味ではなくて、飲み会の幹事は、プロジェクトマネジメントの縮小版だからです。

  • 関係者の調整

  • スケジュール管理

  • リソース（予算、場所）の確保

  • リスク管理（トラブル予測と対策）

  • 当日のオペレーション

  • 事後処理

これらを小さなスケールで経験できる。失敗しても、プロジェクトの失敗ほどダメージは大きくはありません。

そして、僕のなんとなくの感覚なのですが、飲み会の幹事をうまくやれる人は、プロジェクトマネジメントもうまくやれる可能性が高いと考えています。逆に、飲み会の幹事すらうまく運用できない人は、プロジェクトでもうまく運用できない可能性が高いです。

まとめ

プロジェクトでも飲み会でも、何かをやるときは工程の共通認識を取ることが大事です。

  • どういう工程があるか

  • どういう順番でやるか

  • どこでトラブルが起きそうか

この3つを最初に共有するだけで、物事はぐっとスムーズになります。

特に「どこでトラブルが起きそうか」を予測できるかどうかが重要です。トラブルを予測できていれば、それが起きても「想定内」として対処でき、
予測できていなければ、慌てて後手に回ってしまいます。

当たり前のことを当たり前のように共通認識を取るだけで、後からの何時間もの混乱を防げるのです。


本題としては終わりですが、飲み会の幹事を行う人のために実践ノウハウを下記に残しておきます。

飲み会幹事の実践ノウハウ

飲み会の幹事で押さえるべきは「人」「日程」「場所」の3つです。優先順位は基本的に「日程 >= 人 >>>>> 場所」となる。日程が一番重要なのは、飲み会は開催すること自体が最優先だからです。

日程の決め方

大人数の場合は調整さんなどのツールを使ったり、チャットツール内で決めてもいいですが、期限を設定し、回答しない人には積極的にプッシュする必要があります。

3月、4月、12月、1月は歓送迎会や忘新年会のシーズンで店が混みます。特に金曜日は予約すら困難になるので、1ヶ月以上前、できれば2ヶ月前から予約準備を始める。
期間に余裕があれば、お店の選択肢の幅が圧倒的に広がったり、急いでやらないといけないことが少なくなります。

他の人に伝える際の期限設定のコツは、自分が思っている最終期限よりも前に設定すること。バッファを常に持っておく。

全員が合う日程がなかった場合は、合わない人にあきらめてもらうか、再度日程を追加して調整する。ここで悩みすぎると永遠に決まらない。
※日程調整した上で合わなそうと人は、裏でDMとかでメッセージしておくとスムーズに進みやすいです。

人の決め方

歓送迎会の場合は当然、歓迎される人・送迎される人は必ず参加してもらう場合が多いのではないでしょうか。また、チーム特性や飲み会のコンセプトによって変わります。基本的にチームの飲み会ならチーム全員を誘うのが定番です。

場所選びのチェックリスト

  • 人数が入るかどうか

  • コース＆飲み放題が提供されているか

  • 料金

  • 予算の負担元（会社負担、自己負担、上長負担）を事前確認

  • 個室か半個室か

  • 喫煙可否（参加者によって判断）

  • 駅からの距離

  • 参加者のアレルギーや苦手な食べ物

一度行ったことのある店だと当日のイメージが湧きます。下見してもいいくらいです。日頃から使えそうな店をストックしておくと良いですが
どんな席なのか、ネットで確認したり、電話して確認しても良いです。

また、コースや飲み放題がいい理由は金額が会社負担の場合は予算が設定されてたりするし、個人負担の場合も事前に支払ってもらうことでお金の回収漏れをできるだけなくすためです。

参加者への連絡

日程と場所が決まったら参加者に連絡する。会社の場合は参加者のカレンダーに予定を登録しておく。

飲み会の場所はGoogle MapのURLや食べログのURLを貼るのがオススメです。キャンセル期限、キャンセル料も明記しておきましょう。ドタキャンの抑止及びドタキャン時に支払ってもらうためです。

連絡のサンプル

皆様、お疲れ様です。
○○さんの歓迎会についての連絡になります。

日程：2025-12-19（金） 19:00 ~ 21:30
場所：○○○○（https://example.com/shop-name）
料金：6000円（2時間飲み放題コース）

キャンセルは12月17日の18時までにお願いいたします。
それ以降についてはキャンセル料が6,000円がかかります。

料金については事前にいただきたく、別途連絡させていただきます。

では皆様、当日よろしくお願いいたします。

集金の優先順位

お金の集金は「事前 >>>>>> 事後」ぐらい楽さが違います。

当日にお店で集金するのはできれば、避けた方がいいです。お金をもらったかどうかの管理が手間で、お酒を飲むと払う側も受け取る側も忘れてしまいます。
飲み放題みたいに金額が確定していると集めやすいですね。

どうしても当日になる場合は、チェックリストを用意して飲み会の最初に集金することで漏れを防げます。事後になると、払わない人や忘れる人が普通に出てくる。

リマインド

前日や当日に予定通り行われることをリマインドしていきましょう。
忘れている人や予定が漏れている人が必ずいると認識しましょう。

会社の人とみんなで会社から出る場合は同じ時間に出発するので出発時間を決めておいたり、
タクシーで行く場合はタクシーを誰が捕まえる、予約しておくなどもあると思うので移動手段はちゃんと整理しておきましょう。

いいなと思ったら応援しよう！

すてぃお よろしければ応援お願いします！ いただいたチップはおいしいご飯を食べるのに使わせていただきます。