« MT用Flashクライアント作り始め(XML-RPC) | メイン | MT用Flashクライアント:Statusは? »

ソフトウェアのイノベーションは、どこから起こるのか

江島氏の「サーバにイノベーションのジレンマは起きているか(1) (2) (3) (4) (5)」を読んで、僕なりの視点で、いろいろ感じることがあった。

江島氏は、サーバ技術やソフトウェア技術の目標を、

「抽象度の高い」「生産性の高い」ソフトウェア技術の目指すところは、人間が感じる複雑さを軽減すること、人間にとっての見え方をよりシンプルにすることに力点がある。

この延長線上にある究極的なゴールはどこか?それは、業務システムを作るための受託プログラマを必要としない世界である。

とした上で、これに対するジレンマを

メインフレーマーや大手インテグレーターがジレンマに陥るポイントは「受託エンジニアがいらなくなる社会」の到来であり、そしてそれはソフトウェア・イノベーションの一貫した方向性と一致している。

まさしく「IT業界は自分たちの職をなくすために仕事をしている」のである。

と指摘している。
そのイノベーションの要素とは「性能」「価格」「信頼性」「利便性」だ。ハード面からは、オープンシステムはイノベーションの可能性がある。しかし、システム開発のコストはほとんどは人件費だ。ソフト面(含む人間)から見れば、そこにはイノベーションが起こっていない。ここから、江島氏の所属するインフォテリアの製品(ASTERIA)が、ソフト面でのイノベーションを目指しているという話になる。

ASTERIAという製品の性質は、ひとことで言えば「ノン・プログラミングでシステムを作る」というものである。

ユーザの声をダイレクトにシステムに反映しスピードアップと品質保証を両立させる。ここには設計と開発のプロセスに区別はない。そんな新しい価値観と新しいワークスタイルを、フィールドエンジニアに提案するところがターゲットなのだ。

この「ノン・プログラミング」というパラダイムへのシフトこそが、オープンシステムにとって最大級の折り返し地点になるであろうことを、インフォテリアでは最大の仮説として置いている。

イノベーションのジレンマについては賛同する。しかし、単に「ノン・プログラミング」にすれば、イノベーションを生むかというのは疑問を感じた。もう少し深い話が必要だと思う。


ソフトウェア品質向上には、知識のシェア = ツールが必要
まず、ツールとはなにかというのを掘り下げたい。
品質向上をユーザー視点で考えた場合、今求められているのは、「ビジネスとマッチしているのか」ということだ。これは、変化するビジネスに対応し、常に整合性を保つことが求められる。ソフトウェアとして基本的なバグなくとも、仕様が正しくなければ意味がない。

そのため、ソフトウェアエンジニアリングで積極的に取り組まれているのも、ビジネスからシステムへの落とし込み方法の開発である。これは、プログラミング言語の自由度が高まっったことも関係している。昔であれば、言語の制約から書き方を変えることは難しかったが、自由度の高い言語の登場により、書き方の範囲も広がった。
つまり、「どういう書き方であれば、ビジネスの変化についているのか」というのを議論しているといっても良い。

例えば、言語で言えばオブジェクト指向型のJava・C#、設計ではUML、開発プロセスとしてXP・RUPなどである。

そのため、一般的なエンジニアにとっては、書き方や手法を「知っているか」ということが非常に重要になってきている。当たり前だが、多くの人数で考えたほうが、良いものができる可能性は高い。その成果を利用しない手はない。

そういった知識をシェアするためには、知識の有形化が必要である。これが、ツールというものだ。

この、知識をシェアするためのツールを究極的に進化させていくと、プログラミングの範囲を狭めることができる。MDAのアプローチは、これに近い。

(余談であるが、江島氏の文章の中で、言語の高級化がコードを減らし、品質が高まるというくだりがある。が、それはさすがに間違っている。確かに低層なライブラリは充実しているが、書き方の範囲が広がっているはずだ。それが証拠に、昔と比べてバグは減っていない)


知識のシェアにはハイブリッド型のツールが求められる
こういったツールは、従来の概念ではくくれないはずだ。知識は常に増え続けるし、ビジネスも変化していく。それに対応できなくてはいけない。

