草薙の研究ログ

英語の先生をやってます。

構成概念について自分が考えること(1):記号としての構成概念

概要

  • 構成概念を記号として捉えてみる
  • パースの記号論を援用して,構成概念の解釈を記号過程と捉える
  • 記号過程の中で,それぞれが別個の記号でもある心,行動,測定という要素を複雑に媒介していくことで構成概念に解釈が与えられる
  • この観点の下で,構成概念の解釈はおよそ7種類に分類される(という試案)

背景

構成概念(construct)とはなにか,というものについて考えない日はない。というか,より具体的に,「構成概念に関する考え方が,著しくひとによって異なること」に対して興味がある。思考や勉強を垂れ流しのままにしていてももったいないので,勉強したり思ったりしたことをメモしていくことにする。

記号論的に構成概念を見てみる

1. もっとも広い意味での構成概念の見方

  • 構成概念ってぶっちゃけ記号である

構成概念について思索を始めるときは,常にここからスタートすることにした。ここが絶対的なスタート地点であることはもう疑わない。

  • 記号は,なにかの代わりをするあらゆるもの
1.1 ソシュール記号論

ここではあまり使わないけど,構成概念を語るテキスト(論文や本)の中で,構造主義的な見方をするのに役立つと思って。

1.2 パースの記号論
  • 記号,対象,解釈項の三項
  • それぞれ一次性,二次性,三次性に対応する
  • 解釈項はまた記号になり,別の記号との関係が発生し…という記号過程

構成概念を記号過程という観点から捉えるというアイデアを思索の中心にする。

  • 記号と対象の関係性には,類似性,因果性,規約性がある
  • それぞれ,アイコン,インデックス,シンボルと対応する

特に術語としての特徴に注目を当てるとき,構成概念は,他のあらゆる言語表現と同じで,基本的に恣意的で,規約的で,そして慣習的なのでシンボルでもある。りんごという発音と果物としてのりんごの関係は,なんら必然的な関係はなく,そう決められただけのことであって,知性という発音とその対象の関係もそうに違いない。

これを,個人的に最初の解釈ということにした。つまり,なんかをとにかくそう呼ぶことにしている,というお約束。これももう疑わなくていいと思っている。

しかしこれで終わりでない。記号過程は続いていく。

1.3 それ以降の解釈に関係するだろうこと

記号過程の中で,具体的に以下の3つの要素(これらもある意味記号である)の組み合わせを媒介することによって,構成概念にさまざまな解釈が与えられているとひとまず考える。

  • 物理的外延をもたない実体=心
  • 行動
  • 測定手続き

これらを最低でもひとつ含む組み合わせは以下の通りで7つ。

 

  行動 測定手続き
1    
2  
3  
4
5    
6  
7    

 

こんな感じ。なので,とりあえずこの(未熟な)考えの上で,記号としての構成概念は7種類に分ける,としよう。

  • ここでのは,デカルト的な意味で,まったく物理的外延をもたないもの。物理的外延をもたないので,ときに時間と独立したり,空間と独立した働きをしたりする。しばしば私は,ライルのことばを借りてゴーストと呼ぶ。
  • ここでの行動は,人の一般的な行動のこと。行動はもちろん記号でもあるし,モリスのように,記号というものの基礎づけに行動を置く場合もある。しばしば私は,文脈によって観測と行動を同じ意味でつかう。
  • ここでの測定手続きは,質問紙をやったり,それになんらかの測定モデルを適用したりすること全体。測定はかならず行動を伴うが,ここでは奇妙なことに,測定手続きに含まれる行動のみに限定する。そしておおざっぱにも,データやモデルも全部含めてしまう。

ここが自分の考えに独自性があるところだと考えているけど,心理統計やテスティングでは,当然ながら,この測定手続きを考慮しない議論は存在しなかった。ほとんどの場合,構成概念は,観測変数と潜在変数の論理的ないし数理的関係とその実装を中心に語られてきた。しかし,応用分野になればなるほど,自分にとっても盲点だったが,測定手続きと完全に独立した構成概念はあり得るし,いわゆる心の実在や因果関係に関する認識は変わってきて自然。つまり,構成概念という記号にも,コードというようなものがあるだろう,ということ。

2. 7種類の構成概念の解釈

