2004年3月の技術日記

CVSの後継ということで、Subversionを試す。
RPM や apt が依存関係の問題で簡単に入りそうも無かったので、自分でコンパイル。
環境はVMWareの中のDebian-woody。

まず、BerkeleyDB 4.2.52 を configure - -prefix=/usr でインストール。
あとはINSTALLに書いてあるとおりにApache2からAPRをコピーしてきて、
Subversion 1.0.0 を configure - -prefix=/usr でインストール。
大変だと書いてある割には簡単に入った感じ。

export LC_ALL=C としないと動かないらしい。

svn鯖は svnserve+sshのポートフォワーディングを採用。svn+sshは、自分のやりたいアクセス制御がやりにくそうだったので、 ssh -L 3690:foohost:3690 user@fooserver でトンネルを作って、svn (command) svn://localhost/somerepository でアクセスすることにした。WebDAV版は、WebDAV自体のパフォーマンスが良くなさそうだったのと、設定項目が多かったので今は見送り。将来CVSViewが必要になったときに考えることにする。

しばらく、CVSで管理していたファイルをSubversionに移していろいろ試してみる。ディレクトリやファイルを心置きなく移動できるのが気持ちよい。CVSだったら、一旦作ったディレクトリは将来ずっと残るし、ファイルを移動すると移動前の情報が消えてしまうので後でどこからやってきたファイルなのか調べるのが大変。自分のような整理が苦手で、後でいろいろファイルやディレクトリを移動してしまうような人には大変便利。また、結構たくさんのファイルを入れたり出したり移動したりしてみたけれど、今のところほとんど問題は起きていない。

ということで、自分的にSubversionの正式採用が決定された。

長かった確定申告の書類作成が終わった。最後は親切な（見かねた）税務署の方と一緒に、ややこしい状況を解決して何とかまとめることが出来た。今回の敗因は以下のよう。

• 日々の記帳の努力が足らなかった
• 自分への資金の移動を良く分かっていなかった

後者は法人の場合と勘違いしていたため、専従者給与で何とかするのだと思っていろいろ考えすぎていた。実際には事業主貸で何とかするのだと教えられて解決。バランス表とPL表を修正して完成。会計のソフトは作れても、経理や確定申告のノウハウはまだまだこれからということで。

日々の積み重ねが重要だということは何にしても重要。とはいっても、日々の積み重ねほど難しいものは無いと思う。伝票、領収書だけでなく、部屋や論文やパソコンの中に日々溜まり続けている情報なども整理しなければいけないと思うのであるのだけども、どうしても今すぐやらなければならないことを優先しないといけないので、そのうちTODOリストの下のほうに流されてしまう。解決には、TODOリストを「すぐやること」「やるべきこと」などの2つ作るという手や、週に1日「〜をやる日」と決めるのがいいらしい。

とうとう自分も内容証明を送る立場になった。それ以外にもいろいろと事務処理が発生して、なんだか経理だけで日々の業務が終了してしまいそうな勢い。秘書でも雇いたい気分ではあるのだけども、確定申告によって自分にはそんな収入も無いことがよく分かった。

各ページが横書きなのに、右から左にページが進んでいく（つまりページが反対）冊子を見る機会があった。素人（プロではない人）が作った卒業文集みたいなものなのでしょうがないと思ったのだけれども、聞けば以前からずっとこの方式らしい。しかも誰もおかしいと思わない（指摘できない環境）ということらしい。

このような事例は印刷だけにとどまらない。技術の進歩によって機能が容易に実現できるようになったが、一方でその操作性や分かりやすさの研究や教育はあまり進歩していない。広くはユーザビリティーという分野でいろいろと研究されている。WebのユーザビリティーではJakob Nielsen博士のAlertboxが有名。重要なことは「相手のことを考える」ということ。

AlertboxではFlash: 99％有害やウェブでのマルチメディア・ガイドラインのように時代に逆行しているようなかなり厳しい指摘もしているが、これらは非常に的を得た考察から導きだされた主張である。しかし、これらの主張を素直に誤解してしまう人が多いらしい。例えば、デザイナーが言いたくて口に出せない事 (by プライベート ジャイアン)によると、

• Flashが悪いのではなくてFlashコンテンツの開発者の問題である
• また、ユーザビリティーだけの視点でFlashを否定するヤコブ・ニールセンの主張は近視眼的だ
• 「使いやすさ」はデザインのほんの一部の要素でしかない

と主張されている。他にもヤコブ・ニールセンの主張に反対する人が多い。これは誤解か、本気であればデザイナーとして間違った態度だと思う。

Flashが駄目な原因

Flash自体は道具でしかなく、Flashコンテンツを開発する人の能力が直接的な原因である。そういう意味で、世の中のほとんどのFlashの使われ方が有害であると主張されている。実際にFlash: 99％有害の冒頭では次のように述べられている。

