フローチャートの必要性・大切さについて
何で作るのか、なぜ必要なのか

ソフトウェア関連の会社に入ったとき、研修でフローチャートの書き方を説明されると思います。

研修中苦手でもどうせ実務では書かないし別にいいか。

など考えている人も多いと思います。

今まで何人か新人・若手を見てきましたが、過去見てきた新入社員も、ほぼ全員がそうでした。

個人的にはフローチャートは書けないと困ると思っています。

フローチャートの必要性や大切さについて書いていこうと思います。

フローチャートとは

まず、フローチャートとは何か。

フローチャートは、プログラミングを行うときにロジックを書いて行って正しくコーディングをするためのものです。
事前にフローチャートを作ることで、事前にレビューし、机上でバグをなくしてからコーディングを行い動作時のバグを減らすためのものでした。
ホストコンピュータを使用していた時代は、１回のコンパイルや実行に費用がかかっていたためこのような作業をしていました。

しかし、近年は納期が短くなっていることもあり、デバッグしながらコーディング をするということも多くなっています。
自端末で動かしながらコーディングをしても費用はかかりません。
慣れている人であればそれで時間短縮になっています。

ですが、新人や経験があまりない人が動かしながらコードを書くと、無駄なロジックが入ってしまう可能性が高いです。
また、探り探りで作ってしまうため余計に時間がかかってしまう可能性もあります。
まず、どんな処理であってもロジックはシンプルであるべきです。
無駄なコードがあるとバグの原因になります。

余談ですが、絶対にバグを作らない方法を知っていますか？
コードを書かないことです。
コードを書かなければバグは発生しません。

そのバグの原因となるコードを出来る限り減らして、単純なものにしていくためにフローチャートは必要だと考えています。

フローチャートを使用する場面

若手の社員で「フローチャートを書いてもしょうがない」「書けないから書かないという」と言っているのを目にします。

そんなことはないはずです。

現在、私はPGからSEをやってきて１０年弱になりますが、いまだにフローチャートを使う場面があります。

その主な３つの場面について紹介します。

①処理の内容を説明するとき

保守の作業を行っていると、故障が発生したときに原因を説明することがよくあります。

その説明をメールで行うということがあるのですが、そのとき文章だけでは、なかなか伝わりません。

文章だけだと、受け取り方の違いや伝わり方によって認識の齟齬が発生しやすいです。

そういうときに、補足の資料としてフローチャートをつけます。

フローチャートをつけることで、処理の流れが伝わるため認識齟齬が無くなります。

そして、メールの本文を読むことで伝えたかったことが正しく伝わりやすくなります。

②頭の中を整理するとき

経験年数を積むごとに、難しい処理を任されることは多くなります。

技術的には上がっていますが、やはり煮詰まってしまうことはあると思います。

煮詰まった状態でどんどんコードを書いていくと、張りぼてで、本来であれば無駄なコードをたくさん書いてしまっていることがあります。

そんなときに、フローチャートを書けば一旦コードから離れるので冷静になり、処理の流れが改めて見えてくるので綺麗なコードを書くことができます。

③解析を行うとき

故障の原因特定や、機能追加の影響調査を行う際にコードの解析を行うことがあります。

そのとき、コードだけ見ながら追っていく混乱してしまい、どうなっているのか分からなくなってしまいます。

フローチャートを書いていれば、追って行った記録が残っていくので、前の処理に戻ったときにも何を見ていたかすぐに思い出すことができます。

また、故障の原因を調査しているときには書きながら頭の中で整理できているので、早く原因を特定することができます。

まとめ

今回はフローチャートの必要性や大切さを説明しました。

納品物ではないため必ずしも書かないといけないとは言いません。

悪く言えばメモにしかなりませんが、されどメモです。

打ち合わせではメモを取るのに、コーディングだとメモを取らなくなるのはおかしいですよね。

なんのためにやるか。

自分の作業を円滑に行うためです。

そして、自分の評価を上げていくためです。

メモなので綺麗に作る必要はありません。時間をかける必要もありません。

自分のために作成してみてください。