まず書く前に自分の立ち居地について書いておく必要があるかな。

• エンジニアの未来サミットには参加してません
• 実際にシステムの受託開発的なことを一時期していて、ほとんど中小企業だけど中には上場企業のシステムやサイトなどをコンサルティング、製作したりしてました
• ほとんど社会人とだけつるんでやってたので、学生周りの事情を知ったのは最近
• ちなみにまだ大学生（卒業できんかったのですよ）。受託向いてないと思って辞めたところで来年から大学院生

ちょっと書きたいことをバラバラ書くので読みにくかったり、語弊があったりしたらすみません。あまりエンジニアの未来サミット関係ないかもしれません。
また、多分に個人的主観が強いであろうことも付け加えておきます。突っ込みは歓迎。むしろ中々実情について調べられないでいる（と、いうかあまり自分には関係ないので調べるつもりもないんですが）ので、事実を教えてもらえるのはうれしいです。

自ら泥化する学生たち

あまり一般性はないかもしれないですが、これを最近思いました。これを思ったのはちょっと前に知り合いがwebのデザインを始めたといったときのせりふ

すごい高額な料金を取ってデザインしているのに、それにお客さんが満足していない。同じものならもっと安くできる

価格競争を自ら誘発しているわけです。で、開発やデザインの差はあれども、実際安くやることによって仕事を得てる人たちがいます。
しかし、それは本当に安くやるべき仕事だったのかどうかについてはよく考えたほうがいいんではないでしょうか？

たとえば、私も結局安い値段でやってはいたわけですが、railsやCMSなどを組み合わせ、さらに仕事を絞ることで基本的なコストを削減することを第一に考えてやっていました。
少なくともそういった工夫は必要です。

第二に一般論ではありますが、コストベースで仕事をするのは価格競争に陥りやすく、あまりお勧めではありません。
ほとんどの商売上手な人は相手によって少しずつ提案する内容を変え、利益に対する値段を考えたりしています。
請求書上項目がどうなってるのかは人によると思いますが。
特に、結果としてアウトプットに差がでにくいwebの開発やデザインなどにおいては、そうなりがちであることは想像に堅くありません。
多くの人は「信用を得るために仕事をこなすことが重要」というのを言います。これはある程度認めましょう。しかし、最終的にはサービス面での差別化をはからなければ、その会社は泥化を促進するだけのものでしかないんではないでしょうか？
安くやるというのにはそれなりの戦略性が要るのかと思います。

泥な人たちはどのくらいいるというのでしょうか？

これが私にはよくわかりません。
なんどとなく書いていますが、定時にかえってるSI屋さんというのもいます。なぞですね。

あと、なにをもって泥といっているのでしょうか？これもよくわかりません。

就業時間でしょうか？外資コンサルの人たちの初任給と労働時間について考えたことはありますか？
私も労働市場全体のことはよく知りませんが、ITに限らず残業が問題になっているのはご存知のとおりかと思います。

給与面でしょうか？
これは単純に数字をよく知りません。
しかし、IT「業界」が泥だといいたいなら、個別の事例を取り上げてうだうだ言ってもしょうがないはずです。
これに関する定量的な話をついぞ聞いたことがありません。

さらにIT業界って何でしょうか？
大手電機メーカーの研究所でエンジニアをしていると大体年収平均700万くらいで安定するそうです。
大金持ちってわけでもなさそうですが、安定度には定評があります。
これも部分的なはなしなので、一般に当てはめるには困難がありますが・・・

なんでもいいんですが、泥じゃないサンプルをいくらでも知っています。だれか定量的な説明をしてないんでしょうか？定量的じゃなくてもいいですが、事実について正確に把握してる人がどの程度いるのかが疑問です。

人月商売・多重下請構造は破綻するのか？

破綻ってなんだろう？という気がしますが、0になるという意味なら、それはありえないでしょう。なんにしても最終的に手を動かす人が必要です。
価格競争に耐えられなかった自律泥化企業は消えていくだろうなというのはありそうなシナリオな気はします。

自分の人生は自分で決めろという論理は正しい

PDSCサイクルではないですが、自分で計画して、実行して、失敗して、修正するしかないことはたくさんあります。
特に有象無象な業界ほどそれは当てはまる気がします。
教育制度のしっかりしている大手企業以外で教えてもらうことを期待することは非常に難しいです。

ほとんどの学生にとっては就職が人生を考え始める第一歩であるような気がします。
私事で恐縮ですが、実際いろいろやってみて「明日くう金がないかもしれない」というリアルな状況におかれるまで、なんか昼夜を問わず電話をかけてくる理不尽な人と出会うまで、いろんな心温かい大人たちに色々と指摘されるまで、自分の人生についてなんか考えたことはありませんでした。
もちろん将来○○系でやっていきたいという漠然な考えはあるでしょうけれども。

たたかれるにしてももちあげられるにしても、基本的には私の行動に対して世間はリアクションを取るわけで、悩んでいるだけではまさに自分の存在は世間から見たとき「空気」です。

泥の話にひっかけるなら、主体的にビジネスをできないほど泥に足を突っ込むことになるでしょう。
泥の論理自体は至極単純です。リソースに見合わない作業を強いられているだけです。
積極的なリソースの確保と作業の調整がそこには必要なわけです。自分が社会の歯車にはまっていないのであれば、なおさら努力しないとそこにはまり込むことはできません。

