More info...

2010-06-18

オープンソースによる新しい受託スタイルの提案

前々回のエントリ「受託開発とGPL」では、受託開発においてGPLのソフトウェアを用いる際に注意すべき点やライセンスの扱いについて書いた。ただし、その視点はあくまでも「GPLはSIerにとって注意すべき≒厄介なシロモノであり、如何に地雷を踏まないようにするか」というものであったように思う。だが、「厄介である」という性質は、裏を返せば「味方につけると頼もしい」ということだ。つまり、GPLは、味方になれば強力で頼もしい存在なのである!今日は、SIerが今の開発スタイルから脱却し、如何にしてGPLを味方につけて戦っていくかということについて語ろうと思う。ちょっとひどい妄想夢物語的な記述も入っているのだが、「何言ってんだコイツ?!」とツッコミたいところをぐっとこらえて最後までお付き合い頂ければ幸いである。

システム全体を再構築するのは大変

SIと一口で言ってもその規模は大小様々であるが、業務(基幹系)システムをお客のニーズに合わせて一から構築するとなると、その規模は巨大にならざるを得ない。開発を効率化するために、様々なフレームワークやライブラリを駆使することになるだろうが、大量のプログラムを案件ごとに書くのはどうしても避けられない。その大量のプログラムを開発するのに掛かる工数を、人月単位で見積もってお客さんから頂戴するのが今のSIのスタイルである。

お客の業務プロセスは千差万別であり、100社のお客が居れば100通りの業務システムが構築されることになる。とはいえ、それらは同じ「業務システム」というジャンルであるため、各々のシステムには共通のロジックがかなり含まれることになる。反感を恐れずに言えば、それは壮大な車輪の再発明をおこなう行為でもあると言っても過言ではない。再発明だからと言って、SIが容易な作業だというわけではない。むしろその規模から考えると、全てを段取りよく行うのは至難の業である。個々のロジックは使い古されたものであっても、全体としてシステムを構築するのが難しいのだ。つまり、SIとは規模が大きい故に成り立つビジネス形態なのである。如何にそれを効率的に、計画的に、お客のニーズに合わせて柔軟に、そして納期に間に合うよう確実に行うかということが、SIerとしての腕の見せ所となろう。

大規模システムは開発すること事態も非常に大変なことであるが、ユーザー企業側には、システム開発完了後も後生大事にメンテナンスをするという大厄・・・もとい大役が待っている。実際にはSIerに丸投げすることになるだろうが、そのメンテナンスコストたるや高級車が買えるどころの話ではない。

パッケージ製品は賢い選択肢か?

壮大なシステム構築のプロジェクトには、巨額の資金が必要となる。するとユーザー企業は躍起になってコストカットに奔走するわけだが、そこでユーザーを新たに誘惑するのが、予め業務システムにとって一般的なロジックを作り込んだ「パッケージ製品」である。あくまでも一般的な話として、パッケージ製品には、SIと比較して
  • 構築に時間が掛からない。
  • 価格が安い。
といったメリットがある。こういった特性はユーザー企業にとっては非常に魅力的だ。「なにっ!?それはいい!!もう使うしかない!!」という具合にユーザーは飛びついてしまうのではないかと思うかも知れないが、実際にはそうでもない。ユーザーが業務パッケージに飛びつかないのは、パッケージ製品には都合の良い側面だけではなくデメリットも存在するからだ。

その中で最も代表的なのが、パッケージ製品ではあまり枠から外れたことは出来ないというものだ。自社の独自の業務フローに合わせてシステムを構築するといったことは苦手なのである。ユーザー企業側の業務フローが至極典型的でシンプルなものでない限り、そのまま業務パッケージを自社のプロセスに当てはめて使うことは出来ない。

また、ひとたびパッケージ製品を使い始めると、ベンダーロックインという恐ろしい罠が待ち受けているのも頂けない。確かにSIに比べるとTCOは下がるかも知れないが、ユーザー企業は将来に渡りそのベンダーの商品を使い続ける羽目になってしまうのである。たとえ他社製品に乗り換えたいと思っても、自社の業務フローをパッケージ製品に合わせてしまっていては身動きが取れないだろう。その結果、ロックインされ続け、ベンダーの言い値で料金を支払うことになるのだ。

SIerに全部作ってもらうか、パッケージ製品を導入するかという状況は、ユーザーにとってまさに「前門の虎、後門の狼」である。逃げ場はない。ならばどちらか一方を選んで大金を払ってしまうしか道はない。それが現状である。

賢者の選択=GPL!!

