ブログ執筆中 このページをアンテナに追加

2009-06-21

あらゆる仕事はインフラになる

研究のプログラムが上手く動作しなくてむしゃくしゃしているので、適当に今思っていることを書きなぐる。

営業だろうと企画だろうと開発だろうと研究だろうとなんだろうと、仕事とは人が嫌がることを代わりにやってお金を頂くことです。それが自分にとって楽しいことかどうかは関係ない。そして、仕事とは常にパイが減るものです。それはコンサルティング業界やらIT業界、研究職という業種/職業が存在する以上、避けられないこと。

ただ、パイが減らないように見える業種もあります。例えば、ゲーム業界、テレビ業界、風俗なんかもそうですね。彼らは需要を生みだすことによりパイを増やし続けています。

しかし、需要を生み出すということは何かしら目新しさが必要。それは、人間全体にとってではなく、本人にとってであれば良いけれども、でもそういうものが必要。だからテレビもゲームも既にインフラになりつつある。

この間のInprotの夏野さんとひろゆきの講演を公聴させていただいたのだが、ひろゆきが「TBSは軒並み視聴率を落としたが、その中で一番視聴率が高かったのは再放送の水戸黄門だった」というお話がありました。

夏野

 過去に、TBS番組改編して、60%を生放送にしたんですね。

 そうしたら視聴率が激減。

 ちなみに、再放送の水戸黄門が一番だったそうで。

 (会場爆笑)

no title

あれ、これひろゆきの発言じゃなかったっけ。まあいいや

これはTBS現在あまりよろしくないことを意図して出た発言ではありますが、もう一つ見逃せない事実があります。面白い作品は何度も見られるということです。

だからゲームもリメイクが売れるのも当然。


ということを考えると、最終的に残るのは新しい企画を打ち出してくことではなく、いかにして良いものを継続的に売っていくかになります。ゲーム業界も今は右肩上がりですが、必ずパイは下がっていきます。

このことは、畑村洋太郎先生も「技術の創造と設計」という本の中でおっしゃっております。

すべて産業の成長と衰退は、この図に示すような飽和曲線を描くのである。

(中略)

すべての産業は、生産量が少ない「萌芽期」、増えていく「発展期」、だんだんと増えなくなっていく「成熟期」。そして減っていく「衰退期」という4つの時期を通る。そして、非常に不思議なことだが、萌芽期の終わりから成熟期の終わりまでの期間は、どんなに産業かに関係なく、約30年になっているのである。

技術の創造と設計

このことを事実として捉えるのならば、例えばゲーム業界であれば、ファミリーコンピュータが登場した1983年を萌芽期の終わりとするならば、衰退期に入るのは2013年ごろとなります。今、ゲーム業界は空前の人気業界ですが、その人たちが働きざかりになるころには、ゲームを作り出す人たちのパイの減り方が半端なくなっていると思います。事実、テレビは既に衰退してきてますよね。少なくとも新しいことを生み出すことに関しては、かなり弱くなってきていると思います。

であれば、ゲームを作り出す人たちになるより、ゲームを継続的に提示する側になるほうが賢い。ただし、継続的な顧客が見込めるような方法で。だからリメイクは強い。某N社には内定を頂いた友人がいるので、ちょっと心配。ま、めっちゃ面白くて、頭の良い彼なら大丈夫だとは思うが。

近代?は研究はお金持ちが有り余った時間を使って趣味でやるものだったわけだが、現代もそう遠くない未来、同じようになるだろう。昔は手法が確立してなくて、現代は研究する領域がなくてと理由はことなるものの、結局のところ同じ状況になるだろう。

だから、会社としてもう残っている領域は、どのようにインフラを提供していくかになってしまう。ゲームも新しく作り出すことより、例えば過去のゲームを一緒にやっている感覚の共有に価値を見いださせることにより、継続的な収入を得る方向性に変えていかなきゃならない。プラットフォームビジネスとかまさにそんな感じだし。作る側は殆ど趣味であることが正しくて、時々ヒット作品が出て、そこから新しい発展がおこるかも程度で良いんじゃないかしら。製品をオープンソースにして、講習会でお金を取っているとかも同じですよね。

向いてることを仕事にし、好きなことは趣味でやろうということになるんでしょう。だから、需要を生み出し続ける業種につとめることは良い選択では決して無い。売り抜くことで一生過ごせるだけの収入が得られるのであれば良いが、そうでなければやめて、安定している企業に入るべき、と思う。

そして僕は博士後期課程を志しているという矛盾。はぁ。

