画面仕様書を「作らない」リスク

　IT Pro の開発ドキュメントの最適化で笑わせていただいた。これ書いた人は画面仕様で酷い目に遭ったことがないんだろう。笑った箇所は次の通り。

画面仕様書をプロトタイプ・アプリケーションで代用する方法がある。Webシステムの場合は，HTMLの作り方を工夫すればプロトタイプで実際の入力手順や画面遷移も確認できるようになる。エンドユーザーにとっても，ドキュメントよりは実際の画面で確認した方が分かりやすいので，手戻りが減る。これは帳票にも同じことが言える。

　あのな、HTMLで作る画面なんざ、紙芝居だよ。「ふいんき」をかもし出すだけで、そいつは「仕様」じゃねぇ！ボタン配置や文字色を目の前で変えられるものだから、いつまでたっても顧客は「ちょっとコレ直して」と言ってくるんだよ。気軽に直せるものとお金を頂戴しないと直せないものがあることをギッチリと顧客に理解していただくために、画面仕様書はどうしても必要。

　コレ書いた人は、画面仕様書を前に顧客と丁々発止したことがないから、そんなコト言える。あるいは light weight なやつしか作ったことがないからだろう。以下3つの観点から、画面仕様書を「作らない」リスクを書く。

　　　1. 画面とチェック仕様
　　　2. 画面と業務プロセス
　　　3. 画面とデータベーステーブル

* * *

1.画面とチェック仕様

　画面とチェックはコインの表裏であり、切り離せない関係だ。紙芝居だけをいじっているとこの本質を見失う。

　チェックとは「その画面の中でどんなチェックをするか?」だ。桁・属性なのか、データベースまで見に行くのか、チェックそのものを監視していて、その結果をどっかのフラグに反映するのか、チェック結果の如何で何かができあがるのか、チェックが「OK/NG/ぬるぽ」だった場合は…を複数のチェックの組み合わせの中で決める必要がある。

　まともなSE/PGなら、「想定されうる組み合わせ」を予め洗い出し、チェックのための部品やスキームを準備しておくんだが、それらを土壇場でひっくり返してトンデモチェックを要求するぐらいが普通の顧客だ。

(゜∇゜)　A画面で入れた内容を元に、B画面でチェックしてくんない?

　　（ﾟДﾟ;)　あの～　A画面の「前」にB画面を呼ばれたらどうなるんですか?

(゜∇゜)　そりゃ、自動的にA画面で入れる内容を作り出してよ

　　（ﾟДﾟ;)　あの～　その後でA画面で入れた内容が違ったら?

(゜∇゜)　そりゃ、当然チェックするだろ

　　（ﾟДﾟ;)　あの～　そのチェックは、B画面で入れたのが原因だったら?

(゜∇゜)　そりゃ、当然チェックするだろ、B画面のチェックもAでやってよ

　画面ごとにオブジェクトを生成してそいつにデータとチェックをやらせるスキームは、これで潰える。ごり押しすると「チェックのたびに無数のオブジェクトがわらわらと生成・消滅を繰り返しリソースに多大なダメージを与えるトンデモ画面」ができあがる。やめなはれ。

* * *

2.画面と業務プロセス

　顧客が画面をちょこちょこ直したがる最大の理由は、業務プロセスが明確になっていないため。つまり、「その画面で何をしたいのか？」が明確になっていないからなんだ。

　色やボタンの配置は話のキッカケにすぎない。話の背後に控えているのは業務プロセスを「画面」「画面遷移」という見える形にすること。それをホイホイ真に受けて直すと、業務プロセスの定義があいまいなまま、あいまいに画面を修正していることになる。要求は明確なクセにいつまでたっても決まらない最大の原因はこれ。

　これは不幸だ。SE/PGが顧客の要望に応えようと親身になって直せば直すほど、取り返しのつかないあいまいな画面の修正作業に追われることになる。

　何をしたいのか分からない顧客は、スケジュールに追い詰められると、「盛りだくさん全部入りつゆだく画面」、すなわち何でもできる画面を要求しだす。「だって今までさんざん直してきたんだから、まとめるぐらい簡単でしょ?」と言い放つ悲劇に全米が泣くだろう。

　「画面仕様書を作る」ということは、「その画面で何をしたいのか」を業務プロセスの手順までに落とし込む作業。「画面のイメージを作りましたので、ちょっと見ていただけますか」と渡すことで、顧客はその「紙」や「ホワイトボード」を前にして初めて「ここでやりたいこと」を考え始める。てか、そこまでしないと考えてくれない。

* * *

3.画面とデータベーステーブル

　画面とデータベーステーブルの密接な関係は、断るまでもないだろう。もちろん「どんな画面でもドンとこい」「どんなテーブル構成でも大丈夫」なように別々に作ることも可能だ。しかしその際のリスクはパフォーマンスだろう。

　顧客の言いなりになって気軽に気軽にスクラップ＆ビルドを繰り返した結果、後半でチューニングに追いまくられる事態になる。当然、テストでたたき出したバグ改修とは「別作業」だ。

　DB屋の言い分は「アプリ屋は簡単に言ってくれるけれど、後になって“パフォーマンスが悪い”だの“データベースが遅い”だの文句を言ってくる。テーブル構成やトランザクションを無視して画面を修正するからじゃねーか（怒）」

　ちうわけで、ホイホイ直せるものと直すには銭を頂戴するものとを明確にギッチリと「顧客」と「アプリ屋」に理解していただくために、どうしても画面仕様書は必要。

* * *

　じゃぁ全部キチンと作ってメンテせぇ、というわけではない。「何のための画面仕様か?」と考えると、かなり減らせる。例えば、「画面の種類ごとに画面仕様書を作る」やり方。

• プロパティ画面
  
• 管理者向け（ユーザや業務プロセスを管理）
  
• 帳票やファイル化など、メディア出力のための画面
  
• 共通業務画面
  
• ○○業務画面
  
• △△業務画面
  
• …
  

　作るモノにもよるが、早い段階で画面の「種類」が割り出せるはずだ。言い換えると、「別のクラスにしたくなる/別のテーブルにしたくなる/別のトランザクションにしたくなる」のが「種類」。でもってその種類毎に画面仕様書はキッチリと書く。

　何度も出てくる共通的なアイテム、グループは.「○○画面の△と同じ」という表現で省略する。当然執筆もレビューも参照元の画面を見て一貫性が保たれていることをチェックすること。

　このやり方だけでも1/4から1/5まで減らせるだろう。

　あ、言い忘れていたけれど、数十画面にも満たないシステムにはこのやり方は重たいかも。小さいやつならプロト作ったほうが早いことは事実。このやり方は、数百画面、もしくは動的に組み合わされて生成する画面（組み合わせ次第では数千）にはとてつもなく有効だと断っておく。