ricollab Web Tech Blog » design http://blogs.ricollab.jp/webtech ricollab engineers' blog Mon, 26 Apr 2010 02:09:12 +0000 http://wordpress.org/?v=2.8.2 ja hourly 1 ペルソナ/シナリオ法セミナーに参加してきました http://blogs.ricollab.jp/webtech/2008/08/persona_seminar/ http://blogs.ricollab.jp/webtech/2008/08/persona_seminar/#comments Wed, 27 Aug 2008 06:20:23 +0000 yohei http://blogs.ricollab.jp/webtech/2008/08/persona_seminar/ 昔、とあるデータベース研究の偉い先生に、研究は上位レベルレイヤーか下位レベルレイヤーかどちらかに偏っている方が面白い、というような話を聞きました。とくにそれを意識していたわけではないのですが、最近の自分の興味がその言葉のとおり、一番上と一番下の両極端になってきているなと感じている山本です。

上位レベルレイヤーの方では情報アーキテクチャや情報デザインがとても気になっています。いわゆる REST 的な文脈のリソースモデリングに関ってくると考えているからです。そんな折に、社内のとあるUI系研究者の同僚から「ペルソナ/シナリオ法による商品・サービス開発」というセミナーがあるよ、と教えてもらいました。

プログラムを見ると、いつもブログを拝読している(でも情報量が多くてなかなか読みきれていない)千葉工業大学の山崎先生と DESIGN IT! w/LOVE の棚橋さんのご講演ではないですか。さっそく嬉々として申し込みを行いました。

当日は中野坂上の会場いっぱいに100名くらいの参加者があり、たいへん盛況なセミナーでした。
以下では、汚い字で書いた下手なマインドマップとともにレポートしてみます。

まず、山崎先生から「ここちよい体験のためのデザイン ペルソナ・シナリオ法とは」と題して講演がありました。

高度成長期が典型的ですが、これまではモノが不足していたためモノそのものに価値があり、必要な機能を満たすモノさえ提供すれば買ってもらえる時代でした。しかし、今はモノがあるのは当たり前の時代です。モノがあることを前提としてどのような商品やサービスを提供していくか、が重要になっているという背景があり、デザインがモノ中心(色やかたち)から人間中心(お客様の満足)に移ってきたそうです。これは自分の時代感覚とマッチしてナルホドと思いました。

棚橋さんの話(ペルソナ/シナリオの作成のための具体的な実践テクニック)は、ペルソナを作っていく過程のデザイン作業を具体的に、そして実践的に解説するものでした。印象的だったのは、ペルソナをグループワークの共同作業で作ることで、ドキュメント配布によるメンバー間の認識のずれや、大量な情報を読み込むオーバーヘッドを回避することができる、という内容でした。

セミナー全体を通してよく理解できたのは、ペルソナは単なるデザイン手法やマーケティング手法なのではなく、製品やサービスを企画・設計・開発・販売するプロジェクトチームの中でのコミュニケーションツールなのだ、ということです。たとえば Web サイトの色合いを決めるときに、普通の議論だと「自分が赤が好きだから」とか「コーポレートカラーが青だから」、「競合サービスが赤だからうちは青」などという議論をしがちですが、「メンバー全員で作ったペルソナは何色を求めているのか」を議論するとプロジェクトチーム内で合意も得やすいし結果も妥当なものになります。

本当は大和ハウスの山口さんの事例紹介もあったのですが(これも面白かった)、長くなりそうなのでこれくらいで…

このような有益なセミナーを無料で開催してくださるイードさんは太っ腹ですね。参加して本当によかったです。ありがとうございました。

]]> http://blogs.ricollab.jp/webtech/2008/08/persona_seminar/feed/ 0 リソースの考え方 http://blogs.ricollab.jp/webtech/2008/01/concept_of_resource/ http://blogs.ricollab.jp/webtech/2008/01/concept_of_resource/#comments Thu, 10 Jan 2008 02:14:15 +0000 yohei http://blogs.ricollab.jp/webtech/2008/01/concept_of_resource/ Web アプリケーションや Web サービスを RESTful に設計するときに、まず大切になるのはリソース設計(リソースモデリング)だと考えています。私が自分でサービスを開発するときは、そのサービスでどんなリソースを提供するのか、をまず考えるようにしています。