2009-01-30

10万ヒットを達成致しました

どうもこんにちは、tomityこと富田です。

先日10万ヒットを達成致しました。

そして何だかんだでRSS購読してくださる方が結構いらっしゃるらしく、[TopHatenar] tomity さんの順位によるとLDRだけで55名もいるそうですね。ありがとうございます。ひえー。恥ずかしい。

さて、いろんなWebサービス(主にTwitterはてな関連とニコ動ですが)についての考察やら、こんなサービスあったらいいんじゃないかとか、基本的に勝手に気ままにやってきましたが、今回の10万ヒットを期に方向性を少し変えたいと思っています。簡単にいうと研究分野とリンクする話をしたり、もっと社会に目を向けたいと思っております。

記事で時々触れていたように、去年の4月から自然言語処理系の研究室に所属しております。そもそも、自然言語とは日常私たちが利用している言語のことであり、プログラム言語と区別する名目で自然言語とこの業界では呼びます。そして、自然言語処理とは、その名前に騙されがちですが自然言語を処理するというだけではなくて、自然言語を解析するステップも含まれます。そして、自然言語を処理したシステムの提案なんかも含まれるんです。要するに、自然言語に関わることが何でもOKの分野と言えば、まあそのとおりです。

そうなると、どこまでが趣味で、どこからが研究なのかという線引きが難しくなります。以前マッシュペディアというのも流行りましたが、取り合えずこうなんじゃないという法則性を推測して、フィルタリングすることでそこそこのものができてしまいます。ただ、その方法だとある時点から急に精度向上が難しくなり、コストパフォーマンスに合わなくなってきます。それ以上をやるのが自然言語処理存在価値かなと思います。

自然言語処理に語るのはこれくらいにして、話を戻すと、そろそろちょっと自然言語処理系に近い話をしていこうかなと。一年間、こちらの分野に居させてもらって解ったことは、この分野でやっていくために必要な学問よりの知識が非常に多い。統計機械学習アルゴリズム(特にDPや計算複雑性)、形式文法(文脈自由文法等)、情報検索などなど。もちろんLinuxの知識もいります。

それに、自然言語を扱っていればいいのと、比較的短期間で成果がでるので、規模としてはそれほど大きくない(と思ってますが実際どうなんでしょう?)ものの、観測範囲が大きすぎるなとも感じます。

ですので、自分の理解を確認する意味も込めて、勉強したものとか、研究時に読んだ論文とかこのブログで紹介していきたいと思っています。そうすれば、身についたことになることをチェックできるようになるので、俺としてはありがたい。そういう記事が増えてくるとあんまり面白くないという人は結構いると思いますが、どうかご容赦願いたい。

あと僕は博士行くつもりですが、絶対アカデミックに残るんだという考えはそれほどなくて、社会的に価値を作れるのであれば企業に行くことも考えてます。

そうしたとき、企業がどういうサービスを展開してるとか、どんなものが今求められているか(特にネット/携帯のライトユーザー)というものを知らないのはならないと最近考えてます。

はっきり言って僕のブログって社会とはまるで関係ないですよね。はてな村には近いけどw

だからもう少し社会に目を向けた記事を取り上げるようになると思います。

とにかく、どちらにしても、今までみたいな考察系の記事は減ってくると思います。ですので、この間の機械学習についてのエントリみたいに専門性の高いことになったり、ニュースに敏感になって、タダ取り上げる記事が多くなったりと、今までの記事とは方向性が異なる記事が今後多くなってくるとは思いますが、どうか見捨てないでやってくださいまし。


あと、実質メンテナンスできなくなってしまったので、提供していたサービスはすべて終了させていただきます。どうかご了承ください。

2008-12-04

[][]プログラミングとマニュアルを作成すること

ロジックをつなげて流れを作り出し1つのアウトプットを出すという行いは、文章を書いて1つのエントリなり日記なりを書くという行いと、相当の部分が似ていると私も感じます。

プログラミングと文章を書くこと - GoTheDistance

プログラミングは文章を書くことというのは半分正解で半分間違いだと思います。プログラミングそのものには起承転結は必要ありません。

相手は機械ですので、指示したとおりに動きます。なので、その指示をするプログラムは、単純に言えば、どう動かせば自分が望むことをやってくれるかを書く作業であると言えます。

これってマニュアル作りに通じるところがあって、マニュアルは人を動かすために書くものです。

機械と人の差はあれど、その根本は変わらないと私は考えます。

