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

情報サービス産業に対しては，人月単価ベースのビジネスモデルがいけない，エンジニアを使い捨てている，高い単価でオフショアとどう戦うのか，とかいろいろなことがいわれているし，どっかに活路がないものかなとここ数年いろいろ調べたりもしたのだけれども，最近ふと別に情報サービス産業に明日がなくても構わないじゃないか，と考えるようになった．
結局のところ要件定義や仕様書に基づいてシステムをつくるという仕事は，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ベンダとで要件定義や仕様書で線を引いた受発注関係ではなく，創り手が自発的に創造性を発揮し，その質に応じて報われるビジネス構造から生まれる可能性が高いのではないか．そういった実社会と深く結びついた革新のために，エンジニアが知恵を絞ることができるような事業構造はどうすれば可能なのだろうか．