しごと観シリーズ なにを考えるか

by tanabe on January 28, 2008

技術者として、ビジネスを通して技術者としての自分の価値を社会に還元したいと考える人は、皆この記事を読むべきである。

喜んでもらいたい。認めてもらいたい。そんな気持ちから更なる開発に拍車がかかる。何度かそんなやりとりが続き、もうだめかとあきらめそうになったとき生まれるブレークスルー。「ありがとう」「助かったよ」「すごいね」この言葉の魅力にとりつかれて、再び挑戦への道へ分け入る。

技術者を輝かせるもの

今月のオープンソースマガジンにみねろうさんのコラム(ハッカー養成所のやつ)が載ってるんだけど、すごいいいこと書いてた。

みねろうさん曰く「ハッカーになるには、自分はハッカーであり得るのだと覚悟すること」だと。ハッカーに限らず、何かになりたいと思ったら覚悟をすることだそう。覚悟を決めるというのは、何か難しい仕事がふってきたときに、「今の自分には無理だから」という理由で逃げるではなく、将来自分がイメージするハッカーになったつもりで、それをやってみるということらしい。

覚悟

何にせよ腹を括れば怖いものはない。「腹を括る」というのは「失うかもしれないもの」を確定させる、ということ。言うなれば「引き当て」。あとは、そこから「何をどれだけ得るか」。リスクとリターンの話。

これからは「デザイン」の時代。プロダクトを、サービスを、ビジネスをデザインする。デザインには物語が付いてくる。どれだけ顧客の「共感」を得られるか。不確定な時代には、定量的な評価よりも定性的な評価が重要なこともある。

最近思うこと

半年後にこうなっていたい、という風にまずはゴールを設定する。そこから割り戻してきて、じゃあそのためには、まずどうなっていないと駄目かを考えて、そこに至る方法を考える。こうやってどんどんと現在まで割り戻してきたときに、今の自分と今自分が出来ているべきことのギャップが見えてきます。そこで、そのギャップを埋めるために必要なことを考えて取り組んでいくのです。

きちんと未来につなげるためには、未来と向き合う覚悟が必要です。見たいものだけ見てても何も変わらないです。出来ない理由を並べるのではなく、出来るようになるためにまず具体的に何をやるべきか、を考えるところから始めるのです。未来が今からの逃避の延長では、きっとしょぼくなる一方です。こうなりたい、こうありたい、というゴールを決める。「自分で決める」という行為はモティベーションを超えます。リスクに向かい合う覚悟を作ります。まずは当座のゴールを決める。そこからはじまるのです。

ゴールから割り戻して考える

語るべきエピソードなしで成功という結果だけ掴んでしまうと、そこには「対等な関係を結ぶに足る人間が誰もない」「出会う人間がアホしかない」という荒涼とした世界が広がっているのだ。

「一日も早く成功しようとして努力することは...」

セイフティネットがない中で、家族とキャリアとパーソナル・ファイナンスのバランスをどう取るのか

「やりたくないこと」「やるべきではないこと」は、目先の損得にまどわされずに徹底的に断わり続けるという根性がないと、タイムマネジメントは絶対にできない。でもそれができると一日はものすごく長くなる。たくさんのことができる。そこにしかサバイバルの活路はないのである。

ロジャー・マクナミーの講演「The New Normal - Career, Family & Personal Finance」を読む
  

しごと観シリーズ 見晴らしのよい場所に立つ

by tanabe on January 25, 2008

