雑種路線でいこう

2007年05月13日

情報サービス産業に明日がなくても構わない

情報サービス産業に対しては,人月単価ベースビジネスモデルがいけない,エンジニア使い捨てている,高い単価でオフショアとどう戦うのか,とかいろいろなことがいわれているし,どっかに活路がないものかなとここ数年いろいろ調べたりもしたのだけれども,最近ふと別に情報サービス産業に明日がなくても構わないじゃないか,と考えるようになった.

結局のところ要件定義や仕様書に基づいてシステムをつくるという仕事は,ITが生む付加価値そのものを受け取るようにビジネスモデルができていないのだ.技術や製品・専門知識に希少性があった時代はそれでも儲かったが,ハードソフト,それらに対する知識がコモディティ化した瞬間,サービスやソリューションそのものがコモディティ化することは避けられなかったのだろう.

僕はIT自体にはまだまだ可能性があると思うけれども,徐々にレントがIT製品を扱う企業から,ITを活用して新しい価値を生む側に移転するのは自然で避けがたい動きである気がする.そして彼らにとってソフトとは自分たちが使うためにつくるもので,仕様書通りかではなく,これまで以上に業務と一体で見直されるものになるのではないか.

いや仕様書がないからよいソフトウェアとは限らないんだけど.Rubyにも,Linuxにも,Windowsにも,きっと厳密な意味での仕様書ってないんだよね.何故それが許されるかというと,パッケージ製品であれば開発時にはVision StatementとかPersonaとかは定義して,つくりながら試行錯誤して,時々世に問い,何かいわれたら「それが仕様です」と返すし,オープンソースであれば「ソースを読めば」「自分で直せよ」と.

すごく乱暴に論じると開発生産性が高まれば高まるほど,厳密に仕様書を書くことは難しくなるはずだ.何故なら実装言語の記述効率は着々と上がっても,自然言語の記述効率はさほど上がらないからだ.DSLとか形式言語を使って記述効率を上げるという議論もあるけれど,ツール群が充実してDSLと実装とをいったりきたりできるようになると,そもそもDSL記述って仕様なのか実装なのか微妙なところだ.

仕様書が受託開発に於いて重要なのは,仕様書に基づいた実装を完了することが検収の条件となるからだ.他人のためにつくるから何をつくるかの約束事が必要なのであって,自分のためにつくるとか,自分のつくったものを不特定多数のひとに使ってもらう分には,厳密な仕様書などいらない訳だ.

そして往々にして仕様書の出来が悪いのは,プログラムを書けない奴が仕様書を起こすからである.どうつくるかという想像力に欠けていることもあるし,本当に必要とされていることを精製されていないこともある.プログラマにとって苛立たしいのは,自分よりも馬鹿の書いた仕様書に振り回されて,クールでも本質的でもないことに工数を割くことである.

優秀なエンジニアは面白い仕事を探す.だからプログラムを書けない奴が長々とした会議仕様書を通じてプログラマ足枷をはめるような職場からは,優秀なエンジニアは段々と逃げ出していくだろう.

そう考えると旧来の定義での情報サービス産業に優秀なプログラマが残るとは考え難い.自律的で優秀なプログラマが,駄目な奴と十把一絡げで人月単価で計算され,使い捨てられるような仕事に就くだろうか.時間的な仕事量ではなく,仕事の質や意味を通じて,成果を出し,評価を受け得る領域に行こうとするだろう.

IT産業の内側なら,他人のいうことを聞くのではなくて自分の考えを世に問うことのできるパッケージSaaSの方が面白いし,ICTを使ってICT産業の外側で新しいビジネスモデルを組み立ててれば,システム構築だけでなくビジネス自体から継続的な収益を上げることができる.

もはや大企業に於ける業務のITによる作業の自動化といった領域は概ね開拓され尽くされていて,そこには大きな市場があるし価格破壊による新規参入の余地もあるが,基本的に煮詰まった成熟市場だ.だから,これまで充分にIT投資を行っていない中小企業とか,これまでと全く違った商流をつくるC2C的なサービスの方が面白そうだ.

仮に狭義の情報サービス産業が成熟しているとしても,これから出てくる新産業がITと関わっていない可能性の方が低い.ベンチャーによるIT企業への投資ネットバブル時の1割ほどで,多くの資金がバイオとか医療に流れているという話があるけれども,バイオだって医療だって最先端の技術には最先端のITが活用されている.飲食や流通といった既存の産業でも,ITが作業の自動化だけでなく,新しい市場や価値を生む機会がいくらでもある.

既存の商流ビジネスドメインを効率化するとかではなくて,がらっと変えてしまうようなイノベーションは,これまでのようなユーザー企業とITベンダとで要件定義や仕様書で線を引いた受発注関係ではなく,創り手が自発的に創造性を発揮し,その質に応じて報われるビジネス構造から生まれる可能性が高いのではないか.そういった実社会と深く結びついた革新のために,エンジニアが知恵を絞ることができるような事業構造はどうすれば可能なのだろうか.

syotaro_yoshidasyotaro_yoshida 2007/05/14 12:55 まったく持ってその通りだと思います。
人月ベースで定義される仕事は、要求仕様書の要求事項を満たすことのみに
主眼が置かれ、顧客の問題解決や価値の提案などは盛り込まれていないように
感じます。

現実問題としては予算と、到達範囲を明確に定義する必要がありますが、
これはビジネスモデルの欠点なのでしょうね。

ただ、エンジニア自身がおもしろい仕事を見つけられるかどうかは別問題
です。結局、お金を儲けるということはおもしろいかどうかだけでは決ま
らないわけで、取り分けてキャッシュフローを確立するのが難しい。

FATFAT 2009/01/13 16:00 このエントリーのロジックは、日本の組織活動全般に当てはまるような気がします

mkusunokmkusunok 2009/01/13 17:24 そうかも知れませんね。ITが特別じゃないよと。その文化的土壌って、どこにあるのでしょうか。気になるところです。

つよしつよし 2009/02/17 14:50 今の情報サービス産業は、昔の代書屋さんに近いと思い始めています。
識字率が低いときには付加価値が高くて大もうけですが、一通りの教育が行き渡ってしまえば単なる単純労働です。

そこで失われた経済規模の代替を求めたときにどこに出口があるか、と問われると...代書屋ですからね。文字書けるだけの能力にいまさら金は払わないでしょう。
価値の集積度を高める=より安い労働力を提供するか、独自の価値を提供することにシフトすることになるんでしょう。

投稿したコメントは管理者が承認するまで公開されません。

スパム対策のためのダミーです。もし見えても何も入力しないでください
ゲスト


画像認証

Creative Commons License
雑種路線でいこう by 楠正憲 is licensed under a Creative Commons Attribution-NoDerivs 2.1 Japan License.
このブログは楠正憲の個人的なものです。ここで述べられていることは私の個人的な意見に基づくものであり、私の所属する組織とは何ら関係はありません。