ARCによる新しいビジネスモデルの可能性

顧客と共栄を目指すビジネス・モデル

ARCは、納品型のソフトウエア開発とは、さまざまな点で異なります。従来のシステム開発受託のビジネスでは、完成されたシステムを成果物として納品します。こうした文化の違いを考えずに従来のシステム開発受託の感覚でARCを始めると、多くの食い違いが発生し、うまくいかないでしょう。

一方、SaaSベンダーにとっては、ARCを採用することは自然なことであり、うまく活用することでより大きな効果を発揮できるでしょう。しかし、世の中のすべてのWebアプリケーションがSaaSで提供されることはありませんし、すべてのユーザー企業がニーズを満たすために内製要員を抱えることも現実的ではありません。

この課題を解決するヒントとして、筆者たちが行ったARC実践事例を紹介します。SaaSのような汎用品ではなく、特定顧客のニーズに応えつつも、納品型のシステム受託でなく、ARCを実践した事例です。

この事例は、とある企業のエンドユーザー向けのWebサービスです。社員が利用するものではなく、顧客企業のエンドユーザーが利用するというところが1つのポイントです。社内システムではないので、パブリック・クラウドを活用できます。今回は、Amazon Web Services（AWS）を採用しています。

また、既存システムのリプレースなどでもなく、新規に開発するシステムです。さらに、エンドユーザー向けということもあり、最初からたくさんの機能が盛り込まれたものというよりも、最初は小さく始めてユーザーのニーズに応じて機能追加していくことを目指しました。

顧客との役割分担として、企画と営業を顧客が行い、Webサービスの開発と運用を筆者たちが行っています。本番環境とテスト環境をAWS上に構築し、インターネットを通じて、顧客側の担当者に操作を行ってもらいます。各環境の内部へのアクセスは、筆者たちのみに制限しています。

「顧客にいったん納品した後で、運用を任される」という形ではなく、当初から、Webで利用できる環境をそのままサービスする、という形をとっています。ですので、必要な書類は少なく、内部に関する資料は不要になります。

企画の最初の段階から、筆者たちのプログラマが参加しており、顧客の担当者と直接話をして開発内容を決めながら進めていきました。一番最初のリリースまで1カ月をかけずに、動くサービスとして稼働させています。あとは、実際に稼働するサービスを動かしながら、必要な機能を決めて開発を進めていきます。

もし、要件定義などと言って将来を見通した機能設計をしようとしていたら、それだけで相当な時間がかかっていたと思います。実際に要件を決めるにも時間がかかるものです。決まったところから機能を開発して動くサービスに反映させていくことが、ちょうど良いタイミングになっています。

今回の事例では、レベニュー・シェアという形の契約形態をとりましたが、ほぼ実際には、月額固定の費用でのサービスに近いものになっています。ここが従来の納品型のソフトウエア開発のビジネスと違う点です。成果物に関する完成責任での契約ではないのです。

この金額固定の契約は、従来で言えば、保守契約に近いものかもしれません。保守契約との違いは、要員を現場に派遣して張り付けるのではなく、クラウドを通じてサービスを提供しているという点です。月額固定にすることで、これまでのシステム開発では応えられなかったスモール・スタートが可能になり、最初の段階で大きな金額を投資する必要がなくなります。

SIerのビジネス・モデルでは、ある程度のボリュームのシステム開発案件にしなければもうけが出ない構造のため、どうしても最初の段階である程度のWin-Loseが見えてしまいます。しかし、それではどちらか一方が不幸になるだけです。金額が固定であれば、お互いに余計な機能は作らず、本当に必要なものだけを作ろうと考えが変わってきます。

一方、金額固定の契約方式のリスクは、完成責任を負うものではないため、本当に投資に見合うだけの開発がなされるかどうかが見えにくい点です。それについては、属人性を排除するという従来の考えを一転して、実際に開発をするプログラマのチームを担当制にして「誰が作っているか」を約束することで担保する方法をとりました。これも、開発時だけ実装要員を増やすという考えや、開発と運用でチームを分けるという考えを捨てることから実現できます。

ARCモデルの本質

ARCは、アジャイル、Ruby、クラウドの頭文字ですが、必ずしもRubyである必要は無いと思います。筆者たちSonicGardenの技術戦略としてRubyを選んだということなので、Pythonでも構わないと思います。ただ、ARCに向くプログラミング言語やプラットフォームというのはありますし、Rubyはここで紹介したモデルにもっとも向いていると感じています。

ARCを実践してきて大事だと感じる価値観は、「作り手（プログラマ）が直接対話すること」、「いつでも動くサービスを提供し続けること」、「顧客との共栄を目指すこと」、そして「変化に対応していくこと」、です。それを素直に実践できるようなビジネス・モデルとワーク・スタイルを目指すことが、ARCの本質ではないかと思います。

ARCモデルを普及させる際に目指したいのは、従来のシステム開発業界にはびこる、あしき慣習の打破です。アジャイル、Ruby、クラウドを活用することで、従来であれば大企業のように大きな資本を持たなければできなかったシステム開発が、技術力のある小さな企業でも可能となってきています。

また、顧客にとっても、本当はスモール・スタートしたいようなWebサービスがあったり、この経済状況の中で、丸投げをするのでなく自らリスクをコントロールして低コストでシステムを手に入れたいというニーズが増えてきています。

また、ソーシャル・メディアが広まるにつれて、企業だけがブランドを持つ時代から、個人でもブランドを持てる時代に移りつつある中で、優秀なプログラマが活躍できるビジネス・モデルが求められているように思います。

ARCは、それらをうまくつなげるイノベーションになる可能性を秘めていると、筆者は考えています。