ほとんどの人は、そういった意味で泥にはまり込まないように、できるだけ主体的に判断しなくてもいいように、学歴とかネームバリューにこだわるんだと思いますが、その権利を得られる人は社会全体から見れば小数です。
しかしそういった学歴とかがある人でも、大成功を目指すような野心家は、やはり最終的に主体的判断が必要になるでしょう。いずれにしても社会全体に存在しているリソースは有限であり、大量の成功者を抱えるには足りません。

技術とは何なのか？

実務として何をしてるのかはよく知りませんが、文系SEというのは結構いるものです。
しかし個人的な思いとしては、プログラムかけます程度を技術と呼びたくはない気はします。もちろんプログラミングはたくさんある技術のひとつではありますが、その「プログラミング」というひとつの技術を持つ人を指してエンジニアとは言いたくありません。
一言で言えば、それだけだとほとんどの世の中にある工学的・エンジニアリング的問題が解決できないからです。
はたしてプログラム書けるだけの人がサイトに集客をしたいというニーズを解決できるんでしょうか？その問題をテクニカルに解決するのがエンジニアの価値です。
最近めっきり公的にはなくなりましたが、プログラムでスパムサイトを量産するというのはひとつの立派なソリューションです。（勧めてるわけではありません）

経営者の価値が適切な組織運営の方法を提供することであるならば、エンジニアの価値は適切な技術の選択と適応ができることが価値です。
単一の技術をもつだけではほとんどエンジニアとしての価値はないといっていいでしょう。

今まで私は「文系」と「理系」という区別には意味がないという主張をしてきましたが、それは主にシステムの開発に関する教育を行う機会が平均的には存在しないため、差がないという意味で使ってきました。
しかし技術者・エンジニアという文脈で考えた場合、より多くの技術ポートフォリオ・技術的思考になれている人間のほうが相対的に有利であと思います。
ここに関して「文系」と「理系」を区別することには意味があると思います。（正確には受けてきた教育に関してわける合理的理由はあるかと思うという感じです。）

文系エンジニアが成立するのはかなり局所的な話であり、すでにweb開発がコモディティ化している現代においては、すでに文系エンジニア論理は終わりを告げつつあるように思います。それこそ泥なのは文系エンジニアの世界ではないですか？（これは提案。実際はよくわかんない）

重要なのは敬意

以前紹介した記事(twitterに書いただけだったかも・・？)にもありましたが。

4. Failure to Show Respect
When in Rome, do as the Romans do. If you’re a tourist overseas, you shouldn’t assume that everyone speaks English. That’s just plain rude. Natives of your host country will appreciate any attempt to speak their language, however feeble it might be; it’s a sign of respect and will go a long way to making sure the waiters don’t spit in your food. Likewise, even if business execs don’t understand the “language” of their technical counterparts, they need to do their homework and try to gain a basic awareness of the job at hand. It shows respect and breeds confidence. Business execs also often fail to appreciate what inspires and motivates technical and product folks, who sometimes are creative types more interested in building cool, innovative and useful stuff than making a busload of cash.

（要約）

郷に入れば郷に従え。エンジニアたちの言葉を理解することは、彼らに対する敬意をしめすことなのである。もし理解できないのであれば、自分で勉強してちょっとでも仕事についてわかるようにしておくべきである。
また何が製品担当や技術担当のモチベーションをあげるのかをうまく理解できないことがよくある。

経営者の話を聞いていると「ずいぶん勝手なことを言うな」と思うことがしばしばある。これは本当に簡単なことであるのに気づかない人が多い。

エンジニアだから、プログラマだからといってどんなものを作ってても楽しいということはないわけです。よく「プログラムかいてれば楽しいんでしょ？」という人がいますが、大きな勘違い。もちろんそういう人もいるにはいますが・・・・

ひるがえってこう聞けばいいかもしれません。「温暖化を解消する会社を経営してよ？経営してればなんでも楽しいんでしょ？」

どんな会社でも経営できれば楽しいという人は、プログラマと同様にいるんだとは思いますが、自分の興味のない会社を経営することを考えたら、ほとんどの人はモチベーションあがらないんじゃないでしょうか？
それが将来もよくわからないような会社だったらなおさらどうでしょう？なんで自分がそんなことをしないといけないとか思いませんか？
俺も仕事じゃなきゃこんなこと考えませんが（モチベーションはやはり品質に跳ね返る。身内ならなおさら。）、すごく当たり前のこととして考えてほしいと思うことが多いです。エンジニアを少しひとくくりにしすぎじゃないでしょうか？

経営者は自分の仕事に関してよく考えてほしい

かえって俺は経営者の仕事というのがよくわかりません。いや、大体わからなくもないのですが、コードを書けるべきとかそういうのとは本来的に別次元であると思うんですよね。
やっぱりインターネット。作る側の悲鳴ばかり聞こえてきて「私はそれにメスを入れる！」みたいな人たくさんいるわけですが、果たして経営者が本来的にするべきことについてネット上で語られてきているでしょうか？
ここには相当バイアスがかかっていることに注意しなくてはいけないと思います。

たいていの場合経営者は組織の制度上の明確な権力を持っています。形式上エンジニアを首にすることは簡単なわけであり、コストに見合わなければ首をすげかえることができるわけです。
それに対して技術者は実力で対抗しなくてはいけないわけです。「私の代わりはいませんよ？」

