神がシステム開発を変える
上流工程でアシスタントが作成する文書は以下の通り。
神がシステム開発を変える
GODモデルのROIだが、たとえばV字モデルで期間３年、２００人年というようなプロジェクトがあったとする。控えめに計算してもGODモデルなら期間２年、１００人年くらいにはなる。成果物のほとんどを自動生成するからだ。GODモデルで自動生成される成果物一覧を下に示そう。
ダイアグラム
仕様一覧
- テーブル一覧
- クラス一覧
- テストクラス一覧
- テストデータ一覧
- UI設計書
- ジョブ一覧
- 用語一覧
- 設定値一覧
ソースコード
では技術者は一体何をするのか。彼らの仕事は成果物が妥当であることの確認。要はレビューである。
神がシステム開発を変える
昨今ではAjile開発が増えてきているがこれは小規模開発の話だ。大規模開発では依然としてV字モデルが採用されているのが日本の現状である。
V字モデルとは重厚長大なプロジェクトが中心であった時代に登場し日本で最も普及している開発モデルだ。だがQCD*1の点で問題がある。金がかかる、時間がかかる、質が悪い、の３重苦。管理者は納期遅れに頭を抱え、開発者は自分たちの作った品質の悪い成果物にストレスを抱え、顧客は納期の遅れや品質の悪さにクレームを出さずにはいられない。これがV字モデルの末路である。
ではなぜそれが分かっていて大規模開発はV字モデルを採用するのか。それは代替がないからだ。
確かにオブジェクト指向開発にはUP*2というモデルがある。これはAjileモデルとちがい大規模向けといわれている。ところがSIer中心の日本の開発現場にはUPは適さない。V字モデルの工程とあまりに違うためだ。V字モデルしかやったことがない日本のSIerには荷が重い。扱えないのである。
私がかつて居たプロジェクトもV字モデルを採用していたがキックオフ１年てすでに破綻寸前だった。進捗は８か月遅れ（キックオフから１年で！）、その上品質が悪いと顧客からクレーム、開発者は残業と休出で疲弊しBP*3は次々と離れていくという状況だった。そこで私たちはGOD*4モデルへの移行を提案した。GODモデルとはジェネレータを中心に開発を進めるモデルである。V字モデルとほとんど変わらない工程を持つのが特徴だ。
稟議の結果提案は段階的に受け入れられることになり私たちは最初にUML図ジェネレータの開発にとりかかることになった。UM図ジェネレータはクラス図やシーケンス図といったUM図を自動生成すツールだが開発のためにはジェネレータ開発の専門知識だけでなくUML図についての知識も必要だった。私たちはその役を買って出た。
ジェネレータにはさまざまな種類がある。UML図ジェネレータ、ER図ジェネレータ、ソースコードジェネレータ、機能設計書ジェネレータ、テスト設計書ジェネレータ、テストデータジェネレータ、ドライバコードジェネレータ、スタブコードジェネレータなど多岐にわたる。
ではなぜUML図ジェネレータを選んだのか。理由は費用対効果だった。当時のプロジェクトではクラス図とシーケンス図の作成が開発者たちの悩みの種であった。ほとんどがオブジェクト指向開発の経験がなくクラス図とシーケンス図作成に関するナレッジがなかったためそのままでは納期オーバーしてしまうことが予想された。
そこで私たちは開発者にクラス図とシーケンス図を書くことをやめさせ、代わりにクラス図定義申請書とシーケンス図定義申請書を書かせるようにした。定義申請書作成にかかる工数を最初１週間と見積もったが、彼らのスキルを考えリーダーには３週間と提言した。これは本来彼らがクラス図やシーケンス図の作成にかかるであろう工数の３分の１以下であった。開発者が定義申請書を書く隙に私たちはジェネレータの開発に着手し彼らの定義申請書の完了と同時に私たちも完了した。定義申請書を投入するとジェネレータは高い品質のクラス図とシーケンス図を瞬時に生成した。そしてその生成物は高い評価を得た。
納品後に開発者にヒアリングをすると面白いことが分かった。実はジェネレータはベータ版を開発者に配布していた。これは彼らが自分たちの作成した定義申請書が正しいのか同化を確かめたいという要望に応えてのことだった。彼らは最初定義申請書に戸惑ったが、そのおかげでクラス図やシーケンス図を確認しながら定義申請書を書けるようになった。これは、彼らにとってのジェネレータがプログラマにとってのコンパイラやデバッガの役割を果たすことを意味していた。プログラムと違い設計書のような文書の作成はその正しさの確認手段がない。そのため間違いに気づきにくいのだがジェネレータは開発者にとってテストツールの役割を果たした。これにより彼らは品質の高い定義申請書をかくことができた。
GODモデルの導入は期間短縮、コスト削減、品質向上という矛盾する３つの要素改善を成し遂げたのだ！
ユースケースの推敲
UC図をOO開発経験の浅い者が作成した場合とても読み辛いものとなる。UC図は様々な目線の者が読む文書である。そのためその様々な目線に耐えうる記述でなければならない。すべての関係者にわかるような記述が必要ということだ。だが、経験の浅い者はその記述が概してできない。彼らにとって特に厄介なのはシナリオの作成である。
ユースケースシナリオは「文」の羅列であるがこの「文」は基本「SVO」「SVOO」「SVOC」で表現されるのが望ましい。S、つまり主語は「アクター」と「システム」しかない。OはSがアクターの場合は画面のウィジェットつまりテキストボックスやチェックボタン等の入力項目やボタンやリンク等のイベント項目となり、システムの場合はドメインとなる事が多い。そしてVはその項目に対する振る舞いとなる。例えば
●アクターは、メールアドレスを、入力する【SVO】
という具合だ。文章は冗長である。ゆえに見やすさを兼ねて抽象化する必要がある。それが多くの人にわかりやすい記述となるからだ。上の例であればこういう表現となる。
●入会希望者はシステムにメールアドレスを登録する
これはユーザ視点の文である。だが最終的にはSVO形式となる。２はモデラーがクライアントとラフなレベルの要求確認をする際に重要だがそれが済めば重要ではなくなる。開発者は２を読めないからだ。だが１は読める。だから最終的には１が成果物となる。
重要なのは最初から１ができるわけではないということだ。原型は２でありそれが１になる。その変換がモデラーのタスクとなる。
１のようなユースケースシナリオの最終形は標準的な書き方がある。この例は「ユースケースからテストケースへの追跡可能性」にも示されている。一部抜粋しよう（誤植修正）。
このオンライン書店 (Online Bookstore) プロジェクトでは、ユースケースの基本フローは注文で、次のようになります。
B1 ユーザーがブラウザーに Web サイトのアドレスを入力します。
システムがログイン・ページを表示します。
B2 ユーザーは電子メール・アドレスとパスワードを入力します。
システムは正しいログインを確認し、メイン・ページを表示して、検索文字列の入力を要求します。
B3 ユーザーは検索文字列 (書名の一部) を入力します。
システムは検索条件と一致するすべての本のリストを表示します。B4 ユーザーは本を選択します。
システムは本の詳細な情報を表示します。
B5 ユーザーはその本をショッピング・カートに追加します。
ショッピング・カートの内容がユーザーに表示されます。
B6 ユーザーは「チェックアウト」オプションを選択します。
システムは配送先住所の確認を要求します。
B7 ユーザーは配送先住所を確認します。
システムは配送オプションを表示します。
B8 ユーザーは配送オプションを選択します。
システムはどのクレジットカードを使用するかをたずねます。
B9 ユーザーはシステムに登録されているクレジットカードを確認します。
システムは注文の最終的な確認を要求します。
B10 ユーザーは注文を確定します。
システムは確認番号を表示します。・・・
注目すべきはB1からB10までの文が単純であることだ。殆どが「SはOをVします」「SがO1をO2にVします」となっている。B2も文が直列でつながれているだけだしB5も能動態に直せばSVOで表現される。ここでより明確にSVOであることを示そう。
B1
【ユーザー】が【ブラウザー】に【 Web サイトのアドレス】を【入力】します。
【システム】が【ログイン・ページ】を【表示】します。
B2
【ユーザー】は【電子メール・アドレスとパスワード】を【入力】します。
【システム】は【正しいログイン】を【確認】します
【システム】は【メイン・ページ】を【表示】します
【システム】は【検索文字列の入力】を【要求】します。
B3
【ユーザー】は【検索文字列 (書名の一部) 】を【入力】します。
【システム】は【検索条件と一致するすべての本のリスト】を【表示】します。
B4
【ユーザー】は【本】を【選択】します。
【システム】は【本の詳細な情報】を【表示】します。
B5【ユーザー】は【その本】を【ショッピング・カート】に【追加】します。
【システム】は【ショッピング・カートの内容】を【表示】します。
B6【ユーザー】は【「チェックアウト」オプション】を【選択】します。
【システム】は【配送先住所の確認】を【要求】します。
B7【ユーザー】は【配送先住所】を【確認】します。
【システム】は【配送オプション】を【表示】します。
B8【ユーザー】は【配送オプション】を【選択】します。
【システム】は【どのクレジットカードを使用するか】を【たずね】ます。
B9【ユーザー】は【システムに登録されているクレジットカード】を【確認】します。
【システム】は【注文の最終的な確認】を【要求】します。
B10【ユーザー】は【注文】を【確定】します。
【システム】は【確認番号】を【表示】します。
このようにすべて叙述的な文に修正すればかなり明確な意味となる。ただそうならない文もある。修正済のB8を見てみよう。
●【ユーザー】は【システムに登録されているクレジットカード】を【確認】します。●【システム】は【どのクレジットカードを使用するか】を【たずね】ます。
これを見て皆さんは違和感を覚えるだろうか。１文目は素直に読めばこれは、画面に「登録されているクレジットカード」が表示されており、それをユーザが目視で確認するという意味だ。では2文目はどうか。システムが尋ねるとはどういう意味か。そもそもなぜアクションをユーザが起こしてもいないのにシステムに処理が移動したのだろうか。
実はこの２文目の主体はシステムではない。ユーザだ。処理がユーザからシステムに移動していない。ユースケース記述としてはトリッキーだ。私なら次のように書く。
●【アクター】は【クレジットカードを使用するか】を【たずね】ます。
これはアクションではない。ユーザ側からシステム側に処理が移動する条件はユーザがボタン押下などのアクションを起こさなけらばならない。ところが目視はアクションではない。ではこの次の行にあるのだろうか。ところが次の文はこうなっている。
●【システム】は【注文の最終的な確認】を【要求】します。
システムに処理が移動している。これはいったいどういう事か。
「確認する」の意味は通常３つである。
①「目視する」
②「目視確認し▲▲ボタンを押下する」
③「確認ボタンを押下する」
では上の例はどれに相当するのか。
●【ユーザー】は【システムに登録されているクレジットカード】を【確認】します。
●【システム】は【どのクレジットカードを使用するか】を【たずね】ます。
●ユーザーはシステムに登録されているクレジットカードを確認します。（【ユーザー】は【登録されているクレジットカード】を【確認】する）
これは登録されたクレジットカード情報が画面に表示されていることを確認するという意味だ。だがこの「確認」は「目視」ではなく「確認ボタンを押下する」と云う意味である。これは次行のアクティビティからわかる。
システムは注文の最終的な確認を要求します。
察し、そこから確認ボタンの存在を推理できる。その上で、カード情報がどのような構成になっているかをドメインモデル図、概念モデル図を参考にしながら別紙にでも書き留めておかないとこのユースケースレビューを終わらせることはできない。
こうした他のモデリングを並行しながらユースケースを検証をしていく過程で、ベンダーとクライアントは様々なことを学習していく。不整合、記述不備、曖昧記述は直されユースケースは徐々に推敲されていく。その間に新たなアイデアも浮かぶ。ならばそれも取り込めばよい。そのレビューが最適化につながる。これを推敲と呼ぶ。
推敲作業はユースケースシナリオが完成してから２回行われる。その際に１回目の推敲がおわるまで、設計作業は開始すべきではなく、２回目の推敲が終わるまでは実装を始めるべきではない。
＜修正中＞
ユースケース
OOAでは機能要求を「ユースケース図」に記述する。
「ユースケース図」にはユースケースの説明文として以下のような「ユースケース記述」が付与される。主処理フローはメインフローに記述されるがケースにより代替フロー、例外フローも記述される。またフロー開始時の条件は事前条件、終了時の条件は事後条件、ビジネスルールなどは事前事後に適用される不変条件として記述する。
なお、ユースケース図の各要素（特にフローと条件）はイテレーティブに記述が追記・変更されることが前提である。
【ユースケース名】商品を購入する
【概要】本ユースケースは、Web上および店頭で商品を購入する際に呼び出される。店頭では、店員を通じて本ユースケースが利用される【アクター】
- Webユーザー
- 店員（オペレータ）
【事前条件】
- アクターがログイン済であること
【メインフロー】
- アクターは、購入したい商品のジャンルを選ぶ
- システムは、選択されたジャンルの商品一覧を返す
- アクターは、商品を選ぶ
- システムは、商品の詳細情報（説明、金額、写真）を返す
- アクターは、この商品でよければ商品購入手続きに入る
ユースケースはユースケース名を決めた時点で粒度が決まるが、その粒度を小さくしすぎて機能数が増大してしまう落とし穴がある。これを回避するため「ユーザの認識できる言葉」でユースケース名をきめていく必要がある。
機能単位をユースケースにするな
ユースケースの単位を、機能分割の感覚で作ってしまいます。そのようなユースケースは、ユーザーの視点から見ると時系列を伴うものが多く、時系列を表すすべがないユースケース図には不適切であり、また、ユースケースの個数が膨大になってしまいます。
ユースケースは「技術」「性能」「品質」に依存しない。DBが変わったりFWやPGLがかわってもユースケースには影響しない。
データベースがどこにあるかなどは問題ではない
よくある誤解が、例えば「商品を登録する」というユースケースの中にデータベースが存在すると勘違いしてしまうことです。この勘違いから、「商品を参照する」というユースケースに関連を持つアクターからも「商品を登録する」に関連を引いてしまいます。
ユースケースには変更されやすいホットスポット、変更されにくいコールドスポットがある。そしてコールドスポットがあるユースケースにはBRが含まれることが多い。逆にBRがないユースケースはホットスポットとなりやすい。優先順位が高いのは前者だ。ロバストネス分析でBRの数を数えればそれが開発優先順位の指標となる。勿論数が多い方が優先順位が高い。変わりにくい、またはビジネスにとって重要なユースケースから始めるのだ。
最後に洗い出されたユースケース全体を眺めて粒度をそろえる。
ビジネスルールの概要
ビジネスルールはユースケース抽出と平行で分析する。
このルールはドメイン分析にて抽出され最終的にはドメインクラスとして定義される。ビジネスルールの概要には次のように定義されている。
ビジネスルールとは、ビジネスの1つの側面を定義あるいは制限するもので、ビジネス構造をはっきりさせたり、ビジネスの振る舞いに影響を与えたりするために作成します。ビジネスルールでは、アクセス権限に関する事柄に着目することがよくあります。たとえば、教授は、自分が教えているゼミを受けている学生の点数を入力したり修正したりすることができますが、他のゼミの学生の点数を入力することはできません。ビジネスルールには、ビジネス上の計算が含まれることもあります。たとえば、パーセントで表した学生のゼミの評価(91%など)を、文字で表した評価(A-など)に変換する方法などです。ビジネスルールの中には、組織の方針に着目したものもあります。大学の方針として、同じ学期のうちに2つ以上のコースで不合格になった学生を1年間停学にするというものがあるかもしれません。
ビジネスルールのロジックはビジネスロジックの粒度に比べ小さい。そのためしばしばエンティティに付与される。例えば以下のようなビジネスルールがあるとしよう。
ビジネスルールの例 (要約形式)
- BR123 教授は学生の評価をつけることができる。
- BR124 教授から権限を認められた助手は学生の評価をつけることができる。
- BR177 数値の評価と文字の評価を変換するための表。
- BR245 修士過程には論文の提出を含まなければならない。
全てのルールは「BR」に定義され「BL」より呼び出される。依存性は「BL→BR」。「BR」は「BL」に依存しないが「BL」は「BR」に依存する。
しかしこれで正しいのだろうか。さらに調べたところ詳細なルールが分かった。
名前:
教授は学生の評価をつけることができる
識別番号:
BR123
概要:
自分だけが教えているゼミの学生の評価を、教授だけが最初に入力したり変更したり削除したりすることができる。それかできるのは、ゼミが行なわれている学期の間だけである。
例:
「生物301 ガンマ放射線の先進的利用」を教えているBruce博士は、そのゼミに登録している学生全員の評価をつけることができるが、Peter博士が教えている「生物302 クモ類に対する放射線の影響」に登録している学生の評価をつけることはできない。
ロバストネス図作成におけるプラクティス
ロバストネス分析を行うにあたり有効なアジャイルモデリング(AM)のプラクティスを抜粋。
基本プラクティス
- 利害関係者の積極的な参加：これはXPの「オンサイトの顧客」を拡張したものです。「オンサイトの顧客」とは、開発対象のシステムに関する情報を提供したり、要求とその優先度について適切でタイムリーな決断を下すことができる権限と能力を持つユーザに、現場にいてもらう必要性を述べたものです。AMでは、XPのプラクティス「オンサイトの顧客」を拡張して、直接のユーザやその上司や上級の管理職、運用担当者、サポート(ヘルプデスク)担当者といったプロジェクトの利害関係者に、プロジェクトに積極的に参加してもらうことを提唱しています。たとえば、上級の管理職に資源に関してその場で判断してもらったり、上級の管理職にプロジェクトに対する公的/私的な援助をしてもらったり、運用やサポートの担当者に、それぞれの担当職務に関係する要求やモデルの作成に積極的に参加してもらったり、といったことが考えられます。
- 複数モデルを並行して作ろう：モデルの種類ごとに長所/短所があるため、1つのモデルだけでモデリングのニーズを満たすことは不可能です。たとえば要求を調査しているときには、いくつかの本質ユースケースやユーザストーリー、1つの本質UIプロトタイプ、いくつかのビジネスルールを作成する必要があります。アジャイルモデリングでは、「他の成果物に移ろう」のプラクティスと組み合わせることで、一度に1つのモデルに集中するよりも複数のモデルを並行して作成する方が、ずっと生産性が高くなることがよくあります。
- 中身はシンプルに作ろう：要求、分析、アーキテクチャ、設計といったモデルの内容は、プロジェクトの利害関係者のニーズを満たせる範囲内で、できるだけ簡単にするべきです。つまり、正当な理由なしにモデルに余分な情報を付け加えるべきではありません。システム監査機能を追加するという要求がなければ、その機能をモデルに追加してはいけません。依頼されたときに(依頼があった場合にだけ)実際にその機能を追加できると信じる勇気を持ってください。
- モデルを公開しよう：モデルは公開すべきです。多くの場合は、「モデル掲示用の壁」や「不思議の壁」と呼ばれるようなものに掲示します。モデルの掲示によって、隠しごとがなくなり、チームのメンバーやプロジェクトの利害関係者が最新のすべてのモデルをすぐに見ることができます。その結果、チームの「オープンで正直なコミュニケーション」が促進されます。モデル掲示用の壁とは、誰にでも見えるように自分のモデルを掲示する場所で、開発チームやプロジェクトの他の利害関係者からアクセスできるところでなければなりません。モデル掲示用の壁は、アーキテクチャのダイアグラム用に指定されたホワイトボードや、物理データモデルをプリントアウトしてテープで貼り付ける場所のように、物理的なものになる場合もあるでしょう。また、スキャンした画像を載せる内部的なWebページのように、仮想的なものの可能性もあるでしょう。
- 少しずつモデリングしよう：大規模な仕事を小さな部分に整理して、順に、できれば数週間から1、2か月の間隔でリリースするというインクリメンタルな開発では、ソフトウェアを早くユーザの手に渡すことができるため、アジャイル（機敏）さが向上します。
- 他の人々と一緒にモデリングしよう：「目的を持ってモデリング」を行っている場合、自分が何かを理解するためにモデリングをしていること、アイデアを他人に伝えるためにモデリングをしていること、あるいはプロジェクトの共通の構想を作り上げようとしていることに気付くことがよくあります。これはグループでの作業であり、複数の人の意見を効果的に組み合わせる必要があります。プロジェクトにとってきわめて重要な一連の中核モデルを作成するためには、開発チーム全体で協力する必要があることに気付くことも多いでしょう。たとえば、システムのメタファ（喩え）やアーキテクチャを構築するには、グループでモデリングをして、皆が合意し、しかもできる限り簡潔である解決策を作り出す必要があります。ほとんどの場合、これを行うためのもっともよい方法は、その問題について徹底的に人と論ずることです。
- コードで確かめよう：モデルとは考えを抽象的に表現したものであり、開発対象の1つの側面を正確に反映するべきものです。しかし、そのモデルで大丈夫なのでしょうか。それを判断するには、コードを書いてモデルを確かめなければなりません。請求先住所の情報を入力するHTMLページの下絵を書いたとしましょう。それをコーディングして、その結果のユーザインターフェースをユーザに見せ、フィードバックをもらってください。複雑なビジネスルールを実装するロジックを表したUMLのシーケンス図を書いたのであれば、テストコードとビジネスロジックのコードを書き、テストを実行して、正しく動くことを確認してください。多くのプロジェクトで一般的になってきている反復型のアプローチでソフトウェアを開発するときには、モデリングは行わなければならない数多くのタスクの1つでしかないことを忘れないでください。少しモデリングをし、少しコーディングをし、そして(これが特に重要ですが)少しテストをするのです。
- もっとも簡単な道具を使おう：大多数のモデルは、ホワイトボードや紙や、あるいはナプキンの裏にでも描くことができます。それらのダイアグラムを保存したければ、デジタルカメラで写真を撮ることもできますし、単に紙に書き写すこともできます。これで問題がないのは、ほとんどのダイアグラムが使い捨てだからです。それを描いて問題点をじっくり考えることに本当の価値があるのであって、問題が解決すればそのダイアグラムにはあまり価値がなくなります。そのため、ホワイトボードとマーカーというのが多くの場合にもっとも適したモデルを作る道具になります。重要なプロジェクトの利害関係者に見せるダイアグラムを作成するには描画ツールを使い、コードの生成などプログラミング作業に役立つときにだけモデリングツールを使ってください。次のように考えるとよいでしょう。単純なモデルを作成している場合、その多くは使い捨てです。というのも、「理解するためのモデル」を作成しているなら、問題を理解してしまえばそのモデルをとっておく必要はおそらくないからです。だとしたら、複雑なモデリングツールを利用する必要はありません。
基本プラクティスで最も重要なのは「利害関係者の積極的な参加」だ。ロバストネス分析には利害関係者の知恵が必要だ。その実現のためにこのプラクティスを遵守することはプロジェクトを成功させる可能性を高めるだろう。
追加プラクティス
- 一時的なモデルを捨てよう：作成したモデルの大部分は、一時的/作業モデルです。つまり、設計の下絵、あまり正確でないプロトタイプ、インデックスカード、アーキテクチャおよび設計の代替案などといったモデルですが、これらはすでに目的を果たしていて、今後価値を持つものではありません。モデルはすぐにコードと一致しなくなりますが、それはあたりまえのことです。そこで、プロジェクトにとって価値があるのならモデルを同期させるか、モデルを更新するための労力に見合うだけの価値がない(費用対効果はマイナス)ためモデルを廃棄するかの判断を迫られることになります。
- 話すためにモデリングしよう：モデリングを行う第2の目的は、チーム外部の人とコミュニケーションしたり、取り決めモデルを作成したりすることです。いくつかのモデルの利用者はチーム外の人なので、ワードプロセッサやお絵かきツール、あるいは高度なモデリングツールといった電子ツールを使い、時間をかけてモデルをきれいに整える必要があるかもしれません。
- 理解するためにモデリングしよう：モデルを適用するもっとも重要な目的は、問題空間を検討したり、システムの要求を識別・分析したり、いくつかの設計案を比較して要求を満たす中でどれがもっとも簡潔な解決策になりそうかを判断したりすることです。このプラクティスを実行することで、クラスのライフサイクルや画面間のフロー、目的を果たせば捨ててしまうダイアグラムといった、ソフトウェアの1つの側面に焦点を当てた小さく簡潔なダイアグラムを作成することができます。
この追加プラクティス「一時的なモデルを捨てよう」「話すためにモデリングしよう」「理解するためにモデリングしよう」は重要だ。
ロバストネス図が「ロバストネス図以外のモデルの起点」となるためには関係者全員がこのモデルに対して「口を出す」必要がある。
例えば全ての開発者はこの図をベースとして設計する。DB設計者ならER図やテーブル設計書を、画面担当者なら画面遷移書やUI定義書を、プログラマならビジネスロジック、ドメイン、DAOを「ロバストネス図をベースにして」作成しなければならない。利害関係者ならこのモデルが現実化されたシステムを利用しなければならない。
そのためには図を理解しなければならない。不明点があれば質問をしながら理解を深め、問題があれば話し合い時には変更を決断しなければならない。この開発手法はロバストネス分析駆動開発といっていい。我々はこうした分析作業をしながら各モデルに適切な名前を付け、それを覚え、その意味を理解する。全ての設計はこの図の理解なしでは立ち行かない。そして最適化のために話し合う。そのために各人が積極的に参加する必要がある。
