PlanningFlow3（以下、Pf3） は、JIS や ANSI に制定されたフローチャート記号のほとんどを用意しませんでした。 それは思うところがあったからで、プログラムフローチャートのサンプルにこんなことを書いています。

本職のプログラマーの方は、「ずいぶん簡素だな」 と感じるかも知れません。
PlanningFlow3.0 が用意した図形は、□， ◇， 「端子」 の三つのみ。 ＪＩＳの定義の多くは取り入れていませんし、 「書類」 「データ」 「画面表示」 といったポピュラーな図形も取り入れていません。

開発中、その昔、就職した会社でもらったテンプレート定規を見つめてみました。 「パンチカード」、「紙せん孔テープ」、そして、一度も使った記憶のない図形たち．．．　 一体こんな図形、今でも使われてるの?
でも、Microsoft Office も、Visio も、それらを用意している．．．

indysoft のメンバーにアンケートしたところ、これまた回答がまちまち。
共通していたのは、シンプルを心掛けている点。 そして、いたずらに見慣れない図形を使って、見る者を不安にさせまい、という配慮。

”□，◇，「端子」の三つのみ”　が良いかどうかはわかりません。
ただ、ＪＩＳの図形をすべて用意するのが良いとも思えません。
ご意見ありましたら、お寄せください。

そして、丸２年の間に、10人ほどの方から ご意見が寄せられました。
なんという関心の高さでしょうか。（笑）

＋　＋　＋　＋　＋

寄せられた意見のほとんどは、「ループ端」 が欲しい、というものです。
これは失敗したと思いました。

「ループ端」 は、JIS の 1986年の改訂により、新しく追加されたものです。 ◇ で描くループはごちゃごちゃするので、すっきりさせるために採用されました。 この記号を使うと、フローがとてもすっきりします。

ループ端で描いたループ

ただ、この記号。　わたくし、習っておりません。
1986年の改訂だから、当時、現場では使ってなかったわけです。
で、研修のときは、現場の先輩から、現場で描いてるフローを習うわけだから、教わらなかったのです。

その後、一応、存在は知りました。 自分が新入社員を教える立場になったとき、フローチャートの教本に載っていたのです。
でも、同僚と、
「どする?　これ教える?」
「でも、現場じゃこんなの使ってないよ。　混乱するぞ。」
なんて話になって、さらっと触れるだけで、描かせませんでした。

で、相変わらず、自分たちは、◇ のまわりを、ぐるぐる線が回るフローを描いていました。 そもそも、フローチャートの書き方は、ある程度は仕込まれましたけど、ディテールはずいぶんと自由だった気がします。 現場の関心はそれほど高くなかった。
理由は２つあったと思います。

・当時のフローは （納品物件であっても） 手書きだった。　各人が手で書くのだから、自然とばらばらになる。

・プログラムフローがだんだん書かれなくなっていった。少なくとも正式な成果物の座からは降りていった。
各人が、個人的に思考の補助として使うようになっていったので、標準化の対象からもはずれていった。 （標準化の関心は、HIPO （ハイポ） などの、”書式を統一された仕様書” に移っていた）

だから、いよいよ 「JIS の最新の書式はどうなってる?」 なんて意識はなくなっていきます。 情報処理技術者試験 でも受け続ければ、違ったかも知れませんが。

Pf4 の開発中、初めてでしょうか。いろいろと 「ループ端」 を使ったフローを描いてみました。
いや、便利ですね。（笑）
線がすっきりするし、流れがまっすぐになって、幅を取らない。
慣れたら絶対これです。
馬鹿なことをしたなあ、と思います。

Pf3 のプログラムフローの自動線画なんて、ほとんどの工数は、ループの判定と座標計算にかかったようなものです。 「ループ端」 を採用して、あんなのやらなければ、どんなに楽だったか。
まあ、「ループの線の形をこうしてくれ」 なんて意見も来ましたから、 僕のように相変わらず 、ぐるぐるループの線を描いていた人も多いのでしょう。

