はじめに
どうもこんにちは、末端生技エンジニアのニコラです。
今日は
「フローチャート、毎回なんとなく書いてるけど、これで合ってんの…？」
というすべての生技・保全・ITエンジニアの方向けに、
TOPIX100に入るような大手JTCメーカーでも
「正直これだけ使えれば十分通用するよ」
という、「フローチャートの最小セット」を紹介します。
先に大事なことを言っておきます。
フローチャートに「正解」はありません。
ですが、私はこれまで
- 運用フロー
- システムフロー
- 仕様書向けフロー
をこのルールで散々作ってきて、
基準書として発行されてもクレームゼロでやってこれました。（クレーム ＝ 記号に対してのクレームね）
その経験ベースで「ちゃんと使えるやつ」だけ知りたい方だけ、読み進めてください。
前提：フローチャートの「正解」はない。でも「軸」はあった方がいい
最初にはっきりさせておきます。
- 正解のフローチャート記号セット
- 正解の書き方
なんてものは、存在しません。
ただし、現場で運用するうえでは
- 記号の種類を増やしすぎない
- 誰が見ても同じ意味に読み取れる
- 「誰向けに書くのか」をはっきりさせる
この3つが揃っていると、フローチャートは一気に“仕事で使える資料”になります。
この記事で紹介するのは、
- 運用向けフロー
- システム設計向けフロー
- 仕様書向けフロー
全部で共通して使える、最小限の6記号セットです。
しかも、Excelの図形だけで完結できます。
ベースはExcelでOK。まずはこの6つだけ覚えよう
ここから、内容を紹介していきます。
すべてExcelの図形で用意できるものだけです。
1. 開始・終了（ターミナル）
- よくある「角丸の四角」のやつです。
- 結論から言うと、あってもいいけど、運用フローでは無くてもいいです。
「え、それ省いちゃうの!?」と思うかもしれませんが、
- 基準書や運用マニュアルで
開始・終了をいちいち書いていると、
フローチャートが無駄に縦長になるんですよね…。
どうですか？ わざわざ書かなくても分かるな・・・・ってなりません？
なので運用や動作フローでは、開始・終了は省略することが多いです。
一方で、システムフローでは使うことが多いです。
- バッチ処理の開始
- 外部システムからのトリガ
- 処理全体の終端
などがきちんと分かったほうがいい場面では、ちゃんと書きます。
2. 判断（ダイヤ）
- みんな大好きダイヤ形の「判断」記号です。
- 運用フロー、システムフロー、動作フロー、全部で頻出。
中に入れる文言は、例えば「人がいるか」で分岐が
- Yes / No
- OK / NG
どちらでもOKです。
大事なのは ルールを統一すること。
または
中の文言を「選択」、分岐が「保存する／保存しない」という書き方もOK！！
さらに、個人的にかなりおすすめしているルールがこれです。
- ポジティブな流れ（Yes／OK） → 下方向へ
- ネガティブな流れ（No／NG） → 横に分岐させる
こんな感じ↓
これだけで、
- パッと見で「うまくいくパス」と「エラー処理のパス」が分かる
- エラー側の処理だけ横に伸ばしてまとめやすい
というメリットがあります。
3. 処理（長方形）
- 言うまでもなく、一番使う記号です。
- 「○○を実行」「○○を設定」「○○をON」など、ほぼ全部これ。
たまに、
- 手操作＝台形記号で分ける
という教科書通りの記述を見かけますが、
私はあえて台形は使いません。
理由はシンプルで、
- 記号の種類が増えるほど、読む側に負担が増える
- 手操作か自動かは、横の列を変えることで表現できる
からです。
例えば、
- 左の列：人（オペレータ）がやる操作
- 右の列：設備・システムが自動でやる処理
というように分ければ、
記号は同じ「処理」でも、誰のアクションか一目で分かります。
4. 定義済み処理（サブルーチン）
ここから少し技術寄りです。
- 手帳アイコンっぽい「二重線の四角」のやつです。
- 意味としては「サブルーチン」「まとめた処理を呼び出す」です。
サブルーチン＝
「パッケージ化したプログラム（または処理のまとまり）を呼ぶ」と考えてください。
FAの現場なら、
- 「画像処理Prg」
- 「搬送処理」
- 「異常ログ処理」
など、細かく書くとめちゃ長くなる部分を定義済み処理としてまとめるとスッキリします。
システムフローや制御仕様書では、
この記号を使いこなせると一気に“できる人のフロー”っぽくなります。
5. 磁気ディスク（サーバー、HDD、SSD、NAS）
- 横向きの円柱のようなあの記号です。
- 意味としては「データの保存先」。
システムフローでよく使います。
理由は簡単で、今のシステムはとにかく
- 履歴
- Log
- トレース情報
を残しまくるからです。
例えば、
- 「検査結果をDBに保存」
- 「トレース情報をファイル出力」
といった処理を、処理記号＋磁気ディスク記号の組み合わせで書くと、
「どこに何が残るのか」が視覚的に伝わりやすくなります。
6. 照合（比較）
- 中に「＝」「×」っぽい記号が描かれた丸っぽいやつです（Excelにもあります）。
- これはたまに使うくらいのポジション。
意味としては、その名の通り「何かと何かを比べる」です。
- センサ値と閾値の比較
- 新規データと既存データの同一性チェック
- 入力パラメータの整合性確認
などで、「比較して判定している」ことを強調したいときに使います。
ただし、頻度はそこまで多くないので、
- 使いすぎると逆に読みにくくなる
- 本当に比較が主役のところだけで使う
くらいの感覚でOKです。
なぜこの6個だけで十分なのか？
ここまで読んで、
「他にも記号いろいろあるよね？」と思った方もいると思います。
その通りで、教科書を開けば
- 端子
- 文書
- 手作業
- 表示
- …などなど
いろいろ出てきます。
それでも、私が現場ではこの6個に絞っている理由はシンプルです。
これ以外の記号を日常的に使ったことがある人が、圧倒的に少ないから。
感覚値ですが、98%の方に
「見たことない記号なんだけど…」という顔をされます。
フローチャートは、
- 自分が気持ちよく描くためのもの
ではなく - 他人が一瞬で理解できるためのもの
です。
だからこそ、
- 「教科書的には美しいか？」ではなく
- 「現場の人、他の人がパッと見て意味が分かるか？」
を優先して、記号の種類を削ぎ落として6個まで絞っています。
誰向けのフローかで「見せ方」を変えるのが一番大事
ここまで記号の話をしてきましたが、
実は一番重要なのは
フローチャートは「誰向けに描くのか？」
を最初に決めておくことです。
例えば、
- 運用フロー：オペレータ／現場の担当者向け／使用するユーザ向け
- システムフロー：SE／プログラマ／IT寄りの人向け
- 仕様書向け：Sier、メーカー等の発注先
それぞれで、同じ記号でも見せ方や詳細度を変える必要があります。
- 運用フローなら、開始／終了を省いてでも「やること」を端的に
- システムフローなら、サブルーチンや磁気ディスクをしっかり書く
- 仕様書フローなら、判断の条件や処理ルートを明確に分岐
といった具合です。
この記事で紹介した6つの記号は、
どのパターンでも共通して使えますが、
「誰向けか」で細かいルールを変えると、さらに読みやすくなります。
この6記号だけでフローを実際に描いてみる
ではこれらを使って「搬送エレベータ」のフローチャートをいろいろ作ってみましょう。
搬送エレベータの「動作フロー」
以下に動作フローを描いてみましたが、正直、定義済みの処理を動作フローで書かない人も多いので、
もっとシンプルでもOKです！！
「動作フロー」のポイントは
人が目で見て分かる単純動作を記載すること
細かい部分を書きたくなる気持ちもわかりますが、そこはシステム側に記載するか、発注先に依頼でも問題ないかと思います。
搬送エレベータの「システムフロー」
次に「システムフロー」を作成していこうと思います。
実際には発注者側ではなく、元請け側が書くことが多いと思います。ここのすり合わせでどんな機器が必要か変わってきます。
最後ちょっと端折ってしまいましたが、ここまで書いてあるとお互いにメリットがあります。
メリット１：設備間でどんなシェイクをしてほしいかを議論できる
設備導入後になって発生するのが、メンテ性の悪さを指摘される、または指摘することです。
ここではもっとこの信号を見てほしかった。保全性が悪い。。。。。
みたいなことありませんか？
ある程度、詳細のフローを描くことでどんなシェイクをしたいのか、初めて議論ができるんです。
メリット２：発注者側、受注者側の齟齬が少なくなる
メリット１に付随することですが、圧倒的に設計時点での齟齬がなくなります。
システムの組み方は100人100通りと言っても過言ではありません。
そんな中、
普通はこう設計するでしょ。。。。
って思ったことないですか。「普通」ってないんですよ。
それはもはや平均値と中央値の違いを知らない人と同じです。
よくあるNGフローチャートと、その考え方
最初にハッキリさせておきたいのは、
「フローチャートに“唯一の正解の書き方”はない」
ということです。
ExcelだろうがPowerPointだろうが、
縦長だろうが横長だろうが、
読む人が迷わず理解できて、実設計に手戻りが出ないならOKです。
ただし――
「これはさすがにNGでしょ」という書き方は、明確にあります。
ここでは、特に生技・保全・システム設計側で
手戻りの原因になりやすいNGパターンを整理しておきます。
NG1. 主語がないフロー（誰がやるのか不明）
一番やっちゃいけないのがこれです。
- 「確認する」
- 「設定する」
- 「リトライする」
といった箱が並んでいるだけで、
- それをやるのが「オペレータ」なのか
- 「PLC」なのか
- 「上位PC」なのか
- 「外部システム」なのか
が 一切書かれていないフロー は、実装側からすると地獄です。
結果的に、
- 実装側：「これはどっちがやる想定です？」
- 仕様書側：「どっちでもいいけど…そっちで決めて」
みたいな会話が発生し、手戻りと認識ズレの温床になります。
NG2. システム境界が曖昧（どのシステムがやるのか不明）
主語がないことに近いですが、特にシステム系で多いのがこれ。
- 「データを格納する」
- 「結果を判定する」
- 「アラームを表示する」
といった箱があっても、
- PLCのロジックなのか
- 画像処理PCなのか
- MES / 上位サーバなのか
- HMI（タッチパネル）側の機能なのか
がフロー上で区別されていないケースです。
これをやられると、
- どの機器にI/Fを持たせるのか
- 誰がどこまで設計するのか
が後から曖昧になり、仕様分割のやり直しが発生します。
NG3. 1つの箱に「やること盛り盛り」＋長文
例えばこんな感じの箱：
「作業者がボタンを押して設備を起動し、その後に搬送が開始されて、
センサでワークを検出したら次工程に搬送する」
…これ、一発でアウトです。
- 1つの箱には1アクションを原則とする
- 長文になりそうなら、
- 「設備起動」
- 「搬送開始」
- 「センサ検出」
などに分割する
ようにしないと、
レビューする側も読む気がなくなりますし、
実装側も「どこからどこまでが1処理なのか」分からなくなります。
NG4. 矢印が迷路になっている
ありがちなパターンがこちら。
- 矢印があちこち交差している
- 画面の端から端へ、謎の折れ曲がり矢印が飛んでいる
- 上下左右に行ったり来たりして、視線の動きが読めない
こうなると、
フローを追うだけで疲れる図になります。
「フローは縦方向に流す（上→下）」
「横方向は分岐・例外だけにする」
など、視線の流れが一定になるように設計することが大事です。
NG5. 記号が乱立しすぎて覚えられない
- 開始・終了
- 処理
- 判断
- サブルーチン
- データストア
くらいで十分なのに、
- 例外処理用の特殊記号
- 手作業専用の記号
- システム別に色も形もバラバラ…
みたいな図は、初見の人にはまず読めません。
この記事のコンセプトは、
「普通と呼ばれる書き方はなくてもいいが、NGな書き方は避ける」
なので、
- 記号は最小限の種類に絞る
- 使い慣れた形に統一する
という方針にしておくのが安全です。
NG6. 終点がない／どこまでが1シナリオか分からない
- 矢印を追っていっても、どこで終わるのか分からない
- 「リトライ」「再試行」が多すぎて、ループから抜ける条件が不明
- 「異常時の出口」が定義されていない
こういうフローは、
- 実際の運用で「いつまでリトライするか」迷う
- システム側で「無限ループ」的な実装になりやすい
などの問題を生みます。
正常系も異常系も、「どこで終わるか」を必ず明確にしておくことが重要です。
NG7. 分岐条件があいまい／Yes/Noがよく分からない
判断のダイヤに、
- 「検査OK？」
- 「エラー？」
とだけ書かれていて、
- 何を見てOKなのか
- どの範囲ならOKで、どこからがNGなのか
がフローから読み取れないケースも要注意です。
ラフ案ならまだしも、
実設計・実装に渡す段階では、判断条件はできるだけ具体的にしておかないと、
- 実装側：「どの閾値で判定していいか分からない」
- 現場側：「そんな仕様だと思ってなかった」
という手戻りになります。
フローチャート品質チェックリスト（詳細版）
ここまで見てきたNG例を踏まえつつ、
「これに引っかからなければ、最低限OKと言える」
というチェックリストを作りました。
レビュー時に印刷して赤ペンでチェックしてもいいですし、
標準化のときの“物差し”として使ってもらってもOKです。
1. 基本構造・読みやすさ
- フローの大きな流れは 上 → 下（縦方向） に統一されている
- 横方向の矢印は、分岐や例外処理など必要最小限に抑えられている
- “入口”と“出口”（開始と終了／異常終了）が明確に書かれている
- 矢印を一筆書きで追ったときに、「どこまでが1シナリオか」が分かる
- 過度な行き来（上に戻る矢印・画面端から端へのジャンプ）がない
2. 主語・責任分担の明確さ（誰が・どのシステムがやるか）
- 各処理が 「誰がやるのか（人 or システム）」 明確になっている
- 例：オペレータ／作業者／検査員／保全
- 例：PLC／画像処理PC／上位サーバ／タッチパネル
- 必要に応じて、スイムレーン／列分けなどで「担当」を分けている
- 左列：人、中央：設備、右列：システム など
- 「確認する」「設定する」など、主語がない動詞だけの箱が残っていない
- “人間がやる処理”と“自動で行われる処理”が混ざっていないか確認した
- インターフェースの境界（どこからどこまでをどのシステムでやるか）が明示されている
コンセプト：
「普通と呼ばれる書き方」はなくても、
誰が・どのシステムがやるのか不明なフローは確実にNG という基準を持つ。
3. 分岐・条件の明確さ
- 判断記号（ひし形）には、具体的な条件が書かれている
- 「OK？」ではなく「検査結果 ≧ 閾値？」など
- Yes/No（または OK/NG）の向きが全ページで統一されている
- 例：下が Yes、右が No で統一…など
- 分岐後のフローで、「どこに戻るか」「どこで終わるか」が明確
- 再試行／リトライのループには、回数制限 or 抜け条件が定義されている
- 異常系のフローが、「とりあえずアラーム表示」で終わっていない
- 例：アラーム表示 → 設備停止 → オペレータ対応 → 復旧条件 までつながっているか
4. 記号・表記ルール
- 使用している記号の種類は、この記事で挙げた6種類＋α程度に収まっている
- 開始・終了 / 処理 / 判断 / サブルーチン / データ格納 / 照合 など
- 同じ意味の処理に、違う記号・違う色を使っていない
- 特殊記号を使う場合、その意味が凡例や注釈で説明されている
- 箱の中のテキストは、一目で読める量に収まっている
- 1行〜2行程度を目安にし、それ以上になりそうな箇所は分割を検討
- 略語や専門用語を使う場合、
- 読み手（運用側／システム側）が理解できるか
- 必要であれば用語集や脚注を用意するか
を検討した
5. レイアウト・可読性
- フローチャート全体を見たときに、詰め込みすぎていない（白地がある）
- 箱同士の間隔が一定程度あり、読みにくい密集地帯がない
- 矢印同士が何本も交差している箇所がない
- ページをまたぐ場合、「続き」がどこかが明確（リンク番号や注釈）
- Excel／PowerPointのグリッド・整列機能を使って、位置が揃えられている
6. レベル感・粒度の揃い方
- 1つの箱に 複数アクションが詰め込まれていない
- 「ボタン押下→設備起動→搬送開始→…」のような長文箱がない
- 同じレベルの箱（同じ段の処理）が、だいたい同じ粒度で書かれている
- 片方は「検査する」、片方は「画像処理パラメータを設定し閾値を比較して判定する」など、粒度差が激しすぎない
- このフローをそのまま「手順書の章立て」として流用したとき、違和感がない粒度になっている
- 詳細化が必要な部分には、
- 別紙フロー（サブルーチン）
- 注釈
などで「掘れる余地」が用意されている
7. 仕様 ↔ 実装の橋渡しとしての機能
- フローを見れば、どの部分を誰（どの部署／ベンダ）が実装するかがイメージできる
- 契約・仕様書として使う場合、「ここは相手側の責任範囲」と明確に分かるようになっている
- 実設計者がこのフローを見たとき、追加で確認したくなるポイントが最小限になっている
- 例：「これ誰がやる想定です？」「どのタイミングで通知します？」などが大量に出ないレベル
- 運用側（現場）に見せたときも、「何をするフローか」がきちんと伝わる
8. 保守・変更のしやすさ
- 後から工程が増えたとき、箱1〜2個の追加で済む構造になっているか
- 仕様変更の影響範囲が、フローを見ればある程度見えるようになっている
- Excel／PowerPointのテンプレートとして再利用しやすい構成になっている
- 似たようなフローが複数ある場合、
- 共通部分をサブルーチン化する
- 別ページにまとめる
など、重複を減らす工夫がされている - 将来、別の人がこのフローを見たときに、
「何となく雰囲気で書いてある」のではなく、
意図を読み解ける情報量が入っている
9. 最後に：チェックリストの使い方
このチェックリストは、
「普通と呼ばれるフローチャートの型に合わせるため」ではなく、
「NGな書き方になっていないかを確認するため」の道具
です。
特に、
- 誰がやるのか
- どのシステムがやるのか
が曖昧なフローは、ほぼ間違いなく手戻りになります。
フローを書くときも、レビューするときも、
- 「読み手（実設計者・運用者）が迷わないか？」
- 「責任分担がぼやけていないか？」
という視点で、このチェックリストを軽くなぞるだけでも、
フローチャートの品質はかなり安定してくるはずです。
いかがでしたでしょうか。。
以上！
フローチャート沼から抜け出したいすべてエンジニアの方の参考になればうれしいです😎
この記事へのコメント