コンテンツにスキップ

フローチャート

出典: フリー百科事典『ウィキペディア（Wikipedia）』
簡易なフローチャート これはsに1から10までの数字を足しこむ処理を表した図である。

フローチャート（flowchart, 流れ図）は、プロセスの各ステップを箱で表し、流れをそれらの箱の間の矢印で表すことで、アルゴリズムやプロセスを表現する図である。アルゴリズムやプロセスについて、単にその順序だけを示すものであり、全体から詳細へというような「段階的」な説明ではない（ないし、記述者が意識してそのような階層を作る必要がある）[注釈 1]。また、データフロー図と対比すると、より重要であるデータの流れをフローチャートは表すことがなく、操作を順に示すことでデータの流れを暗示する。しかし、フローチャートは様々な分野の工程の解析・設計・文書化・管理に用いられている[1]。

概要

[編集]

フローチャートは複雑なプロセスやプログラムの設計および文書化に使われる。他の図と同様、何が行われているかを視覚化するのを助け、それによって見る者がプロセスを理解するのを助け、さらには欠陥・ボトルネック・細かい特徴などを発見できることもある。フローチャートには様々な種類があり、それぞれ固有の部品（箱）や記法を持つ。最も一般的な箱は次の2種類である。

  • 処理ステップ、活動を表す箱。単純な四角形で表される。
  • 判断。通常菱形で表される。

ページをいくつかに分割し、異なる組織の制御を異なるスイムレーン（英語版）に描く形のフローチャートは「部門間協力」型のプロセスを表せる。特定のレーンに描かれた部品群はその組織の制御下にあるプロセスを意味する。この技法は各活動の責任分担を明確化でき、意思決定を正しく行えるようにする効能がある。全体として一つのプロセス（事業、プロジェクトなど）を実施する際の各組織の責任を明確化できる。

プログラミング言語の教育においては、処理を理解するために用いられることがある（たとえば、for (i = 0; i < 10; ++i) という字面からだけでは、「繰返しの1回目では ++i は実行されない」「2回目からの繰返しの前に ++i と i < 10 の判定がこの順に行われる」といったことがわかりづらいため、そういったことを可視化するには適している）。事務処理においては、提出資料の様式として要求する者がいるため、使わざるをえないこともある。日本の特許の実務では、これを避け後述する構造化チャートであるPADで手続きを記述し特許を取った前例がある[2]。

問題解決においてフローチャートを作成する意味は、

  1. 問題解決の方法を視覚的に明確に表せる。
  2. 処理手順を追いやすい。そのため手順に問題がある時、それを発見・修正するのが容易になる。
  3. 問題解決を複数人数で行う時、担当箇所の明確化や、説明する際の理解向上に役立つ。

などがある。[3]

フローチャートはプロセスのある側面を描いたもので、他の側面は他のダイアグラムで補完される。例えば、石川馨は品質管理の七つ道具として、グラフ、ヒストグラム、パレート図、チェックシート、管理図、特性要因図、散布図を挙げている。また、非形式的なモデリング言語としてUMLがあるが、数あるダイアグラムのうちのアクティビティ図はフローチャートのように制御フローを書くことに使うことができる。

いずれにしても、コンピュータ科学の観点からは、フローチャートは、コンピュータのプログラミングにおいて無条件と条件分岐の分岐命令（goto文とif文）だけを制御構造として使っているような「構造化以前の存在」、として扱われている。構造化をフローチャート（的な図法）に取り入れた試みについては、#構造化フローチャートの節を参照。

歴史

[編集]
フローチャート作図用のステンシルテンプレート

プロセスの流れを文書化する最初の構造化技法として「フロー・プロセス・チャート（英語版）」がある。1921年、アメリカ機械工学会 (ASME) の会員だったフランク・ギルブレスが “Process Charts—First Steps in Finding the One Best Way” と題して発表した。このツールは間もなく経営工学の教育に組み込まれた。1930年代に入ると、アラン・H・モーエセンという経営工学者がニューヨーク州レークプラシッドで経営工学のいくつかのツールをビジネスマン向けに教えるという仕事を始めた。

1944年にモーエセンのクラスを卒業したアート・スピナンジャーは、それらツール群をプロクター・アンド・ギャンブルに持ち帰り Deliberate Methods Change Program を開発した。同じく1944年に卒業したベン・S・グレアム（英語版）は Standard Register Industrial の帳票開発部門のディレクターで、フロー・プロセス・チャートを発展させ複数の文書間の関係を示すマルチフロー・プロセス・チャートを考案した[4]。1947年、ASMEはギルブレスのフロー・プロセス・チャートから部品群を採用したプロセスチャートのASME規格を策定した。

