先週の水曜日に行われたIA Summit 2010 Redux in Tokyoに参加してきました。
IA Summitの報告会は去年に引き続いて2回目の参加。場所は大崎にあるNaverで行われました。

スピーカーは、Concentの長谷川さんと、三菱電機株式会社 宣伝部の粕谷俊彦さん。

内容としては、粕谷さんがクライアント的な視点からIA Summitに参加する意義と社内調整的な手法とか、長谷川さんも全体の雰囲気といくつかのセッションについて掘り下げてコメントしてました。内容はプレゼンテーションをご参考ください。

基本的に、IA Summit 2010で発表されたプレゼンテーションはSlide Shareにアップロードされているので、プレゼンの内容だけ見たい人は、Slide Shareを参照するのがいいかと。

個人的に一番印象的だったのは、アンビエントファインダビリティなど和訳をされている浅野 紀予さんのコメント、日本のIA界もプラクティスを積み上げているだけではダメ、プラクティスからセオリーに落とし込まなければいけない。的な内容だったと思いますが。

やはり本場アメリカでは、業界の人々が自分たちの仕事の意義を主張し、重要性をクライアントに認めさせていくという姿勢を感じます。アメリカから提供される成果を消費するだけでなく、日本の現場でもそういった努力が必要ですね。

と、いろいろ考えさせられる内容でした。

Wireframe（ワイヤーフレーム）とは？

ウェブサイトを構成する要素（ナビゲーション、見出し、ボタンなど）を画面単位で記述したウェブサイトの設計資料の一つ。どのような要素が存在し、どこの場所に配置されるかを定義する。ビジュアライズされたデザインとの混同をさけるため、線画で記述されるのが一般的。

上記は個人的な定義ですが、IAIの用語集には以下のように記載されています。

A wireframe, also known as page architecture, page schematic, or blueprint, is a highly simplified sketch of the important information in a page.
The goal is to reflect the relative importance of different elements, including the content and the navigation….see more

ページの情報を単純に視覚化したもので、コンテンツやナビゲーションなどの各要素の優先度を定義する、といったところでしょうか。ただし、人・会社によっていくつか争点になるというか、異なる点があります。例えば

• 要素のレイアウトをどの程度まで精密に規定するか。
• ボタンやフォームなど、UIの挙動を記述するか。
• 画像やテキストなどのコンテンツを含むか。
• 全画面分作成するべきか。
• 公開後の変更をどこまで追記するか。

これらに関しては、それぞれの会社やプロジェクト、Wireframeを作成する人の職域で決めればよいとは思いますが、個人的には、以下のようにすることが多いです。

• レイアウトは相対的な位置（右寄り左寄りなど）や要素の優先順位のみを定義する。
• UIの挙動などの仕様に関しては、機能リストとして別途切り出す。
• コンテンツ自体は、基本的には含まずにコンテンツリストとして別途切り出す。ただしナビゲーションのラベルなど設計を確認するために想起されたほうがよい要素に関しては記述する。
• 画面のフォーマット分だけ作成する。
• あくまで設計用の資料なので、コスト的に余裕がある場合のみ現行仕様を反映する。

例えば、機能リストとして切り出しておけば、テストの際のチェックリストとしても活用できるし、コンテンツリストなどはライターや担当者に入力をしてもらうケースがあったりする切り出しておいたほうが便利。画面数に関しては、後行程の人（コーダーやプログラマ）の人に理解される程度にパターン化。画面のフォーマットもページリストなどで管理するのがよいかと。

経験上、高精細なWireframeはそれ自体の目的が”設計”という点から外れてしまうケースが多いので好きでありません。もちろんデザイナーでもないので、ピクセル単位でレイアウトも規定すること自体できないという事もありますが。

結局結論としては、結局Wireframeは設計に関する要求をすべて提示できるものではないので、その他の資料と組み合わた上で、何をどこまで定義すべきと決めるのがよいのではないでしょうか。

一体なんの為に、わざわざハードウェアキーボードを使えなくしてまで、入力しずらいスクリーンキーボードを使う必要があるるのでしょうか？理由は以下の2点のようです。

