「分けて考える」という原理・原則

ある一定レベルの仕事の成果を安定して出すには、「原理・原則」が欠かせない。「型」や「スタイル」と言ってもいい。トラブルシューティングでも営業活動でも、個々の状況に応じて臨機応変に対処しなければならないのはもちろんだ。しかし、どんな場合にも共通の、自分の行動の原理・原則となる型を持っていれば、判断に迷ったときのよりどころとなり、仕事の質が安定する。原理・原則はひとそれぞれだ。私の場合は、「見える化」「分けて考える」「仮説と検証」の3つを基本としている。

原理・原則を意識するようになったのは、10年以上前に受講した坂本善博氏（株式会社資産工学研究所・代表取締役）のセミナーだ。坂本氏が独自に開発したのが「原理・原則アプローチ」。坂本氏は、様々なノウハウを原理・原則としてワープロで書き留め、システム手帳に綴じ込んでいた。原理・原則の書き方さえ、1行何文字で行間はどのくらいに設定すると原理・原則化しているのが印象的だった。

そのセミナーの収穫はもうひとつ。坂本氏が原理・原則のひとつとして挙げた「分けて考えること」だ。これは非常に幅広い場面で使える、役に立つ思考の型だということがわかってきた。「見える化」や「仮説と検証」は、「分けて考える」ことを補佐する原理・原則といってもいいくらい、「分けて考えること」は重要だ。

様々なノイズが混じって何が何だかわからない状態から、情報が理路整然と整理されていて次のアクションが明確になっている状態にする。極論すれば、これが学問やビジネスなど、人間の頭脳活動の基本である。それには何らかの視点を導入して、それを評価軸にして類似しているものと異質なものを「分けて考える」意識が欠かせない。

したがって「分けて考える」ことは、誰もが日常的にやっているし、あまり意識していないだろう。たとえば、大きなプロジェクトを小さな作業項目に「分ける」ことは、プロジェクトマネージャなら必ずやっている。データ分析も「分けて考える」ことだ。収集した雑多なデータを、ある視点で「切り分けて」、何らかの意味を見いだすのが分析という行為だ。

サポートエンジニアのトラブルシューティングを「障害切り分け」と呼ぶことがあるように、これも「分けて考える」行為である。ログやトレースを様々な視点で読み込んで、問題箇所を絞り込んでいく。この過程で、様々な「分けて考える」が行われている。普段から出力されているメッセージとトラブル時にだけ見られるメッセージを「分ける」。障害の一次原因によるメッセージと、それに付随したり波及したりして起こったイベントのメッセージを「分ける」。重要なトラブルとそうでないものを「分けて考えて」優先度を付ける。

「分けて考える」ためには、分けるべきデータや情報が必要だ。それを集める作業が、最近ビジネス雑誌や仕事術の本を賑わせている「見える化」というもうひとつの原理・原則だ。トラブルシューティングでは、ログやトレースの収集がこれに当たるし、マーケティングでは市場動向や消費者調査がそうだ。しかし、「見える化」だけを追求しても、それだけでは片手落ちだ。あくまで「分けて考える」ための手段に過ぎない。油断すると、手段は目的化しやすい。見える化することが目的になってしまわないように注意する必要がある。本来やるべきは、「分けて考えて」次のアクションを明確にすることだ。

さて次のアクションを明確にするためには、もうひとつの原理・原則「仮説と検証」が役に立つ。「分けて考える」ときに使った視点や、そこから導き出した結果は、この時点ではまだ仮説にしか過ぎない。それを検証し、修正したり補強したりする必要がある。トラブルシューティングでは、ログ解析からある障害原因を推測するのが、仮説を立てることに相当する。LANケーブルに問題があるのではないかという仮説を立て、それを検証するために新品と交換してみるというのもそうだ。再現テストを実施したり、暫定修正モジュールを作ってテストしてみたりすることもあるだろう。「仮説と検証」の結果、もう一度「見える化」や「分けて考える」に戻り、このサイクルを何度も回すことも多い。

「見える化」「分けて考える」「仮説と検証」は、別に新しい概念ではない。それぞれ、いろいろなところで言い習わされている。意識するしないにかかわらず、誰もが自然とやっていることでもある。しかし、それを意識して普段の行動に組み入れることで、仕事の質は必ず安定するはずだ。状況が十分見えているか、分けて考える視点は適当か、仮説が十分に検証できているかなど、普段から心がけるようにしたい。