2.1 心のみ
  • 行動と測定手続きをまったく介せずに心を直接的に参照する

記号は,なにも物理的外延をもたないものもその対象にすることができる。ユニコーンのように。

これを悪しき二元論だとか,安易な実在論だ,と決めつけるのは慎重であるべき。経験とまったく独立した記号は存在しない。その経験というのが,おそらくひとの話を聞いたり,本や論文で読んだり,そして自分の主観であったりということだ。これが成立するかはわからないが(厳密な意味ではしないと思うが),たとえば,「動機づけ」は,観察されうる行動の頻度や持続長などと関係なしに,そして質問項目や因子モデルなどとも独立した意味をもつ。

それが関係する行動も測り方も知らないけど,このことばを使う,みたいな場合。これを心やゴーストと呼ぶかもまた難しいけど。

2.2 心と行動
  • 測定手続きを介しない,心と行動の関係

この態度は,一般的にアブダクションと呼ばれる論理にもとづいていて,場合によってはそれが間違いであるとか,循環に陥るという批判を受ける。

アブダクションは,論理A→Bと結論Bから,前提Aを導く。なにかがなにかを動かすという論理があって,なにかが動いているのだから,それを動かしているのもあるはずだ,というような考え方。ペラペラとよく英語をしゃべるのだから,またはしゃべらない人がいるのだから,その原因となる熟達度というのがあるはずだ,というに考える。

関係というのも一筋縄にいかない。類似関係と因果関係のふたつはあると思う。いわゆる,「行動は心を映し出す鏡」,つまり行動は心と並行しているであるとか,少なくとも性質的によく似ている,というようなものだ。この場合,記号としての構成概念はアイコンに分類されるはず。

もう一方,因果関係は,いわゆる機械の中の幽霊だ。心と身体が別々にあって,心は物理的ではないのに,なぜか物理的な身体に影響を及ぼすというあの超自然的な考え方。

機械の中の幽霊批判は人間の尊厳を傷つけるという方がいるので,この話をするときはできるだけ穏健なヴァージョンを用意してそれを使う。それはドラクエ的世界観だ。ドラクエではゲーム中,メニュー画面を開くと,キャラクターのパラメータが見えるんだ。ちからが8で,かしこさが7というような。で,実際に,おそらくこのドラクエの世界の中からは直接的にアクセスできないこのパラメータが,ドラクエの世界の中におけるできごとの本当の原因となっている。しかも,超簡単な数式で。たとえば,スライムにこのキャラが攻撃をしかけるとき(これは行動であり記号でもある),スライムがくらうダメージは,ダメージ = キャラのちから + 武器の性能 - スライムのぼうぎょ,みたいになっている。熟達度が英語使用の原因だというのとおなじで,ちからはダメージの原因だ。

ここでは,あくまでも測定手続きが関係ないことに注意。つまり,ある意味運命などもそうだ。運命という目には見えない,おそらく物理的外延をもたないものが,行動を支配していて,そして運命を測定しようとはしない。

2.3 心と測定手続き
  • 行動を介しない,心と測定手続きの関係

この態度が成立するかも難しいのだけど,こう理解したらよいかも。たとえば,まったく将来の行動を予測しない心理測定。動機づけは,この質問紙とこの因子モデルによって測定できる(ここでは大雑把な意味)のだけど,動機づけは,日常的な,または測定以降の行動の頻度や持続長などとは関係ない。

つまり,測定手続きに関わる行動のみの原因となっている。…そんなものやっぱないかなぁ。この組み合わせを廃止しようかな。

ただ,いいたいこととしては,なんら実際の行動などを顧みない,その関係性を考慮しないクソみたいな操作主義に相当するイメージ。

2.4 心と行動と測定手続き
  • 心,行動,測定手続きの三者関係

 

おそらく,これがもっとも多数のひとにとっての構成概念。心,行動,測定手続きは互いに関連付けられていて,構成概念という記号が示す対象は,これらの複雑な関係だということ。

典型的な場合,こんな関係だ。

  • 熟達度はある種の行動の原因となっている(熟達度が高ければペラペラ)
  • 熟達度は測定手続きに含まれる行動の原因にもなっている(熟達度が高ければテストのスコアが高い)
  • なので,(アブダクション的に)テストのスコアが高いのならば熟達度が高いと見積もるのがもっともらしい(合計得点をもとめ,個人に割り当てる)
  • テストのスコアが高いひとは熟達度が高いとみなせる