経営者は組織上明確な権力を持っている以上は、本当に見合った仕事をしているのかについては慎重に考える必要があります。
究極毎日ゴルフしてたって誰もあなたを首にはできません（人はついてこないでしょうが）
そういった立場であることを第一に考えるべきではないでしょうか？
果たして技術なんかにうつつを抜かしている場合なんでしょうか？もっと経営者がすべきことがあるんではないですか？

これは技術がわかるべきかどうかというのとは別次元の問題であり、かつ、本来的にもっと議論されるべきところなんだと思います。

思い出したのでついでに言うと「エンジニアにとってすごしやすい会社/企業」というのはなんかおかしいのです。前項にあげた「敬意/それぞれの趣味趣向」を認めるなら、それが物理的に実現不可能であり、たとえ実現したとしてもエンジニアリングとして優れた人は来ないであろうことが想像できます。
むしろ会社として「求める人材像」があり、その人たちにすごしやすい環境を整えるべきなんではないでしょうか？

泥の原因

個人的には泥の原因はこれじゃないかというのがあります。だいたいこの中のどれかか、これの組み合わせじゃないでしょうか？

• 全方位的に興味をもった、定まらない人材
• そういった人材と誰でもできる仕事を提供する企業との幸福で不幸なマッチング
• 自主的にコスト競争をし続ける中小企業や学生とか個人
• 特定の悲惨なサンプルがすごいクロースアップしている（誰も定量的に議論していない）
• なんかよくわかんないものを過大評価したり過小評価したりする
• 他人の人格を認めない人たち

すくなくとも、「エンジニアの未来サミット」というタイトルで、なぜかプログラミングっぽい話だけをする感覚自体になにかしろの破綻が見られるように思えます。
（もちろんgihyo.jpが主催な時点である程度察しろという話はありますが）

希望というか提案

• もし泥とか何とか議論したいなら、ちゃんと業界「全体」について考察してみてはいかがでしょうか？
• 「泥」の定義は何なんでしょうか？
• 自分が何に興味があるのか、自分の目標/目的はなんなのか考えてみたらどうでしょうか？根拠のない自信がもてるくらいまでの何かが必要だと思います。
• きれいごとっぽいですが、相手の人格を認めてあげてはどうでしょうか？

そしてもうひとつ。これ個人的には重要なんですが。

• エンジニアリング＝プログラミングではありません。むしろプログラミングだけなら、たいていの場合文系の人のほうが幸せにできると思います。

理系で全うに工学してる人は、学部であっても、webとかよりはだいぶ別次元のことしています。

追記：なんかアレゲなので今後泥の話には触れません。

というのがはてなにあがっていたらしい。

あんまし厳密なことは何気によくわかっていないので、ざっくりとした話をします。雑学とも言います。間違ってたら突っ込みいれてください（うちの弟が物理に詳しいので聞きゃいいっちゃそうなんだが）

もともと見つけたのはここ。

数学と科学の違い 404 blog not found

とりあえず数学について

まず数学は反証し得ないのか。
これに関しては先のブログにあるように、ゲーデルさんが示した不完全性定理により「正しいのか正しくないのか確かめることができない事実が存在する（かなり意訳してますが）」ことが示されています。
正確な表現はうろ覚えですが、だいたいこんな感じだったと思います。

自然数を扱う公理系において、その体系が無矛盾であるなら、不完全である

不正確かもしれないですがより正確なことを知りたければwikipediaを。
公理というのは、「経験的に正しいらしい信用できる事実」という感じです。図形だと「平行線は交わらない」とかそういうやつでしょうか。中学校の教科書にまとめてのってるようなやつですね。
「不完全」というのは論理用語で「ある公理系から導き出せない命題がある」ことを言います。自然数を扱うという部分はもうちょっと一般化できて可算無限個の順序集合を含むような公理系とかにも拡張できそうです。（このへんは個人的に思っただけで厳密にどうだかはわかりません）

反証という言葉をどう扱うかにもよるんですが、不完全性定理においては証明も反証もできないということをいってるので、そもそも反証するというのを当てはめるのがなかなか困難そうです。
代表例でいくと、連続体仮説というものは、「正しい」としても「正しくない」としても、問題ないことで有名です。
また、自然数や自然数と同等のものを含まなければ、反証不可能完全な公理系もどうやら作れるかもしれません。

なので、数学というくくりで話をしてしまうと、設定しだいでどうにでもできる（いいのかそんな結論）ということである気がします。

じゃぁ物理はどうなのか？

次に物理。
物理も実は数学に似てるところが無きにしも非ずです。
ただし、現実に観測される事実を重要視します。事実がすべてです。なので実は結構いい加減なところが多かったりもします。

高校で習うma=Fといったような運動方程式を考えて見ます。これはどうやら「こう考えるとうまく現象が説明できるらしい」というだけで、誰もこれをきっちり説明したわけではありません。

また量子論の世界とかでも割といい加減なところから始まっています。シュレディンガー方程式といったものやリュードベリ定数といったものは、いまだからこそたくさんの実験の元にたしからしいことが示されていますが、もとは電子の不思議な挙動とか、電子線スペクトルを観測していった結果「なんかわかんないけど、この方程式でうまくいくっぽいぞ！」というのりです。
シュレディンガー方程式に関しては、なんでそれがそうなっているのかに関しては未だにはっきりとした理由はわかっていません。
これは諸説あるし、いろんな論文とか報告があるといった程度らしいです。

