講演資料が揃ったようなので個人的に重要と思われるものをまとめておこう。上２つは実際に聞いたやつで下２つは聞きたかったけど他のセッションとかぶってて聞けなかったやつ。うーん、twitter（ http://twitter.com/#!/devsumi ）とかじゃなくてタイムテーブル（ http://seshop.com/se/timetable/21 ）に資料の欄を追加してほしいな・・・終わったら急に手抜きになるのはどうか。
【16-A-1】及川卓也氏「見る前に翔べ ～ギークの工夫で社会を変えよう～」
http://www.slideshare.net/takoratta/ss-11690864
【17-E-3】 オンライン機械学習で実現する大規模データ処理
http://www.slideshare.net/devsumi/17e3
【16-C-2】桑野章弘氏/並河祐貴氏「大規模化するピグライフを支えるインフラ ～MongoDBとChefについて～」
http://www.slideshare.net/akuwano/mongodbchef
http://www.slideshare.net/namikawa/devsumi2012-pigglife-chef
【16-A-7】市谷聡啓氏「あの人の自分戦略を聞きたい！」
http://www.slideshare.net/papanda/moon-and-strategy
あと、下の２つは資料がないね。せっかく良かったのに残念だ。特に16-E-7は建築の専門家が出てきて、津波のシミュレーションから防災設計の優先順位等を意思決定する話を紹介してくれて大変ためになった。17-C-6は進行役がのんびりしすぎていてスケジュールを捌ききれてなく、興味深いテーマが２つくらいかっとばされた。
【16-E-7】3・11から見えた社会基盤としてのIT
【17-C-6】ライターズ・フィロソフィー―IT業界で書いて食っていくひとたちの哲学をきこう
16-A-1の中で、マーク・ザッカーバーグの有名なセリフ「Done is better than Perfect」が出てきた。完璧を目指すよりまずは完了させること、という意味でアジャイル思想と強く関係する言葉だと思われるが、適切な分割設計なしには達成できない巨大なプロジェクト・作業・情報処理に広く応用できそうだ。
大きいことをしたい → 大人数を投入 → 各人に仕事を配るため、完成させたい巨大なものを分割しなければならない → 分割されたもの（部品）は、全て組み立てるまで動かないのでは困る → 部品がそれ単体で意味を持ち、正しく動作するような分割の仕方が要求される というプロジェクト一般の流れは、この矢印を逆に辿っていけば個人でも大きいことができることを意味している。「各人」を、今日・明日・明後日の自分と読みかえればいい。この流れに適合する部品だけがいい部品であり、それ以外は「Done」してもしなくても「Perfect」にやりたい内容とは無関係のことだ。
そこへいくと Done is better than Perfectの教訓というのは、やれることからコツコツ実現しようという当たり前のことではなく、全体と部分の関係についての直感を常に働かせよということではないか。部品を見て組み上がりが想像できるかどうか。何かの目標のために始めた習慣が、ただ惰性となって残り元来の目標が何だったか忘れてしまったとか。何か調べたいことがあって分厚い本を最初から丁寧に読み始めたが、つまらないので捗らずそのうち調べたいことを忘れ、なぜそれを調べたいと思ったのかも忘れてしまったとか。
目に見えるのは常に部品だけであり、全体は最後に現れるか下手をするとずっと抽象物のままである。周囲の人々の行動を見れば、やっていることは大して珍しくもないし高度でもない。にもかかわらず人によって蓄積に違いが出るのは、各人の持っている部品がそのように分割されている意味の濃さによるのだろう。
2012年2月27日月曜日
2012年2月19日日曜日
Developers Summit 2012 の感想
10年後も世界で通じるエンジニアであるために Developers Summit 2012
http://codezine.jp/devsumi/2012
デブサミに２日連続で行ってきたので、とりあえず感想を書こうと思う。
まー今回は１０周年ということでこの１０年間のまとめみたいなテーマが多かったように思われ、
特に印象に残ったのは「3・11から見えた社会基盤としてのIT」と「ライターズ・フィロソフィー IT業界で書いて食っていくひとたちの哲学をきこう（仮）」という、ちょっとテクノロジー寄りではないセッションであった。
資料がアップされたら各セッションの詳細を振り返ることにする。
で、内容を詳しく覚えているわけじゃないんだけど今回は何故か開発プロセスのセッションを３つも受けてしまった。
全部面白かったけれども、スクラムだとか（アジャイルの一種）をどう日頃の開発業務に取り入れていくべきかっていう話は少なくともうちの会社には時期尚早なので、セッションの内容とは直接関係ないことばっかり考えることになったのだ。
うちの会社は就職・転職情報サイトなどリクルート的なウェブサイトをいくつか運営していて各サイトごとに社内SEみたいのがついているが、例えばソーシャルゲーム開発ができるほどの部隊がいないためエンジニアは基本的に売上を生まず人件費だけかかる存在としか（事実上）考えられておらず、上層部がITに疎いことも相まってエンジニアの数を増やす経営判断は後手に回りがちなのである。
別に自社批判をしているつもりはなく、彼らは彼らにとって確信的なビジョンのない博打をしないだけであろうと思っている。面白いソーシャルゲームに自然とユーザが集まる、つまり営業・販促の費用が抑えられエンジニアの人件費だけで莫大なPVを得られることが分かっているならエンジニアを増やす判断は難しくない。しかしノウハウもない会社が突然ソーシャルゲーム市場に参入できるわけもないので、別の例を用いてそういった「判断が難しくない状況」に持っていくことが重要になってくる。
最近DVDで「無法地帯」を見ていて、その中で元帝国陸軍大本営参謀の壹岐正がシベリア抑留を経て近畿商事（伊藤忠がモデルとされている）に入社し商社の大本営たる業務本部創設を社長に提言するが、壹岐がそれをしなければ近畿商事はしばらく重要な組織を欠いた状態のままであったと思われる。壱岐の提言が受け入れられたのは、彼の大本営参謀としての頭脳に社長が信頼を寄せていたこともあるかもしれないが、業務本部を作ることのメリットがデメリットを上回る、しかも割と短期的にそうであることをうまく説明することによって社長を「判断が難しくない状況」に持っていったのだろう。
ある分野に対する上層部の理解がないという状況でありがちだと思うのは、提言がとても中途半端なために単なる愚痴や文句になってしまい聞き入れてもらえずそれ以降あきらめるというパターンである。エンジニアの話でいえば、要は１人雇うと１人分以上の利益が出るようなエンジニアの使い方（体制）を予め用意できていればいいわけで、その用意ができるのはITに疎い上層部ではない。しかしその用意をするためには時間と方法論が必要であり、方法論のほうはエンジニアが習得すべきことであるが時間を与えるのは上層部の役目である。しかしその時間を与える理由が前述のような体制を作るためであって、時間があるとこれこれこのように体制が実現する見込みであると説明するのはエンジニアの役目である。
簡単に考えれば、既存のサイトが例えば１PVあたり１円の儲けになるとすると、１００万ほど月平均PVをアップさせればいい（厳密に言うと、その原因をエンジニアに帰着させなければいけない）のだが、新しくＡ人のエンジニアを採用して同じサイトをＡ☓１００万PV増やすのはＡが大きくなるほど難しくなる。よって、そのサイトの総PVが１００万に対して非常に大きいか（例えば月１億PVのサイトであれば、わずかな直帰率の改善で大きくPVが増える）、少なくとも同規模のサイトが複数存在する必要がある。
つまり、まず増やしやすいのは既存サイトの改善部隊であろう。PVアップの施策を行い、うまくいったらその原因を自分たちの施策に帰着させるためのレポートを行う。反対に、新規サイトの自社構築部隊は後回しになるだろう。新規サイトが増えていけばそれぞれに改善部隊を設けることができ、エンジニアの絶対数が増えるとGoogleの20％ルールのようなプロジェクトによって自前でβサービスを立ち上げられるようになる可能性が高い。
他社構築が前提となっている状態の問題点は、コーディングスキルの高い人がつまらないこと（ひいては、そういう人の需要も供給もなくなる）、また他社構築を要するほど大きい案件ばかりでは新規サイトが増えるスピードが遅いためエンジニアの絶対数が増えるスピードも遅く、２０％ルールを適用するのに必要な余剰時間が作れないこと、つまりコンテンツエンジニア※が生まれないことである。
※コンテンツエンジニア
例えばソーシャルゲームのコンテンツをエンジニアが提供しているとすれば、その人はコンテンツエンジニアである。MovableTypeで記事を作るのがライターなのであれば、そのMTを用意した人はコンテンツエンジニアではない。
PVを生む当の人がエンジニアである場合を含めれば、前述の改善部隊も広義のコンテンツエンジニアと呼べるかもしれない。
まーしかし、ここに矛盾が１つあって、自社にコンテンツエンジニア部隊を持ちたいと考える人は自分がその部隊に入りたいのであって、体制を作っていく当事者になりたいとは限らないしその手の才能なり元気なり覚悟なりがあるとも限らない。うちのエンジニアに聞いてもそのように言っている人はいる。他社構築から自社構築へと転換した話としては昨年のデブサミでDeNAの南場さんが自社の例を紹介していたが、ぼんやり覚えている限りでは、自社で開発しないのにコンサルなんてできねぇよみたいな思いから端を発していた。ふむ、そりゃそうだ。だからDeNAでは上層部のレベルでハードランディング路線を決める判断に確信が持てたんだろう。
うちの場合はコンサルなんてやってないし、他社構築でも直近では問題ない。だから少なくとも論理レベルでは、自社構築路線に転換するにはソフトランディング路線が求められる。デブサミは新しい技術、開発プロセス、クラウドなどの新製品、エンジニアのキャリアに関するセッションはあるが、非IT企業がIT企業になる過程の話を聞くことはあまりない。ある程度組織の基盤が固まったらその先は開発プロセスの分野からヒントが見つかる気もするが、その前は・・・経営論でも参照すると何か書いてあるんだろうか。
http://codezine.jp/devsumi/2012
デブサミに２日連続で行ってきたので、とりあえず感想を書こうと思う。
まー今回は１０周年ということでこの１０年間のまとめみたいなテーマが多かったように思われ、
特に印象に残ったのは「3・11から見えた社会基盤としてのIT」と「ライターズ・フィロソフィー IT業界で書いて食っていくひとたちの哲学をきこう（仮）」という、ちょっとテクノロジー寄りではないセッションであった。
資料がアップされたら各セッションの詳細を振り返ることにする。
で、内容を詳しく覚えているわけじゃないんだけど今回は何故か開発プロセスのセッションを３つも受けてしまった。
全部面白かったけれども、スクラムだとか（アジャイルの一種）をどう日頃の開発業務に取り入れていくべきかっていう話は少なくともうちの会社には時期尚早なので、セッションの内容とは直接関係ないことばっかり考えることになったのだ。
うちの会社は就職・転職情報サイトなどリクルート的なウェブサイトをいくつか運営していて各サイトごとに社内SEみたいのがついているが、例えばソーシャルゲーム開発ができるほどの部隊がいないためエンジニアは基本的に売上を生まず人件費だけかかる存在としか（事実上）考えられておらず、上層部がITに疎いことも相まってエンジニアの数を増やす経営判断は後手に回りがちなのである。
別に自社批判をしているつもりはなく、彼らは彼らにとって確信的なビジョンのない博打をしないだけであろうと思っている。面白いソーシャルゲームに自然とユーザが集まる、つまり営業・販促の費用が抑えられエンジニアの人件費だけで莫大なPVを得られることが分かっているならエンジニアを増やす判断は難しくない。しかしノウハウもない会社が突然ソーシャルゲーム市場に参入できるわけもないので、別の例を用いてそういった「判断が難しくない状況」に持っていくことが重要になってくる。
最近DVDで「無法地帯」を見ていて、その中で元帝国陸軍大本営参謀の壹岐正がシベリア抑留を経て近畿商事（伊藤忠がモデルとされている）に入社し商社の大本営たる業務本部創設を社長に提言するが、壹岐がそれをしなければ近畿商事はしばらく重要な組織を欠いた状態のままであったと思われる。壱岐の提言が受け入れられたのは、彼の大本営参謀としての頭脳に社長が信頼を寄せていたこともあるかもしれないが、業務本部を作ることのメリットがデメリットを上回る、しかも割と短期的にそうであることをうまく説明することによって社長を「判断が難しくない状況」に持っていったのだろう。
ある分野に対する上層部の理解がないという状況でありがちだと思うのは、提言がとても中途半端なために単なる愚痴や文句になってしまい聞き入れてもらえずそれ以降あきらめるというパターンである。エンジニアの話でいえば、要は１人雇うと１人分以上の利益が出るようなエンジニアの使い方（体制）を予め用意できていればいいわけで、その用意ができるのはITに疎い上層部ではない。しかしその用意をするためには時間と方法論が必要であり、方法論のほうはエンジニアが習得すべきことであるが時間を与えるのは上層部の役目である。しかしその時間を与える理由が前述のような体制を作るためであって、時間があるとこれこれこのように体制が実現する見込みであると説明するのはエンジニアの役目である。
簡単に考えれば、既存のサイトが例えば１PVあたり１円の儲けになるとすると、１００万ほど月平均PVをアップさせればいい（厳密に言うと、その原因をエンジニアに帰着させなければいけない）のだが、新しくＡ人のエンジニアを採用して同じサイトをＡ☓１００万PV増やすのはＡが大きくなるほど難しくなる。よって、そのサイトの総PVが１００万に対して非常に大きいか（例えば月１億PVのサイトであれば、わずかな直帰率の改善で大きくPVが増える）、少なくとも同規模のサイトが複数存在する必要がある。
つまり、まず増やしやすいのは既存サイトの改善部隊であろう。PVアップの施策を行い、うまくいったらその原因を自分たちの施策に帰着させるためのレポートを行う。反対に、新規サイトの自社構築部隊は後回しになるだろう。新規サイトが増えていけばそれぞれに改善部隊を設けることができ、エンジニアの絶対数が増えるとGoogleの20％ルールのようなプロジェクトによって自前でβサービスを立ち上げられるようになる可能性が高い。
他社構築が前提となっている状態の問題点は、コーディングスキルの高い人がつまらないこと（ひいては、そういう人の需要も供給もなくなる）、また他社構築を要するほど大きい案件ばかりでは新規サイトが増えるスピードが遅いためエンジニアの絶対数が増えるスピードも遅く、２０％ルールを適用するのに必要な余剰時間が作れないこと、つまりコンテンツエンジニア※が生まれないことである。
※コンテンツエンジニア
例えばソーシャルゲームのコンテンツをエンジニアが提供しているとすれば、その人はコンテンツエンジニアである。MovableTypeで記事を作るのがライターなのであれば、そのMTを用意した人はコンテンツエンジニアではない。
PVを生む当の人がエンジニアである場合を含めれば、前述の改善部隊も広義のコンテンツエンジニアと呼べるかもしれない。
まーしかし、ここに矛盾が１つあって、自社にコンテンツエンジニア部隊を持ちたいと考える人は自分がその部隊に入りたいのであって、体制を作っていく当事者になりたいとは限らないしその手の才能なり元気なり覚悟なりがあるとも限らない。うちのエンジニアに聞いてもそのように言っている人はいる。他社構築から自社構築へと転換した話としては昨年のデブサミでDeNAの南場さんが自社の例を紹介していたが、ぼんやり覚えている限りでは、自社で開発しないのにコンサルなんてできねぇよみたいな思いから端を発していた。ふむ、そりゃそうだ。だからDeNAでは上層部のレベルでハードランディング路線を決める判断に確信が持てたんだろう。
うちの場合はコンサルなんてやってないし、他社構築でも直近では問題ない。だから少なくとも論理レベルでは、自社構築路線に転換するにはソフトランディング路線が求められる。デブサミは新しい技術、開発プロセス、クラウドなどの新製品、エンジニアのキャリアに関するセッションはあるが、非IT企業がIT企業になる過程の話を聞くことはあまりない。ある程度組織の基盤が固まったらその先は開発プロセスの分野からヒントが見つかる気もするが、その前は・・・経営論でも参照すると何か書いてあるんだろうか。
2012年2月14日火曜日
利他について
タイム・コンサルタントの日誌から : 書評：「持続不可能性」 サイモン・レヴィン著
http://brevis.exblog.jp/14689955/
なんか前にもReblogしたような気がするけど・・・既視感かもしれないけど・・・なんか気になるテーマです、利他。
ふつうは生物の進化は自然淘汰がその原理とされている。個体が自分自身のためにつまり「利己的に」生き、その生き方が自分の長寿というか繁栄力をもたらすのであれば、その生き方に対応した遺伝子が次の世代において優勢になる。これは利他を装った利己であっても同じことでしょう。なぜなら「生き方が自分の長寿というか繁栄力をもたらすのであれば・・・」という文章中の「生き方」は、それがどんな内容であっても文章全体の意味を壊さないから。
でも引用文中の「自種の適応可能性を高めるから」という部分は簡単に見逃せない。ここで言ってるのは、ある生き方が（めぐりめぐって最終的に）自分のためにならなくても、自分の生物種の繁栄をもたらすならばその生き方が自然淘汰によって優勢になるという意味かと思うが、るろけんの志々雄真実も言ってるとおり「強い者が生き残るんじゃない、生き残ったものが強いんだ」であり、遺伝子の拡散ってそもそも個体が生き残らないことには起きようがないわけで、仮にある生き方が自分の生物種の繁栄に寄与するものだとしても自分自身のためにならないならその生き方は後世に伝わらない。
といっても、人間なら利他があっても不思議はないかなという気もする。人間には遺伝子とは別の形で文化を伝える手段があり、それぞれ文化Aと文化Bを持つ国家AとBがあって、それらが戦争でもして国家Bが消滅した場合、Bの文化もあらかた消滅するわけであるから文化Aが後世に残るだろう。この場合、利他が国家のためになるなら利他が美徳として奨励されていたのは文化BではなくAのほうである可能性が高い。要するに利他は文化であって本能じゃないんじゃなかろうか。
もし利他が本能なのだとしたら、わざわざ奨励する必要はないわけである。お母さんを大切にしましょう・・・これは遠まわしな利己だ、だからそんなに奨励する必要はない。でも子供が成人したら彼は母親なしで生きていける、だから成人した子供が母親を大切にするのは遠まわしな利己とは言えない、つまり利他だ、だから奨励する必要があって、実際奨励に用いられている言葉は「親孝行」でありその対象は大人である。
もし原始的な生物に利他があるとするなら、その生物種の個体間にも文化的なものがあるんじゃないだろうか。例えば模倣とか。ある個体が気まぐれで利他アクションを起こし、それがなんか真似したい感じだったので近くにいた個体が次々に真似をして、世代間のオーバーラップによって伝えられていくような。集団的にその利他アクションを行うと生物種にとって良い影響があるなら、利他アクションを行わない類似の生物種より繁栄しやすいことになるだろう。
つまり、遺伝子じゃなくアフォーダンス的な反応（原始的な模倣）によって伝わっていくことって実は結構あるのだが、我々から見て利己的と思われる行動は自然淘汰ということにして、利他的と思われる行動は何とか利己に帰着させようという、そういう間違いをしてる可能性ってないのかしらと思ったりした。
http://brevis.exblog.jp/14689955/
生物界には、「利他的」としか言いようのない、不思議な現象が時々ある。それを、めぐりめぐって最終的には自己や自種の適応可能性を高めるから、という視点から説明しようという、いかにもネオ・ダーウィニズム的な研究アプローチである。
しかし、本当にそういう説明ですべてが納得できるのだろうか。進化ゲーム理論やネオ・ダーウィニズムには、競争原理はあれども、協働原理は存在しようがない。前提条件から排除されているからだ。
なんか前にもReblogしたような気がするけど・・・既視感かもしれないけど・・・なんか気になるテーマです、利他。
ふつうは生物の進化は自然淘汰がその原理とされている。個体が自分自身のためにつまり「利己的に」生き、その生き方が自分の長寿というか繁栄力をもたらすのであれば、その生き方に対応した遺伝子が次の世代において優勢になる。これは利他を装った利己であっても同じことでしょう。なぜなら「生き方が自分の長寿というか繁栄力をもたらすのであれば・・・」という文章中の「生き方」は、それがどんな内容であっても文章全体の意味を壊さないから。
でも引用文中の「自種の適応可能性を高めるから」という部分は簡単に見逃せない。ここで言ってるのは、ある生き方が（めぐりめぐって最終的に）自分のためにならなくても、自分の生物種の繁栄をもたらすならばその生き方が自然淘汰によって優勢になるという意味かと思うが、るろけんの志々雄真実も言ってるとおり「強い者が生き残るんじゃない、生き残ったものが強いんだ」であり、遺伝子の拡散ってそもそも個体が生き残らないことには起きようがないわけで、仮にある生き方が自分の生物種の繁栄に寄与するものだとしても自分自身のためにならないならその生き方は後世に伝わらない。
といっても、人間なら利他があっても不思議はないかなという気もする。人間には遺伝子とは別の形で文化を伝える手段があり、それぞれ文化Aと文化Bを持つ国家AとBがあって、それらが戦争でもして国家Bが消滅した場合、Bの文化もあらかた消滅するわけであるから文化Aが後世に残るだろう。この場合、利他が国家のためになるなら利他が美徳として奨励されていたのは文化BではなくAのほうである可能性が高い。要するに利他は文化であって本能じゃないんじゃなかろうか。
もし利他が本能なのだとしたら、わざわざ奨励する必要はないわけである。お母さんを大切にしましょう・・・これは遠まわしな利己だ、だからそんなに奨励する必要はない。でも子供が成人したら彼は母親なしで生きていける、だから成人した子供が母親を大切にするのは遠まわしな利己とは言えない、つまり利他だ、だから奨励する必要があって、実際奨励に用いられている言葉は「親孝行」でありその対象は大人である。
もし原始的な生物に利他があるとするなら、その生物種の個体間にも文化的なものがあるんじゃないだろうか。例えば模倣とか。ある個体が気まぐれで利他アクションを起こし、それがなんか真似したい感じだったので近くにいた個体が次々に真似をして、世代間のオーバーラップによって伝えられていくような。集団的にその利他アクションを行うと生物種にとって良い影響があるなら、利他アクションを行わない類似の生物種より繁栄しやすいことになるだろう。
つまり、遺伝子じゃなくアフォーダンス的な反応（原始的な模倣）によって伝わっていくことって実は結構あるのだが、我々から見て利己的と思われる行動は自然淘汰ということにして、利他的と思われる行動は何とか利己に帰着させようという、そういう間違いをしてる可能性ってないのかしらと思ったりした。
登録:
投稿 (Atom)