仕事場ではシステム・アーキテクトやシステム・アナリストの真似ごとをしています。
実際にやっていることは開発担体の情報処理業者や人材派遣業者からやってきているエンジニアたちが
「ど～すればいぃんですか？」
と、訊いてくるアレコレについてまとまりのよいコード・ライブラリとそれを利用し応用プログラム作成方針の準備と報知でしかないわけですが。
最近になって、ふと、気づいたことがあります。それは、
アプリケーションを作成したり改修しているエンジニアというのは、もはや不必要な(すくなくともパートタイマで充分なことでしかない)業種なのではないか？
ということなのです。
なぜ、アプリケーション・エンジニアのすべてを素人のパートタイマで置き換えてしまうべきだと、かんがえるのか？
私が出くわしてきた業務用アプリケーションにまつわる業務知識というのは特定のチューリング・マシンのプログラム・コードと同等なロジック記述でしかありませんでしたし、アプリケーション・プログラムを何年も使いつづけるために必要な柔軟性や頑腱性というのは状態遷移機械の実装の善し悪しのことでしかなかったからです。
業務知識を実装につなげるとは、ユーザ側のシステム部門が主体となって書き下す要件定義と、それを受けてインテグレータが書き下す機能設計レベルあたりの“仕様書”に記載された箇条書きや図表を“どのように読み下せばいいのか”についての手順を愚直に実装した専用チューリング・マシンを複数(多分、コンポーネント数の2, 3倍でしょう)つくり、箇条書きと表形式に載っている事柄をチューリング・マシンそれぞれのプログラム・テープに相当するデータ構造の初期化処理に変換するだけです。
柔軟性と頑腱性を両立させるには、トランザクション内容、ユーザ権限、ジョブ周期の違いなどなどの文脈に相当する情報に依存して実行時に変化するべき事柄を単に状態遷移機械として表現して先のチューリング・マシンに埋め込んでしまえばよいわけです。
ということは、開発にかかる前に要件定義と精精のところが機能分割程度までの検討を済ませ、そして仕様のどこをチューリング・マシン式を適用し、どれについては状態遷移機械で表現しておくのかの方式選定にユーザとインテグレータが納得してしまえば、業務コンポーネントであるとかビジネス・ロジック・レイヤなどと呼ばれている従来システムのコード量にして5%～10%程度のコーディング(チューリング・マシンと状態遷移機械を実装する作業)と多数のデータ初期化列の記述(仕様文書から機械的に変換しうる作業)を行うことが、アプリケーション開発であるべき姿になるのではないかと思うのです。
ユーザは、体感的に10倍近い無駄な人件費をシステムの開発や改修のたびに支払わされているのだと思います。そろそろ、プログラミング演習やロジック構築訓練をユーザ先でやっている/やらせているようなベンダ、メーカそして下請けをシステム業界から淘汰しないとマズイでしょう？
※ See Also: On Lisp (Paul Graham著，野田 開 訳)