このような仮定や推論が構成概念という記号をなす,と考える。

この態度やこれとは異なる関係性についてはあとで詳しく考える。記号としては,インデックス的な性質が強い。

ドラクエ的世界観だとこんなかんじだ。ちから(心)は,ダメージの原因になっているのだから,ぼうぎょがおなじスライムに,おなじ武器を装備させてダメージを測ったら,ちからが間接的にわかるだろう。つまり,メニュー画面を開かなくても,ドラクエの中からちからがわかるだろう,と。

2.5 行動のみ
  • 心と測定手続きを介さない行動それ自身

ここからは心を介さない構成概念。

心を介さない構成概念の見方も非常に根強い。古くいえば,エピクロスとかルクレティウスとか…20世紀に飛んでライルとか,論理実証主義のカルナップ,記号論ではモリス,もちろんいうまでもなくスキナーとか,最近だとラクリンとか,面々たる系譜が繰り返し繰り返しいってるような態度。「心は行動の原因でもないし,けっして説明にもならない」という。

術語としては行動の傾向性などともいうそうだ。ここでの態度は,熟達度は,(将来的に)ペラペラ喋ったり,英字新聞を読めたりするような行動のカテゴリーそれ自体である,といった感じ。

ただ,具体的な測定手続きは考えない。

2.6 行動と測定手続き
心を介さない,行動と測定手続きの関係

もちろん,場合やものによるのだけど,私が一番構成概念として解釈するのはこれのこと。行動と測定手続きの関係は,全体部分関係にある。心理統計だと,潜在変数の非因果的解釈などともいわれるよう。たとえば詳しくは後述するけど,ある行動のカテゴリーからその一部分に当たる行動をサンプリングして測定手続きに使っていると考えわけ。因果関係はここにない。

つまり,行動の傾向性を表す指標を取っていること。もちろん,記号としてインデックス的だ。

2.7 測定手続きのみ
  • 心と行動を介さない,測定手続き

この態度は奇妙なことに成立しそうだ。たとえば,熟達度とはTOEICのスコアそれ自体を,ほかの心や行動とは何の関係もなく示しているというもの。心なしで,そして測定が行動の予測力をもたない,といったパターン。

2.8 まとめ

というわけで,記号としての構成概念に着目して,構成概念は7種類に分けられるんじゃないかと妄想した,という記事でした。まだまだ続くけど今日はここまで。

 

 

範疇と構成要素をしっかりと区別すること

範疇

範疇またはカテゴリーとは,このようなものだ。

フルーツという範疇に,バナナ,りんご,みかん,なし,もも…がある。

個物の性質に応じて分類されているものだ。

構成要素

構成要素は,このようなものだ。

車の構成要素は,エンジン,タイヤ,ボディー,ブレーキ…などである。

車が車であるような,その成り立ちを決める一部分のこと。人工物なら,部品といっても通るようなものだ。

 

範疇と構成要素は,全く異なるものだ。

 

外国語教育研究における構成概念

「語彙知識には,形式の知識,意味の知識,そして使用の知識がある」

→ 私は理論についてはまったく素人でよくわからないが,おそらくこれは構成要素を示している。

「文法知識には,明示的知識と暗示的知識がある」

→ 私は理論についてはまったく素人でよくわからないが,おそらくこれは範疇を示している。

「動機づけには,道具的動機づけと統合的動機づけがある」

→ 私は理論についてはまったく素人でよくわからないが,おそらくこれは範疇を示している。

非常に紛らわしい。よく混同しているような用例も見る。というか,わたしが理論面についての知識をもたないからかもしらないけど,どちらかわからないことが非常に多い。範疇なのか構成要素なのかを明確に言明してほしい。

 

ChromebookにLubuntuを入れてしまいAtomに引きこもろうと思ったが…やっぱEmacs!

繰り返される「勝手な」Windows Updateの波に本当に嫌気がさしている。

別にこちらの会社に限った話じゃないけど,いつの間にか,コンピュータは人が命令したことを盲目にする道具じゃなくて,人に先回りしてなにかして,承諾を得るというようなスタイルでひとと関わる地位に上がっていたようだ。私はまだPCっていうのは私の相棒でもパーソナルアシスタントでもなくて計算機だと思いたい。

