モデリングの一般業務に対する効用

　ある作業を部下に任せているのですが、「ヌケ」がポロポロと発見されます。一昔前の私であれば、「何をやってるんだ」っと注意していたかもしれません。しかし今日は、「非機能的要求が未定義だからヌケが出るんだよ」と、作業を改善するためのアドバイスを具体的にすることができました。なぜこのようなことができたかというと、コンテキストモデルを部下に作らせていたからです。

　今回の案件は、A社製の複写機をB社製に変更する、というもので、（IT関係の専門知識が不用という意味で）一般的な業務と私は認識しています。難易度も高くはないので、部下に任せていました。しかし、ひとつだけ注文を付けて、「この業務のコンテキストモデルを作っておくように」と指示してありました。

　そして今日、部下からの報告に対して「これは？　あれは？」と質問をすると、ヌケが散見していることが確認されたので、取り敢えず、もう一度良く確認するようにといって打合せを終わりにした後、部下の作ったコンテキストモデルを確認しました。
　部下は、コンテキストモデルと要求モデルを作成していました。このふたつのモデルがあるのに、どうしてヌケが起こるんだろう？　よく見ると、機能的な要求はモデル化されているのですが、非機能的な要求が完全に欠落しているのです。なるほど、要は、もう少し早い段階でモデルをレビューしなかった私の「ヌケ」だったのです。

　今回の案件の機能的要求は、
　A2がコピーできる、とか、A4を毎分何枚コピーできる。
　というようなものです。

　非機能的要求は、
　複写機の入れ替えは通常業務時間外に行う、とか、設置スペースは十分か？
　というようなものです。

　これらの要素をモデルに表現できていれば、ヌケが散見することはなかったはずです。しかし、今回のなによりの収穫は、このような業務においてもコンテキストモデルと要求モデルが効果を発揮できるということです。つまり、ヌケの原因を明確に私と部下は知ることができたのです。

　コンテキストと要求のモデルを作るということは、問題の対象とアクターを抽出し、それらの振る舞いを規定することです。これができていれば、その後の作業（今回であれば、機種を選定する、見積をとる、段取りを組む）は漏れなくスムーズに行えるはずです。

　今日の収穫をもとに、ある程度の複雑性（それがどの程度のものであるかは今は分かりませんが）を持った業務に対しては、必ずコンテキストモデルと要求モデルを作成することにします。