阿部和也の人生のまとめブログ

私(阿部和也)がこれまで学んだとこ、考えたことなどをまとめていきます。読んだ本や記事をきっかけにしていることが多いのですが、読書日記ではありません。

2013年06月

ハーバート・ギンタス『ゲーム理論による社会科学の統合』(NTT出版)を読み進めていたが、中断することにした。400ページほどの本で、150ページを越えるところまで読んだが、このまま読み進めることには無駄が多いと結論した。以前にも書いたように、この本は訳に問題がある。しかしそれは中断の理由ではない。

この本を読み始めたきっかけは、ゲーム理論に興味があったことと、社会科学の統合という壮大な主張に惹かれたからだ。しかし、この本はゲームの理論とそこで使われる数学について、一定の基礎知識を前提としていた。この本では説明なしに新しい記号が使われることが多い。例えばギリシア大文字のΠは、普通は多数の項目の積に使われる記号だが(複数の項目の和を表すのに使われるギリシア大文字のΣに似ている)、この本では集合の演算を表すのに使われている。数学的な類推からすれば、連続する集合の積集合を表すと考えられるが、文脈からすると和集合を表しているように思える。このような重大なことを棚上げにしたまま読み進めることは非常な苦痛を伴った。

また集合の前にギリシア大文字のΔを付加する記法(とたえばΔS)も登場するが、このΔにどのような意味があるのか(演算子であるのか、添字であるのか)が示されていない。添字と解釈して読み進めたが、すぐその後にΔ*Sのような記法が登場した。こうなると、Δや*にどのような暗黙の意味が付されているのか、分からないと非常にフラストレーションがたまる。

数学の本では全ての記号や記法が説明とともに導入される。もちろん、初等中等教育で説明済みの記号は解説なしに使用される。等号=、不等号<、>、四則演算記号などが説明なしに導入される代表的なものだ。コンピュータ関係の言語解説書では、あらゆる記号が説明される。たとえば()でさえ、演算の実行順序の変更、関数を示す演算子など、複数の役割を担うので、ことこまかに説明される。

しかし、論文となると別だ。フェルマーの最終定理を証明した論文では、様々な記法が前提知識とされて説明なしに使われているので、冒頭部分から理解できなかった。コンピュータ関係の論文なら、計算量を表すO記法などが説明なしで使われるだろう。この本も、一般書のように紹介され、販売されているが、専門書に近いものだと思う。きっと、ゲーム理論を学んだ人や、ゲーム理論の教科書を読んだことのある人ならば問題なく読めるのだろう。

「読書百遍、意自ずから通ず」という言葉があるが、私はこの言葉を素直に信じている人間である。このギンタスの本も、何遍も繰り返して読み、掲載されている証明を、紙と鉛筆で実際に追ってみれば、随分理解が進むかも知れない。それよりも、ゲーム理論の入門書なり、教科書なりを読んで勉強すれば、本書の内容も良く分かるのだろう。しかし、残念ながら、私にはゲーム理論をそこまでして学ぼうと言う気がない。そこで中断することにした、気軽に読める本ではなかったということなのだろう。

ただし、読んで分かったことはある。ゲーム理論は、プレーヤーがどんな方法で思考するかを想定して数式化し、様々な局面でのプレーヤーの行為を計算で求めて行く。計算で求めた答えと、実際の実験の結果が一致する場合が多い。それは、人間の思考パターンが、結果としてかなり単純なもので、異なる対象に対しても同じパターンが繰り返して使われているということを意味している。人は、ゲームを行う時に、様々に考えを巡らすのだが、出てきた結果は、統計的に見ると、単純な理論で説明可能である。これも、脳細胞の働きを詳しく解析するより、巨視的に人の行動を観察したほうが、より早く正確に規則が発見できるということを示しており、以前からブログで取り上げている、マクロレベルでの把握をミクロレベルでの把握で置き換えることはできないと言う主張の傍証になっているのではないだろうか。

今日は医療とコンピュータの両者にまたがる研究会があった。私は動的ウェブページのデバッグ技法について発表した。

