議題

仕事でも、システムでも、設備でも、よく使われる言葉があります。

「去年もこれで問題なかった。」

「例年通り運用しています。」

「これまで事故は起きていません。」

一見すると、安心材料のように聞こえます。

しかし、本当にそうでしょうか。

2026年7月、多摩動物公園で飼育されていたライオン複数頭が体調を崩し、その後3頭が死亡しました。

東京都の最終報告では、最も可能性の高い死因として、暑熱順化が不十分な状態で急激な気温上昇にさらされたことによる熱中症、そして重症化による多臓器不全が挙げられています。

重要なのは、東京都自身が、

「飼育管理は例年通り行っていた」

と説明していることです。

私はこの事例を見て、プロジェクトマネジメントでも全く同じことが起きると思いました。

そして同時に、もう一つ強く感じます。

これは単なる「運用改善」の話ではありません。

命を預かる仕事なのだという自覚の話でもあります。

---

「例年通り」は、安全を保証しない

今回の事故では、2026年6月から7月初旬までは比較的涼しかった一方、その後に急激に気温が上昇しました。

そのため、ライオンの身体が暑さに十分慣れる前に高温環境へさらされたことが、事故につながった可能性が高いとされています。

つまり、

管理方法が変わっていなくても、環境側が変わった。

ということです。

これはプロジェクトでも非常によくあります。

• ユーザー数が増えた
• 売上規模が増えた
• 取り扱うデータ量が増えた
• 担当者が変わった
• 外部サービスが変わった
• 法規制が変わった
• 攻撃手法が変わった
• 顧客の期待値が変わった

しかし、運用方法だけは昔のまま。

---

「これまで問題なかった」は、過去の話

プロジェクトで、よく聞く言葉があります。

「今までこのやり方で問題なかった。」

しかし、この言葉には一つ大きな落とし穴があります。

今まで問題がなかったのは、今までの条件下での話です。

条件が変われば、同じやり方でも結果は変わります。

例えば、アクセス数が1日100件だったサービスと、1日10万件になったサービスでは、同じサーバー構成でよいとは限りません。

10人の組織で機能していた情報共有方法が、100人でも機能するとは限りません。

国内だけで販売していたサービスが海外展開すれば、物流、法規制、言語、税務、顧客対応の前提が変わります。

---

プロジェクトは「前提条件」で成立している

私は、プロジェクトを見るときに、タスクやスケジュールだけではなく、

「この計画は、どんな前提の上に成立しているのか」

を見ることが重要だと思っています。

例えば、

• 月間アクセスは10万件程度
• 担当者は3人いる
• 特定の外部サービスが正常稼働している
• 物流コストは現在の水準
• 顧客問い合わせは1日20件程度
• 特定の技術がサポート対象である

こうしたものです。

そして、このどれか一つでも変われば、プロジェクト設計そのものを見直す必要があります。

プロジェクトとは、タスクの集合ではなく、前提条件の上に成立している仕組みです。

---

ただし、命を預かる仕事はそれだけでは足りない

ここからは、少し厳しい言い方をします。

動物園で動物を飼育する仕事は、単なる施設運営ではありません。

命を預かる仕事です。

ライオンは、

今日は暑いから室内へ入りたい。

身体がつらい。

この環境は危険だ。

と、自分で人間へ説明することができません。

逃げる場所も、環境を変える権限も持っていません。

飼育環境のすべてを、人間側に委ねています。

だから私は、

「仕事として決められた飼育業務をやりました。」

だけでは足りないと思います。

目の前の動物が苦しんでいないか。

昨日と様子が違わないか。

今年の暑さはこれまでと違わないか。

今の設備で本当に守れるのか。

そこまで考える。

その原動力になるのは、マニュアルだけではありません。

その動物を守りたいという愛情と責任感です。

---

愛情があるから、管理が細かくなる

「愛情」というと、プロジェクトマネジメントとは関係のない感情論に聞こえるかもしれません。

しかし、私は逆だと思っています。

本当に守りたい対象があるからこそ、

• 小さな変化に気付く
• 温度を細かく見る
• 昨日との違いを見る
• 異変を記録する
• 危険を早めに共有する
• 必要なら展示を止める
• 設備投資を提案する

という管理行動が自然に起きます。

数字を見ることも、報告することも、止める判断をすることも、全部その目的のためにあります。

---

命を預かる仕事に「後で直せばいい」はない

Webサイトなら、表示崩れが起きても修正できます。

システムの不具合なら、バックアップから復旧できることもあります。

商品ページの誤字なら、後から直すことができます。

しかし、命は違います。

一度失った命は、修正できません。

再リリースも、ロールバックもできません。

もちろん、人が関わる以上、絶対にミスをゼロにできるとは限りません。

しかし、

「ミスが起きても仕方ない」ことと、「ミスを許容する設計でよい」ことは全く違います。

命を扱う以上、可能な限り事故が起きないよう、何重にも予防する。

そこまでやる責任があります。

---

銀行が預金を預かるのと同じくらい、重い責任がある

銀行は、お客様からお金を預かっています。

そのため、

「担当者がうっかりしていました。」

「例年通りの管理でした。」

「環境が変わっていました。」

では済みません。

多重チェック。

権限管理。

監視。

異常検知。

バックアップ。

監査。

さまざまな仕組みで守ります。

なぜなら、

