フローチャート図はそもそもプロセスを判断条件も付け加えながらわかりやすくしたものである。分かれ道がありつつ、それを説明するべく、フローチャートには守るべき約束事がある。 しかしながら、「あなたは実はこんなタイプ？！ チャートで見つけてみよう！」といったチャート図なんかもあったりして、それがまちまちな気がする。 覚えるのが嫌いな私も、分かりやすく作るべく、いくつか守っていることがある。それを以下にまとめておく。

• 約束事その１：処理は□、判断は◇
• 約束事その２：何事も「はじめ」と「終わり」が肝心
• 約束事その３：水の流れは上から下へ、時間の流れも上から下へ
• 約束事その４：本流を作るべし
• 約束事補足：分岐は「～である」という文章で

約束事の前にフロー・チャート・フローチャートの違いとは？

ところで、フローチャートフローチャートって言っているけれども、「フロー」と「チャート」の二つの言葉が含まれている。そもそもこの二つはどういう区別がされているのか、と不思議に思ってウェブで簡単に検索してみた。しかし違いを説明した資料は見つけられなかった。 しかしながら、UMLで「ステートチャート図」と使われていることから想定し、以下のように「フロー」と「チャート」を区別する。

• フロー → 流れを表現するもの
• チャート → 分岐を表現するもの

そして、上記の「流れ」と「分岐」を合わせて表現するものとして「フローチャート図」と定義する。定義したところで、詳細を見てみよう。

約束事その１：処理は□、判断は◇

フローチャート図は、大きくわけて、二つの振る舞いがある。一つは処理、もう一つは判断。処理とは、作業することである。判断はそうではなく、YesかNoか、といったような一つの答えを導くものであり、作業は発生しない。 これを図形で区別するのがフローチャート図なんだが、区別せずになんでも□を使っているのを見かけたりする。しかし、それではいかん。何のために図をして、分からしむるのかわからない。 ちなみに、全ての処理を□で表示していると、その□の中を理解するのに、以下のような手順を踏む。

1. 文章を読んで、中身を理解する
2. 中身を理解し、それが処理か判断かを、判断する

これは面倒である。□と◇を区別して描くことで、2番目の処理がカットされるのだ。

約束事その２：何事も「はじめ」と「終わり」が肝心

キリがいいのは、分かりやすさの特徴である。フローチャート図もそのキリのよさをはっきり見せ付けなくてはいけない。そこで、「はじめ」と「終わり」をはっきりつける。 通常、フローチャート図はそんなこと言われなくたって、わかる場合があるが、そうでなかったりもするし、見る人によってはわからなかったりするので気をつけよう。

約束事その3：水の流れは上から下へ、時間の流れも上から下へ

フローチャート図の中で、「↑」のような上向き矢印を見かけることがある。しかしこれはいけない。というのも、フローチャート図は、暗黙の了解がある。

上から下へ処理は流れる

水だって、何も力がかからなければ上流から下流へ流れるものだ。流れに逆らうのは鮭に任せよう。 でも上部に戻る分岐だってあるよ！ そんな場合はどうしたらいいのか？ そんな時は上向き矢印が出ないように、□を配置するのである。それができなければ、少なくとも「→」や「←」といった横向き矢印を使うようにしよう。それだけで、フロー図の気持ち悪さがちょっと緩和される。

約束事その４：本流を作るべし

分かりやすいものには幹があり、本流がある。フレームワークも骨組みであり、大きく捉えれば幹の一種とも言えるであろう。フローチャート図にも、この幹は必要であり、スタートからエンドまで、正常パターンを見せ付けるべく、本流としての一つの流れを用意しておこう。 これは、開始から終了まで、1直線の処理を作ることで幹が作成される。これだけで、どの道筋が本来なのかが、理解しやすくなる。

約束事補足：分岐は「～である」という文章で

さて、先ほど出てきた判断であるが、たまにこんな判断の説明だったりすることがある。

「○○がＡであるかそうでないか」 判断は「Yes」か「No」かに二つに分かれている。

さあどっち？ といいたいところだが、文章からYesがどっちか分からない。

対処方法

対処方法としては二つのやり方がある。

1. 分岐の文章を「○○がＡである」に変える
2. 分岐条件の「Yes」「No」を「Aである」「Aでない」に変える

勿論、2番目の方法でも構わないが、「Yes」「No」にしておくと、図形をコピペしたり、条件が変わった時に変更しなくてもよかったりと、後々便利である。だから1の方を薦めておく。 しかし、これは別にわかりやすければ守る程でもない。分かりさえすればよいのだ。

望ましいフローチャート図

日本運搬機械株式会社さんの「火災時管制運転装置運転フローチャート」がとても分かりやすく、上記の約束事に準拠していた。スタートとエンドが区別され、上から下に流れており、処理と分岐は図形と色でクリアに区別され、スタートとエンドが同じラインで配置されて本流が分かりやすくなっている。 このように、クリアにチャートがまとめられていると、火災の時にも安心して実行している様が伺えるというものである。

