life x web Technology Design

「インターフェイス」といえばアプリケーションなどで実際にユーザーの目に触れる、サービスの重要な要素のひとつです。 僕も少しの間画面設計やユーザビリティのコンサルタントのお仕事をさせていただいていた期間があるのでちょっと使いづらかったりすると解決法を考えちゃったりします。 （実際には裏側の概念まで指しますが）インターフェイスというと目に見える部分が多く、サービスの質を左右するので設計者はプロとして腕の見せ所なんですが、意外にも「手品」の概念が似ている、とのことです。 勘違いをしやすいという点は、逆に考えるとイリュージョンを見る能力があるという長所だと考えることもできます。計算機システムの入出力が多少いい加減だとしても、人間のこの「長所」のおかげでそれなりに使えているものは多いでしょう。例えばマウスでカーソルを動かすとき、カーソルの位置は離散的にしか動きませんが、人間の目にはなめらかに動くように見えます。（中略） GUI をはじめとする計算機のインタフェースは完全に手品的なものであり、ユーザが積極的に騙されることによって、わかったような気になって計算機を利用することができるようになっているというわけです。表示されているアイコンとハードディスク内のデータはどういう関係なのだろう？などといちいち悩んでいたらパソコンで仕事など不可能でしょう。（第36回 手品とインタフェース／増井俊之の「界面潮流」） 現在僕自身もプログラミングをメモリの０と１から勉強しなおしていますが、実際に利用するユーザーはそんなことを意識することは無くて、長い年月をかけて高度に構築されたイリュージョンの上で利用しています。 もちろんそのイリュージョンが最終的にユーザーの感覚に依存しすぎてしまったり、中身が出すぎてしまったりしていれば予期しない動きや使いづらさにつながってしまうのでイリュージョンの設計から学ぶことは多そうです。

本家のブログSEM-Analyticsでも書いたのですが、１０月から開発部門に異動することになり、えせホリデープログラマーから職業プログラマーになることになりました。 もちろん開発経験は無いので現在Javaの猛勉強中。 ３ヶ月間の研修をみっちり受けてついに開発の世界に入ります。 これまで以上にこのブログも更新していかないとと思います。

（最近新卒の話ばっかりですが、） 新人用の勉強会でよく訊かれるのが 「普段どうやって勉強してるんですか？」 という質問。 僕は大学で 「Research and Study Skills（リサーチと勉強法）」 という科目をとっていて（というか必修）、 統計学や勉強法を学んだことあるんですが、 やっぱり勉強法から勉強することは大事だと思います。 苦しい大学勉強生活で感じた「勉強」は ——————————————————— ■ツールになるもの（英語とか）→基礎から学ぶ 単語や文章などコンテンツそのものより、 それをどのように使うかというフレームワークや スキームが大事なので基礎から学ぶ。 下手にちょっとなれてきて知識がついたりすると 知っていることだけでこなそうとしてしまうので、 できるだけまっさらなうちから基礎を学んだ方が いいと思います。 ■知識がいるもの 一方とにかく「知っているかどうか」という分野においては （基礎からやっていれば圧倒的に飲み込みのスピードは 早いですが、、、。）、とにかくわからなくなったら調べる、 を繰り返し行っていくことが大事。 なぜかというと、世の中には覚えなくてもいい情報が たくさんあるから。 何度も調べて、何回も出てきたことは自分にとって 重要なことなので、それを優先して覚えていくことが大事。 ——————————————————— それぞれひとによって今勉強しなければならない 事柄の勉強の仕方が違うと思います。 結局どちらも大事なんですけどね。 基礎から学ぶ骨の部分と、後から継ぎ足していく 肉の部分を見極めて勉強したいですね。

「仕組み作りの達人」→プログラマー もう一つのブログ「SEM-Analytics」に書評を あげました。 仕組み作りという仕事の教科書（SEM-Analytics） 小飼弾の 「仕組み」進化論 posted with amazlet at 09.05.07 小飼 弾 日本実業出版社 売り上げランキング: 750 Amazon.co.jp で詳細を見る ・プログラマーの三大美徳（怠惰、短気、傲慢） ・DRY（RoRで有名になりましたね） などプログラムを使って仕事をされている方には 当たり前なところがベースにはなっているのですが、 是非プログラムをやらないヒトにも読んでいただきたいです。 「プログラム」というとコードの羅列のイメージですが、 この本の中では使うヒトの「自立した意識」まで含めて 「仕組み」と説いています。 使うヒトと使う目的によってその書かれたコードが うまく活用されるかは変わってくるのが「テクノロジー」 のおもしろいところです。 エンジニアとマーケターのコミュニケーションギャップにも是非。

ITmediaにチームでの開発についてかかれていました。 ネットサービスに限らず、複数人でものを作ったことがある人なら分かると思いますが、人がいればいるほどコミュニケーションコストがかかります。人が多ければ作業をできる人が増えるため、早く作れるということは決してなく、むしろ非効率の場合も多いのです。最近、1人でネットサービスを作る人が増えてきましたが、これはそういったコミュニケーションのムダを省けるため、むしろ作りやすいということなのでしょう。 しかし1人で作っていては、自分の実力以上のものは作れません。自分の力以上のものを作り上げていくには、コミュニケーションコストがかからない人たちと組むしかないのです。 こえ部のメンバーはそれぞれの実力を認め合い、お互いの反対意見にも耳を傾けながら、サービスを作ってきたのです。「僕の言う通りにやられたらここまで成功していなかったと思います。お互いに意見を言い合えたのがよかったですね」 「それはできない」とは言わない　急成長する音声コミュニティー「こえ部」 （「1を10にする」ネットサービスの育て方 / ITmedia News） 確かに一人での開発はスケジュールがゆるかったり、 コーディングの他のひとの連携(具体的にはSubversionや Gitなどのバージョン管理)とかのコストがあまりかからないので 楽なんですが、どうしても一人でできることには限界があって、 最初のコンセプト自体に客観性がたりない 一人しかコーディングしてないからコードがわかりづらい ↓ 最初の人との差があるからプロジェクトに他のひとが参加しづらい プロジェクトの更新が一人に依存する ↓ サービスのクオリティアップにブレーキがかかり、伸びていかない ↓ 最初にもどる、もしくはフェードアウト、、、。 ということになりがちなので、サービスはコンセプトを 作る最初と、サービスを提供し続けることが重要 (そして一番難しい)だという認識をおいて、 はじめから妥協しないメンバーをそろえてスタートする方が はじめは時間がかかっても、長期的には伸びるサービスを 展開していけるかもしれないですね。 もっと多くのプロジェクトやアイデアが コンセプト段階でオープンになって、チーム開発が活発に なればいいなと思います。 開発者向けのアイデア投げ合いサービスみたいなのほしいですね。 ごりごりの開発者向けじゃなくってもっと「興味がある」という 人たちも参加できるような敷居の低いやつがあれば、、、。

そのうちアップしようと思いますが、この間ゲットしたPoken（電子名刺サービス）にシールを作って貼ってカスタマイズするのを社内でたのまれていくつかやってみてます。 もちろんもろもろコストは発生していますが、できれば「ビール1杯おごりで！」ということでゆるーく受けてます。 ビール1杯で、というのは海外にもあるみたいで、Wikipediaにも登録されています。 Beerware (Wikipedia) 僕が個人的に好きなのはビールが直接会わないと払えないこと（缶ビールとかは反則w）。 「ビール1杯払います。是非、今度一緒に呑みに行きませんか？」 という直接のコミュニケーションがとれるのはすごくうれしいこと。 ビールウェアライセンス。うまく使って心から満たされる開発をしていきたいですね、、、。