どんなビジネスマンでも使える「できるエンジニアの思考術」
アイデアをものとして具現化するエンジニア。彼らの中には、素晴らしいひらめきとセンスを持った人たちがいます。
今回の記事では、私が会ったエンジニア達が行っていた思考の中で、日常的に使えるなと思った思考術を紹介したいと思います。
エンジニアだけでなく、非エンジニアなビジネスパーソンも応用できる思考術になっていると思いますので、皆さんの参考になれば幸いです。
さて、今回紹介するのは、次の3つです。
・モデル化する
複雑な現象を理解して、問題解決をしやすくするための思考術。
・バッサリ切り捨てる
何かの問題を解決するとき、できるだけ早く少ない労力で解決策を見出す思考術。
・結果を描き、次に、動く
数字を使って、分析、コミュニケーション、アクションを行うための思考術。
さて、初めに「モデル化する」について紹介します。
これはものごとをできるだけシンプルに、しかし深く考え、本質を見抜くために使用する思考術です。（できるエンジニアはものごとを考えるときに、初めにモデル化を行っているんだとか。。。）
モデル化とは、現象を構築する要素や要素同士の関係性を明確化して、現象の振る舞いを把握できるようにすることです。
世の中には、さまざまな現象やシステムがあります。日常的に接している現象やシステム、仕事などで接している現象やシステム。いくつかのものは、理解しやすいかもしれませんが、多くのものは普通に考えていると何が起こっているのか把握するのは難しいものです。
普通に見た現象のイメージを図1(上)に描いてみました（読者の方は、会社で問題が発生した時のことを思い浮かべてみてください）。
ゴチャゴチャしていて、何が何だかわかりません。
わかることといえば、「色々なことが絡み合っていそうだ」ということだけです。
これでは、問題解決をするのは難しそうです。勘と経験で動いてみたら、解決できるかもしれませんが、うまくいくかはわかりません。
そんな時、できるエンジニアは現象をモデル化、つまり「現象を構築する要素や要素同士の関係性を明確化して、現象の振る舞いを把握できるようにする」ということをします。図1の普通にみた現象をモデル化すると、例えば、図1(下)のようになります。かなりシンプルになりました。このモデルを少し詳しくみてみましょう。
現象を構築する要素としては、インプット、ノイズ、プロセス、アウトプットの4つがあります。インプットとは、現象やシステムが動くための入力となるものです。ビジネスだったら、ヒト、モノ、カネ、情報などが考えられますし、調理家電であれば、電気や材料などがインプットとなります。ダイエットの目標で、あと3ヶ月で5kg痩せるなんていうのもインプットです。
プロセスとは、インプットやノイズを処理する行動や工程などのことを言います。ビジネスであれば、業務、調理家電であれば、熱や圧力をかける、材料を混ぜるといったことがプロセスとなります。ダイエットなら、脂肪分が落ちるように「しっかりと肉を焼く」といったことがプロセスになるでしょう。図1では、一つのプロセスしか描かれていませんが、複数のプロセスが並行したり、順番に並んだりして、大きなプロセスとなっていることもあります。
アウトプットは、インプットやノイズがプロセスによって処理された後に出てきた結果のことです。これまでの例で言えば、売上が上がった、美味しい料理が作れた、5kg痩せたというのがアウトプットです。
最後に、ノイズとは、インプットと同時プロセスに入っていき、インプットやプロセスを勝手に変えてしまうだけでなく、それ自体はコントロールできず、ランダムに変わってしまうものと思ってください。
ダイエット中のことを考えてみてください。インプットは、3ヶ月で5kg痩せるだったとしましょう。そのためのプロセスとして、甘いものは食べないというものがあったとします。一方で、テレビに映る美味しいものや街に出歩いた時の美味しい匂いなどは、不要な食欲を喚起して、気が緩めば甘いものを食べてしまうかもしれません。また、これらは、5kg痩せるというインプットを歪めて、やっぱり3kgでいいやと思わせてくるかもしれません。この時、美味しいものや香りがノイズです。インプットやプロセスを歪めているし、いつテレビに映るか、どこで香りがするかは、自分でコントロールができない上に、内容はランダムに変わっていくからです。
次に、要素同士の関係性をみてみましょう。実は、関係性の説明の半分は、上でしてしまっています。それは、インプットとノイズがプロセスに入っていき、プロセスに処理された結果、アウトプットが出てくるというものです。
残り半分は、図中に転線で書かれている部分です。これはフィードバックと言います。フィードバックは、アウトプットがインプットやノイズ、プロセスに影響を与える関係性です。
ダイエットで考えてみましょう。初めの1ヶ月間に気合を入れて頑張った結果、アウトプットとして、3kgの減量を達成したとします。しかし、同時に達成感から、気が緩むというアウトプットもあった様です。（あるあるですね。。。）
達成感と気の緩みによって、もういいか。。。という気持ちになり、5kgというインプットが3kgになる可能性があります。また、今まで美味しいものを意識的に見ない様にしていても、達成感からデパ地下に行ってしまうかもしれません。脂肪が落ちないちょうどいい加減でお肉を食べるというようにプロセスを変更してしまうかもしれません。逆に、3kgの減量の達成で、更なるやる気がアウトプットとしてあった場合は、ついでに筋トレを始めてみたりなど、全体にポジティブな影響を与えるかもしません。
このようにモデル化をすると、現象やシステムがシンプルに捉えられて、振る舞いを把握したり、予測することができる様になります。ぜひ、日常的に現象やシステムをモデル化して練習してみるのが良いでしょう。練習するといっても、慣れないと難しい部分もあると思うので、図2にいくつかの例をあげておきました。できるエンジニアに聞いたコツは、興味のある要素に着目したり、いらない要素を省いたりすることだそうです。
例えば、犬を高さh、幅w、長さl、密度d、質量mの直方体とモデル化することができます。密度dがわかれば、筋肉質の犬なのか、それとも、運動不足で脂肪が溜まっているのか、なんてことがわかるかもしれません。かわいらしい犬を直方体としてみるのは気が引ける部分もありますが、かわいらしさや身体の細部に注目する必要がなければ直方体で良いのです。
また、料理が好きじゃないけれども、家に帰ってきてどうしてもやらないといけないから効率化したいと考えている人がいるかもしれません。料理は、入力、出力、処理やフローとしてモデル化できます。すると、時間があるときに、事前にやっておけるところが発見できたり、並列して行える部分を整理したりなど効率化すべき点を考えられるかもしれません。このモデルでも、料理の楽しさ、味などは出てきません。だけれども、それで十分なのです。むしろ、このモデルは、料理の入力（材料）やフロー（切ったり、煮たり）や出力（食べたいもの）を明確にすることの方が重要だったりします。
他にも図2にはいくつかのモデル化の例をあげたので、何に注目して、何をいらない要素として省いたのか考えてみると練習になるかもしれません。
さらに、できるエンジニアが言うには、モデル化の練習をして、最終的に目指すのは、図3に示す出来事・パターン・構造・原理・原則を自分の頭で導き出せる状態だそうです。そうすると、目に見えて観察しやすい領域とその背後にある隠れた領域の両方を理解することができるからだそうです。
図3では、みんなが目で見て確認できる問題は「観察した出来事」に該当します。また、出現パターンとは、ある時期に特定の問題が頻発するとか、ある部分に欠陥があると別のどこかで問題が起こるといった何かが起きる時の傾向のことです。例えば、「お昼ごはんの後には、眠くなってしまい午後の仕事の効率が悪くなる」ということを経験したことはないでしょうか？「お昼ごはんの後には、眠くなってしまい」と言うのが、「午後の仕事の効率が悪くなる」という出来事の出現パターンです。（図4参照）
出現パターンは、背後に隠れている構造から作り出されています。
「お昼ごはんの後に、眠くなってしまう」のは、食べ過ぎや短時間での食事をする必要があるということが考えられます。これは理由や原因と呼ばれるものですが、構造とは、この原因や理由を作り出しているものです。例えば、お昼休憩以外ものを食べられない環境のため、ついつい食べてしまうといったことや休憩時間が短いといったことがあるかもしれません。さらに、眠気で効率が落ちる⇨ストレスが溜まる⇨食べることでストレスを解消する⇨眠気で効率が落ちるというループにハマっているという構造も考えられます。
原理・原則は、物理学や化学など自然現象を支配しているものや価値観や固定観念など構造を作り出すものです。眠気の場合は、炭水化物を摂取したことによる血糖値の急激な上昇や原理・原則の一つとなるでしょう。また、食事に関して言えば、昼休憩以外では食べ物を食べられないという思い込みや環境は価値観や固定観念と言えるので原理・原則に当てはまるでしょう。
観察された表面的な出来事に対して直接手を打つのではなく、構造や原理・原則に対して打ち手を考えることが、エンジニアリングです。午後の仕事の効率低下も、ご飯の量を減らし、飲む水の量を増やして満腹感を得るといったことで、改善できるかもしれませんね。これはコーヒーを飲むという場当たり的な改善策とは、アプローチしている層が異なる上に、本質的に近い部分の改善になるはずです。
さて、次は「バッサリ切り捨てる」です。
冒頭で述べた通り、これは何かの問題を解決するとき、できるだけ早く少ない労力で解決策を見出す思考術です。
仕事が早いできるエンジニアは、問題に関わる要素をモデル化で見出した後、要素がコントロールしやすさ、そして問題への寄与率の高さ（問題を起こしている可能性の高さ）でマッピングを行います。（実際にマッピングを書いているわけではありませんが、どうやら頭の中にマッピングを行なっている様です。）
すると、要素ごとに次のような領域に分かれます(図5参照)。
ここからやる領域：要素をコントロールしやすさが高く、問題への寄与率が高い領域。図中の赤で示す領域。つまり、要素がコントロールしやすくて、問題への寄与率も高いなら、その要素をチューニングするだけなので、それで問題は解決するということです。もしこれで解決しない場合は、次にやる領域に進みます。
次にやる領域：これは、コントロールしやすいけれども、問題への寄与率は「ここからやる領域」に比べて、低いという領域です。「ここからやる領域」のみで解決できなかった場合に、この領域に手をつけて、複数の打ち手で問題解決を図ろうという訳です。（しっかりとモデル化を行えれば、問題の原因分析を行うことと同義なので、この領域までで問題解決ができるはずだ。とできるエンジニアは言っていました。）しかし、それでも解決しない場合があるそうです。その場合、モデルに見落とした要素があるため、モデルを改良するか、「作戦を考えておく領域」の要素に手をつけます。
作戦を考えておく領域：ここは、問題への寄与率が低くなさそうな雰囲気ですが、あまりコントロールしやすそうではないなという領域です。コントロールしにくいので厄介な領域ですが、アイデアをひらめいて、コントロールしやすくすることができれば、問題解決への突破口となる可能性があります。上2つの領域は、比較的手を動かしやすい部分なので、それをやっている間に、もしこの領域に手をつける必要がある場合のアイデアを考えておくのだそうです。
ほぼ無視領域：問題への寄与率が低い領域です。「ほぼ」無視する領域で、この部分に対して何かをアクショすることはしないそうです。ただし、「ほぼ」という部分が重要で、何かあった時のために、無視していることを自分でしっかり認識しておく必要があります。
ほぼ無視領域を、「ほぼ」無視することによって、考えたり、アクションを起こす領域は、全体の3分の2 (67%位)になり、少ない労力で解決まで持っていきます。また、事前にどこがダメなら、次にここをやるという流れがあるので、周囲との連携もすやすいという特徴もあります。
最後のトピックは「結果を描き、次に、動く」です。
これは、数字を使って、分析、コミュニケーション、アクションを行うための思考術で、別名「モデルから解決に必要なデータを取りに行く戦法」とも言います。
これには、反対に位置する思考があって、それは「とりあえず、これやって、こんな感じの結果出ました戦法」があります。
まずは、できるエンジニアの思考術がわかりやすいように、普通の思考（とりあえず、これやって、こんな感じの結果出ました戦法）を解説していきます(図6参照)。
エンジニアに限らず、ビジネスでは、データを使って問題解決をすることが多いと思います。その一連のプロセスの要素は、「実験やリサーチなどデータを集める作業」、「得られたデータを分析する作業」、「データをわかりやすい様にグラフ化する作業」から成り立っていると思います。普通は、この順番で作業を行い、必要があれば何度か繰り返し、その結果を報告するという流れを取ることが多いでしょう。このやり方は、何かをやった感がありますが、報告の場で意思決定や次のアクションを促しにくいです。読者の中にも、せっかく業務の報告したのに、「なんでこのデータとったんだっけ？」とか「これだけではなんとも言えないね。」とか「で、結局次は何をするのがいいんだっけ？」と渋い顔で言われたことがある方がいるかもしれません。そして、運が良ければ、何回かのループの後、データの海に溺れなければ、何か意味のある結果に漂着したかもしれません。
一方で、できるエンジニアはこれとは真逆のやり方をします。
つまり、分析をして、グラフを作って、最後に実験やリサーチを行うのです。
データがないのにどうやって分析して、グラフを作るんだと思うでしょう。ここで登場するのがモデルです。
モデルを構築すると、問題を支配する原理原則は何か、どのような構造になっているかが掴めます。すると、問題の出現パターンがどのようなものか分析できるようになります。つまり、ある問題が起こるならば、モデルの原理・原則や構造から考えれると問題発生の原因は、パターンA、B、C、D・・・のどれかになるなといったことが考えられるようになる訳です。
ここまで来たら、データを集めに行っても良いと思うかもしれませんが、まだ一歩踏みとどまり、グラフ化を行います。データがないのに、グラフなんて作れないじゃないかと思うかもしれませんが、違います。明確な数字は出せないかもしれませんが、どのようなデータを、どの様なグラフにしたら、どの様な違いになるかというくらいのものは、「描ける」のです(図7参照)。イメージを伝えるとすれば、原因がパターンA、Bなら〇〇のデータを□□グラフで表すと、△△になるが、C、D、・・・なら××になるのをペンで描いてみるのです。
最後に実験やリサーチなどデータ取得する作業を行います。
データを取ったら、数字をごちゃごちゃいじる必要はありません。事前に描いたグラフと同じものを作れば良いのです。グラフが同じだった場合は、問題解決に近づきました。いくつかアクションは必要になりますが、構造や原理・原則からどの様な解決策がありそうか、「バッサリ切り捨てる」書いたように解決していけるはずです。もし、データから作ったグラフが事前に描いたグラフと異なっていても問題ありません。モデルで省いた要素があれば修正したり、別のモデルを考えたりできるからです。
ここまでの流れに慣れないうちは、一人でやらずにチームメンバーと一緒にやるのが良いでしょう。上手くグラフが一致してくれた時には、チームの考えるモデルが間違っているわけではなさそうだという確認ができ、チームの意思決定やアクションにつなげることができます。間違っていた時には、チーム全体の認識をアップデートした上でディスカッションができるでしょう。また、必ず(モデルや)グラフが登場するため、自然と数字を使ったコミュニケーションになっているはずです。
さて、今回の記事では、3つの思考術を紹介しました。
・モデル化する
複雑な現象を理解して、問題解決をしやすくするための思考術。
・バッサリ切り捨てる
何かの問題を解決するとき、できるだけ早く少ない労力で解決策を見出す思考術。
・データとビジュアルを「使う」
数字を使って、分析、コミュニケーション、アクションを行うための思考術。
ここまで読んでくださった読者の方。ありがとうございました。
皆様の参考になれば、幸いです。
この記事が参加している募集
この記事が気に入ったらサポートをしてみませんか？