エンジニアからコンサルになるときのブレークスルーその４
こんにちは、水上裕介です。
今回は、ファクトの定義方法とその集め方についてコラムしたいと思います。
■ファクトとは何か
ファクト（事実）について考えてみます。まず、事実と意見は別物です。
意見は、主語が自分（ヒト）であり、自分の考えや思惑を整理したものと定義します。
一方で事実は、主語が自分以外（モノなど）であり、（時間経過を基準とした）ありのままの状態を表したものと定義します。
エンジニアをしていると、どうしてもシステム障害を経験するときがあります。
そのとき重要なのはファクト（事実）です。
ファクトは、然るべきヒトが判断（意見整理）をするために重要であり、システム障害発生時点ではエンジニアに意見は求められていません。ファクトに基づき、システム障害の根本原因が判明した後に意見を伝えることが重要です。
■エンジニアのファクトとは具体的に何か
エンジニア視点でのファクト（事実）はログに尽きます。
ログと言っても、各レイヤ（HTTPサーバ、アプリサーバ、DBサーバ）ごとのログ、ツールログ、作業ログなど多数あります。
すべてのファクトが集められれば理想（ツールログや作業ログはシステム障害時には不要）ですが、契約上などの問題で必要なログを絞り込んで集めなければならないケースもあります。
私の経験上、最初に集めるべきログは、システム障害を検知したレイヤのログです。
その後、自レイヤのログだけで根本原因が判明しない場合、隣接する各レイヤのログを収集します。
余談ですが、アプリログ出力ロジックでログを握りつぶしていたり、適切なログを出力していない現場も少なからず存在します。
エンジニアの責務としてログを正しく出力することは非常に重要です。
また、無用な大量のログを出力している現場もあります。
エラーケースを想定してロジックを組むと運用担当者がとても助かりますので、留意すべき点です。
■コンサルのファクトとは具体的に何か
さて、コンサルでのファクトはエンジニア視点とは異なります。
語弊を恐れずに言えば、「信頼できるヒトの発言や回答」がファクトになるということです。
政治力があるヒト、権威があるヒトの発言とも換言できます。
コンサルの関わる企業は大企業がほとんどで、関係者が多く「信頼できるヒト」を見つけるにも苦労するし、「信頼できるヒト」からファクトとなりうる発言を引き出すことも大変苦労する場合があります。
また、エンジニアのファクトとなるログはないことがほとんどです。
さて、ここまで論じてきて結局コンサルにとってのファクトとは何か？それは現場により異なるということです。
コンサルのミッションを達成するためにロジカルに説明するための起点として仮置きしたファクトを定義する。
具体的には、データ移行プロジェクトにおいて、複数のベンダをコントロールして推進ような場合、新旧システムのデータマッピングを一覧化した仮置きファクトを作り、それ（仮置きファクト）が合っているかを各ベンダに問い合わせる。そうやって地道にファクトを作り上げていくことが求められます。
■次回
最後までお読み頂きありがとうございます。
次回はファクトをベースにした効率的かつ正確なロジカルシンキング方法についてコラムしたいと思います。
前回までの記事は以下にあります。