大規模システムを継続して利用する際にかかる高額なメンテナンスコストや、パッケージ製品利用時のベンダーロックインを避けることが出来る唯一の道は、オープンソースである。ソースコードが公開されていれば原理的にベンダーロックインは発生しないし、カスタマイズも可能だ。

「オープンソースなら全て解決じゃないか。オープンソースブラボー!!」

と言いたいところであるが、残念ながらことはそれほど簡単でもない。そもそも現在の業務システムはオープンソースではない(ものが多い)ので、「如何にしてオープンソースで業務システムを構築するか?」という最初のハードルが待ち構えているのだ。いわゆる「産みの苦しみ」というヤツである。オープンソースの業務システムを手に入れた暁にはバラ色の生活が待っているのだが、如何にしてそれを手に入れるかが最初にして最大の難関であろう。そう、問題は、

「SIerはソースコードをオープンソースライセンスで提供してくれるか?」

ということである。オープンソースライセンスは星の数ほど存在するが、その中でももちろんフリーソフトウェアライセンスをチョイスしたい。もちろんベストなのはGPLだが、ライセンスに互換性がない場合にはMPLなどの弱いコピーレフトのライセンスを選択するとイイだろう。MPLのようなフリーソフトウェアライセンスであれば、少なくともソースコードは再利用・再配布可能である。もし状況が許すなら、最も強いコピーレフトライセンスであるAGPLv3をチョイスするのもアリだ。オープンソースの業務システムを手に入れるにあたり、最も難しい課題はこの点だろう。SIerとの契約書をどのようにするかということも検討しなければいけないし、SIerを説得するには割り増し料金を払うことも検討しなければいけないだろう。

オープンソースの業務システムを手に入れるにあたっては、SugarCRMなど既存のオープンソースの業務アプリを活用すると良い。もちろんそのままでは業務に適合出来ない場合が多いので、SIerにカスタマイズしてもらったりプラグインを作成してもらったりした部分を、オープンソースで貰いうけるという寸法だ。そうすると開発期間・コストが下がることが期待出来るし、ライセンスの問題もクリアし易い。元々の開発費が低ければ、割り増し料金を支払ったところでフトコロはそれほど痛まないので、割り増し料金を払うという戦略も採りやすい。

ユーザー企業にとってのウルトラCは、現在利用している自社の業務アプリをオープンソースとして公開するというものだ。もし自社で業務システムのソースコードとその著作権を保有しているのであれば、これは非常に魅力的な選択だ。「自社の知的財産をわざわざさらけ出すなんてとんでもない!」と、古いタイプの人には反対されるかも知れないし、ライセンスの整備(GPLが適用出来るなら最高だ!)や社内調整が難航するかも知れないが、オープンソースとして公開することにはそれに見合うだけの価値がある。無料で利用できればユーザーは増え、コミュニティが形成されることになるだろう。するとバグ出しや相互助力による問題解決、さらには機能拡張が期待出来る。そのソフトウェアを活用してSIをする業者が現れたら最高だ。コミュニティはエコシステムへと発展し、その業務システムのメンテナンスコストは飛躍的に下がることになるだろう。

オープンソースすると損をするのか?

大枚はたいて構築したソフトウェアをオープンソースで他人に無償で提供するなんて?!ライバルがそれを使う可能性もあるし、それはみすみす敵に塩を送ることになるんじゃないのか?!と思う人も居るかも知れない。

いいじゃないか!!ライバルが助かったっていいじゃないか!!それ以上に自分が助かるのだから!!特にライセンスにGPLを選択しておけば、ライバルがそれを拡張したときに拡張部分をGPLで公開してくれる可能性がある。

ライバル同士が助け合う。いいことじゃないか!最高だ!!そもそも、今は日本企業にとって国内のライバル同士で争っている状況ではないはずだ。チマチマとお互いの足を引っ張り合ったりしてる場合ではないのだ!!ライバルが助かったって、日本が、日本の会社が元気になればそれでいいじゃないか!!ちなみに、孫正義氏も今年の3月に行ったライブで同じような主張をされている。そう、次のように。
ヤフージャパンが喜ぶ。それはいいじゃないか。でもついでに楽天も喜ぶぞ。ついでにニフティとかなんとかいろんな会社もインターネットやってるあの人たちもみんな喜ぶけど、社長いいんですか?

うちの役員に聞かれました。

「バカモン!!」

