Interlude

公開日時：: 2003/11/11 23:18
著者：: kenn

トラックバック(2)

コメント(5)

ブックマーク(-)

ちょっと休憩

前回までの5話にわたるミニ連載というチャレンジを終えてみて、「うーんまだまだ整理が足りないな」と自覚をする羽目になった。知人たちからも「読み物としてはコミカルで刺激があるけど、後味はイマイチ」とか「後半にかけてだんだん自己陶酔モード入ってたよ」などとおしなべて辛口の感想をいただいてしまった。

勢いでどんどん長くなっていく文章に流されて論旨が腰折れ気味だったかなと感じてはいたし、最終回も今読み返してみると、もっとフェアな書き方があったかなぁと思えてくる（あまつさえ、書きたかったことが書けなかった）。うーん、反省。

自分のBlogスタイルを確立するにはまだまだ時間が必要なようだ。もう少しあれこれ試してみようと思う。

エンジニア雇用の主体はITユーザへ

ところで、連載の途中で気が付いたのだが、梅田さんの最近のエントリの「雇用なき景気回復とITエンジニアの雇用をめぐる大転換（このエントリは大変貴重な論考だと思う）」や「アマゾンの実験に需要サイドからのイノベーションを考える」あたりでも頻繁に取り上げられているホットなテーマだが、

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

という考え方とは、私は面白いほどピッタリと意見の一致をみている。

梅田さんのストーリーは、AmazonやeBayやGoogleといったインターネット世代のプレイヤーたちのワークスタイルをみてそのような仮説を立てたとのことだが、私は既存産業と従来型のイノベーションの延長線上でさえ、実現までのタイムラグこそあろうが全く同様にITベンダーからITユーザへのエンジニアの雇用シフトが起きるだろうという仮説を得ている。受託ビジネスの崩壊がそのきっかけとなるだろう。（何のことだかわからない人は、もう一度前回までの連載をざっとおさらいしてみてください）

そこでもう一歩考えを進めると、ITユーザに属するエンジニアには少なくとも2つの類型があるような気がしてくる。

Yahoo!やGoogleのようなミッションクリティカルなシステムが中心にあるビジネスは、優秀なITエンジニアたちにとって楽しい職場となるだろう。そこには枯れた技術であっても限界ギリギリにチャレンジするといった種類のスリルがある。モータースポーツマニアが市販車にカスタムパーツをつけまくり、ゴリゴリにチューンアップして「どうだ、俺のマシンは速いだろう」と競い合うような感覚だろう。ここで最も求められるスペックは、一点突破型のテクノロジースキルだ。

一方の既存産業でITエンジニアの果たす役割はといえば、社内で発生するビジネスのニーズに対して自らユーザとして事業企画からインプリまでを一貫して遂行することが求められるようになるだろう。テンポよく結果さえ出せればよいので、パーツにはこだわらない。むしろなるべく純正品や標準品を使うことで、アウトプットの品質が安定することが優先課題となる。ノーマルなオートマのセダンに乗るべしというような感覚だろう。ここで最も求められるスペックは、柔軟性重視のヒューマンスキルだ。

こんな感じで、ITベンダーからITユーザへのエンジニアの雇用シフトにも、性格的な向き・不向きも含めてキャリアパスが見えてくるのではなかろうかと、おぼろげながらに考えている。

♪ Kenny Loggins / Leap Of Faith

※このエントリは CNET Japan ブロガーにより投稿されたものです。シーネットネットワークスジャパンおよび CNET Japan 編集部の見解・意向を示すものではありません。

ログインしてコメントするこのエントリを評価する

運営事務局に問題を報告この記事についてブログを書く（ブロガー専用）

このエントリーへのコメント

Vilyamfj on 2007/10/28

Vilyamxq on 2007/10/28

>ITユーザに属するエンジニアには少なくとも2つの類型があるような気がしてくる。

>Yahoo!やGoogleのようなミッションクリティカルなシステムが中心にあるビジネスは、優秀なITエンジニアたちにとって楽しい職場となるだろう。ここで最も求められるスペックは、一点突破型のテクノロジースキルだ。

