上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。
コミュニティ検索 »
TechCrunchなどの海外(主に北米)ITニュース記事を読んでいると、疑問が湧いてきます。
「なんでこんなに(テクノロジ、サービス内容、ビジネス的に)優秀なサービスが多く出てくるんだろう?」
     ↓
「なんでこんなに(テクノロジ的に)優秀なサービスを作れるエンジニアが多いんだろう?」

ある統計によると、世界でも日本のエンジニアが一定量のコードに対するバグ含有率が一番少なく、
最も高品質=優秀であるというデータがあります。
実際、その気になれば良いものを作れそうな人を何人も知っています。
なのに日本に世界で通用する独創的で優秀なサービスが少ないのはなぜか?


個人的には以下の理由があると思っています。

1.サービス内容、ビジネス的に優れたアイディアを持つ人が、テクノロジを持たない
2.テクノロジ的に優れたものを生み出せる人が、サービス提供の機会に恵まれない

1は経営者や企画者、2はエンジニアですが、
要はこの2者のマッチングがうまくいっていないのではないかと思うのです。
実はこのマッチングが出来ればいいだけ?
実際にこのような例(テクノロジが必要だがそれを持った人を雇えない状況)をいくつか見ているし、
周りからもよく聞く話なので間違いではないと思います。
(もちろんこれ以外の理由も多くあるのでしょうけど)


優秀なエンジニアはもっとサービス提供者側に回るべきだと思います。
SIerの市場なんて、事業会社のIT投資(のしかも一部)の合算でしかないんですから、もっと大きな市場に出るべきです。
自分の可能性を、たかが開発生産性向上のためだけに使うだけで満足してはもったいないです。
サービスを作ることでもっと高い価値を提供できる可能性があることを認識しつつ、それを実践して欲しいです。
もしSIerやパッケージ開発を行うとしても、少なくとも、サービス提供者側の視点が重要になってくることに変わりはないと思うので、一度くらいは経験してもいいのかなと思います。


また、技術に着想したサービスももっと多くなってもいいのではないかと思います。
何かを作れるというのは、何も知らない人からすればそれこそ魔法使いなわけです。
エンジニア視点からの技術をサービスまで昇華できる人が増えたら、実に面白いですよね。
(実際、1つのアイディアだけで起業している人なんてゴマンといます)

そうすれば、日本のITはもっと面白くなるんじゃないかと思っています。
あとは、あちら側に踏み出す勇気みたいなものが必要なのかな。
これについては別で書きたいと思います。


P.S.
私もサービス提供者側で、仲間を探していますが、なかなか巡り会えないですね。
ちなみにスキルよりは志、考え方、楽しめるかを重視しています。この辺も書かなきゃ。
とりあえずサービス提供者側になりたい人、来てくれないですかね?
スポンサーサイト
コメント (0) | トラックバック (0)
コミュニティ検索 »
Ruby | 2007/05/09(水) 03:01
InfoQのこの記事、まさにBig win for JRubyって感じ。
どうもThoughtWorksがmingleなるアジャイルプロジェクト管理ツールをリリースした模様。
環境がJRuby on Rails。APサーバはjetty、DBはなんとDerbyという構成。
1.1ではtomcatとかにもデプロイできるようにwarファイル形式でもリリースするのだそうな。
構成だけでも十分おもしろいなあ。
#よくよく考えたらRails on JRubyだな。

mingle自体は有料になるっぽいので使うかどうかは微妙だけど、JRuby対応プロダクトが出て来たことで、今後JRubyに抵抗が少なくなりそう。
AR&Migrationの手軽さと、DerbyとかH2の手軽さってすごく相性がいいと思うんですけど。

あと性能は問題ないそうです。
with a simple clusterって書いてあるけど、何の事だろう?
jettyにはクラスタ無いしなあ。JVMをクラスタしてたらそれこそ話題にするだろうし。
1JVM内で10個のJRubyインタプリタを動かしたこともあるそうで。へー。
コメント (0) | トラックバック (0)
コミュニティ検索 »
prototype.js使えば楽勝、とか思っていたら意外とハマったのでメモ。

iTunesみたいなselectが3つ並んで左から選択するUIを作りたいと。
で、FirefoxやSafariだと

<option value="0">ロック</option>
<option value="1">ダンス</option>
・・・
みたいにoptionタグだけか、

<select id="hoge">
  <option value="0">ロック</option>
  <option value="1">ダンス</option>
</select>
みたいにselectタグをサーバで返して、
selectタグ自体を直接Ajax.Updaterで書き換え可能でした。
$('hoge').innerHTML = request.responseText;
でイケたと。


でもIEだとダメで、同じことにハマってる人も何人かいたみたい。
http://snowland.net/nucleus/item/742


MSのサイトには3つ回避策が書いてあったけど、
結局divでselectを囲んでdivごと書き換えてみました。
サーバでは上記のようなselectを返しておいて、

var isMSIE = /*@cc_on!@*/false;

