思考のフレームワーク： 事実・判断・仮説

ソフトウェアエンジニアをしている私。
不具合修正の日々が続いています。

様々な問題に対して、エンジニアとしてどう解決していくかというアプローチの仕方・考え方について試行錯誤した結果、少し学ぶことがあった。

日常的に遭遇するソフトウェアの不具合という具体的な問題から、
あらゆることに応用できる定理のような一段抽象化したノウハウの形でまとめる。


ノウハウとかビジネススキルというと、世間では「外資系ほげほげの・・・」とか「マッキンゼーの・・・」とかいうやつがいっぱいある。
代表的なものは以下のフレームワークだ。

マッキンゼー社員の問題解決フレームワーク「空→雨→傘」

コンサルタントがうまく言いくるめるためのうさんくせぇ話術とか思って、
こういうの気にも留めていなかったんだけど、最近エンジニアとして仕事をしていく中で
このフレームワークで物事を切り分けることの大切さをひしひしと感じております。


まず、私はエンジニアの仕事は少し抽象的に言うと
　 - 自明でない有用な事実を集めること
 　- 事実から論理的に説明がつく判断を下すこと
 　- 判断から検証可能な粒度で仮説を立てること
だと思っている。

# まさにマッキンゼーのほげほげとほぼ一緒でニュースバリューゼロなわけですw

例えば、誰かが「AはBだ」と言っている時、
それが誰から見てもそう言える事実なのか、
はたまた個人的な判断や未検証な仮説なのかで受け取り方が異なってくる。

事実であれば、「あ、そうだね」って反応でいいし、
判断であればそれが論理的に妥当なものか推し量る必要があるし、
仮説ならそれを確かめるための検証してみようかってなります。


反面教師的ではあるけれどいろんなダメな事例をたくさん見てきた & しでかしてきたので、
意識して思考を整理していこうと思う。
特に、意識すべき3点のアクションアイテムは以下のとおり。

1. 「なんとなくこんな感じかなぁ」とかふわっとした妄言を吐くことはやめて、事実・判断・仮説を明確に分けて地に足の着いた議論をしよう。

2. 仮説は検証可能な粒度に砕いて、検証のフェーズはだれでもできるタスクに落とし込もう。筋の良い仮説は経験から作られることが殆どなので、なれないうちは仮説が外れても気にしないことにしよう。

3. 仮説が外れた時にこそより良い軌道修正のチャンスと思うようにしよう。



問題解決をする初期のフェーズは情報が混沌としていて、
何から取り組めばよいか全くわからないことでしょう。
そこで嫌になって、盲目的に「AはBなんじゃない？」みたいな妄言を吐いて、
ピントのずれたものをさも「うん、大体合ってる」みたいな雑な仕事はしないようにしよう。
# 激しくイラッとしてSATSUIを覚えます


振り返りも大事かと思うので問題解決までの過程を残して、
 - 精度がどうだったか、
 - 生産性はどうだったか
 - 改善点はないか
を考えてスキルを上げていこう。


おしまい。