[2005] 音喰らう脳

投稿:  著者:  読了時間:17分(本文:約8,000文字)


<よどみないきれいな台詞を暫く聞いていて胸がむかむかしてくる>  

■デジタルサウンズ研究室 
 音喰らう脳
 モモヨ(リザード)

■電網悠語:Ridual内面・展開編[119]
 エクスペリエンス・エンジニアリング
 三井英樹

■Skypeの味わい方[5]
 Skypeつながりで出会うスゴイ人々
 rゆ


■デジタルサウンズ研究室 改め 音喰らう脳 
音喰らう脳

モモヨ(リザード)
───────────────────────────────────
最初に、編集部そして読者の方にお断りしたい。コラム表題の『デジタルサウンズ研究室』を改めるということである。

これまで私のコラムでは、音楽媒体、流通の質的変化に着眼して状況を観察、意見を述べてきた。表題に掲げたデジタル音楽という言葉もそれなりに広がりをもっていた。そこに、音楽配信というタブーめいた未開領域があったというのがその事由であったろう。

我が国の音楽業界は、ながらく、楽曲のネット配信に否定的な態度を持して来た。それが、ここ二年ほど、iPodの普及や携帯の援用などにより急速にひろまった。そして、その相乗効果によってCD売上が伸びたという結果を得て、いまや180度状況が変わっている。加えて、放送のデジタル化も急速に進み、ふと周りを眺めてみると、デジタル音楽でない音楽パッケージをさがすことすら難しくなっている。

環境の質的変化をかんがみれば、『デジタルサウンズ』という用語の成立すら危うくなっている。これが表題変更の理由である。

ちょうど、デジクリそのものがサイトと連動して質的跳躍を企図している。いい機会である。これを機にコラム表題を『音喰らう脳』と改めようと想う。

デジクリのリニューアルという話題がでたところで、新サイトについて感想を述べておこう。

サイトの形態が一新されることをリニューアルと言うわけだが、今回のデジクリのそれにはリニューアルという言葉で片付けられないものがある。

サイトがかわるというのは聞いていたが、実際に見るまでは、これほどの変容を企画しているとは想わなかった。想像力の欠如を恥じるしかない。これほどインパクトがあるとは、正直、思わなかった。

膨大な量の過去ログをどう料理して読み手に届けるか、そこに眼目をおいて新サイトは構築されたのであろう、ブログ系システムを応用して筆者別の表示などが可能になっている。白状すると、なさけないことに私はまだ使いこなせていない。慣れるまで少し手間どるかもしれないが、馴染めば便利であることくらいはわかる。どのような使い方があるかは各自で確認していただきたい。

今回、導入したシステムは、筆者、編集者、そして読者相互の関係性の変容をもたらす、そんな気がしている。ヨイショではない。本気でそう考えている。

どんな類の変容かを語るほどの見識は、私にはない。いずれにしろ、デジクリという言葉で我々が想起する本質、これまでメルマガとして認知してきたそれが従来とかけはなれたものとなることは想像に難くない。

その変化が私たち一人一人の生活を少しでも明るくできるなら幸いだ。まだまだ楽しみが先にまっている、常にそう思っていたいものである。

モモヨ(リザード)管原保雄
< http://www.babylonic.com >

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
■電網悠語:Ridual内面・展開編[119]
エクスペリエンス・エンジニアリング

三井英樹
───────────────────────────────────
ソフトウェア開発環境展(SODEC)に参加した。三日間の会期中、一日二回、計六回のミニセミナーで話す。座ってくれる方ゼロの回もあり、なかなか精神的にタフなもの。広い会場の路地裏で話すようなものだから、しょうがない。参)http://www.sodec.jp/

タイトルは、「エクスペリエンス・エンジニアリング」。テーマは、「体験は工学(エンジニアリング)的に生産可能なのか」。それに絡めて、Experience Design(XD)的開発手法について自分なりにまとめてみた。

●仕様変更に耐えられる開発プロセス

開発プロセスを考えると、昔ながらの「ウォーターフォール型」を否定できない。要求仕様/概要設計/詳細設計/開発/テスト、そんな感じで進んでいければいいに越したことはない。

でも、要求がどんどん変わっていく。クライアントの担当者が、こちらの提案に感化されて、そこから勉強始めるんだもの。そして、こちらもこちらで、その横揺れに応じて、よせば楽なのに提案を重ねてしまう。

