読者です 読者をやめる 読者になる 読者になる

ロバストネス図作成におけるプラクティス

ロバストネス分析を行うにあたり有効なアジャイルモデリング(AM)のプラクティスを抜粋。 

基本プラクティス

  • 利害関係者の積極的な参加:これはXPの「オンサイトの顧客」を拡張したものです。「オンサイトの顧客」とは、開発対象のシステムに関する情報を提供したり、要求とその優先度について適切でタイムリーな決断を下すことができる権限と能力を持つユーザに、現場にいてもらう必要性を述べたものです。AMでは、XPのプラクティス「オンサイトの顧客」を拡張して、直接のユーザやその上司や上級の管理職、運用担当者、サポート(ヘルプデスク)担当者といったプロジェクトの利害関係者に、プロジェクトに積極的に参加してもらうことを提唱しています。たとえば、上級の管理職に資源に関してその場で判断してもらったり、上級の管理職にプロジェクトに対する公的/私的な援助をしてもらったり、運用やサポートの担当者に、それぞれの担当職務に関係する要求やモデルの作成に積極的に参加してもらったり、といったことが考えられます。
  • 複数モデルを並行して作ろう:モデルの種類ごとに長所/短所があるため、1つのモデルだけでモデリングのニーズを満たすことは不可能です。たとえば要求を調査しているときには、いくつかの本質ユースケースやユーザストーリー、1つの本質UIプロトタイプ、いくつかのビジネスルールを作成する必要があります。アジャイルモデリングでは、「他の成果物に移ろう」のプラクティスと組み合わせることで、一度に1つのモデルに集中するよりも複数のモデルを並行して作成する方が、ずっと生産性が高くなることがよくあります。
  • 中身はシンプルに作ろう:要求、分析、アーキテクチャ、設計といったモデルの内容は、プロジェクトの利害関係者のニーズを満たせる範囲内で、できるだけ簡単にするべきです。つまり、正当な理由なしにモデルに余分な情報を付け加えるべきではありません。システム監査機能を追加するという要求がなければ、その機能をモデルに追加してはいけません。依頼されたときに(依頼があった場合にだけ)実際にその機能を追加できると信じる勇気を持ってください。
  • モデルを公開しよう:モデルは公開すべきです。多くの場合は、「モデル掲示用の壁」や「不思議の壁」と呼ばれるようなものに掲示します。モデルの掲示によって、隠しごとがなくなり、チームのメンバーやプロジェクトの利害関係者が最新のすべてのモデルをすぐに見ることができます。その結果、チームの「オープンで正直なコミュニケーション」が促進されます。モデル掲示用の壁とは、誰にでも見えるように自分のモデルを掲示する場所で、開発チームやプロジェクトの他の利害関係者からアクセスできるところでなければなりません。モデル掲示用の壁は、アーキテクチャのダイアグラム用に指定されたホワイトボードや、物理データモデルをプリントアウトしてテープで貼り付ける場所のように、物理的なものになる場合もあるでしょう。また、スキャンした画像を載せる内部的なWebページのように、仮想的なものの可能性もあるでしょう。
  • 少しずつモデリングしよう:大規模な仕事を小さな部分に整理して、順に、できれば数週間から1、2か月の間隔でリリースするというインクリメンタルな開発では、ソフトウェアを早くユーザの手に渡すことができるため、アジャイル(機敏)さが向上します。
  • 他の人々と一緒にモデリングしよう:「目的を持ってモデリング」を行っている場合、自分が何かを理解するためにモデリングをしていること、アイデアを他人に伝えるためにモデリングをしていること、あるいはプロジェクトの共通の構想を作り上げようとしていることに気付くことがよくあります。これはグループでの作業であり、複数の人の意見を効果的に組み合わせる必要があります。プロジェクトにとってきわめて重要な一連の中核モデルを作成するためには、開発チーム全体で協力する必要があることに気付くことも多いでしょう。たとえば、システムのメタファ(喩え)やアーキテクチャを構築するには、グループでモデリングをして、皆が合意し、しかもできる限り簡潔である解決策を作り出す必要があります。ほとんどの場合、これを行うためのもっともよい方法は、その問題について徹底的に人と論ずることです。
  • コードで確かめよう:モデルとは考えを抽象的に表現したものであり、開発対象の1つの側面を正確に反映するべきものです。しかし、そのモデルで大丈夫なのでしょうか。それを判断するには、コードを書いてモデルを確かめなければなりません。請求先住所の情報を入力するHTMLページの下絵を書いたとしましょう。それをコーディングして、その結果のユーザインターフェースをユーザに見せ、フィードバックをもらってください。複雑なビジネスルールを実装するロジックを表したUMLのシーケンス図を書いたのであれば、テストコードとビジネスロジックのコードを書き、テストを実行して、正しく動くことを確認してください。多くのプロジェクトで一般的になってきている反復型のアプローチでソフトウェアを開発するときには、モデリングは行わなければならない数多くのタスクの1つでしかないことを忘れないでください。少しモデリングをし、少しコーディングをし、そして(これが特に重要ですが)少しテストをするのです。
  • もっとも簡単な道具を使おう:大多数のモデルは、ホワイトボードや紙や、あるいはナプキンの裏にでも描くことができます。それらのダイアグラムを保存したければ、デジタルカメラで写真を撮ることもできますし、単に紙に書き写すこともできます。これで問題がないのは、ほとんどのダイアグラムが使い捨てだからです。それを描いて問題点をじっくり考えることに本当の価値があるのであって、問題が解決すればそのダイアグラムにはあまり価値がなくなります。そのため、ホワイトボードとマーカーというのが多くの場合にもっとも適したモデルを作る道具になります。重要なプロジェクトの利害関係者に見せるダイアグラムを作成するには描画ツールを使い、コードの生成などプログラミング作業に役立つときにだけモデリングツールを使ってください。次のように考えるとよいでしょう。単純なモデルを作成している場合、その多くは使い捨てです。というのも、「理解するためのモデル」を作成しているなら、問題を理解してしまえばそのモデルをとっておく必要はおそらくないからです。だとしたら、複雑なモデリングツールを利用する必要はありません。

