2014年9月10日水曜日

合理主義の人類学

はじめに

これから文化人類学、社会人類学を学ぶ予定であるため、現時点での自分自身の考えをまとめておく。現実には未確定な部分は多いが、ビジネスやエンジニアリング、場合によっては科学にかかわる人の思考や行動を分析したいと考えている。

現代の組織、企業や役所、研究機関などは、それぞれ目的を持っていて、自らの資源によってその目的を達成することを仕事としている。例えば企業の場合、ステークホルダーとの共存共栄や社会貢献などもあるが、基本的には利益を上げることが目的となっている。従業員個人としては別に目的を持っているとしても、組織の一員としては利益に貢献することを求められる。

ここでの合理主義とは、目的を設定したうえで、自らの行動を目的達成の手段として位置付ける考え方、としておく。利益のような数字にはっきり現れるものでも、そうでなくても、目的を達成する上では事象のモデル化や評価、広い意味での計算が必要であるが、目的を所与としても、論理だけですべきことがすべて決まるわけではない。逆に言うと、(あいまいな言葉ではあるが)「文化」が発生する余地がある。以下に挙げる問題は論理だけで決まる問題ではなく、そのために個人や組織によって異なる方法論やプラクティスが存在すると考えられる。

「計算」の諸問題

可能性の探索

個人や組織は判断に必要な情報をすべて持っているわけではない。なので調査やブレインストーミングなど情報を取得し、整理する活動が必要になるが、それ自体コストがかかるものであり、また情報の有用性は通常情報を得た後でないとわからない。何をどう調査するかをどのようにして決めるのか。過去の経験などを参照して可能な限り論理的に調査しようとする努力には価値があるかもしれないが、経験を生かそうとする場合は、検討対象となっているケースに過去の経験は当てはまるかという同定の問題が生じる。

多数の選択肢から選ぶ

数社の中から発注先を選ぶ、というのであればあまり問題はないが、さらに複雑なケースもありうる。買い物をする場合、各商品をいくつ買うか(買わないか)という選択を考えるだけでも、各商品の選択が独立でない場合、例えば商品Aについての選択が商品Bについての選択に依存する、といった関係が多数ある場合は人間が比較可能な範囲を超えてしまう。そうした事態を避けるため、明示的、暗黙的なルールはあるかもしれないが、ルールはどのように決まり、どう運用されるのか。

例えば、可能性の探索や選択の過程のどこかで、占い師に相談して決めるというのは、不合理とみなされる場合が多いと思われるが、それによって個人や組織が決定にコミットでき、その後のプロジェクトがスムーズに進むというのであれば、後述するコミュニケーションも含めた全体として考えた場合あながち不合理とはいえない。

他者とのコミュニケーション

コンテキストの形成

ほとんどの仕事は一人でできるものではなく、他の人とかかわりながら行うものである。上司と部下のように上下関係があるものもあれば、プロジェクトメンバー同士のように役割が異なるものの対等に近い関係、コンサルタントとクライアントのように組織をまたがる関係も存在する。ただ、個人の側から見た場合、どのような関係であっても相手を(人として敬意を払うにせよ)自分のために動いてもらう存在、と見ることはできる。以前会社で上司が部下に対して自分を使えと言っていたことを聞いたことがあるが、部下であっても上司からアドバイスをもらったり、キーパーソンにつないでもらったり、会議の場でフォローしてもらったりなどいろいろ「利用」する方法はある。

各個人も組織と同様に目的を持ち、合理的に行動している存在だとすれば、他者との関係は「道具的」(instrumental)になるのが自然である(Bateson 1972)。つまり、相手を自己の目的のために働きかけ、利用する対象と考え、その範囲内で自ら学習を行う。この道具的コンテキストで考えることが妥当な場合もあるかもしれないが、多くの場合、こうした関係だけが組織を支配しているわけではない。業務上の関係から出発したとしても、個人間の友情や愛につながり、目的-手段とは別のコンテキストが現れることもある。もっとも、業務上の関係も続いている場合、この合理性を超えた「我と汝」(Buber)の関係は目的達成を至上命題とする組織にとってはプラスにもマイナスにも働きうるものであり、組織の側でどう扱うかは課題となりうる。他の形の関係も考えられる。例えば、上司は道具的に、部下はパヴロフ的(宿命論的)に考えているような場合、上司は自分の指示への反応によって対応を決めようとしているのに対し、部下は自分が何をしても上司の行動に影響を与えられないと考え、(部下から見て)いつ来るか予想できない上司の制裁におびえるという状況である。

また、大きなコンテキストとしては道具的であるにせよ、チームとして活動するにあたり、自らを、またチームメンバーを一時的に対象に没入させることもある。心理学で「フロー」と呼ばれる状態はおそらくこれにあたる。合理主義的計算をゲームとして楽しんでいれば、道具的コンテキストとフローは両立するし、目的達成のために特定の心理状態を作り出すことができれば、そこでもフローが発生する。実際にどのような形をとるのかは検討の余地がある。

意味の解釈

