はじめに
ソフトウェア開発は危険です。急に暴れることから、ある時は狼男、ある時は熊に例えられます。まじめにコツコツと働いていたのに、突然現れた狼男や熊によって計画が台無しになってしまいます。
混乱に陥ったプロジェクトを見てみると、混乱の原因は意外と明確です。しかも、当事者である若いメンバーから部門のマネージャに至るまで、だいたい答えられることも多いでしょう。しかし時すでに遅し、混乱を押さえるには仕切り直して計画や配員を見直さないとプロジェクトを立て直すことができないでしょう。
不確実コーンを細くする
社会の発展や競争の激化、ソフトウェア技術の進歩によってソフトウェア開発期間は短く、より多機能になり、見積もりの振れ幅を時間軸で示した不確実コーンは広く、短くなっています（[#TiDD] 最近のソフトウェアを考えるとアジャイルに向かう）
そこで、短い期間に区切って段階的に開発するアジャイル開発が増えてきています。 これば、不確実コーンを小さなコーンに分ける方法です。 アジャイル開発はUXを重視する場合や、まずはビジネスを開始したい場合には、実際の動作を見極めながらの方向性の変更や、必要なものからビジネスの支援が可能なので、とても効果的です。
しかし、必要な機能を分解できない場合や、イテレーション（スプリント）を複数回実施できないほど短期間の開発の場合には、効率的なモデリングでリスクを下げて不確実コーンを小さくする必要があります。
そこで求められるのは、戦略的な考え方です（[#agileto2012] 『チェンジ！』の考え方 ～マネしやんと！～）。その時点で最も効果のあるポイントをのモデルを作成する必要があります（大規模開発の場合は、ランチェスターの法則（ランチェスターの法則と売り上げ、利益、利益率）に従って総力戦も可能ですが、重点の見極めは大切です）。
作成するモデルは、ドキュメントとして完成されたものでなくても、考える道具になり、ステークホルダーと共有できるなら、なんでも良いでしょう。以下にパターンに分けて説明しましょう。
全体が曖昧な場合
何かを作ってしまうと、それに引きずられて全体像が見えにくくなる場合がありますので、全体がぼんやりとしている時にわかる所から作り出すのは賢明ではありません。
全体像を抽象的な方向性でなく、具体的な構造を考えて実現可能性を高めます。具体的には、業務フロー、シーケンス図など全体の流れがわかるモデルを作成します。モデルを書いてみると、そこには業務の用語やデータが見えてくると思います。
抜けがあるような気がするとき
データをモデリングします。必要なデータを探してまとめます。ER図でも、オブジェクト図やクラス図でも、ただの一覧でも構いません。
次に見つけたデータがどこで作られ、どこで更新され、どこで削除されるかの説明を試みます。説明ができたなら不安が解消していると思いますが、精査したければやり過ぎないレベルでCRUDを書いてみても良いでしょう。
実装イメージがわかない、自信が無いとき
あまり経験の無い環境などで、自信が無いなら調べましょう。インターネット上の記事は大まかな知識や事例を知るには役立ちますが、最終的には公式ドキュメントで確認しましょう。
それでも不安が残ったり、わからない所がある場合はプロトタイプを作成します。プロトタイプは全ての実装ではなく、課題となっている所を抜き出して単純化したものですので、まさに「モデル」です。
モデリングのポイント
ここで示したモデリングの方法は、以下の3点を明確にするものです。
- 全体のイメージ
- データと関係
- 関連ソフトウェアの詳細仕様
これらのモデリングを考える道具道具として使い、リスクを排除します。これによって不確実コーンを細くして、ソフトウェア開発の混乱を少なくします。
ここで注意しないといけないのは、前回（効率的なモデリングをマネージメントする その１ - モデリングの目的 -）に書いた様にモデリングの目的には様々あるものの、ここで挙げた方法は
- 見つける、理解する
- 整理する
- 作り出す
といった目的が中心です。つまり、モデリングの全ての目的ではないのです。モデリングでリスクを低減するには、リスクそのものにポイントを絞ったモデリングが必要で、その他の目的を達成する際の参考になりますが、不十分なものです（プロトタイプと同じです）。しかし、それでも優先してモデリングすることが重要なのです。
おわりに
ここであげた効率の良いモデリングとは、義務としてドキュメントを早く仕上げるのではなく、個々のプロジェクトに特有のリスクを低減する方策としてモデリングです。このような視点でプロジェクトを実践すれば、より安定した開発を実現することができるでしょう。
モデリングは工程に関係なく、必要ならいつでも実施すべきです。「しかし、開発標準が、、、」と言われる方のために、次回は「開発標準を素直に実施しない」ことについて説明します。