他にない、上質なITを

Column

フローチャートとプログラミングの悩ましい関係


Pocket

プログラミングの研修を行っている同業の方や、スクールのカリキュラムをチラッと見せて頂いたのですが、最近では「フローチャート」を教える機会が減っているように感じます。オブジェクト指向が主流となった今の時代においてはUMLのようなより適したダイアグラムが出てきたことも一因かもしれません。

当社のプログラミング研修カリキュラムでも、フローチャートの書き方をみっちりと教えることはしておりません。粒度の問題があるからです。

フローチャートの粒度問題

フローチャートで問題になるのは、処理の粒度をどこまで書くかです。フローチャートで変数Xに10を代入して〜ループの中でtmpに入れて〜という様な「疑似コーディング」をしてしまうと、フローチャートとしては細かすぎます。

現代のオブジェクト指向プログラミングにおいては、一つの変数の中に表現できる情報を無限に詰め込むことが出来るので、処理の流れよりもデータ構造を可視化して、この変数はこのように変遷していくのだと書いたほうが設計書としてわかりやすいです。

フローチャートを詳細に書くことより、変数や引数などのデータをどう定義するか。その違いがプログラムの品質に大きく影響を与えます。データ構造だけでなくクラス構造がどうなっているかも考慮しないと行けない時代ですので、プログラミングを教えることが本当に難しい時代です。実行環境は容易に構築できるようになりましたが、そこから先へのステップアップはいつの時代も自己研鑽が欠かせません。

フローチャートを書く最大の目的は、プログラムやアルゴリズムを図にすることでわかりやすく表現し、設計思想を共有することだと考えています。複雑なものを簡単に表現することが狙いですが、そういった抽象化が行えるまでには鍛錬が必要です。細かくて複雑なものをそのまま表現するほうが楽だからです。それでは意味がない。複雑者に構造を与えて単純化するのが、設計の意味する所です。

机上デバッグの是非

「机上デバッグ」という言葉があります。端的には汎用機の時代においては、マシンリソースが潤沢ではなくプログラムの実行そのものに時間がかかり、簡単にプログラムの修正と実行が行えない環境でした。コードにミスが有るとマシンのOSが落ちることもあったので、実行したらバグは許されないのが常識だったと記憶しています。

コーディングの内容をExcel方眼紙に近いチャートに書き下ろし、ソースコードの処理内容を頭に叩き込んでレビューを受けて、はじめてプログラムの実装が可能になるというものです。

ソースコードを十分に把握しているので、机上でのデバッグが可能。この変数にこの値が入れば「必ず」こういうデータになるので、自分の作成したプログラムコードの全容を把握できる。その能力が無いのにプログラマであるというのはどうなのだ、というのが机上デバッグでプログラミングを叩き込まれた方の主張です。

確かに自分の書いたコードの意味がわからない(処理内容を把握していない)のは問題ですが、30年前と現在ではプログラミングで表現できる物事の幅が桁違いです。OSSによるライブラリの数も増える一方なので、全てを把握することが現実的ではありません。もちろん、意図しない動作をした時はOSSのコードを当たる必要はあるのですが。

フローチャートで疑似コーディングは、プログラミングの表現力を殺します。プログラムの設計手法としてオブジェクト指向が当たり前となり、データを表現する型が増え、例外/オブジェクト/同期非同期/スレッド/ジェネリクス/高階関数など…コードで表現できる幅が広がっており、細かく書ききることすら困難です。

プログラミングの設計を図で表すこと自体が難しい行いなのですが、フローチャートを再発明する時期に来ているのかもしれません。

プログラムを作ることで、論理的思考を養う

プログラミングで重要なのは、「課題を分解して、小さな目標をつなぎあわせてゴールを目指す」という道筋を作る力が求められます。プログラミングは、YES or NOの2つしかありません。制御構造としてあるのは、条件分岐と繰り返しだけで、これらをうまく使い分けながら、様々なケースに対応して適切な道順を作る必要があります。論理的思考と言い換えてもよいでしょう。こういった構造を与えてこういう前提に立てば、必然的にこのような結果になるというモデル化が必要になります。

そう書いてしまうとかなり堅苦しいので、私はゴルフのコースマネジメントに近いと思って、こういう例え話をします。

グリーンの方向がわかっても、適切な能力がなければ打数を叩いてしまいます。OBであったり、ラフやバンカーに捕まったり、色んな「罠」がプログラミングの中には潜んでいます。アマチュアゴルファーにハンディキャップが必要なのは、能力不足もマネジメント不足も過分にあるからです。

熟練されてくると似たようなコースでもコースの特性や環境依存の状況を捉え、適切な方向にティーショットを放ち、フェアウェイをキープしながらより少ない打数でホールアウトすることが出来ます。

当社のプログラミング研修では、プログラミングの文法だけでなく、プログラムを作るための考え方や理屈の組み立て方を、紙とペンで書かせて図解を行いながら学ぶスタイルを採用しています。


IT企画の進め方

IT企画、ITプロジェクト支援

会社や事業を変革するために必要なITをどうやって企画して、プロジェクトをどう立ち上げて、成功裏に導くのか。当社はそのためのノウハウを全て公開しています。IT企画から構想立案、要件定義までの支援をさせて頂いています。

IT企画・プロジェクト支援へ

システム内製化支援

様々な開発ツールを使い、御社の業務システムを共に作り上げ、最適な会社の仕組みを作ること。将来的には自立した内製化チームを立ち上げ、業務改革に貢献するソフトウェアの開発・運用を担うメンバーの育成を同時に実現するご支援です。

システム内製化支援へ

お問い合わせはこちらから