と、いった感じで、物理は論理の賜物というよりは、どちらかというと、現象をうまく説明できるように数学的ななにかを当てはめていると考えるほうが自然であるように思います。

もちろん論理的に未発見の事実を予想するようなものもあります。有名どころではアインシュタインの相対性理論。
光がどんな完成系から見ても同じスピードで動くという物理現象（仮定）から、光が重力で曲がるであろうことや、質量がエネルギーに変わるであろうことを予想しています。
ちゃんと実証実験できたのは、じつは論文発表後それなりにたった後だったりします。
アインシュタインが生きているうちに原発ができていたなら、ノーベル賞が取れてたんではないかという話があるくらいです。

重要なのは、実は物理はそれほど過去のものを反証しているわけではありません。
量子力学は古典力学を否定したというひとがいるようですが、そんなことはないわけです。私たちが普段生活しているスケールでは古典力学は十分に正しく、それは量子力学からも導くことができます。
むしろ、物理が発展したことでより微細なこと（電子とか）とか、より巨大なこと（宇宙とか惑星とか）とかがわかるようになり、それに対しては新しい理論を、これまでのものを含んだ形で、作る必要があったというほうが正しいでしょう。

別に古典力学が間違っていたことが証明されたわけではありません。

もちろん、新しい実験結果からいままでの理論では説明できない現象が出てくることはありますが、たいていの場合それは新しい理論の特別な場合として示すことができます。

ただ、めんどくさいので「物理が覆った！」というわけですね。そっちのほうがセンセーショナルだし。

じゃぁ数学と物理を反証うんぬんからみると何が違うの？

まず共通する点としては、どちらも論理的な整合性を重んじているという点でしょうか。
数学は、公理系や各々の定理どうしが論理的に整合が取れてることを重んじています。
また、物理においても、観測された事実やこれまで存在した理論/論理との整合性を重んじています。

両方とも、学問的なレベルで「正しい」となったものが覆ることは相当レアであると思います。

では、何が違うのか。

数学はより少ない事実から、すべてを論理的に導き出します。
極端に言えば定理の積み重ねでできてるといえるでしょう。
Aさんが証明したものを使ってBさんが新しい定理を。Cさんがまたそれから新しい定理を・・・・という感じで、どんどん積み重ねていきます。

一方で物理は、そういった数学的なアプローチに加え、観測されている現象を説明するために理論を作ります。論理適正合成よりは事実と合致することが重視されるでしょう。
そして実験や世界中の研究者の追試を経て、どうやら事実らしいということになります。そこで今までの理論とあわないとなぜだろうとなって、「新理論の特殊な場合として示せる」とかそういうふうになります。
もしくは新理論が修正されることもあるでしょう。

結論

より話をシンプルにしてみます。

いずれにしてもアプローチと重要視する点が若干ことなるだけで、本質的には同じだといえると思います。

オッカムのかみそりをふるって、今までの理論をよりきれいに説明すべく洗練していき、あたらしい事実がみつかればそれに加える。
反証というのも、一度事実認定されたものが覆るのは稀で、微妙に修正されて言ってると考えるのが自然であるように思います。

たいていの場合根本的に覆るのは、多くの場合仮定の段階にあるものです。わかりやすいところで言えば「世界は亀の甲羅の上にある」といった部分や、現実的にありえそうなところでは特殊相対性理論の「慣性系によっては光の速度は変わらない」といったところでしょうか。

後者については未だに「正しいらしい」ことがわかっていますが、もしかしたら間違ってるかもしれません。

しかしもしそれが間違っていたとしても、特殊相対論が根本から覆るわけではなく、新しい理論のうち「光の速度が一定だと見てもいい場合」に限り正しい理論に変わるだけであって、これを反証と呼ぶかは微妙なところです。

というわけでした。

※多分にはらじゅんの科学感が入っているので、ひとによっては違うことを言うかと思います。厳密にあってることを言ってるわけでもないのでその点ご了承ください。ちなみに私の専攻は物理関係ありませんのであしからず。

※読み返すとやっぱしところどころ不正確なので時々直してます。

自分のことをとりあえず棚にあげまくりますが。上の記事は前貼ったやつと同じです。

今までよく「お前ら少しくらい脳みそ使え」ということをよく言ってたのですが、最近それがちょっとずれていたことに気づきました。
基本的にどの人も自分より頭いい気はしますし、実際会社やってたり具体的な行動を起こしていたりと、おそらく私よりよほど優秀であるような気はします。
より適切にいえば「具体的にimplementしよう」ということなんだなと気づきました。

バイトでも何でも最近一番苦労することは、空気を読むことだったりします。
はらじゅんがKYだという説はとりあえずほっておくとして、特に比較的詳しいプログラミングとかシステムに関して考えてみたいなと思います。

まずいただく注文のほとんどが曖昧としてます。（ほとんどのものは過去形ですが）
曖昧としてて誰も相手にしてくれないので自分のところに来るという予感が一時期してたくらいに曖昧です。
ひどいときは「超画期的なものがほしいんだ（なんだそれ？）」という人も出てきたりするわけですが・・・
ほとんどはまったくもってよく考えられていないか、考えただけで形に落としていないかのどちらかなので、大体アイディアが沸きそうな似たようなサイトを教えてあげたり、具体的に最近はこういうことが流行ってるとか教えることがあります。

