天才機関説と未踏の次 - 雑種路線でいこうというエントリは大変考えさせられたので、コメントします。

天才機関説と未踏の次 - 雑種路線でいこうより

未踏コミュニティの連中は流石に業界耳年増になっているから、あまり大企業志向を感じない。Google幻想とかは結構あるようだけど。ただ彼らが工房のような身軽なベンチャーを立ち上げるのも、結局のところこれまでのような生活を続けたいっていう保守性からきているのではないか、と感じることもある。会社を大きくすると、自分のやりたいことできなくなっちゃうよね、僕が豊かに暮らしていく分には効率的な働き方だってあるからね、と。

まぁ、私は 20:80 で分ければ 80 の側に入るクチなので、未踏でくくられてもいまいち実感はありません。事実、上記の記事に対応するのはスパクリクラスの人でしょう。しかし、上記は自分のメンタリティと関係する話だと感じました。

未踏出身者は何百人もいるので、勉強会などに行くとかなり高い確率で顔を合わせることになります。話を聞く限りでは、未踏のネタを事業化して成功させた例は、ゼロではないにせよあまりないようです。死の谷どころか魔の川を越えることも難しいというのが、私の印象です。しかしながら、未踏採択者本人は「自分のやりたいこと」を仕事にすることには成功しているようです。

未踏出身者として言っていいことかわかりませんが、今のところ未踏という制度が採択者本人を大きく超える範囲で世の中に貢献するケースはそれほど多くなく、「採択者当人の閉塞感を打開する」という状態にとどまっているようです。いや、私がお世話になった千葉先生配下のプロジェクトだけでも、「YARV は？」「Mayaa は？」「Tuigwaa は？」「SE-PostgreSQL は？」と世の中に貢献しているプロジェクトはたくさんあります。

もちろん、Kodougu も世の中に貢献していくつもりです。

でも、未踏を始めた時に、製品とは別の方法でも世の中を変えていきたいという思いもありました。平凡なエンジニアが未踏ソフトウェア創造事業をやったらどうなるのか書いてみたはまさにその意図を持って書いたエントリでした。たとえ、20:80 の 80 の側だったとしても挑戦する道はあり、突き抜ければこの閉塞感を打ち破れると書いたつもりでした。

が、未踏が終わって 4 か月。上記の記事を読んだらあまりにも自分にあてはまります。「自分さえよければいいから、今のままでいいや」などという心の声が聞こえてきそうです。

日本の IT 業界については、泣き言を言っても始まらないし、大上段に構えたからと言ってすぐに何かが生まれるわけでもないと考えています。ただ、私にとって「未踏の次」とは、世の中と向き合うことでなければならないなと強く感じました。

