As a Service と Open が Innovation を創出する

先週バルセロナで開催された OpenStack Summit に参加し、いくつかのセッションを聴講したり、参加者とのディスカッションで学んだこと。それは、Open Source, Open Community と As a Service との組み合わせが Innovation を創出しやすい環境を提供していているということでした。以前から漠然と思っていたことと合わせて以下の通り整理してみましたので公開します。

1. As a Service は Lean Start-up に向いている。最初から完璧を求めず、MVP (Minimum Viable Product：必要最低限な機能を持った製品・サービス) を実顧客に提供することができる。β版もMVPのひとつであるし、プロトタイプでも良い。なぜ、As a Service だと MVP の状態で実顧客に提供しやすいかというと、製品として顧客の手元に渡ってしまうものと違って改修がしやすい。不具合の修正もできるし、機能の向上、追加もできる。これが、CI / CD (Continuous Imtegration / Continuous Delivery)。
   
   
2. Open Source は、従来のソフトウェア製品と比較して品質面が不完全であることが少なくないが、Open Community による Open Development によって改修が継続的に行われ、かつ改修も早い。また当事者である自分自身で改修を行う事もできる。（と言うよりもすべきであろう。）　このような DevOps / Agile な開発を行うには、既に顧客に提供してしまっている製品／サービスへの反映の手間（コストと期間）が課題であった。
   
   
3. この課題は、As a Service とすることで解決される。顧客の手元にあるものを改修するのは莫大な労力とコストを要するが、As a Servie の場合には事業者側を改修するだけで済む。
   
   
4. MVP を As a Service で顧客に提供することによって、顧客要望を取り込むことができる。Open Design 的なアプローチによってサービスを顧客ニーズの変化に追随し継続的に進化させることができる。
   
   
5. Open Source の Open Community による Open Development によって、自社の開発リソースを使った独自機能の開発ではなく、広く世界中にいる開発者の力を借りて皆が必要とする機能や品質を継続的に開発することができる。
   
   
6. 上記を理解し共感し共創の精神で自らも貢献していくことができない組織は、Open Source を活用してイノベーションを創出することは難しいだろう。
   
   
7. 大きな課題はマネタイズの方法であり、それが明確にできないと特にレガシーな組織（特に日本の大企業など）は経営陣による理解や承認が得られなかったり、上場企業であれば株主からの圧力によって、実行できなかったり、そもそもスタートできない可能性が高い。　
   
   
8. そのような状況に陥ると、Open Source を元に独自開発を行い他社との差別化を図ろうとしたりする。そして、そのような会社は往往にして開発をウォーターフォール型で行う傾向にある。その場合、元の Open Source とは別の「亜種」のようなものになってしまい、本来の Open Source、Open Community のメリットを享受できなくなり、結局は機能拡張や信頼性向上などで遅れをとることになる可能性がある。