自分のものではなく、お客様から預かった大切な資産だからです。

動物園も同じだと思います。

むしろ、失ったら戻せないという意味では、さらに重いとも言えます。

だからこそ、命を預かる仕事では、

「普通の仕事」と同じレベルの危機管理では足りません。

失敗を前提にしてはいけない領域として、管理を設計する必要があります。

---

リスク管理は「問題が起きてから」では遅い

多摩動物公園では、事故後に暑熱対策を大きく強化しています。

東京都の最終報告では、

• 日陰を増やす
• 大型送風機を設置する
• 水飲み場を改修する
• 将来的に常設空調を導入する
• 舎内の断熱・気密化を進める
• 放飼場内の温度を遠隔測定する
• 動物の体温を遠隔測定する
• WBGTを踏まえた展示中止基準を策定する

といった対策が示されています。

これは非常に重要です。

なぜなら、

「暑くなったら対応する」から、「危険になる前に検知して止める」へ考え方が変わっている

からです。

---

人の感覚だけでは限界がある

今回の再発防止策では、動物の体温や放飼場の温度を遠隔測定する仕組みの導入が示されています。

これも、プロジェクト管理にそのまま置き換えられます。

現場では、

「まだ大丈夫そうです。」

「少し忙しいですが問題ありません。」

「なんとか回っています。」

という言葉がよく使われます。

しかし、感覚だけでは危険です。

だからこそ、

• 工数
• 残業時間
• 問い合わせ件数
• エラー件数
• 売上
• アクセス数
• 遅延件数
• 課題残数

など、状態を数値として見る必要があります。

これもPMの重要な仕事です。

---

「異変の兆候」を決めておく

東京都は今後、ライオンの異変兆候やWBGTをもとに、展示中止基準を策定するとしています。

これも非常に参考になります。

プロジェクトでも、

「危なくなったら止める。」

では遅いことがあります。

では、何をもって危険と判断するのか。

事前に決めておく必要があります。

例えば、

• 障害件数が一定数を超えたら公開延期
• テスト消化率が基準を下回ったらリリース中止
• 残業時間が一定値を超えたら体制見直し
• 問い合わせ件数が急増したら原因調査
• 売上変動が一定幅を超えたら施策停止

といった基準です。

「止める勇気」より先に、「止める基準」を作っておく。

これが重要です。

---

急激な変化が最も危ない

今回の事故で特に注目すべきなのは、単純に「暑かった」だけではない点です。

比較的涼しい時期から、急激に高温へ変化した。

この変化速度が大きな要因とされています。

これはビジネスでも同じです。

会社が少しずつ成長する場合と、半年で売上が10倍になる場合では、組織への負荷は全く違います。

1年かけてユーザーが増える場合と、SNSで突然話題になり1週間でアクセスが100倍になる場合も違います。

---

成功しているときほど、前提を疑う

事故や失敗が起きているときは、誰でも改善しようとします。

難しいのは、問題が起きていないときです。

売上も順調。

システムも動いている。

クレームも少ない。

だから、何も変えない。

しかし、本当は、そういう時こそ確認する必要があります。

「今の成功は、どんな条件の上に成立しているのか。」

そして、

「その条件は今も変わっていないのか。」

です。

---

コンサルタントの役割もここにある

コンサルタントが価値を出す場面の一つは、

「今のやり方に問題がある。」

と指摘することだけではありません。

むしろ、

今は問題なく動いているが、前提が変われば危険になる部分を見つける。

ことだと思います。

現場では当たり前になっている。

昔からそうしている。

だから誰も疑わない。

その前提に対して、

「なぜ、この方法なのですか？」

「この条件が変わったらどうなりますか？」

「どこまでなら耐えられますか？」

と問いかける。

これもコンサルティングの重要な役割です。

---

プロジェクトで確認したい5つの前提

私は、プロジェクトでは定期的に少なくとも次の5点を確認すると良いと思います。

1. 環境：市場・技術・法律・顧客は変わっていないか
2. 規模：利用者・売上・データ・業務量は増えていないか
3. 人：体制・能力・負荷は変わっていないか
4. 仕組み：設備・システム・運用方法は今の規模に合っているか
5. 基準：危険を検知し、止める基準があるか

この5つを見直すだけでも、

「昔は大丈夫だったから、今も大丈夫。」

という思い込みをかなり減らせます。

---

まとめ

多摩動物公園のライオン事故では、例年通りの飼育管理が行われていました。

それでも、急激な気温上昇という環境変化によって、これまでの管理方法では十分ではなくなりました。

この事例から学べるのは、

ということです。

そして、命を預かる仕事では、もう一段深い自覚が必要だと思います。

ライオンは、自分の命を自分で管理できる環境にいません。

その命を、人間へ預けています。

だからこそ、

「例年通りやった。」

「マニュアル通りだった。」

だけで終わってはいけない。

本当に守れているのか。

今年の環境でも安全なのか。

昨日と違う兆候はないのか。

そこまで考え続ける。

それが命を預かる仕事の責任だと思います。

そしてこれは、銀行がお客様の資産を預かる仕事と同じように、

「失敗したら後で直せばいい」が通用しない領域です。

プロジェクトマネジメントとは、単に予定やタスクを管理することではありません。

守るべきものを守るために、変化を察知し、必要なら仕組みを変え、時には止める。

その責任を引き受けることなのではないでしょうか。