そんな仕様変更に耐えられる、開発プロセスって何だろう。一般的には、要所要所に、スパイラル(試行錯誤的な巡回運用)を取り入れる形が主流だろうか。それはWebの世界だけでなく、他のアプリケーション開発でも同じ流れになってきているように思う。

最初に作った設計図(仕様書)が、最後まで有効であると考える方がおかしいという風潮にもなってきている。でも、最初にしっかりとした設計書を作らなくてもいいんじゃないかという、言い訳にも聞こえなくもない。だから、個人的にはウォーターフォール型を捨てきれない。王道だと思うから。

じゃあ、RIA(Rich Internet Application)システム開発のプロセスは、何も違いがないんだろうか。RIAコンソーシアムでも何度も話した内容だ。単純に、スパイラル部分が付与されただけで、本流部分は同じなのだろうか。

●「ユーザー」が見あたらない

SODECの会場で、そんな話をする。最初のプレゼンではいまいち自分でも答えが見えなかった。でも回を重ねるごとに、その間にSODEC会場で見聞きしたことが重なってくる。

ここ数年、SODECはほぼ毎年見には行っていた。コード生成やテストツール、タスク管理ツールや、デバッグ手法。毎年注視していたのはほぼ同じ領域だ。根本的に、どうやったら開発が楽になるのか。もちろん、全部を見れた訳じゃない。ご近所しか探索できなかったが、雰囲気は感じ取った気がする。

すぐそばで、派手なオネエさんを従えた大企業が、「リッチクライアント」製品のデモをやっていた。簡単にリッチクライアントが開発できます。エクセルなどの定型フォームに情報を入力して、クリック一つで、はいっ生成。ドラッグ&ドロップで部品をはめ込んで行けば、ほらリッチでしょ。

よどみない、きれいな台詞を暫く聞いていて、胸がむかむかしてくる。その開発プロセスのどこに、ユーザーが求める姿を考慮する部分があるのだろうか。こ難しい技術を並べて、作り手の生産性だけを、高めただけに感じてしまう。

RIA型開発で火が付く「仕様変更」は決まって、ユーザーとの接点だ。そこで作り手のエゴや短絡思考や配慮のなさが、開発/製造工程にまで影響して、大火事になる。なのに、SODECで語られる言葉に、「ユーザー」が見あたらない。

そうしたユーザを見つめる部分で、ブレがあったとしたら、その後の工程でどんなにきれいなプログラムコードが出来上がったとしても、無駄なんじゃないだろうか。そのブレを何とかするのが、今必要なトコなんじゃないんだろうか。

CASE(Computer Aided Software Engineering)がキーワードだった時代から、下流CASEの部分だけがどんどんと深化していったに過ぎない気がしてくる。もちろん、上流工程の大切さは誰もが言うし、専用のツールも体系も語られるんだけれど、何か観点の違いを感じてしまう。Webの現場と違う匂いしかしない。
参)http://e-words.jp/w/CASE.html

そんな予感を覚えつつ、RIA型開発プロセスを、設計段階が「概要+詳細」という不可分なプロセスで、下記の特徴を持つものと説明した。

・ビジネスゴールをエンジニア的に支援するすることを忘れない
・押し付けにならないように、エンドユーザの享受できるものを考慮する
・感覚だけではなく、学術的にも裏付けられた手法も多用する
 ? ペルソナ/人間中心設計手法
 ? ワイヤーフレーム/モックアップ/プロトタイプ
・常にユーザビリティテスト(自分はモルモット)
・局所的なスパイラルではなく、設計段階全体をスパイラル可能に
・様々な部分で「検証」可能なように作り込み、検証する
参)http://homepage3.nifty.com/mitmix/RIA/img/XD_dev_process.gif

●エンジニアリングの本質

同時に、根本である「エンジニアリング」についても調べて、新たな発見があった。克元亮氏は、その定義を「技術を組み合わせて統合し、顧客に利便性を提供すること」としている。見つけたとき、少し目を見張った。
< http://allabout.co.jp/career/swengineer/closeup/CU20030106A/index.htm >

何が新鮮だったかというと、「エンジニアリング」とは「?を提供すること」という部分。とかく、エンジニアリングとは、何かを「作ること」と定義されがちだけれど、この定義では違う。ソースコードを提供することでもない。利便性を提供することだとある。