それと、無敵の 「ループ端」 にも、一点だけ弱点がある。
プログラムフローチャートは、プログラマーだけが読めるのか、それとも現代人ならば誰でも読めるものなのかは、 意見の分かれるところでしょう。　「描き方による」 というのが、僕の今のところの結論です。
で、□ と ◇ だけで、ループの線がぐるぐる回る描き方だと、たいてい誰でも読めるようです。 そこに 「書類」 や 「画面」 の記号を使うと、読めなくなっちゃう。 記号の意味を知らないから、不安になって、つっかえちゃうわけですが、 「ループ端」 も、これは習わないと、何の記号だかわかりません。
ちゃんと勉強しないと読めないという意味で、万人向けではないなあと。　その点だけは弱点に思いますね。 （ループの自動線引き。 大変だったけど、まあ、作っておいて良かったのかも）

＋　＋　＋　＋　＋

さて、JIS の記号ぜんぶは揃える気はない、と言っていたのですが、Pf4 では結局、ほとんど全部揃えました。
何故かと言うと、切るのが難しかったからです。 フローの描き方って、みんな まちまち じゃないですか。

データと記憶データの描き分け

好みや癖で使ってる。　切るのは不可能と思いました。

原典に当たった、ということも大きいです。
まだ、厳選しようという気持ちが少し残っていた頃、好みや癖に振り回されないためには、原典を入手しようと思った。 でも、近所の大きな書店で尋ねたら、「JIS の規格書は在庫しないことにしているんですよ。注文は承りますが。」 と言う。 注文て言ったってあなた、JIS の規格書のタイトルなんて、わかんないっつーの。
インターネットでも、タイトルだけなら検索できますが、内容が閲覧できるようにはなっていません。

だから、赤坂の JIS協会に行ってきました。
規格の正式な分類、規格書の内容、そのタイトル、がわからなければ、先に進めない。

こういうときは東京は便利ですね。 僕は田舎暮らしが好きですし、情報や決済といった面では、地方格差のまったくない世の中が来ることを望んでいます。
インターネットや携帯電話の登場で、格差は縮まりました。 パソコンのカタログなんてネットで見てしまうし、携帯の電波さえあればライセンスの発行も可能です。
でも、まだ時々、やっぱり東京、と感じるときはありますね。

案の定、『フローチャート記号』 なんてタイトルの規格書はないのです。
正式な名前はこうです。

『情報処理用流れ図・プログラム網図・システム資源図記号　JIS X 0121 - 1986』
-- Documentation Symbols and Conventions
　　　　for Data, Program and System Flowcharts, Program Network Charts and System Resources Charts --

本職のプログラマーでも、”プログラム網図” って何?　と思う方は多いでしょう。
JIS の規格書は、基本的に ISO の翻訳で、だから ISO での世界各国の意見が反映されるのだそうです。 Program Network Chart　をよく描く （または当時描いていた） 国があるということですね。

また、紛らわしい名前の規格書もあります。

『計算機システム構成の図記号と用法　JIS X 0127 - 1988』
-- Computer System Configuration Diagram Symbols and Conventions --

やっぱり、タイトルだけでは、中身がわからない。

さて、原典を見てしまうと、いよいよ切れなくなりました。
どれも意味を与えられて決められてある記号なのだから、使わないかも知れないけど全部入れようと。

でも、原典に当たると面白いですね。
それまでずっと、「記号が重複してんじゃないの?」 と感じていたのですが、 それはいい加減に重複していたからじゃなく、フローの詳述の度合いにより使い分けられるように、階層化されていたからです。
ツリーにすると、一目瞭然です。

フロー記号のツリー図

また、ずっと抱いていた疑問も解決しました。
クラリスインパクト というビジネスグラフィックスソフトがあります。 （旧クラリス製品は、今アップルが引き取ったんでしたっけ。どうなってるか知らないんですが。）
それの 「JIS フローチャート記号」 のパレットの並びがどうにも不可解だった。
こういう順番なのです。

クラリスインパクトのパレット