「そんなこまい、ちまちました考えでどうするんだ! ヤフージャパンが喜ぶ、ええじゃないか。ついでに楽天も、モバゲーみたいなところとか、そのいろいろあるけども、みんな喜ぶでええじゃないか」
そもそも今持っているものをオープンソースしたところで、今使っている業務システムが止まるわけでもない。ソースコードが消えて無くなるわけでもない。金がかかるわけでもない。失うものなんて何もないのである!ライバルがほんの少し得をする。そんなのはいいじゃないか!!後で自分にもっとでっかくなって返ってくる可能性があるのだから!!利他は最終的に利己へと通じる。まさにフリーソフトウェアの精神である!!

ようこそフリーソフトウェア!!さらばロックイン!!さあ、あなたは自由の身だ。GPLが適用されたソースコードさえあれば何処にだって行けるッ!!

SIerの短期的な成功

ボルテージが上がりすぎてしまったのでここでいったんクールダウンしよう。これまでは主にユーザー側の視点に立って解説して来たが、ここからはSIerにとっての視点に切り替える。

開発したシステムのソースコードをGPLで納入ないしは公開する。もしあなたがSIerならば、「そんなことが本当に可能なのか?もとい、本当にそれでビジネスが成り立つのか?!」という疑問を持たれるはずだ。「そんなわけがない!!そんなビジネスが成り立つわけがない!!」と。

GPLであってもビジネスは成り立つ。ユーザーがお金を払ってくれる限りは。

SIerが取り得る戦略のひとつとして、「GPLにすること」自体に付加価値をつけることが挙げられる。ユーザーにGPLでオープンソースすることの良さを理解して貰うことで、「GPLであること」に対してプレミアをつけるのである。つまり、GPLにする代わりに割り増し料金を頂戴するという、至極分かり易い短期的なメリットを享受するというわけだ。実際、上記で述べたようなメリットがあることを本当にユーザーが理解していれば、賢いユーザーは割り増し料金を支払ってでもGPLを選択するだろう。そのようなユーザーに対しては、他社SIerとコンペになったとき「うちはGPLでやります」と言えば大きなアドバンテージになるはずだ。

このように、やり方次第ではあるが、短期的にはGPLを利用することは利益を生み出すのである。

SIerに広がる新たなビジネス

納入したシステムのソースコードをGPLで公開したり、GPLのシステムに手を入れてユーザーのニーズに沿うようにする。そんなスタイルの受託開発を俺は提案したい!!SIというビジネスに新たな広がりを創造するために。

大手SIerの利益悪化がとどまることを知らない件 - GoTheDistanceではSIビジネスが儲からなくなってきている様子が描かれている。以下は記事からの抜粋である。
今までの延長線上で取れる仕事が無くなって来た、ってことが鮮明になってきました。特に親会社に力のあるSIerの数字が悪い。系列関係の仕事しか無い証拠ですね。全体的に「予算を切られた」→「見込んでた仕事無くなった」→「稼動しない」→「売上立たない」→「利益でない」→「数字悪化」という大変分かりやすい絵になっております。

このような状況は、SIerにとってもユーザー企業にとっても、そして日本全体にとっても幸せなものではない。出来ることなら、SIerには頑張ってこのような状況を打破して頂きたい!!そこで、提案させて頂くのがオープンソース戦略である。何度も繰り返すが、ライセンスはGPLがベストだ!!

単刀直入に言うと、大規模開発でお金を頂戴しようという発想を転換し、保守でお金を頂戴する戦略へと切り換えるのである。収入源が保守サービスになれば、ソースコードをGPLで公開したところで失うものは何も無い!!というわけだ。今やプロプラエタリソフトウェアの世界でも、ライセンスフィーから保守料へと収入源のシフトが起きている。SIの世界でも同じ方向へ進むのは全然不自然じゃない。保守料をメインの収入源にするのであれば、ライセンスをGPLで、かつ無料で提供したほうが有利になるだろう。

GPLのソフトウェアを"ハック"するという選択肢が意味すること。

GPLのソフトウェアを題材にして競争する場合、皆が同じソースコードにアクセスできる。従ってライバル達は完全に平等な立場で競争することになるだろう。そのような状況で競争するにあたり、勝つために一番大事な要素はなんだろうか?それはやはり「技術力」であると筆者は考える。

GPLのソフトウェアをハックするためには、そのソフトウェアをよく理解している必要がある。もちろん、そのためにはソースコードを読む技術が大事なのは言うまでもない。そのソフトウェアを他者より熟知して、上手に使いこなせる者が勝者となるのである。つまり、
  • 如何に素早く問題を解決できるか。
  • 如何に安定して稼働させられるか。
  • 如何に素早くバグを修正できるか。
  • 如何に手早くプラグイン開発や改造ができるか。
  • 如何にたくさんの良質な情報を発信できるか。
