はじめに
「理由は？」
「もうちょっと考えて発言して欲しい。」
などと、上司からお小言を言われてうんざりしているあなた！
もしかしたら、PAC思考を使えば、解決できるかもしれません。
この記事では、主張の妥当性をアップさせるフレームワークであるPAC思考について解説します。
対象者
この記事は下記のような人を対象にしています。
- 駆け出しエンジニア
- プログラミング初学者
- 「自分はロジカルじゃないから...」と諦めてる人
結論
とにかく疑え！PAC思考を使えば主張の妥当性がぐんとアップします。
PAC思考とは
PAC思考とはPremise(前提・事実)、Assumption(仮定)、Conclusion(結論・主張)の3つに分解してそれぞれの妥当性をチェックし、思考の精度を上げるビジネスフレームワークです。
自分が考えたロジックが妥当か、検証する際に活躍します。
それぞれの項目について、下記の具体例を用いて、詳しく解説します。
在庫管理システムに在庫量のフォームを追加しようとしている。
クライアントからは「とにかく早く作って欲しい」と言われている。
在庫量は数字入れるのが当たり前だし、ささっと実装したいので、バリデーションかけなくていっか！
ということで、スピード重視で実装を進めた。
Premise(前提・事実)
まずは主張の前提となっている事実について、整理します。
事実・前提となっているのは下記の通りです。
在庫管理システムに在庫量のフォームを追加しようとしている。
クライアントからは「とにかく早く作って欲しい」と言われている。
この事実・前提に対して「本当にそうなのか？」「なんでそうなるのか？」を深く考えます。
今回の例だと、「早く作って」と言われたけど、具体的にはいつまでなのでしょうか？今日中なのでか、今週中なのか、今月中なのか、によって取るべき行動は変わってくるでしょう。
Assumption(仮定)
前提・事実から、自分が考えたロジックが仮説です。
下記の2点が仮説です。
在庫量は数字入れるのが当たり前。
バリデーション無しのほうが実装が早い。
この事実・仮説に対して「本当にそうなのか？」「なんでそうなるのか？」を深く考えます。
今回の例だと、「本当に半角数字だけか？全角数字や、カンマ、漢数字などが入力される可能性はないか？」などを検証します。
Conclusion(結論・主張)
事実・前提・仮定から導き出した結論・主張についても検証しましょう。
下記が結論、主張です。
バリデーションかけなくていっか！
ということで、スピード重視で実装を進めた。
この結論についても妥当かどうか、検証しましょう。
「本当にバリデーションなしで大丈夫？」「そんなに急ぐ必要ある？」など、きちんと解凍できるか、シミュレーションしてみましょう。
PAC思考を使うと、主張の妥当性が格段にアップ
PAC思考を使わないと、パッと見はロジカルな主張のように見えますが、下記のように失敗してしまいます。
在庫管理システムに在庫量のフォームを追加しようとしている。
クライアントからは「とにかく早く作って欲しい」と言われている。
在庫量は数字入れるのが当たり前だし、ささっと実装したいので、バリデーションかけなくていっか！
ということで、スピード重視で実装を進めた。
↓
結果、数値以外の入力があり、エラーが発生...とほほ
今回勉強したPAC思考を使えば、根拠の妥当性を考えられるので、きちんとした行動方針が立てられ、成功する確率がぐんと上がります。
在庫管理システムに在庫量のフォームを追加しようとしている。
クライアントからは「とにかく早く作って欲しい」と言われている。
↓
PAC思考で検証
↓
確認したところ、今週中に納品すればOK。
数値以外の入力もあり得る。
↓
バリデーションを実装し、今週中に納品。
クライアントの要望にも合わせ、品質の高い機能を実装できた。
おわりに
主張の妥当性を上げるPAC思考についてまとめました。