デザイナー主導型プロジェクトに適した見積もり方法
プログラマとデザイナーの協力体制が敷かれているプロジェクトであっても，いざ実作業となると，次から次へと問題が発生する。
ヒアリングを行い，顧客の要求を洗い出す。顧客が希望する機能と，開発サイドから提案する機能をリストアップし，優先順位を付けて実装する機能を絞り込む。この段階で，ユーザーの閲覧環境（OSとブラウザ，解像度，回線速度，携帯端末の場合は対応するメーカーと機種），サーバーOS，プラットフォームといった前提条件も固まり，予算の大枠も明らかになってくる。予算の都合上，希望が一度に叶えられない場合は，機能をシェイプするか，順次追加する方向で検討する。要求仕様をまとめ，企画書と画面遷移図を起こす。顧客の了解を得られたら，概算見積書を作成する。
筆者がWebサイトの制作を手がけ始めたころは，見積もり方法も手探り状態だったので，作業積算方式を採用した。企画やデザイン，素材制作の費用は，当時印刷物の見積もりに使っていた「JAGDA制作料金算定基準1990年第1回改訂版」（JAGDAは，社団法人日本グラフィックデザイナー協会）に従った。デザイン会社が受注する場合は，印刷物と連動させるためにカラーカンプからWebページのラフデザインを起こしたり，商品撮影でカメラマンに動いてもらうことがあるからだ。
そのうえで，HTML，CSS，スクリプトの1ファイルあたりの単価を決め，画面遷移図から，最終的に必要なファイル数を割り出す。単価とファイル数を乗算して，コーディング費用を算出して，加算する。この方法なら，作業の増減によって，細かく見積もり金額を変えることができる。デザイナー主導型プロジェクトに適した見積もり方法といえるだろう。
一方，技術者主導型，いわゆるシステム・ハウスでは，作業積算ではなく人件費計算で見積書を作成する場合が多い。プログラマの人件費が月いくら，システム・エンジニアがいくら，工期がおおよそ何カ月，だから全体の金額はこのくらい，という方法である（もちろん，FP法など厳密な見積もりを実施しているところも少なくない）。
【表1】人月計算と作業積算方式の見積方法の例
|
システム・ハウスの経営者からこの計算方法を聞いたときには，なんて大ざっぱな！と驚いたものだ。それは技術者主導でシステム・エンジニアがリーダーを務める場合にのみ有効な方法ではないだろうか。なぜなら，デザイナーがリーダーの場合，人月計算の見積書を提出すると，仕様の膨張を防ぐのは容易ではないからだ。
デザイン会社と，開発案件を打診する顧客の間には，長い歴史のあることが少なくない。顧客側には，広告宣伝媒体の制作で内情を熟知しているデザイン会社なら，顧客の身の丈に合った，運用可能な形に仕上げてくれるはずだという安心感がある。
例えば，会員登録のページで，項目数が異常に多い入力フォームを準備して，エンドユーザーの詳細なデータを取得したとしても，それを活用するスキルがなかったり，気配りのあるサービスを展開できないのなら意味がない。ユーザーに入力の手間をかけさせることで，逆に会員希望者を失ってしまったら本末転倒である。
また，膨大なデータベースを瞬時に検索できるような処理に多額の予算を投じても，顧客が日常業務に忙殺されてデータの準備が進まないなら，初回立ち上げ時から，それだけの予算を使う必要はないわけだ。
スタッフの働きぶりなど，付き合いの長いデザイン会社でなければわからないことは多い。どんな顧客も，新規参入のシステム・ハウスには，つきなみな面しか見せないものだ。しかしながら，デザイン会社ご指名ではなく，システム・ハウスが見積もり参加した場合は少々事情が異なってくる。視覚に訴える術を知っているデザイン会社は，プレゼンテーションでは圧倒的に有利なので，受注を勝ち取ったとしよう。ところが，システム・ハウスからプレゼン時にありとあらゆる機能を提案された顧客は，実作業着手後に，「この機能もあったほうがいい，あの機能も普通は付いているはずではないか」と，思い出し始める。
そうなると，見積もり承認時の「予算はこれだけしかない。その範囲内で出来ることを」という約束はどこへやら，である。
見積もりにも企画にも合意が得られたうえで，実開発に着手したにもかかわらず，仕様の追加や変更希望が相次ぐようになる。それがビジュアル面の希望なら，もちろんデザイナーは理由を説明して追加予算を請求することができる。
しかし，その希望が，ビジュアルの問題ではなく，データベースやプログラムにかかわることであれば，人月計算での見積書を提出していた場合，デザイナーにとって追加予算の請求と説明は難しい。納期までに何とか作業を詰めて予算内でできないか，と詰め寄られると，返す言葉が見つからなくなる。
その点，作業積算方式で見積もっておけば，追加する機能を実装するために何個のプログラム・ファイルが必要になるかを割り出して，概算見積書の同様のプログラムの単価を提示することにより，予算を盾に，顧客を説得しやすいという利点がある。
たしかに，作業積算方式は，画面遷移がある程度固まらなければ見積書を作成できず，その作成自体にも結構な時間がかかるという欠点はあるものの，予算の上限を設定された上で作業が増えることのないよう，安全弁の役割を果たしてくれる。
仕様の膨張に，歯止めをかけろ
ところが，顧客が，根本的に「企画」というものを理解していないがために，機能の追加や変更を要求し始め，かつ，追加予算を準備できるとなると，作業積算方式の見積書も防御の役割を果たさない。その場合の対応は，非常に難しい。
筆者の経験では，万人にとってベストなものは存在しない，ということをわかっていない困った顧客が，20％ほどいるようだ。
ユーザー層を絞り込んでWebアプリケーションの運用効果を引き出すために，画面遷移とともに承認を得たはずの企画書の中では，訴求対象が特定されている。だが，ユーザー層の絞込みに対して，隠れた抵抗感を持っていながら，企画書を素通りさせているのだ。
例えば，ファミリー・レストランは万人にとってベターかもしれないが，万人にとってのベストではない。関東のうどんは，関東人にとってはベターかもしれないが，四国の人間にとってもってのほかの味である。
同様に，Webアプリケーションでもユーザー層を設定したうえで，機能とインタフェースを練る必要がある。「誰にでも愛され，使われるWeb」という言葉は聞こえが良いが，人は遺伝子も生育環境も価値観もセンスも異なるのである。万人に同等の効果のあるアプリケーションを開発することはできない。
万人幻想に捉われている顧客は，実開発でアルファ版ができようものなら，友人知人，取引先に見せて感想を求める。その結果，「こんな機能が必要だと言われた」「あんな機能があったら便利ではないかと提案された」と要求し始める。そして，ただ一人のレアな感想を取り上げ，「この機能がなければ開発の意味がない」とまで思いつめてしまう。
こうなると，「仕様膨張」という悲劇が待ち受けている。
プロジェクトのリーダーは，受注した限りは，顧客の想いを叶えなければという気持ちになる。顧客との付き合いが長ければ長いほど，また併行して動いている印刷媒体や映像の仕事があれば，そういう気持ちになることは，やむをえないだろう。
しかし，ちょっとデザインの仕事，例えば商品カタログの仕事に置き換えて考えてみてほしい。顧客が取引先にカラーカンプを見せた。いろいろな感想が返ってくる。「空から見た写真があると，凄そうだけどね」「過去の商品の写真もすべて載せてしまえば」「（ダミーで貼り付けているイメージフォトの）モデルが，タイプじゃないなあ。」そのために，航空撮影や大量の商品撮影，モデルを手配する話に膨れ上がってしまう。
すでに制作は進行しているが，顧客は，セスナを飛ばし，カメラマンを拘束し，モデルを手配するために追加予算を出すので，デザインを変更してほしいと言う。「ページ数も増えますし，コンセプトから練り直しましょう」と進言したときに，「できあがっているデザインに，それらのページを付け足せばいいだけじゃないか」と言われたら，「はい，わかりました，おっしゃる通りにいたしましょう」と即答できるだろうか——。そのまま進めたら，コンセプトのあいまいな仕上がりになり，効果が出なければデザイン会社の責任が問われてしまう。
そのような要求に抵抗感を示すアート・ディレクターやデザイナーは「能力不足」だろうか——。
プロジェクトのリーダーが全員，技術に歩み寄る姿勢を持った人ばかりだとは限らない。「顧客の希望を実現できないのなら，それはプログラマの能力不足」と決め付けるようなリーダーも，少なからずいる。
そういうリーダーは，プログラムには材料費や印刷代といった費用が発生しないので，少しの機能追加程度なら作業の速い人に任せれば納期に間に合う，と考えるようだ。高い技術を持つベテランをプロジェクトに迎えれば作業時間を短縮できる，と思ってしまう。ところが，ベテランを使って工期を短縮するという行為は，作業時間がかかる新人のほうが高い予算を獲得できるという矛盾を招く。技術への無理解から，価格破壊を招いてはならない。
では，プログラマの頭数を揃えて分担すればよいのではないか，と考えるリーダーもいる。ところが，デザインでも，アパレルとグラフィックとインダストリアルが異なるように，また同じ紙媒体でも，パッケージが得意な者とポスターが得意な者がいるように，プログラマにも専門というものがある。Javaの得意なプログラマが.NETの経験が豊富であるとは限らないし，C言語のスペシャリストだからといって，Webアプリケーションに詳しいとは限らない。前提条件が決定し，プロジェクトが動き始めた後で，前提条件に合う複数のプログラマに声をかけて，スケジュールを調整してもらうことは極めて困難だ。
顧客の要求からプログラマを守れ
実は，数人分の仕事を一人でこなせるようなベテランのプログラマほど，仕様膨張に難色を示す。それがスパイラル開発であっても，だ。なぜなら，実開発着手後に，基本設計に含まれていない機能を何個も追加することが，ある種の危険性を招くと知っているからだ。
まず，アプリケーションの安定性に問題が生じかねない。1個の処理の中の，ささいな変更が，その処理に関連するコードの大幅な修正に発展することがある。また，他のWebフォームに影響が及ぶこともある。また，プログラマを必要以上に急かす行為は，バグの温床を築くことにつながる。
次に，メンテナンスに際して問題が生じる恐れがある。仕様変更が度重なり，コードがツギハギになってしまうと，納品した1～2年後，プラットフォームのバージョンアップに伴ってプログラムを見直す際に，問題が表面化することがある。プログラマ自身が，自分の書いたコードを見ても，どこに何の処理が書いてあるのか思い出せない。任意の処理で取得した値を渡した先の処理を探して，コードをたどり続ける。ましてや初回開発時に複数のプログラマで分担していると，既存のコードを利用するよりも，1から開発し直したほうが速い，などという状況に陥りかねない。
納期を設定されたうえに，品質の低下という危険を招くかもしれないほどの仕事を託されたのでは，プログラマが潰れてしまう。共に研さんしつつプロジェクトの成功を目指す仲間の立場を，デザイナーのリーダーは十分に理解しなければならない。
そして，コア・デザイナーには，板挟みになってでも，顧客の仕様変更希望からプログラマを守る，という覚悟が求められるだろう。
|
PROJECT KySS（プロジェクト・キッス） 薬師寺 国安（やくしじ くにやす，フリープログラマ）と，薬師寺 聖（やくしじ せい，個人事業所SeiSeinDesign自営，http://www.SeinDesign.net/）によるコラボレーション・ユニット。1996年，聖が勤務先で地域ポータルを企画制作，これを訪問した国安と知り合う。ActiveXユーザー同士で意気投合し，翌年「PROJECT KySS」結成。1999年よりXMLとDHTML利用のコンテンツ開発，2000年にはCMSツール開発と，一歩進んだ提案を行い続けている。XMLに関する記事や著書多数。両名ともMicrosoft MVP for Windows Server System - XML(Oct 2004-Sep 2005)。http://www.PROJECTKySS.NET/ |
