論理的に考えるために「事実」と「感情」を分ける

ＩＴエンジニアは「考える」ことが仕事です。
「悩む」ことでも、ＩＴを駆使して「手を抜く」ことでもありません。

　いかにしてＩＴを用いて目の前の課題を解決するか

そのために日々知恵をしぼるのが私たちＩＴに携わる人間の仕事の在り方です。
そのため、論理的に考える習慣を身につけることはＩＴに携わる人間の登竜門といってもいいでしょう。

しかし、多くの人は思ったほど論理的ではありません。

ソフトウェア開発に携わる業界においても、せっかく論理の集大成であるプログラムなどに日常的に触れている割に

　「この課題をどう解決しますか？」

という質問に対して、

　「頑張ります」

と答えるエンジニアは少なくないのが実情です。これはまったく非論理的ですし、そのままほかでも同様の対応しかできないようでは大抵のソフトウェア開発プロジェクトで失敗を誘発してしまいかねません。

お客さまのもつ課題や問題、要望に対して『ＩＴ』という技術を駆使して解決してあげるのが私たちＩＴを生業とする仕事の本質であるにもかかわらず、ＩＴ的なモノの考え方が身についていないということに他ならないからです。

「頑張る」だけで、お客さまの要求を満たしてあげられるのであればそれでもいいのですが、現実はなかなかそうはいきません。ただ「頑張る」だけで解決できるのであればお客さま自身が自分たちでそうします。私たちに問い合わせが来た時点で「頑張る」以外の方法を求められているのだということを理解しましょう。

まずは、事実と感情（=意見）を分けることから始めてください。

もう一度言いますが、ＩＴエンジニアは知識労働者であり「考える」ことが仕事です。

さらに、私たちが扱うコンピュータはデジタルな回路で成り立っていて論理的な処理を行います。そもそも私たちの仕事は本質的に論理性の高い仕事なはずです。だからこそ論理的思考（ロジカルシンキング）を何らかの形で身につけるよう求められたことが必ずあったはずです。　

論理的に考えるとは？

論理とは何かと一言うと「原因」があって「結果」があるということです。

たとえば、作成したシステムやプログラムに何らかの問題（結果）があればそれは何らかのミス（原因）があったことを示しています。反対に、仕事がうまくできた（結果）のであれば何らか良い行動をした（原因）からと考えることができます。

もっとも単純な論理は、この原因と結果だけで表すことができます。

　手を叩いた → 音が鳴った

しかし、私たちの生活や仕事は、それほど単純ではありません。
一つの結果に至るには、様々な事柄が影響しているからです。

論理ピラミッド

たとえば、料理の場合で考えてみましょう。

良い材料を使って適切な大きさに材料を切って正しい割合で調味料を混ぜ、適度な時間の間加熱するといった複数のプロセスを経て料理ができます。ですから「おいしい料理ができた」という一つの結果に対して、原因は一つではありません。

さらに、「正しい割合で調味料を混ぜることができた」のは「レシピで分量を確認した」、「計量スプーンを使った」という他の原因の結果かもしれません。

実際の事象は、論理的に考えると図のような階層構造になっていきます。

これを論理ピラミッドと呼びます。

論理的思考を身につけるための近道は、この論理ピラミッドがきちんと書けるようになることです。

論理的問題解決のポイント

ＩＴエンジニアの仕事の中で、論理的思考が役に立つ場面はとても多岐にわたります。特に、問題解決のプロセスの中では活躍することが多いと思います。

また、スキルを向上させるために行う自己分析も論理的に行うことが必要です。

問題解決や自己分析を行うときには、

　「原因は一つとは限らない」

ということを常に念頭に置いておくといいでしょう。

正しい原因を導き出すためには、複数の原因を網羅的に漏れなくリストアップすることが重要だということです。つまり、きちんとした論理ピラミッドになるように体系的に考えていくことが大切なのです。

論理的問題解決の３つのステップ

とは言っても、なかなかうまく考えることは難しいようです。
うまくいかない原因は、単純に「なぜ？」とWhyを考えてしまうからです。

