プログラミングにフローチャートはいらない？【粒度が詳細なら不要】
エンジニアの方：
プログラミングの仕事で、正直フローチャートっていらない気がするだけどなぁ。だって、最初からコーディングしたほうが早い気がするから。
プログラミングにおいて、フローチャートがいるかいらないか、現役エンジニアに話を聞いてみたい。
今回はこのような悩みについて解説致します。
プログラミングにフローチャートはいらない？【粒度が詳細なら不要】
フローチャートって、プログラミングや情報処理を勉強すると必ず聞く言葉ですよね。
そして、コーディングの前にフローチャートって、実際の業務でも使うには使うのですが、正直微妙じゃないですか？
プログラミングにフローチャートは、詳細粒度なら必要ありません。
なぜなら、詳細すぎるフローチャートを書くくらいなら、コーディングしたほうが早いからです。
コードレベルのフローチャート記載は消耗するだけ
フローチャートときくと、「コードで実装する処理を詳細に図にしてかく」ってイメージがありますよね。
ほとんどの書籍で、そのような解説や例題を出しているので。
勉強段階では、まあそんな感じでいいのですが、業務でそれやると、正直消耗します。
教科書とかで出てきそうそうですが、実際これやってみてください。
かなりシンドイですよ。
コードの１行レベルで書いていくうちに、
- 途中、処理の追加や条件追加が発生
- 序盤ならすぐ修正できるが、かなり書き終わった後に追加、削除があるとメンテが大変
- レビューで指摘が入っても同様
こんな感じだからです。
正直、その粒度で書けば、コーディングでやることは、何も考えず、単にフローチャートをコードにするだけの作業、いわゆるデジタル土方となります。
で、そこでもしコード間違ったらどうします？単にコードが間違ってるだけならいいが、フローチャート自体が間違ってたら
- まずフローチャートを直す
- そのあとコードを直す
・・・ツライです。
なので、コードレベルのフローチャートは、ただ疲労するだけとなります。
そのようなところですと、詳細なフローチャートは有効です。てかむしろ必須です。
とはいえ、俯瞰的にみるとそのやり方自体が不毛な気がするのは自分だけでしょうか。。。
概要レベルのフローチャートなら、処理の整理として有効
では、どのくらいの粒度がよいのでしょうか？それは、「処理の固まりを時系列に表現する」レベルでよいのかなと。
例えば、じゃんけんでいうならこんな感じ。
- 変数A,Bを初期化
- 〇〇関数をコール
- 〇〇関数から、ユーザの出し手情報を取得し、変数Aに代入
- ・・・
こんな感じで書くのに比べ、
- ユーザの出し手情報を取得
- コンピュータの出し手情報算出
- 勝敗を判定する
このように書いたほうが、
- すぐに書ける
- コーディング前に、コード化したい内容をイメージできる
- 仮にコードに細かい修正が入っても、フローチャートは修正不要
また、巷でも同様の考えの人も一定数いるみたいですね。
なので、コーディング前にフローチャートを書くなら概要レベルとし、細かいことはコーディングしながら考えればよいのかなと。
では、詳細レベルのフローチャートは全く価値がないのか？
ここまで書くと、「なら、詳細なフローチャートには全く価値がないのか！？」
と、思ってしまうかもしれませんが、もちろんそんなことはありません。
なぜなら、コーディング前に詳細なフローチャートを記載することで、コーディングの際にバグを埋め込む確率は下がるからです。
とはいえ、そのような詳細なフローチャートを書くのには、下記の通り、あまりに代償がありすぎます。
- 時間がかかる
- どんなにがんばっても、コードを修正しなくてよいという保証がない
- 状態遷移図を書き、遷移条件や処置の抜け漏れ検討
- デシジョンテーブルを書くことによる、条件、処理を網羅的に検討
これらがすべてではないですが、このような、「コード詳細化でなく、検討内容に抜け漏れがないかの検討」に時間を使ったほうがよいのではないでしょうか。
なので、フローチャートは概要レベルに留め、さっさとコーディングしてしまったほうが早いです。
プログラミング以外でもフローチャートは有効
これまで、コーディング前に記載するフローチャートは、詳細粒度なら不要であることを解説しましたが、フローチャートは、何もコーディングのためだけに用いる技法ではないです。
フローチャートは、コーディング以外にも有効な技法です。
なぜなら、
- 順に処理を進めるから
- 場合により処理が分かれるには分岐が使えるから
- 概要レベルなら、文字で書くより、直感的にわかりやすいから
このような特徴が、モノゴトの処理の流れを説明するのに非常に有効だからです。
業務プロセス書の記載として使えます
フローチャートを製品開発以外で使う方法として、業務プロセス書の記載が挙げられます。業務プロセスって、以下のようなものですよね。
- 上から順番に進めていく
- 途中、この時はこれ、あの時はあれ、のように分岐がある
これって、つまりはフローチャートそのものですよね。
なので、例えばですが、フローチャートは、このように業務プロセス書の記載としても有効です。
開発以外でも、モノゴトの処理の流れを説明するのに使えます
フローチャートは、開発以外のことにも使えます。
なぜなら、モノゴトを上から順番に並べるようなものを表現可能だからです。例えば、
- カレーの作り方
- 会議室の予約の仕方
- 書類承認手続き
などなど、言い出したらきりがありません。
このようなものを書く時は、文章だけだと読むのも理解するのもシンドイので、フローチャートによる図解のほうが理解が圧倒的に高まりますよね。
なので、開発以外でも、モノゴトの処理の流れを説明するときには、フローチャートは有効です。
- 詳細レベルの粒度：コーディング前に詳細まで設計できるが、そこまでするならコーディングしたほうが早い
- 概要レベルの粒度：コーディング前に流れを整理できるが、コーディングしながら詳細を考える必要がある。また、開発外でも使える
なので、フローチャートは、基本は概要レベルに留めて書く、でよいかと。
今回は以上です。