少し大仰な前置きとなってしまいましたが、基本的なスタンスとしては「非定型図式は誤解を与えることが多い。定型図式が使えるときは定型図式を使い、定型図式が使えない場合に限って（仕方なく、かつ慎重に）非定型図式を使う」ということで良いと思います。
非定形図式はフォーマットが決まっておらず、描く人によって表記ルール（例えば線の種類、矢印の向き、文字の囲みの形に与える意味）が異なるため、これを読み解くためには「表記ルールを理解」したうえで「描かれている内容を理解」する必要があります（2つのステップを踏む必要がある）。一方、定型図式では表記ルールが決まっているため、描かれている内容の理解にのみ集中できます。違いはたった1つのステップの有無ですが、コミュニケーション・ロスの発生ポイントを減らせると考えれば、たった1つのステップでも省けるのは実に嬉しいことなのです。
以上を踏まえ、私が普段から心掛けているのは、「定型図式の適用範囲を広げる」ことです。具体的には次のようなことを実践しています。
- 定型図式の表記ルールの習得
- 定型図式の描画ツールの習熟
- 自分が習得した定型図式の普及
ここで結構重要なポイントが3番目の「自分が習得した定型図式の普及」です。どんなに頑張って図式を描いても、それを理解できるのは自分だけ、という状況ではまったく意味がないですからね。有用な定型図式については周りにどんどん広めて行きましょう。
と、このように普段から定型図式の適用範囲を広げておいても、やはりどうしても非定形図式で表現せざるを得ない場面はあります。例えば以下のような場面です。
- 自分が習得している定型図式では表現できない
- 自分が使いたい定型図式の表記ルールを、読み手が知らない（かもしれない）
このようなときには、十分に注意して慎重に非定型図式を描くしかありません。しかし上述した通り、これはなかなか難しい。非定形図式を描くための系統的な知識があまり普及していないこともその一因だと思います。少し遠回りになってしまいましたが、第6回mixbeatワークショップはここを出発点にしても良かったのではないかと考えました。
ちなみに、非定形図式を描くポイントはいくつかありますが、前回もご紹介したウルシステムズの林氏による「ポンチ絵の描き方」は非常に参考になります。
最後にちょっと余談。システム開発の歴史は、コミュニケーション・ロスとの戦いの歴史と言っても過言ではないくらい、多くの人がコミュニケーション・ロスを減らすことに心血を注いできました。そしてその歴史の中で、非常に有用な定型図式がいくつも開発されてきました。私はこうした定型図式のうちのいくつかは、一般的にもかなり有用だと考えています。私が技術者以外の方にもお勧めしている定型図式は、UMLユースケース図、UMLシーケンス図、そしてUMLクラス図の3つです。これらは技術者以外の方も習得しておいて損は無いと思います。特にUMLクラス図は素晴らしく、これ（とオブジェクト指向）に習熟するとほぼどのような「もの」でも表現できるようになり、さらには複雑な物事の整理や分析にも役立てられるようになると思います。