自死に至るまで…

仕事場で自殺者が出ました。氏の御冥福を祈ります。


…提供したソフトウェアを、それを使用することでユーザが被ったいかなる被害に対しも、
　　“無保証 (NO WARRANTY)”
であることを提供側も使用者側も失念してしまう。それが、システム開発に携わるものが陥る“死にいたる錯誤”なのだ。

　　ソフトウェア開発プロセスが創り出しているのは著作物なのであり、製造物ではない。

“自分が消えてしまう朝”を迎える前に、この原則を外れた“現場の上長の指示”だの“業界内や社内での商習慣と内規”など踏みにじれ！
そして、より優れた著作物を生み出す根拠を自分自身で見つけ出すのを楽しもう！
根拠が見つけられずに迂回や逃げを選んだとしても、それも“一つの解”だ。
“自死”という停止コードに対して、今の私が出せる対処方式はコレだけだ。

Happy Hacking!!


URL-s FYI:
　　・ITPro: 開発現場のメンタルヘルス～事例から考える傾向と対策～
　　・ITPro: メンタルヘルスの必須知識を身に付けよう
　　・ITPro: 部下の「心の病」への正しい対処法

人道的な市場経済

市場経済というのが今のままではヒトに厳しいものなんじゃないか？と、言われています。
そこで、こんなことを思いつきました。

　　ハゲタカをもうちょっと賢くすると人道的な市場経済になる。

どういうことかというと、ハゲタカ・ファンドは買い付けた企業の価値を上げて高く売り抜けなければ生きていけない存在なので、彼ら企業価値をあげるための手段を付け加えてあげれば、ダメ企業を市場にいてもダイジョウブそうな健全な企業に変えることが労働者や消費者にとって利益になるんじゃないかということです。

どんな知恵をハゲタカにつけるとよさそうか？

　　買収した企業で雇用している人間を洗脳することを合法化する。

これです。企業がダメになってしまうのは、上から下までの人間が市場に適応できない認識・判断をするからに決まっています。ですから、市場に適応できる人間に洗脳してしまえば、まともな企業に自律的に変化するわけです。

　　自社は売り払い、すべての幹部と従業員は洗脳を受け、市場に適応する人間へと成長する。

市場経済から不適応人間を削減しダメ企業を淘汰する。有能で健康で市場価値のある人間が棲んでいる惑星“地球”を効率よく作り出せるならば、市場経済は人道的になったといえるでしょう。

※ scholar google 検索「brainwashing」

アプリケーション開発の末端で入り用なものと不要なもの。

仕事場ではシステム・アーキテクトやシステム・アナリストの真似ごとをしています。
実際にやっていることは開発担体の情報処理業者や人材派遣業者からやってきているエンジニアたちが
　「ど～すればいぃんですか？」
と、訊いてくるアレコレについてまとまりのよいコード・ライブラリとそれを利用し応用プログラム作成方針の準備と報知でしかないわけですが。

最近になって、ふと、気づいたことがあります。それは、
　アプリケーションを作成したり改修しているエンジニアというのは、もはや不必要な(すくなくともパートタイマで充分なことでしかない)業種なのではないか？
ということなのです。

なぜ、アプリケーション・エンジニアのすべてを素人のパートタイマで置き換えてしまうべきだと、かんがえるのか？

私が出くわしてきた業務用アプリケーションにまつわる業務知識というのは特定のチューリング・マシンのプログラム・コードと同等なロジック記述でしかありませんでしたし、アプリケーション・プログラムを何年も使いつづけるために必要な柔軟性や頑腱性というのは状態遷移機械の実装の善し悪しのことでしかなかったからです。

業務知識を実装につなげるとは、ユーザ側のシステム部門が主体となって書き下す要件定義と、それを受けてインテグレータが書き下す機能設計レベルあたりの“仕様書”に記載された箇条書きや図表を“どのように読み下せばいいのか”についての手順を愚直に実装した専用チューリング・マシンを複数(多分、コンポーネント数の2, 3倍でしょう)つくり、箇条書きと表形式に載っている事柄をチューリング・マシンそれぞれのプログラム・テープに相当するデータ構造の初期化処理に変換するだけです。
柔軟性と頑腱性を両立させるには、トランザクション内容、ユーザ権限、ジョブ周期の違いなどなどの文脈に相当する情報に依存して実行時に変化するべき事柄を単に状態遷移機械として表現して先のチューリング・マシンに埋め込んでしまえばよいわけです。

ということは、開発にかかる前に要件定義と精精のところが機能分割程度までの検討を済ませ、そして仕様のどこをチューリング・マシン式を適用し、どれについては状態遷移機械で表現しておくのかの方式選定にユーザとインテグレータが納得してしまえば、業務コンポーネントであるとかビジネス・ロジック・レイヤなどと呼ばれている従来システムのコード量にして5%～10%程度のコーディング(チューリング・マシンと状態遷移機械を実装する作業)と多数のデータ初期化列の記述(仕様文書から機械的に変換しうる作業)を行うことが、アプリケーション開発であるべき姿になるのではないかと思うのです。

ユーザは、体感的に10倍近い無駄な人件費をシステムの開発や改修のたびに支払わされているのだと思います。そろそろ、プログラミング演習やロジック構築訓練をユーザ先でやっている/やらせているようなベンダ、メーカそして下請けをシステム業界から淘汰しないとマズイでしょう？

※ See Also: On Lisp (Paul Graham著，野田 開 訳)

誰もがすなる…

今様は、誰もがすなるぶろぐを、吾れもしてみむとてするなり。

･･･あちこちの日記サービスには思いつきであるとか気分といったものを殴り書いてしまいがちなのを省みて、
ここでは、推敲なんてことをしていこうというのが、はじまりのココロもちです。
そうはいっても、雑な文章も載せてしまうでしょうが、それも推敲していけたらいいなぁ、と思っています。