他にない、上質なITを

Column

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


Pocket

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

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

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

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

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

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

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

机上デバッグの是非

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

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

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

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

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

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

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

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

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

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

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

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


おすすめ記事

最後までお読みいただきありがとうございました。
こちらの記事にご興味を持っていただいた方には、こちらの記事もおすすめです。

執筆者について

著者

(株) クオリティスタート 代表取締役

湯本堅隆(YUMOTO Michitaka)

略歴

1979年生まれ。ISPの電話サポートのアルバイトをきっかけにIT技術に興味を持ち、2003年にアイ・ティ・フロンティア(現タタ・コンサルタンシー・サービシズ)に新卒で入社。

SIer在籍期間からブログ「GoTheDistance」でSIerを巡るIT業界のあり方・エンジニアのキャリアについて記事を書き、累計はてなブックマーク数40,000を超えるブログになりました。

「ITを使いこなしたいなら、ユーザー企業は内製すべき」と主張しているうちに、2009年から雑貨卸の有限会社 エフ・ケーコーポレーションで内製化を1人で担当するはめに。メーカー送料ロットのない雑貨卸というビジネスモデルをITシステムを実装することで確立し、経済産業省が主催するIT経営実践認定企業に選ばれました。

「システムを作る人材や会社」はあっても「何が正しいITシステムなのか」を事業会社の立場で考え、デザインできる人材が枯渇している。

この課題を解決したいという思いから、会社を創業しました。

重度の野球好きで、東京ヤクルトスワローズのファンです。



IT企画の進め方

ITプロジェクトの進め方、公開中

事業を運営するために必要なITや業務システムの企画の作り方、プロジェクト担ってからの進め方をワークフローという形で完全無料公開しています。10000文字超えの力作です。是非御覧ください。

ITプロジェクトの進め方

IT戦略・IT企画の無料相談承ります。

ITプランナーが御社にお伺いして、御社のシステム企画のディスカッション・パートナーをさせて頂くサービスです。60分時間限定ですが、IT企画のモヤっとスッキリさせるお手伝いをさせて頂けたら。

ITプランナーへの無料相談

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