ただし、もちろん違いはあって、マニュアルは多少の不備があっても人が補完してくれますが、プログラムはそうは行きません。ですから、プログラムを書く人はマニュアルを書く以上の正確性を求められます。

でもこれ逆から見ると、面白い着眼点になっていて、プログラムをバグを少なく書ける人はマニュアルを正確に作ることができるということを意味しているんですよね。


他にもプログラムとマニュアルの違いはあり、それは動かす対象の性質の違いです。人は正確に、また一つのことに集中して物事を行うのが苦手ですが、逆に機械は状況に応じて柔軟に対応するのが苦手です。対象の違いにより作り方は違います。

でも、機械の中にも得手不得手があります。例えば関数型のプログラム言語とオブジェクト思考型のプログラム言語では効率良く書ける書き方が違います。また、従来のコンピュータと量子コンピュータでは得意とする分野が違います。詳しくは知りませんが、因数分解が得意らしいですね、量子。あとパイプライン処理を多段持っているアーキテクチャーとそうでないものでは早い書き方はまた違うらしい。知るかって感じですが。

しかし、結局、マニュアルも対象とする人の専門性や気質に対し、より良い方法が違います。

プログラムそのものが上手く書ける人は、マニュアル作りが上手い人になれそうです。


文章を作るのに近いのは、ツール・サービス・アプリケーション・システムを作ることだと思います。

どうしてそのツールを作るのか。どうして現在の社会に必要なのか。どのくらいの期間規模で作ることができるのか。そのツールが生まれることで何が変わるのか。そして、それを実現する具体的な方法(プログラム)は何か。

一種のストーリーになっています。どうやってツールを意義あるものにするか。文章と近いのは、むしろここなんじゃないかなと思っているのでした。

あと、僕はSIer屋さんではないので想像でしかないですが、SIer屋さんに限って、文章とプログラムは近いという考えも理解できなくはありません。SIer屋さんは、プログラムのロジックをプログラムが分からない顧客に見せなければならなりません。顧客により理解して頂くために、プログラムにストーリーを入れることもあるでしょう。例え、速度を犠牲にしてでも。だから、プログラムが文章に見えるのかもしれません。

2008-10-31

[][]プログラミングに対するスタンスの差がモロに出てるね

思ったことをつらつらと。結構適当かも。批判して。

ちょっと囓っただけの素人が自分を過信して陥る三つの罠? - カレーなる辛口Javaな転職日記

はてブでふろむださんが指摘しているように、アプリ屋さんの意見だなぁと思う。そして、この意見が決して間違っているわけではない。

中途半端に優秀なプログラマが「正しいプログラミングテクニック」だと妄信しがちな3つポイント - 分裂勘違い君劇場 by ふろむだ

サービス屋さんの意見というかデータを扱うプログラムを書く人の意見だと思います。データを扱うので、プログラムはデータベースから目的のデータを取ってくるなり、取ってきたデータを如何に表示するかということが問題となり、この目的にプログラムを使う場合はデータの付属品でしかありません。Ruby On Rails最近触ったけれども、データベースから取ってくる使い方は1行で済んでしまう。こうなると、ますますこの使い方におけるプログラミングの重要性は低くなっていく。今後もこの流れは加速されると思われる。かける時間に見合わないような概念は消えていくだろう。

例えば、インターフェースさえ既定してしまえば、その内部でのスコープはあまり重視しなくてもよくなってくる。もちろんスコープを規定しないと、予期しない使われ方をしたり、いろんなところからアクセスを許可することになるのでスパゲッティコードになる可能性がある。スパゲッティコードを良くないけど、フレームワークによってコードを管理することで、コードがぐちゃぐちゃになるリスクはだいぶ減っていることを考えれば、スコープの既定は優先度が低いタスクになるだろう。 

あと大事なこととして、サービスはデータの見方が重要であると思っている。WWWのリンク構造を評価システムと見ることでWebページのランキングを構築した PageRankであったり、Webページのアクセスを集計してサイトの導線を解析したり、おもしろいサービスの中にはデータの見方を買えることで成功しているサービスが少なくない。見方を変えると言うことは、データの扱いかたを変えるということだ。もし開発中にデータの見方を変えることになれば、今まで使っていたコードは捨てるしかなくなる。一部のコードは再利用できるかもしれないが、部品としては役に立たなくなる。捨てる可能性のあるコードが多くなるのに、そこに注力しすぎるのはどうなのだろうか。