ですがこの方法だけでは、掘り下げ不足に陥りかねません。

そのため「なぜなぜ分析」で根本的原因を特定するのは容易ではありませんし、よほど慣れていないと大抵分析そのものが形骸化して一向に解決が進まなくなります。

ですから、次の３つを順番に考えることをオススメします。

　Ｗｈｅｒｅ：どこに問題があったのか？
　Ｗｈａｔ　：その問題は、何が原因で起こったのか？
　Ｈｏｗ　　：どうやって問題を解決するのか？

トラブルを改善するとき、バグの説明をするとき、プロジェクトで振り返るときなどにも、同じ手法を用います。たとえば、何かの作業でうまくいかなかった場合には、次のような順序で考えてみてください。

Where（作業段階のどこに問題があったのか？）

実施した行動やプロセスのどこに問題があったのかを考えます。
多くの場合には、問題となるプロセスは一つではありません。

たとえば、「文言を作ったが、品質が悪かった」という場合には、文書を作る過程を思い浮かべて、その過程のそれぞれの段階に問題がなかったのかを網羅的に考えることが大切です。通常のソフトウェア開発においては「混入工程」や「発見するべき工程」の特定がこれにあたります。

What（何がいけなかったのか？何が良かったのか？）

次に、問題があった各プロセスに対して、具体的にどのような行動が問題だったのかを考えます。つまり、原因となる行動を特定することをします。

この場合も、問題となる行動は一つではないかもしれません。
原因には、技術的な問題と、動機的な問題の２種類があります。

ただし、動機的な問題に原因の多くが偏る場合は、What（何が）よりも、Why（なぜそうしようと思ったのか）と問いただした方がいいかも知れません。

How（次は、どうするのか？）

Whatで考えた原因となる行動に対して、次はどのようにするのかを考えます。
具体的な再発防止まで考えられなければ、失敗や問題は解決したと言えません。

Howまで考えたがらないエンジニアが多いようですが、それでは未来永劫トラブルは減ることはありません。　

Whereを重視する

また、多くの人はWhereを飛ばしてしまう傾向にありますが、実はこの「Where」が一番大切なことをみなさんはご存じでしょうか。

Whereを考えないと、なかなか考えが深まらず、とても浅いものになってしまいます。
物事を一面的にしか捉えられず、本質的な改善に辿りつかないからです。

このときに、考えるヒントになるのはＰＤＣＡのステップです。

仕事は、理想的には計画(Plan)、実行(Do)、評価(Check)、是正(Action)の順になるはずです。ですから、このそれぞれのプロセスのうち正しく実施できていないものがなかったかを考えます。

次に、それぞれのプロセスを詳細に考えます。
つまり、どのように実施したかということを考えるということです。

たとえば、「文書を作ったが、品質が悪かった」という例では、次のようにWhereを考えていくことになります。

《計画》
　・文書を書き始める前に計画を立てたのか？
　・計画はどのように立てたのか？
　・先に調べておくべきことはなかったか？
　・文書の目的を理解して計画を立てたか？

《行動》
　・品質を意識して書いていたか？
　・どんな順番で書いたのか？
　・きちんと内容を網羅したのか？
　・根拠を持って書いたのか？
　・考えが足りなかったような部分がなかったか？

《評価》
　・文書を読み返してみたか？
　・チェックの仕方は適切だったか？

《是正》
　・チェックで見つかったことを、きちん改善したのか？
　・他にも同様の問題がないかを確認したか？

このように、Whereだけでもとてもたくさんの視点があります。

また、Howで対策を考えるときには「自分が実施できること」である必要があります。
対策として自分ができないものをリストアップしても意味がないからです。

うまくできていない人の特徴

ここで、もう一度論理的思考のポイントを整理しておきましょう。

　・結果には、必ず原因がある
　・原因は一つとは限らない
　・階層構造で物事を考える
　・問題解決では、Where、What、Howの順に考える
　・特にWhereを網羅的に考える
　・対策は、自分で実施できるものを考える

論理的に考えられていない人に見られる特徴として、

