続ワイヤーフレーム

何を表現したいかによってワイヤーフレームの見せ方が異なります。

引用元: ワイヤーフレーム制作の５つのアプローチ : could.

以前に、ある業務管理ウェブアプリケーションの仕様策定や要件定義の段階で、顧客がPPTによる「ワイヤーフレーム」を時間を掛けて作って（打ち合わせ当日に資料として配布して）いたのを見て無限の純粋さを感じたという件を話題にしたが、エンドユーザー向けのウェブページ制作で且つ、実装作業から顧客や担当者の確認作業に至るまでの反復時間が長〜いウォータフォール型方法論という条件であれば、上述に引用したような手法や導入方法は有効だと思った。平たく言えば伝統的な大企業とのやり方になると言えるだろうか。

しかし世界的な流れで手数を少なくし効率化を求める、強いて言えばクリエイティブな（個）人がサクッと作ることができるものなら、なんだってアリになろうとしている時代に、企画段階で時間を掛けて体裁を整える必要性は条件を問わず益々低くなる一方だと感じている。実際には顧客の性格や経験値にも因るのだが、スカイプなどのビデオ会議で手書きの図を示しながら納品に向けて作品を調整していく（そう言えば Skype for Mac がようやくアップデートで画面共有ができるようになった。）、あるいは打ち合わせの際に描いた図を iPhone のカメラで記録し確認用に共有するということが当たり前のようになってきている。またこのような概念の根底には「ソフトウェアは動いているものこそが設計書である」という考えがあるし、機能や要素を段階的に追加することで、あっという間に図は何度も書き換えて再確認の繰り返しとなるからである。

ものの序でに、例の管理ウェブアプリの画面遷移図を最初にどのように書いたのかその一部を公開しておく。この図を使って提案した後でも先方はエクセルを使って今までのメールのやり取りにIDを付与してまとめ出し、新たに30ページほどあるワイアーフレームをPPTで作成しようとしているのだから、いよいよ本格的にデスマに向けてホラ貝の音が鳴り出すところだろう。それよりもまず小さな機能を目標として動くものをサクッと構築後に動作確認を提示し、そこから次の機能を検討するということを繰り返して組み立てて行った方が効率的であると思うし、事実、30ページのワイアーフレームの提案で見積もると予算の許容を２倍も越えてしまい、これは企画重視で何でも押し込んでしまいがちな典型例だと感じた。

アジャイルWebアプリケーション開発では当然の方法論ではあるのだろうが、特にフロント側の制作しか知らない方に、こんな設計や企画の進め方もあるということを知る手助けになれば幸いである。（字が汚いのはご容赦願いたい。）また併せて取得するデータ設計の書類もあることをお忘れなく。

Share on Tumblr