ソフトウェア開発における「ドッグフードを食べる」とは、ソフトウェアの開発者もしくはその会社が、自分たちが開発したソフトウェアを実際に業務などで使用することです。要は自らを実験台にするわけです。有名なのはマイクロソフトのドッグフードです。どこよりも早く MS 製品を使い始めるわけですから、命がけ（？）ですね。(^^;　それゆえあれだけ複雑な製品をそれなりの品質で提供できているともいえます。

ソフトウェアをドッグフードしなければいけない理由より

ソフトウェアのドッグフードというのは、開発を継続できる最大の武器だよね。自分がアプリを開発していけるのは、自分で日常的に使ってるから、というのが大きい。バグだってどんどん見つかるし、改善すべき点も見えてくる。自分は使わずに誰かの為に開発しているソフト、なんてものを私は信じない。何年何十年と粘着的に考え続け使い続け、開発するからこそ見えてくる何かがあるはずだ。

自分は使わずに誰かのために開発しているソフト、例を挙げると「オーダーメイドの業務アプリ」です。システムを内製できる会社はそれほど多くないので、業務システムは外部の企業に発注するわけですが、そうした請負の会社でドッグフードして実業務で使用してから納品なんて話はあまり聞きません。（「あまり」と書いたのは、システムそのものをドッグフードしないのであれば、たとえばソリューションのドッグフードなどは行われているケースがあるからです。）

続きを読む

平凡なエンジニアが未踏ソフトウェア創造事業をやったらどうなるのか書いてみたは、多くの方に読んでいただくことができました。IPA フォーラムの件で IPA 関連の事業が注目を集めていたこと、スーパークリエータが発表されたこと、IPA 中期計画終了年度による未踏ソフトウェア創造事業の見直しなど、注目を集めやすい状況にあったことがその要因でしょう。何はともあれ、お読みいただいた方に、お礼申し上げます。

アクセス数も収まってきたようなので、こっそり「あとがき」を書きます。

続きを読む

ソフトウェア技術者がどっかの段階で覚えなきゃいけないことを読んで思ったのは、広場っぽいカラーが出てていいなぁと思いました（笑）。私の結論は以前書いたとおり、自分の目指すところに合わせてポートフォリオを組んでくださいということですが、この考え方を使ってソフト（Kodougu）を組んだばかりなので、いまさらですが再考します。

ソフトウェア技術者がどっかの段階で覚えなきゃいけないことより

ソフトウェアにはメタな構造があって、さらに根源のところでは自己記述っぽい形でぐるぐる回ってるというイメージを持つ事じゃないかなーと思う。これはソフトウェアの本質そのものなので、知っておいて損は無いはず。

例に挙がっている Lisp なら、Pure Lisp の言語仕様と car/cdr に注目してもいいと思います。より、シンプルで本質的です。ちょっと視点は変わりますが、Ruby で DSL を作った Rails がなぜ流行るのかも考えてみるとよさそうですね。

マシン語だって、高級言語からアセンブリ言語、そしてその命令がスーパーパイプラインでどのように処理されているかというような階層を知れば、意外とそういう理解を得ることも可能なんじゃないかなという気がします。それに、知れば知るほど、深く掘れば掘るほどシンプルで要素分解できるというほどわかりやすい世界でないことがわかります。Pentium4 が出た時は、CPU は神のお告げで命令の実行順を決めているなんて言われたもんです。（μOP、分岐予測あたり。）言うまでもなく、shi3z 氏はこの手のことくらいは熟知していると思います。

確かにこの手の知識は必須じゃないのですが、その割にこの手の知識を知っている人には技術的に「骨のある人が多い」のも事実なんですよね。なんでだろ。

さて、メタ階層的な話に戻ります。Kodougu は UML の抽象構造であるメタメタモデル（UML Infrastructure）をいくつか改造して実装しています。メタモデルはデータで表現されています。適切な例かわかりませんが、クラスとオブジェクトの関係が、メタメタモデルとメタモデルの間に表現されています。メタモデルのデータをもとにコードを生成して、クラスとオブジェクトの関係をメタモデルとモデルの間に構築しています。そのため、Kodougu はモデリング言語を設計することができるのです。また、メタ階層的な考えで実装しているため、Kodougu のコードはサーバは 4000 行（Wiki とか余分な機能が含まれていますが）、クライアントは 2000 行で書かれています。この種のアプリの一般的なコード量は十万行から百万行程度になりますから、ずいぶんスリムです。

この手の設計思想のメリットは、初期の開発コストはそこそこ高いですが、ソフトウェアの規模が小さいため、保守コストが小さいことでしょう。デメリットは、このメタ階層が処理できない問題にあたると、どうしようもなくなるか、途方もないコストがかかる恐れがあることでしょう。そういう意味では、もっとももメタな部分の設計／実装センスが問われてしまうので、リスクを取ってでもやりたいという強いモチベーションが必要です。（ここでいうセンスは別に先天的なものを意味しているつもりはありません。音楽やスポーツに要求される”才能”とは違う気がします。）

それがアーキテクチャ設計の宿命だといえばそれまでなので、エンジニアとして生き残っていきたいのなら、この種の能力は必須かもしれません。

お、スラドでも話題になっているようです。さすがにスラド、割りとガチでテクニカルに議論している気がします。

shi3z 氏のマシン語関係のエントリを読んでいたら、久々にアセンブリ言語で書かれたプログラムを読みたくなったので、かつて自分が書いたコード（Delphi のインラインアセンブラですが）を読み返していました。まだ書けるかどうかは怪しいですが、読むことはできるようです。10 代のころにやったことはなかなか忘れませんね。

さて、shi3z 氏の言わんとしていることはわかりますが、IT もこれだけ複雑になると、「××が必須」というのはなかなか難しくなるのではないかなと常識的な反応をしてみます。SE なら、会計知識だったり、物流の仕組みだったり世の中のことを知っているほうが重要な場合もたくさんあります。

思うに、システム作る人ってあまり生き残らない気がするのです。パッケージを利用したり、SaaS（この言葉自体は微妙ですけど）だったり。SE の仕事は何を使えば業務が遂行できるか判断するのとツールのカスタマイズが主な仕事になるのではないかとさえ思います。組み込みやゲームは違うかもしれませんけど。もっともそういう人は、SE じゃなくて IT コンサルとか名乗っていくのかもしれません。

パッケージや既存システムに問題があったらサポートに連絡です。これは MySQL だって一緒です。大体、企業でオープンソース製品が話題になるのは、オープンソース製品が重要というよりは、製品サポートビジネスが立てたい人たちが仕掛けているところもあると思います。コードの中身が公開されていて安全ですよ、しかも弊社のサポートがあるので何があっても大丈夫です、みたいな感じで。

結局サポートに頼るなら MS だっていっしょじゃん！
# パッチリリース速度なら MS だって OSS に負けてないし。

そういうこともあるのか、昨今の SE はアセンブリ言語どころか、複数の言語を操れない人さえいます。プログラミングわからない IT コンサルを何とかしてくれという人もいますが、彼らは彼らでないと困る様々なスキルを持っています。

この手の議論は、SE は理系出身でないと務まらないかどうかという話題に近いと思います。これだけ複雑化してきた世の中なら、お決まりの文句になりますが、「いろいろな人が必要なんだから、それぞれの専門を尊重しながら仕事しましょうね」ってことになりますかね。何かひとつふたつベースになるものを身につけてくださいってことで。（で、これらの人たちがコミュニケーションするにはモデリングが欲しいよねってことで、Kodougu をよろしく！）

でも、作る側に残りたいのなら、アセンブリくらいやっとかないとね。というわけで、MySQL とかの中の人になりたい人は必須でしょう。

以下の記事について非常に頷けるものがありました。

小野和俊のブログ:IT業界の大企業での生々しい話を5つほどより

1. 2ch へのアクセス禁止で開発効率が大幅に低下
＜中略＞
2. 人事評価制度の歪みを解消するためにあえて優秀でない人材を採用
＜中略＞
3. 社内では使われない自社パッケージ
＜中略＞
4. 競合他社への販売禁止を条件に出されパッケージ販売を断念
＜中略＞
5. IPAのプロジェクトで間接業務に忙殺される

1, 2, 3 については、私にも経験があります。1 についてですが、2ch はともかくとして、会社の枠を越えた（仕事に関係する）横のつながりを重視する人としない人とで意見が分かれてくると思います。少し文面の内容とはずれますが、プライベートはともかくとして、仕事面で会社で枠を作ってしまうことで、活動の幅を狭めている人は多い気がします。
（そういう人がわりと悪気なしにこういうコミュニケーションを阻害する仕組みを作ってしまうんですよね。）

2 ですが、優秀でない人材云々はともかくとして、人事評価は相対評価なので、仕方の無いことだと思います。ま、高く評価されない変わりに、低く評価もされないということです。私のように独りものならともかく、養わなくてはならない家族がいる人には、リスクが低いほうがいいと思うので、これはこれでアリなのかなと考えたりもします。

3 は・・・以下、まったくおっしゃるとおりです。(--;。

保守の問題があるから簡単には捨てることはできないかもしれないが、そんな状況なら少なくとも新規の販売は差し止めた方がよいのではないかと思う。自社でも使いたくない製品を買わされる側はたまったものではない。

5 について・・・未踏は恵まれてるんですね～。実際、未踏では間接業務に費やす時間はほとんどありません。その上、プロジェクト管理組織というある意味雑用を一手に引き受けてくれる方がいらっしゃるので、開発者は本当に楽です。

久々に IT 業界のどろどろとした話を思い出しました。(^^;

以下のエントリを読んで少し気になることがありました。

Collection & Copy - 日記 2007-02-9、ブログを書くことより

「ブログに載る新しい情報も、企業の中ではもうずっと前から使っていて、あたりまえになっていることがよくある。技術を専門に研究する人たちもいて、金もある。そして、そこで生まれた知識は社内だけで共有される。」

こういう発言に嫌悪感を示すのはそれはそれでいいのですが、少し冷静に考えて見ましょう。そもそも社内の技術共有ってそんなにうまくいくのでしょうか。私は以前の会社で、上記で言うところの専門に研究する人っぽい仕事をちょこっとだけしていたことがあります。その経験上、得た知識を社内に広めようとすると、会社という枠内の活動では非常に薄まったものしか広められないという現実に突き当たったことがあります。

つまり、以下のエントリに同意です。

yosisの日記より

「確かに"技術を専門に研究する人"はいるが、"ブログに載る新しい情報"→"企業：当たり前"ではない。 　また、"そこで生まれた知識は社内だけで共有される"は嘘。社内でも共有されない。」

ブログ、勉強会、オープンコミュニティの活動では非常に濃い密度の情報交換が行われます。これだけ濃い共有が土日にできるのに、平日にはこんな薄い情報の共有しかされないのかと驚いた記憶があります。

これは、モチベーションの違い・・・ということなのでしょうか。誰かが調査してそれを社内で共有という理路整然としたプロセスに無理があるのかもしれません。

弾氏が面白いエントリを書いていらっしゃるので、私も思うところを書いてみます。

発端は、分裂氏がプログラマの労働条件を過酷にしているのは、プログラマが労働力のダンピングをしているからであるという議論を始めたことです。それに対して、弾氏がプログラマを労働者よりは作家や芸術家に例えています（労力と成果の関係があまりに非線形であるため※）。

※ 労働者＝労力に対して対価を受け取る人と定義しています。

404 Blog Not Found:プログラマーって本当に労働者なのか? より

百歩譲っても、プログラマーというのはメタ労働者ではあっても労働者とは言えないと思う。厳しいようだけど、労働者として扱ってもらいたかったら、プログラマーではなく別の職を選ぶべきだと思う。少なくとも、それを本職にするべきではない。

弾氏の気概を感じますね（笑）。弾氏も分裂氏もプログラマは主体的に自己の労働環境の改善をしていかなくてはならないという点では共通しています。

立石氏は少し立場を変えていて、プログラマをひとくくりにしないで、芸術家的な要素を持つプログラマ（立石氏は「開発型」と呼ぶ）とそうでないプログラマ（「生産型」「運用保守型」）を分けて考えましょうと提案しています。（後者は労働者という考え方です。）

で、私の考えです。私は「プログラマは主体的に自己の労働環境の改善をしていかなくてはならない」というメタな点では、分裂氏にも弾氏にも賛成です。ただ、立石氏のエントリにもあるように多様性を認める必要があると思います。
弾氏にせよ分裂氏にせよ、抜群に優秀なエンジニアじゃないと成り立たない議論をしているような気がします。そういう気概を持つことはすごく大切なのですが、労働者として安定して働きたい人も多いはずです。エンジニアは自分がどう働きたいのかを明確にした上でそれを発信していくことが必要なのだと思います。
# でも、会社に居たときから「エンジニアの自分自身が働く環境に対する意識の低さ」は気になっていました。

■ 議論の流れと関連エントリ
分裂勘違い君劇場 - プログラマの労働条件を過酷にしているのは、過酷な労働条件を受け入れるプログラマです
http://d.hatena.ne.jp/fromdusktildawn/20070216/1171627060

404 Blog Not Found:プログラマーって本当に労働者なのか?
http://blog.livedoor.jp/dankogai/archives/50766218.html

コンサルタントのネタモト帳＋（プラス） 人月神話：「プログラマー」は労働者？芸術家？ ～ ほぼ日刊で「経営の話題ネタ」を名古屋から発信！社労士・診断士のコンサルタント立石智工のビジネスヒント集
http://blog.goo.ne.jp/tateishi_awing/e/a71aa46b86aac6d9df78aa73a37e4dda

404 Blog Not Found:俳優と脚本家
http://blog.livedoor.jp/dankogai/archives/50766689.html

前にも少し触れましたが、今、ネット上では生産性に関する議論がなされているようです。
# 多分、もう決着はついたと思いますが・・・。

下にネタもとのリンクを貼っています。いわゆるアルファブロガーに相当する人しか追っていません。あまりに議論が膨大なので。(--;　多分、議論は生産性と賃金についてです。賃金は当人の生産性によって必ずしも決まるものではなく平均生産性から決まる（by 山形氏）という話題から始まって、紆余曲折あって、賃金は限界生産性（※）によって決まるという結論になって終わります。結論が出た後は、富の分配システムの方に議論が行ったようです。

これだけ盛り上がったのは、いわゆる炎上に近い現象が発生したと考えて良さそうです。経済関係の議論の問題点として、複雑なケース（たいていの現実は複雑ですが）になると、モデルを組むことが難しくなって議論が定性的になったり直感に頼るようになったりする（※※）ので、なおさら炎上しやすいのだと思います。(--;　でも、私は皆さんが言いたいことはそんなに違わないと思っています。

※ 限界生産性とは、労働者を一人雇用したときに上昇する生産性のことです。SIer なら生産性＝売り上げでいいと思います。間違っても生産性＝書けるコードの量ではありません。SI は人月による人身売買ですから、何人売れるかで十分です。一人雇ったときに上昇する売り上げによって賃金が決まると言えば、直感的でしょう。

※※ 池田氏はモデルがシンプルなのでこうした罠にははまっていません。読み物としては山形氏のものが面白いです。

結論がわかりにくかったので、自分でも少し考えてみました。（結論をなぞっただけですけど。）

SIer の場合、限界生産性は横ばいに近い（人月でビジネスをするので、人数×単価で売り上げが決まる）のですが、研究開発などのイノベーションによって単価を上げることができる（＝限界生産性を上昇させる）のなら、売り上げが上がって賃金も上がるというわけです。前の職場はそうしたロジックを大切にしており、単価を上げるような研究開発を継続して行っているため、単価＆利益率は業界最高クラスです（※）。給料は中の上くらいですが。(^^;　たいていの SIer は限界生産性は横ばいだと思うので、賃金も横ばいです。ただ、オフショアの浸透などが SIer の単価を引き下げる要因になるので、給料は下がっていくのかなと思います。
# だからオフショアの影響を受けにくい職種（要求とか PM とか）にエンジニアは転向しようとするのです。

※ このブログは前の職場の人も読んでいるので、一言警告を。この優位性は長くはもたない・・・つまり、抱えているイノベーションや新しく生み出しているイノベーションが相対的に価値が低くなっているので、会社におんぶにだっこではいずれ給料が下がっていきます。この方向性（技術の××）で行くのなら個人個人がもう少し意識を高く持つ必要があるんじゃないかな。え？　仕事が忙しいからムリ？？　そもそも技術志向なんてやってらんない？？？　ま、そーだよねー。

ということは、SI に関しては単価の高い仕事に転向しないと給料は下がる一方だよ・・・と。プログラマは生きてけないよってね。上流志向の人ならいいけど、IT エンジニアになったらみんな上流に行かなくてはいけない・・・というのはちょっと窮屈です。（私は長くオフショアに関わったせいか、そういった窮屈感は感じなくなっていますが。）もっとも、池田氏の最後のエントリ（賃金格差の拡大が必要だ）が実現すれば生産性の高いプログラマなら生きていけるという話になって、技術屋にとっては技術力を磨くモチベーションになります。

池田信夫 blog 賃金格差の拡大が必要だより

労働時間で賃金を支払って年功賃金で会社にしばりつけるといった在来の賃金体系をやめ、優秀なプログラマには契約ベースで管理職より高い賃金を払う必要がある。

さーて、単価が下がってプログラマがいなくなるもしくはワーキングプアになるのが先か、優秀なプログラマなら生き残っていける社会が来るのが先か。どうしたもんだろ。

■ 議論の流れ
以下、議論の流れです。（めちゃくちゃ長いのでリンク先は興味のある人以外は読まなくていいです。）

2007/2/4
山形浩生 の「経済のトリセツ」　　Supported by WindowsLiveJournal - ゴッドランドの経済学
http://d.hatena.ne.jp/wlj-Friday/20070204/p1

2007/2/11
山形浩生 の「経済のトリセツ」　　Supported by WindowsLiveJournal - 生産性の話の基礎
http://d.hatena.ne.jp/wlj-Friday/20070211/p1

2007/2/12
池田信夫 blog 生産性をめぐる誤解と真の問題
http://blog.goo.ne.jp/ikedanobuo/e/cd4e52fd7cca96ac71d0841c5da0cb75

404 Blog Not Found:生産性より消費性
http://blog.livedoor.jp/dankogai/archives/50762325.html

2007/2/13
分裂勘違い君劇場 - アルファブロガーたちの地位争いが優良コンテンツを量産する
http://d.hatena.ne.jp/fromdusktildawn/20070213/1171359965

山形浩生 の「経済のトリセツ」　　Supported by WindowsLiveJournal - それでも賃金水準は平均的な生産性で決まるんだよ。
http://d.hatena.ne.jp/wlj-Friday/20070213/p1

2007/2/14
池田信夫 blog 生産性と「格差社会」
http://blog.goo.ne.jp/ikedanobuo/e/b8b2dd3502ef769c7f5baf18143f53e1

2007/2/15
分裂勘違い君劇場 - 「他人の生産性が向上すると自分の給料も増えるのか？」を中学生でもわかるように図解してみました
http://d.hatena.ne.jp/fromdusktildawn/20070215/1171504603

山形浩生 の「経済のトリセツ」　　Supported by WindowsLiveJournal - 山形より上手でていねいな説明をごろうじろ。
http://d.hatena.ne.jp/wlj-Friday/20070215/p1

404 Blog Not Found:生産性は誰のものか
http://blog.livedoor.jp/dankogai/archives/50765006.html

池田信夫 blog 賃金格差の拡大が必要だ
http://blog.goo.ne.jp/ikedanobuo/e/b697e23a80b6602167c2f5e43ebad041

ウェブに接続していると常に感じることは、タイムラグが結構あるということです。何かの本では、ウェブで世界と瞬時につながるという話もありましたが、そういう意味で言うとウェブはまだまだ発展途上ってことですかね。

最近、生産性に関する議論があって面白かったので、そのやり取りを時系列に並べてみました。

2007/2/11
山形浩生 の「経済のトリセツ」　　Supported by WindowsLiveJournal - 生産性の話の基礎
http://d.hatena.ne.jp/wlj-Friday/20070211/p1

2007/2/12
池田信夫 blog 生産性をめぐる誤解と真の問題
http://blog.goo.ne.jp/ikedanobuo/e/cd4e52fd7cca96ac71d0841c5da0cb75

404 Blog Not Found:生産性より消費性
http://blog.livedoor.jp/dankogai/archives/50762325.html

2007/2/13
分裂勘違い君劇場 - アルファブロガーたちの地位争いが優良コンテンツを量産する
http://d.hatena.ne.jp/fromdusktildawn/20070213/1171359965

山形浩生 の「経済のトリセツ」　　Supported by WindowsLiveJournal - それでも賃金水準は平均的な生産性で決まるんだよ。
http://d.hatena.ne.jp/wlj-Friday/20070213/p1

飲み屋でやったら 2 時間（もかかるのか？）で済んじゃいそうなやり取りですが、ウェブでのやり取りでは数日間は最低かかりそうです。ただ、生み出す価値は計り知れないです。（知見のある方々が公の場で、ある意味万人に向けたわかりやすい議論を展開するわけですから。）

ウェブでタイムラグを感じる理由は、例えば情報収集のアンテナの反応速度によるのかもしれません。例えば、はてな RSS は、記事を書いてから 12 時間くらいたたないと新着記事を拾ってくれない場合があります。

さて、タイムラグがあるといいつつも、上記のような議論の場合、人間の反応速度としては、これが限界（つまりウェブのタイムラグがボトルネックにはならない）かもしれません。リアルで忙しいのにウェブに費やせる時間なんてたかが知れていますから。

今のウェブは「瞬時ではないけどそこそこすばやく、そこそこ整理された情報に触れたり議論したりすることができる」ところに価値があるのかな・・・？