■

使いどころはあるかといえばある。
ただし、対象はプログラマに向かないタイプの初心者に物事の手順をわからせるためってあたりにである。

業務ロジックもフロー通りにとかいう人たちがいる。
表現力がたりねぇ。
UMLのほうがいくばくかマシだ。
ネコでも読めそうな簡単なフローチャートのほうがわかりやすいのだが、
そんな貧弱なフローで業務は表現できない。
業務は、まっとうな流れと幾多数多の例外処理で成り立っている。
重要な例外をフローで表現できるのか？
しきれるのか？
否である。

フローチャート通りにプログラムを作ったとしても
そこで保障されそうなのはまっとうな流れのか細い一本だけで、
例外対処もなんにもできない貧弱な実装になるのがオチである。

そもそも、そんな程度のフローをことさら有難がることは全く必要じゃない。
初心者教育というが、そんなやつらを業務ロジックに携わらせるのがそもそもの間違いだし、*1
フローチャート以上のことができるように成長した以降はスパゲティとか心配しなくていいからだ。

そんな現実を目の前にしていまさらフローチャートなんて持ち上げる必要があるのだろうか？
否。
存在意義を否定されてしまうような、そんなレベルのエセ技術者ががんばるだけだろう。
ゆえに無いのだ。

業務プログラミングにおいて、プログラマに必要なのはこんなことくらいだろう。
　　・実装できるプログラミング能力
　　・命題を理解する頭
　　・人の話をきちんと聞く姿勢
これとは別に業務をきっちり把握しておく役と、
顧客との折衝結果や経緯を記憶しておく役がいれば事足りる。

何をやるか。
何が問題点でどうなればよいのか。
この回答にいたる経緯はなんであって、そもそも目的は何であったのか。
時間と経費とのバランスを見て、いくつかある対処法のうちどれを選ぶべきなのか。

きっとこれらの日常対処をどれだけ定量化して、
推し進めたい方向へ誘導するかってのが何かを作るうえで重要なのだが、
そこに大事なポイントがあって、
出来ないやつってのはホントになにやっても出来ないんだ。
でも多くは何か出来るもんで、それは書類整理やパターンテストの実行であったり、
ツールの作成だったり、何かのスクリプトやマクロの作成だったりする。
業務にかかわればマイナスしか発揮しないのだから、それ以外の雑多な作業の中から
解決されると便利な事象をこなしてもらえばマイナスがあっという間に0になる。
やればやるだけ後退するなんてジリ貧には陥らないのだが、
先のエセ技術者達からは倦厭される。
彼らにとっては「何か重要な作業に携わっている」ことがなにより大事な至上命題であり、
「みんなでこのプロジェクトを完了させる」ってことが至上命題であることが理解できていないからだ。

UMLも形骸化する。
フローチャートはプロジェクト完了後、ソースから起こしたものをみて、
処理を理解できた気になれる。
もしくはあまりにも膨大すぎて見ることを拒否する。
どっちみち形骸化している。

エキスパート達に学ぶ仕事っぷり。
要件やユースケースを押さえ、
やりたいことを見つけ、
それをプログラムしつつ微修正や調整を行うことで仕事が終わる。
要点を押えて的確に実行できればそれがBestだ。

要点は常にシンプルなことなんだな。

*1:マイナスの要因ってやつですよ。