Loading AI tools
ウィキペディアから
フローチャート（flowchart, 流れ図）は、プロセスの各ステップを箱で表し、流れをそれらの箱の間の矢印で表すことで、アルゴリズムやプロセスを表現する図である。アルゴリズムやプロセスについて、単にその順序だけを示すものであり、全体から詳細へというような「段階的」な説明ではない（ないし、記述者が意識してそのような階層を作る必要がある）[注釈 1]。また、データフロー図と対比すると、より重要であるデータの流れをフローチャートは表すことがなく、操作を順に示すことでデータの流れを暗示する。しかし、フローチャートは様々な分野の工程の解析・設計・文書化・管理に用いられている[1]。
フローチャートは複雑なプロセスやプログラムの設計および文書化に使われる。他の図と同様、何が行われているかを視覚化するのを助け、それによって見る者がプロセスを理解するのを助け、さらには欠陥・ボトルネック・細かい特徴などを発見できることもある。フローチャートには様々な種類があり、それぞれ固有の部品（箱）や記法を持つ。最も一般的な箱は次の2種類である。
ページをいくつかに分割し、異なる組織の制御を異なるスイムレーンに描く形のフローチャートは「部門間協力」型のプロセスを表せる。特定のレーンに描かれた部品群はその組織の制御下にあるプロセスを意味する。この技法は各活動の責任分担を明確化でき、意思決定を正しく行えるようにする効能がある。全体として一つのプロセス（事業、プロジェクトなど）を実施する際の各組織の責任を明確化できる。
プログラミング言語の教育においては、処理を理解するために用いられることがある（たとえば、for (i = 0; i < 10; ++i) という字面からだけでは、「繰返しの1回目では ++i は実行されない」「2回目からの繰返しの前に ++i と i < 10 の判定がこの順に行われる」といったことがわかりづらいため、そういったことを可視化するには適している）。事務処理においては、提出資料の様式として要求する者がいるため、使わざるをえないこともある。日本の特許の実務では、これを避け後述する構造化チャートであるPADで手続きを記述し特許を取った前例がある[2]。
問題解決においてフローチャートを作成する意味は、
などがある。[3]
フローチャートはプロセスのある側面を描いたもので、他の側面は他のダイアグラムで補完される。例えば、石川馨は品質管理の七つ道具として、グラフ、ヒストグラム、パレート図、チェックシート、管理図、特性要因図、散布図を挙げている。また、非形式的なモデリング言語としてUMLがあるが、数あるダイアグラムのうちのアクティビティ図はフローチャートのように制御フローを書くことに使うことができる。
いずれにしても、コンピュータ科学の観点からは、フローチャートは、コンピュータのプログラミングにおいて無条件と条件分岐の分岐命令（goto文とif文）だけを制御構造として使っているような「構造化以前の存在」、として扱われている。構造化をフローチャート（的な図法）に取り入れた試みについては、#構造化フローチャートの節を参照。
.jpg)
プロセスの流れを文書化する最初の構造化技法として「フロー・プロセス・チャート」がある。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のアクティビティ図はフローチャートを表記変更および拡張したものとも言える。ただし、アクティビティ図は制御フローだけでなく並行動作やデータフローもある程度表現できる。
右図は、階乗の計算方法を示したフローチャートである。
最も重要で注意すべきなのは、階乗を計算するアルゴリズムの本質は、箱の中に補助的に（したがって以下の解説ではロクに触れていないが）書かれている、変数を参照している演算式や、変数の代入といったもので表現されていて、「フローチャート」の箱や矢印は、その順序付けを表現しているに過ぎない、ということである。
各工程（処理）を示す絵図の標準の一つとしては「情報処理用流れ図・プログラム網図・システム資源図記号」[10]があり、またその他に多数の標準や規格や仕様や各社まちまちのローカルルールなどがある。
部品の論理的順序を保つことが重要である。あらゆるプロセスは上から下、左から右に流れるべきである。
制御フローではなくデータフローを表現するデータフロー図を描くための部品の規格化が行われてきた。そのような部品は制御フローを表すフローチャートでも特に平行四辺形の「入出力」部品を詳細化するのに使われている。
なお、そもそもコントロールのフローとデータフローは違うものであるため「（フローチャートの）データフロー的拡張」として両者を混用すると、フローチャートの「代入などの操作を表現する箱」と、データフロー図の「データを保持したり加工する実体を表現する箱」が混在することになり、同様に「順次的な手続きの流れ」を表現する矢印と「データの流れ」を表現する矢印が混在することになる。
Sterneckert (2003) によれば、フローチャートは様々なユーザーグループ（管理者、システムアナリスト、事務員など）の異なる観点からモデル化でき、それらは次の4種類に分類できる[11]。
どのフローチャートも流れ自身ではなく、ある種の制御に着目したものであることに注意が必要である[11]。
他にもいくつかの分類がある。例えば、Andrew Veronis (1978) は、システムフローチャート、概要フローチャート、詳細フローチャートという3つに分類した[12]。また同年、Marilyn Bohl (1978) では「実際、ソリューションプランニングにおいてはシステムフローチャートとプログラムフローチャートの2種類のフローチャートが使われる」と記している[13]。さらに最近の Mark A. Fryman (2001) ではさらに様々な種類があるとし「意思決定フローチャート、論理フローチャート、システムフローチャート、製品フローチャート、プロセスフローチャートは、ビジネスや政府で使われている様々なフローチャートのほんの一部である」と記している[14]。
さらに、フローチャートとよく似たダイアグラム技法を異なる名前で呼んでいる場合もあり、例えば、UMLのアクティビティ図がある。
可逆フローチャート[15]は、計算プロセスの可逆性に焦点を当てたコンピューティングのパラダイムを表している。演算が不可逆であることが多い従来の計算モデルとは異なり、可逆フローチャートは、どのようなアトミックな計算ステップも可逆であることを保証する。 可逆フローチャートは、可逆チューリングマシンと同等の表現力を持つことが示されており、構造化可逆プログラミングやエネルギー効率の高い可逆コンピューティングシステムの理論的基礎となっている。[16]
JISで標準化された図法は、工業・情報処理でどうしてもフローチャートで書かなければならない場合に用いられることが多い。一方、株式公開や内部統制のフローを描く場合には、以下のような形式のフローチャートを用いることがある。
フローチャートはいわば、goto文とif文だけでプログラミングしているようなものであるため、プログラミングに構造化プログラミングがあらわれたように、段階的詳細化などの問題解決の手法をきちんと反映するような、より良い図法とされるものが、いくつも考案された。そのような図法としてNS図（w:Nassi–Shneiderman diagram、DIN 66261）の他、ISO/IEC 8631（対応するJISとして、JIS X 0128）のAnnex A（informative）には、以下の種類の図法が示されている。
また他に YAC (Yet Another Control chart、富士通) がある。
これらがさほど普及しなかった理由としては、ノイマンらがフローチャートをプログラミングの補助として採用した頃の機械語プログラミングからの時代の経過で、構造化をサポートした高水準プログラミング言語などにより、むしろこういった図法よりもアルゴリズムをより明確に、プログラミング言語で直接書けるようになったことがある。また全く技術的でない理由として、唯一に標準化されたものでなければ使えないとする信仰のようなものから、このようにたくさん提案されているのでは採用できない、といったようなものもある。
またこれらを使う際には、数個以上の箱が縦に並ぶようなことは可能な限り避けきちんとサブルーチンとして切り出すなどして、「フローチャートの欠点」とされるような書き方は戒められなければならない。そういったことから「フローチャート」の語を避けて、構造化チャートと呼ばれることもある。
作図プログラムならフローチャートを描画できるが、単に図として描画するとデータベースやプロジェクトマネジメントシステムや表計算ソフトとデータを共有するデータモデルを提供できない。一部のツールはフローチャート描画のための機能をサポートしている。また、何らかのソースコードあるいはフローチャート記述言語から自動的にフローチャートを生成できるソフトウェアも多数存在する。ウェブ経由でオンラインで使えるツールも存在する。
Seamless Wikipedia browsing. On steroids.
Every time you click a link to Wikipedia, Wiktionary or Wikiquote in your browser's search results, it will show the modern Wikiwand interface.
Wikiwand extension is a five stars, simple, with minimum permission required to keep your browsing private, safe and transparent.
