 |
||||||||||
|
||||||||||
| 前のページ 1 2 3 次のページ | ||||||||||
|
||||||||||
| オープンソースに対する疑問と回答 | ||||||||||
|
今回の連載は、数回に分けて、魔法のお鍋に書かれている9つのビジネスモデルを詳細に解説する。そして後編では、それらのモデルに対して「現場の人間」から必ず寄せられる疑問と、それらに対する回答を用意した。 まず、ビジネスモデルから見てみよう。 |
||||||||||
| Apacheの実践する | ||||||||||
|
コスト・シェアリングモデルオープンソースにすれば、システムの開発費や維持費を、多くの人に分散できる。ここで「共同開発」という明示的な方法によらないのが、重要な点だ。 一度挑戦された方ならわかると思うが、合議制等による共同開発には、大きな落とし穴がある。利益配分や作業配分の問題が、最も重要な打ち合わせ課題になってしまうのだ。また、共同作業が技術者の自己主張の場と化してしまうと、そこは修羅場だ。 その点オープンソースとして公開すれば、そもそもの開発者が放り出しておいても、何時の間にか誰かが改良してくれるかもしれない。また技術論議や作業分担、利益分担等を気にせず、スムーズに共同作業を進められる可能性も高い。 セルベッサも、三井物産がASPとして採用してくれた手探りの頃、会議によって開発の方向を見定めようとした。今、考えても、あの打ち合わせの虚しさはなかった。せっかくオープンソースにしたのだから、もう少しやんわりとした共同作業ができたはずだと、今となっては思う。 |
||||||||||
| シスコを支える | ||||||||||
|
リスク分散モデルIT部門は、さまざまな将来リスクを抱えている。たとえば人的リソースの問題だ。開発担当者を企業内部に維持できなくなる企業は、珍しくないだろう。 人的リソースの不足に備えるには、オープンソースが有効だ。そして多くのユーザ企業が考えなければならないビジネスモデルが、ここにある。 ソフト技術者のレベルを維持するのは難しい。また彼らの興味をいつまでも引き止めておくのも容易ではない。さらにいえば、「釣った魚に餌はやらない」文化で育ってきた企業経営者に、魚が死んでしまうリスクを認識させるのがいかに困難かということだ。 それでは、20年間安定稼働していたソフトに、急に改変の必要性が出たら、一体どうすればよいのか。その時に偶然担当者にされてしまっていたシステム責任者は、仕様も何もわからないシステムを前に、こう叫ぶに違いない。 「前任者は後の事を一切考えていない。あまりにも無責任ではないか」 だが、20年先を考えて開発を進められる担当者はいないだろう。また企業経営者としては、20年も安定稼動しているソフトの維持のために、年間数百万円もの人件費は払いたくない。たとえ専属の担当者を雇ったとして、その担当者がちゃんと職務を果たしているかどうか、確認する術はない。勤労度合いのチェックのためだけに、時々作り直したり、改良させたりするだろうか。そこまでするくらいなら、「風が吹いたら首を縮めて、頭上を通り過ぎるのを待つ」のではないか。 しかもこれは、割合に勝ち目の多い勝負だ。かくして「座して死を待つ作戦」で、コスト削減の栄誉と、事故なしの運用記録が手に入る。 これは正解なのか。もちろんそうではない。「もう少し早めに経営者を説得し、オープンソースとして公開しておけばよかった」というのが正解だ。彼はそう呟くべきだったのだ。 オープンソースにしておけば、こんな破局はやってこない。もちろん絶対ではないが、少なくとも破滅に至る可能性を大きく減らすことができる。 ソフトを読み解くのには時間がかかるが、オープンソースなら、この時間を節約できる。追い詰められた担当者にとっては「時は命なり」だ。 オープンソース化し、小さくてもコミュニティが立ち上がり、メンテナンスしていれば、こうした事態を防げる可能性は高い。もしかしたら「それに対応したバージョンなら、去年の夏にアップしたよ」というメールが届き、問題は解決するかもしれない。 |
||||||||||
|
前のページ 1 2 3 次のページ |
||||||||||
|
|
||||||||||
|
||||||||||
|
|
||||||||||
|
||||||||||
|
|
||||||||||
-
-
連載
