プログラミングにフローチャートはいらない?【粒度が詳細なら不要】

CODE Programming

エンジニアの方:
仕事でフローチャートを書いているが、正直フローチャートって書く意味があるのだろうか?最初からコーディングしたほうが早い気がする。

今回はこのような悩みについて解説致します。

これを書いた自分はこんな人です学卒後、組み込みソフトウェアエンジニア職に従事。古くは基本情報の勉強でフローチャートを学び、業務でも作成した経験あり。また、コーディング以外の目的で、プロセス書の記載としてもフローチャートの作成経験あり。

本記事を読むことによる利点フローチャートは、基本概要レベルに留めて書けばよいことがわかるため、業務で詳細なフローチャートを書くことによる不毛な時間をカットでき、効率的に開発を進めるきっかけをつかむことができます。

プログラミングにフローチャートはいらない?【粒度が詳細なら不要】

フローチャートって、プログラミングや情報処理を勉強すると必ず聞く言葉ですよね。

そして、コーディングの前にフローチャートって、実際の業務でも使うには使うのですが、正直微妙じゃないですか?
プログラミングにフローチャートは、詳細粒度なら必要ありません。

なぜなら、詳細すぎるフローチャートを書くくらいなら、コーディングしたほうが早いからです。

コードレベルのフローチャート記載は消耗するだけ

フローチャートときくと、「コードで実装する処理を詳細に図にしてかく」ってイメージがありますよね。

ほとんどの書籍で、そのような解説や例題を出しているので。

勉強段階では、まあそんな感じでいいのですが、業務でそれやると、正直消耗します。

記載が詳細すぎるとほんとキツイ「コーディングする前に、フローチャートで実装する処理を予め明確にしましょう」

教科書とかで出てきそうそうですが、実際これやってみてください。

かなりシンドイですよ。
コードの1行レベルで書いていくうちに、

  1. 途中、処理の追加や条件追加が発生
  2. 序盤ならすぐ修正できるが、かなり書き終わった後に追加、削除があるとメンテが大変
  3. レビューで指摘が入っても同様

こんな感じだからです。

詳細粒度で書いた先は、それみてデジタル土方するだけせっせとがんばって、詳細粒度で書いたフローチャート。それが日の目を見るのは、コーディング時。

正直、その粒度で書けば、コーディングでやることは、何も考えず、単にフローチャートをコードにするだけの作業、いわゆるデジタル土方となります。

で、そこでもしコード間違ったらどうします?単にコードが間違ってるだけならいいが、フローチャート自体が間違ってたら

  • まずフローチャートを直す
  • そのあとコードを直す

・・・ツライです。

なので、コードレベルのフローチャートは、ただ疲労するだけとなります。

デジタル土方が専門の会社なら有効自分はやったことがないのですが、巷では、コード1行レベルのフローチャートを受領し、その通りにコーディングを行うのを生業にしているところがあるそうです。

そのようなところですと、詳細なフローチャートは有効です。てかむしろ必須です。

とはいえ、俯瞰的にみるとそのやり方自体が不毛な気がするのは自分だけでしょうか。。。

概要レベルのフローチャートなら、処理の整理として有効

では、どのくらいの粒度がよいのでしょうか?それは、「処理の固まりを時系列に表現する」レベルでよいのかなと。
例えば、じゃんけんでいうならこんな感じ。

  1. 変数A,Bを初期化
  2. 〇〇関数をコール
  3. 〇〇関数から、ユーザの出し手情報を取得し、変数Aに代入
  4. ・・・

こんな感じで書くのに比べ、

  1. ユーザの出し手情報を取得
  2. コンピュータの出し手情報算出
  3. 勝敗を判定する

このように書いたほうが、

  • すぐに書ける
  • コーディング前に、コード化したい内容をイメージできる
  • 仮にコードに細かい修正が入っても、フローチャートは修正不要

なので、コーディング前にフローチャートを書くなら概要レベルとし、細かいことはコーディングしながら考えればよいのかなと。

では、詳細レベルのフローチャートは全く価値がないのか?

ここまで書くと、「なら、詳細なフローチャートには全く価値がないのか!?」

と、思ってしまうかもしれませんが、もちろんそんなことはありません。

なぜなら、コーディング前に詳細なフローチャートを記載することで、コーディングの際にバグを埋め込む確率は下がるからです。

とはいえ、そのような詳細なフローチャートを書くのには、下記の通り、あまりに代償がありすぎます。

  • 時間がかかる
  • どんなにがんばっても、コードを修正しなくてよいという保証がない

状態遷移図やデシジョンテーブルを書いたほうがマシ詳細なフローチャートを書くくらいなら、それよりも他の手法による設計をしたほうが効果的です。例えば以下。

  • 状態遷移図を書き、遷移条件や処置の抜け漏れ検討
  • デシジョンテーブルを書くことによる、条件、処理を網羅的に検討

これらがすべてではないですが、このような、「コード詳細化でなく、検討内容に抜け漏れがないかの検討」に時間を使ったほうがよいのではないでしょうか。

なので、フローチャートは概要レベルに留め、さっさとコーディングしてしまったほうが早いです。

プログラミング以外でもフローチャートは有効

これまで、コーディング前に記載するフローチャートは、詳細粒度なら不要であることを解説しましたが、フローチャートは、何もコーディングのためだけに用いる技法ではないです。

フローチャートは、コーディング以外にも有効な技法です。
なぜなら、

  • 順に処理を進めるから
  • 場合により処理が分かれるには分岐が使えるから
  • 概要レベルなら、文字で書くより、直感的にわかりやすいから

このような特徴が、モノゴトの処理の流れを説明するのに非常に有効だからです。

業務プロセス書の記載として使えます

フローチャートを製品開発以外で使う方法として、業務プロセス書の記載が挙げられます。業務プロセスって、以下のようなものですよね。

  • 上から順番に進めていく
  • 途中、この時はこれ、あの時はあれ、のように分岐がある

これって、つまりはフローチャートそのものですよね。

なので、例えばですが、フローチャートは、このように業務プロセス書の記載としても有効です。

開発以外でも、モノゴトの処理の流れを説明するのに使えます

フローチャートは、開発以外のことにも使えます。
なぜなら、モノゴトを上から順番に並べるようなものを表現可能だからです。例えば、

  • カレーの作り方
  • 会議室の予約の仕方
  • 書類承認手続き

などなど、言い出したらきりがありません。

このようなものを書く時は、文章だけだと読むのも理解するのもシンドイので、フローチャートによる図解のほうが理解が圧倒的に高まりますよね。

業務していても、文章で説明するのと、絵を使って説明するのでは、後者のほうが圧倒的に他者の理解が早いです。なので、フローチャートも同様に有効です。

なので、開発以外でも、モノゴトの処理の流れを説明するときには、フローチャートは有効です。

と、いうことで、記載粒度を考慮しよう結局、フローチャートは下記の性質があります。

  • 詳細レベルの粒度:コーディング前に詳細まで設計できるが、そこまでするならコーディングしたほうが早い
  • 概要レベルの粒度:コーディング前に流れを整理できるが、コーディングしながら詳細を考える必要がある。また、開発外でも使える

なので、フローチャートは、基本は概要レベルに留めて書く、でよいかと。
今回は以上です。

関連記事コーディング初心者が会社の仕事でコーディングする時の注意点

関連記事【絶対にこうなるな!】プログラミング初心者あるあるのミスを紹介