if (isMSIE) {
    $('hoge').outerHTML = '<div id="hoge">' + request.responseText + '</div>';
} else {
    $('hoge').innerHTML = request.responseText;
}

として、IEだったらouterHTMLにdivを付け足して書き込み。
1行目はこれだけでIEかどうか判定するためのコード。

最初は囲んだdivを書き換えるだけでイケる、
と思ってたらダメだったので、IE判定&outerHTMLへの書き込みをしてます。
やり方がまずかっただけかも。もしくは寝ぼけてたか。
ま、とりあえず動いたのでこれで。
コメント (0) | トラックバック (0)
コミュニティ検索 »
SI | 2007/05/07(月) 06:23
いやー、相変わらずおっしゃる通りです、という感じのkuranukiさんの2つのエントリです。
同じことを思っていても、こんなに構造化して表現できるなんて素晴らしい。

ディフェンシブな開発 ~ SIビジネスの致命的欠陥
アジャイルのレイヤ ~ アジャイルを整理し直して理解する

でも勝手に一つだけ問題点というか認識すべき点を追加。

レベニューシェアは確かにあるべき姿に近づいていると思います。
少なくとも、発注者(Servicer)と受注者(SIer)のベクトルが合うスキームになっている。
実際は、ある程度の初期費用が発生することになると思うので、一部これまでの形を残した状態にはなると思いますが、良い方向ですよね。ぜひ進めてもらいたい。
でもこれだけでは解決しない大問題が一つ。
SIerの出す金額、もしくはその元になる単価、そして給料です。


高すぎる金額

金額が高すぎる。これは最近Servicer側に転職したのでわかりました。
大規模なプロジェクトや会社ならばともかく、スタートアップや中小企業にとってはSIerの今出せている価値ぐらいでは、全然コスト/パフォーマンスが合いません。
これはSIerのときにも薄々感じていましたが、これほどまでに感覚が違うか、というくらい痛感してます。
「この人がこの単価?」という感覚は、PMをやったことのある人ならば一度は経験していると思います。
その感覚は、発注者側からすると、その10倍くらいのインパクトです。

じゃあなぜ今その金額で受注/発注されているかというと、単純に需要と供給のバランスが取れているから、および価格が横並びだからという理由だけだと思っています。
そこには何の競争も生まれないし、強みも培われない状況を生み出しているとしか思えません。

レベニューシェアでも解決できないことは、まず初期費用が高いことに現れると思います。
仮に初期費用0円でいいとなったとしても、それでは請け負った側の会社は潰れてしまうでしょう。
サービスインしてから全く収益が上がらなかったら?そのサービスを止めてしまったら?
シェア率の決定は、なんの根拠もなく行わざるを得ないと思うので(もちろん事業計画から割り出すはずですがそもそもそれが合ってない可能性大)、リスクヘッジが難しいモデルでもあると思っています。
そんなモデルで給料を安定的に払うのは、しばらくは難しいでしょう。
一山当ててからならやりやすいですが、そんな会社はそれほど多くないでしょうし。


実はみんなの給料がSI業界閉塞の一員?

SIer含むIT関連業界の平均年収は、業界別で見ると上の方です。
その代わり突出して稼げるわけではなく、業界内の年齢と年収構造は台形になっています。
まあ、平たく言うとみんながそこそこ稼ぐということです。
しかし、その中途半端な稼ぎの多さが業界全体を閉塞の方向に向けているのもまた事実です。
給料を払うために会社は売り上げないといけないので、その給料を払えるだけの売上が上がる金額を見積もり/請求せざるを得ません。結果、なぜか高い見積もりになります。
PMをやったことがある人ならば、なぜこのシステムでこの金額になるんだろう?と疑問に思ったことがあるのではないでしょうか。きっと、その感覚が正解なのです。
僕も薄々気づいていつつも、そういうもんだと割り切っていました。

一度上げてしまった給料と給与体系は、会社としてはなかなか下げられません。
でも、その状態が続きつつ、会社や社員として外向けに提供できている価値が下がって来ていたとしたら?
しかも内側に居るとそれにすら気づかない。
そんな状況が既に起こり始めているのが、今のSI業界な気がしています。


業界の発展は、自身の価値の見直しから

アジャイルにおいてもビジネスのレイヤーが語られていないとは、kuranukiさんの言う通りだと思います。
アジャイルに限らず、僕も常々そう思っていました。
でもSIerの個々の単価、ひいては給与についてもまた、語られていないのではないでしょうか。
ここまでくると、生活とか価値観とか、そういうレベルまで考えないとダメかな?と思えて来てしまいます。
のでなかなか言及しづらいし、どこから変えればよいかなんて、人それぞれ幸せの形が違えば変えなきゃいけないことも違うので、ますます難しい。
QoEL(Quality of Engineering Life)という言葉の中には、エンジニア自身しか見えておらず、実際にどのような価値を外向けに提供できているかという視点が足りていない気がします。まずはそこから考える必要があるのではないでしょうか。

