プログラミングの研修を行っている同業の方や、スクールのカリキュラムをチラッと見せて頂いたのですが、最近では「フローチャート」を教える機会が減っているように感じます。オブジェクト指向が主流となった今の時代においてはUMLのようなより適したダイアグラムが出てきたことも一因かもしれません。現代のオブジェクト指向プログラミングにおいては、一つの変数の中に表現できる情報を無限に詰め込むことが出来るので、処理の流れよりもデータ構造を可視化して、この変数はこのように変遷していくのだと書いたほうが設計書としてわかりやすいです。熟練されてくると似たようなコースでもコースの特性や環境依存の状況を捉え、適切な方向にティーショットを放ち、フェアウェイをキープしながらより少ない打数でホールアウトすることが出来ます。そう書いてしまうとかなり堅苦しいので、私はゴルフのコースマネジメントに近いと思って、こういう例え話をします。様々な開発ツールを使い、御社の業務システムを共に作り上げ、最適な会社の仕組みを作ること。将来的には自立した内製化チームを立ち上げ、業務改革に貢献するソフトウェアの開発・運用を担うメンバーの育成を同時に実現するご支援です。フローチャートを書く最大の目的は、プログラムやアルゴリズムを図にすることでわかりやすく表現し、設計思想を共有することだと考えています。複雑なものを簡単に表現することが狙いですが、そういった抽象化が行えるまでには鍛錬が必要です。細かくて複雑なものをそのまま表現するほうが楽だからです。それでは意味がない。複雑者に構造を与えて単純化するのが、設計の意味する所です。フローチャートで問題になるのは、処理の粒度をどこまで書くかです。フローチャートで変数Xに10を代入して〜ループの中でtmpに入れて〜という様な「疑似コーディング」をしてしまうと、フローチャートとしては細かすぎます。グリーンの方向がわかっても、適切な能力がなければ打数を叩いてしまいます。OBであったり、ラフやバンカーに捕まったり、色んな「罠」がプログラミングの中には潜んでいます。アマチュアゴルファーにハンディキャップが必要なのは、能力不足もマネジメント不足も過分にあるからです。プログラミングの設計を図で表すこと自体が難しい行いなのですが、フローチャートを再発明する時期に来ているのかもしれません。当社のプログラミング研修カリキュラムでも、フローチャートの書き方をみっちりと教えることはしておりません。粒度の問題があるからです。会社や事業を変革するために必要なITをどうやって企画して、プロジェクトをどう立ち上げて、成功裏に導くのか。当社はそのためのノウハウを全て公開しています。IT企画から構想立案、要件定義までの支援をさせて頂いています。プログラミングで重要なのは、「課題を分解して、小さな目標をつなぎあわせてゴールを目指す」という道筋を作る力が求められます。プログラミングは、YES or NOの２つしかありません。制御構造としてあるのは、条件分岐と繰り返しだけで、これらをうまく使い分けながら、様々なケースに対応して適切な道順を作る必要があります。論理的思考と言い換えてもよいでしょう。こういった構造を与えてこういう前提に立てば、必然的にこのような結果になるというモデル化が必要になります。フローチャートで疑似コーディングは、プログラミングの表現力を殺します。プログラムの設計手法としてオブジェクト指向が当たり前となり、データを表現する型が増え、例外/オブジェクト/同期非同期/スレッド/ジェネリクス/高階関数など…コードで表現できる幅が広がっており、細かく書ききることすら困難です。フローチャートを詳細に書くことより、変数や引数などのデータをどう定義するか。その違いがプログラムの品質に大きく影響を与えます。データ構造だけでなくクラス構造がどうなっているかも考慮しないと行けない時代ですので、プログラミングを教えることが本当に難しい時代です。実行環境は容易に構築できるようになりましたが、そこから先へのステップアップはいつの時代も自己研鑽が欠かせません。コーディングの内容をExcel方眼紙に近いチャートに書き下ろし、ソースコードの処理内容を頭に叩き込んでレビューを受けて、はじめてプログラムの実装が可能になるというものです。当社のプログラミング研修では、プログラミングの文法だけでなく、プログラムを作るための考え方や理屈の組み立て方を、紙とペンで書かせて図解を行いながら学ぶスタイルを採用しています。ソースコードを十分に把握しているので、机上でのデバッグが可能。この変数にこの値が入れば「必ず」こういうデータになるので、自分の作成したプログラムコードの全容を把握できる。その能力が無いのにプログラマであるというのはどうなのだ、というのが机上デバッグでプログラミングを叩き込まれた方の主張です。「机上デバッグ」という言葉があります。端的には汎用機の時代においては、マシンリソースが潤沢ではなくプログラムの実行そのものに時間がかかり、簡単にプログラムの修正と実行が行えない環境でした。コードにミスが有るとマシンのOSが落ちることもあったので、実行したらバグは許されないのが常識だったと記憶しています。確かに自分の書いたコードの意味がわからない(処理内容を把握していない)のは問題ですが、30年前と現在ではプログラミングで表現できる物事の幅が桁違いです。OSSによるライブラリの数も増える一方なので、全てを把握することが現実的ではありません。もちろん、意図しない動作をした時はOSSのコードを当たる必要はあるのですが。 この記事で umlを使って描いた 状態遷移図（ソフトウェア設計図）について説明しています！. フローチャートを書く能力はプログラマーにとって必須スキルであり、優秀なプログラマーになるための第一歩です。なぜなら、フローチャートの有無、もしくはフローチャートの内容次第で出来上がるプログラムの品質に大きな差が出るためです。 プログラミング教育で切っても切り離せないもの。それがフローチャートです。 プログラムの設計やロジカルシンキングの解説などに登場するため、理数的な印象を持っている方もいらっしゃるようですが、全く難しいものではありません。 傾向としては立場が上の管理者・責任者の場合が多く「大体こんな感じでやっています」というような書き方になるのが特徴です。フローチャートを利用するシチュエーションはさまざまです。システムの設計やプログラムの設計、業務を表すフローから、占いのような絞込みチャートまで幅広く利用されています。ここではその種類について１つ１つ解説していきたいと思います。プロジェクト担当者の多くが頭を抱える問題、それが業務フローチャートの粒度についてです。外部コンサルタントと自社メンバーによるハイブリッド運営外部コンサルタントの利用のメリットがわかったとしても、実際...ましてや、条件分岐などですべてのパターンを表現してはいけません。業務フローチャート作成のステップ業務フローチャートを作成にはいくつかの工程がありますが、優先すべきものと、後回し...細かすぎる、粗すぎる、といった偏りのない担当者、例えば事務局などが補正をしていきます。基本的には業務が細かくも洗い出されている状態なので、事務局担当者の判断で次々とまとめあげていくだけで補正を進めていけます。業務フローチャートを作成する目的によって、正しい粒度というのは異なります。なので残念ながらコレといった正解はありません。業務改善を始める前に現状を把握する業務改善を行うにしても、改善というからには何か基準があって、それに対する変化を...業務フローチャートのサンプル解説コーナーです。今回のツールは無料のフリーソフト「CaCoo（カクー）」で作成しました。一番シンプルな書き方で書いた場合の解説をしていきたいと思います。ついつい、業務をよく知っている方＝立場が上の方が話した内容はすべて業務フローチャートとして落とし込まなければならない心境になりがちですが、そこはぐっと抑えて、業務フローチャート本来の視認性を優先させ、細かい情報は業務フローチャートに展開せず、別途詳細情報として記載しましょう。よくありがちなのが、個社別対応の業務をフローチャートとして落としこんでしまったり、状況に応じた対応などを、判断図形を使用して条件分岐で全パターンを表現してしまうのですが、これはせっかく簡潔で視覚的に理解できる業務フローチャートの特性をすべて台なしにしてしまいます。業務をよく知っている方にヒアリングを行った場合にありがちな落とし穴があります。それは、業務をヒアリングしていくと「状況による」「場合による」といった回答です。いわゆる例外処理なのですが、よく業務を経験されているからこそ出てくる情報です。業務フローチャートを見る人の多くは、どれかの担当者の目線で評価する場合がほとんどで、その担当者の区切りが明確になることで、ほかの担当者の作業を区別して自分の知りたい業務を集中して評価することができます。作業する担当者が変ったときに、別の図形で表現するというルールを定めることで、わかりやすい業務フローチャートに仕上がります。進め方としては、同じく事務局担当者がヒアリングを通じて１つ１つ細かく聞いていく他ありません。具体的には、業務フローチャートを作成した担当者にヒアリングを行いながら、洗い出された細かいオペレーションレベルの作業をある程度の粒度にまとめあげていきます。（ある程度の粒度は後述）フローチャートを書く際に悩んでしまうことの１つとして「使用する記号」が挙げられます。フローチャートの主役でもある記号。その種類や呼び方、役割などもいろいろありますので解説します。ひどい場合には作業図形１つに対して、文章のように作業名がかかれていることもあります。現場に近い担当者レベルの方が書いた業務フローチャートですが、どのシステムのどのメニューのどこどこを実行する、といったような細かい粒度で書いてしまう傾向にあります。特に情報システム部門の担当者の場合、「受信日付を確認して、フラグを0から1に変更して・・・」といった、オペレーションレベルの作業を細かく書いてしまいがちです。これは参画する担当者の属性（所属する部門、その立場など）によって、業務フローチャートの粒度に対する認識が大きくことなることが原因となっています。ポイントとしては、その業務のトリガーに注目すると良いでしょう。発生トリガー、パターンを軸に、どこから発生し、どのような作業があるのかを１つ１つ聞いていきます。それは、これらの事象を１つ１つの業務フローチャートとして起こさないことです。入力、確認、照合など、処理の対象物が変わるタイミングで図形を分けるのも効果的です。それは上記のルールのいずれにも該当せず、一連の処理となる場合です。非常に細かい業務フローチャートを書く方がいる一方、非常に粗い業務フローチャートを書く人も出てきます。業務フローチャートを複数のメンバーで書き始めた場合、この粒度をはじめとした業務フローチャート品質のばらつきが必ず発生します。粒度が細かった先ほどの例とは対照的に、必要な情報がすべて洗い出されていない可能性が高いので、業務に抜け・漏れがないか最新の注意を払う必要があります。特にマニュアルとしての業務フローチャート作成を目的とした場合ですが、作業・処理の対象物が複数混在していたり、入れ替わると混乱してしまいます。例えば、「お客様属性の確認」という作業「1.顧客情報確認」「11.条件抽出」「112.お客様属性」といった画面遷移などのオペレーションが該当します。対象を固定して表現してあげると、頭の中で思い描くイメージがすっきりし、理解しやすくなります。業務改善や業務改革に役立つ情報を掲載しています。情報掲載希望、取材希望、広告掲載の相談はお問い合わせフォームよりお願いします。しかし、ある程度の基準をルールとして定めることで、業務フローチャートの粒度を近づけることができます。システムの要件定義を目的とした場合は図形を分けるべきかもしれませんが、業務の把握レベルであれば「お客様属性の確認」といった図形１つにまとめてしまうほうが利便性が高まります。