ある意味,パターナリズムということばの意味を深く考えさせられる。そうか,「コンピュータのことなんかどうせわからない私だから,コンピュータのことなんかどうせわからない私の命令を待つのじゃなくて,コンピュータが私をいいように導いてくれるのか」なんて。だから,「だから,私がコンピュータに命令を出すのでなくて,コンピュータのいうことに従うべきなのか」なんて。

そんなため息をつきながら,Macを使えばいいじゃないかと思って開いてみても,数分もしたらなんかコレジャナイ感に苛まれる。吸血鬼が銀に触れたら火傷するように,私はこのアルミの筐体によって身を焦がす。

Ubuntu系のOSは,ここ10年くらいのつきあいだ。Ubuntu,特にLXDE環境のLubuntuだけにしたい,などといってもそうはいかないときも多い。パターナリズムに怯えながらも結局,Windowsが入っているマシンを触る。だからといってWindowsを開いてもどうせVirtualBoxで仮想的にLubuntuを開いたりする。困ったもんだ。Lubuntuみたいな軽いデスクトップ環境だと,ほとんどの市場に出回るWindows機ではオーバースペックになる。仮想環境のメモリやストレージの割当てを何故かできるだけ少なくして,どれだけカツカツにするかで楽しむようになる。「やばい!領域が少なくて,apt installできない!」みたいなのがいい。…ビョーキだ。

病身の末,唐突に思い立った。いつだって唐突が一番だ。私を救ってくれると期待していたラズパイを,仕事用に使うのはやはりキツいものがあった。ラズパイ,ごめん。でも,それよりはマシだけど,私の身を焦がさない程度に低スペックで,非力で,しかし製品として気が利いているChromebookはどうかと。なによりもWindowsがプレインストールされていない。非力で,そしてWindowsが入っていない。なんて素晴らしい。

日本市場のChromebookはどれも似たりよったりだけど,ASUSさんのChromebook flip c101pa,英語キーボード版をポチった。eMMcで16gb,RAM 4gb,CPUはARM,10インチ,900g。4万程度。タブレットみたいな値段だ。いいじゃないの。とても安い。1kgを切ると軽い感ある。いろいろと変形合体みたいなギミックになっているのは,はっきりいってなんの意味もないのけど,おっさんには嬉しいものだ。それに,むかし愛したSharpMebius Muramasaにそっくりじゃないか。あのバカみたいな薄さと非力さ。いいぞう,可愛いぞう。

 

で,ChromeOSには限界がありそうなので,好みのLubuntuを入れる。これはかなりやられていることのよう。

参考にしたのは,こちらのサイトさま。

 

neos21.hatenablog.com

chromesoku.com

 

要はChromeOSから仮想化機能でいれるわけだ。買ったそのときからすぐにデベロッパーモードに入ったら,すげえビープ音とか鳴らすもんでびっくりしたけど,まあ上のリンク先のとおりにしたら,現在もなんの問題もなく導入できる。もちろん,クリーンインストールもできないことはないらしいのだけど,ちょっと設定がめんどいらしい。

ちょっと自分用のメモだけど,terminalからbashに入った段階で,

sudo sh ~/Downloads/crouton -r list

とすると,ディストリビューションのリストがでるので確認したほうがいい。現在は18.04のbionicが最新で,LTSなのでしばらくはこれでいいかな。

追記:…と思ってbionicやったのだけど,現在は18.04のbionicはうまく対応ができていないみたいで,実際に色々問題があった。無理やりやったら解決するだろうけど,手間なので結局その前のLTSであるxenial,つまり16.04で入れたほうが絶対にいい。xenialのサポートは2021まで。もしかしたらtrustyとかのほうがいいかもしれないくらい。

この仮想環境実行中に,ChromeOSとLubuntuはキーボードショートカットキーですぐに切り替えられるみたいだ。便利ね。

ChromeOSも話題になるだけあって,なかなか興味深い。特にGooglePlayに対応しているので,Androidアプリが動く。いいじゃないの。

で,Lubuntuのほうにいつもの通りAtomを入れて,いろいろAtomに連携させればいい。

 

