投稿者「Atsushi」のアーカイブ

Atsushi について

Information Architect

眠い週末(081018-19)

約二週間お休みをいただいて、イタリア旅行へ。
思ったより時差ぼけは感じなかったが、やはり旅疲れがあったようで、昼まで寝てしまった(時差ぼけだな)。

土曜。
前日の金曜にMacBook Airのヒンジ部分(開け閉めするテコの部分)が折れてしまい、がくがくするのでApple Storeへマシンを持ち込む。
たまにあることらしくたぶんリストア(ディスクの初期化)はしないで直るとことで安心して預ける。
会社に戻り、母艦のMacBook Proにてごりごりと仕事をすすめる。

夕方から現在マネックス・ユニバーシティ代表を務められている内藤さんら夫妻に連れられ、六本木のごま油鍋料理店石頭楼(スートウロウ)へ。
噂には聞いていたが、ごま油にお肉なのにしつこくなく、どんどん食が進む。
紹興酒もとても合って、ますます食が進む。

内藤さん夫妻もこれからイタリア旅行とのことなので、話はイタリア話へ。
我々の旅行はバチカン博物館とおいしいものを求める旅であったため、話はもっぱらサンピエトロ大聖堂の模様と、うまいレストラン関係となる。
おなかいっぱいなのにまだ食べ物の話をしている我々はどこまで強欲なのであろうか。

翌日曜。
午前中に修理が終わった連絡をベッドで受け取り、昼に再びApple Storeへ。
と、マシンを立ち上げて検証してみるとアカウントが減っている?
なんと、カーネルパニックが起こり、再インストールをしたとのこと。
げげ、と頭が白くなる。

バックアップ自体はとってあるけど、この忙しいのに環境の再設定とか、アプリのインストールとか、あれやこれやと頭をかけめぐる。
こんなことなら水曜のApple Store(!)での講演後に修理にだせばよかったと一瞬思うが、まあ、こんなものだろうと、あきらめて会社に戻り、仕事を進めながらインストール作業。

.Mac(Mobile Me)、FolderShare、DropBoxのおかげで、それらをセットアップするだけで書類はみるみるうちにもとの環境にもどる。
やはり決してローカル環境に書類はためるまい、と固く決意した週末だった。

機会損失的側面の計量方法

ユーザーインターフェイス、情報アーキテクチャ設計において、ここのところ機会損失の影響について考えさせられることが続いている。

一般に、ユーザーインターフェイスは必要な要件を積んでいっただけでは、いっぱいいっぱいになってしまい、飛行機の操縦席のようになってしまう。
最近では飛行機の操縦席も統合化されているようだが、とはいえ、エキスパートにはやはり物理的に計器が並んでいる方が「使いやすい」ことが多い。
しかしながら、初めて使う人、長期間にわたって使っているがコミットが低い人、などには、そういったいっぱいいっぱいインターフェイスは、どれからつかってよいかわからない、なにがなにかわからない、といった結果となってしまう。

ちなみにこれを最近「インターフェイスの共倒れ問題」と呼んでいる。

この問題自体はかれこれもう20年くらい語られてきていると思うが、じゃあ、どこまで単純化すればいいの、というポイント、(できるだけ)客観的なこの部分を評価するための指標、といったものをまだ見つけられていない。

おそらく安藤昌也氏の提唱した「長期的ユーザビリティ」の観点、インターフェイスの最低限の教示要件の観点、安全性能の観点(緊急停止とか、ミュートはダイレクトにやる必要がある、とか)、などの要件が足しあわされるのだと思うが、どうもそれだと通り一遍でつまらない。

最近のHCI関係ではそういったあたりも研究されていたりするのかな?
どういった分野を参照すればよいか、ご存じの方いたら教えてください。

担当者不在でコメント不可

最近、

「判決文を見ていないので、コメントできない」
「担当者が不在のため、コメントできない」

というようなコメントが見受けられるが、これってコメントできない理由になっていると思って言っているんでしょうか?
判決文を見ていない状態でのコメント、担当者ではないけれどコメント、というのが筋ではあると思うんだけど。

上記のような「コメント」は一律「ノーコメント」「コメントを避けた」って言った方がまぎらわしくないか?

担当者が戻ったり、判決文を読んでからコメントを言ってくれるんならまだいいんだけど、なんとなくその場を逃れる技を、マスコミが助長しているように思えてならない。

K.O 7発売

山形在住のデザイナー奥山清行(Ken Okuyama)氏によるオリジナルカーK.O 7が発売される見通し。

K.O 7 – Ken Okuyama Design Office
http://www.kenokuyamadesign.com/?d=cars&m=ko7

ジュネーブショーで3月に発表されたコンセプトカーが99台の限定発売。

ぱっと見で、刀っぽいと思った。

たぶん塗装していない表面の質感でそう思ったのだと思うが、実物を見てみたい。

