簡易なフローチャート これはsに1から10までの数字を足しこむ処理を表した図である。 フローチャート （flowchart, 流れ図 ）は、プロセスの各ステップを箱で表し、流れをそれらの箱の間の矢印で表すことで、アルゴリズム やプロセス を表現する図である。アルゴリズムやプロセスについて、単にその順序だけを示すものであり、全体から詳細へというような「段階的」な説明ではない（ないし、記述者が意識してそのような階層を作る必要がある）[ 注釈 1] データフロー図 と対比すると、より重要であるデータ の流れをフローチャートは表すことがなく、操作を順に示すことでデータの流れを暗示する。しかし、フローチャートは様々な分野の工程の解析・設計・文書化・管理に用いられている[ 1]
フローチャートは複雑なプロセスやプログラムの設計および文書化に使われる。他の図と同様、何が行われているかを視覚化するのを助け、それによって見る者がプロセスを理解するのを助け、さらには欠陥・ボトルネック・細かい特徴などを発見できることもある。フローチャートには様々な種類があり、それぞれ固有の部品（箱）や記法を持つ。最も一般的な箱は次の2種類である。
処理ステップ、活動を表す箱。単純な四角形で表される。
判断。通常菱形で表される。 ページをいくつかに分割し、異なる組織の制御を異なるスイムレーン （英語版 ）
プログラミング言語 の教育においては、処理を理解するために用いられることがある（たとえば、for (i = 0; i < 10; ++i) という字面からだけでは、「繰返しの1回目では ++i は実行されない」「2回目からの繰返しの前に ++i と i < 10 の判定がこの順に行われる」といったことがわかりづらいため、そういったことを可視化するには適している）。事務処理においては、提出資料の様式として要求する者がいるため、使わざるをえないこともある。日本の特許 の実務では、これを避け後述する構造化チャートであるPAD で手続きを記述し特許を取った前例がある[ 2]
問題解決においてフローチャートを作成する意味は、
問題解決の方法を視覚 的に明確に表せる。
処理手順を追いやすい。そのため手順に問題がある時、それを発見・修正するのが容易になる。
問題解決を複数人数で行う時、担当箇所の明確化や、説明する際の理解向上に役立つ。 などがある。[ 3]
フローチャートはプロセスのある側面を描いたもので、他の側面は他のダイアグラム で補完される。例えば、石川馨 は品質管理 の七つ道具として、グラフ 、ヒストグラム 、パレート図 、チェックシート 、管理図 、特性要因図 、散布図 を挙げている。また、非形式的なモデリング言語としてUML があるが、数あるダイアグラムのうちのアクティビティ図 はフローチャートのように制御フローを書くことに使うことができる。
いずれにしても、コンピュータ科学 の観点からは、フローチャートは、コンピュータのプログラミングにおいて無条件と条件分岐の分岐命令 （goto文 とif文 ）だけを制御構造 として使っているような「構造化 以前の存在」、として扱われている。構造化をフローチャート（的な図法）に取り入れた試みについては、#構造化フローチャート の節を参照。
フローチャート作図用のステンシルテンプレート プロセスの流れを文書化する最初の構造化技法として「フロー・プロセス・チャート （英語版 ） アメリカ機械工学会 (ASME) の会員だったフランク・ギルブレスが “Process Charts—First Steps in Finding the One Best Way” と題して発表した。このツールは間もなく経営工学 の教育に組み込まれた。1930年代に入ると、アラン・H・モーエセンという経営工学者がニューヨーク州 レークプラシッド で経営工学のいくつかのツールをビジネスマン向けに教えるという仕事を始めた。
1944年にモーエセンのクラスを卒業したアート・スピナンジャーは、それらツール群をプロクター・アンド・ギャンブル に持ち帰り Deliberate Methods Change Program を開発した。同じく1944年に卒業したベン・S・グレアム （英語版 ） Standard Register Industrial の帳票開発部門のディレクターで、フロー・プロセス・チャートを発展させ複数の文書間の関係を示すマルチフロー・プロセス・チャートを考案した[ 4]
ダグラス・ハートリー は、ハーマン・ゴールドスタイン とジョン・フォン・ノイマン がコンピュータプログラム（当時のことであるから、機械語 を直接人間が書く、というプログラミングであったことに留意）のためのフローチャートを考案したとしている[ 5] IBM 技術者による傍証があり[ 6] [ 7] [ 8]
フローチャートはアルゴリズム を表現する手段として広く使われた。今[いつ? でもその用途で使う者もいる[ 9]
しかし、1970年代になると対話型端末 と高水準言語 が一般化し、ソースコード でもっと簡潔にアルゴリズムを表現できるようになり、フローチャートの人気は減退した。また、フローチャートはgoto文 を多用したスパゲティプログラム そのものであるとも言え、アルゴリズムの表現としては、特定のプログラミング言語 の詳細に関わらない擬似コード がよく使われるようになった。また、#構造化フローチャート という試みもある。
UML のアクティビティ図 はフローチャートを表記変更および拡張したものとも言える。ただし、アクティビティ図は制御フローだけでなく並行動作やデータフローもある程度表現できる。
Nの階乗 N! を計算するフローチャート 右図は、階乗 の計算方法を示したフローチャートである。
最も重要で注意すべきなのは、階乗を計算するアルゴリズムの本質は、箱の中に補助的に（したがって以下の解説ではロクに触れていないが）書かれている、変数を参照している演算式や、変数の代入といったもので表現されていて、「フローチャート」の箱や矢印は、その順序付けを表現しているに過ぎない、ということである。
各工程（処理）を示す絵図の標準の一つとしては「情報処理用流れ図・プログラム網図・システム資源図記号」[ 10]
端子
円、楕円、角が丸められた長方形などで表現され、その中に「開始」または「終了」といった単語か、それに類する文が書かれる。プロセスの開始と終了を示す。
流れ線と矢印
制御の流れ を示す。部品間をつなぐように描くことで、制御が部品から部品へと流れることを示す。常に矢印を使う作法もあるが、流れ線を使う場合は上から下に制御が流れることを表し、それ以外の方向の場合に矢印を使う。JISでは別の部品の上辺に到達するよう描くように標準化しているが、そうではない作法もある。破線 も使われることがあるが、その意味は様々である。処理
長方形 で表現される。中には具体的な処理を「Xに1を加算」、「識別した部分を置換」、「変更をセーブ」などと記述する。定義済み処理
長方形の左右の辺を二重線にした形で表す。別のフローチャートで詳細に描かれた工程を参照するのに使う。定義済み処理はサブルーチン などに相当するが、入口と出口が複数存在する場合もある（コルーチン 参照）。その場合、どの入口から参照するかを示す記述が必要となる。
入出力
平行四辺形 で表現される。中には例えば「ユーザーがXを入力」、「Xを表示」などと書かれる。準備
六角形 で表現される。後続の「判断」で使用する値を準備する操作が書かれる。判断
菱形 で表現され、一般に「Yes/No」あるいは「真/偽」が答えとなる判断を表す。2つの流れ線または矢印が出て行く点が他の部品とは異なる。出て行く流れ線は、下の頂点と右（または左）の頂点から発するのが一般的で、一方が「Yes」または「真」、もう一方が「No」または「偽」に対応する。そのため常にラベルを添えて意味を示す必要がある。3つ以上の線が出て行く場合もあるが、それは判断が複雑であることを意味し、複数個の「判断」で詳細化することができる。あえてswitch文 に相当する書き方をする場合は、下の頂点から発した流れ線を分岐させる形で描くのが一般的である。合流
一般に黒い点で表し、複数の制御の流れが合流して1つの流れとなることを示す。他の種類の図法で使う、丸「◯」の中に円周に接さない十字記号「+」を入れた記号を流用することもある。合流シンボルには複数の矢印が到達し、1つの矢印が出て行く。JISでは単に流れ線の途中に矢印が接する形で合流を表すと標準化している。一般には「判断」によって別れたものを再び合流するなどに使うのであるが、反復処理をループ によって実装したり、何らかの本来ならば別の一連の手続きとして切り出すべきものを、その先頭への流れに合流させて済ませたり、など、スパゲティの元である。そのためかUMLのアクティビティ図 は、「判断」によって別れたものの再合流には、専用の「判断」と同じ形状の菱形を使うこととした[ 注釈 2]
また、作図の都合上2つの流れ線が交差することがあるが、その場合は合流ではないことを示すために一方の線を小さな半円状に曲げてもう一方の線をまたがせることがある。
結合子
円の中に識別用ラベルを記した形で表現される。複雑なフローチャートで矢印や流れ線の代わりに用いられる。ページをまたがるような場合、JISではホームベース形の結合子を用いると標準化しているが、特に区別しない方式もある。同じラベルの結合子同士が流れ線でつながっているかのように扱われる。結合の終点となる側は一意なラベルを付与し、起点となる側が終点となる側と同じラベルを付与する。起点側は複数でもよく、その場合は合流シンボルを含意する。
並行性
二重の水平な線で表現され、上に複数の流れ線（矢印）が入り、下から複数の流れ線（矢印）が出る形で表現される。これによって複数の同時並行的に行われる制御フローを表す。入ってくるフローが全て二重線に到達すると、出て行くフローが全て同時に開始される。入力フローが1つの場合を「フォーク」、出力フローが1つの場合を「ジョイン」と呼ぶ。 部品の論理的順序を保つことが重要である。あらゆるプロセスは上から下、左から右に流れるべきである。
制御フローではなくデータフローを表現するデータフロー図 を描くための部品の規格化が行われてきた。そのような部品は制御フローを表すフローチャートでも特に平行四辺形の「入出力」部品を詳細化するのに使われている。
なお、そもそもコントロールのフローとデータフローは違うものであるため「（フローチャートの）データフロー的拡張」として両者を混用すると、フローチャートの「代入などの操作を表現する箱」と、データフロー図の「データを保持したり加工する実体を表現する箱」が混在することになり、同様に「順次的な手続きの流れ」を表現する矢印と「データの流れ」を表現する矢印が混在することになる。
長方形 の下辺を波形にした図形で、「書類」を表す。上辺が左から右に斜めに上がっている四角形で、「手操作入力」を表す。例えば、帳票へ書き込むことを表す。
上底の方が長い台形 で、「手作業」を表す。人間が自ら行うしかない作業や調整を表す。
円柱形で「データファイル」を表す。
Sterneckert (2003) によれば、フローチャートは様々なユーザーグループ（管理者、システムアナリスト、事務員など）の異なる観点からモデル化でき、それらは次の4種類に分類できる[ 11]
文書フローチャート - システム内の文書の流れについての制御を示す図
データフローチャート - システム内のデータの流れについての制御を示す図
システムフローチャート - 物理レベルまたは資源レベルの制御を示す図
プログラムフローチャート - システム内のプログラムにおける制御を示す図 どのフローチャートも流れ自身ではなく、ある種の制御に着目したものであることに注意が必要である[ 11]
自動車の運転をフローチャートでモデル化したもの 他にもいくつかの分類がある。例えば、Andrew Veronis (1978) は、システムフローチャート、概要フローチャート、詳細フローチャートという3つに分類した[ 12] [ 13] [ 14]
さらに、フローチャートとよく似たダイアグラム技法を異なる名前で呼んでいる場合もあり、例えば、UML のアクティビティ図 がある。
可逆フローチャート[ 15] 可逆コンピューティング システムの理論的基礎となっている。[ 16]
JISで標準化された図法は、工業・情報処理でどうしてもフローチャートで書かなければならない場合に用いられることが多い。一方、株式公開 や内部統制 のフローを描く場合には、以下のような形式のフローチャートを用いることがある。
NOMA方式
日本経営協会 (NOMA) の理事であった、三枝鐘介によって作られたもの。使用する記号を抑えて、シンプルに記述するのが特徴。
日能式
日本能率協会 によって作られたもの。思想はNOMA方式に近い。産能大式
学校法人産業能率大学 によって作られたもの。NOMA方式に比べ、「FAX 」「コピー 」等の具体的な記号を用いているのが特徴。株式公開時の提出資料で、この形式を用いることが多い。
フローチャートはいわば、goto文 とif文 だけでプログラミングしているようなものであるため、プログラミングに構造化プログラミング があらわれたように、段階的詳細化などの問題解決の手法をきちんと反映するような、より良い図法とされるものが、いくつも考案された。そのような図法としてNS図（w:Nassi–Shneiderman diagram 、DIN 66261）の他、ISO/IEC 8631（対応するJISとして、JIS X 0128）のAnnex A（informative）には、以下の種類の図法が示されている。
PAD (Problem Analysis Diagram、二村良彦 考案)[ 17] HCP (Hierarchical ComPact description chart 、日本電信電話公社 の横須賀電気通信研究所で開発)PSD (Program Structure Diagram、日本電気)
DSD (Design Structure Diagram)
SPD (Structured Programming Diagram)
LCP (Logical Conception of Program hierarchical)
LCP (Logical Conception of Program flow chart) また他に YAC (Yet Another Control chart、富士通) がある。
これらがさほど普及しなかった理由としては、ノイマンらがフローチャートをプログラミングの補助として採用した頃の機械語 プログラミングからの時代の経過で、構造化をサポートした高水準プログラミング言語 などにより、むしろこういった図法よりもアルゴリズムをより明確に、プログラミング言語で直接書けるようになったことがある。また全く技術的でない理由として、唯一に標準化されたものでなければ使えないとする信仰のようなものから、このようにたくさん提案されているのでは採用できない、といったようなものもある。
またこれらを使う際には、数個以上の箱が縦に並ぶようなことは可能な限り避けきちんとサブルーチンとして切り出すなどして、「フローチャートの欠点」とされるような書き方は戒められなければならない。そういったことから「フローチャート」の語を避けて、構造化チャート と呼ばれることもある。
作図プログラムならフローチャートを描画できるが、単に図として描画するとデータベースやプロジェクトマネジメント システムや表計算ソフト とデータを共有するデータモデルを提供できない。一部のツールはフローチャート描画のための機能をサポートしている。また、何らかのソースコードあるいはフローチャート記述言語から自動的にフローチャートを生成できるソフトウェアも多数存在する。ウェブ経由でオンラインで使えるツールも存在する。
^ そのため、問題解決の理解には程遠いこともある（すごろく やあみだくじ やゲームブック のようなものだと思えばよい。各ステップとステップ間の流れは単純明快でわかりやすいが、全貌を誤解なく理解するには大変な努力を要することもある）。
^ なお、可逆計算 を表現する場合には「制御フローの合流の逆」は重要なのだが、UMLの設計者たちがそのような先進的なアイディアを考慮したものか否かは不明である。
^ SEVOCAB: Software and Systems Engineering Vocabulary . Term: Flow chart . Retrieved 31 July 2008.^ 二村 他: 特許2922207 ^ 萩原芳彦 監修 『ハンディブック 機械 改訂2版』 オーム社 2007年3月20日 p.352
^ Graham, Jr., Ben S. (10 June 1996). “People come first ”. Keynote Address at Workflow Canada'. 2012年11月4日 閲覧。 ^ Hartree, Douglas (1949). Calculating Instruments and Machines . The University of Illinois Press. p. 112 ^ Bashe, Charles (1986). IBM's Early Computers . The MIT Press. p. 327 ^ Goldstine, Herman (1972). The Computer from Pascal to Von Neumann . Princeton University Press. pp. 266-267. ISBN 0-691-08104-2 ^ Taub, Abraham (1963). John von Neumann Collected Works . 5 . Macmillan. pp. 80-151 ^ Bohl, Rynn: "Tools for Structured and Object-Oriented Design", Prentice Hall, 2007.
^ JIS X 0121:1986 「情報処理用流れ図・プログラム網図・システム資源図記号」 ^ a b Alan B. Sterneckert (2003)Critical Incident Management . p. 126
^ Andrew Veronis (1978) Microprocessors: Design and Applications . p. 111
^ Marilyn Bohl (1978) A Guide for Programmers . p. 65.
^ Mark A. Fryman (2001) Quality and Process Improvement . p. 169 .
^ Yokoyama, Tetsuo; Axelsen, Holger Bock; Glück, Robert (January 2016). “Fundamentals of reversible flowchart languages”. Theoretical Computer Science 611 : 87–115. doi :10.1016/j.tcs.2015.07.046 . ^ Krakovsky, Marina (June 2021). “Taking the heat”. Communications of the ACM 64 (6): 18–20. doi :10.1145/3460214 . ^ 二村良彦, 川合敏雄, 堀越彌, 堤正義「PAD （Problem Analysis Diagram）によるプログラムの設計および作成 」『情報処理学会論文誌』第21巻第4号、情報処理学会、1980年7月、259-267頁、ISSN 1882-7764 、NAID 110002723539 。
ウィキメディア・コモンズには、
フローチャート に関連するメディアがあります。
.jpg)