といったことが大事になってくるのだ。

昨今のIT業界ではともすると技術力はないがしろにされがちであるが、土俵をオープンソースへ移動することにより、「技術力」の重要性は復権するのである。ちなみに、Web系の会社の人たちはエンジニアの技術力を高く評価する傾向にあるように思うのだが、それは彼らがオープンソースを活用してWebサービスを構築しているからだろうと思う。オープンソースにおいてごまかしは利かない。「技術力」、少し言葉をかえると「サービス品質」での勝負になる。それはユーザーにとっても企業で働くエンジニアにとっても、素晴らしいことなのである。

また、GPLのソフトウェアを利用する場合、基本的には同じソフトウェアを長い間育てて使い回すことになるだろう。開発者だけでなく、ユーザーにとってもそれは同じである。ユーザーは、長年慣れ親しむことによりそのソフトウェアの良い点も悪い点もよく見えてくる。そうすると、「ここを改善したい。こんな機能が欲しい。」という欲求が次から次へと沸いてくることになるだろう。その度に、SIerへ小さなプロジェクトを発注するのも良いし、SIerとの「保守契約」の一貫として、細かい変更に対して柔軟に対応するという条項を盛り込んでおくのも良いだろう。ユーザーの要求は尽きない。よく知れば知るほど新たな要求が沸いてくる。そのサイクルを繰り返していれば、SIerにも仕事が尽きることはないのである。

業務システムの運用においては、何年かに一度システムをまっさらに作り直すということがままある。システムを刷新すると、使いづらくて仕方がないとか、業務に合わなくて使い物にならなかった。そういう話は枚挙にいとまがない。しかし、このようにGPLのソフトウェアをベースにして、継ぎ足しや改良を繰り返していれば、そのような状況に陥る可能性はぐっと下がることになる。どちらが最終的に会社にとって、いや社会にとって本当に必要なものになるだろうか?

業界は競争から協調へ。

オープンソースでは、業界内で横の繋がりが必然的に形成されることになる。いわゆるコミュニティである。勉強会を開催したり、メーリングリストで質問しあったり。そのような光景はオープンソースの世界ではよく見られるのだが、IT業界全体でスタンダードになったらどれだけ素晴らしいことだろうか。そのような状態にするために必要なことはたったひとつ。業務アプリをオープンソースにすることだ。それもGPLで。

同じソフトウェアを扱っていれば、様々な協業の道が見えてくる。ひとつの案件に複数の会社が合同で取り組む(元請け、下請けという関係ではなく対等に!)ことが出来るだろうし、人材の貸し借りももっと柔軟に出来るようになるかも知れない。メーリングリストやフォーラムで質問して助け合うのもひとつの協業のスタイルであろう。また、会社が違っても扱うソフトウェアが同じなら、転職もやりやすくなる。コミュニティで横の繋がりがあれば、誰に実力があるかも分かり易くなるからスカウトもやりやすい。実力があればよりよい条件の会社へ転職することが当たり前になる。人材の交流が盛んになれば、俗にいうところの「ブラック企業」は淘汰されるしかないのだ。

ライバル同士が助け合うことでIT業界全体が活気づく。業界の風通しが良くなり、エンジニアにとって住み心地がよくなる。そんな素晴らしい未来を実現出来るのは、やはりGPLしかない。

生き残りを賭けて真の競争力獲得を!

オープンソースの世界では、頭数では勝負出来ない。それよりも重要なのは、如何にソフトウェアを理解するかということである。ひとりひとりの生産性を高め、クリエイティブな仕事をすることが生き残りへの戦略となるだろう。オープンソースにすることで、とても健全な競争が待ち受けている。健全な競争をすることにより、業界は活気づき、真の競争力が手に入るのである。

人月だけで勝負するなら、日本のSIerは絶対に海外、特に中国やインドには適わない。あちらの国では皆が躍起になって技術力を高め、技術力のある者はより多くの報酬を貰う仕組みが出来ている。プログラマが使い捨てられ、35歳定年説などがまかり通る日本とは大きな違いである。それでいてなおかつ、価格的には日本人より優位なのである。だが、日本のSIerは彼らと勝負しなければならない。だからこそ、今のスタイルから脱却し、真の競争力を獲得するべく「オープンソース」の道、もとい、もっと欲を言えば「フリー(自由な)ソフトウェア=GPL」の道を歩むべきなのである。オープンソースに国境はない。そこでは、必ずや真の競争力、即ち技術力が役に立つだろう。

0 件のコメント:

コメントを投稿