実はほとんど多くの問題は、システムで実現可能である場合が多いです。はっきりいってしまえばコストがん無視すればできないことはそんなにありません。
より適切にいえば、実現不可能なことを思いつくほど斬新な人がいないとか、勝手に不可能だと思って忘れてしまうという感じで、ほとんど耳に入ってくる段階で合理的に実現可能になっていることが多いです。
おそらくまったく実現不能なことというのは、元々詳しい人がネタで言うとか、最先端の研究をしてるとか、そういう系なくらいだと思います。

さて、その状況で問題が発生します。実に多くの問題が発生するのですが、そのうちおもいつくものをいくつか。

• それは確かに実現可能なのだけど、いつまでにできることがに意味があるのか
• そのシステムを使う人はだれなのか
• どのくらいのコストが避けるのか
• どの程度全体像が見えているのか
• （システムであれば）その会社に専任の担当者がいるか
• 教育のコストを考えているか
• システムの規模/必要なスペックはどうなってるのか
• etc.etc…

時と場合によって２，３日質問項目考えてきくんですが、なかなかすぐ答えを得ることができなかったりします。そこで空気読む必要が発生するのですが、ここが大変難しいです。事務的な言い方をすれば要求仕様を固めるとかいうかもしれないです。

しかし、これは多くの場合「具体的に考える」作業をすることによって、簡単に発見することができます。プロトタイプ作る技能を持ってる人はそれでいいと思いますし、なくても合理的に考える根性さえあればなんとかなります。ビジネスプラン書くことができるのならきっと問題はないでしょう。

具体的なケースを考えて見ます。

