Web構築のワークフロー - Labs : IA wiki

提供: IA Wiki
移動: 案内検索

当サイトでは、Webを構築する際に以下の6つの段階を提案する。これはウェブ戦略としての「ユーザーエクスペリエンス」―5つの段階で考えるユーザー中心デザインの考え方を拡張したものである。

  1. 戦略
  2. 要件
  3. 構造
  4. 骨格
  5. 表層
  6. 実装

戦略

企画。目的。目標。コアコンピタンスを明確にする。

Webサイトを使って、何をするのか、何をしたいのか。企業をアピールするのか、モノを売るのか、人を集めるのか。

Webは道具である。その道具を使って「何をするか」を定義なければならない。目的が明確でない道具は、存在意義が無い。

また、ここで決めた目的はプロジェクトのメンバー全員が共有する必要がある。もちろん、クライアントも。

戦略が明確でないプロジェクトは、ちゃぶ台返しや仕様の未実装などが発生しやすく、チーム内での誤解も懸念される。いわゆる「ぶれやすい」状態になる。

クライアントの欲求や隠れたニーズを引き出し、資料化して共有するべきである。

要件

「どうやるか」。要件定義。機能設定。方法論など。

機能定義やデザインテイストや技術選定がおこなわれる。WBSを定義たり、スケジュールを引いたり、見積もりをする。この段階からQCDを強く意識してプロジェクトマネジメントにコミットするべきである。

道具の目的が決まったら、その道具をどう作るかをきめる。CMSを導入するとか、検索機能をつけるとか戦略フェーズの決定事項を実現するための問題解決方法が定義される。

QCDとは

製造業における3要素。ものづくりに関わる人は絶対覚えておくこと。

QCDはトリレンマな関係であるため、互いにバランスをとりながら落とし所を見つける必要がある。

  • Q:品質 (Quality)=機能要件、達成条件など
  • C:コスト (Cost)=おかね!
  • D:納期 (Delivery)=スケジュール 、マイルストーンなど

WBSとは

Work Breakdown Structureの略。(だぶりゅーびーえす、と発音する)(わーるどびじねすさてらいとではない)

文字通り、プロジェクト全体を細分化して構造化した資料である。WBSを作成することで細かいタスクやサブプロジェクトの存在が明らかになり、効率的で合理的なプロジェクト進行が可能になる。

良くできたWBSは、そのまま見積もりの項目になる。また、ガントチャートと併用してスケジュールを定義することも可能である。つまりプロジェクトのQCDを網羅するための根幹資料であり、ある程度の規模を持つプロジェクトでは、WBSなしにはプロジェクトマネジメントは不可能である。

WBS作成については専門資料が沢山あるので、参照されたし。

構造

Webサイトの全体構造を設計する。主なアウトプットはサイトストラクチャである。

時間のないWebの人は、このフェーズを飛ばして骨格設計(ワイヤーフレーム)や表層設計(ビジュアルデザイン)に取りかかることが多いが、良い結果を得ることは難しい。

Webは多次元的な構造物である。その複雑な構造物がどのような意図で設計されたかを共有・記録・吟味するために、サイトストラクチャを作成する。

物理設計(ディレクトリ設計)・論理設計(導線設計など)を行い、サイトストラクチャの完成を目指す。この時、ワイヤーフレームも同時に設計する。ワイヤーフレームとサイトストラクチャを同時にみつつ、設計を吟味するフェーズである。

インフォメーション・アーキテクトってなんだ?

インフォメーション・アーキテクト(InformationArchitect、略してIA)とは、情報設計をやる人のこと。

サイトストラクチャとワイヤーフレームにおける設計は、まさにWeb設計の本丸といえる(IAやってる感が強い)が、この部分だけを切り出して情報設計・インフォメーションアーキテクチャだと勘違いしている人がおもいのほか多い。情報設計とは本来、非常に広義であり、Webだけのものでもなく、もちろんワイヤーフレームを書く行為を指すものでもない。

弊社の仕事において、Webもで紙でもない特殊な表現媒体を取り扱うことがよくあるが、どの場面でも情報設計技術は必須である。それほど原理的で支配的な分野であると言える。

Webの多次元性

画面・ページは平面なので、縦と横の二次元がある。さらにこの画面が、ハイパーリンクによって意図のある構造を成す(三次元)ことでWebが形成される。そして、ユーザーとのインタラクション(四次元)でWebは動的に変化する。他にも時間経過や内容の更新など、多次元的な要素はたくさんある。

Webサイトをただのページの集合(二次元の集合)だとシンプルに考えるのは、非常にもったいない。Webが持つ多時限的な機能と可能性をもっと活用できたら、出来ることは格段に広がる。

骨格

画面設計フェーズ、ワイヤーフレームを作成する。

ブラウザに表示される「ページ」という単位で、表示要素の配置(コンポジション設計)をおこなう。このフェーズに至るまでにサイトストラクチャを作成しているはずなので、それが広義な設計図となる。サイトストラクチャ無しでワイヤーフレームを作成するのは効率と合理性の面からおすすしない。


