|
いままでの苦労の集大成を迎える時が来ました。最終テストです。しかし発注者と開発者の関係が最も悪化して確執を生むフェイズでもあります。この段階まで来てから物別れに終わり，開発費支払いについて裁判になったという事例も知っています。何がトラブルの原因なのか，うまく案件を完了するにはどうしたらいいのか，どこかで道を外してしまった実際の例も見ながらお話ししていきます。
テストには大きく三つの切り口がある
「稼働テストの準備ができました」-- 文言やデータで大変な苦労をしていただいてから数日後に，営業からこういったテスト準備の連絡が入ります。作成していたサイトがほぼ完成し，いよいよ実際に触れることになりました。発注者であるあなたは，この仮納品されたサイトを検証しなくてはなりません。工業製品などと違って，サイトというものは，今が製造過程のどのステータスに位置しているのかがわかりにくいものです。最終テストの直前というのは仮納品状態であって完全納品ではありません。誤ってここで受領のハンコをついたりすると大変なことになります。慎重にテストをして，結果に納得できるまでは受領意志を見せてはいけません。
さてテストです。テストにはいくつかの切り口があります。切り口は以下のようなものになります。
・デザインの確認
・HTMLレベルの確認
・システムの動作確認
「デザインの確認」は一番わかりやすいものです。
○色味は問題ないか
○指定した画像が正しくセットされているか
○フォントサイズはいいか
○極端なレイアウトの崩れはないか
「どこそこのページで表示されている水平線の長さが5mmくらい短い」「メニューの背景の赤はもう少し地味にしたい」などの要望はこの段階でつけてください。デザイナが対応します。メニューなどのすべてのページにかかわるものは，全ページを修正する必要があるため，即時修正というわけにはいかないことが多々あります。
実はこの段階でごっそりとサイト・デザインを変更するという要望が出る場合もあります。デザインについては開発途中にいったん素案が提示されることがほとんどです。素案から大きく逸脱した変更は開発側に大きな負担になります。最終テストからオープンまでに時間がない場合にはデザイナは休日返上の徹夜続きとなってきます。
およそ最後の最後に大きく変えたいという話が出るときは，とてもエライ人たちの要望だったりします。「社長がどうしてもここがいやだと言っていて…」みたいな話です。理屈としてはわかりますが，デザイン素案の段階で上位管理職にも必ず確認を取るようにしてください。最終段階からの大改変は両者の関係を思い切り悪化させます。今後のメンテナンスで開発／デザインとの付き合いは続きますので，あまり無茶を言い過ぎて関係を悪化させるのは得策ではありません。
「ここはもう少しこれこれでもよかったな」という社長発言が"要望"とされていたケースがあります。「これこれでないと納得できないし受領できない」とは少しニュアンスが違います。上司の意見を尊重するのはわかりますが，ビジネスで納期というものが存在する以上はほどほどにしないといけません。上司に対してでも「先に了承していただいた素案の通りですし，今からの全体改変は時間的に無理です」と説明する勇気も持ってください。
「HTMLレベルの確認」はデザインと似ていますが，もう少し機能部分についてのチェックです。
○各ページ，メニューの文言は正しいか
○リンクをクリックしたときの移動先は正しいか
○トップに戻れないなどの不都合はないか
デザイン関係と比べると，発注者は本当にテストしたんだろうかと開発側を不安にさせるのがこの項目です。何かのミスでリンクが切れていたことにデザイナが気がついても，発注者からは何も言われないといったことが多々あります(当然こっそりと直されます)。つまり文言の確認もされていないであろうと簡単に想像できます。
デザインに気持ちが行ってしまうのはわかりますが，実際のユーザーの立場になって，各ページを隅から隅までよく"読んで"ください。そのうえでユーザーならばここをこうクリックして情報を知りたいだろうというリンクが適切に配置されているか，ちゃんとリンクで飛べるかを確認する必要があります。文言やリンクの追加，修正はデザイン修正と比べれば作業時間は短く，即時対応もできます。
以上2点については，携帯サイトも併設しているような場合には，携帯電話からの確認も必要です。
それは仕様なのか追加要望なのか
やっかいなのが，「システムの動作確認」です。システムには2種類がありましたね。管理側とユーザー側です。例えば不動産サイトであれば，物件を登録したり修正するのが管理側，検索したり申し込むのがユーザー側です。管理側はユーザーには見えない位置に置かれています。一方ユーザー側は実際に閲覧者が操作する画面を指し，サイトを見た人ならば誰でもが操作できます。管理側とユーザー側は混同することなく，個別にテストする必要があります。重要度で言えば，管理側よりもはるかにユーザー側のウエイトが高いです。管理側は社内の一部，ひょっとしたら担当者一人だけが使うものです。多少操作性にクセがあっても大きな問題にはなりません。一方ユーザー側については，サイトの規模によりけりですが何百～何十万の人が操作する可能性があります。
大事な話の前に，ちょっと蛇足的なお話をしておきましょう。管理画面のデザインについてです。管理画面のデザインはユーザー側を表としたときの裏にあたります。多くの案件であまり管理側のデザインに凝っているというケースはありません。かなりシンプルなものが多いです。機能最優先であり，見る人は限られていますので，管理側のデザインについては，あまり高度な要望や細かい希望は出さないほうが開発の心象はよくなります。要望に対する対応は，たくさんの要望の中で作業優先度が設けられますが，管理側デザインの処理優先度はおそらく最低扱いになります。もちろん機能については別物です。管理機能に対する要望の優先度は相当高く設定されると思います。
さて，テストの前に絶対に手元に用意していただきたいものがあります。仕様書です。プログラマは仕様書に沿ってシステムを作成します。すべての動作の実装，試験基準は仕様書です。もし仕様書と別に要件定義書があれば，それも用意してください。記述の便宜上，以降は要件定義書や取扱説明書も含めて「仕様書」と記述します。
テスト，テストというと難しく聞こえますが，すべての動作について，仕様書のとおりになっているかどうかを確認するのがテストです。仕様書が手元に一部しかない場合には，コピーをとるなどして自由にメモが取れるものを用意します。画面と仕様書を見比べつつ，もし動作が違っている部分があれば赤ペンなどでメモします。
テストの段階ですでにいくつかの本番環境に近いデータが入っている場合，まずユーザー側からテストしてください。不動産サイトやECサイトのような形態では，指定した条件で正しく検索できるのか，検索結果が0件のときの画面の文言や誘導リンクは正しく機能するかといったところがポイントになります。何も条件を指定しなかった場合にどうなるかといったことも見ておいてください。見慣れない英語のエラーなどが出る場合には要注意です。英語のエラー・メッセージの多くは，見苦しいという問題ももちろんですが，本来部外者に知られたくない情報を含んでいる場合があります。
管理側のテストは，実際に入れるであろうデータでの確認がベースになります。「テストお願いします」といわれて，面倒だから商品名に"aaaaa"，価格は100で一つ二つ入力してみたということではテストにはなりません。運用していくと実際に入力するであろうデータを入れていくということが大切です。入力した結果が正しくユーザー側に反映されていくのかも確認します。もし運用開始後に管理側のオペレータとなる人がいるのであれば，必ずその人もテストに参加してください。多くのシステムでは管理側はユーザー側と比べて"緩め"にシステムが作られています。入力者を限定できるので，ありえないようなデータは入力されないはず，というスタンスがあります。ユーザー側についてはPCに不慣れな人，悪意のある人もいるため，相応にガチガチで"堅め"に作りこまれます。
テストの際，特にユーザー側では面倒ですが，ありとあらゆる条件を指定するということが大切です。ある条件の組み合わせではなぜか結果が正しく出ないということもあります。文字を入力するタイプのシステムではアルファベットや半角カナでの入力もチェックします。この際，仕様書に「半角カナでの入力は不可」のように書かれていれば，その結果が正しくないのは"不具合"ではなく"仕様"になります。仕様書を手元に置いて確認しましょうというのは，ここにかかってきます。
自分としてはおかしいと思うが，仕様書にそう書かれているという場合，疑問点を改修する作業は"修正"ではなく"追加要望"になります。「トマト」を半角カナやひらがなで検索しても「トマト」が出てきてほしい，というのは，完全一致でないと検索できないという仕様であれば修正要望のリストには載せられません。機能追加になります。機能追加ということは，また見積もりを取って作業料金が発生します。
「検索にちょっと手を加えるくらいは簡単だろ」というのは実は大きな誤解で，既存システムの内容によっては数日を要する大改変になることもあります。改修の作業をするプログラマもいい大人ですので，1日稼働して5000円ということはありません。5日稼働しないと実装できない内容を作業すれば，10万円～20万円という稼働経費が発生します。追加機能の実装となれば，それだけの追加料金が必要になるというわけです。一方仕様書に沿っていない問題点は当初の契約料金に含まれている義務を果たしていないということになりますから，これで追加料金が発生することはありえません。
たいていの案件は，この境目があいまいです。仕様書そのものが未完成なままテストに突入してしまう案件もままあります。開発途中にメールや電話で要望したことが仕様書に反映されていない，つまり開発者に届いていないということもよくあります。仕様書が固定できない案件は決していい案件とはいいません。真ん中に置いてすべての基準点となりえるものがない状況だと，どうしても言った言わないが始まります。テストの段階で発注者と開発の関係が悪化するというのは，これを作るんだという最終設計書であるはずの仕様書がしっかりしていない場合に，本当に多々あることです。
仕様書を固定するという作業は，発注側の折衝担当(つまりあなた)と受注側の営業担当にかかっています。電話やメールで要望を出したら「仕様書に反映して関係者にメールしてください」と必ずひとこと添えてください。特に電話という手段は大変危険です。必ず文書(ファイルも含む)の形で残して，関係者全員に届くように段取りをつけることが大切です。なお発注側の全員ということだけでなく，受注側についても必ず回覧して了承を取ってください。
発注側の連絡が行き渡っていないと次のようなことが起こります。
受注営業「あれ，でもBさんに赤でいいといわれましたよ」
発注関係者A「それはBの個人的な意見だから」
青に変更。後日。
発注関係者B「先日赤でという話しましたけど」
受注営業「でもAさんに青に変えろと…」
問題はこの会話に出てきていないところで，デザイナも働いているということです。赤にしろ，青にしろといわれて「はいはい」とニコニコしながら修正していると思ったら大間違いだというわけです。
当然こう言い出します。折衝窓口を一本化しないと，実質作業者であるデザイナやプログラマはどんどんモチベーションを下げていきます。他人事として見れば，誰でもそんなおかしな話はないよねと思うんです。ところが自分が当事者になると，なぜか結構な頻度でよく起こることなんですね。これが建物の外装工事だとしたら，一度塗り終われば無茶は言われないんでしょう。ところがWebの世界では，どこかに「色を変えるくらい簡単だろ」という風潮があります。簡単かどうかが問題ではなく，何を作るべきかという基準のあいまいさが問題です。
