CMSもRIAもIAの役割が重要

(CC)Cappellmeister

悲しいかな仕事が空いているのでセミナー三昧の今日この頃、皆様いかがお過ごしでしょうか？　今日は、ロフトワークさんのクライアント向けCMSセミナーと、その後のAdobeMAX2009にいってきて、共通して気がついたことを、社内報告と備忘録を兼ねながら、まとめてみたいと思います。

ワークフローが変わる

CMSセミナーは、第2部の林さんのパートがとても共感できた。CMS導入のワークフローを、設計、実装、検証に分けて、その比率が１：１：１であるのが理想という話。ネットでシステム開発の一般的な工数比率を調べてみると、実際に、失敗プロジェクトと、成功プロジェクトの違いは、この比率にあるという調査結果に当たる。

大体、失敗プロジェクトは、実装の比率が大きく、設計、検証が小さい。設計段階での工数見積が甘く、検証をする余裕がないので、品質の低いシステムができあがってしまう。

ロフトワークでは、全ページのリストをきちんと作って、具体的に何ページのサイトを作ろうとしているのかを把握することの重要性を語っていた。その為に、全ページのリストと、ワイヤーフレームだけでなく、各ページのＣＭＳ仕様書（新着なのか、カテゴリ別なのか、何件表示するのか等々）を作っているようだ。

AdobeMAXでの、bAのワークフローでも、同様なテーマを扱っていた。大規模サイトを制作するときのワークフローについてだ。bAでは、ワークフローを、設計、デザイン、実装と分けていた。たしか、デザインを「表現」と表していたのが、bA流だったと思う。この場合、CMS前提ではない静的サイトなので、検証が別あつかいになっているのだと思うが、設計段階で、どこまでリアリティのある設計ができるかという話だった。

bAでは、ワイヤーフレームの制作効率を上げることと、ワイヤーフレームを作って確認をとっても、実装段階で差し戻しが多いことに着目し、紙のワイヤーフレームから、HTMLでのワイヤーフレームにかえることをやっているようだ。すなわち、実際にテキストが流し込まれ、リンクによってページ遷移を確認できないと、クライアントはイメージがわかないのではないかと言うことだ。

これを実現するために、デザインをモジュール化し、ワイヤーフレームを全ページ展開するのと平行してデザイン作業に着手できるようにしたり、ワイヤーフレームをHTML化するために、Dreamweaver→ＣＭＳ→Contributeといったツールを連携させることによって、大量のページを効率よく設計して、クライアントとイメージの共有をするということを実験しているとのことだった。

実は、このワイヤーフレームをHTML化するということは、自分もずいぶんと前からやっていた。ワイヤーフレームという言葉がまだ一般的でなかったころ、自分たちは、このHTMLによる画面遷移と要素確認のラフを「スケルトン」と呼んでいた。今でも自分のお客さんの一部では、スケルトンがそのまま用語として定着している所があるぐらいだ。

このスケルトン、結局Webを2回つくっているのと変わらないじゃないかという話もあるが、原稿整理をテキストでやっているのと、さほど手間が変わらない。フォトショップで全画面つくるよりはあきらかに楽だ。HTML構造が決めうちでいけるところなどは、そのまま流用できるわけで、無駄は思ったより少ない。

むしろ、スケルトンが完成度が高すぎると、若いデザイナーだと、そのまま色をつけただけのデザインをやってしまいがちなところが、問題といえば問題。アートディレクションをきちんと平行して作業をしておくのがポイントで、スケルトンをみてからデザインすると、結構影響を受けがちだ。

この2社の事例に共通しているのは、設計にしっかりとしたコストをかけているという点だ。いい加減なワイヤーフレームと原稿整理で、あとはデザイナーの力量に任せるのは、ページ数が多いサイトの場合、効率が悪い。雑誌編集のように、ラフとなるワイヤーフレームの段階で、一度クライアントと詰めておくことは重要だと思った。

ちなみにうちの場合、ワークフローは大きくわけて、設計、実装、検証の3段階。いわゆるデザインは設計フェーズに入る。要件定義、IA、コンテンツ編集、ビジュアルデザインまでが設計で、デザインは主要パターンを抜き出して検討する。それを全ページに展開するのが、実装段階となる。