動的ウェブページでは、ユーザの反応により生成されたページがユーザの操作や時間の経過といった要素で動的に変化する。不具合が発生しても、ユーザの反応は再現が困難で、不具合が発生した時にどのような画面が表示されていたのかも分からないことが多い。そのような場合、不具合の発生原因の特定は困難を極める。

ウェブページを記述する言語(HTML)や、それを動的に変更する言語(JavaScript)の本を見ても、デバッグに関してあまり記述がない。一般の汎用コンピュータ言語の解説書ではデバッグに関してかなりのページを割いているのと対照的である。ウェブページを開発する人の助けになればと思い、今回私のデバッグ方法を発表した。

私が使っている技術は2つある。ひとつは生成条件など、ウェブページを作成する際に必要としたデータをできる限りページ内に非表示で書き込んでおくことである。画面内に非表示の<div>要素を用意し、サーバでウェブページを生成する際に用いたデータや送信パラメタなど、書き込めるだけ書き込んでおく。勿論、大量のデータを書き込めばページの表示が終了するのに時間がかかるようになるから、書き込む量には自ずと制限があるが、非表示要素に書き込んだデータは画面に表示されないので、邪魔にならないし、ソースを表示させれば見ることができるので、確認に便利である。

もうひとつはJavaScriptを使って表示中の画面のソースをキャプチャする技術だ。JavaScriptにはタグを指定して内容を取得するユーティリティメソッドがある。getElementsByTagNameである。ウェブページは全体がひとつのHTML要素になっている。そこで、
t = document.getElementsByTagName('html');

とすれば、tに現在のページ全体の情報が保存される。このページ情報とはサーバから送信されたページではなく、その後にユーザの操作などにより変化し、現在表示されているページだと言うことだ。

私が示した例では、ページの上部に「バグレポート」というボタンを設置し、ボタンをクリックすると簡単な文章が入力できるウィンドウを表示すると同時に、その時点でのウェブページをキャプチャする。「送信」ボタンのクリックで入力したレポートと共にウェブページのデータをサーバに送信する。

ただし、tは配列になっていて、ページのソースはt[0]['innerHTML']にあること、ソースは容量が大きいことがあるので、POSTで送信する必要があることなどが注意点となる。

内富庸介・藤森麻衣子:編『がん医療におけるコミュニケーションスキル―悪い知らせをどう伝えるか〔DVD付〕』(医学書院)を読了した。『コミュニケーションスキル・トレーニング』と併せてコミュニケーション関係の本を2冊読んだことになる。両者とも2007年出版の本だった。

当然のことながら、内容的には、両者はよく似ている。ただ『がん医療~』の方は、コミュニケーションの場面をがん告知と、予後不良の告知に絞っているので、話が非常に具体的だ。例も、ドラマの脚本のような例が掲載されている。コミュニケーションスキルが学習可能なスキルであること、知識を持っているからと言って行動は変容しないことなど、本書でも指摘されている。

患者の扱いとしては、状況設定が限られていることもあってか、患者に対する配慮を中心としたものになっている。編者らは患者とのコミュニケーションを有効に行う要素をSHAREとしてまとめている。
S:Supportive environment。支持的な場の設定。患者の心を落ち着かせ、余裕を持たせるような面談環境の設定。
H:How to deliver the bad news。悪い知らせの伝え方。
A:Additional information。付加的な情報。日常生活への影響や、心配事、関心事などを打ち明けられる雰囲気作り。
RE:Reassurance and Emotional support。安心感と情緒的サポート。患者のみならず家族にも配慮する。

悪い知らせを伝える場合については以下のようなアドバイスがある。
悪い知らせを伝える段階では、まず、警告となる言葉をかけることによって患者に心の準備を促す。そして、悪い知らせは明確に伝えることが大切である。例えば、がんを伝える際には「がん」という言葉をきちんと用いて伝える。あいまいに伝えられることを望んでいる患者は少ない。ただし、1回の面談の中で何度も「がん」という言葉を繰り返すことは適切ではない。2回目以降は、「あなたの病気」や「この腫瘍」など言葉を置き換えることが望まれている。つまり、「悪性腫瘍」などの言葉では「がん」と捉えられない場合も少なからずある一方で、「がん」という言葉は患者の心には侵襲的であることから、一度明確に悪い知らせを伝えた後には、適切に婉曲的な表現を用いることによって患者への心理的負担を軽減する。(19ページ)

