ITエンジニアのWhy型思考とHow型思考
aushepherd3
ITエンジニアには2つの特徴的な思考パターンが存在します。
一つがWhy型思考、もう一つがHow型思考です。
どちらの思考パターンにも特長と力を発揮する場面があります。意識的に両者を使い分けることができれば、エンジニアとしてより大きな成果を上げることができます。
このコラムでは、そのような2つの思考パターン、Why型思考とHow型思考について解説します。
Why型思考・How型思考の特徴
思考の違いの具体例
Why型思考とHow型思考の違いを理解頂くためには、まずはプロジェクト中または保守中を想定し、担当しているエンジニアとお客様との次の会話文を見て下さい。
このやり取りを見て、担当エンジニア側の回答にどのような違和感を抱いたでしょうか。
How型の思考は「どうやって」を重視する
たとえば、
- 技術的には可能と言わない方が良い
- 納期の確認をしていない
- 検証に必要な時間目安を伝えていない
このような違和感を抱いた方は「How型」の思考パターンが強いと言えます。
Why型の思考は「なぜなのか」を重視する
それとは別に、
- その機能がなぜ必要なのか確認していない
- どういう背景でその要望が出てきたのか聞いていない
このような違和感を抱いた方は「Why型」の思考パターンが強いと言えます。
長期的な成果に結びつく思考法とは
How型の思考パターンは「どうやって実現するか」という方法を重視し、Why型の思考パターンは「なぜなのか」という理由・背景を重視します。
では、どちらの思考形態の方が長期的な成果が出せるでしょうか？
How型思考のメリット
How型思考のメリットは迅速に回答を導き出せるところにあります。
従って、障害発生時などの緊急対応場面では大きな力を発揮するでしょう。
Why型思考のメリット
一方でWhy型思考は、相手の実現したいあるべき姿（To-Be）と現状（As-Is）から課題を整理し、解決策を導き出す思考です。
そのため、最も効果的な解決策を生み出す可能性が高くなるというメリットがあります。緊急性を要さない通常時には大きな力を発揮します。
より良い解決策にたどり着くのは”Why”に着目する思考
先ほどのお客様とのやり取りを図解するとこのようになります。
例文にあったお客様のコメントは、解決策である機能の追加にフォーカスをしていました。
How型思考はこの解決策に着目し、より具体的な実行方法（How）を展開しようとします。
Why型思考は解決策の手前にある課題（Why）に着目し、より良い解決策がないか模索しようとします。
エンジニア経験者であれば、お客様が言い出した機能（解決策）がそもそも解決策として良い案ではなかったという経験をお持ちかもしれません。
エンジニア以外の方でも、例えば上司から頼まれた仕事がその背景を確認すると、あまり得策ではなく、別の仕事をした方が良いと思った（または伝えた）経験を持っている方も少なからずいると思います。
たとえ、お客様であっても、上司であっても、背景を確認せずに解決策をただ実行してしまうのは、長期的な成果をあげる上で常に最善とは限らないと言えます。
ITプロジェクトであれば、お客様の要望に従ってシステムを構築したのに、結果的に使われない、現場から不評、そもそも使用に耐えない、メンテナンスコストがかかる、などの失敗事例もたびたび耳にします。
これはお客様の提示した解決策だけに着眼してしまうと起きてしまうプロジェクトの失敗パターンです。
このようにWhy型思考はエンジニアが長期で成果を出すために必須の思考パターンと言えます。
ITエンジニアに見られる思考の偏り
ITエンジニアの傾向は8割程度がHow型
では実際にエンジニアの中で、Why型思考を有している人はどれくらいいるでしょうか。
弊社がトレーニングの中で上記例のエンジニアとお客様のやりとりに関する質問をすると、How型思考の回答が8割、Why型思考の回答が2割程度返ってきます。
企業によって割合は多少前後しますが、エンジニアの方の主要な思考パターンはHow型と言えるでしょう。
この結果は恐らく、エンジニアにはモノ作りが好きな人が多いと言うのも背景にあると思います。
難しい機能であっても、新しい技術や独自の工夫を加えて構築してみたいという意欲が、「なぜ」よりも「どうやって」に目を向けさせてしまうのだと考えられます。
経験がもたらすHow型の危うい側面
また、経験年数が増えてくると、Why型思考だったエンジニアがHow型思考になってしまうケースもあります。
これは、過去の経験から解決策の引き出しが増えている分、「Aの場合はB」「Cの場合はD」と問いと答えが結びついているからです。
こうなると、お客様から「＊＊の機能は追加できるか？」と聞かれると、即座に「AとBの2パターンがあり…」と回答できるようになるのです。
この経験の引き出し自体はとても良いことだと思います。経験豊富なメンバーというのは頼りがいがあり、難しいプロジェクトに一人いるだけで成功確率が高くなるものです。
しかし、いつの間にか問いと回答がセットになり、仕事を「処理する」ようになってしまうと危険です。
本当の課題は別のところにあるにも関わらず、答えだけを出してしまい、最終的に良い結果を生まないという場合があるからです。
ベテランにも使い分けるセンスは求められる
これはもっと身近な例で言うと、同僚から相談を受けた時にも当てはまります。
例えば、
「いまのプロジェクトで＊＊を実装してみたいんだけど、どうやったら良い？」
「それなら＊＊をしてみるといいよ」
このような一問一答が当てはまります。
一見同僚からすると、即座に答えが出てきて良い相談相手と言えますが、実はその実装を行うよりも別の解決策の方が適切な場合も往々にしてあります。
従って経験豊富な人であれば、答えをいま出すべきか、立ち止まって背景まで確認すべきか都度判断をする必要があるでしょう。
毎回、質問をするたびに背景を聞かれてしまっては相談する側も徐々に嫌気が指してしまうと思います。
ですから、Why型思考で背景を聞くべき案件かどうかをかぎ分けるセンスもベテランには求められていると言えるでしょう。
それでは、ここまで見てきたWhy型思考をどのように身につけたら良いでしょうか。
それには「トレーニング」と「習慣化」の2つが鍵になります。
Why型思考の身につけ方～トレーニング～
「問題発見力」を徹底的に磨く
まずトレーニングでは、「問題発見力」を徹底的に磨くことが大切です。
問題発見とは結局は「あるべき姿」と「現状」のギャップから「解決するべき課題」を抽出することです。
普段何気なく行っている業務であっても、全てはあるべき姿を実現するための手段のはずです。
しかし、業務に邁進しているとそのことを忘れてしまいがちなため、トレーニングでは改めて問題発見を徹底的に見直します。
これは全ての業界・職種に言えることですが、人は問題そのものよりも解決策に目が行きがちです。
ですので、解決策から離れて問題そのものを見つめ直す機会をトレーニングで提供することが大切です。
よくある問題発見の失敗事例は4つに大別できます。
失敗事例1：あるべき姿がない
一つは「あるべき姿がない」または「あるべき姿が曖昧」なケースです。
関係者が同じ方向性を共有していなかったり、上役にリーダーシップが欠如していたりする場合に起きる悲劇です。
失敗事例2：現状理解が足りていない
二つ目は「現状理解が足りない」ケースです。
現場にいると現状は一番よく理解できていると思ってしまいがちです。しかし、普段から見ているからこそ、客観的に見たり、データで多角的に確認したりすることができていないというケースもままあります。むしろ現状をきちんと理解できていれば、多くの企業で起こる不祥事や時代遅れによる業績悪化は防げるとも言えます。それくらい現状理解は難しいのです。
失敗事例3：課題の深堀りが足りていない
三つめは「課題の深堀が足りない」ケースです。
あるべき姿と現状を比較した結果をそのまま課題として捉えることは多くないと思いますが、それでも課題の深堀が足りないことは往々にして起こりえます。
例えば、今月の販売目標は1,000万円、現状は700万円で300万円不足している。300万円の不足は課題ではありませんが、新人の売上が未達なのが課題である、と一個掘り下げるだけで課題の深堀を終了してしまうケースは多々あります。 「なぜを５回繰り返す」と言われる通り、なぜ新人が目標未達なのかを掘り下げることで、本当の課題を見つけることができます。
失敗事例4：解決策ありきでの課題設定
最後の四つ目は「解決策ありきでの課題設定」です。
既に思いついている解決策や実行できる解決策から逆算して課題を設定してしまうことです。
そんなこと起こりえるかと思われるかもしれませんが、多くの企業で「AIの業務活用」「クラウドファースト」のように解決策が先に定義されてしまい、それを追いかける形で業務の課題が整理されるケースがあります。 この流れの全てが間違っている訳ではありませんが、解決策から逆算することで実行するためのロジックづくりに終始してしまうというのは、組織人として経験したことがある人は多いのではないでしょうか。
このようにトレーニングでは問題発見の型を失敗事例も踏まえて、しっかりと分析し、内省していくステップが必要です。
Why型思考の身につけ方～習慣化～
次に習慣化です。
いくらトレーニングで問題発見の手法を叩き込んだとしても習慣化されなければ、ただの知識で終わってしまいます。
習慣化の方法としては上司の協力が必要なものと個人でできるものがあります。
上司に目的としているあるべき姿を聞く
上司の協力が必要なものとしては、普段の業務報告の場や1on1などの機会に、現在取り組んでいる業務が「何をあるべき姿として設定しているのか」「何が本質的な課題なのか」を日常的に聞くことです。
強制的に問題発見のスイッチが入りますので、実行する前に問題を発見する習慣をつけることができます。
日常生活で日々の問題を疑う
また、個人でできることは日常生活で日々“問題”を疑うことです。
例えば、ニュースで少子高齢化“問題”が取り上げられたとしたら、本当に問題なのか、何をあるべき姿として設定しているのか考えることで、問題に対する感性を養うことができます。
先の例で言えば、少子高齢化は問題ではなく事実です。仮に多子若年化をあるべき姿と置いていれば問題として設定できますが、あるべき姿を何に置くかによって問題は変わってきます。世界規模で見れば、人口増加は持続可能性という点で問題としてみることができます。そうなると、日本は先んじて持続可能な社会人口を目指しているという見方も可能です。
このように日々接しているニュースを一つとっても、問題発見の目を養うことができます。
まとめ
ここまで見てきた通り、Why型思考はソフトスキルの中でも最も重要なスキルであり、プロジェクトマネージャーやプロジェクトリーダーには必須のスキルと言えます。
（営業や他の職種でも同様のことが言えますが、特にHow型に傾きがちなエンジニアの方にとっては特に意識するべきスキルと言えます）
こちらのコラムで記載した内容を参考に、問題発見力を鍛えて更に大きな成果をあげて頂ければ幸いです。
EdWorksでは、ITエンジニア向けにWhy型思考を身につけるトレーニングプログラムを提供しています。
本プログラムではトレーニングだけではなく、上司のサポートも含めた業務に紐づいた習慣化の支援も2～3か月の期間で行っております。
関連するコラム