　「ばっさりと一つの原因だけを答える」
　「表面的な原因を取り除くことを対策とする」
　「事実とは違うものを原因として考える」

という３つの兆候を紹介しておきます。

「ばっさりと一つの原因だけを答える」という人は、網羅的に物事を考えられていない人、あるいは考えることができない人です。

たとえば、「料理がうまくできなかった」原因を聞くと「腕が悪かったから」と答えたりします。まさに一刀両断です。すると、対策は「腕を磨く」と大雑把になってしまいます。

「表面的な原因を取り除くことを対策とする」という人は、原因を深く掘り下げて考えることが苦手な人です。

たとえば、「料理が塩辛かった」という問題に対して「塩を入れすぎた」という原因をあげます。対策として「塩の量を適切にします」と答えます。一見すると正しそうなのですが、実は単に原因を裏返したにすぎません。そして「確実に自分で実施できる対策」ともなっていません。

実際には「なぜ塩の量が適切でなかったのか」をさらに掘り下げて考える必要があります。すると「計量スプーンを使って量らなかった」「計量スプーンがなかった」というようなより深い原因があるはずです。ここまで考えると、「計量スプーンを買ってくる」という『確実に自分で実施できる具体的な対策』にすることができます。

「事実とは違うものを原因として考える」という人は、気持ちや感情を原因として考えてしまうことが多いようです。場合によっては、原因に「言い訳」が並ぶこともあります。

たとえば「料理がうまくできなかった」ということの原因として、「初めてだったから」「気合が足らなかった」など、実際にあった事実とは無関係の個人的に思ったことを答えてしまいます。すると、対策は「何度も作ってみる」「次は頑張る」というようなアバウトなものになります。これを仕事で発言すると上司も顧客も呆れるしかなくなるわけです。

気持ちや感情を事実と区別する

この３つ目の例についてもう少し着目してみたいと思います。というのは、論理的思考を身につけるために最初にしなければならないことは、気持ちや感情と事実を分けて考えることだからです。

典型的な例を紹介しておきます。ある新入社員が、新人研修の課題が時間までに問に合わなかった原因として報告した内容です。

私の行動が遅いことで時間が足りなくなってしまいました。
行動が遅くなった原因は、次の通りです。

　①先が見通せておらず、計画に現実性が無かった
　②プログラムに丁寧さが足りなかった
　③必死さが足りない

この3点を改善することで、得られなかったものを取り返します。

みなさんは、これを見てどう思いますか？

報告の文章としては、一見するとよく書けているようにも見えるかもしれません。

しかし、先ほどの３つの兆候がはっきり出ています。

　・原因として「行動が遅いこと」とたった一つしか考えられていない
　・対策が、「この３点を改善すること」と、単なる原因の裏返しになっている
　・「丁寧さ」という気持ちを表す言葉を使っている
　・「必死さ」という感情的なところを原因としている

多分、報告を言いた本人は良い報告が書けたと思っていたでしょう。これが謝罪文なら「丁寧さ」や「必死さ」という気持ちや感情的なことを前に出しても良いかもしれません。また、次はきちんと改善すると言う「気持ち」を伝えることにも意味があるかもしれません。

しかし、ソフトウェア開発における原因の分析や再発の防止という観点では、もう少し掘り下げて考える必要があります。どんなことを考えればいいのかというと、

　「なぜ計画のときに、先が見通せなかったのか？」
　「現実性がない計画で進めてしまったのはなぜか？」
　「プログラムに丁寧さが足りなかったというのはどんな行動が足りなかったのか？」

という点です。
そうすると、たとえば

　「細かな仕事内容をきちんと確認しないまま計面を立てた」
　「プログラムを書いた後の試験が不足していた」

のように具体的な原因を考えることができます。
ここまで掘り下げて考えて、初めて自分で実施できる形にすることができるのです。

人間は、感情の生き物と言っても過言ではありません。
ですから、どうしても気持ちや感情が前面に出がちです。

しかし、自己分析や問題解決などの論理的に考える必要がある場面では、実際の行動などの「事実」に焦点を当てましょう。