一方、アプリケーションを作る場合は事情が異なる。大規模なプログラミングを行うことが多くなるので、クラスやモジュールなどで部品単位にまとめないと何がなんだかわからなくなる。そして部品の数も多いので、それの使い方をドキュメント・スコープの両方で制御したほうが、誤りが少なくなる。グローバルで扱うほうが良いケースはそれほど登場しない。あってもログ出力とか、ヘルパー関数とかかなぁ。その場合、先のエントリで否定された3項目はほとんどの場合プラスにはたらくので、「3つの迷信」を守るのはいいんじゃないかなと思います。

ちなみに、俺はオブジェクト指向があまり好きではない。正確には自分が設計する範囲でオブジェクト指向があまり好きではない。共通部分が多くなることは良いことだと思うが、捨てる可能性の高い部分に意識の大部分を向けるのは無駄であると思っている。俺は、絶対この見方がは変わることはないと言える場合だけ共通化・抽象化を使う。そうでない場合は手続き的な書き方を好むようになった。サービスを作る場合、継承ってほとんど害悪にちかいでしょ。


プログラムをメインに据えるか、サイドに据えるかの立場の違いによりこの二つの意見の衝突が起こっているだと私は考えます。捨てられないコードと捨てても良いコードでは書き方が違うよね、というお話かなw

2008-08-01

[][]「プログラミング能力とは」によってわかるプログラミングとは

めっさ亀レスですが。

$id を $name に変えるなどして、indexをチョチョイといじればなんとかなると思っていた。

ギークなお姉さんは好きですか CoolなURLを作るには

この一文にべにぢょの成長を感じた。

昔だったら絶対思わなかった感覚だろう。

プログラミング能力とは - そのままなめて

「5*2はいくつですか」

とほとんどの人は10と答えると思いますが、「5*2=10」が成り立つのは「5+5=10」と「a*2=a+a」が成り立つからです。「5*2=5+5=10」ね。

でも、「5+5=10」が成り立たず、「5+5=0」という世界だとどうでしょう。「5*2=5+5=0」ですから同じ計算でも答えが違います。

でも「5+5=0」になる世界なんて、私たちのすぐ側に転がっています。10進法の世界では「5+5=10」ですが、この計算の一桁目を見れば「5+5=0」です。単に私たちが気づかないだけで、気づかなくても困らない。

論理とは、2つの要素からなります

1.前提(仮定、知識)

2.ルール(演算、述語論理)

数学だと前提が「1,2,3」という数字、ルールが「+*」等の演算子となります。先ほどの例だと「5+5=10」と「a*2=a+a」などがルールですね。

プログラミングをする上では、前提も、ルールも、その多くが自分で決めることが出来ます。低級であろうと高級であろうとそれは変わりません。関数というのはこれこれを入力したらこれこれが出力されるというルールに他なりませんし、変数の値がいくつだと何を表しているかというのは前提ですよね。

ライブラリやフレームワークを用いるということは、相手の前提とルールに乗っかることでもあります。つまり、ライブラリを使うということは、相手のルールに縛られてしまうということでもあります。だからライブラリを用いるときは、そのルールと矛盾しない、アプリケーションを作るために必要な追加ルールを考え出さなきゃなりません。そして、その追加ルールを足すことでアプリケーションがホントに作れるのかを頭の中で予想できる必要もあります。

人のプログラムを読んで改良するということも同じです。ただその前提やルールが完全に判るとは限りません。バグもあって仕様書に書かれているルール通りに動かないかもしれないし、仕様書がそもそもないこともあり得ます。ルールを推測することも必要になる場面もあります。

ルールを知り、ルールを操れること、これがプログラミング能力なのかなぁと最近思っています。


べにぢょさんの話に戻すけど、この話はWebアプリケーションのルールを知ることで、どう操れば問題を解決できるのかの策が見えるようになってきたということですよね。

$id を $name に変えるなどして、indexをチョチョイといじればなんとかなると思っていた。

ギークなお姉さんは好きですか CoolなURLを作るには

そういう感覚を得ることがプログラミング能力だと思う。

GoTheさんの話も同じく、ルールの組み合わせできちんと動くのかをシュミレートするという話。

「いける」と思った数×「やべぇ」と焦った数=プログラミング能力(「できるようになった」数)

「いける」と思った数だけプログラミングは上達する。 - GoTheDistance


おまけ

Prologってプログラム言語があるけれど、あれは前提とルールしかない言語だよね。だからあれが純粋なプログラム言語という気がします。ただしルールが厳密すぎて出来ることが偏りすぎるのが難点だけど。