« 2005年11月27日 - 2005年12月3日 | トップページ | 2005年12月18日 - 2005年12月24日 »

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

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

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

| | コメント (2) | トラックバック (1)

マネジメントとは何かgoogle先生に訊いてみた

結果(日本語)↓

management_ja.JPG

洋梨… 

洋ナシ… 

ようなし… 

用無しぃ?

(古ネタごめん)

ちなみに、結果(英語)↓

management_en.JPG

師匠は偉大なり。

| | コメント (2) | トラックバック (0)

最近の劇薬小説

 劇薬小説の企画は続いているが、「コレは!」というのが見当たらない。

 良作に出会えて嬉しいが、それだけ。ベンチマーク「隣の家の少女」のハードルが高すぎたのだろうか。これを「たいしたことない」と放言した輩がいるが、じゃぁ「隣の家の少女」よりスゴいのを教えてくれないか? というツッコミには賢明なことに沈黙を守っている。

 ケッチャム読んだことある人は、かなり慎重に言葉を選ぶ。これを超えるやつなんて、そうそう無いことを知っているから。非道小説をたくさん読んできた(つもりの)わたし自身、

  ケッチャムに匹敵する劇薬は、ドストエフスキーしかないのでは?

とまで思うようになってきた。

 「劇薬小説」の企画は、言い替えると、「文字で構築された世界でどこまで酷い目に遭うことができるか? 」になる。「酷い目に遭う」ためには、作品にのめり込む必要があるし、酷い目に遭う人と同体化してなきゃならない。それだけ作品に魅力がある、とも言える。

 スゴい小説にハマりこみ、読み終わったとき、「ああ生き延びた」「還ってこれた」という思いをしたことがないだろうか? そのとき、ナマナマしく潜り抜けた経験が酷ければ非道いほど「読まなきゃよかった」と感じないだろうか。

* * *
完璧な犠牲者 完璧な犠牲者(クリスティーン・マクガイア)

 ハタチの娘が拉致され、調教され、肉奴隷となった7年間の話。これが「小説」ではなくノンフィクションであるところがスゴい。誘拐した男が自作した箱に「監禁」されるのだが、ぐだぐだここで説明するよりもこの絵を見たほうが早い→箱女(エロ画像注意)。

 「もう誰とも干渉したりされたりしたくない」とダンボール箱を被る「箱男」(安部公房)は、さしずめ引きこもり空間のポータビリティだろうが、こっちの「箱」は、洗脳のための道具。外界の情報を徹底的に遮断することで容易に精神を壊すことができる。

 この事件を題材にしたのがケッチャム地下室の箱。残念なことに(というか恐るべきというか)、事実は小説よりも奇なりを地でいっている。小説の方が安心して読める。んで、「地下室の箱」の映画はこれらしい→コード(未見だが良さげ)


閉鎖病棟
閉鎖病棟(パトリック・マグラア)

 素直に「良かった」といえる作品。劇薬度は低。この小説をどういう風に読むのが効果的か考え込んでしまう。「歪んだ純愛の形」も「狂気に燃える情炎」もマチガイではないのだが、話者の狂気まで想像が閃いてしまうのは気のせい? 裏読みすぎ?

 …というのも、この作品は第三者が書いた「手記」の形式をしているから。第三者は読み始めてまもなく明かされるし、その人の知性や客観性は申し分のない。知りたいことは先回りして教えてくれるし、異常な行動の描写の後には「なぜなら…」と説明付けてくれる。

 けれども、時どき出てくる一人称がどうしても目に付くのよ、まるで読んでる自分が試されている気がして。そして読み終わった後でもじくじくと後を引くのよ、○○は本当に○○だったのか? ってね。そういう意味では遅効性の毒薬なのかも。


自由自殺法
自由自殺法(戸梶 圭太)

 プロット一発勝負なら大傑作。ただし、書いてる途中に行き倒れてしまっているもったいない作品。名は体、「国家が自殺ほう助する世界」の話。リアルな日本が描かれている。ネットよくあるセリフ「死ねば?」を執拗に拡大解釈し、「使えない国民を自殺まで誘導する」国家プロジェクトまで昇華させている。そのクセ内情は一切明かさない。ここまでは三重マル。

 ところが後半で失速する。読む人(そして恐らく書き手)を鬱にさせる話の展開は、いずれネタ切れになる。同じ話の繰り返しだもの。そして、ネタを重ねれば重ねるほど、その裏にある「理由」を書かなきゃいけなくなる。どうしてこんなことになったのか? ってね。ソコを考えて書き始めたならば、エピソードを通じてだんだんつまびらかにしていくだろうが、やってない。あるいはラストでついに明かされる、というサゲにしてもまぁ可、なのだが、それすらもしていない。

 これは、筆者が書くのに「飽きた」んだろう。

* * *

 「ZOO」は非常に期待して手にしたが、失望。「異形博覧会」もソコソコ期待してたんだが、失望。異常を精確に描く手法は2ちゃんねるの怖い話でさんざん慣れているので、そーいう免疫のない人にはクるかも。まずはこのランキングを上から順に読むことをオススメする。

────────────
「劇薬小説を探せ!」に戻る

| | コメント (0) | トラックバック (1)

« 2005年11月27日 - 2005年12月3日 | トップページ | 2005年12月18日 - 2005年12月24日 »