世界で何が起ころうとしているのかが見える場所に行け。シリコンバレーなら、まずはGoogle。GoogleがダメだったらApple。いやYahoo かな。Oracleだっていい。シアトルならMicrosoftだな。こういうところは皆、「a great vantage point」((見晴らしのきく地点、よい観戦場所)なんだ。そういう会社で職を得れば、世界でこれから何が起ころうとしているかが皆見える。the next big thingが来たとき、そこに陣取っていれば、見ることができる。

若者はバンテージポイント(有利な場所)でキャリアを磨け

こんな話があります。ある企業のウェブアプリケーションエンジニアと数人で会話しているときのこと。「昨日○○というサービスをオープンしたよ。」「おお、あの規模のサービスだし結構時間かかったでしょう? 半年ぐらい?」「いや、フレームワークあるし三日くらいかな。」

彼らは私と同年代のソフトウェアエンジニアでした。環境こそ違えど、手がける仕事のドメインにそこまでの違いはないはず。しかし、ふとした会話の中にあったスピード感の違い、そして自分が日ごろ行っているプロセスとの違いに圧倒されたのは言うまでもありません。それが良いとか悪いとかいうことではなく、違う世界はすぐそこにあるのだなと実感させられた瞬間でした。

人との出会い、不連続な成長が作るキャリアパス

SE時代の上司と同僚と飲み。彼らの仕事環境、ビジネス、技術状況が2年前とほとんど変わっていないことに正直驚いた。やはりスピード感が違うのか、いまひとつ会話が成り立った気がしなかった。

企業ユースの世界ではいまだにウォーターフォール型で、人月商売の開発が行われいます。まあ、それでユーザー側もベンダー側もそれでビジネスが成り立っている以上、それはそれでいいのかもしれませんが、なんか引っかかります。

どーすんのよ、俺。
  

しごと観シリーズ ユーザ企業の時代

by tanabe on January 24, 2008

「あなたのためのソフトウェア。」の時代。狭く、簡単で、少ない目的に最適化したたくさんのソフトウェアを短いサイクルで作る。そのために、極少数の優秀なプログラマが企業の内部から、自分たちの企業へインパクトを与えるためのコードを書き、課題を解決する。オンサイト顧客ではなく、いつでもプラグマティックプログラマがあなたの隣にいるということが生む価値。

これまで、ITエンジニアにとっての花形の職場、就職先はITベンダーであったわけだが、ひょっとするとこれからそれがITユーザの方に移行していくのではないか。それがITエンジニアの雇用をめぐる大転換なのではないかというのが、いま僕が考え始めている仮説である。

その21世紀型ITユーザでの仕事、つまり「自社の事業にITを活用してその結果自社事業を繁栄させることに対する対価を得る」ユーザでの仕事に、「IT を道具やインフラや技術そのものとして他社に提供して対価を得る」ベンダーでの仕事よりも、少なくともシリコンバレーでは、ITエンジニアが魅せられ始めているという現実があるわけだ。

「あーでもない、こーでもないとみんなで頭をひねり、「こういう機能があったら絶対面白い!」というようなアイデアを出し合ったり、時にはトラブルの対応に夜中に叩き起こされたりしながらも、日々進化してゆくサービスを支えるのがソフトウェア・エンジニアというわけです。コンピューターを動かすプログラムを作るという作業は、エンジニアの仕事の一部ですが、他にもサービス全体がどう構成されるかの設計をしたり、様々な問題の解決策を考えたりすることができなければ、この仕事は務まりません。そんなことから、プログラマーという呼び方はあまり使われないのでしょう。インターネットビジネスのアイデアを形にするには効率よく、しかも安定して動く大規模なサービスを作らなければなりません。しかし、こういった大規模なサービス作りは、ノウハウが少ないので、エンジニアの職人的な経験と勘がものをいいます。」

「ところが、僕の仕事はそのどれにも当てはまらないというか。プログラマというほどプログラムをガリガリ書きまくるわけでもないし、SE のようにクライアント相手に分析/設計を行って仕様に落とし込むプロというわけでもなく。時としてサーバの運用なんかもやるし、アプリケーションを作ることもあり、その一方で新しいサービスのアイデアを企画したり色んなサービスのブレストに参加したりもします。良く言えばオールマイティ、悪く言えば中途半端というやつなのです。色々やれて楽しいと言えば楽しいのですが、じゃー僕の職種は一体何なんだって思ったときに、一言では言い表せないし、万が一転職なんて話になったときに、こんなキャリアで相手にしてもらえるんだろうかとか。」

「でもここでのコラムを読んだら、どうもシリコンバレーではそんな職種が花形でもあったりするようなことが書いてあって、少しだけ自信を持つことができました。「インターネット関連の企業でエンジニアやってます」と言えばいいのですね。」

NDO:: Weblog氏が言う「SI、SE やプログラマ、ITコンサルなどに対する、ある程度型にはまったイメージ」というものこそ、ITベンダーにおけるITエンジニアの職のイメージなのである。上田さんやNDO::Weblog氏の仕事のイメージこそが、生まれたばかりの、21世紀型ITユーザにおけるITエンジニアの職のイメージとは言えないであろうか。

雇用なき景気回復とITエンジニアの雇用をめぐる大転換

ただし、要件は大抵使う場所に近いところから出るのでそこは日本でやる必要がある

独り言

日本の(大手)SIerの価値の源泉は、業務分析能力と運用も含めたシステム設計能力であって、個別のコンポーネントに精通していることは競争力の源泉とはならない。

SIerはテクノロジーで食っていけるか?

ユーザの問題解決代行業がSIerの本質だといえます。

SIがOSS化するとは何か?

シリコンバレーの本当の恐ろしさは、そこそこ優秀ではあるけれど、どこにでもいるようなありふれたスキルのエンジニアを使って、あるいは場合によっては、インドのアウトソースサービスを使って、世界中どこにもないようなソフトウェアや、サービスを短期間のうちに作り上げる仕組みのほうにあるのだと思います。

100万行のソフトの作り方(1)

事業部門の運営をサポートするようなIT資源とサービスを提供するのが「供給」のマネジメントであり、その対極にある、事業部門によるITを通じたイノベーションを助けるのが「需要」のマネジメントであって、新しい世代のCIOは、「供給」サイドの仕事でなく、「需要」サイドの仕事に専念する傾向が見られる、ということである。

企業のリーダーシップを採ろうとするCIOには、複雑に絡み合うビジネス上・テクノロジー上の動きの中から、イノベーターであれば誰もがするように、パターンや意味を抽出し、どれが「本当に役立つもの」で、どれが「ただの流行りもの」かを見極めた上でビジョンを形成する能力が求められる、ということなのだが、「ITの使い方を考える」仕事で磨かれる能力がこのようなものであるとすれば、それはとてつもなく刺激的な仕事なのではないだろうか?

ベンダーサイドだけがITのキャリアではない

「とにかく、何か新しいビジネスをオンラインで立ち上げるためには、ユーザーのフィードバックを集めながら、Plan -> Do -> Check -> Actionを繰り返していけるような体制を社内に集めないとだめだろうということです。いちいち要件定義して、仕様書書いて、SIerに発注なんてしていたら、時間もお金もかかりすぎて、事業として成り立ちません。オンラインのオペレーションは変化の連続ですが、アウトソーシングしてコストメリットが出るのは枯れたオペレーションだけなので、ここを外に出すとかえってコストは上がるし、スピードは下がるし、品質は悪化するしで、良いこと無しだろうと思うんです。」

オフショア開発で明暗別れるプログラマーのキャリア

やがてくる未来ではソフトウェアの生態系がかわると私は信じている。その生態系を、ここでは 馴染系ソフトウェア (Situated Software) と呼ぶことにしよう。特定の場面や文脈のために設計されたソフトウェアのことだ。馴染系ソフトウェアを作る方法は、いわゆるウェブ学派(かつて私がプログラミングを勉強した場所)のやりかたとは対照的だ。ウェブ学派はスケーラビリティや汎用性、完全性を美徳としてきた。

私の生徒達はウェブ学派の流儀をあっけらかんと無視し、それでいて面白いものをつくっている。

全ての関心はアウトソーシングに集まっているが、多くのダウンソーシングもまた起こりつつあるのだ。プログラミングは職業上の技能から、より広く身につけられるスキルになりつつある。もしプログラマという言葉が 「コードを書いて給料を貰っている人」 ではなく 「コードを書く人」を指すなら、2015 年にむけてその数は増えつづけるだろう。

アプリケーションを長く使いたいと考えるのは、それを作るのにコストがかかるからだ。安く簡単にソフトウェアを組めるようになれば、この原則は弱まる。ビジネスでは稼ぎのいい人々に数百時間をかけて PowerPoint? のスライドひとつをつくらせることがよくある。そのスライドはミーティングで一度使うだけだ。ソフトウェアを多くのユーザに使えるようにする、あるいは多くのユーザのために残すというのは慣習にすぎず、ソフトウェアそれ自身の要件ではない。

実際問題、多くのユーザに長く使ってもらおうと作られた大抵のソフトウェアはその両方の目標を永久に達成しない。馴染系ソフトウェアはこう主張することができる: 「大抵のソフトウェアは短い期間、少しのユーザに使われるだけだ。なぜその利点を設計に生かさないのか?」

こうした事態は、奇妙なことだが、進歩といえる。馴染系ソフトウェアが他のアプリケーションを駆逐するからではない。そうはならないだろうからだ。現在のソフトウェアがつくる生態系のもつ価値はどれも、一握りのユーザが数ヶ月使うアプリケーションがもたらすものではない。私達は新しいソフトウェアのニッチをみつけたのだと思う。コミュニティは個々の特別な要求にぴったりのツールを手に入れる。そのツールはこれまでの設計品質や成功のための試験には落ちるだろうが、にもかかわらずよく機能する。そのソフトウェアは、それを使うコミュニティによく馴染んでいるから。

馴染系ソフトウェア
  

しごと観シリーズ コモディティ化するソフトウェア

by tanabe on January 23, 2008

ソフトウェアエンジニアの価値はシステムを作れることなのか。売れるシステムにこそ価値があるのだとしたら、そこへどんな貢献ができるのか。今、成果として何を生んでいるのか。いなくなったら、本当に困る存在か。替わりのきかない役割があるとしたら、それは一体なにか。10年後にも価値を生み続けるための競争力は、今やっていることの延長線上にあるのか。

知識労働者たるものは、自らの組織よりも長く生きる。したがって、他の仕事を準備しておかなければならない。キャリアを変えられなければならない。自らをマネジメントすることができなければならない。つまるところ、これまで存在しなかった問題を考えなければならない。

キャリア・ビジョン

勉強が好きな少年も、野球好きの少年や将棋好きの少年や音楽好きの少年と同じような「人生の厳しさ」に直面するようになる。

それが「次の10年」なのではないか。

そんなことを最近よく思うのだ。

たとえば僕の場合でも、本を読んだり勉強したりモノを書いたり、そういうことは子供の頃から大好きだった。でもそれだけでは食えない。いま僕の事業を、ひいては生計を支えているのは、僕の「勉強能力」ではなく「対人能力」もっと言えば「営業能力」なのである。

「これからの10年飲み会」で話したこと、考えたこと

「手に職を付けたい」と言ったところで、文系で就職した日本の大学生が、海外の理工系大学でIT教育を受けてきた人材に技術力でかなうわけがありません。スタート地点が違うわけです。

最後に一言

アマチュアという言葉の反対語は言うまでもなくプロである。

「mass amateurisation」の大きな流れは、今現在何かの領域でプロを自認して飯を食っている人にとって、膨大な新規参入者(アマチュアと言ってもいいし、エンパワーされた人々と言ってもいい)が、ものすごく大きな脅威になる。これこそが「mass amateurisation」現象の本質であるという問題提起である。まったくその通りだと思う。

第一タイプは、既存の体制によく親和して、何かを成し遂げようとするときには「しかるべきプロセス」の中に自然に身を置いて、その中で着実に経験を積んでいくことを喜ぶ(厭わない)というタイプである。日本のエスタブリッシュメント層の大半は、こういうタイプの人たちである。

第二タイプは、何かを学ぶのも何かの経験を身につけるのも自己流。学校や大組織のような秩序立ったところにはあまり親和せず苦労するが、混沌とした社会の現実にぶつかる経験の中から、独力で頭角を現していくタイプである。

こういう第二タイプの才能がエンパワーされて世に出やすくなる現象こそが、「mass amateurisation」なのではないだろうか。

でも、ジャーナリズムやプログラムの分野に限らず、音楽の分野、映像の分野、ありとあらゆる知的作業のための環境が低コスト化、コモディティ化するにつれて、第一タイプのエスタブリッシュメントたちを、第二タイプの在野の実力者が脅かし始めるという構図がいたるところで現れてくる。それが21世紀の「仕事の現場」なのではないだろうか。

ネットがもたらすプロフェッショナルへの新しい道

「グローバルに仕事が移転する時代では、ある時首を切られて、それ以降全く仕事がなくなってしまう、ということが十分起こり得る。

なんというか、海辺の絶壁を想像してしまう。水際ぎりぎりにぽっかり横穴が開いていて、その中で安穏と暮らしていると、だんだん潮が満ちてきて、海の水がじわじわと穴の中に入ってくる。今にまた潮が引いて、元通りの安穏とした暮らしに戻れるのではないかと思って耐えているが、ついに水は腰の辺りを超え、首あたりまで来る。どこかで決意して、荒海に泳ぎ出て、さらに上のほうにある穴によじ登った人だけが生き残ることができる。」

まわりの連中よりも何百倍も何千倍も優秀なプログラマーというのは居るものだ。そういう能力を持った人は大企業にも勤めている。でも大企業だとそういう人のインパクトが薄められる。そういう才能をきちんと雇用し、大企業の中でもちゃんと活かせ、そうすれば、顧客満足もうんと上がる。同じ成果を低コストでということばかりでなく、そういうプラス効果を考えなきゃダメだ。

年収500〜1000万円の仕事がなくなっていく米国

全く別の観点から、元オラクルCOOのRay Laneのインタビューは、グローバル化がもたらすアウトソーシングではなく、IT化のゴールとしての「リアルタイム・エンタープライズ」が実現することと人員削減の関係についての未来像を提示している。

20世紀型の「人の多い」会社から、もっともっとビジネスプロセスを自動化し、無人化していくのが、21世紀型企業のイメージだと、Ray Laneは言う。

シリコンバレーという場所は、アメリカの中でも、変化が最もラディカルに表出する場所なので、ここに住んでいると、よくも悪くも、未来の仮説が増幅した形で、僕らの前に姿を現す。ここに住むほぼすべての人たちが理解しているのが、自分たちの子供の時代になったら、人をめぐる競争環境がますます激化するという事実だ。

世界規模の人材競争に日本の若者が生き残るには

米国300万プログラマーのピラミッド構造

まず、「Software programming is the iconic jobs of the Information Age, but not all programmers are created equal. Here’s the breakdown of software jobs and their prospects」と書かれているように、この図では、ソフトウェアに関する仕事のピラミッドを6階層に分類し、それぞれの階層ごとの今後について一覧したものである。ちなみに、米国全体では約300万人が、このピラミッドにどこかに位置している。

まず、頂点に位置するのが、 Architect階層(第1階層)である。「A few thousand tech visionaries sketch out entire systems to handle complex jobs.」というわけで、この階層は数千人の世界。例としては、BEA SystemsのChief ArchitectのAdam Bosworthが挙げられている。年収は15万ドルから25万ドル。アウトソーシングの影響はいっさい受けない。

さて、次が、 Researcher階層(第2階層)である。ここがイノベーションのためのカギで、米国にとっての生命線である。ここに2万5000 人くらい居るとBusiness Week誌は推定している。年収はアカデミアだと5万ドル。在野だと19万5000ドル。基本的にはこの階層の将来は明るいが、この仕事もオフショアに出て行く可能性がある。

そして、Consultant階層(第3階層)。企業のテクノロジー・ニーズについてアドバイスし、新しいソフトウェアをインストールしたり、新しいアプリケーションをスクラッチから作ったりする、ビジネスに精通したコンサルタント。年収は7万2000ドルから20 万ドル。この階層の将来は明るい。 次が、Project Manager階層(第4階層)。グローバルソフトウェア工場の重要な歯車。異なる国、異なるタイムゾーンで働くチームをコーディネートして、仕事を時間通りに完遂する仕事。これに関連しては、本連載2月12日「グローバル化が進む分散開発体制の今」も合わせてご参照。年収は9万6000ドルから13万ドル。ここでいいマネージャーになれば、仕事は安泰。

そして下から2つ目が、Business Analysts階層(第5階層)。ビジネスニーズからプログラマーのためのスペックに落とす人。年収は5万2000ドルから9万ドル。ビジネスセンスがあって、コミュニケーションスキルがあるプログラマーにとって比較的安全な場所(仕事が外に出て行かない)。

そして最後が、Basic Programmers階層(第6階層)。「The foot soldiers in the information economy」(情報経済における歩兵)で、アプリケーション用のコードを書き、アップデートして、テストする。年収は5万2000ドルから8万 1000ドル。仕事が海外に出て行ってしまうという意味では、ここが一番危ない。この階層における仕事の18%が、6年以内に、オフショアに流れていくというのがフォレスターの予想。

オフショア開発で明暗別れるプログラマーのキャリア

Gartnerによると、IT関連職は以下4つの傾向による影響を受けるという。

  • 技術インフラ/サービス関連業務は、エンドユーザーの組織では減少し、逆にサービス/ハードウェア/ソフトウェアベンダーでは増加するだろう。しかし、その業務の多くが開発途上国から提供されることになる。
  • ビジネスインテリジェンス、消費者向けのオンラインサービス、コラボレーション技術に従事する人の数は、ユーザー企業、システムインテグレーター、コンサルティング企業の間では増加するだろう。
  • 競争力のあるビジネスプロセスやプロセスオートメーション、業務プロセスの設計ができる人が求められるようになる。プロセスの設計/管理分野は、有望な分野になるだろう。
  • 「無形の財産」を管理する能力や、地理的に分散し、作業能力も文化も異なる複数の関係者を管理する能力が要求されるようになるにつれ、関係管理や外注管理に関するスキルが重視されるようになるだろう。
「技術オタクの時代」が幕を閉じる?--米調査
  

Mongrel 生まれの高速(らしい) Web サーバ Thin に関するメモ。

by tanabe on January 06, 2008

Ruby Inside で紹介されていた Thin に関するメモ。(なんだけど、試していないので実態は不明。)

Thin actually relies on Mongrel, but is ultimately faster than it, even against Mongrel's EventMachine-enhanced guise.

とのこと。公式サイトの about を読むと、Mongrel のパーサを使っているので、Mongrel の速さとセキュリティを受け継ぎ、EventMachine を使っているから、安定していてスケーラブル。そして、Rack 対応なので既存アプリも簡単に移行できるということらしい。

上記のブログのコメントからいくつか抜粋。

Does Thin run multiple Rails processes? Or do you still need to put it behind a load balancing proxy like you do with Mongrel? (like this config: http://blog.codahale.com/2006/06/19/time-for-a-grown-up-server-rails-mongrel-apache-capistrano-and-you/)

に答えて、

Thin is exacly like Mongrel on that side, you’ll need multiple Rails processes for a web site with some traffic.

You should probably also check out Rev (http://rev.rubyforge.org) which is a light simple binding around libev (not libevent) and works only in Ruby 1.9. Tony is building a very nice API for it that you can use, and libev is very fast and small.

これは Zed Shaw のコメント。libev はこれか。

How long, you think, before it can be used on a production server?

への回答。

A better reply would be: you tell me! If you feel like it, deploy an app using it and let me know if it works for you.

そら、そうだw

(Ruby はあんまりスケールしない(しなかった)って議論があるんだけど、その点はどうなの?って質問に答えて。)

Ruby had some problems in the past with threads, Mongrel helped fixing those bugs in Ruby’s core but still, Ruby threads are not native (don’t use OS processes, so can’t take advantage of multicore processors). And threading is not the most scalable way of handle huge loads. Event-driven I/O can handle more requests and uses only one thread.

"Event-driven I/O can handle more requests and uses only one thread." について関連情報を検索してみた。

Cool, now where’s the info on how to replace my mongrel clusters with thin clusters?

here’s a rake task to start and stop a cluster:
http://groups.google.com/group/thin-ruby/browse_thread/thread/a639d1e20a1b0d75

豆知識として、現状、Thin で検索かけてもさっぱり目的の情報は見つからないので、"gem install thin"あたりで検索するのがオススメ。

  

あけましておめでとうございます。(遅)

by tanabe on January 05, 2008

今年もぼちぼちやっていこうと思います。

空気を読むと、ここで Merb の紹介とまとめ記事書いて「Rails はもう古い!2008 年の Web フレームワークはこれだ!」みたいなんを書くのかもしれませんが、そういう人は「やさしい Merb の育て方」を読んでおくといいと思います。

今年は基礎に帰ろうということで、パタヘネ本とか計算理論の基礎とか数学ガール(あ、これ関係ないか)を買い込んでいるぼくにはあまり関係ない一年になりそうです。

Mongrel の人のあれは arton さん訳を読んだだけなので、これから原文あたります。なので、評価保留。