スピードベスト

自転車をこいでいる速度を周りに知らせてくれる服 – GIGAZINE

自転車の速度は自動車から見ても歩行者から見てもいまいち分かりづらいものですが、速度によって数字を変えて光で表示するベストを作った人がいるようです。

速度は背中に表示されるので自分で確認することは出来ませんが、自転車で車道を走る場合などは、後方に情報を伝えられるため、安全性が上がりそうです。

実は車にも自車のスピードをまわりに表明する技術があってもいいのかもしれない。

法定速度を超えたらスピードの文字が赤くなるとか。

ペルソナ法と塩野七生氏

ペルソナ・シナリオ法という言葉がはやっている。

ペルソナ法とは簡単に言ってしまうと、デザインをするとき、一般的でない、具体的な利用者をイメージせよ、という方法。

先日もそういったセミナーを開催したが(すいませんQ&Aの結果はもうじきこの場でお答えします)、その際いつも、「ペルソナ法だとその人向けだけに特化されてしまうのではないか?」という趣旨の質問をいただく。

毎回「そういうものではなく、具体的に対象者を想定することで企画が具体的になる、ということを意図しているんです」という返事をしているのだが、たまたま読んでいた塩野七生さんの「男たちへ」にそのものずばりの解答が載っていた。

(略)ここには、創作活動のカギの一つが見事に言いつくされている。(略)その私でも書くときは、読者は頭になく、眼の前の担当編集者に向かって書く。彼を、でなければ彼女を、うならせてみたいという思いだけで書く。なぜなら、それが上手くいけば、その向こうにいる不特定多数の読者にも自然に通じる、と確信しているからである。(太字は傍点部)
男たちへ―フツウの男をフツウでない男にするための54章 (文春文庫)

とまあ、そういうわけなんです。

DESIGN IT! Forum 2008

もう1週間たつが、去る8月22日、ソシオメディアとDESIGN IT!, LLC主催のDESIGN IT! Forum 2008に参加した。

今回のテーマは「インタラクションデザインの現在と未来」。

2日にわたる日程のうち、2日目の全体を総括するパネルディスカッションにパネラーとして参加させていただいた。

続きを読む

TC協会シンポジウムにむけて

ウェブサイトなどのデザインにおいて、機能(裏側)とユーザーインターフェイス(触れるところ)のデザインは通常別に職能を持った人が行い、フェーズとしても分かれている。

Linuxに必要なのは見た目か – コデラノブログ3

さて、LinuxにMacOSのような見栄えが必要かと言えば、うーんまあ今ぐらい頑張ってればいんじゃない? と思う。実際に使うのはアプリケーションだったりオンライン上のサービスだったりするわけだから、デスクトップやファイルのアイコンなどは、既存OSのい いとこ取りをして使い勝手が良ければ、それで十分だろう。

それよりも、ちょっと使い勝手を変えたり、ツールを入れたりするときに、やっぱり10年経ってもsudoしてコマンド打ち込んだり、エディタで設定 ファイル開いて書き直すみたいなことになっている。多くの人を取り込もうと思うのならば、この辺をGUIで何とかした方がいい。

OSの動き全体をコーディネートする人がいて、その人のポリシーを実現しようとするような集団が後ろについているような状態、つまり会社内の命令系統のような形でチームが固定化されないと、なかなかすべてをGUIでデザインするのは難しい。

そのあたりが、多くの推進力を有志のプログラマ集団に依存しているGNU/Linuxというものが構造的に抱え続けている問題だと思う。

この融合については、いくつか方法を試したり、検討がなされていたりしている。

昨日、テクニカルコミュニケーター協会(TC協会)シンポジウムでのパネルディスカッションの事前打ち合わせのために、TC協会理事の高橋さん、HCD-Net機構長の黒須さん、ソシオメディアの篠原さん、テクニカルライターの高橋さんなどとミーティングをしてこのテクニカルライティング業界でも同じようなことが起きていることに気づいた。

テクニカルライティングは、通常「マニュアル執筆」という形をとることが多いが、これはわりと後工程として製品私用ができあがってから、その説明書、という形で書かれる、ことが多いようだ。

が、いま情報プロダクトを企画するとき、「どう使えるのか」というメッセージは、説明書で説明するものではなく、機器自体に埋め込まれていなければならない(あるいは箱に書いてある、とかでもいいかもしれないけど)。

この部分にテクニカルライティングの専門家が関与していない、できていない、というのは大変もったいない。

「テクニカルライティングの専門家」がどこからどこまでの領域の技能を指すのかは定義が難しいような気がするが、そこが明らかになれば、サービスや製品の企画・設計の段階にもっと関与できるようになると思う(というか、参加していただきたいです)。

若干はしょり気味で書いたのでわかりにくいですが、今後深掘りする必要があるテーマに思う。