http://blog.shibu.jp/article/28983162.html

上で渋川さんがプログラミングについてまとめてたので、何かしらプログラミングで言いたいなーと思ってしまったので、今やってるプログラミングの作業順番をまとめておきます。

私はもともとjavaのプログラマでした。ブログのタイトルはその名残です（小文字始まり・4使用）。プログラムめんどいよ～仕様決める仕事がいいよ～、と思ってPMにジョブチェンジしました。粒度が合わなかったんですね。それはさておき、今回の自動化作業のだいたいの作業の順番について。

今回のお仕事

お題：ウェブサービスの運営で、定常作業を自動化するのに、perlでプログラミングを組むこと。

ゴール：他の人がそれを使って作業を実施できること。問題があっても他の人がメンテナンスできること。何かあったら他の人が改変しやすいこと。

とゆーよーな感じのお仕事です。

作業手順

1. 定常作業から作業項目を洗い出す
2. できるところからプロトタイプ
3. ２を繰り返す
4. 標準化
   1. conf設定対応
   2. IF統一
   3. ログ追加
   4. 定数化作業
5. 資料作成

以下詳細。

１．定常作業から作業項目を洗い出す

もともと手作業でやってたのを自動化するので、もとあった手順書からプログラミングすべき作業を洗い出します。この時点で作ろうと思う関数は洗い出しされてます。設計がないと、ここで抜けもれが発生しました（例：conf設定対応とログ）。

２．できるところからプロトタイプ

プログラミングも久しぶりだし、perlも手馴れてないんで、できるところから書いては実行です。動いているので安心感があります。この時は面倒なのでファイル1枚で実行し、関数を増やすといった感じ。

３．２を繰り返す

必要な関数を増やします。で、一通りできたら、それを使って手順書通りに実行する関数を作ります。正直ここで終われるものなら楽です。

４．標準化

私のやる気ナッシングな領域に。

４．１．conf設定対応、テンプレート対応

設定ファイルは外部化します。xxx.confとかそんなファイルから読み込めるようにしておきます。使いまわしする予定があるのでー、ファイルと同化してるとダメなんです。

テンプレート対応とは、conf設定やtmplファイルに、テンプレート変数を使っていたので、それの対応もしました。これは、confファイルで、出力ファイル名を”xxxx-$today_yyyymmdd.xls”とか設定しておくと、自動的に”xxxx-20090511.xls”とかに変更してくれるような仕組みです。

ここらへんで、ファイルを分割してライブラリ専用ファイルを作りました。

４．２．IF統一

上記との兼ね合いもあり、再度関数のインタフェース（引数とか返り値とか）を見直しです。

４．３．ログ追加

ここでようやくログ追加。

４．４．定数化作業

文字列排除。今作業はここらへん。今思ったけどやっぱり徹底的に文字列は排除しよう。。

５．資料作成

で、上記の設計をまとめた資料を作る予定。

• 概要設計 – ツールの目的、ゴール、ユースケースがあると便利（使い方のイメージつくから）
• 外部設計 – 枠決め。関数のインタフェースと機能を決める。シーケンス図があると便利。
• 内部設計 – 中身決め。関数の中身を説明する。アクティビティ図。
• 実装設計 – 実装決め。どのファイルにどの関数を入れるか。設定ファイルはここら辺で書くと思う。
• 使い方説明 – 使い方。修正方法等。

後残ってるのが、ログの説明ぐらいか。。どこに組み込もう。

総論

perlもプログラミングも昔とった杵柄レベルであまりに慣れてないので、今回はプロトタイプの作成から始まりました。しかし、時間がかかりすぎるのが難です。

なぜなら、あとから追加項目が多いから。毎回変更したら、ちゃんと動くかどうかテストするのが面倒だから。なんにせよ、手戻り作業が多すぎるです。

今回は、プログラム自体は2ファイル程度（設定ファイルは10ファイル前後）の成果物でしたのでなんとかなってますが、時間のことは関係しなくても、他人が使うことを想定すると、やはり設計は必要です。とはいっても、自分が使うにしても、やっぱり設計は必要だと思います。なぜなら、3ヶ月前の自分も赤の他人だから。

でもね、プロトタイプは最初は楽しいんだよねー。

まぁあれですね、他の人に共有すること前提なら、プロトタイプからのプログラミングは、あんまり合わない、ということでした。

ソースがきれいとか構造がきれいとか

ソースがきれいとか構造がきれいとかありますが、私の昔の感想は以下のような感じでした。

作った直後の私は、自分のソースはきれいと思ってました。他人のはきれいかそうでないかというか、読みにくいな、と私は思うのでした。理解の粒度は違うのでそれはしょうがないんですな。そして、数ヶ月後の私は、自分のですら汚い読みにくい何コレサイテー！と本気で思うのでした。

 

自分コメント

• 勢いでやった。後悔はしてないけど、文章に責任はもてずにすぐお蔵入り。
• ていうのと、どのライン用なのよ、というのがあって、やっぱりお蔵入り。