要素３は、「責任・権限」です。
大企業の新規業務設計をご支援していると、「社内での調整ごとや軋轢に対して、多くの人がそれを避ける行動をとりがちである」ことに気づきます。トラブル等、言い争いの場面では「君の言っていることは筋が通らない」といった発言もあるでしょう。「筋が通る」というのは、「本来やるべき仕事を責任部署が実施する。」「担当なのだからそれにふさわしい発言・行動を行う」ことを意味します。
業務＝DOの部分だけ可視化しても、それでは業務の良し悪しを判断することはできません。「本来実施すべき部署が、実施すべきことを正しく行っているか」「責任と権限を少し変えることによって現状業務のどの部分が良くなるか」などが、DOを可視化した図面を使って議論できなければなりません。
その意味で、可視化すべき要素の３番目は、「責任・権限」です。Whoと言っても良いでしょう。Whoを表現するにあたって選ぶべき言葉は、個人を指す名称や個別の組織名ではありません。それは、論理組織名（あるいは役割名）です。
ＤＦＤにはいくつかの流派がありますが、たとえば初期のトム・デマルコのＤＦＤにはWhoが登場しないので、こういった議論ができません。ユースケース図も、アクターが表現されますが、アクター間の責任分担が理解できるレベルでWhoを表現しません。
ソフトウェアの構造をモデル化する立場と業務の構造をモデル化する立場は、区別しなければなりません。業務の構造をモデル化する立場、すなわちビジネスの世界をモデリングする場合、責任と権限が業務のあり方を支配しているという力学を知っている必要があります。
私は、働く人々の気持ちまで話題にしながら、新しい業務を設計すべきと思っています。我々モデラーが可視化すべきは、DOであり、Whoであり、DOとWhoの関係なのです。従って、論理組織（スウィムレーン・部署）などを表現できる、IPF・BPMN・事務フロー・アクティビティ図などの図表現は、いずれか１つを必ず採用しなければなりません。
