観察されたデータを絶対的なものとするか、
それとも
仮説を絶対的なものとしてそれに見合うデータを待つか
という二つの立場に対して柔軟な立場をとるのが3.アブダクションです。
3.アブダクション
データを批判的に検討しつつ、データが仮説に対してモル証拠としての価値を擁護する（三中、同著、p.64）
理論の「真偽」を問うのではなく、観察データのもとでどの理論が「より良い説明」を与えてくれるのかを相互比較する
というのが、アブダクションの立場です。
例えば次のような例が挙げられます。
- 観察データ : 二つあるパソコン用のディスプレイが両方とも何も映らなくなった。
- 仮説1 : 電源ケーブルが外れた
- 仮説2 : グラフィックカードが壊れた
- 仮説3 : 両方のディスプレイが壊れた
この観察データからは仮説の1が「真に」正しいのか、
それとも仮説の2が「真に」正しいのか問うことがナンセンスです。
なぜなら、観察データは個々の場合によって異なるからです。
こういった個々のケースを推論するような場合には、
従来の演繹法や帰納法などのように
データと仮説との関係性に強さを与えるのではなく、
もっとデータと仮説との間の弱い関係性が必要です。
今、手元にあるデータから最も当てはまりそうな、
いい感じの仮説をとりあえずは採用するスタイルの推論を
アブダクションと呼びます。
そして、アブダクションという推論は終わることなく続けられます。
というのも、アブダクションという推論は「真偽」の絶対的な確定行為ではなく、
どの説が最もよくデータに当てはまるかを
テストし、一時的に採用するという
一時的な仮定行為だからです。
例に戻る
先の例においては、皆さんも行う通り、
最初の観察データの後、
とりあえず電源ケーブルを見たり、
他のディスプレイに変えたり
他のパソコンに繋げてみたりといった
新たなデータを取得してみて、
どの仮説が適切であるかを推論していきます。
これが例えば、開発であった場合などは
- 観察データ：画面のボタンを減らしたら、業務効率が上がった
- 仮説１ : タブを押す回数が少なくなったから
- 仮説２ : ユーザーがシステムのUIに不慣れであった。
このような仮説が立てられます。
もし、この後に、「ユーザーはUI操作に習熟している」というようなデータが得られれば、
仮説１の方が妥当でありそうですから、
- いらない機能が多かった
とシステムに対して新たな事実を発見することができそうです。
そうなれば、その機能はいらないのか、
必要だけど普通のユーザーは使わないので、
特別なユーザーだけ使えるようにする
といった選択が出てくると思います。
まとめ
こうして見てみると、アブダクションという推論過程は
いわゆるアジャイル的なプラクティスに近いものが
あるのかと思われます。
ウォーターフォール型開発は、
真の仕様とは何であるかを定義して、
(演繹的もしくは経験的に真を決定してから、)
開発するようなスタイルでです。
「真」に到達したときに開発は終わります。
これに対してアジャイル型開発は、
変化を受け入れ、もしかしたら学習をして
開発していくスタイルです。
開発にはおそらく終わりはないでしょう。
なぜなら、すべてのリリースが一時的な仮定行為なのだから。
もしかしたらアブダクション的なスタイルの
開発というのもありかもしれませんし、
それでユーザーの価値が向上するなら、
取り組んで見る価値があるかもしれません。
こぼれ話
実は『系統樹思考の世界』という本を読み進めていくと、
アブダクションという推論様式はAIを開発する過程で研究されたという記述が出てきます。
AIは機械が人間のような振る舞いを見せるために
学習するという部分を研究する必要があったのでしょう。
そうするうちに研究の結果が他の分野へも派生して行って、
昨今のアジャイルプラクティスの勃興につながったのではないか
な～んて仮説が出てきたりしますね。
（逆かもしれませんが…）
0 件のコメント:
コメントを投稿