ダグラス・ハートリーは、ハーマン・ゴールドスタインとジョン・フォン・ノイマンがコンピュータプログラム（当時のことであるから、機械語を直接人間が書く、というプログラミングであったことに留意）のためのフローチャートを考案したとしている[5]。これには同時代のIBM技術者による傍証があり[6]、ゴールドスタインの回想録でも裏付けられている[7]。ゴールドスタインとフォン・ノイマンの最初のプログラミング用フローチャートは、当時公表されなかった報告書 "Planning and coding of problems for an electronic computing instrument, Part II, Volume 1" (1947) にあり、後にフォン・ノイマンの著作集に収録された[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]。JISでは反復を専用に表現する部品があり、そちらを使うべき（使わなければならない）であろう。
また、作図の都合上2つの流れ線が交差することがあるが、その場合は合流ではないことを示すために一方の線を小さな半円状に曲げてもう一方の線をまたがせることがある。
結合子
円の中に識別用ラベルを記した形で表現される。複雑なフローチャートで矢印や流れ線の代わりに用いられる。ページをまたがるような場合、JISではホームベース形の結合子を用いると標準化しているが、特に区別しない方式もある。同じラベルの結合子同士が流れ線でつながっているかのように扱われる。結合の終点となる側は一意なラベルを付与し、起点となる側が終点となる側と同じラベルを付与する。起点側は複数でもよく、その場合は合流シンボルを含意する。
並行性
二重の水平な線で表現され、上に複数の流れ線（矢印）が入り、下から複数の流れ線（矢印）が出る形で表現される。これによって複数の同時並行的に行われる制御フローを表す。入ってくるフローが全て二重線に到達すると、出て行くフローが全て同時に開始される。入力フローが1つの場合を「フォーク」、出力フローが1つの場合を「ジョイン」と呼ぶ。

部品の論理的順序を保つことが重要である。あらゆるプロセスは上から下、左から右に流れるべきである。

データフロー的拡張

[編集]

制御フローではなくデータフローを表現するデータフロー図を描くための部品の規格化が行われてきた。そのような部品は制御フローを表すフローチャートでも特に平行四辺形の「入出力」部品を詳細化するのに使われている。

なお、そもそもコントロールのフローとデータフローは違うものであるため「（フローチャートの）データフロー的拡張」として両者を混用すると、フローチャートの「代入などの操作を表現する箱」と、データフロー図の「データを保持したり加工する実体を表現する箱」が混在することになり、同様に「順次的な手続きの流れ」を表現する矢印と「データの流れ」を表現する矢印が混在することになる。

  • 長方形の下辺を波形にした図形で、「書類」を表す。
  • 上辺が左から右に斜めに上がっている四角形で、「手操作入力」を表す。例えば、帳票へ書き込むことを表す。
  • 上底の方が長い台形で、「手作業」を表す。人間が自ら行うしかない作業や調整を表す。
  • 円柱形で「データファイル」を表す。

様々なフローチャート

[編集]

Sterneckert (2003) によれば、フローチャートは様々なユーザーグループ（管理者、システムアナリスト、事務員など）の異なる観点からモデル化でき、それらは次の4種類に分類できる[11]。

  • 文書フローチャート - システム内の文書の流れについての制御を示す図
  • データフローチャート - システム内のデータの流れについての制御を示す図
  • システムフローチャート - 物理レベルまたは資源レベルの制御を示す図
  • プログラムフローチャート - システム内のプログラムにおける制御を示す図

どのフローチャートも流れ自身ではなく、ある種の制御に着目したものであることに注意が必要である[11]。

自動車の運転をフローチャートでモデル化したもの

