ＩＴエンジニアが得意なはずの論理思考

いや、特異なはｚ…もとい得意なはずなんです。

え、そんなことないですか？おかしいなぁ。

「論理思考の技術」は、驚くほどエンジニアが仕事で使っている技法と似ていて、しばらく業務を進めていると、実はエンジニアが得意な考え方、やり方で殆ど説明が付くことに気付くはずです。

たとえば、次のような点です。

　・思考過程をビジュアル化する（考えを図解し、まとめあげる）
　・話し手と聞き手の間で、図を使って思考や情報を共有する
　・さまざまな可能性を網羅的に考え、仮説を立てて検証する
　・あらかじめ代案を用意しておく

これらはエンジニアが、設計、製造、テスト、またトラブルシューティングのときによく使う手法です。逆にこうした技法が使えていないエンジニアは、おそらくお客さまと打合せをする際に手間取って必要以上に時間をとったり、いざ問題が起きた際にお客さまに納得していただけなかったりします。

と言うか、そもそも『プログラム』およびプログラムを形作るために、処理の流れを定式化した『アルゴリズム』は論理思考の極致と言っても過言ではありません。アルゴリズムが組めるなら、論理思考が普通にできていても不思議ではないはずです。

まぁそれはともかく具体的にエンジニアの仕事に置き換えてみましょう。エンジニアは、

　プログラムのロジック
　データの流れ
　ネットワークのデザイン

など、本来目に見えないものを日常的に図解しています。フローチャートやＤＦＤ(Data Flow Diagram)、ＥＲ図(Entity Relationship Diagram)などさまざまなダイアグラムを使って、文章形式の仕様書では捉えにくい全体像を一覧性のある図でチェックしています。もちろん、UMLやSysMLと言ったいまや一般的なダイアグラムも同様です。

さらにお客さまやプロジェクトメンバー問で、図を使って情報の共有をスマートに行っています。文章だと読むのに時間がかかり、解釈の仕方によっては誤解が生じたりする可能性がありますが、図だと一目瞭然です。

この結果、より正確かつスピーディに相手と情報を共有できます。

論理思考の世界でもフローチャートやＤＦＤに代わってロジックツリーやマトリクスという図解ツールを使い、「思考過程をビジュアル化」したり、「図を使って思考や情報を共有」しています。図の形状こそ異なりますが、同じようなアプローチ方法なので違和感なく思考に取り入れることができるはずです。

またシステム設計をするときには、さまざまな可能性を想定しながら設計書に組み込んでいきます。プログラミングやデバッグ時は、トラブルを想定し、仮説を立て、例外処理を組み込みます。テスト時にはさまざまなシチュエーション、さまざまな可能性を想定してテストしていきます。本番運用が始まり、フィールドエンジニアがトラブルシューティングをするときには、仮説と検証を繰り返し、解決に導きます。

いずれも、エンジニアの得意領域でなければいけません。

論理思考の世界ではこのような進め方のことを「仮説アプローチ」と呼んでいます。すでにエンジニアになっているみなさんは、ＩＴに関わる仕事のあらゆる場面で、論理的なアプローチを駆使して問題解決しているはずです。

他にも、プログラムを書くときに、条件分岐によって処理を変更したい場合などは、if-else句やswitch-case句の処理を組み込み、１つのモジュールで複数の状況に対応させていると思います。

ＯＳやデータベース、ネットワーク管理のコマンドなども、オプションスイッチを使い分けることにより、さまざまな付加機能を選択して実行することができますよね。

論理思考の世界では、これを「オプション思考」と呼んでいます。

あらかじめ正しくあるべきルートのほかに、いかなる状況にも耐えられるよう代案を用意しておき、状況の変化に応じて思考を柔軟に切り替える手法のことです。これも多くのエンジニアが無意識のうちに使っている論理思考の一種です。

システムの仕事だけでなく、日常のコミュニケーションの中で相手の反応に一喜一憂するのではなく、あらかじめ相手の出方を想定し代案を準備しておけば、急な要望にもあわてずに済みます。また相手に主導権を渡さずに、自分のペースで事を進めることができるでしょう。

　
私たちは新しいＩＴ技術を身につけるとき、書籍を読んだり、セミナーに参加して知識を習得することもあると思います。ですが、エンジニアの中にはマニュアルや教科書的な知識が現場では役に立たず、実践で体得した知識、経験こそが、実践的な戦力として「使える」ものだと気づいている人も多いと思います。

思考技術の世界も同じです。

せっかくの思考技術を書籍や講習会で学んでも、「なかなかビジネスの現場で活かせない」という声をよく聞きます。一読して「知っている」という状態だけでは、仕事の現場や日常生活ですぐ活かすことはできません。「使える」状態にするには、実際に手を動かして、自らの思考に習慣性を持たせることが不可欠です。

１回でわかった気にならず、「癖になったぞ」と実感するまで何回でも描いてみてください。

もし、身近に仲間がいれば、ちょっとした時間を使って描いた図を見せあったり、印象に残るコメントをするなどして、擦り込みを促進する努力や工夫をすればより効果的です。いったん擦り込みが完了すれば、子供の頃に身についた癖と同じように、めったなことでは忘れません。そうなれば、その思考技術は一生使えるのです。

そして、誰でも陥る危険な状態が「思考の停止」です。

普通の人は解決策が出せたら、ほかの解決策を考えるのをやめてしまう傾向にあります。日本の義務教育では、問題に対して解答が１つしかないパターンが圧倒的に多く、とにかく１つ解答を見つけたらさっさと次の問題へ進むというやり方が擦り込まれてしまっているからです。

このようなやり方は、短時間でテストに合格するためだけの試験勉強には最も効率的かもしれませんが、未知の分野を開拓したり、今までにないビジネスモデルを考えようとする場合、それが唯一の答えであるという「思い込み」や「思考停止」を助長することになってしまいます。

おそらく殆どのビジネスシーンにおいて致命傷になりかねません。

たしかに社会人になると日々仕事に追われてしまうかもしれませんし、毎日毎日が目まぐるしく忙しい日々を送っているかもしれませんが、あるテーマに関して多少時間をかけて吟味するくらいの時間は、皆さんの裁量で見つけられるはずです。

たとえば、システム構築の案を出すとき、

　誰が利用するのか
　どのような環境下で利用されるのか

など、立場や視点を変えて考え、安易に思考停止しない習慣を意識的につけるようにしましょう。そう言う思考を育んでいかないと、「責任ある仕事」、「大きな仕事」を任されるようにはなりません。だって、思考を停止してしまった人と言うのは、仮に任せたとしても、きちんと考えて、最適解を見つけてくれはしないってことですもんね。