概要

エンジニアが解決する必要のある仕事上の問題は、当初からはっきり与えられていることは少ない。
このため、「与えられた問題をどうやって解いたらいいかを考える」学力テストのような方法論で解決を試みても、実際にはなかなか解決することができない。

本記事では、書籍の内容を引用した上で、例題を通して、その実践例を示す。

情報を生み出す考え方

学力テストの場合は、与えられた問題を読み込むと、どこかに解決への鍵がある。その鍵を発見することができれば、そこから解答を自分1人の力で導くことができる。私たちは、これまでの学習過程で、無意識のうちに問題をそのような方法で解く習慣が身についてきてしまっている。

しかし、エンジニアが直面する仕事上の問題の場合、当初の情報内に解決への鍵が必ずしも存在しているわけではない。では、どのようにして問題を解決すべきなのだろうか。

解決のための考え方は、経験主義と仮説思考である。

「仕事と学力テストの3つの違い」の表に記載した通り、情報は必ずしも十分に存在するわけではない。このため、まずは情報の不足を補うための行動をする必要がある。

また、仮説を立てることで、すべての情報が揃っていなくても、早く問題を解決することができる。

では、実際に具体的な例を挙げて考えてみよう。

あなたは会社の情報システム部門に所属している。
ある社員から「自席でふだん利用しているPCから、インターネットにつながらなくなった」という問い合わせがあった。
さて、どのように解決すればよいか？

「インターネットにつながらなくなった」という文が指す問題は曖昧である。
受け取り手によって、そのイメージはバラバラになってしまう。

このため、まずはどのような情報が不足しているために、問題が曖昧になってしまっているのかを考えてみよう。

たとえば、下記のような例が挙げられるはず。自分で考えて、もっとたくさん挙げてみよう。

不足している情報がわかったら、実際に行動を起こして情報を入手しよう。
たとえば、それらの不明点を問い合わせ元の社員に質問したり、実際に現場に行って自分で確かめたりできる。

行動した結果、下記のような情報を新しく手に入れることができた。

その情報から、問題の原因に対する仮説を立ててみよう。
たとえば、下記のような仮説が立てられるはずである。

仮説を立てることができれば、また、その仮説を行動によって確かめればよい。

このように、仕事上で直面する問題においては、学力テストと違って、一回で正解を導き出す必要はない。時間と資源の制約の中で、より正解に近づく一手を打ち続けることこそが重要である。

結果的には、そのほうが短時間で解決することができるだろう。

本記事の内容は、エンジニアリング組織論への招待～不確実性に向き合う思考と組織のリファクタリングの「1-3. 情報を生み出す考え方」を引用した上で、例を挙げての解説を試みたものです。

本書はきちんと順を追って話を運んでくれるので、新人エンジニアから組織の長まで、幅広いエンジニアに対しておすすめです。