「あなたのためのソフトウェア。」の時代。狭く、簡単で、少ない目的に最適化したたくさんのソフトウェアを短いサイクルで作る。そのために、極少数の優秀なプログラマが企業の内部から、自分たちの企業へインパクトを与えるためのコードを書き、課題を解決する。オンサイト顧客ではなく、いつでもプラグマティックプログラマがあなたの隣にいるということが生む価値。
これまで、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? のスライドひとつをつくらせることがよくある。そのスライドはミーティングで一度使うだけだ。ソフトウェアを多くのユーザに使えるようにする、あるいは多くのユーザのために残すというのは慣習にすぎず、ソフトウェアそれ自身の要件ではない。
実際問題、多くのユーザに長く使ってもらおうと作られた大抵のソフトウェアはその両方の目標を永久に達成しない。馴染系ソフトウェアはこう主張することができる: 「大抵のソフトウェアは短い期間、少しのユーザに使われるだけだ。なぜその利点を設計に生かさないのか？」
こうした事態は、奇妙なことだが、進歩といえる。馴染系ソフトウェアが他のアプリケーションを駆逐するからではない。そうはならないだろうからだ。現在のソフトウェアがつくる生態系のもつ価値はどれも、一握りのユーザが数ヶ月使うアプリケーションがもたらすものではない。私達は新しいソフトウェアのニッチをみつけたのだと思う。コミュニティは個々の特別な要求にぴったりのツールを手に入れる。そのツールはこれまでの設計品質や成功のための試験には落ちるだろうが、にもかかわらずよく機能する。そのソフトウェアは、それを使うコミュニティによく馴染んでいるから。
馴染系ソフトウェア
