論理モデルでユーザとコミュニケーションをとるべし！

以前、「システム開発のできるだけ早期の段階で、モデルを利用したシステムイメージの確認（共有）を行うことが、リスクを回避するもっとも効果的な方法」だということを述べました。

イメージを調整するために、業務をモデル化（可視化）するためには、開発者にもさまざまな能力が要求されます。
ユーザが「こんなことをしたい」といった内容を咀嚼し、『システムが完成すると、こんなイメージになるます』という結果を見せて、意識あわせをしていくという作業を繰り返し実施する必要があります。

完成後のユーザが利用する画面や帳票のイメージを具現化することや、処理手続をフロー図化することがこれに相当します。

システムの完成形を事前に具現化する手法として、プロトタイピング手法があります。
プロトタイプ手法の効用の最たるものは、このユーザと開発者間のイメージの確認です。
実際に稼動するプロトタイプが、十分に早いスピードで提供できるのであれば、それにこしたことはありません。
しかし、プロトタイプの作成に工数や時間がかかるようでは、あまり意味がないのではないでしょうか？

逆に、イメージの確認が効率よくできるのであれば、プロトタイプにこだわる必要はありません。

また、複雑な処理や条件は、デシジョンテーブルに変換したり、絵や図を使って表現したものを独立した文書として作成し、互いに内容を確認していきます。

例えば、『値引金額の計算方法』などのような一連の条件や処理からなる約束事を、実際にどのプログラムでどのように実装するかを度外視して、本来どうあるべきか、という事実だけを具現化していきます。

実際問題として、このプログラムでの実装を度外視してという発想が重要です。

システム開発において、ハードウェアやデータベースの制限を加味して、プログラムを設計する作業は、大変な作業であり、時間がかかるものです。
プログラムの完成をまって、イメージの調整をしていたのでは、時期を逸しています。
打ち合わせに結果築き上げたイメージを、プログラム仕様書に表現していたのでは遅すぎるということです。（XupperのＧＵＩ設計機能では、その場でプロトタイプの定義を行い、イメージの調整を行うことができるようになっています。ちょっと、宣伝してみました。）

論理的であるということは、イメージに近いということです。
しかも、このイメージは適用業務上のイメージであり、プログラム的なものではありません。
従って、論理的なモデルは、ユーザにとって理解しやすく、開発者側にとっても設計作業を加えない分だけ早く作成でき、より正確にイメージの調整ができるわけです。