« マネジメントとは何かgoogle先生に訊いてみた | トップページ | 育児とはつまり○○と○○ »

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

 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まで減らせるだろう。

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

|

« マネジメントとは何かgoogle先生に訊いてみた | トップページ | 育児とはつまり○○と○○ »

コメント

なんか、画面仕様書に過度な期待をしてしまっているような気がする。
画面仕様書をつくるだけでそんなに幸せになれるかな。
だって画面仕様書だぜ~。
仕様書とは、お客にシステムがどんなものかをわからせるためのものだから、それが紙であってもHTMLであっても表現方法はかまわないと思う。
もし、画面仕様書には、HTMLでは記述できない内容があるというのなら、それはもはや画面仕様書ではないのでは?そしてそれは違う仕様書で記述されるべき内容のものでしょう。

最後に「雰囲気」は「ふんいき」です。

通りすがりで書き散らしてしまってすみません。

投稿: 通りすがり | 2006.05.24 17:15

> 通りすがり さん

 ご意見ありがとうございます。画面仕様書を「作らない」リスクは、あなたが想像するよりも大きいですよ、というのがこのエントリの趣旨なので、このご意見から察するに、うまく伝わっていないのかも。

 通りすがりさんは、顧客との丁々発止の経験が「ある」という前提で補足しますと、「画面仕様書」には、機能仕様、チェック仕様、エラー・例外・メッセージ仕様といった業務仕様(HTMLで書ききれない仕様)が滲み出るものですよね。だからキレイに画面仕様というカテゴリーでまとまるはずもなく、紙(またはホワイトボード)に動きやつくりを書き散らして落とし込みをはかるのが、丁々発止の現場ですよね。

 最後に。「ふいんき」の誤用は承知の上でそう表現しています。そのココロは「雰囲気すら伝えきれていない場合がある」です。わざわざカッコ書きで記述しているのが証左。

 くくった書き方をしてしまってごめんなさい。通りすがりさんがもう一度通りすがることがないかもしれないので。

投稿: Dain | 2006.05.24 23:41

コメントを書く



(ウェブ上には掲載しません)




トラックバック


この記事へのトラックバック一覧です: 画面仕様書を「作らない」リスク:

» 画面仕様書が必要なときも、不要なときもある [なんとなくblog]
画面仕様書を「作らない」リスクは、ここで書かれているようなことは起こりえるし、同意もする受託開発では、ユーザー部門と打ち合わせする際に、画面仕様書を使い打ち合わせするときもある 仮に相手がシステム部門(管理者)であれば、HTMLやVBなどのサンプルを提出すれば、追加項目を置いてほしいところを更新してく要望を出してくれることもあるだろう。しかし、相手がユーザー部門(使用者)であれば、そうはいかない。結局、キャプチャした画像に追加項目を記載し、要望を出しててくる。 では、画面仕様書が省略できないかという... [続きを読む]

受信: 2005.12.13 00:02

« マネジメントとは何かgoogle先生に訊いてみた | トップページ | 育児とはつまり○○と○○ »