めったにないことだが、よいFlashデザインというものも存在する（時にはサイトの価値を高めるのに役立っていることさえある）。だが通常は、Flashを利用するとユーザビリティは低下する。・・（中略）・・

Flashは以下の3つの点でユーザビリティを損なう傾向がある。まず、デザインがやり過ぎになる。また、ウェブの基本的なインタラクション原理からも逸脱している。さらに、サイト本来の価値から注意がそれてしまう。
(Flash: 99％有害)

ということで、Flashはうまく使えば有効であるが、ほとんどの場合は駄目になる傾向があると主張している。そして、そうなってしまう根本的な原因について次のように述べている。

Flashの制作が安価で済み、さらに、コンテンツ制作者全員が標準のウェブページを書く時と同じくらい使いやすいFlashオブジェクトを作ることができるのなら、これらの問題の多くは軽減されるだろう。
(Flash: 99％有害)

つまり、

• Flashの開発コスト ＞ HTMLで書くコスト
• Flashで使いやすいサイトを作れる人数 ＜ HTMLで使いやすいサイトを作れる人数

ということから、Flashでサイトを構築した場合は、相当コストをかけないと内容も使いやすさも良いレベルに達しないから駄目だと主張している。なので、Flashは多くの場合、サイトのユーザビリティを駄目にしてしまう傾向があるので、めったに使うべきでないという主張である。

実際、Flashでなければ表現できない情報はほとんど無い。また、たとえFlashでなければ表現できない情報があったとしても、そのインタフェースには十分な注意とコストを払ってデザインするべきであるが、多くのFlashサイトを見る限りそのような特別な注意が払われているように思えない。よって自分は、Flashを使っているサイトは表面的なデザインにしか意味が無く、たいした内容を含んでいないと一方的に思っている。

デザイナーの仕事

ヤコブ・ニールセンが本当に言いたいことは、「表面的なデザインに凝る前にもっと考えたり他にやるべきことがある」ということのはずである。単にFlashや凝ったデザインを否定しているわけではない。「他にやるべきこと」とは、例えばFlash: 99％有害によると、

• 継続的なアップデート
• 内容の質の向上・維持
• デザイナーが顧客のビジネスについてより理解すること

だと書かれている（自分的意訳）。必要最低限の情報を見やすく配置する「デザイン」は「内容」に含まれていると考えるべきであろう。

では、「必要最低限」とは何かということになるが、標準的なWebブラウザがサポートする文書構造タグやスタイルシート、また「内容」としてのマルチメディアファイルなどであろう。これらは複雑な技術はほとんど必要ないため比較的簡単に導入できるだけでなく、これだけで十分見やすいサイトが構築できる。また、メンテナンスも容易なので継続的なアップデートも可能である。

目的が情報提供にあるのなら、お金をかけるところは表面的なデザインだけでない。誰の何のためのデザインかを忘れ、顧客や訪問者の利便性を考察せずに、自分の独善のみでデザインしてしまうことは、プロのデザイナーとしては良くないことだと思う。芸術家としてはありかもしれない。顧客のためのデザインであるからこそ、顧客の言うことに耳を傾け、議論を重ねて仕事をするべきである。客が変なことを言っていても単に否定するだけでなく、なぜそんなことを要求したがっているのかを理解して適切なアドバイスをするべきである。

ユーザビリティは必要条件か？

「ユーザビリティだけの視点によるFlash否定が近視眼的だ」と言うことについてもおそらく誤解だと思われる。

ヤコブ・ニールセンの用いる「ユーザビリティ」は、ユーザビリティとは？(@U-site)にあるとおり、単に操作性のことを言っているのではなく、「そのサイトが実現しようとしている目的の達成度合い」を指している。これはつまり、操作性や分かりやすさだけを指しているのではない。実際に、ユーザビリティを単に操作性だけだと思ってAlertboxを読むと意味が怪しくなる。

なので、おそらくユーザビリティを否定する人は、単に操作性だけをユーザビリティだと誤解しているのだと思う。目的の達成度合いがユーザビリティだとすれば、ほとんどのサイトにとって、ユーザビリティは良いサイトのための必要十分条件であると思う。

シンプルで飽きが来ないものは、無駄な装飾が無いため最初から本質が見えている。本質を見極めて選んだものは、必要とされている限り使われ続ける。逆に表面的な装飾で選んだものは、装飾の有効期限内でしか必要とされない。

ということが、上の議論から理解できた。

PCパーツの買い物をした。FDドライブも買ったつもりが、送られてきた箱には無かった。また、Pentium 4 の 3.0GHz ではなくて、3.2GHz が入っていた。多分、お店のサービスだろう。