…などと思ったのだけど,重大な問題を考えていなかった。この筐体,ASUS Chromebook Flip C101PAはARMアーキテクチャだった。調べた限りでは,Atom(エディタ,ややこしい)はこれにまだ対応していない。しまったー。

それに数日使ってみたら,どうもLXDEはそんなに安定してないようで,挙動が結構怪しい。xfce環境のほうが安定しているようだ。最近のGNOMEは正直よくわからないし,ましてやUnityなんて重いしおしゃれだしおしゃれだしおしゃれだし,なんていうか身を焦がすデスクトップ環境の代表だ。

それに,なんと調べたら,まだβ版なんだけど,最近のChromeOSはネイティブでLinuxモードというのを起動できるようになったみたい。この筐体は対応している。

Linuxモードをオンにすると,普通に端末が開いて,aptなどが使えるので,RやEmacsなどをいれてみたら見事動いた。残念ながら,このモードだと日本語対応がまだしっかりとはできないみたいだけど(たとえばEmacs-mozcが入らない),EmacsにESS入れてRを動かしたり,EmacsからMarkdown書いたり,TeXを書いたりといろいろできるので,ま,これでいっか,というような感じ。

Emacsは久しぶりで,自分なんか初心者ともいえない低レベルだけど,Emacsにまたひきこもろう。…というわけで,どうせAtomが入れられないならEmacsするしかないわけで,croutonを使っていれたLXDE環境は一度Powerwashして,LinuxモードからEmacs開くことにした。

というかChromeOSいいね。Android環境とLinux環境が共存している。まあ,もとがそもそも同じようなもんだからだけど。いずれにせよ,これでwineとかしたらWindowsアプリにも動くのがありそうだし,とっても楽しそう。

brmsパッケージでカーブフィッティング

計量言語学のMenzerath-Altmann法則をbrmsで。

(a)y = ax^{-b}e^{-cx}

s<-1:5
m<-c(3.1,2.53,2.29,2.12,2.09)
dat <- data.frame(s, m)
my.prior <- prior(normal(0,3), nlpar = a) + prior(normal(0,1), nlpar = b) + prior(normal(0,1), nlpar = c)
fit <- brm(bf(m ~ (a*s^-b)*exp(1)^(-c*s), a + b + c ~ 1, nl = TRUE),
	data = dat,
	prior = my.prior,
	save_all_pars=T)
summary(fit)


f:id:kusanagik:20180914171856p:plain


f:id:kusanagik:20180914172534p:plain

これ,データポイントが少ないから,事前分布の設定がすげえ問題だよね。
適当に,

  • a ~ Normal(0,3)
  • b ~ Normal(0,1)
  • c ~ Normal(0,1)

とかにした。実際に-1とか1とかの値を取ることがほとんどないbcはともかく,このaの設定は恣意的といわざるをえないけど。
ちなみに,より簡単な,

(a)y = ax^{-b}

ベイズ因子やWAICで比べてみるとか。

my.prior <- prior(normal(0,3), nlpar = a) + prior(normal(0,1), nlpar = b)
fit2 <- brm(bf(m ~ (a*s^-b), a + b ~ 1, nl = TRUE),
	data = dat,
	prior = my.prior,
	save_all_pars=T)
summary(fit2)

f:id:kusanagik:20180914172915p:plain

f:id:kusanagik:20180914172933p:plain

bayes_factor(fit,fit2)
waic(fit, fit2)

fitがfit2より高かったけど…微妙。

AtomからRを使うための設定(Ubuntu系OS)

お気に入りのエディタからなにがなんでも出たくないという病気。
ここ3年はAtom推しなので,今回はAtomからRを使用する環境を作る。

環境は,Lubuntu 18.04 LTS。
でも別にこのOSがなにか特別なわけじゃない。

これまでAtomからRを使うときは,Atomのパッケージである,

  1. language-r
  2. autocomplete-r
  3. build-rscript

などといったものを使っていた。
詳しくは,こちらの記事の通りに。

Atom - RjpWiki

というか,buildがめんどくさくて,もうterminalをペインに開いて打っていたけど。

でも最近,Atomでrboxというパッケージができたらしい。
これはちょっと便利そうじゃないのー。

atom.io