リソースの設計は、関係データベースのスキーマ設計のように系統立ててまとまった手法は存在しません(情報アーキテクチャは一つのスタートポイントになるのでは、と考えています)。

今回は以前、社内向けにまとめたリソース設計に関する文書を再構成してみました。何かのヒントになれば幸いです。

＃余談ですが、RESTful Web Services を初めて読んだとき、 表現の選択のところで出てくるフォーマットリストとほとんど同じものが9章に出てきてちょっとびっくりした思い出があります。

概要

Web サービスや Web アプリケーションの設計を行うときは、どのようにリソースを分割していくかが重要となります。本文書では、REST (Representational State Transfer) におけるリソースについて簡単に振り返り、新しくリソースを作成する際のヒントを示します。

リソースの考え方

REST の定義に従えば、リソースは情報の断片です。

しかし、それではあまりに抽象的すぎるので、ここではもう少し具体的な定義をします。

リソースはたとえば以下のようなものです。

これはすべて Web 上にあるデータです。そう、リソースとは Web 上にあるデータを少し抽象化したものだと考えても構いません。

概念的には Web 上にないデータでもリソースと捉えることは可能ですが、無理にはやらない方がよいでしょう。たとえば「人」というリソースを考えるのは面白いですが、残念ながら物理的な人は Web 上でデータとして存在し、やりとりされることはありません。

Web 上に存在するのは「人」ではなくて「人のブログ」だとか「人の写真」でしかないのです。

リソースと URI

Web 上のリソースの大きな特徴の一つとして、「全てのリソースが URI を持つ」ということが挙げられます。リソースが URI を持つことでリソース同士をリンクさせることができるのです。

リンクは Web を考える上で非常に重要です。リンクされていない Web ページは Web 上に存在しないも同然だからです。

リソースとリソースの表現

リソースは情報、あるいは Web 上のデータだと述べました。このリソースをサーバ・クライアント間で転送するときのデータ形式のことをリソースの表現といいます。

一つのリソースでも複数の表現を持つことがあります。

たとえば2006年10月10日の東京地方の天気予報、というリソースを考えてみましょう。このリソースの URI はたとえば以下のようになります。

  http://weather.example.com/20061010/tokyo

HTTP クライアントがこのリソースを GET するとこのようになります。

リクエスト

GET /20061010/tokyo HTTP/1.1
Host: weather.example.com

レスポンス

HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8

<html>
  <head>
    <title>2006年10月10日の東京の天気</title>
  </head>
  <body>
    <h1>2006年10月10日の東京の天気</h1>
    <p>晴れ</p>
  </body>
</html>

ここでサーバからクライアントに返されているのは、 2006年10月10日の東京地方の天気予報、というリソースの「HTMLによる表現」です。

このリソースは「晴れ」という情報を持っていますが、その表現形式は HTML であっても、 XML であっても PDF であっても画像であっても音声あっても映像であっても構いません。重要なのはこのリソースが「2006年10月10日の東京地方の天気予報」を表しているということです。

HTTP の Accept リクエストヘッダを使うと、欲しい表現の形式の優先度を明示的に指定することもできます。以下の例は Atom 形式の表現を HTML 形式の表現よりも高い優先度でリクエストしている例です。

リクエスト

GET /20061010/tokyo HTTP/1.1
Host: weather.example.com
Accept: application/atom+xml;q=0.9,text/html;q=0.5

レスポンス

HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8

<entry xmlns="http://www.w3.org/2005/Atom">
  <title>2006年10月10日の東京の天気</title>
  <updated>2006-10-10T00:00:00Z</updated>
  <author><name>foo bar</name></updated>
  <content type="xhtml">
    <div xmlns="http://www.w3.org/1999/xhtml">晴れ</div>
  </content>