基本プラクティスで最も重要なのは「利害関係者の積極的な参加」だ。ロバストネス分析には利害関係者の知恵が必要だ。その実現のためにこのプラクティスを遵守することはプロジェクトを成功させる可能性を高めるだろう。

追加プラクティス

  • 一時的なモデルを捨てよう:作成したモデルの大部分は、一時的/作業モデルです。つまり、設計の下絵、あまり正確でないプロトタイプ、インデックスカード、アーキテクチャおよび設計の代替案などといったモデルですが、これらはすでに目的を果たしていて、今後価値を持つものではありません。モデルはすぐにコードと一致しなくなりますが、それはあたりまえのことです。そこで、プロジェクトにとって価値があるのならモデルを同期させるか、モデルを更新するための労力に見合うだけの価値がない(費用対効果はマイナス)ためモデルを廃棄するかの判断を迫られることになります。
  • 話すためにモデリングしよう:モデリングを行う第2の目的は、チーム外部の人とコミュニケーションしたり、取り決めモデルを作成したりすることです。いくつかのモデルの利用者はチーム外の人なので、ワードプロセッサやお絵かきツール、あるいは高度なモデリングツールといった電子ツールを使い、時間をかけてモデルをきれいに整える必要があるかもしれません。
  • 理解するためにモデリングしよう:モデルを適用するもっとも重要な目的は、問題空間を検討したり、システムの要求を識別・分析したり、いくつかの設計案を比較して要求を満たす中でどれがもっとも簡潔な解決策になりそうかを判断したりすることです。このプラクティスを実行することで、クラスのライフサイクルや画面間のフロー、目的を果たせば捨ててしまうダイアグラムといった、ソフトウェアの1つの側面に焦点を当てた小さく簡潔なダイアグラムを作成することができます。

この追加プラクティス「一時的なモデルを捨てよう」「話すためにモデリングしよう」「理解するためにモデリングしよう」は重要だ。

ロバストネス図が「ロバストネス図以外のモデルの起点」となるためには関係者全員がこのモデルに対して「口を出す」必要がある。

例えば全ての開発者はこの図をベースとして設計する。DB設計者ならER図やテーブル設計書を、画面担当者なら画面遷移書やUI定義書を、プログラマならビジネスロジックドメイン、DAOを「ロバストネス図をベースにして」作成しなければならない。利害関係者ならこのモデルが現実化されたシステムを利用しなければならない。

そのためには図を理解しなければならない。不明点があれば質問をしながら理解を深め、問題があれば話し合い時には変更を決断しなければならない。この開発手法はロバストネス分析駆動開発といっていい。我々はこうした分析作業をしながら各モデルに適切な名前を付け、それを覚え、その意味を理解する。全ての設計はこの図の理解なしでは立ち行かない。そして最適化のために話し合う。そのために各人が積極的に参加する必要がある。