基本的な方針としては,

  1. Rをインストール
  2. Jupyterをインストール
  3. Atomをインストール
  4. JupyterにR言語を対応させる
  5. AtomにJupyterを対応させる

というような手順。Jupyterを経由するという発想。

  1. JupyterとRの対応は,RからIRkernelを入れる
  2. AtomとJupyterの対応は,AtomからHydrogenを入れる
  3. 最後にrboxを入れる

ま,そのままJupyterを使ってもいいんだけど,個人的にAtomでやりたい。

さて,順番にコードを書いていく。

コンソールからRを入れる

sudo apt-get install r-base-core

Jupyterを入れる

sudo apt-get install jupyter

Atomを入れる

sudo add-apt-repository ppa:webupd8team/atom
sudo apt-get update
sudo apt-get install atom

IRKernelのための準備

sudo apt-get install libzmq3-dev libcurl4-openssl1.dev libssl-dev

(なんかココ変だな,Rのdevtoolsはcurlがないと入らないのだけど,curlは依存関係があるようだ。もしだめだったら,libcurl3とかを先にいれないとだめかも。で,libcurl-openssl1.0-devを最後に入れるのかな?)

RからIRKernel関連を入れる

install.packages(c('crayon', 'pbdZMQ', 'devtools'))
devtools::install_github(paste0('IRkernel/', c('repr', 'IRdisplay', 'IRkernel')))
library(IRkernel)
IRkernel::installspec()

Installation · IRkernel

これでJupyterとは対応されるはず。

jupyter-notebook

と打って,ブラウザ上からNewを開いて,Rが追加されていることを確認。
あとは,Atom上で以下のパッケージを入れる

  • rbox
  • hydrogen
  • atom-beautify
  • termination

これでOKなはず。

ひとに統計相談をするための8つの基本的なTips

その1:データや資料を必ず用意する

統計を得意とするひとであっても,実際のデータやそれに関する資料などが,手元に全くない状態において,(しばしば不正確で非専門的ないい方による)文字や音声だけによる情報で正確に相談の意図を把握することは簡単ではないと思う。データや関連する資料をメールで事前に送ったり,面会する際は印刷して参照できるようにするほうが効率的だ。統計に関する参考書や自分の研究に関する先行研究もよい資料となる。

その2:できればデータを取得した後でなくて,事前に相談をする

ほとんどの場合がそうだが,有意差がでなかった,思うような結果にならなかった,ということについて「統計分析にその原因がある」と一意的にみなし,本来あった研究仮説と整合性がなくなるようなレベルで,モデルや分析法を変えたりするように統計相談をするひとがいる。これはほとんどの場合,被相談者にとって心持ちのよいものではない。実験・調査の事前段階でその計画について相談するほうが大抵は優れた研究につながる。特に研究仮説の書き直し(HARKing)につながるとみて,場合によっては相談自体をお断りされる方もいると聞いた。

その3:質問をできるだけ具体的に細かく分ける

たいていのことはそうなのだが,「大丈夫か」とか「問題ないか」とか「適切か」といった抽象的で曖昧な聞き方をするとあまりよい回答は得られない。たとえば,この計画は大丈夫か?というよりは,「標本サイズ決定の仕方を知りたい」とか「効果量はどの指標を使うべきか?」といった具体的な質問をリストアップするほうがよい。もっとも非効率的なのは「どうしたらいいですか?」だ。これはほとんどまともな返答をもらえない。相談を受ける方にとって,「こうするんだけど適切か」と聞かれたら「厳密には文句がない統計など絶対にない」というだろうし,その程度は非常に曖昧なものになってしまう。

その4:対価に当たる部分についてどのように考えるかを知っておく

相談を受ける側が対価を求めるわけではなくても,その行動にはそれなりにコストが発生しているわけで,それをどうするかは人による。まったく贈答品やお土産の類を受け取らない,論文等の謝辞などもすべて辞退するというタイプのひともいれば,遠慮なく受け取るひともいるし,ある程度以上であれば謝辞や著者権が正当だと思う方もいる。非常に難しい問題なので,事前に対価について相談を受けるひととスッキリしておく方がよい。たとえば,私が相談を受けるときは,対価にあたるものはできるだけ受け取らないようにしているし,謝辞なども辞退する方針でいる。高級なお菓子とかが食べたいからやっているわけではないし,謝辞などに勝手に書かれるのは非常に困る。「自分の勉強のためになりますので…」といって対価を拒むひとが相対的に多いと思う。しかし,だからといっていつでも無対価で頼むとひとによっては失礼になるかもしれない。