まぎれもなく、これはビジネスゴールにどこまで加担できたかが、エンジニアリングの本質だといっている。つまり、使われないシステムを納品することは、エンジニアリングですらない。プログラム書きました、のレベルなのだろう。

システムがシステム単体で存在できた頃、人はその操作を無理やり覚え、システムに合わせて生きてきた。しかし、そんな時代はもう過ぎようとしている。システムは、それを操作する人間に合わせて作られるべきで、システム単体のデータの流れの速さが大切なのではなく、人間の操作も含めた上で付加価値をどれくらい生み出せるかが語られる時代になりつつある。

本来、企業が行なっている「システム投資」の意味はそこにある。ソフトとハードだけの世界で高性能を誇っても、企業としては価値はない。記録上の数字競争をしている訳ではない。社員(人間)が使った上での、生産性が向上しない限り、投資をする意味がない。

Webはそういった意味で、使いにくければ無視され忘れられるという過酷な環境で、次世代のアプリケーション開発の試行錯誤をしているのかもしれない。システムはデータに仕え、データは人間に仕える。忘れがちだけれど、Webでは当たり前の常識だ。原点に立ち返りつつ、セミナーで話をしつつ、自分の方が何か新しいことを得たような気分になった。SODECに感謝。

【みつい・ひでき】感想などはmit_dgcr@yahoo.co.jpまで
コンクリの上に立ちっぱなしはやはりキツイ。足から腰まで棒のよう。
・Ridual < http://www.ridual.jp/ >
・Ridual-users < http://groups.yahoo.co.jp/group/Ridual-users/ >
・ミルクエイジ < http://homepage3.nifty.com/mitmix/MilkAge/ >
・日経ITpro Webデザイン エンジニアリング
< http://itpro.nikkeibp.co.jp/article/COLUMN/20060309/232107/ >

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
■Skypeの味わい方[5]
Skypeつながりで出会うスゴイ人々

rゆ
───────────────────────────────────
前回、「Skypeの異国情緒」で伝えたようにSkypeの主体は海外にあり、日本人の参加、ましてや組織への意志の反映には、一から十まで語学的ハードルがついて回る。

そういった環境の中、自分以外にも孤軍奮闘して頑張ってる方がいらっしゃる。今回は是非その方々を紹介したい。2005年頭からSkype関連ソフトなどを作り、SkypeJapan岩田さんに引き合わされた面々を一期生とすると、今回紹介する2人はSkypeJapan創世2期生とでも言うべき世代になる。両氏とも開発者Forumへの書き込みがきっかけで知り合いとなった。

●Skype社公認デヴェロッパーになったSkype API for Javaの久納さん
< http://skype.sourceforge.jp/ >
< https://developer.skype.com/wiki/Java_API >

次に紹介するTand0さんとrゆが、JavaからSkypeへ連携することをForumで話している所に、絶妙のタイミングでライブラリを公開されたのが久納さんである。2005年初めくらいまでには、JavaからAPIを利用するためのアダプタとして海外発のJSAというライブラリがあったのだが、メンテされておらずSkypeの新しいバージョン(1.4以降)では使えなかった。

そのため、Forumで1から書き起こして掲示していたのだがSkype API for Javaは単なるブリッジという機能を超え、APIをWrapする事でさらに使いやすい物になっている。

彼は元々Javaのすごい人で、ケータイ用のGameBoyエミュレータを作ってSunから表彰されたりという経歴を持つ。その他、若くして2児の父だったりするのだが、その辺のおもしろい話題は彼のmixiの自己紹介を是非見て欲しい。

●API Contestで次点になった"Skype A2A Simulator"作者のTand0さん
< http://park.ruru.ne.jp/ando/work/skwork/index.html >
< http://share.skype.com/sites/devzone/2006/06/api_contest_results.html >

彼もおもしろい。D言語というマイナーな言語でForumにエントリしてきた。いやいや、C、C++の次はD? というか、存在すら知らなかったが。

A2AというのはSkypeAPIの機能の一つで、Skype間でデータ通信を行なうものだ。A2Aを利用したプログラムのテストには、あたりまえの事ながら2つのSkypeが必要になるため慣れないとかなり面倒なのだが、彼のA2A Simulatorを使えばSkypeを使うことなくテストが出来る。

