営業は、もはや営業だけのものではなくなってきた、というお話
いつもの客からシステム開発の引き合いがあった。
いそいそと出かけて行き、仕様を聞いてきた。
今回も素晴らしい提案をして受注させてい ただこうと思っていた。
ふたを開けたら失注だった。
信じられなかった。
理由を聞いたら、相手はもう動くソフトを持って、その画面 を操作して見せながら
見積書の説明をしたのだという。
しかも見積金額が自分のところより３割も安い。
そりゃそうだろう、って感じですなあ。
わたしなんかはデザイナあがりなので、要件が発生したらほぼリアルタイムでHTMLモックを作って、そのあとに入力制限だーエラー画面だーといった詳細仕様を詰めていくようにしています。検索フローや会員登録フローのようにプログラムがないと動かない部分でも、ローカルで「限りなく完成形に近い形」まで持っていくことは可能です。
HTMLモックを作る大きな利点は
- ゴールをイメージしやすい
- 開発に入る前に仕様漏れリスク、論理矛盾発生のリスクを軽減できる
- ユーザビリティ、アクセシビリティ、画面数のチェックができる
- 関係者間の認識すり合わせが速い
というところなんですけども、どうも周辺のプロジェクトではパワーポイントの企画書、仕様書だけで開発を始めてしまうことが多い。吹き出し、注意書き満載のパワポを一生懸命作るのはいいんですが、正直わかりづらいし、読む気がしないんですよねえ。。。
もちろん既存サイトの小さい改修や、マトリックス表で見せたほうがいい場合なんかはパワーポイントフォーマットのほうが適していることもあります。
が、リニューアルなど新規の画面遷移が絡む案件は開発前にモックを作って設計方法をよくよく検討したほうがいいように思います。どんなに想像力豊かな人でも「あれ？そういやここクリックしたらどうなるんだ？」みたいなことって必ず出てきますから。
社内で何度かHTML仕様書のフォーマット化を提案したことがあるのですが、エンジニアには「わかりやすい」と支持されたものの、ほかのウエブディレクタには不評でスルーされてしまったのでした。なんだかねえ・・・業務の非効率さの一端はあの見づらい仕様書にある気がしてならない今日このごろ。
2010/07/10追記:
ライブドアディレクターブログに同じことが書いてありました。 プロジェクトメンバーが幸せになれるワイヤーフレームの作り方
最近「ワイヤーフレームをマークアップしちゃおう」といった動きが活発のようです。僕も受託でウェブサイトを制作していたときは、ワイヤーフレームは全ページコーディングしていました。
第2回ワイヤーフレームコミュニケーション研究会@東京終了しました – ワイヤーフレームコミュニケーション研究会
マークアップで表現する大きな理由は「ウェブサイトのワイヤーはウェブ (ブラウザ) で確認できるべき」というところにあると思います。たしかに PDF や PowerPoint で「ここをクリックしたら次のページへ (次のスライドへ)」みたいな記法よりは断然分かりやすいですよね。
それ以外にも、
環境 (OS・ブラウザ) を選ばない
ローカルに落とせばオフラインでも見られる
HTML なので変更・修正も容易
A タグで実際のページ遷移をブラウザ上で体験させることができる
といったメリットも享受できるからではないでしょうか。
うんうん。まったくその通りだと思うよ。下記はド先端にいるプログラマーの仕事のやり方ですが、業界末端のウエブ開発でも根本は変わらんと思います。
ITアントレプレナーになりたい若者のみなさんはプログラミングを習得しましょう － 渡辺千賀 テクノロジー・ベンチャー・シリコンバレーの暮らし
最先端のウェブサービス開発の現場は、とてもアウトソースなんかできない状況になっている。「仕様書を文章で作って、それを誰かが作る」なんていう悠長なやり方は通用しない。（中略）「人の話を聞いてさっさと理解して、それをすぐにコードにできる、いま・ここにいる人」というのが非常に重要なのです。
私のとっておきのプログラミングスタイル － Life is beautiful
十週間のプロジェクトであれば、最初の二週間が勝負。そこで八割がたのめどをつけておき、後は流す。最初の二週間がめどが立てられなければ、十週間で完成 できる可能性は低いと考える。常にそういう姿勢でいれば、締め切りぎりぎりになって致命的な欠陥が見つかって痛いめにあったり、本当は大幅な設計変更をす べきなのに応急処置ですます、などの可能性が減らせる。