仕様探求の旅に出かけよう（４）：「要求仕様」ではなくて「全体共通認識仕様」なんだ！
『アジャイルプラクテス』と言う本を読んだ。
前に書いたアジャイルへの認識は間違えていた。
ウオーターフォールとアジャイルは対立した概念ではないと言う事が良く分かった。
今度ゆっくり書きたい。
ここ１ヶ月くらい土日も会社で、すでに5回くらい会社に泊まって仕事している。
モックモデルをお客様にお見せする為である。
何とか出来上がった。
従来のモックモデルと言うのは『あなたの言う事はこんな感じですね』と言いながら見せるのである。
そして『これから作りますが、出来上がり始めたらまた修正するから意見下さいね』と言う物であった。これでは、お客さんはまともに見ようとはしない。
これは開発者の甘えでもある。
プログラムで無い物（ドキュメントやモック）うを作るにはプログラムを作る物とは別な技術が必要なのだ。
仕様書も『要求仕様書』と呼ばれる場合が多い。
最近の昨日の高いradツールでチャカチャカと画面を作るのである。これでは、他の開発者はその仕様書を読んで、自分で解釈をするから出来上がったプログラムはバラバラのものになる。
どうしたらそれを防げるか考えた。
お客様、仕様作成者、開発担当者の3者が共通の認識を持つ為の仕様が必要なのである。
お客さんと仕様作成者の間で何度もキャッチボールをして、画面を固めて行く。
画面の中には全ての要素が詰まっているので。その画面にしたがって処理やデータ構造を検討する。僕はそれを「全体共通認識仕様」と呼ぶことにした。
一回モックの段階で開発を終らせる様な物だから猛烈に大変である。
まるで納品2週間前の様な追いつめられ方である。人は怠惰な生き物である。出来るだけ辛い事は後おくりしたいのである。
また、プログラマーは絵を書くのが苦手である。
RADツールでモックを作りがちである。
つまり、画面の動きや列項目の表示をプログラムを作るツールで作ってしまうのである。
僕も過去には何度もやったが、それが間違えの元であることを知っていた。なので今回は純粋に絵を書いた。
最初のモックでは30画面だったが、フィードバックを受けて結局今は50画面である。最初のモックで作り出して納品の時点で、20画面プラスになったとしたらそれはプロジェクトの失敗である。
作りながらユニットテストー＞総合テストを行って行くから、最終的な検収時点で問題が起こると目もあてられない事になるのだ。今なら何の問題もない。モックの状態で本気でお客さんに見てもらって完成させる事は最大重要な事である。
今その時点にいる。
ここ１週間でモックを3回アップグレードした。
お客さんもしっかり見てくれている。キチンと画面のショットに問題点や変更要求を書いてくれる。
モックの通りにシステムは出来るからしっかり見る様に話してある。
全ての画面を印刷して渡してそこに書き込んでもらい、フィードバックを受ける。
モックがプログラムの終着点となる様に進めるのだ。
5/31（明日である）には画面仕様、印刷仕様、処理仕様をあげる。
6/1にはCSS(画面の細かいインターフェース)の担当者と打ち合わせて進める。
これから7月の終わりまで開発は続く。多分土日はない。
上手く行けるか分らないが、どちらにしても時間は過ぎて行く。
これからの１０年を技術者として生きて行けるかの勝負どころである。
正しい食事をしながら前に進もう。
今日はこれから戦争である。
負け戦には出来ないのだ（笑）。
198775