ちょうどそのころ、個人的にA2Aを利用するプログラムを作っていて、早速利用させて貰った。D言語の限界かということで、C#のサンプルを書いたり、前述のJavaのブリッジを作ったりしたのだが、最近は活動していないような…。ネトゲとお絵かきが趣味でそちらが忙しいようだ。

今回、Skype社にかたや公認、かたや受賞という2人を紹介した。自分としてはどちらにも噛めなかったのは少し残念ではあるものの、お二人にはおめでとうと伝えたい。久納さんには記念にライブラリの機能追加のソースをプレゼントした(笑。

こうして海外のコミュニティで認められるという事もひとつの目標なのだが、それ以上にIT業界でソフト作ってる人間として、こうした方々とSkypeをネタに横のつながりができた事が嬉しい。会社に所属していると、縦のつながりはできてもなかなか横のつながりができないのだ。これからどんな人が3期、4期として登場してきてくれるか、期待している。

【rゆ】ryu.at.nyanyan.to  < http://nyanyan.to/ >
Japanese Skype Developers Forum Moderator
本業は普通の会社員、PMやってます。こういう、ネットならではの社会参加も面白いんじゃないかと?
Skype公式ユーザForum(J): < http://forum.skype.com/viewforum.php?f=35 >
Skype公式開発者Forum(J): < http://forum.skype.com/viewforum.php?f=29 >


━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
■編集後記(7/4)
・デジクリの新しい世紀が始まります
サイトもリニューアルオープン
< http://bn.dgcr.com/ >

・自転車がパンクした。修理セットを取り出すが、接着剤は乾燥して使いものにならない(前もこんな場面があったような)。本音はめんどうくさいからなのだが、接着剤のせいにして自転車屋さんに持ち込む。さすがプロのテクニック、あっというまに2つの穴を発見して、あっというまに塞いでしまった。いつもながらほれぼれする。パンクしないタイヤもありますよねと話をふると、うちでは扱っていないと不機嫌に言う。それはわかる。あんなものが普及してしまったら、自転車屋さんは困るだろう。自転車屋さんはたいてい昔から同じ所にあって、今も商売を続けている。そんなに儲かるようには見えないが、パンクなどの修理による稼ぎがいいとか、どこかで聞いたことがある。たしかに、今回のように所要5分間、材料費わずか、それで1,000円(うちの近所では1か所500円だ)の現金収入とはおいしい。いや、自転車屋さんの経営については正確には知らない。それでも、パンク修理がなくなったら痛いはずだ。だいぶ前にジャスコに行って、パンクしない自転車を見た。それはウレタンチューブだったと思う。あいにく試乗できなかったが、自転車は重くて快適な走りは期待できそうになかった。最近では、合成ゴムとオイルを組み合わせた「リペアムゲル」なる新素材ゲルを、空気にかわってチューブに充填する方法があることをネットで知った。空気じゃないから、穴をあけてもパンクしない。いま乗っている自転車のタイヤに注入するサービスもある。両輪に注入すると約2キロ強重量がふえるそうだ。重くなるのはちょっと困るが、もうパンクを心配する必要がなくなる心理的効果は大きい。クロスバイクをオーバーホールして、ノーパンク車に仕立てようかと思案中。(柴田)

・デジタルARENAの「授業中でもケータイOK!? 大人になったら聞こえない着信音!!」が面白かった。未成年者には高周波数の音がよく聞こえるらしい。コンビニにたむろする未成年者を追い払うため、その高周波数の不快な音を発生させる音響装置が開発されたとか。逆に、未成年者にしか聞こえないなら、授業中に先生に気づかれない着信音として使えるのではないかというコラム。2つの音へのリンクがあって、最初の音ではよくわからないのだが、2つめの音では、外付けHDDの音や、エレベーターや飛行機に乗った時のようなキィーンという音が聞こえる。知人はイヤホンを通したら、かろうじて聞こえたらしいのだが、かなりショックを受けていた。元ネタのBBCでは、11歳だけど聞こえないとか、55歳でも聞けたとかのコメントがあるので単に個人差かも。(hammer.mule)
< http://arena.nikkeibp.co.jp/col/20060620/117268/ >  高周波数
< http://www.ne.jp/asahi/fa/efu/soft/wg/wg.html >  WaveGane
< http://www.bbc.co.uk/wiltshire/content/articles/2006/04/04/mosquito_sound_wave_feature.shtml >