プログラムで会話する奴とUMLの必要性とフォロワーの現れないオープンソースソフトウェア

図示のパターン

情報組織管理論の講義に遅刻した。前回の講義を丸々サボって（寝過ごしたのですよ）いたため全く内容についてけん。

講義に出たところでは、丁度ミーリー型とムーア型の状態遷移図の説明がなされていて、最後のまとめでどうやらここまでの間に「自動機械の内部処理の表現法」として「図的表現」「ブロック図」「フローチャート」「ネットワーク図」「状態遷移図」の5種類を扱ったらしいことが分かったのだけれど、説明を聞いた「状態遷移図」と中学時代にやった「フローチャート」以外がてんで分からなかったというのが今日の要旨。

Google で検索してみたり研究室の方に教えてもらったり教授に直接教えて貰ったりで色々あって、以下のようなことが分かった。

• 図的表現とは、 IDL 定義のように中で何をやっているかは考えずに入力パターン・出力パターン・パラメータを列挙するもの。
• ブロック図（ダイアグラム）とは、処理装置を具体的なデバイスあるいはモジュールの集合体と捉えて、それらの間の物・情報のやりとりを神の視点で図示するもの。
• フローチャートとは、利用者から見た時のひとつのタスクについて処理の始まりと終わりを設定し、その間の抽象的な処理内容を図示するもの。
• ネットワーク図（ダイアグラム）とは、処理装置の取る状態について始まりと終わりを設定し、始まり＝初期状態からいくつかある中間状態を経て終わり＝終了状態（＝次の初期状態）に辿り着くまでの流れを図示するもの。
• 状態遷移図とは、処理装置の取りうる状態を列挙して、外部からの入力をトリガーとして起こる状態の移り変わりとその時の外部への出力を神の視点で図示するもの。始まりも終わりもなく（強いて言うなら、作り出された時が「始まり」で壊された時が「終わり」か）、ただいくつもの「状態」があって、その中を順次移り変わっていくという、処理装置の在り方を表現する。

でもテストに出るのはフローチャートと状態遷移図くらいらしい。なんだよ、焦る必要なかったんじゃないか……

ところで、このような「処理の流れの図示」が何故必要なのだろうか。プログラミングの現場の人の言葉で、よく「フローチャートなんて時代遅れだ」とか「直接コーディングしていくのが今風」とか「いやいやフローチャートをしっかり作らないとやっぱりいかん」とかそういう発言を目にするけれど、何故図示する必要があるのかというところから考えてみたい。

コミュニケーションツールとしてのプログラム

フローチャートの役割は二つある。一つは言うまでもなく処理の流れの全体像をイメージ的に表現すること、もう一つはプログラムの内容を伝えることだ。初期のコンピュータは使えるリソースが限られていて、変数名一つとっても自由につけることのかなわない、そういう時代があった。紙テープに穴を開けただけという時代すらあった。プログラムを見ても、書いた人の意図が全く分からなかったわけだ。（今でも、変数名を英字一字にしていたりダラダラと命令を書き連ねたりした「汚いプログラム」は溢れている。当時は、そういう「汚いプログラム」が当たり前、というより、「汚いプログラムにならざるを得なかった」。）それ故、プログラムの内容を共通語で他の人に伝える役目をフローチャートが担う必要があった。

ところが今や、変数名の制限は極めて緩くなった。中には日本語を使える物すらある。コメントもふんだんに盛り込めるようになった。どこかで「英語圏の人間はまるで自然言語のようにプログラムを読み書きする（バグ発生を避けるコーディングテクニックよりも、自然な読みやすさを重視する）」という話を見かけたけれど、プログラムの内容はプログラムを読めば分かるというのが今の時代の常識なのだ。そういう意味で、フローチャートの二つの役割のうち一つはもう失われてしまったと言っていい。

英語が分からない人は日本語訳を手元に置いておきたがり、英語が分かる人は原文をそのまま読む。それと同じように、プログラムが読めない・読めないプログラムしかない場合は別途自然言語で解説を作り、プログラムが読める・読めるプログラムの場合はプログラムのソースコードしか（後はコメントくらいしか）残さない。プログラミングの制約が緩くなったことと、生まれた時から家電製品やゲームに親しんでいて「よりコンピュータやプログラムに近い世界のルールで物を考える」ことに慣れた世代の増加がこの傾向を生んだと僕は考える。

それ以外にも、フローチャートを使うことのデメリットはある。フローチャートとプログラムの二つを平行して作成するのは大変面倒だ。プログラムを書き換えたらフローチャートも一緒に書き換えないといけない……となると、まったく億劫でしょうがない。また、プログラムが複雑だったり大規模だったりするとフローチャートの書きようがないかもしれない。こういういくつもの要因が重なった結果、フローチャートが廃れるのも当然といえば当然だろう。

図示の必要性はまだある

しかしもう一つの役割、すなわち「処理の流れをイメージ的に表現する」という機能を忘れることはできない。

プログラムを書く人は常に頭の中に「プログラムの動作」のイメージ、メンタルモデルを持っているが、多人数でのプログラム開発ではそのメンタルモデルをいかにして共有するかが重要だ。それに失敗してしまうと、互いの意思疎通が図れず開発は破綻してしまう。

ミーティングを繰り返して互いのメンタルモデルを確認しあうのもアリだろう。しかしこれは時間と手間がかかりすぎる。オブジェクト指向のプログラミング手法などはプログラムそのものがメンタルモデルを表現するというアプローチだ。ソースコードとフローチャートを平行して作るような手間が要らず、しっかり考えてソースコードを書きさえすればよいので、これはなかなか優れた方法ではないかと思う。しかし、そういう「記述されたメンタルモデル」があっても、「読んだ者」が頭の中で正確に再生できなければ意味がない。文章、ソースコードレベルでの解説では、まだ誤解の余地がある。

だから、様々な処理が雑多に書かれたプログラムのソースコードそのもの以外に、メンタルモデルの構築を助けるためだけに別途何かを用意しないといけない。オブジェクトのインターフェースの情報だけを書いたIDL定義もその一つと言える。しかしそういったものの中でも、誰にもほぼ確実に意図が伝わるのはやはり図だ。「 UML 」が重要視される理由はおそらくそこにある。（参考：5分で絶対に分かる UML ）

独りよがりなプログラミング

プログラムには二つの役割がある。それを実行して結果を得るという「自動機械」としての役割と、処理内容を他の人に伝えるという「コミュニケーションツール」としての役割だ。

多人数でのプログラム開発、特にオープンソースのような開発形態では、プログラム自体が参加者間の共通言語となり得る。「読みにくいコード」「汚いコード」「コーディングルールを守っていないコード」が嫌われるのは、「悪文」「汚い字」が嫌われるのと同じことだ。

ただソースコードを公開するだけでは、他の人はメンタルモデルを構築できないから、何も手を出せない。僕の公開している拡張機能について協力者が現れないのは偏にそのせいだと言える。「誰も協力してくれないよウワァァァァンと嘆く前に、まずは我が身を振り返らなくてはならない。