わー
水耕農園の話の続きを見つけたのを逆にあっという間に見つけられてしまいましたよ(ﾉ＿＜。)
うっかりリンクしてしまったのが失敗だったかもしれません・・・。
発見というのは酔漢師匠のBlogまでしかふだん読まないので、その先の酔漢師匠のコメントを見つけたのが自分の中で新鮮だったというだけなのですが。
ソフトウェア開発に自然科学的管理が導入されて何年？
前のエントリに書いた
「そこは○十年前に我々が通り過ぎた場所だ」
という冗談で書いたのですが、ちょっと検索したら何十年前にはそれが試みられていたのか分かる資料を見つけられたので書いておきます。
我々はソフトウェア計量化の応用として、ソフトウェア品質会計(S0ftware Quality Acounting)を提案し昭和57から運用してきた。
−ソフトウェア品質会計とソフトウェア管理会計
（強調は引用時に付加）
昭和57年は1982年なので2008年の今年で26年ですね〜。
品質会計は初めて聞いた時に自然科学的管理は高度経済成長期には製造業に浸透していたはずで、ソフトウェア開発の世界にそれがやってきたのはその後のはずだからその歴史は20〜30年ぐらいと予想していたので当たりでしたヾ（’’ツ
読んでみたいのですが、会員じゃないとオンラインでは読めないのですね。図書館に行くのもめんどうくさいというか図書館にその都度通って何度も読み直すのは大変なのです。
ちなみに自然科学的管理の後に興ってきた人間関係的管理は『戰後の労務管理、とくに人間関係的管理をめぐって(統一論題「戰後十年の企業経営と経営学の再検討」をめぐる討論会記録, 経営学の新展開)（19560710）』を見つけたので、学問の世界では50年前には既に社会で実践されるべきと言われていたのですね（その前から研究が始まっていたのは知っていましたが）。
それが実際に社会のニュースなんかで話題にされ、風向きが変わり始めたのは（わたしの感覚では）1990年台になってからだったような気がしています。そして未だに導入は進んでいないわけですから、社会科学の成果が社会に反映されるまでの時間は長いですね〜。
長い話のついでに紹介すると、EUの通貨統合の下敷きになっている最適通貨圏の理論が最初に発表されたのが1961年で、ユーロが使われるようになったのが1999年なので38年かかってます。ちなみに最適通貨圏の研究をしたロバート・マンデルは1999年にノーベル経済学賞を受賞しています。
まあそんなものという感じもしないでもないですが、自然科学の研究から実用までの時間と比べると長いですよね（人間が対象の医薬品と比べたとしても）。
水耕農園の話の続きを発見
「ギーガーやMatrixの世界に似ていると気味悪がられたとしても，それが大事なの」というところに続きを発見。
程度の差こそあれ，社会というのは，構成員各自が自らを部品化をすることで成り立っていると言って良いはず
という話題に一段落割かれているのを見て、人間の社会もパッチモザイク構造なんだと改めて感じてしまいました。
そこが要点なのであれば、それは日本でも自然科学的管理がソフトウェア開発の現場に持ち込まれた時に到達していて、現在はコーディングをするプログラマーの多くを派遣社員で構成することにより、社内制度よりも強固な契約という形で実現していると思います。日本はその形がもたらす弊害がそろそろ許容限度を超えるので対策が打たれ始めているところです。「部品」というキーワードで労務管理を語り出すと「そこは○十年前に我々が通り過ぎた場所だ」と言いたくなる人がいそうな感じがします。現在の社会はその議論の後に存在していますし、そのキーワードだけで語りつくすのは難しいのではないでしょうか。
個人的には「起業できるぐらいの実力がある個人が生まれてほしい」という希望の話と集団に対する労務管理の話の関連性がすぐに思いつきません。
たぶん日本の大企業の人から見た未踏に選ばれた人は「（その導きが偶然か必然かどうかは置いておいて）世の中のニーズに応えるものを生み出す実力がある個人」という感じで、常日頃同じ課題を組織で解決している人たちからしたら興味深い人種だというぐらいではないでしょうか。今の段階では特にお互いとも相手に本気で期待しているものがないと思うのであまり気にしなくていいような。
実は壊れていました・・・
GWにとても情けなく恥ずかしい壊し方をして、修理見積もりの結果「修理不能」を言い渡されてしまっていました。
次に何を買うかという話もあるのですが、年初にデスクトップPCを買い替えていたのと、今までどのようなスタイルで利用していたのかについて書きたいと思っています。
「希望就職先：水耕菜園」を読んで
酔漢師匠の記事から「開発抽象化レイヤ - The Joel on Software Translation Project」をたどって読んでみて思ったことを書いてみます。
読んで思い浮かんだのは↓でした。
地上に天国を作ろうとする企ては不可避的に地獄を産み出す − カール・ポパー
酔漢師匠が連想したものが文字ではなくてイメージだったというのにはうらやましいと思いました。求む感受性。
上のフレーズが出てくる「開かれた社会とその敵」は未読なのですが、読んでみたいです。
原義とはちょっと違うかな？と最初思ったのですがちょっと考えたら似たような話のようでした。上のフレーズは「その企ては不寛容を導く。その企ては宗教戦争に至り、そして、魂の救済を異端審問を通じて行うに至る。」と続くらしく、ある価値観に基づく幸せというものを万人が共有できることはない、という話のようです。
酔漢師匠に同じくわたしも「開発抽象化レイヤ」は素晴らしいとは思えませんでした。何がおかしいのかを長々と書き出すとくどいと思うのでやめておきます。簡単に言うと目的を遂行するためにどうしたらいいのかという話といやな思いをしたことに対する反動が混ざってしまっていて、ごく限られた問題に対する解にしかなっていないと思います。酔漢師匠はその限られた狭い範囲の幸せについて書かれているのを機械的に感じたのですね。
プログラマ至上主義についても同じく感じたのですが、そこから連想した日本でも良く目にする光景は「○○は技術的に程度が低いからやりたいと思わない」という発言です。最近もふと目にして、流れを読んでいくとやはりその発言は技術的な難易度に対する認識に基づいてされたわけではなさそうでした。実際に作る物の規模や作り方はともかく、プログラミングのジャンルで勉強の必要がほとんどなかったり努力のしようがないような分野はないと言っていいと思います。ではどうしてそういうことを言っているのかと考えた結果行き着いた理由は「プログラマーである自分が誰の意向に従うこともなく主導権を握って物事を進めたい」というものでした。本当にそうならそういった方がいいと思うのですが・・・。
これも酔漢師匠が言っている、
海のこちらも向こうも世間からの引きこもり志向が強いんですかね
という話ですね〜。
思いついたことを書きたかっただけなのでこれでおしまいでいいのですが、元の話のGoogleに就職した人たちが起業を期待されているというそもそもの話が「開発抽象化レイヤ」をよく実践しているような企業からは起業する人は生まれにくいのであまりよくなかったと思います。
ひさしぶりに日記を書くたびにはてな記法を忘れています・・・
読んで考えたことがある記事は他にもたくさんあったのですが、なかったことに・・・。
「マシン語はそれほど…」を読んで
酔漢師匠の記事から元記事の「マシン語を知らない子ども達」をたどってすぐに、これは個々人のごく限られた経験を基に議論してもまとまらない話題だということには気づいて、それを書こうかなと思っている間に4カ月経っていました（＠＠
正月明けにふと思い出してもう一度考えたら簡単に一般化できてまとめられたので書きます。つまりその時点からも一週間は経っているという・・・(ﾉ＿・。)
- （プログラミング上の）困難な問題を解決する際には下層（低レベル）の知識が役立つ
というのがこの話題を一般化した形です。
効率的に問題を解決することを考えた場合、自分が選んだ層（言語を含む開発環境）で解決できるのが効率よく、通常はそうします。しかしそれでは解決できない問題に遭遇した時に必要になるのがその基盤に当たる層の知識になります。
- 問題の効率的な解決に役立つのは自分がいる層の直下の層の知識である
なぜそうなるかですが、最終的に問題の解決に必要な操作（調査）をするのがその層になることがほとんどだからです。
ただし、それ以外の知識が無駄というわけではありません。問題解決の糸口をつかむ可能性は問題の下層のあらゆる部分に存在します。元記事ではプログラムの問題を解決する際にマシン語（と密接に結びついたハードウェア）の知識を取り上げていますが、計算機科学や情報工学に立ち戻ってもいいはずです（目の前にある情報の精査のレベルまで戻るなら論理学も挙げられるでしょう）。
この話をプログラマーの方にしたところ「自分の中で問題を考えるレイヤーのスコープを素早く切り替えられるかどうかということが重要だと思う」というプログラマーらしい言葉を頂きました。
また、基礎的な知識の有用な理由をもう一つ挙げておくと、上層の知識ほど精密で問題解決に対する効率がいいかわりに、対象になる問題が変わると途端に役立たずになるものだということがあります。下層の知識ほど対象の問題が変化しても一定の効果を得られます。
最後に開発環境ごとに何が直下の基盤なのかを並べてみます。
C/C++言語の場合はマシン語（アセンブリ言語）です。その理由は自分の書いたプログラムはマシン語として実行され、ソースが提供されていない他人が書いたプログラム（典型例としてはライブラリ）を解析するのにもマシン語ですることになるからです。
JAVAの場合はVMとクラスライブラリです。この場合は言語というよりはドキュメントとツールになるでしょう。その次はOSの知識でしょうか。
Rubyの場合もVMになりますが、ドキュメントよりもVM自体のソースを頼りにすることが多いようなのでC言語の知識があると有用でしょう。Ruby以外のUNIX上で動作するスクリプト言語にも当てはまりますが、PC-UNIXはOS自体がC言語で書かれていてソースが公開されているのでC言語の知識がOSの問題解決に役立つことになります。
