今回は，プログラマには耳の痛い話になるかもしれない。プログラマの言う「実装不可能」の，どこまでがホンネかをあぶり出すつもりだ。プログラマの発言の主旨を見抜くには，デザイナーも，プログラミングという作業について知らなければならない。
デザイナーが知らない，Webプログラミングの三つの本質
まずは，筆者が考えるWebプログラミングの三つの本質を揚げてみよう。
(1) Webプログラミングとは，渡された値を制御する技術なり
第6回目で書いたように，一つの機能の裏には，複数の処理（複数のフォーム，複数のプログラム・ファイル）が隠れている。例えば，商品のWeb見積のページを思い浮かべてほしい。最初にアクセスしたフォームで「品番がABCDEというノートパソコン」を選択したら，次のフォームには「品番がABCDEというノートパソコン」という値が渡される。そして，選択したパソコンの仕様が表示され，見積金額を試算することができる。
「渡す」とは，ページをまたいで「データを引き継ぐ」ことだと思えばよい。Webアプリケーションでは，複数のフォーム間でデータを渡しながら処理していくことが多い。そのため，データを渡す側のページに仕様変更が生じれば，データを受け取る側のページにも影響が及ぶ。
渡す値は，ユーザーの入力した文字情報や選択した値，カレンダーの日付のような，わかりやすいものばかりとは限らない。ユーザーがクリックした表のレコードのインデックス番号や，ツリー表示のXMLの階層の深さや要素の順番を表すインデックス番号を，いくつものフォームを経由しながら再利用する。フォームとフォームの間を，整数値が行き来しているわけである。複雑なアプリケーションになると，どのタイミングでどんな値を渡して，どの変数に格納しているかは，プログラムを書いた当人でも覚えられないほどだ。
プログラマが，「一個所だけ変えてほしいと言われても，他のプログラムも見直すようになるんだけれど…」と変更を渋る場合は，ちょっとした仕様変更が，関連するすべての処理に波及するので，変更に予想以上の時間がかかりそうだ，ということを言いたいのである。
ただしプログラマは，ことビジュアル・デザイン絡みの変更については「見た目なんぞ，どうでもいいじゃないか」という考えから，実装を渋っている場合がある。だから，デザイナーは，変更の及ぶ範囲と所要時間＊1を見極めて，納得するのか説得するのかを決める必要がある。
(2) Webプログラミングとは，分岐処理とエラー処理なり
プログラムは，「もし○○であれば」と「それ以外の場合は」という分岐処理の積み重ねである。分岐処理は，Webサイトのリンクのように，蜘蛛の巣状に広がり，振り出しに戻ることもある。ユーザー・インタフェースが過度に複雑であると，プログラムは絡まった糸のようになる。例えば図1のような，単に「分類」を選択して筆者名を検索キーとして記事情報を得るという，非常に簡単な検索処理であっても，それ相応の分岐処理が必要になる。
【図1】ユーザーのアクションによって分岐する処理の例（記事情報の検索）[クリックすると，さらに詳細な工程の別ウィンドウが立ち上がります] |
また，アプリケーションの全容を知らないユーザーは，手順通りに操作するとは限らない。入力作業を中断したり，入力途中で[登録]ボタンをクリックする。半角で入力すべきところを全角で入力したり，入力し忘れる。Web上の[戻る]ボタンは使わずに，ブラウザの[戻る]ボタンを使う。意表をつくような操作をすることもある。
ユーザーの操作を予測して分岐処理を書き，入力されたデータの検証やエラー処理をほどこすことが，バグを防ぐのである。それには，練られた設計だけでなく，プログラマの経験やノウハウも必要だ。
デザイナーには，「もし○○であれば」という条件に対してのみ処理を書けばよいと思っている人が多いが，「それ以外の場合」の処理が重要なのである。ベテラン・プログラマになると，どのようなケースが「それ以外の場合」に該当するかを網羅して，バグをつぶす。
所定の操作で正常に動作するプログラムを書くことができても，エラー処理をサクサク書けなければ，プロのプログラマとはいえない。Webプログラミングのポイントは，「エラー処理」にあると言っても過言ではない。
プレゼンテーションの際に，プロトタイプが動作しているのを見て，「すでにプログラムの7～8割はできている」と誤解するデザイナーもいるが，実開発に利用できるコードは，2割あればいいほうだ。
(3) Webプログラミングは，サーバーに配置するまで成否のわからぬものなり
プログラマは，1個の処理を書き終わる度にデバッグを行い，動作を確認しながら作業を進めていく。プログラムが一通り完成したら，実データを使ってローカルマシンの開発ツール上で最終確認を行う。次に，ドライブ構成や開発ツールのエディションが異なるマシンに配置して再確認を行う。問題なく動作すれば，Webサーバーに配置する。すると，この段階でエラーが生じる。通常，開発環境とWebサーバーの環境は，異なるからである。よくある話だ。
Webサーバーの設定を変更すれば解決する問題ではあるが，「アプリケーションエラー」という文字は，できるだけ見たくない。そこで，筆者の参加するプロジェクトでは，公開用と同じプラットフォームに整備したWebサーバーを一時的に立てている。ロボット避けを置いて速やかにテストを行い，動作確認が終了したら，速やかにプログラムを削除する。
プログラマの相方の弁を借りれば，「プログラマは無意識のうちに，不具合を避けるように，動作確認をしてしまう」ものらしい。決められた手順通りの操作をしがちになる。しかし，バグは通常決められた手順以外の操作によって発生する。ブラウザでの表示は，閲覧側の環境にも左右される。そこで，メンバー全員がテストに参加することになる。
ベテランのプログラマであっても，公開用サーバーに配置し終わるまでは気が抜けない。プロジェクト・リーダーから「納品完了！」のメールが届いて初めて，一息つけるのである。