他者との間で何らかの関係が成立している場合、情報のやりとりが行われるが、その情報が何を意味するかが常に明らかなわけではない。次の行動に移るに十分な程度に意味を解釈できなくてはならない。例えば、会議でビジネスプランについての調査結果が報告される場合に、通常は質疑応答が行われ、応答内容によって、さらには声の調子や身振りなどによって報告者が実際には何を考えているか、報告が判断材料としてどれだけ有用か、また報告者のスキルや性格、体調や精神状態といったメタ情報の判断材料になったりする。

道具的コンテキストで考えている場合、相手は機械とあまり変わらないので、近似として人間-機械から成るシステムで考える。人間が何か入力すると機械は出力を返すが、人間が予想しない出力が返ることもある。人間に予測できないのにはいくつか理由があるが、まず機械には人間が知らない仕様があり、多かれ少なかれブラックボックスである。そのため、機械の仕様を知るためにさまざまな入力を与えて反応を見たりすることがある。次に、機械が仕様どおりに動くとは限らない。ソフトウェアのバグやハードウェアの経年劣化など、機械が本来の仕様と異なる挙動をする理由はいくつか考えられる。相手が人間であっても基本的には同じで、人によってできることは異なるし、同じ人であっても状況によって異なるパフォーマンスを示すことがある。

相手が機械でも人でも、何を参照してどのように推論するか、どこまで探索を続けるかなど、合理主義から一義的に決まらない問題がある。相手が人の場合、それに加えて、相手との関係に依存して、相手側からの解釈も行われるので、それをどう扱うかで状況が変わってくる。

以上のような意味の明確化と判明した(と判断した)意味に対する(コンテキストに対応する)行動は現実には並行して行われる。

自己の統治

フーコー的なテーマである。自分とのコミュニケーションという意味では先に挙げた他者とのコミュニケーションと共通するところもある。現時点の合理的に考えられる自分が、別の時点のそうではない自分が暴走しないよう、(第三者の目を入れることを含め)あらかじめ策を講じる、というのであれば、主体としての自己が客体としての自己をコントロールするというデカルト的二元論がほぼ成立し、特に共通するところが多い。

しかし、様々な点で違いもある。自分に罰を与えることができるとしても、その際の精神状態は他人に罰を与えるときと通常は異なる(「自己と対話する」場合も同様)し、「自己欺瞞」は考えられるが、自分に対してうそをつくことは考えられない。

以下のような言葉を考えてみる。
「私はどうしようもなく罪深い人間だ。」
「私はどうしようもなく愚かな人間だ。」
これを次の言葉と比較してみる。
「あいつはどうしようもなく罪深い人間だ。」
「あいつはどうしようもなく愚かな人間だ。」

両者の違いは、「あいつ」を主語にした場合、「あいつ」が自分について同様の認識を持っているとは限らないのに対し、「私」が主語の場合には、文章の意味としてそうした自覚を持っている。他人が罪深い/愚かであるとしたら、自分が、または信頼できる第三者に依頼して何らかの訓練を行い、「あいつ」をまっとうな人間にすることが考えられるが、自分自身が罪深い/愚かなのであれば、そんな自分自身が行う自己改造の努力も信頼できるものでないし、第三者に依頼するとしても、第三者を判断する自分自身の目もあてにならない。これを徹底すると、神や阿弥陀仏のような絶対的な他者に対する信仰に行き着く。ビジネス(ここではエンジニアリングや科学なども含む)では徹底した自己否定から出発することは不可能かもしれないが(それでも信仰など基本的にはビジネスの外で培われた思想がビジネスに与える影響は排除できない)、自分自身に対する信頼と不信がどのような形をとるか、またそれがどのような行動につながるかは検討課題である。

参考文献(現在手元にない文献も含む)
塩沢由典(1998), 『複雑系経済学入門』
Bateson, G.(1972), Steps to an Ecology of Mind(G.ベイトソン(佐藤良明訳)(2000)『精神の生態学』)
Buber, M.(1957), Ich und Du(M.ブーバー(植田重雄訳)(1979)『我と汝・対話』)
Csikszentmihalyi, M.(1975). Beyond Boredom and Anxiety: Experiencing Flow in Work and Play(M.チクセントミハイ(1991)『楽しむということ』) Foucault, M., et. al.(1982), Technologies of the Self(M.フーコーほか( 田村俶, 雲和子訳)(1999)『自己のテクノロジー』)

2014年5月5日月曜日

名前をつけるということ

