仕様探求の旅に出かけよう（７）：「要求仕様」ではなくて画面部分の納品なのだ。

4/10に仕事がスタートした。
打ち合わせをして、色々な話し合いをした。
5/25にモックを上げて、相手会社全体にそれを見てもらう進行にした。
5/29に会社全体に対するレビューが行われる事になった。

今回は、あなたのソフトはこうなるぞ！完成品もこの画面だぞ！
と言うものを作った。

考えてみると、これは「試作品=mok」ではなくて、「製品」なのだ。
納品の一種と考えて良い。

今のこの時点から、色々な開発者が一気に開発を始める。
出発点なのだ。

『全体共通認識仕様書』と呼んだのはそんな意味が有った。

そう考えると色々な事が解けてくる。

アジャイルは頻繁なコミュニケーションをその本質とする。
また、頻繁な納品サイクルをその特徴とする。
当然テストを繰り返す事になる。
お客さんは常に（１週間くらいのサイクルで変わって行く）ソフトを見る事ができる。
当然、フィードバックも頻繁な物となる。

リリースの記録を見ると、

4/20-5/10手で書いた紙の上の画面で担当者と話し合う。
まずは10日で50近い画面を絵で書いてブラウザで見れる様にした。

１）5/21：大まかな画面の流れが出来ているが細かいフィールドなどが出来ていない
　　画面に必要な機能からボタンを配置して、一覧と詳細の組み合わせを考える。
　　機能にたどり着く道筋が見える事が重要。

２）5/24：全ての画面のフィールドが入る
　　テーブル構造が決まって来たのでフィールドを入れる。

３）5/27：いくつかの議論の結論を出して変えた
　　ややこしい画面（システムで違うが、多くの場合3-4画面である。業務の難しさが反映される画面である）

４）6/8：大幅にインターフェースを変えた
　　何度も通して見ていると気がつくことが有る。また、29日のフィードバックが入る。

５）6/11：CSSの担当者と打ち合わせて最終案を出すことにした。
　　ここでまた変わるが、重要である。実装の担当者と話して、難しかったり駄目な問題はスキップする。

この間にも沢山の変更をしている。

これをソースでは書いていないのだ。

絵で書いている。
だから惜しげもなく変えられる。

アジャイルプラクティスにはトルコの諺が引用されている。
『どんなに遠くまで進んでいても、道を間違えている事が分った時には引き返せ。』

確かにそのとおりである。

それは人生にも繋がる。

202399