【イベント参加レポート】 WCAN 2008 Autumn

☆

まだ、7月に開催された WCAN 2008 Summer の参加レポートも書いてないんだけど、先に、先週末(2008年9月6日)の WCAN 2008 Autumn の参加レポートを書きます。

自分なりの要約

メインのセッションは森田雄さんの「スペシャルコンテンツ」の話と、伊原力也さんの「コンテンツ仕様書」の話。

スペシャルコンテンツの作り方 プランニングからディレクションまで

スペシャルコンテンツというのは、要するに、メインコンテンツ が Flash で構成されているサイト(で、期間限定のもの?)。画面遷移が多い割りに短納期ということが多いようです。

どうやってプロジェクトを遂行しているか。設計に時間をかけて、実装にはあんまり時間をかけない。納期直前は徹夜も多い(けど、休むときは休むのでデスマーチにはならない)。

結構、力仕事みたいですね。

効率的なデザインと実装のためのコンテンツ仕様書づくり

仕様書の話の方。

Word や Excel や PowerPoint で仕様書を書くのは簡単だし、顧客も Office くらいは持ってることが期待できるので情報伝達しやすいというメリットがある。その反面、仕様書から実装に落とすのが手間。いっそのこと、html + CSS でプロトタイプというかモックアップを書いて、それを仕様書にしてしまえばいい。見映えはそのものズバリだし、実装に落とすにも、その html をコピペすれば OK。

html で書けば何でもいいかというとそうではなく、そのプロジェクトで必要になりそうなコンポーネント(パーツ)群を html 断片として用意し、そのコンポーネントの組み合わせでモックアップを作るようにする。コンポーネントをライブラリ化しておけば、将来、他のプロジェクトでも流用できる。

このやり方で手戻りもほとんど発生しなくなったし、品質も確保できている。途中からプロジェクトに参加した人にも簡単な説明だけで、すぐに参加してもらえる(コンポーネントを組み合わせるだけで作れるので、どんなコンポーネントがあるか、見てもらうだけ)。

ただ、この方法がベストかというと、たぶんそうではないと思うので、今後も改良すべきところは改良していく。とか、そんな話。

メモ

以下、会場で取ったメモをそのまま載せておきます。たぶん、聞き間違い、勘違いも混じってると思います。 ここ、おかしいよ、とか指摘してください。

(1) スペシャルコンテンツの作り方 プランニングからディレクションまで (森田雄さん)
http://securecat.exblog.jp/8560022/
・やってる仕事
コミュニケーションデザインの戦略的支援

実況ジェネレータ            http://www.projectblue.sony.jp/jikkyo/
  実際にサッカー関連のサイトとかで利用されている
食ベナレ旅ナレジェネレータ  http://www.projectblue.sony.jp/tg1-tabenare-tabinare/
ドラマチックジェネレータ    http://www.projectblue.sony.jp/tg1-dramatic/
  「実況ジェネレータ」のシステムを流用
  つまらない4コマ漫画の劣化コピーみたいで、あんまり好きではない

いきものめっけ  http://www.mikke.go.jp/

言の葉草  http://www.iseokagenosato.jp/kotonohagusa/
  → スペシャルコンテンツの例として、あとで触れますとのこと

・基礎知識
コミュニケーションデザインとは
  戦略、設計、表現、実装 の4層からなる
  どの層に力を入れるかは会社、プロジェクトによって異なる
Webのふるまい
  メディア
  ツール
  チャネル
    の3タイプ。共存不可能
    どのタイプのWebページにするかきちんと決めてから作る
    ごちゃまぜにすると、わけのわからないサイトになってしまう
    目的をはっきりさせる

    サイト構成上、あるページはメディア、あるページはチャネル、というのはあり。
    同一ページに混ぜちゃうのがだめ。

    メディア: 3つのタイプのWebの中ではいちばん汎用的
    チャネル: 事業戦略(会社の規模等が影響)にあわせる
    ツール: 営業ツール、イントラ向けツール、マイページの集合体、etc
スペシャルコンテンツ
 ・サイトの一部の特設サイト的なもの
 ・突発的に、ゼロの状態からからフルスクラッチで作るサイト(かつ、期間限定的なもの)

「俺たちは超高度情報化社会に立ち向かっていくんだ」

 スペシャルコンテンツといえども、
   短期間で作る場合は、指標(明確なコンセプト、目的)がないことが多い。
   とにかく作ればいい、という感じ

   短期間のプロジェクトは直感で作ることが多い。細かいタスクは設定しない
   コンセプト設定後、とにかく走る

   要するに、勢いで作る

グッドデザイン賞に応募するとめちゃくちゃお金がかかる(あんまり、おすすめしない)



(2) Lightning Talks   http://www.wcan.jp/lt/20080906.html
・WCAN Lightning Talks システム（有限会社アップルップル やまださん
   ライトニングトーク用の時計を作ってみた
   http://www.wcan.jp/lt/ でつっこめる (けど、つっこみ用Webページでは、誰が何をつっこんでるか、見えない ＞＜)
   つっこみは、時計のところに、ニコニコ動画風にコメントとして流れる

・クリネタvsCCN対談イベントについて（株式会社コンテンツ庵 堀田さん） 
   雑誌「クリネタ」の対談イベントの宣伝
    活字で読むデザインマガジン デザイナーやコピーライター向けの雑誌
    1行広告が2万円で出せる

・Webデザインプレゼン交換会（トライデントコンピュータ専門学校 長谷川さん） 
    2つの学校間でプレゼン交換会を実施
      トライデントと日本電子専門学校
      イラスト学科

