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企業になる過程の話を聞くことはあまりない。ある程度組織の基盤が固まったらその先は開発プロセスの分野からヒントが見つかる気もするが、その前は・・・経営論でも参照すると何か書いてあるんだろうか。
2012年2月19日日曜日
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のほうである可能性が高い。要するに利他は文化であって本能じゃないんじゃなかろうか。
もし利他が本能なのだとしたら、わざわざ奨励する必要はないわけである。お母さんを大切にしましょう・・・これは遠まわしな利己だ、だからそんなに奨励する必要はない。でも子供が成人したら彼は母親なしで生きていける、だから成人した子供が母親を大切にするのは遠まわしな利己とは言えない、つまり利他だ、だから奨励する必要があって、実際奨励に用いられている言葉は「親孝行」でありその対象は大人である。
もし原始的な生物に利他があるとするなら、その生物種の個体間にも文化的なものがあるんじゃないだろうか。例えば模倣とか。ある個体が気まぐれで利他アクションを起こし、それがなんか真似したい感じだったので近くにいた個体が次々に真似をして、世代間のオーバーラップによって伝えられていくような。集団的にその利他アクションを行うと生物種にとって良い影響があるなら、利他アクションを行わない類似の生物種より繁栄しやすいことになるだろう。
つまり、遺伝子じゃなくアフォーダンス的な反応（原始的な模倣）によって伝わっていくことって実は結構あるのだが、我々から見て利己的と思われる行動は自然淘汰ということにして、利他的と思われる行動は何とか利己に帰着させようという、そういう間違いをしてる可能性ってないのかしらと思ったりした。
2012年1月28日土曜日
SinatraとSequel・Hamlで掲示板アプリを作る そしてHerokuへあげる
WEB+DB Press Vol.65「Write Less, Do More」のコラムから引用：
それはそれとして、以下のアプリはHamlとsassのイージーサンプルとなっているので掘り起こしてみた。
Ruby Freaks Lounge：第9回 SinatraとSequel・Hamlで掲示板アプリを作る｜gihyo.jp … 技術評論社
http://gihyo.jp/dev/serial/01/ruby/0009
上の通り、公開されてるコード（ http://github.com/yhara/sinatbbs/tree/magazine ）をとってきて動かせばローカルで掲示板アプリがサクっと動くが、Herokuで動かすには少し修正がいる。以下、その手順をメモ。
◯ファイル追加など
- Gemfile
sinatra, haml, sequel, sqlite3, heroku をGemfileに書き、bundle install --path ./vendor/bundle としておく。
- start.rb 修正
require './model/comment.rb' （./を先頭につける）
※
Ruby 1.9.2から$LOAD_PATHにカレントディレクトリが含まれなくなった - ぬいぐるみライフ(仮)
http://d.hatena.ne.jp/mickey24/20100907/1283869273
- comment.rb 修正
Sequel.connect(ENV['DATABASE_URL'] || "sqlite://db/development.sqlite3")
※
デプロイ時も考慮して、DBへの接続は Sequel.connect(ENV['DATABASE_URL'] || 'sqlite://my.db') という感じで書く必要あり。 - Lost+Found
http://d.hatena.ne.jp/Snaka/20090704/1246712748
- migration用ファイルの作成
db/migrate/001_create_posts.rb
- config.ru作成
require './start.rb'
run Sinatra::Application
※
Ruby Freaks Lounge：第23回 Rackとは何か（1）Rackの生まれた背景｜gihyo.jp … 技術評論社
http://gihyo.jp/dev/serial/01/ruby/0023
◯ローカルで動かしてみる
# rake db:migrate
※sqliteなので不要だが、herokuで必要なので確認しておく
# rackup
◯Herokuで動かす
# git init
# git add ./
# git commit -am "＜コメント＞"
# heroku create ＜app名＞
# git push heroku master
# heroku rake db:migrate
# heroku open
http://bbs-sp3.heroku.com/
完成。
参考サイト：
CSS拡張メタ言語「SCSS(Sass)」と「LESS」の比較 - (DxD)∞
http://dxd8.com/archives/217/
Ruby Sequel DBアクセスライブラリ - yshのメモ日記
http://d.hatena.ne.jp/yshgt/20080629/1214720897
herokuでsqliteなsequelつかうときのメモ - Lost+Found
http://d.hatena.ne.jp/Snaka/20090709/1247155835
sequelでmigration | ゆーすけぶろぐ
http://yusukezzz.net/blog/archives/1574
Sinatraの使い方 - ayaketanのプログラミング勉強日記
http://d.hatena.ne.jp/ayaketan/20111219/1324295283
(Railsの進化によって）Rubyの記述量がどんどん削減された結果、今度はそれ以外のコードがネックになってきたと言えるでしょう。だから次はRuby以外のコードをあまり書かなくていいようにと、SCSSやCoffeeScriptが取り込まれたのでしょうネックになってきたというか、なんでrubyは綺麗に書けるのにHTMLとかCSSとかこんな冗長にしか書けないんだという不満が潔癖症のプログラマを動かしたように思う。まぁ、haml・coffee・scssを導入したらしたで、新しい書き方が３つ増えるわけで、一人でやる分にはいいけどチームで開発する時どうなんだという気がしないでもないが・・・やはり目先の学習コストに対する寛容さは人それぞれだと思うし。
それはそれとして、以下のアプリはHamlとsassのイージーサンプルとなっているので掘り起こしてみた。
Ruby Freaks Lounge：第9回 SinatraとSequel・Hamlで掲示板アプリを作る｜gihyo.jp … 技術評論社
http://gihyo.jp/dev/serial/01/ruby/0009
上の通り、公開されてるコード（ http://github.com/yhara/sinatbbs/tree/magazine ）をとってきて動かせばローカルで掲示板アプリがサクっと動くが、Herokuで動かすには少し修正がいる。以下、その手順をメモ。
◯ファイル追加など
- Gemfile
sinatra, haml, sequel, sqlite3, heroku をGemfileに書き、bundle install --path ./vendor/bundle としておく。
- start.rb 修正
require './model/comment.rb' （./を先頭につける）
※
Ruby 1.9.2から$LOAD_PATHにカレントディレクトリが含まれなくなった - ぬいぐるみライフ(仮)
http://d.hatena.ne.jp/mickey24/20100907/1283869273
- comment.rb 修正
Sequel.connect(ENV['DATABASE_URL'] || "sqlite://db/development.sqlite3")
※
デプロイ時も考慮して、DBへの接続は Sequel.connect(ENV['DATABASE_URL'] || 'sqlite://my.db') という感じで書く必要あり。 - Lost+Found
http://d.hatena.ne.jp/Snaka/20090704/1246712748
- migration用ファイルの作成
db/migrate/001_create_posts.rb
class CreateComments < Sequel::Migration
def up
create_table :comments do
primary_key :id
text :name
text :title
text :message
timestamp :posted_date
end
end
end
- Rakefile作成
require 'rubygems'
require 'rake'
require 'sequel'
require 'sequel/extensions/migration'
namespace :db do
desc "migrate database"
task :migrate do
DB = Sequel.connect(ENV['DATABASE_URL'] ||'sqlite://db/development.sqlite3')
Sequel::Migrator.apply(DB, './db/migrate')
end
end- config.ru作成
require './start.rb'
run Sinatra::Application
※
Ruby Freaks Lounge：第23回 Rackとは何か（1）Rackの生まれた背景｜gihyo.jp … 技術評論社
http://gihyo.jp/dev/serial/01/ruby/0023
◯ローカルで動かしてみる
# rake db:migrate
※sqliteなので不要だが、herokuで必要なので確認しておく
# rackup
◯Herokuで動かす
# git init
# git add ./
# git commit -am "＜コメント＞"
# heroku create ＜app名＞
# git push heroku master
# heroku rake db:migrate
# heroku open
http://bbs-sp3.heroku.com/
完成。
参考サイト：
CSS拡張メタ言語「SCSS(Sass)」と「LESS」の比較 - (DxD)∞
http://dxd8.com/archives/217/
Ruby Sequel DBアクセスライブラリ - yshのメモ日記
http://d.hatena.ne.jp/yshgt/20080629/1214720897
herokuでsqliteなsequelつかうときのメモ - Lost+Found
http://d.hatena.ne.jp/Snaka/20090709/1247155835
sequelでmigration | ゆーすけぶろぐ
http://yusukezzz.net/blog/archives/1574
Sinatraの使い方 - ayaketanのプログラミング勉強日記
http://d.hatena.ne.jp/ayaketan/20111219/1324295283
登録:
投稿 (Atom)