「いやあ、図解は苦手なんですよ。絵心がなくて」──

 ITエンジニアの方に寄稿を依頼し、記事中の図をPowerPointなどで作ってもらうと、決まって出るセリフである。この人が書く記事なら読者ニーズが高いと考えて寄稿を依頼するのだから、エンジニアとして一流どころか、日本のIT業界を代表する超一流もいる。それでも、冒頭のようなことを言われるケースが圧倒的に多い。言葉の行間を補うと「自分は理科系なので、畑違いの芸術的センスを求められても困る」ということなのだろう。

 はっきり言おう。大きな勘違いに基づいた、悲しい言い訳だと思う。寄稿執筆を含め、ITエンジニアに求められる図解力は決して絵心のような芸術的センスではない。ITエンジニアの中核スキルの一つ、物事を分析して構造化する「モデリング力」である。図解は苦手と言い訳するのは、構造化分析やモデリングができない、と自己否定しているに等しい。

図解の本質はモデリング

 図解とはモデリングであると確信させてくれたのは、国内きっての図解のプロ、チューブグラフィックスの木村博之氏(代表取締役)である。記者は2002年からの付き合いで、木村氏が書いた図解の連載記事の企画・編集を何度か担当してきた。残念ながら、記者の芸術的センスは乏しい。学生時代の美術の成績は中の下というところ。それだけに、連載記事の編集過程で、木村氏にしつこく食い下がって教えを請うた。そうして記者が理解した図解の本質は「メッセージが伝わるように構成要素をモデリング(構造化)すること」だった。そこには、業務・システム設計のモデリングとの共通点が多い。

 共通点の例を示す。図解には二つの大きなパターンがある。流れを表す「動的パターン」、関係を表す「静的パターン」だ。

 動的パターンは、手順、プロセス、スケジュール、遷移などを矢印を使って表したもの。「業務フロー図」が代表格の一つだ。静的パターンの代表格としては、問題のある状態と解決された状態を横に並べた「Before-After図」、組織体制などを表す「組織関係図」が挙げられる。

 勘の良い方はもうお分かりだろう。業務・システム設計の「動的モデリング」と「静的モデリング」と同じである。UML(Unified Modeling Language)でいえば、アクティビティ図やシーケンス図で業務や処理の流れを表すのが動的モデリング。静的モデリングは、役割や機能を表すクラスをつないでクラス図を作ることである。

 図解もモデリングも構造化であるし、そもそも業務・システム設計のモデリングは図解の一種と見なせる。そのため、どちらも動的と静的に大別できるのは当然といえる。ただし、似ているのはそれだけでない。作成の過程に、分析ステップが必須なのも同じである。図解における静的パターンのBefore-After図だと、次のようになる。