デキる人はなぜトラブルに慌てないのか？
※本稿は、木部智之『複雑な問題が一瞬でシンプルになる2軸思考』（KADOKAWA）を再編集したものです。
■「問題」を自分でさらに複雑にしていないか？
「木部さん、大変です！ ヤバそうなトラブルが発生しました。なんとかして、期限は間に合わせたいのですが、どうしたらいいでしょう？」
メンバーが真っ青な顔をして、慌てた様子でプロジェクトマネジャーである私のところに相談にやってくる……。
私の携わっているシステム開発では、よくある光景です。
トラブルや緊急事態というのは、それが複雑であればあるほど、困難であればあるほど、その人の本質が問われる場面です。
こうした究極の局面で、「慌ててパニックになってしまう人」と「落ち着いて対応してトラブルを解決に導ける人」とでは、いったい何が違うのでしょう？
生まれ持った頭の良さでしょうか？
あるいは経験の豊富さでしょうか？
もちろん、そうしたことが違いになることあります。
しかし、最も重要な違いは、「ロジカルに考えているかどうか」です。
トラブルに遭遇すると、途端に平常心を失ってしまう人がいます。
そして、普段は普通に判断できることが判断できなくなったり、自分で問題をより複雑にしてしまうのです。
そうしないために必要なのが、「ロジカルな思考」です。
「ロジカルな思考」を具体的に言うと、「問題の全体を俯瞰して捉えているか」「複雑なことを、シンプルにしてから考えているか」ということになるでしょう。
■頭がいい人とは、複雑な問題をシンプルにできる人
どんなに難しい仕事も、よくよく見てみれば、基本的な仕事の応用形であり、変化形です。
絡み合った物事をシンプルにして問題の本質を見抜くことができれば、おのずとその解決策を見つけることができるはずです。
つまり、「本当に頭のいい人」というのは、複雑な問題を「複雑なまま解くことができる人」ではなく、複雑な問題を「誰でも解けるくらいの簡単なレベルまで分割できる人」なのです。
例えば、突発的なシステム障害が起こった場合――私の仕事（システム開発）は、システムトラブルが付きものです。システムというのは、ビルや橋と違って、目に見えないもので、そのシステムがトラブってしまうと、原因をつかむのが難しいことが多々あります。 エラーのログ（履歴）を見れば、すぐにわかる場合もありますが、必ずしもそうでもなく、まったくもって何が起きているのかがわからないこともあります。
そんな中、トラブル対応をしているチームの様子を観察していると、「慌ててしまう人」と「的確に行動できる人」の差が、明らかに見てとれます。
混乱した状況について「複雑なまま考えている」人は、目の前のトラブルに慌ててしまい、「あれをしなきゃ、これをしなきゃ」と思いつきで動き、対応に余計な時間がかかってしまいます。ときには、さらなる障害を引き起こしてしまうこともあります。
こういう人は、「木部さん、トラブルです！」と報告が迅速なわりに、「で、問題は何なの？」と聞くと、整理して答えることができません。
一方で「全体を俯瞰し、問題をシンプルにしてから考えることができる人」は、5分でも10分でも立ち止まって、ホワイトボードに全体像、原因、やること、担当者などを冷静に書き出し、情報を整理してから問題に取り掛かります。
例えばシステム障害のトラブル対応であれば、図のように、やるべきタスクと時間と担当を先に洗い出し、2軸の図に整理してから動き始めます。
■立ち止まったほうが、ゴールに到着するのは早い
ちょっとしたことですが、慌てずにこういう行動ができる人は、よりスムーズに、しかも最短の時間でトラブルを解決できているようです。
なぜなら、動き出す前に情報をシンプルに整理し、可視化することで、結果的にやるべき作業の総量が激減しているからです。動く前に作業手順が効率的に考えられているので、ムダな動きは生まれません。
わずかな時間を惜しんで見切り発車をするよりも、5分、10分くらい立ち止まったほうが最短ルートを見つけられるので、より早くゴールにたどり着けるのです。
実際、私のチームに突発的なトラブルが発生したときには、プロジェクトのメンバーに「走るな！」とか「手を止めて、まずはしっかり考えろ！」と、止まることを指示することがよくあります。
無我夢中で走って稼げる数秒よりも、まずはしっかり考えてから動くほうが結果的に早いということを、経験上、知っているからです。
■状況と原因を特定するときに使える方法
問題の起こっている状況と原因を特定するのに、簡単に使える方法があります。
「わかっていること」と「わかっていないこと」を2軸の表に仕分けていく方法です。
トラブル発生時、まったくもって何が起きているのかわからない状況ではありつつも、いくつかわかっていることもあるはずです。
システムの場合は、「間違いなく正常に動いている機能」は「わかっていること」に仕分けられます。
仕分けていく中で、「わかっていないこと」が判明してきたら、さらにそれを「わかっていること」と「わかっていないこと」に仕分けていきます。このステップを繰り返すと、怪しいエリアが徐々に絞られていきます。
ある程度まで怪しい箇所が絞られてきたら、今度はそこを集中的に精査して、原因の特定にかかります。メンバーも増員して、一気に調べあげるのです。
エリアが絞れていない状況で人を投入すると、多くの人数と時間が費やされてしまいますが、調査するエリアが小さければ、最小の労力と最短の時間で問題の原因を特定することが可能になります。
身近な事象を例にあげるなら、「朝、出社したら、財布がない」ということに気づいたとき――。
そんなときは、「朝起きてから会社に着くまで」を振り返り、どこまではあったかを確認するはずです。
「家を出るときはあった」とか、「電車に乗る前、駅に行く途中のコンビニで買い物をしたときに財布からお金を出した」とか。
「確実に手元に財布があったとき」を明らかにすると、財布をなくした可能性のある場所が絞りこまれていきます。
「電車に乗ったときまで確実にあった」と判明すれば、コンビニに問い合わせする必要はなくなります。「電車に乗っている間が怪しい」と絞られてきたら、鉄道会社の落とし物センターに問い合わせればいいわけで、アクションは最小になります。
――焦ってしまいそうなときこそ、手を止める。
トラブル時には、すぐに動きたくなるものですが、むやみやたらに飛び込む前に、立ち止まることを習慣にしましょう。
----------
元日本IBMエグゼクティブ・プロジェクト・マネジャー。横浜国立大学大学院環境情報学府工学研究科修了。2002年に日本IBMにシステム・エンジニアとして入社。2017年より現職。著書に『複雑な問題が一瞬でシンプルになる2軸思考』『仕事が速い人は「見えないところ」で何をしているのか？』（以上、KADOKAWA）がある。
----------
（元日本IBMエグゼクティブ・プロジェクト・マネジャー 木部 智之）
