近年、モデルが普及してきたのでしょう、業務プロセスモデルや概念データモデルを作成することが当たり前になってきました。
先日、あるプロジェクトで作成した業務プロセスモデルと概念データモデルをみせてもらいましたが、何か変でした。「今はどのフェーズですか？」との質問に「基本設計です。業務要件を固めるフェーズです」との応え。「う〜ん」なんと反応して良いか困りました。
その業務プロセスモデルは、時間の流れとともに、ユーザが使う画面名や帳票名が並んでいます。我々が論理組織と呼んでいる要素（組織機能名あるいはロール名）もきちんと出ています。表現形式はアクティビティ図のような事務フローのような・・・。
この図を見て私が一番驚いたのは、コンピュータとユーザの関係しか表現していないことです。組織Ａと組織Ｂと組織Ｃの間で情報のやりとりがあるはずなのに、何も書かれていません。コンピュータとは関係ないからです。
今度は概念データモデルです。企業という管理対象が、「企業エンティティ」「顧客エンティティ」「取引先エンティティ」に含まれるのに、モデル上では全く表現されていません。この３つが無関係に置かれています。業務的意味の構造を表すよりも、コンピュータにもつことになるファイル構造を表しています。
このようなモデルが、今回テーマとした「ソフトウェアの中から実世界を覗くモデル」です。
ここで表面化していることは、フェーズがモデルに期待する内容すなわちモデルのもつ目的と、実際に表現されている内容との大きなギャップです。もう一歩踏み込めばシステム開発方法論の「前提」「コンテクスト」を正しく理解しないまま、その方法論を適用しているという事実です。
私は強く思うのですが、「業務改善プロジェクトの一部としてシステム開発が位置づけられる」という前提でシステム開発方法論があるべきです。
業務設計フェーズは、組織の権限や役割・実際に行う業務の内容が変わるのだから、このフェーズのモデルはユーザ間のコミュニケーションツールとして使われるべきです。
そして、業務設計フェーズで一番重要なのは、「業務課題の検討・解決策の決定」であり、参加するメンバの「合意形成」です。画面の紙芝居をいくらつくっても、「これで業務が良くなる」という手ごたえは得られません。
概念モデルは、ソフトウェアの中から実世界を覗くモデルであってはいけません。そして、人の気持ちを理解し、人と業務課題を中心とした「業務設計フェーズ」を、方法論の中に正しく位置づけてほしいと願っています。
« エンティティの分類アーキタイプパターンとデータモデルパターン »