ケース１：具体的な利用ケースを考えましょう(google miniとか

これは、単に話題にのぼっただけなので実際そういう使いかたしてるわけじゃないんですが。
試験的にgoogle miniを買った企業がありました。一番安い5万ドキュメントのサーバです。
google miniを使って、webから大量に取ってきたドキュメントを検索させてみようというような話をちょろっとしてたのですが、この段階ですでに計画が破綻しています。

webから情報をとってくる場合、対象にもよりますがサイトあたり数百～千件程度がデフォルトです。多いときは万くらいはあるのですが50回クローリングしてきたらもうgoogle miniでは扱えなくなりますね。
このケースの場合明らかに50回以上はクローリングするうえ、すでに数万件は一サイトで埋まることが確定していたので、結果的にこの段階で破綻してます。
はらじゅんひとりで扱ってる文字情報だけでも万はあるので、いかに小規模な組織であったとしても5万は少ない気がするのが感覚値でもあったりします。

こんなのは買う前に確認すればすむだけですね。

(どちらかというとgoogle mini使ってみるのが目的だったのと、他の用途にも使ってるようなのでOKなのですが)

ケース2：根本的に帯域足りてないよそれというパターン

なんかwebサーバの負荷が高くてサイトが落ちるとかいうお問い合わせがきました。正直負荷分散とかやったことないし、やるにしても単純にコピー作って専用の機械入れることくらいしかできないのですが。
ただ話を聞いてるうちに、根本的に回線スペックが足りてないことが発覚しました。

だいたい１トランザクションあたり80KBのデータをやり取りするwebサーバで、一時間あたりmax10万アクセスという話だったのでちょちょいと計算。

80KB*8bit*100000アクセス/3600秒 = 17Mbps

回線が10Mbpsという話だったので、理論的に限界超えてます。ファンタスティック。

サーバの負荷というよりは、単に回線が無理なだけだったようです。こういうのは確かにうっかり忘れそうなポイントではありますが・・・というか、そもそもwebサーバ落ちてないんじゃない疑惑とかもあったんですが、そこはなぞですね。

これも気づくのは確かに厄介ではありますが、気づけば計算は単純なので難しくはないでしょう。

ケース３：どういう人間がそれを使うのか？

これは非常に苦労しまくった話ですね。これでシステム開発やめる決心したといっても過言ではありません。動作面ではまったく問題ないのですが、利用ケースについてまったく考えられていませんでした。

たとえばそれがwebサイトだったとしても、使うのは一般の人だけではありません。たとえばサイトを管理する人は管理しなくちゃいけません。
神級の開発者がいる場合は別ですが、小さいプログラムであっても他人の書いたコードを理解することはなかなか容易ではありません。
多くの場合は管理するためのソリューションが必要とされます。

すると、いろいろ確認しなくちゃいけないことが出てくるんですが、特に業務フローについてはよく把握する必要があります。これは客観的に便利であることとかどうでもよくて、相手の会社がどういうルールなのかという話です。なんにしても、こちらの便利をごり押しするのであれば、業務フローのコンサルごとやって教育までやらなくてはいけません。
簡単に言えば、どういう手順でいつ集計作業がされるのかや、サイトからの問い合わせは誰が処理するのかとか、めんどくさいのだと営業の人とのからみとか色々出てきます。

とても壮大なストーリーがそこには待っています。

もはやここまでくると、それ相応に複雑なので、思いつきだけでやるのとかは危険極まりないです。
なので、それなりに具体的な文書にして客観的に無理がないことを確認することが必要です。
しかしこれはUMLなんていう変体言語で記述しろとか言うわけではありません。あれは開発者同士の共通言語として意味のブレがないように設計されてるだけで、具体的にシステム構築上有利な点があるわけではありません。
（すくなくとも俺はそう感じたという話。ただ意味がぶれない分確実なコミュニケーションが取れるというのはあると思う）
どんな書きかたしてもいいので、とりあえず書き出して過不足がないかを確認するというのが一番大切であり、絵のできは小学生の落書き級でも何の問題もありません。

まぁ読めないのはアレですが・・・・

まとめ

話が若干発散しました。いいたかったことは・・・・

• 具体化というのは何も複雑な作業を必要としているわけではない。
• 多くの隠れた問題は目の前にあればあまりにも普通で、しかも致命的であることが多い。それは作業が進む前に粗く取り除いておくと結果的に早く進む。

はい。

企画書ないと相手にしてくれないのが大人というもの（偏見？）な気はしますが、なんとなく気持ちはわかります。
はらじゅんは話とかだけでも聞きますが、文書化が一度もなされてないアイディアは突っ込みどころが多すぎて、会話がまったく有益でない場合があります。

というわけで、今日もいろんなものを書いています。
冒頭のリンクではこれとは似てるようで違う観点からideaを具体化することの重要性を説いています。

• オフラインだとバージョン管理できない
• 複数人で開発する場合、branchとかつくるのが割りと面倒
• 公開リポジトリと非公開リポジトリをいったり来たりすることがあるので、不便

オフラインでできないというのは、自分が常に公開サーバのつなげる環境にあるわけではなかったり、そもそも扱い厳重注意で外に公開してないサーバにあったり、ネットにつながってないときといった感じですね。
バージョン管理に慣れてしまうと、バージョン管理できない状態というのがやたら不便に感じます。
これはいけていない。

複数人で開発する場合のbranchがめんどくさい。これは、単に運用の問題でしかないわけで、物理的に解決可能ではあるんですが、めんどいもんはめんどい（ぉぃ

公開リポジトリと非公開リポジトリのの行き来の問題。
これは自分ひとりでやってたプロジェクトをある日突然公開する場合とかは、プライベートリポジトリとか仕事用リポジトリ（今はバックアップとって消したけど）と別に作ることがあるということですね。
割と個人的都合。
基本的にプライベートな情報は全部ひとつのリポジトリで管理しているため、切り分ける必要があるわけです。
ただ一方で単に思いついただけの簡単なスクリプトとかのためにいちいちリポジトリセットアップしてたりしたら、管理しきれないし、わけわかんなくなります。

こういった事情からいくつかの候補を検討中です。いわゆる分散リポジトリというもの。

• svk
• mercurial
• git

svkはsubversionを分散管理できるように拡張したもの。
詳しい動作はgihyoにあるのでそちらを参考に。Subversion+svkでらくらく分散リポジトリ
特徴としては、既存のsubversionサーバをいじらないですむことでしょうか。

mercurial / gitは最初から分散管理をすることを売りにしているリポジトリサーバ。

どっちも結構大きなプロジェクトで使われてるようです。
gitはlinuxのカーネルやrails、Xとかcompizとか。mercurialはNetBeansなど。

以下関連記事のリンクを並べておきます。

comparison of revision control software -wikipedia

Subversion+svkでらくらく分散リポジトリ

Mercurial – wikipedia

Mercurial: an alternative to git [LWN.net]

Mercurial Project – google tech talk

gitを使ってソースコードを管理する ibm

OpenSolarisのscm比較

Subversion or CVS, Bazaar or Mercurial? – Java world

bitkeeperからgitへ、ソースコード管理ツール大変更

ほとんどの人にはなじみがないツールであろうmathematica。かくいう俺も使ったことはありません。

数学の計算をやってくれる割とニッチな用途のソフトウェアですが、ほとんどの大学がライセンスを買っている（と、思う）し、ライセンス料が画期的なのですごいなぁといつも思います。

いわゆる数値計算とは違って、人力でやっているような「微分方程式を解く」というようなことをやってくれたりします。結構すごい。

レポートでめんどくさいだけの算数問題とかは、これで解いてしまったりするのは王道。
「なぜならmathematica」という言葉がうちの学科では一時期ブームでした。

物理系の人やシステム系の人が、「微分方程式たてたはいいけど解けないorz」というのはよくある話らしく、数学科のやつにお願いするというようなことがあるとかないとかいう話を聞きますが、そういう人にはうれしいソフトなのかと思います。

記事本体はあんまよくよんでないのですが、あんまたいしたこと書いてなかった気がします。

テスト終わったらなにか追記するかも。

けどとりあえず、今度こそ発表されるみたいですね。

アップル、iPhone SDKイベントの開催は3月に cnet

6日に公開される？らしいので、いまさらうわさをごちゃごちゃチェックするのもあれですが、iLoungeにこんな記事が出ています。

iPhone / iPod SDK: Apple to approve, distribute apps, limit add-ons

Apple plans to require that all mobile applications be distributed through its iTunes Store, making the Store a necessary hub for those interested in browsing or purchasing iPhone and iPod touch software.

iPhone / iPod touchのソフトウェアはすべてiTunes storeを経由して配布されるようになります。

The most controversial aspect of Apple’s SDK plan is its intention to formally approve or deny all SDK-based software releases for its devices.

publishing only approved applications to the iTunes Store

ｓｄｋで作られたアプリケーションは基本的にリリースするかどうかの判断を受けます。

ＯＫがでたアプリケーションだけが公開されます。

SDK developers will be prevented from interfacing directly with Dock Connector-based accessories connected to the iPhone or iPod touch

ドックコネクターを使ったソフトウェアはかけません。（たとえばgpsなどの拡張があったとしてもsdkからはアクセスできない）

Yet integrated iPhone or iPod touch features such as the phone, Wi-Fi, and camera will be developer-accessible,

ただ、最初から組み込まれている機能にはアクセスできますよ。

なるほど。
itunes storeの話については、どんなに制限しようと、結局jailbreakしたiPod touchのパッケージ管理みたいのが出るだろうし、そこはどうしようもないのかなと。
むしろapple公認を取ることでソフトウェアの安全性が担保されるという考え方なのかなぁという気もします。
とても前向きに捕らえれば、appleは一般的なユーザを守っているといえる気がします。

一方で勝手なアプリを開発しようと思えば、誰かがやったハックを使えばいくらでもできるわけで、それは今までと変わらないのかなと。
ただ、その場合はappleは何が起ころうと感知しない。というのは、当然の話ですね。

おそらくiPhone / iPod touchが目指しているのは、家電製品のほうに近く、携帯できるＰＣとかとは違うということなのでしょう。
だれもテレビや冷蔵庫を使うときハッキングされることを心配して使ったりはしないし、壊れるんじゃないかと心配したりもしない。iPhoneはそういう意味で冷蔵庫と同列なのかなと。
多少拡張性を犠牲にしても、誰もが使いやすいインターフェース、誰もが安心して使えるハード/ソフトウェアを目指しているのでしょう。
そういう意味では、appleの今までの製品群と同じ重奏低音が流れているということなのでしょう。

snsやネットゲームで殺人が起きたり、会社を首になったりする人が出る時代です。
たぶん個々人が思っている以上に情報機器というのは危険な存在。
appleがそこまで考えてるのかどうかはよく知りませんが、ギーク向けではなく、みんなが安心して使える製品という意味では、支持できるのかなと思います。

ただ、何かが劇的に変わりそうな期待・・・という意味では、ちょっと薄くなったかもしれません。

追記：

最近情報の世界が現実に近づいてきているなぁというのをひしひし感じます。それはインターフェースの改善によるところが大きい気がします。

そういった意味で、これからはソフトウェアの拡張性だけでなく、ハードウェアのスマートな拡張性についても注目されていくのかなと個人的には思います。

（スマートなっていうのがポイント）

Expanding on the project, Ted Patrick, Adobe technical evangelist, said the technology would allow for cross-compiling existing code from C, C++, Java, Python, and Ruby to ActionScript

このプロジェクトが進めば、C,C++,java,python,rubyなどで書かれたソースコードがアクションスクリプト（バイトコード）へクロスコンパイルできます。

と、いう感じらしい。

ただしGUI周りはもちろんプラットフォーム依存（だと思う）なわけで、ほとんどUIを作ってるといっても過言ではないwebプログラマーたちにはほとんど関係ないかもしれません。

ただ、物理シュミレーションとか信号処理とか、そういったものがflash上で動くかもしれない。だいたいフーリエ変換とか何らかの数学ライブラリってたいていの言語にあるのだけどactionscriptではあまりお見かけしない。
それが既存の財産を移行するだけで使えるというのはちょっとおいしい？かも。

最近のwebの動向を見るに、もうデザインや表面的なサービスを提供する部分に関しては飽和し始めているという印象なので、actionscriptでこういったUI以外の部分での活用の幅を広める試みは興味深いかもしれません。

蛇足：

戦略としては、古くからある他プラットフォームで動くものがflash「でも」動くという互換性を利用して、よりflashを使わせようという拡大作戦なのかなぁという感じがします。
webという側面から考えた場合、そもそもc++とかでweb作るのは一部のマニアしかいないので、まったく関係ないかなと。
ただし、AIRなどに見られるように、javaのような立ち位置を目指している空気があるので、今回はそういったところへの拡大を目指した動きなんだろうなと思いました。

javaはアプレットとして使われることはあまりなくなってしまいましたが、一方で、servletなどサーバ側で動く言語として成功しました。
対照的に、flashはずっとブラウザ上で動くアプリケーションとして不動の地位を保っていました。
そして、javaがまだ食い込みきれていないデスクトップアプリケーションという場所を狙って動き出したということでしょうか。
そうするとjavaもデスクトップアプリケーションとしての立ち位置を狙って・・・・というストーリーを思い浮かべたりしますが、どうなるのかなぁとちょっと眺めていてみたいです。

A Start-Up Says It Can Predict Others’ Fate

シリコンバレーに行くんだし、有名人のブログで勉強しとくかなぁとか思ってたまたま見たら発見。
この前友達と冗談で言ってたやつをマジでやってる人がいたらしいｗ
果たしてこんなことは可能なのか？

不可能ではない。というのが、ありきたりではあるけど、答えなのかなという気がする。

この手のデータマイニング系だと、たとえば保険やローンの与信でこういったアルゴリズムが使われることがある。
年収はいくらいくらか？年齢は？職業は？….etcこういったものを軸にどの程度までお金を貸したりできるのかを予測するわけです。
過去に十分な量のさまざまなパターンのデータが偏りなく満遍なくあれば、それを教師データにしてある程度正確な予想はできそうである。

ちょっと乱暴な言い方をすれば、要は統計の問題なので、たとえば保険商品とか金融商品だって、データマイニングと同じような理屈でできているといえないことはない。
要は「何らかの統計データ＝教師データから得られる統計」、「商品＝学習したアルゴリズム」というような関係。

こう考えてみると、ベンチャー企業の行く末もある程度の確度で予想できそうな気がする。

あとは、うまく説明するための要素と、それによってうまく説明される要素の設定がうまくできるかという感じですね。

意外と何で成功を計るのかというのがポイント。将来の企業価値なのか、IPOまでの期間なのか、買収されるときの金額なのか、買収される可能性なのか。
ものによっては、うまく説明できたり、できなかったりします。これも統計の不思議。
ただ、投資家向けに資料出すならなんらかのexitに関する情報を出すことが必要だろうなとは思います。

個人的にはこのアルゴリズムだけではだめで、最終的にここから出てきた結果を用いて、レポートを作り説明したりする人間的なスキルと、一般的な投資関連知識が必要になるかと思います。
たいていの場合、よくわかんないレポートなんか出てきても理解する・理解しようとするひとは少数で、結局は相手のわかる形に変換する人的な作業が必要になるかと思います。

おそらく投資家に役立つツールというよりは、投資家をお手伝いするコンサルタントなり何なりのお役立ちツールとしての可能性はあるのかなぁという気がします。

あとは、機械だけに黙々と作業してくれるので、オイシイ投資対象の取りこぼし防止とか、とりあえず人間の有限のリソースをちょこっただけ拡大してくれるかもしれません。

個人的にこの手の話は最近注目してるので、結果が気になります。

Microsoft Office Binary(doc, xls, ppt) File Formats

マイクロソフトがＯＳやＯｆｆｉｃｅ製品に対する仕様を公開しました。

いままでずっと公開されてこなかったワードやエクセルの情報が公開。ちょこっと見てみましたが、かなり詳細なことが書いてあります。

今までだと勝手にバイナリを解析して読み込んだり保存したりできるようにしていたソフトウェアが安定することはもちろん、これによってMicrosoft離れが促進される可能性があります。

今回の公開は、オープン化の流れに逆らえなかったというよりも、ユーザがいろいろなプラットフォームを使うようになったため、それにマイクロソフト単独で対応しきれなくなるという判断なのかなと個人的に思っています。

たとえば私はwindows XPとcentos,ubuntu,mac osXを主に使っていますが、ms officeが役に立つレベルで動作するのはwindowsのみです。
有名な話ですが、あるファイルをword/windowsで作成してword/macで読むと文章が崩れたりします。
逆もまたしかり。
なので、基本的に他人とファイルを交換する必要がある限りはwindowsを使わざるをえないというのが現状。
しかし、一方で近年linuxが大変扱いやすくなったり、mac人気が出てくる中、windows離れをし始めている人が多いのも事実。
mac上でwindowsを動かして使っている人もいます。しかしこれも時間の問題で他製品に流れていってしまうでしょう。
ビジネス上のことを考えれば、より多くの人に通用するファイルフォーマットが選択されるように圧力がかかるのは必然で、逆にＭＳはこれを十分に利用していたわけですが、それが崩壊しつつあるということでしょう。

ただレンダリングエンジンの問題もあり、たとえ同じ技術仕様書に基づいて作られたソフトであっても、それを描画するレイヤーでの処理が違えば異なる見た目になる可能性はあります。
またフォントの問題やアートワークの量の問題などもあり、そういった面でOSSのoffice suiteに比べて優位であることはかわらないのかなとも思います。

最後にこの仕様公開で進むであろうoffice suiteのSaaS化。
ベンチャーならいざ知らず、大手企業が他人の会社のバイナリを無許可で解析してそれを製品に組み込むというのは考えにくい。
しかし、今回の公開でそのハードルはすくなくとも低くなりました。
また、人員が不足しているようなベンチャーであっても多少の根性があればofficeドキュメントが扱えるようになりました。
これによってたくさん立ち上がってきてるweb osの使い勝手は多少なりともあがることになると思いますし、ユーザから見れば現状の環境からシームレスに移行できるというのはありがたく、大変有用であるように思います。

いずれにしろ、世界で最も使われているＯＳとoffice製品の技術仕様が公開されたことはとても重要で、より個々人が使いやすいプラットフォームへの移行(わかりやすく言えばwindows離れ)を促進することは確実なのかと思います。

追記：

最終的に仕様公開は「.Net Framework」などの開発系の製品までに及ぶとのこと。
gccでこういったものが簡単にコンパイルできる日がそう遠くないうちにくるということなんだろうか。

SNSで職を失った人やら何やらの話と、ＳＮＳをチェックしている人がいて、それがその人の判断に深く影響してるんではないかという話。

けど、これは裏を返せば、自分の見せたい面だけを書いてうまく利用することができるってことなんじゃないのかなぁとおもう。
ちょうど企業がコマーシャル打つような感じで。

ただ、正直な話、英語・日本語であわせて10個くらい登録してるので正直全部の個人情報を管理しきれる気がしません。
mixiでさえプロフィールは放置です。（もうやめちゃったけど

インターネット上でパブリックになっている情報の重要性を考えるなら、自分の情報を公開する範囲はコントロールできる範囲にとどめておくのがいい気がします。

追記：

lippleという学生ばっかし集めたＳＮＳがあるんですが、いつの間にかつぶれてる（落ちてる？）

tp://s01.megalodon.jp/2008-0217-1159-13/lipple.net/