携帯電話をシルバーのPENCKからブラックのMEDIA SKINに変更しました。
シルバーのPENCKは使用期間２年を過ぎ、表面のメタル塗装がはがれかけてみっともなくなり、はがれてきた銀色の塗装が手や服を汚すようになっていました。
今回の機種変更ではキャンペーンやらauのポイントやらでほとんどお金がかからなかったのですが、ついでに買った512MBのMicroSDカードが3000円足らずだったことに最も驚きました。
やっとワンセグにもおサイフケータイもFMラジオにも対応しましたが、有楽町ビックカメラの店員さんが言っていたとおり数字キー「３」のすぐ上に「POWER」ボタンがあり、メール入力中にうっかり押してしまって、何度もメールが消えました。
正確には、POWERを押しただけでは消えないのですが、「終了しますか？」の確認画面でどう操作すればキャンセルになるのかわからず、けっきょくキャンセルの方法がわかりません。
店員さんによれば、MEDIA SKINは表面が削れても中まで同じ色だそうです。
ディジタル放送の現状についてもっと知っておこうと思ったこともあり、ラジオとアナログテレビ対応PCしか持っていなかった私が、テレビとDVD/HDDレコーダーを買いました。
テレビは店頭でチェックして、レコーダーは石丸電気のオンラインショップで人気を確認して、最後は楽天のムラウチでオンライン注文。
最初はアナログ放送しか受信できず「せっかく買った機器の機能がぜんぜん使えなくてもったいない」「ぜんぜん面白くない」という状況でした。
昨日、UHFのアンテナを買って、やっと受信環境が整いました。
DUCA を窓の外の手すりに無事に固定することができました。室内に置くと地上デジタルのNHKが入りにくかったのですが、窓の外に出せば大丈夫でした。
20インチのテレビは店頭で見るととても小さく見えましたが、置き場所を考えるとこれでよかった、と思いました。
たしかに、NHK地上デジタルのデータ放送で、字幕がついていない生番組はたくさんあります。
やっぱり字幕はついてないなあ、と思いながら見ていた討論番組で自民党の舛添要一さんが「舛添ですけど」と前置きして発言していました。この番組がラジオでも同時放送されていることを意識していたのでしょうか？
WIT研究会でも論文作成・発表アクセシビリティガイドラインの中で
というお願いをしていることを思い出しました。
8月3日および4日に第37回福祉情報工学研究会が開催されました。
8月4日のお昼には専門委員会が開催され、私は幹事として参加しました。
8月4日の午後には情報処理学会福祉情報システムフォーラムによる特別企画:“いま，そこにある”コンテンツのユニバーサルデザインが開催されました。
80人くらいの参加者にお越しいただき、視覚障害や聴覚障害をお持ちの方も多く参加されました。
シネマ・アクセス・パートナーズ(CAP)の平塚さんは、映画の音声ガイドを作る作業の実情について詳しくお話をされました。
日本点字図書館の天野さんは、視覚障害者用DVDプライベートホームシアターサービスの概要についてお話をされました。あとでお聞きしたら、音声ガイドのMP3ファイルとDVDの映像を同期して再生をするソフトウェアを開発するために、Vector でオンラインソフトを開発している人にメールを書いてコンタクトを取り、プログラマーを見つけたのだそうです。
キュー・テックの川野さんは「ウェブ・シェイク」という仕組みでDVDコンテンツの字幕を第三者の立場から提供されています。しかしその背景にあるのは「きちんと字幕をアーカイブすればどんなメディアにでも再利用できる」という考え方とのことでした。
聴力障害者情報福祉センターの森本さんは、放送済みのテレビ番組に字幕をつけたビデオやDVDを制作し、全国の聴覚障害者に無料で貸し出しをする事業について説明されました。
映画のバリアフリー化について最近もこんなことがありました。
でも、当事者の方々が本当に見たいのは福祉や障害をテーマに扱った作品ではなく、普通の作品なのだそうです。
多くの人が、ラジオや新聞ではなく、テレビやDVDなど「音声と映像の複合メディア」から情報を得るようになってきました。そのことが、視覚障害や聴覚障害をお持ちの方にとって新たなバリアを生んでいると思われます。
静岡大学の秡川先生からは情報保障の考え方について新しい視点を提供していただきました。
最後に毎日新聞の岩下さんから、総務省の研究会などに参加された立場を踏まえての御発言がありました。
7月31日から8月3日まで京都大学で「音声認識・音声対話技術講習会」があり、私は最終日で「ISTCソフトウェア紹介」というテーマの時間をいただき、ソフトウェアの実演をしました。
私がGalatea Projectで開発を担当しているGalatea Toolkit Linux版の紹介をしました。主に VoiceXML による対話シナリオ記述について御説明して、まだ正式対応ではありませんが Windows 環境で VoiceXML のシナリオを実行してデモを行いました。
実演で御紹介したソースコードをいくつかお見せします。
以下は PHP で動的にVoiceXMLを生成する例です。
<?php echo '<?xml version="1.0" encoding="utf-8"?>' ."\n" ?> <?php mb_http_output('utf-8') ?> <vxml version="2.0" xml:lang="ja"> <?php if(isset($_REQUEST['region']) && $_REQUEST['region'] != '') { $region = $_REQUEST['region']; mb_convert_variables("UTF-8", mb_detect_encoding($region), $region); ?> <form id="answer"> <block> <log>地域：<?php echo $region ?>，今日：晴れ，明日：曇り</log> <prompt> 天気予報です。 <?php echo $region ?>の、 今日の天気は晴れです。 明日は曇りです。 <break/> </prompt> <goto next="#ask"/> </block> </form> <?php } ?> <form id="ask"> <field name="region"> <prompt timeout="20s"> 天気を聞きたい地域を、東京、横浜、京都から選んでください。 </prompt> <grammar version="1.0" root="#region_rule"> <rule id="region_rule"> <one-of> <item> <token sym="まいくてすと">マイクテスト</token> </item> <item> <token sym="とうきょう" slot="region">東京</token> </item> <item> <token sym="よこはま" slot="region">横浜</token> </item> <item> <token sym="きょうと" slot="region">京都</token> </item> </one-of> </rule> </grammar> </field> <block> <submit next="<?php echo basename(__FILE__) ?>"/> </block> </form> </vxml>
また、以下は PostgreSQL とも連携して、音声認識文法も動的に生成し、出力する情報もデータベースから取得して読み上げる例です。
<?php echo '<?xml version="1.0" encoding="utf-8"?>' ."\n" ?> <?php mb_http_output('utf-8'); ?> <vxml version="2.0" xml:lang="ja"> <?php $db_user = "galatea"; $db_pass = "galatea"; $db_host = "localhost"; $db_name = "galatea_db"; $db = pg_connect("host=$db_host port=5432 dbname=$db_name user=$db_user password=$db_pass"); if (isset($_REQUEST['item']) && $_REQUEST['item'] != '') { $item = $_REQUEST['item']; mb_convert_variables("UTF-8", mb_detect_encoding($item), $item); $rs = pg_query($db, "SELECT name,price FROM goods WHERE code = $item"); if ($row = pg_fetch_assoc($rs)) { $name = $row['name']; $price = $row['price']; } ?> <form id="answer"> <block> <log>name: <?php echo $name ?>，price: <?php echo $price ?></log> <prompt> <?php echo $name ?>は<?php echo $price ?>円です。 <break/> </prompt> <goto next="#ask"/> </block> </form> <?php } ?> <form id="ask"> <field name="item"> <prompt timeout="20s"> 値段を聞きたい果物は何ですか？ </prompt> <grammar version="1.0" root="#item_rule"> <rule id="item_rule"> <one-of> <item> <token sym="まいくてすと">マイクテスト</token> </item> <?php $rs = pg_query($db, "SELECT code,name,yomi FROM goods"); while ($row = pg_fetch_assoc($rs)) { $code = $row['code']; $name = $row['name']; $yomi = $row['yomi']; echo " <item> <token sym=\"$yomi\" slot=\"item\" value=\"$code\">$name</token> </item>\n"; } ?> </one-of> </rule> </grammar> </field> <block> <submit next="<?php echo basename(__FILE__) ?>"/> </block> </form> </vxml>
最後に、音声認識エンジンに対してユーザが発話している途中にどのようなフィードバックをユーザに見せるべきか、ということを考えていただくために、試作中の「音声インクリメンタルサーチ」のデモをお見せしました。
音声対話システムの開発において VoiceXML が常に最適な技術とは限りません。
ISTC-SIG-MMIでは、Galatea Toolkit 開発の経験を生かしつつ、W3Cでの標準化の動向も踏まえて、マルチモーダル対話システムのアーキテクチャーと記述言語の検討を進めています。
Galatea Dialog Manager もそれらの成果を取り込みながら、さらに開発を続けていきたいと思っています。
表題のような著書やサイトが少しはあってもいいような気がするのですが、匿名査読の原則があるせいか、皆様がどのように査読の仕事をなさっているかは、伺うことが少ないです。
私なんかは査読を受けたことの何倍も査読を頼まれたことの方が多い人間なので、（それは論文を書かない自分が悪いが。。）査読を頼まれるたびに困っていました。いまだに困ってますが。。。
でも、表題のようなマニュアルが普及すれば、査読される側に回ったときも役に立つと思うのです。。
投稿するたびに不採録になっていた日々を経て（いまだに？）、たまたま査読を依頼する側も経験して、あくまでも個人的な意見として、言わば「裏・査読マニュアル」を書いてみることにしました。
のっけからこんなこと書いてしまいますが、どうせボランティアです。
自分には引き受けられない、と思ったら、断った方がいいと思うのです。
私がかつて依頼する側に回ったときに、なるほど、と思った「断られ方」は、
「すでに２つ査読を抱えているので。。。」
みたいなパターンでした。
たとえその人が査読者としてふさわしくても、そんな人に頼んだら、きっと締切を守ってはもらえないでしょう。
そう思うと頼む側も諦めがつきそうです。
そこで
「じゃあ適切な人を紹介してください」
と食い下がる依頼者もいると思うのですが、仕事を振った先に恨まれるかも知れないので、気軽に紹介していいかどうか悩みますね。。
もちろん本当に専門外の内容で引き受けられないときにはそう言えばいいのですが、頼む側も
「この人なら専門外とは言われないだろう」
という判断をしていると思うので、受ける側も「読めるか読めないか微妙」という場合があると思うのです。
でも、そこから先は「頼む側の責任」だと開き直って、受ける側としては
「責任は負うけど１００％の責任ではない」
と開き直れると助かります。
そして、特定の査読者に１００％の責任を押しつけない、そういう論文誌編集委員会であって欲しい、と思ったりしています。
私たちはなぜ査読を引き受けるのでしょうか。
まず、依頼された編集委員の方に協力したい、あるいはその人を困らせたくない、という理由があり得ます。
だからと言ってできないことは無理にやるべきではありません。
いずれにせよ、編集委員の方の意図を推測してみましょう。
打診された内容は、依頼された自分のやっている仕事と似ていたり、分野が同じだったり、あるいは自分の既発表の論文が参考文献として挙げられていたり。。
なるほど、だから自分が打診を受けたのか、ということが納得できるのが普通です。
（私の経験では、ですが。。）
仮に自分の研究テーマと同じ内容であったり、自分の研究が引用されていれば、査読者としての自分がやるべきことは、単に論文の善し悪しを判断したり論文を世に出すお手伝いをするだけではなく、自分の研究を妨害されていないか(笑)、を判断することも査読者の仕事にならざるを得ません。
よくないことかも知れませんが、仕方ありませんね。。
もちろん、議論は合理的に、論理的に行うべきで、感情的に他人の仕事を妨害してはいけません。
他人の業績の多寡を左右することにつながるのですから。。
さて、「自分の仕事を妨害されていないか」という言い方は乱暴だったかも知れませんが、具体的にはどういうことでしょうか？
たとえば、自分がやろうとしている仕事を、その投稿論文が「実現した」「解明した」と主張していたらどうしましょう？
題名を読んで「やられた」と悔しく思うかも知れません。
しかし、悔しいからという理由で感情的に妨害するのは研究者にふさわしい行為ではありません。
負けは負け、素直に認めるべきです。
ですが、もしその投稿論文を読んでみて、不備があったらどうでしょう？
あるいは、「できた」と主張されていることの一部しか実際には実現されていなかったらどうでしょう？
指摘してあげることが自分の利益でもあり、読者のためでもあり、著者のためでもあるはずです。
あるいは、投稿論文の中で引用されている自分の論文が誤解されて説明されている、といった場合には、それを指摘してあげるのも、みんなの利益になる行為といえるでしょう。
（言い換えれば、採録された論文を読んだ第三者に「誰だ、こんなひどい論文を通した奴は」と言われて、あなたは責任を取れますか？ ということかも知れません)
こんな風に「自分の取り分をきちんと守る」ということが、査読を依頼された自分の務めだと考えてはどうかと思います。
さて、ここまで書いてきて思うのは、「そういうことは研究会や全国大会とか国際会議とかでやっとけばいいのでは？」という疑問です。
まったくそうだと思います。
著者が論文を投稿する前に口頭発表をするのは、フルペーパーを投稿したときにどんなダメ出しを食らうかを予見するためであるべきだし、将来低レベルの査読の仕事が来るのを未然に防ぐために、研究者はもっと講演に対して質疑をするべきだと思うのです。
次に、もう一つ査読を引き受ける理由があるとしたら、自分の勉強のため、情報収集のためです。
自分が研究会で聞きそびれたトピックについてきちんと理解する（理解できる話であれば、ですが）チャンスだし、得た情報は守秘義務があるとはいえ、その投稿論文に引用されている論文を「お、こんな文献もあるのか」と読んでみるチャンスであったりします。
あるいは、与えられた文章を批判的に読んでみることは、自分の文章力や論理的思考のトレーニングになります。
これに関連して「査読術に役立つ」と思うのは次のような文献でしょうか。。
この部分以外は納得
これは単なる「読みもの」ではない。 「意見」ならば必ず反論されうる、ということがわかった 他人の意見をあっさりと受け入れるな、のメッセージ 毒の効いた良書です
他の文献でも利用されている
悪い本ではないけれど 新聞・雑誌の正しい読み方が学べる良書
面白い本だが 攻撃的啓蒙書
以上、この章では、どちらかといえば「不純な動機」に絞って査読の意義を述べてきました。
もちろん、学会の論文誌にはそれぞれ査読の目的や方法を定めた文章があるはずです。
あくまでも各学会の規定する目的や方法こそが「正式」のものです。
きちんと目を通して従ったうえで、公平・公正に行わなくてはいけません。
ありがちな査読報告書の書式は「採録」「不採録」「条件付き（照会後）採録」などの選択肢を選んで、「新規性」「信頼性」「有用性」などを評価して、それから具体的なコメントを書く、というものであったりします。
真面目に書こうと思うと、まずこの論文がなぜ・どのように優れているのか、あるいはどんな問題点があるか、といったことを列挙して、総合的に「採録か否か」を判断すると思うのです。
でも、そうやって書いていると、下手な論文と同じで、何を言いたいのかよくわからない報告書になってしまいそうです。
最近は私は、論文をざっと読んで、時間が許すかぎり細かく読んで、気になったところには書き込んだりメモをしたりして、しばらく考えて「じゃあ不採録ということで理由を書くぞ」てな感じで報告書を書くようにしています。
やり方は人それぞれだと思うのですが、結論ありきで書き始めると、報告者である自分の立場がはっきりします。
例えば「致命的な問題点はこれとこれの２つです」「他のコメントは参考意見であり、不採録に値する致命的な指摘ではありません」のように書けば、査読報告を受け取った人が「この報告書の内容は妥当だろうか」「総合的にどう判定したらいいだろうか」と考えることが容易になるのではないかと思います。
また、不採録なら不採録に値する理由をきちんと書こうと努力してみて、後で読み返してみて、「やっぱりこんな理由で不採録だと言ってしまうのは言いすぎだなあ」と反省して、そのコメントを「条件付き採録」の「採録の条件」、あるいは「単なる参考意見」に格下げする、といったこともあると思うのです。
私は報告書は「です・ます」体で書くようにしています。
お互いに立場が分からない人間同士のやりとりですから、不快感を与えることなく、たとえネガティブな内容であっても冷静かつ対等にやりとりをしたいからです。そして、冷泉彰彦氏は下記の書籍で「だ、である」は権力や親疎外感をむき出しにしやすく、「です・ます」は（敬語の一種と考えるよりも）日本語の会話の標準スタイルとすべき対等なコミュニケーションのスタイルである、と説いています。
日本語を切り口にした鋭いビジネス論 山本七平先生が泣くのではないか 現代日本におけるコミュニケーションのあり方に納得 軽い読み物としては面白いが。 その場の雰囲気、「空気」に頼らない。
まず「この論文はＸＸＸについて扱った論文で、大変意義のある研究です」など、論文の良いところをきちんと評価します（褒めるところがない場合は無理矢理にでも作ります）。
採録と判断する際には、なぜ採録に値するかを著者に対してというよりもむしろ編集委員の方に客観的に伝わるように説明します。また、誤字脱字や体裁の不備などを指摘します。ただし、ちゃんとした論文誌なら、些細な誤字脱字は採録決定後の校正でチェックされるはずです。
世の中には「めんどくさいから採録」という判定をする査読者がいるのかいないのか、真実は闇の中かも知れませんが、いいことではないですよね。。
条件付き採録と判断する際には、「こういう風に修正しないと採録できない」という「条件」と、単なる「参考意見」を明確に区別できるように書きます。
「条件付き採録」と「不採録」の判定基準は論文誌によって決まっていると思いますが、大幅に内容が変わってしまう要求になりそうだったら不採録にすべし、といった感じでしょうか。
不採録と判断する際にもやはり「致命的な問題点」と単なる「参考意見」を区別して書きます。特に問題点は「照会後採録」に値しないくらい致命的な問題点であることを、著者に客観的に納得してもらえるように書きます。
その他細かいことは各学会論文誌の査読要領に従います。
以上、私の個人的意見を書き連ねてきました。
同業の方々から忌憚のない御意見をお待ちしております。
本当は論文誌ではなくシンポジウムや国際会議の査読はどうしたらいいのか、特に英語で査読報告書を書くときにはどうしたらいいのか、といった話題が残っていますが、また日を改めて書きたいと思います。
査読の仕事がたまっているので（笑）本日はこれで失礼します。
第３回ワザオギ落語会に行ってきました。
場所は国立演芸場。チケットは前売りで完売とのことで、観客にまで
大入り袋が出ました。最初「なんだろう？」と思いました。
ＤＶＤ販売が予告されている落語会ということで、
第１回のときは「ＤＶＤをご覧の皆様」と舞台の上で話しかける方が
いらっしゃったりしましたが、今回はそういう演出ではなく、
古典落語で、できるだけ動きや仕草が楽しめるものを、
出演者はみんなお選びになったのだろう、という、そういう演目ばかりでした。
そういえば新作落語の大御所ばかりだったにも関わらず、
みなさん古典落語を個性たっぷりに演じておられました。
３回目にして、今度こそＤＶＤを買わなくてはと思いました。。
くわしくはこちらを：
3月22日に、電子情報通信学会のイベント企画
「放送メディアにおける福祉情報技術の現状と可能性」を行いました。
当日はのべ40人くらいの方に御参加いただきました。
聴覚障害をお持ちの方が3人いらっしゃいましたので、
手話通訳およびPC要約筆記を行いました。
まずは御参加いただいた皆様にお礼を申し上げます。
最初に西本が趣旨を説明しました。
まず、消費者が作るメディア(CGM)の影響を受けて、
放送の世界に大きな変化が起きつつあることを踏まえて、
さまざまな可能性について議論したい、という問題提起をしました。
また、このイベントが「公開実験の場」であるという宣言をしました。
つまり「放送のバリアフリーと学会講演のバリアフリー」を比較検討したい、
ということです。
このイベントを録音し、インターネットラジオ番組として公開したい、
ということもご了承いただきました。
各講演者の方は、事前に手話通訳者と打ち合わせをしていただいたうえに、
発表の間も「ラジオをお聞きの方のために説明しますと・・」のように、
スライドの図をなるべく音声だけで理解していただけるように、
配慮していただきました。
講演者のおひとりは「完全原稿」を作ってくださいました。
事前に読み上げる内容を決めて、原稿をそのまま字幕として使いました。
これらの試みの後で、パネリスト5人の方に参加していただき、
総合討論を行いました。
議論の詳細は、録音した音声ファイルとともに改めて公開したいと思います。
今回のイベントを企画した立場として振り返ってみると、
まずは「情報を発信する」「受け手に伝える」ということの、
根源的な意味を考え直す機会になりました。
情報保障に神経を使いすぎて、発表者が生き生きとした講演をできなく
なってしまったのではないか、という意見もありました。
「本来、情報にはバリアはない、射影しようとするからバリアが生じるのだ」
という指摘は、「じゃあ情報保障というのは本来どうあるべきなのだろう」と
考え直さざるを得ない、本質的な指摘だったと言えます。
その上で、放送とはなんなのか、という問題提起に対しては、
「雑多な情報を雑多なまま扱えるインターネットの魅力」と、
「情報の受け手にリテラシーが足りない現状では、
放送局は責任を持って信頼のできる情報を発信する義務がある」
という両極の立場は、平行線を辿ったように思います。
さらに根本的な問題として、
「ニュアンスを含めて豊かに情報を伝えるコミュニケーションのあり方」
「さまざまな文化や言語で理解されやすい文章の組み立て方」
などを、今回の「公開実験」はあらためて提起したと感じました。
愛知県瀬戸市のコミュニティＦＭ放送局 RADIO SANQ の「まちづくりＭＹフレンド」というコーナーで、東京・谷中が取り上げられることになり、「谷中でまちづくりに取り組む人」ということで、ゲストに呼んでいただきました。
まず、コーディネーターの名古屋学院大学の古池嘉和先生に案内していただいて、名鉄瀬戸駅の近くの商店街で、若い人たちが思い思いに新しいお店を開き始めた、そんな現状を見せていただきました。そして、古池先生とパーソナリティの鈴木しほさんに、上手に質問をしていただきながら１時間近く喋りました。
同時録音を書き起こして、お二人の質問やコメントも含めて１人称の記述に改めてみました。放送のあとでスタッフの方に「それぞれの場面でいろいろ考えて、その都度ごとに『答え』を出しながらやってきた、そんなことが分かる話だった」と言われました。自分の出してきた『答え』は谷中に始まったことではなく、1999年から数年の京都・吉田山『茂庵』での経験が、いまに繋がっているのだ、と改めて感じています。
追記（2009年12月19日）：アプローチ谷中プロジェクトの活動記録はこちらをどうぞ。
(さらに…)
ひさしぶりに研究会で発表をしてきました。
西本 卓也, 嵯峨山 茂樹, 藤原 扶美, 下永 知子, 渡辺 隆行:
“対面朗読者と視覚障害者の対話の分析とその応用,”
情報処理学会研究報告(SIG-SLP), pp.55-60, Feb 2007.
Nishimoto2007SLP02.pdf
内容は12月のWIT/HI研究会で東京女子大の学生に発表してもらった内容と
同じなのですが、原稿にはかなり手を加えました。
今回はヒューマン・インタフェース(HI)と音声言語情報処理(SLP)の共催研究会で、
特にHIの方から質問やコメントをいただいたのが嬉しかったです。
今回は、プレゼン用PCで Apache/PHP/PostgreSQL を動かしてデモをしました。
また、ALTAIR for Windows を動かして、スクリーンリーダーってこんなものです、
という紹介もちょっとしました。
かなり個性的なソフトですが、デモに使うには適していたように思います。
（本当は定番の「ホームページリーダー」などを使えばよかったのですが、
買ったはずのインストールCDが見あたらなかったのです。
新しいのを買わなくては、と思っています）。
話をわかりやすくするために
「自由ではないが自然なインタフェース」
というキャッチフレーズを使ってみました。
するとさっそく
「『自由』や『自然』とはどんな意味なのか定義してください」
という質問がありました。
今回の例で言うと、選択肢が最初から3つ用意されていて、この中から選んでください、
というのは「自由」とは言えません。
本当は「サラダはどれについていますか？」など、言いたいことを自由なタイミングで
自由に言えることが望まれます。
音声認識の語彙サイズを増やすのはそういうニーズに応えるためです。
私の話における「自然」とは、やりたいことを違和感なく、楽に、効率的にできる、
実用上満足できる、といったことです。本当は「自然」という言葉はぴったり
当てはまらないかも知れません。人間がやっているコミュニケーションの有り様を
そのまま実現することが「自然」とは限らない、と考えています。
こんな風に答えたのですが、後でこの質問をした方と話をしてみたら、
この方は Ruby on Rails の開発者が言っている
「制約が自由を生む」
というフレーズを連想したのだそうです。
Rails の「制約」はプログラマーに「余計なことを考えないで、
本当にやりたいことが楽にできるようになる」という意味での
「自由」を与えている、というわけです。
私の話では「自由」をむしろ「複雑さをもたらすもの」として
否定的に扱っていましたが、
私の話の中での「自由ではない」という部分が
Rails の「制約」と同じ意味になるのだと思います。
「制約があるから楽になれる」というプログラマーと、
「自然な選択肢を与えれば楽に使える」という今回の私の話は、
似ているように思います。
逆に、音声対話システムに関する研究でしばしば
「何を言えばいいか分からないから使いにくい」
というユーザの意見が紹介されているのは、
「制約が足りないことの不自由」なのかも知れません。
視覚障害者がPCを使うためのスクリーンリーダーについての
具体的な質問をいただきました
（WITと違ってそういう質問もあるだろうと思ったのです）。
「お気に入りの選び方の詳細」はどうなっているのですか？
例えば73種類のお弁当をリスト表示して、
ひとつずつ1から順番に読み上げていきます。
ウェブのフォームを音声ブラウザで操作する一般的なやり方としては、
項目の移動はカーソルキーの上下で行います。
それぞれの項目にチェックボックスがあります。
画面を読み上げるときに
「チェックボックス、チェックあり」のように読み上げます。
キーボードのスペースキーなどでON/OFFの切り替えを行います。
じゃあタイミングでユーザーは判断する、ということですね？
タイミングというべきかどうかは分かりませんが、
カーソルがその行にあり、その行が読み上げられたときに、
チェックボックスのON/OFF操作ができる、ということです。
お弁当の場合は、中身を知っているものと知らないものがあると思いますが、
詳細な情報はどのように聞くことができるのでしょう？
クリックすると詳細が出てきます。
リンクがあるということは声の違いでわかります。
ただし、ウェブブラウザのポップアップを使っているので、
ユーザの好みや音声ブラウザの機能によって使い勝手は変わってきます。
今回は
podcastle
(http://podcastle.jp/)
のグループの発表が注目されましたが、
実際に音声認識や音声対話のシステムを公開運用して改良を重ねる、
というアプローチが増えてきました。
それにつれて、
「音声対話システムにはインタフェースやデザインの要素が大切」
という認識も広まりつつあるように思います。
音声の研究コミュニティがそんなふうになっているときに、
今回私は「音声対話を分析することは有用だけど、
その成果は音声対話以外のシステムに役に立つ」
というような発表をしました。
そういえば音声認識の高度なパターン認識アルゴリズムは、
文字認識や画像認識や遺伝子解析などに使われつつあります。
「音声認識の技術はとても役に立つ。ただし、音声認識以外への応用に」
という皮肉も聞かれるくらいです。
音声対話のデザインやパターンについても、
似たようなことが起きるかも知れません。
音声対話システムに対して悲観的なわけではありませんが、
音声インタフェースの研究も、
人間同士の音声対話を模倣するだけでは行き詰まりそうな気がします。
一見、人間同士の会話と全然違うように行われるけれど、
とても習熟しやすく効率的なインタフェースで、
しかも「人間同士の音声対話の分析」から得られた原理が背後に隠れている、
といったことがあるように思えてきました。
そういうことを「自由ではないが自然」と呼んでいますが、
もっとふさわしい言葉を見つけたいと思います。
「基礎的な物事を勉強し直す」「安易に新しいことに手を出さない」という今年の抱負は、例えばこういうことだったりするが、年末年始に改めてPerlの勉強をした。
簡単なテキスト処理にはずっと昔から使っているのだが、最近の動向についていけてなくて。。
perldoc-jp のドキュメントを W-ZERO3[es] に入れて旅行中に読み、やっと言語コアの部分を読み終えた。
リファレンスとかモジュールとかの記法に目が慣れてきて、やっと中級者向けの参考書や雑誌記事が読めるようになった。
Windows + ActivePerl + Apache + Postgres + Eclipse (EPIC) という環境でさっそくいろいろ試している。
動いているプログラムをちょっとずつ拡張したいときに、１行か２行書き足すだけでやりたいことができる。
誰かが似たようなことをやってるのでは、と思えばネットで検索して情報を得られる。
面白そうなモジュールを探してインストールして試してみる。
やっぱり自分に合っているプログラミング言語だということを改めて認識した。
PHP で開発していて「ここから先はお手軽には書けない」という閉塞感を何度味わったことか。。
Perlが特に優れた言語だとは、いままで思っていなかった。
いや、いまでも言語そのものが優れているのかどうか、よくわからない。
Plagger のインストールをしながら、Linux の黎明期に味わった「インストールすることが自己目的的に楽しい」というあの感覚を久しぶりに思い出して、Perlというものがプログラミング言語というよりもOSのような存在に思えた。
Perlを巡る構造で重要なのはやっぱりコミュニティなのだろう。
Perlのある部分は「ガラクタの寄せ集め的言語」なのに、ある部分が「一貫性を重視したストイックでミニマルな言語」なのは、必ずしも先見性というわけではなく、むしろ「コミュニティのニーズを適切に反映してきた成果」だと思う。
僕が初めて触ったころの Perl はまだバージョン４だった。
そのことは C や sed や awk や sh を知っている人が、その知識を生かしつつ仕事を効率化するための言語だった。
改めて言語仕様を読み返すと、例外的なルールがいろいろあるにも関わらず、不自然さを感じない。
それは、実際に行われる仕事やユーザのことをよく理解して作られた仕様だったから、なのだと思う。
その思想は最新のバージョンにも反映されているように思われる。
そしてLinuxが成熟していく過程で有効に機能した（と思われる）コミュニティの構造に似ている。
言語仕様の策定にコンピュータやソフトウェアをビジネスとする企業や、公的な組織が入っていない。
Linux: (a)カーネルの開発者 (b)GNUアプリケーションの開発者 (c) RedHatやDebianなどのディストリ
Perl: (a)Perl コアの開発者 (b)モジュールの開発者 (c) CPANというコミュニティ
ということになるだろうか。
Perl 6 の仕様に関する議論もちょっと読んでみたが、いかにも民主的に行われている、と感じる。
そんなわけで、今年は（久しぶりに） Perl に深入りしていきたい。