|
[2008 年 12 月号] |
［技術講座］
本稿は、OGIS 総研開催の 2007 年度第 2 回西日本フォーラムで発表した内容を再校正しています。
前編 では、「業務モデリングの適用事例と有効性について」と題し、UML 導入事例を紹介し、モデル / モデリングの有効性について考えました。限られた時間で要件定義工程を進めていくには、工程の初期に、システムの全体像を描き、ヌケ・モレ・矛盾がないことを確認した上で、詳細な工程に入るように手順を整えることが肝要です。この局面で、モデル / モデリングは効力を発揮します。
今回は「業務モデリングのパフォーマンスを 3 倍にあげるためのモデリングハックス」と題して、要件定義工程でモデル / モデリングのパフォーマンスをあげるためのちょっとした 9 つの工夫を紹介したいと思います。
モデル、あるいはモデリングを活用する人とその利用目的には以下が考えられます。
ここから、2 つの目的：システムを検討（モデリング）するためと、システムを｛ 理解 / 把握 ｝するためが想定できます。
全体を俯瞰する工程では、全体を俯瞰することに注力します。取組むべきテーマ / 課題のタイトルが洗い出されており、そのテーマ / 課題が、全体とどういう関係があるかが分かるレベルで一旦止めます。多くの業務やシステムのエキスパートの時間をお借りして、全体像を纏め上げる場では、アウトラインを描くところまでにとどめます。各々の詳細なテーマは、それぞれのエキスパート（あるいは意思決定者）に分担していただけるように調整します。
詳細検討をするにあたり、考慮すべき事項があれば、その事項が想起できるレベルにとどめ、詳細な検討に入り始めないようにします。検討を行わないのではなく、別のテーマとして検討する場を設定することで、検討すべき対象から外れないように打合せをコントロールします。
アウトラインを描いた後で、検討すべき事項の要否や優先順位を検討し、詳細な検討工程をスケジューリングします。
モデルは全体像を検討することに集中し、詳細レベルに入り込まないように注意します。
一方で、検討対象は、正確でなければなりません。 モデルを読む人が誤解しそうな言葉や関係はないか、不足はないか、重複はないか、といった正確さについての点検が必要です。
正確な定義ができてから、詳細についての検討に入ります。 ここで、誤解が発生したまま詳細の検討に入らないように注意する必要があります。 同じ会社でも組織が違えば、同じことを別の言葉で言い表したり、同じ言葉で異なるものを指していたりする場合があります。 そのため、言葉の定義や、誤解のない言葉への洗練作業が必要です。正確であれば詳細である必要はありません。後の工程で誤解が発覚した場合、手戻りが発生します。
モデリングのツール選択は生産性に大きく影響します。 モデリングツールは有償 / 無償さまざまなツールがあり迷うところですが、TPO にあわせて使いやすいものを使うことをお勧めしています。 モデル検討の参加人数が多い場合、参加メンバーがモデリングに不慣れな場合、要件定義初期のブレーンストーミングのような場合では、模造紙とポストイットや、印刷機能付きのホワイトボードを利用することが有効です。 参加者が同じものを同時に広く見ることができ、複数の参加者が同時に手を動かすことができるからです。
モデリング作業やモデリングツールにも慣れた少数のメンバーによる検討の場合には、プロジェクタで投影しながらモデルを検討するのもいいでしょう。投影が難しい場合には印刷したものを参加者に配布しながら検討を進めることも有効です。
いずれにしても、参加者が同時にモデルを俯瞰できるようにすることが大切です。また、特定の人しか検討に参加できないということがないように配慮します。
初期のモデリング作業では追加・削除・変更が頻繁に発生しますので、そのような作業に耐える道具選びが必要です。検討初期は模造紙やホワイトボードを使い、ある程度検討が進んだ段階で電子化するとよいでしょう。
モデルを検討する場合、モデルで表現しにくいケースが出てきた場合、モデルでどう表現していいか参加者に知識がない場合は、文章や表で補足しながら検討を進めます。 表記法に習熟してからモデル検討に入ることが望ましいですが、実際の場面では、モデリングを学びながらプロジェクトを進める場合もあると思われますし、新しいバージョンの表記法がキャッチアップできていない場合もあるでしょう。 このような場合、表記法の正確さにとらわれすぎないようにします。本来の検討テーマから外れてはいけません。ただし、独自の表現を使う場合、他のメンバーがモデルを読み誤ったり、モデルの書き方がぶれたりしないように、凡例を決めておきます。
モデルを検討する場合に注意すべきこととして、作成するモデルを、今後参画してくるであろうメンバーを含め、メンバー全員が誤解なく理解できるものにすることです。項目を羅列し、ヌケや重複、曖昧な表現がないかを調べ、粒度が揃っていることを確認します。項目の列挙が完了したら、関連や構造を検討します。 全体の構造を明確にしたら、言葉を定義します。 構造化や言葉の定義の過程で不整合が発生すれば改定し、最終的に整合性のあるものにします。
紙一枚にこだわることには意味があります。モデルで検討することのメリットは、全体を俯瞰することにあるからです。A3 ないし A4 の紙に収まらない場合は、上位のレイヤでモデル分割を行い、モデルの大きさを調整します。 多すぎるモデル要素を含んだモデルを検討するよりも、適切に分割されたモデルを検討するほうが、間違いが少なく、効率的です。
また、検討する人も、何枚もの紙をひっくり返しながら検討するよりも、紙一枚に集中するほうが効率的です。
モデルを検討するときは、テーマを絞って検討します。
モデル検討中は、要望事項や、業務ロジックに関係する情報提供、確認すべき疑問点などが話題に挙がります。 業務概念の関係をクラス図で検討しているときに、チェックロジックに関する懸念事項の話題や、遵守すべき画面の操作性に関する話題になることもあります。 それらの話には重要なテーマが含まれている場合がありますが、テーマが迷走しないようにコントロールする必要があります。
モデルの検討に関連しない内容が話題に挙がった場合は、課題一覧や業務ルール一覧に記入し、詳細に立ち入らないようにします。 あらかじめ、課題一覧や業務ルール一覧といったファイルを、情報の受け皿として準備し、モデル検討の場ではモデルに集中できるようにコントロールします。
ファイル名、ネーミングルール、ユースケース番号、アクター番号、ビジネスルール番号などのナンバリングルールや、ファイル保存先をあらかじめ決めておくことで、円滑にモデリングを進めることができます。
(※1) 実アプリケーションの要件定義で作成した成果物のため、ノイズ処理をしております。
ユースケース一覧・業務ルール一覧、課題一覧を記入するファイルやフォーム、ナンバリングルールを準備しておくと、効率的に検討を進めることができます。 プロジェクトの検討スケジュールや、会議の検討テーマや位置づけを俯瞰できる資料を参照しながら、打合せを進行するとさらによいでしょう。
(※2) 実アプリケーションの要件定義で作成した成果物のため、ノイズ処理をしております。
参加するメンバーが詳細な検討を行う際に、上位のモデルとその検討過程の情報を共有できる環境を用意することで、メンバーの理解を促進し、より効率的なプロジェクト運営を図ることができます。 参加するメンバーに、全体文書の体系、検討プロセスの実績や計画、具体的なモデルを共有できる環境、環境を理解するためのステップを提供することで、円滑なプロジェクト参入が可能になります。
モデリングはアウトラインをスケッチし、全体像を検討する点で有効です。 共通の表記法・ネーミングルール・採番ルール・文書の保管方法・課題管理表などのルールを整備し、効率的に実施できるツールの選定し、検討対象・検討の深さに関する意識合わせを実施することで、一層効果を発揮します。 モデルやモデリングの用途 / 効果を意識しつつ、プロジェクトの進め方や運用ルールを整備改善し、より効果的な要件定義を進めていきましょう。
※今回は要件定義工程でのモデル / モデリングの使用方法について検討しましたが、モデルはプロジェクト期間中のみならず、システム稼動以降に運用維持管理に参画するメンバーが全体像を理解する局面でも威力を発揮しますし、企業レベルで全体システムを検討していこうとする担当者にとっても重要な情報を提供するものです。 検討だけを目的とした場合、矛盾を含んだ未完成モデルで終わらせることも可能ですが、本記事では、モデルは後々まで使われるものであることを想定しています。
| © 2008 Keiko Nakase |
|