役割分担が変わる

さて設計の重要性を、いくつかのセミナーで確認したところで、じゃこの設計フェーズを、だれが担当するのかというのが問題となる。

一般には、ウェブディレクターという、これまた抽象的な仕事の人が出てくるわけだけど、この職業のとらえどころのなさは問題だと思う。この人はマネージメントとクリエイティブ、どちらに責任を持ってるんだろう。

僕は個人的に、マネージメントとクリエイティブを1人の人がやるのは、あまり関心しない。小さいプロジェクトなら問題がないが、大きなプロジェクトだと、どちらかがおろそかになりがちだと思うからだ。

これは、実装した人が、検証しないほうがいいという話とよく似ているかもしれない。実装者はどうしても自分も実装にあわせたフローでしか検証しないものだ。想定外の使い方は、そもそも想定していないからテスト項目にあがってこない。故に検証は、検証専門の担当者、いわゆるＱＡがいることが理想だ。

マネージメントも、お金、スケジュール、スタッフ間の調整といったことと、クリエイティブへのこだわり、時間で読み切れないクリエイティブコストといったものを、マネージメントと、クリエイティブが緊張関係を持つことでバランスをとるのが理想だと思う。故に、ウェブディレクターといわれる仕事は、ＰＭとＩＡに分けてしまうのが理想だ。この場合、ＰＭが主にスケジュールとお金を、ＩＡが、先にでてきた全ページの仕様を、ＡＤとともに設計するのだ。

まとめると、役割は5つに分かれる。ＰＭ、ＩＡ、ＡＤ、ＱＡ，そしてPGだ。(SEはディレクターと同じぐらい抽象的だからあえて使わない）これにコーダーやデザイナー、現場のPG(プログラマー)といった人たちが加わって、プロジェクトメンバーが構成される訳だ。

ここで以外だったのは、この構成が理想とセミナーで解説していたのは、Web系の話ではなく、どちらかというとシステムよりの、RIAの開発におけるチーム構成の話だった。Site4Dというその会社は、RIA制作会社では珍しくデザインから始まった会社のようだったが、RIA開発においても、ＩＡ担当の存在が重要であることを力説していた。確かに業務フローから画面要素と遷移を設計するという事を考えると、ＩＡ的な素養

Adobeの新しいUI開発ツールでは、ＩＡ，ＡＤ（＝グラフィックデザインより）と併せて、Ｉｘ（インタラクションデザイナー）という役割も想定しているようだった。ボタンの状態変化や、画面切り替え時のアニメーションといったインタラクションに関わる部分を中心に、ＩＡ、ＡＤの領域を横断するような立場だ。

ＵＩ/ＵＸ開発に3人（ＰＧいれると4人）もの設計者がかわるのはとても理想だが、逆に4人いれば、相当のものまで作れるなという感じはした。これにＰＭとＱＡをいれても６名。WebもAiaxなどインタラクションが増えているので、ＵＸ，ＷＥＢ共通して、これがチームの最大人数とも言える。あとはそれぞれのアシスタントが必要な時に充当されればよいわけだ。

逆を返すと、人数が少ない場合、この役割分担を限られた人で兼任しなければならなくなる。PM＋ＱＡ、ＩＡ＋ＡＤ＋Ｉｘといった様な組み合わせが考えられる。各人のスキルセットを考慮して兼任するわけだが、注意しなければならないのは、マネージメントとクリエイティブはきちんと分業するということにつきると思う。設計とはクリエイティブそのものだ。設計と実装をきちんと分離するためにも、マネージメントとクリエイティブの分離が必要なのだ。

でなければ、マネージメントと、実装の狭間で、一番大切な設計がないがしろになってしまう。そしてこの一番大切な設計のコストを、きちんと認める習慣がまだまだない。まったく新しいものを考えろと要求しているのにだ！

マネージメントとクリエイティブを兼任するなんて、ジブリの映画で、宮崎さんと、鈴木さんの役割を、ひとりでやるようなものだもの。ありえないと思っておいた方がいい。それは、ワークフローが変わってきた事からも必然的な要請なのだ。

また、ぐだぐだな文章になってしまった…..