仕様探求の旅に出かけよう(5):全体共通認識仕様書 β ここは通過点でしかない。

今週は嵐のようだった。
土日出て、1日会社に泊まった。

ようやく『全体共通認識仕様書 β』が上がった。
ここに来るまでは担当者との話し合いである。
ここから先は、担当者の社内で見てもらう。

ソフトの開発では、納品してからの検収期間に当たる。


開発者の間でも話し合いが始まる。
特にwebサービスCSSが重要なので、CSSの担当者と打ち合わせなければならない。
また、プリントに関してはやった事のない物だから友人の技術者にやってもらう事になっている。
具体的にコードを書いて行くと出てくる問題は物にある物だ。

各開発者は別に個別仕様書を作り始める。




お客様、担当者と僕、全ての開発者=『開発全体』がまとまっていく。

画面インターフェースに関してのドキュメントが一つ
モックモデルが主導となって、画面のショットを左にして右ページに注意事項やコメントを入れたものである。
これはページ数で138ページになった。
画面数が50くらいある。


データベースのスキーマに関する書類が1種類。
メインは今回はシステムの移植なので、現在のフィールドと対応するフィールドの表である。
そこではNOSQL的に実テーブル(DB上のデータを格納)の構成と論理テーブル(perl上に持って来た後で再構成するテーブル)これはハッシュ化するテーブルと配列化するテーブルの2種類に分れる。


処理について記述してあるドキュメントが一つ

プリントに関するドキュメントが一つ(30ページくらい


お客さんには画面仕様を合計5部渡す。

重要な事は印刷して渡すと言う事である。

猛烈に大変だけど、この手間を取らないと、自分で出して作業などしてもらえないからである。


既に問題点は指摘されているし、僕も分っているので直しを始める。
βでモックは一回凍結『120525』して、『120610』と言うモックを作って、そちらを更新始める。

モックは開発ツールで作る事はなく、絵で作るのだ。
完全にこの形で良いと言う所まで作ってから開発に入るのだ。

開発ツールで作ってしまうと、どうしてもそこまで作ったソースとらわれてしまう。
人間は、捨てるのに臆病になる生き物なのだ。
僕はこれをwebを作っている開発者に教えられた。



無論開発ツールで作った時も、モックの状態の時を通過する。
その時はその時で評価してもらうのだ。




僕はこれから、perlのオブジェクトの設計 モジュールの設計を始める。
一回、頭の中で作るのであるから時間はかかる。

いつもならば、納品10日前に起こるシチュエーションである。

様々な問題点が浮かんで来て、かなり根本的な所からの変更が出て来ている(ほとんどは僕が見つけた問題である)。
画面の推移が余りに自由すぎて帰って混乱を生む事が分った。CSVの書き出しの事を忘れていた。
詳細の設計を進めながら画面を直して行く。

今まで、何でこう言うやり方が出来なかったんだろうかなあ。


52歳にして初めて見つけた。




変われると言う事は素晴らしい事だ。



本当にこのやり方が良いものかどうかは7月末(プログラムの納品時)に分る。
そこで満足のいくものが出来ていれば僕の勝ちである。


まあ、負けてもまた挑戦すれば良いのだ。


199691