>一方の既存産業でITエンジニアの果たす役割はといえば、社内で発生するビジネスのニーズに対して自らユーザとして事業企画からインプリまでを一貫して遂行することが求められるようになるだろう。ここで最も求められるスペックは、柔軟性重視のヒューマンスキルだ。

江島さん。仰るとおりだと思います。
ただし、後者の類型の人材には、もうひとつ、「翻訳」機能が求められます。そしてこれが結構クリティカルです。仕事が達成されるか、という観点と、彼がその企業できちんと評価されるか、という両方の観点で。

梅田さんが以前のコラムで、「５０歳代の人間にどうITを説明するか」といった内容のことを取り上げておられました。

後者の人材は、「解体新書」の世界を行く覚悟が必要です。その点で、日本の経営者層の知的誠実さ（※）、ということを考えると、後者は裾野が広そうだが、なかなか人口として増えないのではないかと、やや悲観的な観測を持たざるをえません。

※自分の知らないことをしゃべられると、その内怒り出す。自分がわからないのは、説明者が悪い（そういう部分もあるでしょうが）と１００％思い込む。自ら、知ろうとはしない。自分の思い込みで理解しておいて、後から、「お前には騙された」と言い出す。

sansara on 2003/11/18

筆者の起こそうとしてる「破壊」は、IT業界における「価格破壊」の一つなのかなあ、と解釈した。
昨今のオープンシステム技術の汎化作用にうまく乗った製品をプロデュースし、大量生産的イニシアティブを基幹業務システム市場において獲得することに、市民権開放的な熱いイノベーションを感じてることも最終回で理解できた。ただ、「オープンな技術の汎化イノベーションによる顧客の囲い込み」にも「ジレンマ」は存在しうる(例えばHTMLベタ書きに比べ、安価で使い勝手のよいHTMLビルダは確かに初心者ユーザの裾野を広げHTML技術の汎化としては成功を収めたけど、それ単体で世界制覇しえるビジネス展開をした企業はなかったこと、など。)
他方、IT以外の業界(小売や車など)における価格破壊現象を観察してアナロジを適用すれば、仮に筆者の指摘する価格破壊現象が発生し、体力に劣る企業が脱落した後でも、高付加価値化に成功し高利益率を維持可能な受託型ITベンダは存在しうると思われる。そして、基幹業務システムにおけるオーダーメード的需要が絶えることがないこと、ERPなどのシステム自体が「ビジネスロジックのベストプラクティス」を蓄積する側面を持つこと、などの事実を踏まえると、古い技術にしがみつくこととは別に十分に成立しうる戦略を立てられると推察できる。
最後に、ITとビジネスとの融合のイノベーションはまだ「始まった」段階で、IT技術を前提とした(GoogleやAmazonのような)ビジネスモデルの成功に刺激され、そうした最新モデルの実現を求めて、「現場」に技術者が赴くのは自然な流れだと思う。そうした更に先の融合のイノベーション(OSIアプリ層の更に上に位置するようなイメージ)を求める行為であり、彼らは決して「枯れた技術であっても限界ギリギリにチャレンジするといった種類のスリル」を求めているのではないと思う。あわよくば、そのビジネスモデルを他業種展開したり、パッケージ化したりと、筆者に負けず劣らず野心的に考えてる人たちのように映る。
手短ですが、また面白い思考を提供してもらえることを期待しています。

norm on 2003/11/13

大変楽しく読ませてもらいました。私は現在ソフトウェア開発に従事していますが、今後の「レス・プログラミング」へのパラダイムシフトへの対応は開発会社が頭を悩ませている(楽しんでいる？)問題です。特に中小規模の会社は「派遣屋さん」と化しているところも多く、なかなか次のステップが踏み出せないでいるのが現状でしょうか。
個人的には、オープンソースが今の「開発会社」という概念を崩す可能性もあるかなと注目しています。現在は基盤部分を担うものが多くみられますが、医療レセプトソフトのORCAみたくより業務的なものが増え、産業団体がそれを標準に据えたとき面白い動きが起きるかも、ですね。

tomo on 2003/11/12