他にもいくつかの分類がある。例えば、Andrew Veronis (1978) は、システムフローチャート、概要フローチャート、詳細フローチャートという3つに分類した[12]。また同年、Marilyn Bohl (1978) では「実際、ソリューションプランニングにおいてはシステムフローチャートとプログラムフローチャートの2種類のフローチャートが使われる」と記している[13]。さらに最近の Mark A. Fryman (2001) ではさらに様々な種類があるとし「意思決定フローチャート、論理フローチャート、システムフローチャート、製品フローチャート、プロセスフローチャートは、ビジネスや政府で使われている様々なフローチャートのほんの一部である」と記している[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）には、以下の種類の図法が示されている。

また他に YAC (Yet Another Control chart、富士通) がある。

これらがさほど普及しなかった理由としては、ノイマンらがフローチャートをプログラミングの補助として採用した頃の機械語プログラミングからの時代の経過で、構造化をサポートした高水準プログラミング言語などにより、むしろこういった図法よりもアルゴリズムをより明確に、プログラミング言語で直接書けるようになったことがある。また全く技術的でない理由として、唯一に標準化されたものでなければ使えないとする信仰のようなものから、このようにたくさん提案されているのでは採用できない、といったようなものもある。

またこれらを使う際には、数個以上の箱が縦に並ぶようなことは可能な限り避けきちんとサブルーチンとして切り出すなどして、「フローチャートの欠点」とされるような書き方は戒められなければならない。そういったことから「フローチャート」の語を避けて、構造化チャートと呼ばれることもある。

ソフトウェア

[編集]

作図プログラムならフローチャートを描画できるが、単に図として描画するとデータベースやプロジェクトマネジメントシステムや表計算ソフトとデータを共有するデータモデルを提供できない。一部のツールはフローチャート描画のための機能をサポートしている。また、何らかのソースコードあるいはフローチャート記述言語から自動的にフローチャートを生成できるソフトウェアも多数存在する。ウェブ経由でオンラインで使えるツールも存在する。

脚注

[編集]
[脚注の使い方]

注釈

[編集]
  1. ^ そのため、問題解決の理解には程遠いこともある（すごろくやあみだくじやゲームブックのようなものだと思えばよい。各ステップとステップ間の流れは単純明快でわかりやすいが、全貌を誤解なく理解するには大変な努力を要することもある）。
  2. ^ なお、可逆計算を表現する場合には「制御フローの合流の逆」は重要なのだが、UMLの設計者たちがそのような先進的なアイディアを考慮したものか否かは不明である。

出典

[編集]
  1. ^ SEVOCAB: Software and Systems Engineering Vocabulary. Term: Flow chart. Retrieved 31 July 2008.
  2. ^ 二村他: 特許2922207
  3. ^ 萩原芳彦 監修 『ハンディブック 機械 改訂2版』 オーム社 2007年3月20日 p.352
  4. ^ Graham, Jr., Ben S. (10 June 1996). “People come first”. Keynote Address at Workflow Canada'. 2012年11月4日閲覧。
  5. ^ Hartree, Douglas (1949). Calculating Instruments and Machines. The University of Illinois Press. p. 112 
  6. ^ Bashe, Charles (1986). IBM's Early Computers. The MIT Press. p. 327 
  7. ^ Goldstine, Herman (1972). The Computer from Pascal to Von Neumann. Princeton University Press. pp. 266-267. ISBN 0-691-08104-2 
  8. ^ Taub, Abraham (1963). John von Neumann Collected Works. 5. Macmillan. pp. 80-151 
  9. ^ Bohl, Rynn: "Tools for Structured and Object-Oriented Design", Prentice Hall, 2007.
  10. ^ JIS X 0121:1986 「情報処理用流れ図・プログラム網図・システム資源図記号」
  11. ^ a b Alan B. Sterneckert (2003)Critical Incident Management. p. 126
  12. ^ Andrew Veronis (1978) Microprocessors: Design and Applications. p. 111
  13. ^ Marilyn Bohl (1978) A Guide for Programmers. p. 65.
  14. ^ Mark A. Fryman (2001) Quality and Process Improvement. p. 169.
  15. ^ 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. 
  16. ^ Krakovsky, Marina (June 2021). “Taking the heat”. Communications of the ACM 64 (6): 18–20. doi:10.1145/3460214. 
  17. ^ 二村良彦, 川合敏雄, 堀越彌, 堤正義「PAD （Problem Analysis Diagram）によるプログラムの設計および作成」『情報処理学会論文誌』第21巻第4号、情報処理学会、1980年7月、259-267頁、ISSN 1882-7764、NAID 110002723539。 

参考文献

[編集]

関連項目

[編集]

外部リンク

[編集]
ウィキメディア・コモンズには、フローチャートに関連するメディアがあります。
「https://ja.wikipedia.org/w/index.php?title=フローチャート&oldid=102206268」から取得