その5:自分の理解を超える分析を提案されたらそれを伝える

ときに相談をすると,「そういう問題のときは,こういう新しい分析がありますよ」という提案がある場合がある。そういうとき,その提案された手法を自分がしっかりと理解し,ある程度は著者として責任を持てるようにしなければならない。たとえば査読コメントでその分析について詳しく書くようにいわれたときに,書けないというのではよくない。相談を受けるほうからしてみれば,相談をする方が適切に理解しているか,または今後理解するかを見分けるのが難しいので,自分から「それはできそうにありません」としっかりと伝えるべきだ。まったく責任を自分で持てない場合,著者に入れるというのもひとつの考え方だと思う。

その6:エディター,査読者,指導教官などとの争いに巻き込まないようにする

これらのひとと,相談を受けるひとの方針が対立したとき,普通は相談を受けるひとはなんの責任も負うことができない。たとえば,ある分析をして,エディターがそれではだめだといったけど,「これは問題ないですよね?!」みたいにひとに相談をするのはよくない。けっして代理の喧嘩を頼んではいけない。特に学位論文に関わる際には,仮に指導教官よりも統計面に強いひとに相談したとしても,それが学位論文を審査する人にとって好ましい分析であるかはわからない。

その7:最終的な主張を伝えない

「この研究では,こういうことを主張するために…」というようなことを明確に伝えると,結論ありきの分析につながってしまいかねない。相談を受けるひとが忖度して,かなりQRPに近いことを提案してくるかもしれない。よくある話だけど,ある程度,統計をするひとにとって,有意差を無理矢理つくることは難しくない。非常に難しい問題だが,できれば統計相談の際も,結論を先取りするような態度を示していないか,慎重にありたいものだ。

その8:面会よりもメールにする

面会する場合よりも,文面の方が一般的に質の高いやりとりができる。面会時間よりもはるかに短いあいだで,はるかに質の高い返答をメールで送ることができるかもしれない。たいていは相談を受ける方も,書籍やネットなどでなにかを調べたり,なにかで実際に計算したりするので,ただ面と向かってしゃべっている面会よりは,そういった作業ができるようなメールのほうがよい。多分,メールでは失礼だ,とかお菓子渡したい,というように考えられる方が多いと思うが,そういうのはまったく別の機会でよい。行動の強化を図って即時に強化子たるお菓子を与えなければならないとか,そういうふうに考えない。

 

気軽に「説明」とはもういわない

説明

あいも変わらず,不勉強ゆえに,よく考えずに軽々しく,説明などという難しいことばを何度も使ってきたものだが(幸いなことにあまり自分の論文や原稿には使用例が見当たらなかったが),他人の使用はどうであれ,私はこの説明ということばを軽々しく使わないことを,死んだ愛犬のジョンに誓った。私が知る限り,少なくともこのことばは,かなりの頻度をもって,健全なコミュニケーションを妨げる。

演繹のこと

説明の科学的定義ともいったりするらしい。一般法則から個別の事象を導くことなど。これは,もっとひろく論理学的にいえば演繹のことだ。

妥当な推論であるところの「A(条件,または仮定)ならばB(帰結,または結論)である」とAが真であるということから,Bが真であると導くわけだ。

人間の会話を例にすると,「どうしてご飯を食べたの?」という疑問に対して,「だってお腹が空いていたんだ」と答えるのは,質問者と回答者の中で,「お腹が空いていれば(条件),ご飯を食べる(帰結)」を妥当な推論として先んじて共有した上で,回答者しか知らぬ条件「お腹が空いている(いた)」が真であることを回答者に知らせ,演繹によってすでに得られた帰結を再確認することだ。

つまり,議論に先んじて得られた帰結と,未だ共有されていない条件の下で,条件を伝え,帰結が演繹によって再確認できることを示す。

 

心理的帰結のこと