たとえば、オープンソースはどうだろうか。現在、知識の流通量という点では、オープンソースに勝るものはない。オープンソースの世界では、有能なプログラマ達が自分達のコードを公開し、議論をしながら良い手法というのを日々作り続けている。

とはいえ、現状のオープンソースでは、どうしても大きな広がりを得ることはできない。これは、マイクロソフトも批判している点だ(*1)。あまりにも自由すぎる知識の流通では、発案者へのインセンティブがなくなったり、健全なビジネスとして成り立たせることができず、全体のリスクを押し上げてしまう可能性がある。例えば、早すぎるトライ&エラーによって、技術が異常な速さで陳腐化し、採用企業側で維持にコストがかかってしまう状況がいまでも起こっているだろう。

そこで有償ツールとオープンソースのハイブリッド型のアプローチが模索されている。

たとえば、IBMがオープンソースコミュニティ寄贈したEclipseは、様々な機能を追加してWeb Sphere Studioとして出荷されている。オープンソースベースで開発された成果は、順次製品に取り込まれる予定だ。あるいは、Microsoftも、OSコードをどうにか"安全に"オープンにできないかと、様々なプログラムを実施しようとしている(*2)。


ハイブリッド型ツールによるイノベーション可能性
僕は、こうした「健全な知識のシェア」を目指したハイブリッド型のツールにこそ、イノベーションの可能性があると考えている。

ハイブリッド型に求められてるのは、有償の安定性とオープンソースの自由度の両立だ。多くのエンジニアの知識を短いタイミングで的確に取り入れ、ツールとしてフィードバックしていく。Linuxで、トーバルス氏がはたした調整機能などは、この感覚に近いだろう。

また、すべてのコードが、オープンである必要性もないだろう。コア部分はオープンで、拡張部分を有償にするとか、交換可能なプラグインの高性能版を有償で提供するとかである。この点では、Eclipseが成功し始めているといえよう。

また、ハイブリッド型はツールの価値を定義しやすい。従来は、ベンダーが代替できるであろう人件費を決めていたため、価格モデルに柔軟性がなく、プロジェクトによっては不採用、あるいは違法コピーが出回っていた。しかし、コードがある程度でもオープンであれば、必要な部分を見極めたり、価値を市場理論で決定できる。(物理的に可能かということよりも、チェック可能だという緊張感が良いと思う)

確かに「ノン・プログラミング」は、パラダイムシフトになりえる。しかし、それは目標ではなく、結果に過ぎない。重要なのは、多くのスーパーエンジニアの知識をシェアし、それをみんなが使えるようにするという世界だ。その上で、その知識を出した人物にインセンティブを支払う。知識をシェアや流通ができる枠組みがないと、時代の流れについていくことはできない。

僕は、音楽業界と同じ流れがあると感じている。消費者は、ディスクにお金を支払っているのではない。アーティストに、感謝の気持ちをこめてお金を支払うべきなのだ。それと、同じだ。ツールベンダーが、従来の枠組みの中にいるだけでは、違法コピーのなくならないし、納得性を持ってお金を支払うことなんかできない。


参照:
*1: ソフトウェア ライセンシングおよび開発モデル ソフトウェア開発モデル概要
*2: 「オープンソースに学べ」 -- マイクロソフトの姿勢にビミョウな変化?

トラックバック

このエントリーのトラックバックURL:
http://www.arclamp.jp/mt33/mt-tracback.cgi/1260

コメントを投稿

(いままで、ここでコメントしたことがないときは、コメントを表示する前にこのブログのオーナーの承認が必要になることがあります。承認されるまではコメントは表示されません。そのときはしばらく待ってください。)

About

2003年11月17日 15:00に投稿されたエントリーのページです。

ひとつ前の投稿は「MT用Flashクライアント作り始め(XML-RPC)」です。

次の投稿は「MT用Flashクライアント:Statusは?」です。

他にも多くのエントリーがあります。メインページアーカイブページも見てください。

Creative Commons License
このブログは、次のライセンスで保護されています。 クリエイティブ・コモンズ・ライセンス.
Powered by
Movable Type