開米のドキュメント図解術駆け込み寺，第2回です。
今回は，「省略された静的構造を発見せよ」というテーマを扱います。
「静的構造」というと，オブジェクト指向に詳しい方はUML（Unified Modeling Language）の静的構造図を連想されるかもしれませんが，全く関係ありません。ではいったい何が「静的構造」なのか，まずはその話から始めましょう。
私がこの原稿を書いているのは10月1日，富士スピードウェイで30年ぶりのF1グランプリが開催された翌日です。そのレースについてのコメントの一つと思って下記のテキストを読んでください。
（1）クルマってのはね，エンジンとトランスミッションとタイヤが載ってるんですよ。
（2）エンジンのパワーをトランスミッションを通して伝えてタイヤを回すからクルマが動くんです。
（3）Aチームのエンジンはすごいハイパワーですね。だから直線がダントツに速いです。
いかがでしょうか。これがもしゲストに呼ばれた解説者のコメントだったら，非常に不自然ですね。小学校低学年の子供に向かって「自動車のひみつ」を語る席ならともかく，世界最高峰のカーレースを前にして（1）や（2）のような「自動車の基礎知識」を話すはずがありません。
ですから通常は，解説者は（1）（2）を省略して（3）のレベルの情報を話します。ここで省略された（1）（2）がつまり
静的構造
なのです。もっとも，厳密に言うと（2）のほうは「動く」という話ですから動的構造と言えます。ただし今回は静的と動的を区別する意味がないので，両方をまとめて「静的構造」の一言で呼んでおきます。
■静的構造を理解していなければ「状況」を理解できない
さて，（3）の内容は，ある静的構造を前提としてその上に発生した特定の「状況」であり「現象」です(図1）。
 |
| 図1●静的・動的構造の上に特定の「状況」が起こる 特定の状況には，必ずそれが前提としている静的・動的構造がある。しかしその「構造」は省略されることが多い。図解するときは静的構造まで掘り下げる意識が必要。 |
従って，本来は静的構造を理解していなければ「状況」を理解することもできません。ところが現実には前述の通り
静的構造の説明は省略される
傾向があります。その理由は，「静的構造はいつでもどこでも同じ話になってしまい，当たり前すぎる」からです。考えてみれば当然ですね。「クルマにはエンジンが載っている」なんて話，100年前から現在まで一貫して変わってませんし，今後も変わらないでしょう。こんな当たり前の一般常識をわざわざ言っても誰も感心してくれません。
だからといって，いつもいつも静的構造を省略していいわけではありません。例えば小学校低学年の子供に「自動車のひみつ」を語るようなときがその一例です。つまり聞き手の知識が「そんなん当たり前だろ」と言えるほど確立していない場合には，やはり静的構造をしっかり押さえて説明する必要があります。つまり
静的構造を省略してはいけない場合もある
ということです。容易に推測できるように，例えば「新技術の説明をするとき」は，まさにこの場合に該当します。
ところが実際には，これがなかなかできていません。静的構造は説明が難しいことが多いのです。その理由の一つは「静的構造は目に見えないことが多い」ということです。エンジンであれば車の内部に隠されてますし，ソフトウエアとなると，もはやデジタル化された抽象概念のカタマリです。
しかも，通常，「製品」を使うユーザーが求める教育には「静的構造」は含まれないことが多いものです。
例えば，車の免許を取ろうとする人が必要とする知識はこういうものです。
アクセルを踏み込むと加速されます
ブレーキを踏むと減速できます
ハンドルを右に回すと右に曲がります
これらはいずれも「車をこう操作するとこんな現象が起こる」という「現象」中心の操作方法の説明であって，静的構造は語っていません。あくまでユーザーに徹するならこの程度の教育で間に合ってしまいます。
しかし，くどいようですが，いつもいつもそれで事足りるはずがないのです。
ユーザーに余計なことを考えさせずに指示したとおりのことをやらせよう，というなら現象の説明だけでもかまいませんが，製品の動作原理を理解して臨機応変に対応できるエンジニアを育てたいなら，間違いなく静的構造まで掘り下げなければなりません。
おっと・・・そういえば第1回でもよく似たことを書きましたね。実際，第1回記事中の最後の図（図3●ユーザーの手順ではなく，データ処理の工程として考え直す）は「静的構造」まで掘り下げたものでした。
