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

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

2014年02月

福島県で働く内科医の越智小枝がウェブマガジン「JBpress」に連載している記事が面白い。このブログでも何度か取り上げたが、2014年1月23日配信の『現職が次々落選する福島県が教える“普遍的事実”―世界中で起きているリスクコミュニケーション問題に目を向けよう』(http://jbpress.ismedia.jp/articles/-/39746)も面白かった。

昨年(2013年)12月22日に福島県相馬市で市長選挙が行われ、現職有利の予測に反し、わずか200票差の僅差で現職の立谷秀清が辛勝した(4選)。立谷はメールマガジンを発行しており、医療ガバナンス学会のメールマガジンMRIC(http://medg.jp/mt/)でもしばしば取り上げられている。復興に早期から積極的に取り組み、大きな成果を挙げている。それが勝因であると分析されているが、それではなぜ「辛勝」だったのか。新聞では「東京電力福島第一原発事故後の対応への不満」が原因と分析している(http://www.asahi.com/articles/ASF0TKY201312220101.html)が、越智は国(政府)、地方自治体を含む「現状」への住民の不満が噴出した結果とみている。
「政府」という集団に対する不満は、福島に限ったことではありません。2011年6月に15歳以上の男女1200人に対し行われたアンケートでは、「災害時における情報源として最も信頼できないもの」につき、59.2%が「政府・省庁」であると答えています。
2010年の同じ調査ではこのように答えた人が22.7%でしかなかったことを考えると、福島第一原発事故が国民の政治不信に与えた影響の大きさがうかがえます。

越智はこの後、時系列で原発事故直後の政府の対応がいかに杜撰であったか(あるいは嘘にまみれていたか)を検証するが、「しかしこれは本当に日本特有の問題なのでしょうか」と問いを立てる。彼女の真価はこの点だろう。
この事態を傍観し、批判することは容易です。しかし人災であれ天災であれ、災害がある限り、私たちは何かを学ばなくてはいけないと思います。ではこの事件から私たちは何を学ぶことができるのでしょうか。

越智は「世界の様々な事件において、政府のリスクコミュニケーションの失敗には驚くほどの共通点が見られ」ると指摘する。彼女は2010年のメキシコ湾原油流出事故、2013年に米国東海岸を直撃したハリケーン・サンディ、英国の狂牛病問題と比較し、以下の共通点を指摘している。
1. 事件の中心となる産業が多大な国益をもたらす産業であった。
2. 政府の政策策定に協力した科学者が必ずしも十分な専門知識を持っていなかった。
3. 情報が出揃うまで政府が安全性を強調し続けた。

また、失策の原因として情報共有の悪さを挙げ、情報公開により事態が改善するという意見に対しては「少し楽観的すぎる」と反対する。公開する情報は客観的な科学的データでなければならない。しかし、その「客観的な科学的データ」はどのようにして得られるのかを考えていくと、いろいろ問題があることがわかる。
まず、どのような科学者が信頼できるかという判断は主観的であり、この価値基準は国ごと、あるいは政治家個人によっても大きく異なります。
例えば米国では知識の豊富な専門家が招聘されることが多く、英国ではこれまでの社会貢献度の高い者が御用聞きとなる傾向が高いといいます。また日本においては、原発事故の参謀が最初首相の人脈のみで構成されたという報告もあります。
さらに、「信用のおける科学者」を選定した結果、そのグループの利権に不利な研究は発表されない、あるいは行われないという結果が生じます。福島原発の後、英国のネイチャー誌に掲載が決まっていた「放射性物質の海洋環境への影響」に関する論文が、所属機関長の許可が下りずお蔵入りとなったことは有名な話です。

つまり、科学者がデータ解析の結果を示しても、それが妥当であるか判断することは困難であり、しかも、別々の科学者が別々のデータを出してくる可能性もあるのだ。難しい病気の診断に似ている。

もちろんここで越智は結論を出しているわけではない。上記のような事実を踏まえ、すこしずつでも賢くなっていこうと訴えている。

1997年夏に創刊され、2005年まで続き、現在は廃刊になっている雑誌『季刊・本とコンピュータ』の6号(1998年秋号)の「わたしはコンピュータのここが嫌いだ」で、仏文学者で映画評論家の中条省平が以下のように述べている(一部省略)。
コンピュータは一見メカニカルな技術の集成のように見えますが、コンピュータ操作に関わる環境は、そうした機械性にいわば秘教的なヴェールを掛けているように思えます。[中略][マニュアルを読んでもわからないので]しかたなく、知りあいの先輩などを頼って手ほどきを受けるわけですが、この口から耳へ、手から手へ、というほとんど中世的なイニシエーションの階層性がどうにか改善されない限り、コンピュータに対するぼくの(無用の)嫌悪感は消えないと思います。(126ページ)

この文を読んだ当時、最も未来的であるコンピュータを使うのに、中世的な技術伝授が必要となっているという指摘に、言い得て妙だととても感激したのを覚えている。当時はコンピュータの使用法について、よく知っている人に弟子入りするのが早道だった。最近では、タブレット端末など、マニュアルを見ないで使い始める人も多い。ユーザインタフェースについてはずいぶんと進歩した。しかし、ソフトウェアの開発においては、中世的な徒弟制度がまだまだ大きな役割を果たしている。4月になるとコンピュータ関係の雑誌は新入社員向けの特集を組むことが多いが、「どのようにして技術を盗んだか」「どのように先輩の後ろ姿を見て育ったか」などを伝授する記事が必ずあることをみても、どこの会社でも似たような状況であることがわかる。

私について言えば、システム開発はほぼ独学である。システム開発とはかけ離れた職場で、偶然システム開発にかかわるようにあったのであるから、仕方がない。UNIXが日本に導入されたときにはそのようなことが多かったのだろう。『rootから/へのメッセージ』(アスキー)の著者の高野豊も、そのようなことを書いていた。したがって、進歩は遅い。孤独な環境で開発を行っているプログラマは、入手できる情報が極端に少ない。現在はインターネットがあるので、かなりの情報が手に入るが、それでも問題が解決不可能なことがある。入手可能な範囲のあらゆる対策を講じても、プログラムが思い通りに動かないことがあるのだ。

周囲に自分より経験を積んだ人がいれば、その人に教えを請うことができる。そのような人がいなくても、同僚にソースコードを見せたり、極端な場合は相談のために説明しているだけで問題が解決することがある。孤独であれば、そのような機会には恵まれない。その場合は、そこで時間をおくしかない。時間をおけば、原因に気づくこともあるし、新しい対策を知ることもあるし、回避手段を思いつくこともある。

ミチオ・カクは『2100年の科学ライフ』(NHK出版)で科学文明が発達した未来におけるソフトウェアの重要性について語っている。
じっさい、ソフトウェアが今後ますますハードウェアより重要になっていくだろう。コンピュータチップは価格が下がりつづけており、いずれトラック1台分いくらで売られるようになる。一方で、ソフトウェアは昔ながらのやり方で構想を練らなければならず、人間がじっと座ったまま鉛筆と紙を使って作業する必要がある。ノートパソコンに保存されたファイルには、貴重なプランや原稿やデータがあって、何十万ドルもの価値があるかもしれないが、ノートパソコンそのものには数百ドルの価値しかない。もちろんソフトウェアは簡単にコピーして大量生産することができるが、新たなソフトウェアの開発はそうはいかない。それには人間の思考が必要なのだ。(397ページから398ページ)

カクはソフトウェア作成(プログラミング)を「人間の創造的活動(151ページ)」であると言う。そうであれば、徒弟制のような形で学ばねばならないのもわかる気がするし、独り我が道を行くのも、それなりの価値があるような気がする。

日経ヘルスケアに「厚労官僚の独白」という匿名のリレーコラムがある。以前にもこのコラムを批判したことがあるが、今回もまた腹が立った。2014年2月号の記事の題名は『目先の改定を追う経営からの脱却を』である。
改定を間近に控えて各医療機関が慌ただしい時期を迎える中、筆者はあえて問題提起をしたい。今の診療報酬改定に沿った経営が、10年後や20年後も地域の医療需要に合致しているのかどうかということを。

「無名指」とサインした匿名子は「地域の高齢者の人口推移は今でも簡単に予測できる」とし、地域の医療需要に合った医療経営を進めるべきだという。そしてコラムをこう結んでいる。
目先の点数の増減にばかりこだわり、明日の収入を確保することを考えるだけいいのだろうか。今、たくさんの住民が地域にいたとしても、同様の状況がこれからも続くとは限らない。この先、地域によって医療需要が大きく異なるからこそ、目の前の診療報酬改定に沿って慌ただしく対応しているばかりでなく、確実に予測できる将来の環境を見据えた医療経営もぜひ同時並行で進めていってほしい。

実は、この論旨は私が今までブログで述べてきたことと似ている。匿名子は「将来の経営」について言及しているが、私は将来の医療と言ってきたところが違う。われわれは、将来を見据え、何が必要とされ、何を供給するべきなのかを真摯に考える必要がある。どこかの医師がこのように言ったのであれば、私は喜びもしただろう。しかし、こんなことを厚労官僚に言ってほしくない。

診療報酬で医療を制御しよう(あるいは支配しよう)としているのは、他ならぬ厚労省である。今回の診療報酬改定で、急性期病院を「整理」しようとしているのは、まさにその手法である。厚労省が医療費の削減を目論んで診療報酬を改定してきた結果、病院の経済状況は悪化している。雑誌「病院」2014年1月号に掲載された猪口雄二『都市部(特に東京)における病院医療の課題』によれば、特に東京には赤字病院が多い。
全日本病院協会が毎年行っている経営調査によれば[中略]2002年を除いて、東京の赤字率は常時高くなっており、2003年より暫くは経営状態が悪い。特に2006年は最悪で61%の病院が赤字なのである。(33ページ)

そのような状況で、消費税増税に追い打ちをかけられ、診療報酬改定が実質マイナス改定になろうとしているのに、「目先の点数の増減にばかりこだわり…」云々とは、余りに無責任な言い方ではないか。このように言うのであれば、逆に10年後、20年後の医療需要を見据えて、それに合った診療報酬改定をするべきだろう。少なくとも「調べればわかるだろう」という態度ではなく、政策立案者としてしっかりした展望を示し、将来の医療のあり方について医療側に提言するような態度が欲しい。

もちろん彼らにそのようなことができるとは思っていないのだが、少なくともそのような「態度」でいることを求めている。

ウェブページは表示に時間がかかってはならない。コンピュータが何か処理を実行する場合、かならずいくらかの時間がかかっているのだが、それをユーザに感じさせることは良くない。

Steve Souders『続・ハイパフォーマンスWebサイト』(オライリー・ジャパン)によれば、ユーザが画面上のオブジェクト(ボタンやメニューなど)を直接操作していると感じられる反応時間の限界は0.1秒、ユーザがコンピュータに不当に待たされていると感じることなく、操作空間を自由に行き来している感じられる時間の限界は1秒だそうだ。
0.2秒から1.0秒の遅れがあるとユーザーは遅延に気づくため、コンピュータが自分の操作に対して「ダイレクトに応答している」というよりは、コンピュータが命令に対して「処理を実行している」と感じるようになる。(12ページ)

処理に1秒以上かかる場合は、カーソルの形状を変化させてコンピュータが処理中であることを伝えることが推奨されている。進捗状況を表すプログレスバーを表示するのも良い。ちなみに、ユーザがタスクに対して集中力を維持できるのは10秒が限界で、10秒以上待たされたユーザは作業に戻っても他のことを考えている可能性がある。

したがって、ウェブページの開発者は、いかに「早い」(短時間で表示される)ページを作るかに腐心する。しかし、ウェブページのデザインも内容も充実させようとすれば、データ量が増大する。機能を高めるためにデータベースから情報を取得しようとすれば、さらに時間が増加する。そこで利用されるのが「非同期通信」だ。

ウェブページは上(先頭)から順に表示される。表示したいデータの取得に時間がかかると、そこで表示が止まってしまう。そこで、データを取得する作業を、表示とは無関係(非同期)におこない、取得できていないデータは飛ばして、その先を表示する。飛ばしたデータは取得できてから表示する。そうすればページは早く表示される。そのための仕組みが非同期通信で、もっぱらJavaScriptを使用しておこなわれる。

ウェブページ作成者、ウェブアプリケーション開発者にとって、非同期通信の重要性はますます高まっている。jQueryには当初から非同期通信を支援する仕組みがあったが、バージョン1.5から、非同期通信を含む遅延実行を管理するdeferredというクラスが実装されている。「遅延実行」とは文字通り遅れて実行されるコード(プログラム)で、非同期通信に限らず、実行してしばらく時間が経ってから結果が返ってくる作業を言う。

遅延実行は便利ではあるが、管理が難しい。複数のコードを非同期に実行している場合、どの順番で結果が返ってくるかわからないし、エラーなどにより結果が返らないかもしれない。また、あまり時間が経つと(別のページに移動したりで)、結果が不要になる場合もある。そのような状況を管理するのがdeferredクラスと、関連するdeferredライブラリだ。deferredクラスを使って遅延実行をおこなうと、promiseというオブジェクトが返される。これは、遅延実行そのものをオブジェクト化したもので、promiseを作っておけば、あとは結果が返ってきた場合もエラーが起こった場合も、promiseに登録した関数が処理してくれる。promiseは引数として渡すことも可能だ。そのために非常に柔軟な処理が可能になっている。

Terry Jones、Nicholas H. Tollervey『Learning jQuery Deferreds: Taming Callback Hell With Deferreds and Promises』(O'Reilly)はjQuery deferredについて入門から高度な応用まで、著者らが実際の現場で経験した状況を例として解説する本だ。応用としては、単なる「凝った使い方」にとどまらず、jQueryに実装されている関数の拡張をおこなう。たとえばdeferredライブラリには$.whenという関数があり、複数のpromiseの管理ができるが、ひとつでもpromiseがエラーとなると、$.when自体も終了してしまう。本書では、全部のpromiseについて、エラーになるか結果が返るまで終了しない$.when2を作成する。本書で作成する関数を実装すると、jQueryのライブラリがかなり強化される。

また、随所に挿入されている演習問題は、ただ解法を求めるのではなく、バグを探させたり、理由を述べさせたりと、deferred(遅延実行)の本質を考えさせるための訓練になっている。deferredを理解させようという著者らの熱意が伝わってくる。

本書はすべてのウェブページ作成者、ウェブアプリケーション開発者にとって非常に有用な本だろう。

Terry Jones、Nicholas H. Tollervey『Learning jQuery Deferreds: Taming Callback Hell With Deferreds and Promises』(O'Reilly)を読了した。jQueryバージョン1.5から導入されたdeferred API(deferred.js)について使用法から拡張まで、詳細に解説した本だ。

まず、予備知識としてウェブページで使われるJavaScriptとjQueryについて説明しておきたい。ブラウザでウェブページを表示した場合、さまざまな動きが表示されることがある。もともとのウェブページには動きがない(ウェブページを記述するHTML言語には動きを表す方法がない)。そこに動きを持ち込むには大きく分けて2つの方法がある。1つは動きのある画像を埋め込むことだ。初期の頃はGIF(ジフ)アニメーションしかなかったが、現在はAdobe Flash(アドビ・フラッシュ)を用いてビデオ映像も埋め込むことができる。

もうひとつはプログラムを用いて画面の構成要素(エレメント)を変化させる方法だ。ブラウザ上で実行できるプログラミング言語は複数あるが、現在はほとんどJavaScriptに統一されている。JavaScriptは画面の読み込みと同時に実行されたり、時間の経過やユーザの操作によって起動されたりして、エレメントを移動させたり、消したり、表示したりといった画面操作だけでなく、ユーザとやり取りしたり、サーバと通信したりもできる。

jQueryはそのような頻繁に行われる作業を簡単に記述できるように作成されたJavaScriptライブラリである(http://jquery.com/)。たとえば、画面内にアニメーション付きでエレメントを表示する場合、普通にプログラムを書くとかなりの行数になるが、jQueryではエレメントの後に.fadeIn(200)と付けるだけで200ミリ秒(0.2秒)のフェードイン(徐々に現れる)が実現できる。

JavaScriptライブラリは一時期さまざまなものが競っていたが、現在ではjQueryが圧倒的に多く使用されている。Web Technology Surveyという調査サイトの統計では、2014年2月23日現在で、JavaScriptライブラリを使用しているウェブサイトが調査対象の62.0%で、jQueryを使用しているサイトは57.8%だった。 JavaScriptライブラリを利用するサイトの93.2%がjQueryを使用していることになる(http://w3techs.com/technologies/overview/javascript_library/all)。傾向を追ってみると市場占有率は徐々に上昇しており、jQueryがデファクトスタンダードになったと言っていだろう(http://w3techs.com/technologies/history_overview/javascript_library)。ちなみにWeb Technology SurveyはAmazonの関連会社が公表するウェブサイト人気ランキングの上位1千万サイトを自動解析しており、統計的な信頼性は高いと見なすことができる(http://w3techs.com/technologies)。

JavaScriptはブラウザによって実行されるプログラミング言語なので、ブラウザによって少しずつ仕様が異なる。また、画面のエレメントの表示も、大きさの測り方が違ったりする。同じウェブページが、ブラウザによって違って表示されては困るので、ウェブページ開発者は実行中のブラウザの種別を判別して動作を変えるプログラムを書くのだが、開発者にとってそのようなブラウザの違いを吸収するコードを書くのは大変な作業だ(特にInternet Explorerは独自仕様が多く、開発者泣かせだ)。初期のJavaScriptライブラリは、そのようなブラウザ間の差異を吸収するのが大きな目的のひとつだった。

現在のJavaScriptライブラリは、JavaScriptで実現できることを、より簡単に、正確に実行できるよう、便利な部品を用意するものになっている。jQueryはその中でも、仕様が簡単で使いやすく、一部だけに使用することが可能、他のライブラリとの併用が容易などといった特徴があって利用者を伸ばした。現在jQueryは基本ライブラリのような位置を占めており、その上に重ねて使うようなライブラリも登場している。jQueryUI(カレンダー入力やアコーディオン型のリストなど、新しいユーザインタフェースを導入するライブラリ)はjQuery自体の派生であるが、AngularJS(HTMLをテンプレートとして用いる、新しい形のライブラリ)はまったく独立して開発されたものであるにもかかわらず、エンジンとしてjQueryを用いている。

「予備知識」の説明だけで長くなってしまった。次回はdeferredについて、さらに本書の意義について説明したい。

↑このページのトップヘ