中世ヨーロッパの思想史では、「実念論」と「唯名論」の対立があったとされる。Wikipediaの説明をそのまま借りると、実念論(実在論)は「言葉に対応するものがそれ自体として実在しているという立場」、唯名論は「実在するのは具体的な個物」という立場である。
一般的な「本質」が存在するかという問題はイスラーム教や禅など「東洋」思想においても議論の対象となってきたようである。(井筒俊彦『意識と本質』
これらの思想で議論で議論の対象となってきたのは、主に「花」とか「犬」といった固体としては物質的な形をとるものである。「科学」や「宗教」、「社会」といった概念に対しては近代の学者がさまざまな定義を試みているが、純粋に分析のための概念と、多少なりとも規範的な概念は扱いが異なると思う。例えば、「社会」はそれ自体ではプラス、マイナスの価値を持って使われないが、「科学」は「非=科学」(疑似科学)より優れたものとして扱われる。

筆者がいるソフトウェア業界でも「科学」のように、純粋に記述的ではなく、規範的な意味を伴って概念が使われる。例えば、「ウォーターフォール」は今ではほぼ記述的に使われるが、「アジャイル開発」や「テスト駆動開発」などはある程度規範的な概念だと思う。(「偽アジャイル」という批判は聞くが、「偽ウォーターフォール」という批判はほとんど聞かない。)

少し前に"TDD is dead. Long live testing."日本語訳という主張が出て筆者の周りでも話題になっていた。自分ではあまり実践できていないし、著者はRuby on Railsなどのコンテキストを背景に主張を述べているためなじみのないところもあるが、TDDを記述的な概念、つまりやるべきことの組み合わせとして考えた場合、状況が違えば(変われば)のやり方のほうがよい場合もあるというのは当たり前で、特に衝撃的とは思えない。

なお、著者の主張はユニットテストだけに頼らずシステムテストなど上位のテストをより重視すべきというものだが、一般論としては状況次第であり、コンテキストとなっているRoRの開発においてどれほど当てはまるのかはわからない。極論をすれば、プロジェクトごとに何をすべきか異なる、ということになる。それでは、なぜ議論が行われるのか?

規範的な概念についての議論の方法


TDDのような概念に対する一つの受け取り方は前述のような記述的なものとみなすことである。コンテキストが特定されていない手法であるから、コンテキストが変わればそのままは適用されないのが当然ということになる。ただ、純粋に記述的な概念はマックス・ウェーバーの「理念型」のように外部の研究者が分析のために使うことはあるものの、内部にいる人にとってはあまり意味をもたない。

別のとらえ方は規範的なもので、「状況に適応する」ということも含め、ソフトウェア開発のあるべき姿を表すものである。この考えに立てば、概念自体を放棄することはありえないが、「成功すること」だけが意味内容であればほとんど無意味になる。

ソフトウェア関係で通常使われる方法論あるいはプラクティスに関する概念は記述的かつ規範的なものである。つまり、一定の条件下ですべきことが述べられており、それに従えば何らかの目的を達成できるものとされる。とはいえ、「条件」や「すべきこと」が常に明確なわけではない。どのような法律でも解釈の予知があるのと同様である。

こうした概念が「従ったがうまくいかない」または「よりよい方法がある」などと批判されるとき、反応としては以下のものが考えられる。

  1. 擁護:考え方は間違っていない。あなたの理解が間違っている。ある宗教の教えに従いながら幸福になれない人に対し、教えを正しく信じ、理解し、実践していないあなたが悪い、と非難するのと構造は似ている。
  2. 拡張:明示されてはいなかったが、もとの概念の中に暗に含まれていたものだ。条件が違う場合にはより一般化して適用すればよい。
  3. 限定:そのケースは概念の適用対象としてふさわしくない。
  4. 否定:もとの概念は間違っている。新しい、より良いものに置き換えるべきだ。
これらははっきり区別できるわけではない。また、同じ概念の中に含めるか、もとの概念を限定して別の概念を独立させるかはさまざまな事情による。

名前をつけるということ


ソフトウェア開発やさらに広くビジネスで使われる方法論の場合、一つの方法を適用すればすべてが成功するということはほとんどない。方法論は特定のコンテキストのもとでの複数のプラクティスの集まりであり、一部だけ適用して他は別のやり方で置き換えるなど、状況に応じて適用の仕方を調整することが求められる。ある意味ではパッケージ化され、名前のついた方法論は関係者を思考停止に導くものであり、害をなすこともあるが、それでも名前をつけることにはメリットもあるのだと思う。

一つはコミュニケーション上の必要である。名前がついていれば少ない言葉で概要を理解することができる。もっとも誤解の可能性もないわけではないが。
また、一つの理想型として参照されることにより、規律を保つというメリットもあると思う。何か違ったやり方をとろうとしても、理想型があればなぜ異なるやり方をするのか理由をはっきりさせることになるので、安易な方向に流れることを防ぐ効果がある。

意味のある議論?


ある方法論やプラクティスが特定のコンテキストのもとで成り立つ(有効である)、またコンテキストを言葉だけで表現することはできないと考える場合(基本的に妥当な仮定だと思う) 、意味のある議論としては、
  1. 個別具体的なケースで特定の方法論やプラクティスを適用すべきか
  2. 特定の条件が方法論やプラクティスの適用にどのような影響を与えるか(メタレベルの議論)
特定の現場にいない人は(ヒアリングを行うなどして)意味のあるアドバイスを与えることはできるとしても、コンテキストをすべて知っているわけではないので判断には限界がある、ということになると思う。
方法論の適用条件に関して、また定式化に関してどのようなことが議論の対象になりうるかについてはまた別の機会に投稿したい。