ロバの合理性に固執してはいけない


**********************************************************************************************************
すべての行動を合理的に決定するロバがいました。
ロバは死にそうなくらい空腹で、食べ物を探していました。
道の前方に干し草が見えました。後ろを振り返るとやはり干し草が見えました。
どちらも同じ量の干し草で、しかも今いる地点からの距離が全く同じでした。
どちらかの干し草を食べれば空腹が癒されるのですが、そうすると“選んだ干し草の合理的な理由”と“選ばなかった干し草の合理的な理由”が必要になります。
ロバは悩み続けて、そのまま餓死しました。
**********************************************************************************************************

「ピュリダンのロバ」という話なのですが、うろ覚えだったのでGoogle先生で調べたところ、いろいろな解釈があるようです。
どれが正しい解釈なのかはさておいて、今回は“合理的判断”という視点でこの話を利用します。

昔、この話の議論をしたときに、「このロバは本当に合理的なのか?」と問いかけられて非常に悩んだことがあります。「もし人間だったら、合理的に餓死をするのだろうか?」と言い換えても良いでしょう。(この問いかけは、ロバを蔑視しているわけではありません。“人間”にすることで、“合理的”という言葉の解釈に変動幅を持たせるのが意図です。)

おそらく“人間”は、「どっちも同じ=どっちを選んでも良い」という判断をするでしょう。
つまり、「問題は生きるか死ぬかであって、どっちの干し草であるかは、食った後の問題だ」という“より上位の合理性”という概念を簡単に持ち出すことが可能です。
このような“合理性”は、再びロバの立場に戻ると、「合目的的で、かつ不合理な判断」にしか思えないでしょう。

私たち開発者にとって、“人間”と“ロバ”のどちらが正しいというような議論をすることに価値はありません。しかし、“合理性”という言葉は、非常に便利でかつ非常に不便なものだということを認識する必要があるだけです。
推論を構成する際には不可欠な便利な言葉ですが、解釈に幅があるために他者との合意を維持するのに非常に気を使う必要があります。

さて、ここで製品開発の現場を想像しましょう。
製品の仕様を検討し決定する際に、顧客像を想定しないことはありません。
その際、製品を操作する顧客像は、“合理的な顧客”なはずです。
「○○がやりたいから、この画面のこのボタンをクリックする」
「○○を見たいから、このような検索をする」
のように、顧客のシナリオを想定して、それに最適な“合理的な”製品を設計します。

このように設計された“合理的な製品”が、往々にして“不便な製品”になることがあります。
この場合の“不便”とは“非・合目的的”という意味です。
例えば、“合理的”なデータ構造を忠実にナビゲートした結果、深い階層まで画面を遷移しないと操作ができなくなったりすることです。

“ロバ”は「あなたの感じる不便は、合目的的にしか過ぎず、不合理な要求だ」と反論するでしょう。
しかしこの反論は何の意味も持たないことは容易に理解できます。“開発者にとっての合理性”は製品の価値には何の意味も持たないからです。

開発者は“ロバ”になってはいけません。
“ロバの考える合理性”とは異なるレイヤーに“顧客の合理性”は存在し得ます。
そして、この“顧客の合理性”は、ロバにとっては“不合理で、合目的的でしかないもの”にしか見えない可能性があるのです。

The following two tabs change content below.

谷中

システム開発チームと検証チームのマネージャー。 「疎結合 小さなクラス 分業制」 を裏スローガンとし、これが実現できてこそ、幸せな開発者人生を過ごせるという確信のもと、上流から設計まで口を挟んだり挟まなかったりしています。

Leave a Comment


NOTE - You can use these HTML tags and attributes:
<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>