使用頻度で並べたら、こうはならないでしょう。
□ や ◇ や 「ループ端」 が先に来るはずです。
なんでこういう並びなんだろうと、ずっと不思議だったのですが、 これ、JIS の規格書の表記順じゃないですか。（上のツリーと照らしてみてください。）
真面目な人たちですよ。きっと。

あるいは、原典通りに並べておけば文句は来ない、という判断なのかも知れません。 確かに、フローチャート記号だけじゃなくて、回路図だの、配線図だの、いろいろな原典からパレットを作ったら、 いちいちユーザー感覚で並べ替えるなんて、やってられないかも知れないです。

＋　＋　＋　＋　＋

『計算機システム構成の図記号と用法』 の内容もツリーにしてみましょう。
こちらは、ハードウェアやネットワークの構成図の規格です。

システム構成図の記号のツリー図

見ていて思うのですが、古くないですか?
これらの記号を使った書類を、今も書いている人はいるのでしょうか。

システム構成図の電話機の記号　が 「電話機」 なわけです（ トンパ文字ではありません）。 でも、そう思わない人、けっこう居ると思います。
今、システム構成図で、「電話機」 をどう描くかといったら、 電話機の絵　と描くでしょう。 具象してしまうのです。 ビジネスグラフィックスソフトの登場により、瞬時の具象が可能になっていますから。

この規格のジャンルは、ビジネスグラフィックスソフト（以下、ビジグラ） の登場により、取り崩されてしまったように思います。 昔は手書きで、具象に限界があったから、こういう規格が活きていたのでしょう。 でも今は、これらの記号を手書きするのと同じか、もっと短い時間で具象することが可能です。

具象のいいところは、見栄えが綺麗なこともありますが、それを書く人、見る人に訓練が要らないことが大きいです。 誰でも理解することができる。
システム構成図の電話機の記号　が、「電話」 だと学ばなくて良いのです。
試しに、この規格で描いた システム構成図 を提案書に付けて、見込み客の社長に見せたらどうなるでしょうか。 めちゃめちゃ心証悪いだろうし、プレゼンに時間がかかってしょうがないと思います。

＋　＋　＋　＋　＋

プログラムフローチャートは、今でもよく手書きします。
（ただ、丁寧には書きません。 凄まじいスピードで書きなぐります。　ひどいときは、朝書いた字を、夕方自分で読めないほど。）
なぜ、プログラムフローは、手書きするのだろう?
システム構成図との違いを考えてみます。

・ プログラムフローは、「処理」 とか 「判断」 とか、もともと形のないものを書き表している。

・ 記号が □ とか ◇ で、単純。手書きでも速い。　ビジグラのありがたみがない。

・ プログラムフローは、素人には見せない。　エンジニア同士でしか見ない。エンジニアは □ や ◇ の意味を知っている。

・ とはいっても、（業務マニュアルとして清書した形でだが） 事務班には見せている。
ウチの事務班はエンジニアじゃないし、あの記号の意味を説明したことも一度もない。けど、質問してきたことも一度もない。 そういえば、□ と ◇ しか使ってない。 「データ」 だの 「書類」 だの、いろいろ記号が出てきたら、きっと読めないのだろうが、 □ と ◇ くらいなら、なんとなくわかるのだろう。

・ プログラムフローは多くは自分だけのために書く。思考の補助のために書き、考えがまとまったら捨ててしまう。
市販のビジグラで作図するのは、とても時間がかかるから、そんなことのためには使わない。 対して、システム構成図は、提案書とか、人のために書く比率が高い。

道理ですね。
抽象で、簡単で、速く描けて、個人的なら、手書きするわけだ。
たぶん 10年経っても、プログラムフローの書き殴りはやってるだろうし、 プログラムフローに限らず、そういう性格のフローチャートやポンチ絵は、手書きされ続けていくでしょう。
逆の性格のものは、だんだん ”過去の物” になっていく気がします。

システム構成図 の規格は、JIS で、ISO で、今後もメンテされていくのでしょうか。

indysoft.jp 主宰
びーどろ