説明の心理学的定義ともいったりするらしい。この定義において説明とは,帰結主義的に,人間の主観および内観において,納得した,理解したという心的状態をもたらすこと,といった具合だ。たとえば,数理モデルで完璧な予測と制御ができる状態でも,それは説明したとはいわないというひともいるし,数式を読む人にとっては数式によって心理学的に納得したと感じるかもしれないし,自然言語でなにかのメタファーを使わなければ納得したと感じないひともいる。大概の場合,なんらかのメタファーと後述するアブダクションによって,納得したと感じるひとが多い。ある研究について,頻繁に「直観に合う」とか「面白い」とか「興味深い」という形容をされる研究者にとって,大概説明とはこの心理的帰結のことだ。草薙がこういうタイプの研究者を悪くいっている,と皺を寄せる方もいるかもしれないが,ここのいい方に他意はない。ただ,そういう方もいる,という記述を与えているだけだ。

 

アブダクションのこと

パースのアブダクションを論理のひとつとして認めるひともいるし,すくなくともこれが文字通り仮説形成という役割で,我々の研究においてものすごく重要であることは誰も疑わないと思う。しかし,くだらないかもしれないが,もちろん,アブダクションは演繹ではない。

アブダクションは,所与の帰結Bと,A→Bを妥当な推論とみなすことによってAについて推論することだ。もちろん,これはA⇔Bでなければ正しいという保証がない。ご飯を食べたという帰結と,「お腹が空いているとご飯を食べる」が妥当な論理であるとしたうえで,「お腹が空いていたのだろう」と推論することだ。

アブダクションがだめとはいわないが,これは演繹による確認という意味の説明ではないアブダクションは,数理モデリングではとてつもなく重要で,尤度とかベイズ推定という根幹をなす考え方なんだけど,もっともらしいということを説明とはいわない。

心(mind)一般について私が受け入れない理由はこれだ。私は一般に,(専門用語としての)心は行動からアブダクションされたものだと考えている。たとえば,英会話場面における発話数が少ないという帰結と,スピーキング不安が高ければ,英会話場面における発話数が少ないという(どこから来たかわからない)デカルト的な論理によって,(心としての)スピーキング不安が高いという条件をアブダクションしている。これは少なくとも演繹的な説明の科学的定義に沿うものではない。仮説形成であるとしても,心が見えないばっかりに,このアブダクションされた仮定や条件を直接的に調べる方法はありえない。

予測と統御

最近では,実データの予測と統御がある社会的文脈と歴史の上である程度可能であるという事実を説明と呼ぶという態度も見られる。私自身は,心理的帰結を説明に積極的に含めるならば,別にこれを説明とみなすこともまったくやぶさかではない考えなのだが,コミュニケーションを妨げるひとつ原因であると感じるようになった。*1

で,どうするか

演繹の場合は演繹,アブダクションの場合はアブダクション,予測と制御,そして心理学的帰結をそれぞれいいわける必要があると痛感している。以下のような使い方をする。

  • 結果は,論理Xと仮定Yによって演繹的に導かれる
  • この言明は,あるひとにとって,心理学的帰結としての説明をもたらす可能性がある(または,広くいってこの言明は効用をもたらす可能性がある)
  • 本論文は,観測されたXと論理YによってZという仮説を立てた
  • この数理モデルから得られる予測値は,観測データの優れた近似になった

ここまでのまとめ

これまでの「もういわない」は以下の通り。

  • 測定する
  • 客観的
  • 説明

…なので必然的に私は,これからの研究実践において,「客観的な方法でなにかを測定して,事象やその背景にあるメカニズムを説明する」ことはない。

 

 

*1:モデリングという考えについて話すときに,毎回「それは説明ではない」とか「それは予測ができるだけで意味がない」というコメントをいただく。何度も,ほぼ必ずといっていいほどこういったお叱りを受けるので,対応テンプレートを用意した。まず,前もって,説明とはいわないことだ。大概は,モデリングによる予測と制御によって,個人および集団の効用を高めることを目標とするといっておけばよい。事実まったくそのように考えているし,個人の心理的帰結としての説明を受け入れるならば,これを説明といわない境界線について考え始めなければならなくなるから。次に,予測ができないが納得する説明と,先生はなぜか納得はされないが完全な予測ができる説明では,どちらが経済学的な意味での成果になりますか?と聞き返すことだ。最後に,先生がおっしゃる説明や意味とはなんですか?と聞き返すことだ。大概これで嫌な顔をされるが会話は終わる