ロジカルシンキングの応用でオーバーワーク対策を取って、バーンアウト防止へ。

サブスクリプションメンバーに向けての英語バージョンがあります。English follows Japanese for subscription members.

バーンアウトは最近よく言及される言葉であり、一つよくある原因はオーバーワーク。個人的な経験上、正にロジカルシンキングで乗り越えたので、似たような心理的状態の方の参考になろうかと思うので、考え方を整理してみた。

１．オーバーワークシナリオの紹介

このコンサルティングファームにあるシナリオを想像しましょう。

あなたが一つ小さなクライアント向けプロジェクトの現場リードを務めている。
プロジェクトチームメンバーとして数人がアサインされ、WBS（Work Breakdown Structure - タスクリスト）を作成していて、メンバーにそれぞれタスク単位で役割分担をしている。あなたとチームメンバーはWBSのタスクを対応するだけで既に手一杯な状態。
クライアントがかなりデマンディング。あなだが頻繁に追加タスクや本来後に対応すべきタスクを優先してほしいというリクエストに追われる。
あなだがそれらのリクエストを対応するために、ほぼ毎日12時間以上稼働している。メンバーが既に過負荷になっているため、あなたが多数のタスクを巻き取るしかないと感じている。
一方、内部レビューの時、あなたの準備不足で常にマネジメントに指摘される。そして、クライアントからの指摘も頻発しているため、あなたがプロジェクトの問題を報告するための内部説明資料を複数作成しなければならない。
この状態が既に半年続いていて、あなだは疲弊していて、どうやってこのプロジェクトを遂行するのかはわからなくなってきた。

このようなシチュエーションはビジネスコンサルタントファームであるあるなケースでしょう。

プロジェクトの現場リーダーがリソース不足やクライアントをコントロールするパワーがないと感じているため、状況を打開する方法がないと思っている。

果たして本当にそうなのか。何もできないのだろうか。

２．どうやってロジカルシンキングを使って状況を打開するのか？

以前「ロジカルシンキングでメンタルヘルスへ」の中で、ビジネスだけではなく、メンタルヘルスの文脈でもロジカルシンキングを適用することができると説明したが、この実例で分析してアクションまで落とし込むようにトライしようと考える。

ビジュアライズドロジカルシンキングフレームワーク

事業会社からコンサルティングファームへ。ロジカルシンキングという課題は恐らく私と同じ経歴の方も経験しているのでしょう。短期間でコンサルタントとしてのベーシックスキルを向上するために、自分なりのビジュアライズドロジカルシンキングフレームワークを構築してみた。

Rebooting with Logical ThinkingLizi Chen

Logical Thinking for Mental Health

After three years of thinking, learning and practicing since my major burnout, I’ve come to this conclusion that LOGICAL THINKING is the key to mental health. ロジカルシンキングでメンタルヘルスへ。 Available in 🇯🇵日本語/Japanese. 🇬🇧English quotes included.

Rebooting with Logical ThinkingLizi Chen

以前紹介したフレームワークの通り、メンタルヘルスの問題も実質課題解決の一種であり、ロジカルシンキングのフレームワークを適用することが可能。

一部仮説を含めるが、まず5ステップモデルで大筋を考えると、下記のような全体像を整理することができる。

それぞれの要素を簡易的にビジュアライズすると、問題を分析し、WHAT 1.0からWHAT 2.0へ昇華する過程で、コントロールできないようなジレンマを対処できる問題に導くことができる。

真の課題まで辿り着いたら、解決の道筋はタクティカルなレイヤーとオペレーショナルレイヤーに落とし込むことができるケースが多い。

人が足りない、工数が足りない、クライアントを変えることもできない中、内部マネージメントのヘルプももらえないという、一見絶望的な状況だが、分析によると、そもそも「足りない」のはどこだ、「ヘルプがもらえない」のは本当に他人だけの問題なのか、そして重要なのは、当然ながらクライアントのビヘイビアを変えることが難しいが、共通のゴールであるプロジェクトの推進から妥協点をどう見つけるのか、という問題に置き換えることができ、実施すべきタスクは意外とベーシックなアクションの組み合わせとなる。

実際、クライアントと優先順位変更という方向での交渉ができ、チーム内でもタスクの棚卸しを実施して、オーナーシップベースでの役割分担を実施することで、プロジェクトリード一人ですべてのタスクを管理するというよりは、遂行責任をデリゲーションすることで一定程度の優先順位調整を各メンバーから提案することができた。リソースの追加も後追いでサポートをもらえたが、それはまた別のストーリーである。