流動的

組み合わせが多すぎる。

コンピュータのプログラムでは、if / else(YesかNoか)による条件分岐がつきもの。入れ子構造で、5段階深いところまで if / else が組み合わさると、2の5乗で32通り発生する。今回のケースでは、ざっくり100通り位は派生するかと、読んだ。この程度なら、黙々とやります。

最初から全体像が分かっているなら、データベースの基本設計をきちんとしておけば、「乗算」ではなく「加算」の数で、テストケースを済ませられる。2の7乗なら、128通り。それを、7通りのテストで済ませられるように、作れる。その辺が、年の功というか、短期間にプログラムを仕上げられる、ある意味で僕の自信だったんだけれど、完全に今は、メンタル崩壊。基本構造への修正が間に合わなくて、組み合わせで処理するとなると、テストしなければならないケースは下手したら1000通り近くなる。「自動テスト」のプログラムを書く、って言ったって、これから何週間かかるのよ。

紙ベースならわかるけれども、受注が確定した段階で「売上伝票」を作成する場合がある、と。これを実装するために、暫定的な「結果」をデータベースに書き込むようにした。実際には、ケーキを作る場合で言えば、スポンジの材料を調合して捏ねた、それだけで「商品」にする場合もあるから、そこでデータベースに「完成形」として書き込む。後から、コンパウンドを塗りました、その段階が追加されたら、また、「完成形」を定義し直すようにしました。当然のことながら、「ここは「削除したい」というのが、後から出てくる。今度は、この実装で煮詰まった。

何か一つ、操作する都度、全部のデータの整合性をチェックして、必要な「書き換え」を行うようなプログラムを書いて、毎回その都度データをそこに投げる。これで行けば、いいかも。無駄は多いけれど、ターンアラウンドは1秒以内で済むか?

ところが、「このページでは、売上済みの全データを見られるようにしてください」なんていう話があって(無論、検索条件は設定可能だけど、)、売上済み(ってか、受注の段階で「売上」伝票を作れる仕様だから、本当の「製造完了」なのか、見分けられない、それ)でも、過去に遡って全件表示をするとなると、データベースの全数を拾い上げる必要が出てくる。下手すると、半年したら、クリックするたびに、反応が戻るまで30秒かかる、なんていう騒ぎになりかねない。スーパーコンピュータをサーバに使えるなら、話は別だけれど。少しでも安く、っていうサーバでは、無理だと思う。「その点にご理解」はお願いしたけれど、「それ」が起きてしまってからどういう展開になるか。

悪意がないのはわかっているけれど、最悪の展開というか、もしかしたら、要求通りのシステム、仕上げられないような気がしてきている。いや、9割がた動作するシステムなら、仕上げられるけれど、細かいあれこれが起きたときのテストケースを、1ヶ月や2ヶ月では、テストし切れない、ということは、バグがある可能性を承知の上で、「普通の使い方なら、問題が起きない」レベルの形に、軟着陸というか、胴体着陸というか、仕上げて、後は、問題が起きてから対応するしかない、という感じに落ち着くんだろうか。とにかく、脳味噌が干上がるくらい考え抜いて、それなりの着陸地点を見つけるしかない。

文科省が、「情報技術」を小学校から教えると。
あのさぁ、プログラマとかシステムエンジニアになる人って、1%未満でしょ?全部の小学生に「アルゴリズム」なんかの教育をするよりも、高校生レベルに、せめて、ユースケース図とか、業務フロウをチャート化した「業務処理図」みたいなのを考案して、「発注する」側の教育をしっかりしてもらった方が、作る側としては、遥かにありがたい気がする。それ以前に、人が、紙ベースの台帳で仕事をする際には、相当に流動性が高いやり方をしているのもわかるけれども、コンピュータと人間の違いを、しっかりと理解できるように、それこそ、日本能率協会とかで出してたりする、作業連携のチャートの読み方、書き方みたいな奴(記憶不確か)を、高校生ぐらいから教えて欲しい気がする。事務作業の効率化にだって、使えると思う。

えぇと、このページ、僕が噛み付いているのは、クライアントさんではありません。頭が爆発しそうで、愚痴をこぼしているのは事実だけれども、文科省に、注文を入れてます。情報システムを作る側の立場の教育ではなく、使う側の、さらに言えば、発注する側の教育という視点で、カリキュラムを見直して欲しい。作る人数と、使う人数と、どちらが多いか、ちょっと考えてみて欲しいと思う。とにかく、まず、文科省には、最初に、作る側と、使う側の人口比を、きちんと把握して欲しいと思う。

以上