これからの日本のSIerはいろいろな外圧がかかると予想されるので、20年後には上記の台形の年収構造が崩れている気がします。
要は、みんなが個々には稼げない業界になっているということです。
もしかしたらもっと早く崩れてもおかしくないとも思っています。
そのときが来る前に、いや、来ないように、今からでも個々の価値を見直して、スキルなりキャリアなりを再考するべきだと思います。
それぞれ違ったっていい。違うもんだし。でもメタなレベルで、それを考えているんだよという部分が共有できるだけでも、十分未来が違ってくるんじゃないかと思います。

kuranukiさんと違い、僕はさっさとそんなSI業界からは去ってしまう道を選びましたが、
発注者側から日本のSI、ひいてはIT全体が弱くならないように考慮しなければいけないとは思っています。
逆に発注者側の意識も変えて行かなければいけないと思っているからこそ、SI業界からは去る道を選んだつもりです。
正直、自分が適当に稼ぐだけならSIerは楽です。ちょっとマネジメントできたりITコンサルっぽいことが出来れば人月100とか200万とか貰えるって楽ですよ。別の事業で100万稼ぐのがどれほど大変か。
でもそんなある意味バブルな業界のままではダメなんだと思います。


でも未来は暗くない!

昔からですがイノベーションを起こしやすいのは、圧倒的にITが有利です。
少なくとも今やIT抜きでは考えられません。
ITもSIもこれからずっと必要なんです。問題はたった今のちょっとしたギャップにあるだけなんです。
そのギャップとは価値/対価、コスト/パフォーマンスです。
どうすれば解消するかは簡単です。価値=パフォーマンスを上げるか、対価=コストを下げるか。
どちらを取るかはそれぞれでしょう。でも最後はバランスが重要です。

ちなみに僕はQoELという言葉が大嫌いです。だってエンジニアの生活しか考えてないみたいに聞こえるじゃないですか。実際、劣悪な環境のエンジニアを想定した言葉なんでしょうけど。
でもエンジニアだけでなく、自身の周り、ひいては全ての人が幸せになれる価値を提供できる人間に僕はなりたいです。そしてそんな風に思う人間が一人でも多くなっていったら、生きやすい世の中になるんじゃないかと思う訳です。幸せの形は、人それぞれ違うものです。でもそれを常に追っている、追っている人同士がわかりあえる世の中であれば、それぞれの幸せも掴みやすくなるのではないでしょうか。

なんか宗教じみてますが、こんなことを普段から思ってます。
こういうことを書くと、思想を伝えられる&共感させるアーティストは凄いよなあ、とつくづく思います。
コメント (0) | トラックバック (0)
コミュニティ検索 »
Web2.0 | 2007/05/07(月) 04:36
Microsoftもいろいろ頑張ってますねえ。
DLR(Dynamic Language Runtime)でJavaScript、PythonとなんとRubyサポートだそうです。
その名もIronRuby。なんでまたもやIron?
で、その上で実装されてるSilverlightのランタイムにMac版があるのがびっくり。Flashには負けないぞと。
Pythonに続きRuby + Railsの力も借りちゃえ、とかそんな感じ?
どうせなら開発もMacでさせてくれ。


Ruby + Railsは、これでJava=SunとMicrosoftでの取り合いっぽく見えてきましたねw
いろいろオープンになるのは歓迎ですけどね。

コメント (0) | トラックバック (0)
コミュニティ検索 »
Ruby | 2007/05/07(月) 03:33
何やら最近DreamHostが流行ってるっぽかったので、乗っかってみた。
安いし。promo codeとやらを契約時に入力すると、初年度$25くらい。安すぎ。
この時点で即決でしたね。

で、いろいろ参考にしてとりあえずJSONを返すWeb APIを公開できたよ。
promo codeはここでゲット。
良い鯖.com


最初からRailsに対応してるから、Gem以外につまづくことはなかった。
そのGemもGEM_PATHに自分のパス追加すればいいだけだったぽいし。
SubversionとMySQLも最初から使えるし、ディスク容量とか転送量とか多すぎで気にする必要ない。
便利ですなあ。
デフォルト環境は、こんな感じ。
Ruby 1.8.5
RubyGems 0.9.2
Rails 1.2.2
でも今回はRailsはGemで入れ直したのを使ってるので1.2.3になってます。


参考はDreamHostのWikiがあるから、ほとんどこれで解決できる。
独自でRuby + Rails入れる参考サイト(英語)があってそれでもできたけど、
うっかりブックマークし忘れて出てきません。残念。

DreamHostのWiki(Rails)

でもFCGIプロセスをほっとくとkillされるのでその対策とか要るっぽい。めんどいのでまだやってない。


あとついでに調べた、他のRailsホスティングの会社をメモ。
続きを読む »
コメント (0) | トラックバック (0)
コミュニティ検索 »
プロフィール
 

miyazima

Author:miyazima
常に変化を好み、面白いことを探しています。次の次は?

カレンダー
 
04 | 2007/05 | 06
- - 1 2 3 4 5
6 7 8 9 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28 29 30 31 - -
カウンター
 
天気予報
 

-天気予報コム- -FC2-
ブログ内検索
 
上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。