ワイヤーフレームでの大きな役割として、ナビゲーションシステムの機能定義がある。Webサイトは構造物なので、なにかしらナビゲーションシステムが必要となる。よって、ナビゲーション機能に関わるインタラクションデザインについては、ある程度の見通しをつけておきたい。


もうひとつの役割としては、表層(ビジュアルデザイン)の足がかりとなるコンポジション設計がある。

たとえば、一画面で縦長に作るとか、要素の配置方法に特長を持たせた画面にしたいとか、ビジュアルデザインに大きく影響するコンポジションのアイデアを盛り込むことになる。

コンテンツと設計は「卵とヒヨコ」

この時点でコンテンツの細部が決定しているのは理想的だが、おそらくほとんどの場合、コピーライトやボディコピー、メインビジュアルやロゴ、写真素材などは存在しない。よって、ナビゲーションシステムやコンポジションの設計を重点的に行うべきであり、後から到着する素材に対して、誤差は許容できるような柔軟性を持つ設計を行うべきである。

「素材が無いと出来ないよう!」というのは、一見説得力がありそうだが、素材を生み出すためにはワイヤーフレームまでの設計図があることが望ましいため「卵とヒヨコ議論」に陥る。よって、素材は不確定であると断定し、後からの変更を許容する覚悟でとりかかると良い。

プロトタイプの必要性

なお、設計対象が「インタラクション要素が豊富」であったり「アニメーション要素主体」であったりする場合、エクセルなどの書類を設計資料としてしまうと、設計意図を表現すること自体に膨大なコストがかかる(アニメーションの具合や振り分けルールを言語化するのは非常にしんどいし、なにしろ分かりにくい)。よって、資料はさておき、さっさとプロトタイプ(モックアップ)をくみ上げてしまった方が早くて分かりやすい。

もちろん、ちゃんとしたプロジェクトの場合は後追いで書面化することを求められるが、プロトタイプに対面して、初めて「使った感」がわかってくる。仕様ではキレイにまとまっていたものが、つまらなかったり、分かりにくかったり、なんだか使いにくかったりというのは、よくあることだ。

クライアントも、他人の書いた設計仕様なんて堅苦しいものよ読むより、プロトタイプを「使って」体感したほうが、意見を出しやすい。それはつまり早い段階でのチェックバックが貰えるという、多大なメリットを享受できるということでもある。

表層

いわゆるデザイン。「デザイン」という言葉は広義なので、「ビジュアルデザイン」と表現することにする。

PhotoShopやIllustratorを駆使して「画」を考案し、ワイヤーフレームをベースに、サイトのテイストや細部のビジュアルパーツを定義していく。現状、このフェーズだけで「Webデザイナー」として喰っていけるぐらい確立・独立している分かりやすいフェーズでもある。

しかし、ワークフローとして見ると6つの中の1つである。今後、世間の「Webデザイナー」は、このフェーズの中だけで生きていくことが、どんどん難しくなっていくと思われる。今のうちから「構造設計から後は任せとけ!」というような守備範囲とユーティリティの高さを養っておくことをお勧めする。

なお、ビジュアルデザインについての技法は、主観的な面が強いため、技術として確立しづらいという特性から、当サイトでは言及する予定はありません。

実装

最後に実装フェーズです。サイトストラクチャ、ワイヤーフレーム、ビジュアルデザイン(PSDなど)を元に、納品物をこしらえる。

さらに、機能テスト、単体テスト、接続テストの機能面実装と、それに伴うデバッグや報告書の作成する。

ある程度の規模感があるプロジェクトやクリティカルな情報を取り扱うプロジェクトでは、テストを行う際にテスト仕様書を要求されることがある。


実装フェーズまでに素っ飛ばしたプロセスは、この時点で皺寄せが来る。何倍にも負荷がかかるはずなので覚悟されたし。実装段階でドタバタする人は組織は、ワークフローを見直すことを提案する。多くの場合、戦略設計や構造設計が軽んじられているはずである。

資料について

全ての段階で、できるだけ資料を残すよう心がけること。当サイトで推奨する「設計書:BluePrint」は、要件~表層フェーズあたりが網羅することができる。

資料を丁寧につくることは、チーム内での情報共有につながる。ただし、資料作成自体に莫大なコストをかけるのはナンセンスなので、伝達効率の良い、できるだけ簡単に書ける資料作りを目指すべきである。

よって、資料に画一的な形式・フォーマットはむしろ邪魔で、プロジェクトごとに効果的な資料を都度発明するぐらいの気概でちょうど良い。


また、あまり考えたくはないが、プロジェクトに問題が起こり、瑕疵責任を問われた際、合意のとれた資料は証拠(エビデンス)として効果を発揮する。資料作りはテンションが上がらないが、根気よく丁寧に作るべきだ。

まとめ

これが基本的なWeb構築であるが、


参考

  1. ウェブ戦略としての「ユーザーエクスペリエンス」―5つの段階で考えるユーザー中心デザイン