患者の感情への配慮をきちんと行うこと、家族への配慮も欠かさないことなど、参考になることが多かったし、癌患者のおかれている立場の解説なども、実際の臨床経験に基づく、リアリティの高い、説得力のあるものだった。

なお、編者らは前書きで、「がんが治らない局面では、医学的には目的は延命となる」と書いていた。揚げ足を取るつもりはないが、がんが治らない局面での目的はQOLの維持・向上が延命に優先するのではないだろうか。少なくとも、両者を並列で挙げてほしかった。

レジデントの研修評価管理システムのプロトタイプが完成し、デバッグ(プログラムの不具合を見つけ出し、修正すること)もほとんど終わった。少し機能を修正したい場合などがあり、ソースの少々修正し、デバッグしということを繰り返している。作成にはある程度まとまった時間、プログラミングに集中する必要があり、そのために他の仕事で溜まっているものがある。今後、その消化に力を注がねばならない。

バグとはプログラムの不具合であるが、コンピュータが誕生した初期の頃は、プログラムはキーボードから打ち込むものではなく、機械内部の配線を変更して行うものであった。つまりコンピュータは、配線さえ変えれば様々な計算ができる機械であったが、配線を動的に変更することは不可能なので、決まった計算しかできない機械だった。現在のコンピュータはプログラム自体を動的に修正しながら実行することが可能なので、別の機械と言っても良いような性能の違いがある。その初期のコンピュータがおかしな動作をしたので、中を覗いてみたら虫(英語でbug)がいたと言う訳だ。世界最初に発見された物質的な「バグ(虫)」の写真が日本語版ウィキペディアの「バグ」(http://ja.wikipedia.org/wiki/%E3%83%90%E3%82%B0)にある。

デバッグをしながら、人間の能力の限界について考えた。プログラムのバグは、プログラムを修正したときの修正漏れ、条件に対する考慮漏れ、境界値の取扱いに関する勘違いなどで起こるものが多い(もちろん他の要因による不具合もある)。それらはいずれも人間が作成中のプログラム全てを頭に入れられないことから起こると言っても良い。たとえば、ある部分の処理を修正したとする。同様の処理を行っている部分を修正し、その処理に関連した部分も修正して行くが、関連を思いつかなかった部分にも関連する部分があると、修正漏れとなりバグとなる。内部を解析して原因を見つけると、当然のことを間違えていたり、考慮し洩らしたりしていて「しまった」とか「なあんだ」となることが多く、システムの理解不足や言語の仕様上の問題に起因する「ほ~」とか「なるほど」と思わせるようなバグは少ない。この傾向は私だけのものではなく、様々な本を読んでみても普遍的なものである。

これは、人間の脳が機能を実現した仕方による限界なのだ。人間の脳は、非常に多くのものを記憶することができる。しかし、その記憶は連想に基づく記憶であり、ひとつひとつの事象を個別に覚えるのではない。たとえば、何かを暗記する場合、節を付けたり、語呂合わせでこじつけたりする。それによって情報量は増えているのだが、他の記憶と関連づけやすくなるので、覚えやすくなるのだ。また、人間の記憶は正確ではない。徐々に再構築され変成するし、そもそも事象を連想で覚えているので、間違った思い出し方をすることがある。

自分が作っているはずのプログラムも同様で、いっぺんに頭に入るプログラムの長さについては諸説があるが、画面上でスクロールなしに表示できる長さが良いとするものもあれば、紙1枚に印刷できるほどの量までなら完全に理解できるとするものもある。もちろん、プログラム自体の複雑性にも拠るから、何行と数値で示すことにはあまり意味はない。しかし、1,000行を越えるようなものでは、細部まで頭に入れるのは困難な場合がある。

このように、人間の理解の仕方はコンピュータの記憶の仕方とは全く異なっている。さらに、数の問題もある。2013年6月14日のScience FRIDAYでは、アレン脳科学研究所の主席科学者であるクリストフ・コークが「宇宙で一番複雑な物体を解析する」というような題名で話をしていたが(http://www.sciencefriday.com/segment/06/14/2013/decoding-the-most-complex-object-in-the-universe.html)その中で彼は、脳は約1千億個の神経細胞から成っているが、神経細胞の働きと、その接続を解析すれば(理論的には)脳の働きを解明できると言っていた。それが実質的に誤った考え方であることは既にブログで述べた。

1千億個の神経細胞に関する情報と、そのそれぞれが別の多数の神経細胞とネットワークしている状態を、有効な知識として人間の頭脳に保持することは不可能である。そこには何らかの抽象化が必要になる。

さらに、個々の分子の動きを調べても、氷が溶けだしているのか、固まりだしているのか判断がつかないように、超巨大な数の対象を解析する場合、個々の対象物の解析ではマクロな全体の傾向が把握できないのだ。量子力学の理論を展開しても、砂糖が水に溶ける様子を説明することはできない。マクロの現象を捉えるにはエントロピーのような、マクロの世界の理論が必要だ。脳も同じだと思う。いくら細胞を研究しても、なぜ人が喜ぶかはわからない。それよりも、愛、勇気、心配、悩みといった「マクロ」な心理学用語を使ったほうが、よほどうまく人間の心を説明し理解することができる。

ただ、コークが開発しようとしていたのは、脳の神経細胞をディスプレイのピクセルにマッピングし、感情や学習に伴う脳の活動を映像として可視化しようと言うシステムであった。活動を映像パターンに変換して認識することで、抽象化が起こる。そんなシステムなら、脳の活動を認識する助けになるだろう。

本日も18時から会議だった。当院のあり方を、周辺の医師会の会長たちや行政の関係者たちが集まって話し合う「運営検討会」だ。「公的」な立場の病院なので、周囲の医療機関や行政機関からの意見を聞き、それを当院の運営に反映させる。

冒頭、院長より現状報告のプレゼンテーションがあり、続いて庶務課長から詳しい統計的事項の発表があった。その後質疑応答に移ったが、当院の「公的」病院としての役割を堅持し、周囲と連携して圏域全体の医療の充実に励んでほしいというような意見が多く出された。現状をいかに改善してゆくかと言う話だった。

その中で、某自治体の担当者から、「医療と保健の結びつき強化が必要と考えている。何か強化のためになる研修などを企画しているか」というような質問があった。病院としては在宅移行が重要と考えており、在宅支援のシステムを立ち上げようとしていると答えていた。実際、6月24日より講師を呼んで研修会を開始しており、ゆくゆくは院内に組織を立ち上げる予定である。

しかしながら、昨日の会議でも感じたことだが、2025年問題を考えたとき、在宅移行や病病連携(病院どうしの役割分担による効率的な診療)では間に合わないという危機感が全員に希薄であると感じた。病人の数、急患の数、看取りを必要とする人の数が、明らかに当医療圏域のキャパシティ(医師数、ベッド数)を越える。必要な対策は「医療と保健の結びつきの強化」ではなく、医療が不足する状況でどう過ごすか(医療なしでどう暮らすか)を住民全体に考えてもらうことである。皆が何とかなると考えているような気がするが、何もしなければどうにもならない。何かをしなければ前に進まない。

内田は『死と身体』で、良くない予想をした場合、その予想が当たることを願っている自分がいると喝破している。予想が実現しないように必死で努力した場合、予想が実現しなくても、それが努力の結果かどうかは分からない。何もしなくても予想は外れたかも知れないと言う指摘に有効な反論はない。自分の予想が正しかったかどうか、確かめる唯一の方法は、何もせずに待つことだ。予想が当たれば、いかに自分に先見の明があったか、誇ることができる。しかしそれでは予想が何の役にも立っていない。私たちの世代には、そのような「評論家的態度」を最も忌むべきものとする意識があるような気がする。

私としては、風車に立ち向かうドン・キホーテよろしく、2025年問題対策について、具体的な提言を声を大にして繰り返して行く他ないのだろう。

そろそろこのブログも半年を経過する。中間のまとめをしようと思うが、その中で「提言」を整理しよう。

↑このページのトップヘ