・トライデントサイトリニューアルプレゼン（トライデント学生 佐藤さん） 
    プレゼン交換会でどんなプレゼンを行なったか
      勝負だから負けるな、と言われた
      実際に行なったプレゼンの短縮版
      トライデントの公式ページをネタ元に、改善点をピックアップ
      検索性、探しやすく … 見つけたい情報が見つけにくい

・Webで「Dragon Quest」のようなことをしてみる with JavaScript（メガネラボ 岩田さん） 
    Dragon Quest 風の表示をする (いまのところ、Firefox 専用)
    コマンドを実行できる
    ユーザごとにカスタマイズできる
    ついったー上でも動く

・サイトマップの管理にチャレンジ中（データファーム 勝又さん） 
    実際に製作してみると、製作中にお客さんからいろいろ要望が出てきて、最初のサイトマップ案とどんどんちがってくる
    メニューがわかりづらい、あとから追加したコンテンツにアクセスしにくい
    コンテンツ変更、追加と同時にサイトマップ案に反映させていくには?
      ブログを使って管理 → めんどう
      できるだけ簡略化したい → ファイル管理ツールを導入してみた

・OSC名古屋 CMS大決戦「Fight! CMS」レポート 最後にC.M.C. の栄冠を手に入れたのは....（日本PostgreSQLユーザ会 沢田さん） 
    8月9日にあった大決戦の模様
    1位は島根県版CMS

・仕様変更につよい設計を考えてみた（株式会社日本情報化農業研究所 古荘さん） 
    京都の人
    オープンソースのCMSを開発している
    特にユーザインターフェースの手直しが多い
    テンプレートエンジンを作ってみた (デザインと動作の分離)
      php版 wicket (Javaのパクリ)
    CMS本体の機能の改良とUIの改良が独立に行なえるようになった

・Python東海 東海地域Pythonista語らいの場（VISH株式会社 小田切さん）
    pythonの勉強会  (aodagさん)
    きっかけはOSC名古屋の「勉強会大集合」
    第1回は12人参加 (8月31日)
     Mercurial (分散バージョン管理システム)
     Google App Engine
    勉強会というよりは語らいの場
    次回は9月27日 VISHのセミナールーム

・駅比べ (マール http://www.maar.co.jp/ の増田さん)
  トレーディングカードのような感じで、駅に関するカードを集めて対戦するサイト


(3) 効率的なデザインと実装のためのコンテンツ仕様書づくり (伊原力也さん)
役割分担
  情報設計
  ビジュアルデザイン
  コーディング

dreamweaver でテンプレートを作成 → コントリビュートというソフトで中身を埋める → 仕様書完成

コンテンツ仕様書とは
  モックアップ、プロトタイプ、土台のこと
  まとまりのある何か。スタンダード、体裁は特に決まってない
  デザインを含んでるのか、ドキュメントのみなのか、どこまでカバーするのか、決まりはない
  どこまでの精度で書くのか、もまちまち

仕様書の例
仕様書を分解してみると
  体裁
  守備範囲
最初に仕様がきちんと決まってない(あるいはきちんと仕様を書いてない)と、あとの方の工程で混乱

仕様書のフォーマット
  Office 系のもの(Excel、PowerPoint)を使う
    メリット
      学習コストが低い
      何か仕様書っぽいものができる
      短期間でできる
      顧客もOffice系のソフトはだいたい使ってる

    デメリット
      似て非なるものが増殖する
      再利用性が低い (コピペで取り出しにくい、そのまま html に貼り付けるとかできない→手で入力し直し)
      版数管理が煩雑
      土台を作るツールとしては最適ではない
      紙で印刷して確認という形になりがち
      実際のWebと食い違う
      ナビゲーションの確認がしにくい (ページ単体の確認としては使えるが、サイト全体の確認には不向き)


コンポーネントベースの実装
  コンポーネントという概念を導入することで、いろいろな問題を回避

コンポーネントベースの設計と実装
  ルールと共通化
    柔軟さ、スピードが必要
    html と CSS (Web標準)
  コンポーネントという考え方
    あからじめ、よく使うパーツを作っておく
    パーツを組み合わせて作っていく
    パーツ → コンポーネント
    典型的なものを用意する
  コンポーネントリストを見ながら、各ページの仕様を決めていく

メリット
  土台がはっきりしている
  あとでページ単位で検証できる
  途中で入ってきた人にも説明しやすい
デメリット
  ページまたがりのデザインがしにくい
  ルールの範囲内ではうまくいかないページが出てきたときにどうするか

Dreamweaver で仕様書を書く + Contribute で版数管理、承認

  html と CSS で仕様書を書く → そのままモックアップになる
   (要するに、コンテンツ仕様書というのは、マンガでいうところのネームに相当、という理解でいい?)

  デザインの変更
    Dreamweaver で正規表現を駆使して一気に変更

  パーツをライブラリ化 → 他のプロジェクトでも流用可能
  ページの一覧は作る
  元に戻したいときは Contribute でロールバック

懇親会とか

2次会(世界の山ちゃん 金山南店)では、ライトニングトークでしゃべった人が多いテーブルにいました。 何かいろいろ会話が弾んだ気がしますが、あんまり覚えてなかったり。

3次会(魚民)では、でんぷん系料理のオンパレード。アピオスは要チェックですよ(知らないけど)。 Twitter をやってる人が多そうだったので、何人かからアカウントを聞いたんですが、アルファベット何文字かと数字の組み合わせの人とか、覚え切れませんでした。私(tsupo)のこと覚えてたら、followしてくださるとうれしいなぁ、なんて。

4次会は徹夜カラオケ。朝5時30分まで歌ってました。総勢12人。