ここ数年，単独指名ではなく，コンペや入札によって発注先を決定する傾向が強まってきている。どのプロジェクトも，見積金額を抑えるのに必死である。動作の安定性，メンテナンスの容易さ，将来的な拡張性をいくらアピールしようとも，顧客側に技術知識が欠けていると，その声は届かない。品質が発注の際の評価の対象にならず，短納期低予算が叫ばれる。
バランスを欠いた短納期低予算が招く，品質低下
【図1】 デザイナー主導型プロジェクトでの開発スケジュールの一例（赤の部分が，顧客との交渉・詳細打合せと併行で行う，企画や設計の調整期間。 この間に，プログラマが実開発に先走ると，品質低下の恐れがある） [クリックすると，さらに詳細な工程の別ウィンドウが立ち上がります] |
予算と品質を天秤にかける傾向は，品質をないがしろにしかねない危険をはらんでいる。設計と実装の工期のバランスが崩れてしまうのだ。
いくら開発ツールがめざましい進化を遂げていても程度問題である。バランスを欠いた極端な短納期では，前段階やテストにしわ寄せが及ぶ。ヒアリングも企画も設計もそこそこに実装に着手しなければ，納期に間に合わない。
プロジェクト・リーダーは，工期について顧客と交渉して，データベースの項目や開発に使う実データなどについて仕様を詰めていく。しかし，そうしている間も1日2日と時間は過ぎていく。
やがてプログラマは不安になり，焦り始める。ついには，修正が必要な基本設計書を頼りに，実開発に着手してしまうケースは少なくない。
それでも，ベテランのプログラマならツボをおさえてコードを書くから，最終的にはツジツマの合う不具合のないアプリケーションに仕立てる。とはいえ，ユーザー・インタフェースにこだわったり，メンテナンスのしやすさといった点まで配慮する余裕はないから，正常に動作するだけという「ごく普通の」品質に落ち着いてしまう。
経験の浅いプログラマの場合は，エラーの発生を予測する経験値を持たないので，基本的な品質を保つだけで精一杯になる。ベンダーが提供したり，書籍やWeb上から得られるサンプルから，目的の処理と類似のプログラムを探して適当に組み合わせる。とりあえず動作するアプリケーションにはなるが，エラー処理が万全でなければ完成品とはいえない。バグのチェックにも時間がかかりかねない。
デザイナー主導型プロジェクトが携わるような，中規模以下のアプリケーションでは，金融，防衛，航空，医療，企業間商取引といった，経済や人命に直結する案件はほとんどない。しかし，それが前段階やテストをないがしろにしてよいことにはならない。
後追い仕様書から生まれる，新種の仕事
このような状況下では，実装が先走り，仕様書＊1のうち，基本設計書と詳細設計書の修正や作成作業が，プログラミングを追いかけるという事態になる。さらに顧客からの仕様変更希望が相次ぐと，仕様書に訂正を加えている間にも実装が進んでいく。デザイナーと開発者が異なる開発ツールを使っていると，後追い仕様書の作成自体が困難だ。
手順をさかのぼるなど，デザイナーには考えられないことである。カンプもラフデザインもできていない状態で，アート・ディレクターの意向を無視して，デザイナーやコピーライターやカメラマンが独断で動くことと等しいからだ。
「段取り8分」を忘れて，実装担当者が先走る―――そのようなプロジェクトの成果物には，最終仕様書の不在というリスクがつきまとう。
もっとも，リスクが考えられるところには，必ず新種の職業が生まれる。今後は，Webトレーサーとかストラクチャ・アドミニストレータとでも呼べばいいような職種が登場しそうな気がする。リバース・エンジニアリングという言葉をもじって，「リバース・エンジニア」と命名してもよいぐらいだ。
リバース・エンジニアは，後追いで仕様書を作成する専門家である。開発したアプリケーションを同じ担当者がサポートし続けるとは限らないから，システムの監視まで担うかもしれない。しかも高度な技術力が要求される。ありとあらゆるプラットフォームやデータベースに通じていなければならない。複数のデータベースとクライアント処理とサーバーサイド処理が入り乱れ，仕様書がないばかりか，コードにほとんどコメントが付いていないシステムの仕様書を作らねばならないこともあるだろう。
納期と予算を承諾して開発に着手した以上，納品後に不具合が生じたとしても，顧客に責任はない。デザイナー主導型プロジェクトが，前段階無視の案件を引き受けない方法はただひとつ。価格競争に参入せず，概算見積書提出時点で，工期と品質保証について顧客にはっきりと伝え，ビジュアル・デザインとアイデアという付加価値をアピールして，仕事を獲得することである。
プロジェクト全体で，先走りを防ごう
プログラマの焦りは，その前段階の設計担当者にも影響を及ぼす。早く，早くと急かされるあまり，練られていない設計図をプログラマに見せてしまうのだ。完成していない設計書でも，機能のアウトラインを読み取ることはできるから，プログラマは実装に先走る。このような状況の発生を防ぐために，プロジェクト全体で，気をつけておきたいポイントが二つある。これらを肝に銘じて，少なくとも自分たちのプロジェクトの中では，高い品質を維持しよう。
(1) 「ホンモノのアイデア」と，「単なる思い付き」の優先順位を考えずに，詳細設計を進めてはならない
ひとつの機能を実装するにも，複数の方法がある。その中には，採用すべき一つの「ホンモノのアイデア」と，多数の「単なる思い付き」がある。この「単なる思い付き」とは，コピーやカンプでいえば，「捨てゴマ」にあたるものだ。
ところが，この「単なる思い付き」のほうが，一見実装しやすく見える場合が多い。なぜなら，「ホンモノのアイデア」とは，過去に経験のない新しい方法であったり，改良された方法であって，実装には試行錯誤が必要とされるからだ。そのため，急かされる状況では，「ホンモノのアイデア」を捨ててしまいがちになる。
「ホンモノのアイデア」は，実装が難しくてもシンプルで，汎用的で，バージョンアップやメンテナンスが容易であるうえ，別の新しい案件を請けたとき，ノウハウが役に立ったり，部分的にコードを再利用できるといったメリットがある。品質を高めるために，どちらを採用すべきかは明白だろう。
(2) 処理の全体像を把握していない状態で，1行たりとも「実開発用の」プログラムを書いてはならない
アプリケーション全体の構造と処理をしっかりと把握しないまま，「実開発用の」プログラミングに着手してはならない（テスト用のサンプル・プログラムなら，かまわない）。
経験があって書きやすい処理や，理解しやすい処理から部分的にプログラムを書き始めてしまうと，一部は正常に動作しても，作業が進むにつれて統一感が失われていく。やがてクラス化したほうがよい処理を複数のフォームにダラダラ書いたり，データの整合性がとれないなどのほころびが目立ち始める。
プログラマは，正常に動作するコードをベースにして開発を続行したいと思うので，ほころびを場当たり的な処理で繕おうとする傾向がある。その結果，バグはなくても，見通しの悪いプログラムになってしまう。シンプルで美しいプログラムに仕上げるには，一度考えた処理でも，何十何百行書いたコードでも，「捨てる」英断が必要だ。
進歩した科学も使い方を誤れば悲惨な結果を招くのと同様，進歩した技術を取り扱う人間にも，モラルが問われる。末永く安定運用できる高品質のアプリケーションを開発できるのは，メンバー全員が自省と精進を心がけているプロジェクトである。そして，顧客側にも，作業量と工期と予算に関する意識改革が求められる。
| 【デザイナーのための技術用語解説】 |
| ＊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/ |