</entry>

リソースと URI は1対1の関係ではないため、複数の URI が同一のリソースを指すこともできます。たとえば、上記の天気予報の URI

  • http://weather.example.com/20061010/tokyo

と、HTML 表現や Atom/PDF 表現を明示的に参照する URI

  • http://weather.example.com/20061010/tokyo.html
  • http://weather.example.com/20061010/tokyo.atom
  • http://weather.example.com/20061010/tokyo.pdf

は同じ「2006年10月10日の東京地方の天気予報」というリソースを指しています。

リソース表現と選択肢

上述のように、一つのリソースを提供するのにも、いくつもの表現の選択肢が考えられます。ここでは、代表的な表現の形式とその特徴を簡単に説明します。

  • HTML/XHTML
    • Web 上で最も一般的な形式
    • ブラウザで表示できるので、人間が読める
    • ここで挙げた形式の中で最も自由度が高い
    • 逆にいうと最もあいまいな形式
  • microformats(XHTML)
    • イベント情報、レビュー、コンタクト情報といったあらかじめ決められたデータ形式を XHTML に埋め込むための規格
    • XHTML の class, rel 属性を利用するだけなので、他の形式との親和性が高い
    • XHTML のあいまいな部分をある程度制限し、人間が読むだけではなくプログラムからも扱いやすい形式
    • XHTML と併用可能
    • microformats.org で定義されていないものは一般性に欠ける
  • Atom feed/entry (RFC 4287)
    • HTML が人間用ならば、Atom はプログラム用の代表形式
    • XML なので HTML よりもあいまいな部分が少い
    • contents 要素などに XHTML を入れることができる
    • タグの拡張が自由
    • ある程度のメタデータ(ID、タイトル、日付、著者)はあらかじめ決められている
    • AtomPub との親和性が高い
  • 画像(gif/jpeg/png/pdf)
    • これらの形式でしか表現できないリソースも多い
    • HTML の img 要素からリンク可能
  • JSON/JSONP
    • Javascript から利用しやすい呼出しやすい
      • Javascript 以外のプログラミング言語のバインディングもある
    • データ表現に優れている
      • 配列、データ型、ハッシュなどの表現も可能
    • XML(XHTML/Atom) よりも記述がコンパクト
    • HTML の script 要素からリンク可能

Web API とリソース

ここまでずっと Web API という言葉を出さずにリソースについて説明してきました。

いわゆる Web API というのは、 URI と HTTP を使ってリソースを提供し、編集・更新する仕組みです。すべてのリソースは URI で特定でき、HTTP を使ってさまざまな表現形式でクライアントとサーバの間のやり取りが行われます。

HTTP ではメソッド情報は固定されています。オブジェクト指向設計でクラスの振る舞いを考えるように、リソースの振る舞いを考えても HTTP メソッドは追加できません。リソースに新しいメソッドを追加したくなったら、別のリソースを用意するのが正しい考え方です。このように、HTTP を使った Web API の設計では HTTP メソッドを限定したり、拡張したりすることはなるべく避けるべきです。

この HTTP メソッドを固定する考え方を統一インターフェースと呼びます。すべてのコンポーネント間で、ただ一つのインターフェースを使うことで、世界規模での相互運用性が初めて確保されるのです。

Web API は、URI と HTTP を使ってリソースを操作する仕組み、と言い換えることもできます。

まとめ

Web API を設計する上で、最も重要なのはリソースの設計です。リソースの設計は大きく次の二つに分けられます。

  • リソースの URI の設計
  • リソース表現の設計

リソースは抽象的な概念ですが、今我々がブラウザから使っている Web をあてはめて考えると非常にわかりやすくなると思います。ブラウザを人が操作しているところが、プログラムにかわるということです。

リソース設計で悩んだときは、そのリソースの HTML 表現を考えてみましょう。

]]> http://blogs.ricollab.jp/webtech/2008/01/concept_of_resource/feed/ 0