ということで、Linuxを入れたいのだけども、予定が代わってフロッピーディスクが使えなくなったので、急遽インストールCDを作らなければいけなくなった。近所にはPowerBookG4のCD-Rドライブがあるので、これを使うことにした。

• cdrecord をインストールする。（$ fink install cdrecord）
• 適当なブート可能ISOファイルを取ってくる。
• 生CD-Rを入れて、「無視」を選ぶ（マウントさせない）
• cdrecord -v -data dev=IODVDServices 〜.iso

とりあえず、これでブート可能CD-ROMが出来た。つまりOSXだからということは無くて、あんまりその辺のUNIX系機械と変わらないみたい。

今回の物理学会の物理教育セッションでは、いつもの教材デモの他に教材作成支援なるものがあった。内容は、チャット機能とファイル共有空間の提供という感じで、オーサリングの機能はなし。主にWebページや紙の文章作成支援という感じであった。実際のオーサリングはWordやTeXでやるということで、個人的にはまだまだこれからという感じを受けたが、似たようなものを3年前に未踏で作った身としては、このような教材作成支援・管理・運営ツールの重要性が認知され始めたことはよいことだと思う。

自分がいろいろやってきたり、人と話をしてきた過程で思っていることは以下のよう。

• 単なる Web Based Training のようなほったらかし的な教材は教育として意味がない（トレーニング・訓練としては意味がある）
• 単なる「おもしろい教材を作りました」は、現在山のように似たようなものが溢れていることから、あんまり必要とされていない
• 必要とされているものは授業のHOWTOであり、教材よりは授業の中でどのように教材を活用してどうだったかといった事例が重要
• コンピューターを使った授業はほとんどが個人による実験的なもので、普及にはキラーアプリ（決定的な教材と授業方法）が求められている

ということだと思っている。さらに開発者側の役割として

• 今までにない面白い教材の開発。
• 実際に授業で使ってもらう。またフィードバックを開発に生かす。
• 思いついたアイデアを簡単に実現できるような仕組み、もしくは必要な教材を探し出す仕組みの開発

が重要なのだと思っている。

個人的には携帯電話上でのプログラムはあまり好きではない。というのは、進化の激しい業界なので、雇われる^(*1)か携帯電話マニアもない限り、作ったプログラムが無駄になってしまうので手を出すべきではないと思っていることから。

なので、携帯電話で物理教材も否定的な意見を持っていたのだけど、学会の発表を見てそうでもないかもと思った。携帯電話に限らずコンピューターを使った教材においては、普通の黒板中心講義では出来ないような何かすごいものを見せるというのが一般的な方法となる。例えば、自分のかかわった力学や統計力学のサイトでは、すごくはないがとりあえず「動く」。しかし、携帯電話の能力ではこういったことは難しいし、パソコンで出来ることをそのままやっても意味はない。携帯は気軽さが売りなのでそれを生かした物を作れば受けると思う。

携帯の能力ではグラフの表示や簡単な微分方程式の数値解を解くこと程度がせいぜいであるが、単にこれだけを実装しても面白くない。ゲーム性や、講義でうまく活用できるような要素を付加することが必要であろう。以下、適当に考えてみた例。

携帯物理教材例：アドバンスド・モンキーハンティング

モンキーハンティングを携帯アプリで作る。

目的

モンキーハンティングゲームをクリアする道具として物理法則とその解法を教える

プログラムの仕様

・標的までの水平方向の距離と、高さをランダムに表示する

・角度と速度を入力してもらうと、シミュレーションスタート

・アニメーションする（省略可）

・あたったか、外れたかを判定

・レベルアップする（後述）

使用方法

授業で、モンキーハンティングの概要を教える

授業中におもむろに誰か一人に接続してもらって、出てきた距離と高さを発表させる

先生がなにやら手計算、その角度と速度を入力させる　→　当たる　→　一同「おぉっ！」（多分）

すかさず微分方程式を教える　→　実は角度さえ合えば当たることが分かってちょっとがっかり

とりあえずモンキーハンティングで遊んでもらう。

突然レベルが上がって運動に空気抵抗が入る　→　一同悩む

ここで数値計算を教える

自分で計算させてまたしばらく遊んでもらう

さらにレベルが上がると、なぜか弾が荷電粒子になって電場や磁場などの外場が・・・

このゲームが受け入れられるかどうかは分からないけども、要は「ゲームを解く鍵を物理法則にして、その解法を教える」という形にすればよさそう。単にゲームを作るだけではゲーム慣れした世代にはなかなか受けないし、仮に面白いものが出来たら授業中に携帯から帰ってきてくれなくなりそう。頑張ればどの分野でも応用できそうだけども、こんなことまでしなければ勉強しないのかという話も。