• 入力フィールドに履歴を残さないため
• スパイウェアによるキャプチャーを防ぐため

僕が通っていた学部は、情報学部だったんですが、一年か二年の時にIDとパスワードが盗まれて、そのアカウントから学内にいたずらメールが送られるというような事件がありました。情報学部という特性上ハッキングか？という噂がたちましたが、犯人が捕まってみると、後ろからIDとパスワードを入力するのを覗いていたいたというのが真相でした。

サービスを提供する側からすると、公衆の面前でインターネットバンキングを使う人はいないだろうとという想定なのかもしれませんが、旅行中だったり、出先でちょっと使えたりするということこそが、ネットバンキングのメリットでありユースケースなんじゃないかと思ったりもします。あながち、覗き見なんて事もありえなくはありません。

利便性とセキュリティはある種トレードオフなんだと思いますが、当初、口座番号と暗証番号とパスワードだけで使えていたサービスが、乱数表による認証だったりと、どんどん使い勝手の悪くなり、利便性というサービスの本質が失われていくのはなんだかなぁという気分になります。

今の会社でも個人情報を扱うサービスのインターフェイスを設計したことがありますが、この手のサービスにおいては企業側のマインドはユーザーの使い勝手よりも、セキュリティ（安全だという面子）に重きを置きがちなんで仕方のないことかもしれません。

しかし、新生銀行の定期預金は利率いいですね。

もちろん現役のエンジニアなんで、コードの書き方にも触れてはいるものの、全体を見れば、システム開発に関するプロジェクトマネージメントの方法、開発プロセスのあり方、仕様書の書き方、採用からチームビルドの方法といった感じで、読み物として非常におもしろいので、非エンジニアな方でも楽しめる。
文体の好き嫌いはあるだろうが、これは彼の言うところ、退屈な文章に興味を持ってもらえるような工夫だろう。
ソフトウェア開発に関わる開発者、マネージャー、設計者の姿が滑稽に情緒豊かに描かれている。読みながら上司や同僚を思い浮かべて、”あるある”とうなづく事になる。

実際には、彼がどんな人間でどんな仕事をしたノかは知らないし、エンジニアとしてのスキルがどうなのかもしれないが、彼の持つ視野の広さは、僕がシステムエンジニアの資質として非常に重要だと感じる。（自分の知る限りこういうエンジニアは数少ない）

たいていのステレオタイプなシステムエンジニア像としては、実際にシステムを利用するのユーザの事など一切考えず、目の前のコード対峙しつづける。システムの振る舞いについて質問しようものなら、APIがFalseを返していますので、これは正常な挙動ですなんてエラーメッセージみたいなメールしか返さない。こんなステレオタイプなプログラマとやり取りしていると、同じ世界にこんな人間がいるのか？という疑念すら生まれてくる。

システム（ソフトウェア）を使うユーザをの事を考え、ビジネス戦略を理解した上でコードを書く、エンジニアなんてものが存在するのだろうか、ワォ、クール！

社会人としてウェブの制作会社に就職したとき、いきなり実戦に放り込まれたのはいいが、その時は、サイトマップのすら存在も怪しく、ワイヤーフレーム、ましては要求（機能）仕様書なんてのは、そのチームには存在していなかった。そんな時、仕様書ってこう書けばいいのかというのを教えてくれたのでが、日本語に翻訳されたJoel on Softwareだった。

その仕様書に章にも書かれているが、ユーザーが何を実現できるのかというユーザー視点や、単にユーザーではなく、ユーザーに名前をつけて、個性や背景をもった人間として、システムを設計するいわゆるペルソナ的な考え方も紹介されている。

ただ、彼のバックグラウンンドは商用ソフトウェアの開発者なので、ここで書かれているすべてがウェブサイトの開発に当てはまるというとそうでもない。マイクロソフトの話はもういいよと思う時もたまにはあるがどのような立場であっても、どんな形態であってもシステム開発に携わる人間なら一度は読んでおいた方がいいかもしれない。
ということで、★★★★☆