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

ARCでの開発プロセス

前回は、ARCモデル（Agile×Ruby×Cloudモデル）についての概要と価値について解説しました。今回は、ARCを実践していくうえでの開発体制、ツールや手法、マネージメント、そしてビジネス・モデルについて紹介していきます。ここでは、筆者たちSonicGardenでの実際の事例を元にしたものを、ARCの一例として紹介しています。

ARCでは、クラウドを介してエンドユーザーにサービスを提供していきます。エンドユーザーからすると、いつでも、いつからでも利用できることが価値になるわけです。ずっと最高の価値を提供し続けるのが"Point of Use"なので、「開発期間があって、テストをして、納品があって、それからは保守期間に入る」というプロセスではありません。開発と、テストと、実際に利用されるサービスの運用を、一体となって継続的に進めています。継続するクラウドの提供には「繰り返し型」での開発が有効になります。

例えば、youRoomというフリーミアムのサービスでは、最大1カ月、最小で1週間程度の期間で、新しい機能や改修を行ってリリースを行っています。フリーミアムのポイントは、利用人数の母数を増やすことです。そのためには、さまざまな機能追加や取り組みを行っていき、より有効な方法に力を注いでいきます。また、ユーザーからの要望を受けて、順次実装するということもやっています。

youRoomの開発計画では、月に1度、ざっくりとしたロードマップを立てます。その際には、3カ月程度先までの計画を立てますが、具体的なところまで落とすのは1カ月先の機能までです。1カ月後にまた計画を見直して、次の3カ月分を作り直す、といった感じです。そうしなければ、実際に起きた出来事や新しいアイデアを計画に反映しきれないからです。ずっと継続していくサービスに「完成」までのロードマップは不要です。

1週間から1カ月の繰り返し（イテレーション）の中でのゴールは、実際に動くサービスです。エンドユーザーが触って価値のないものを作ることはありません。例えば、新機能の設計ドキュメントを作成することを目指したイテレーションは存在しません。イテレーションを一定の期間に保つことも開発のリズムのためには重要ですが、動くサービスとしてリリースできないのであれば、その期間を延ばすことも厭（いと）いません。

変化に対応するための開発体制

ARCの開発プロセスでは、開発と保守の期間を分けません。チーム体制も、開発だけのチームと運用だけのチームに分けることはしません。開発も運用も保守も同じチーム、しかも、最小人数でのチームを組むようにしています。チームの人数を少なくするため、分業をしません。プログラマはプログラミングをするだけでなく、顧客との対話もすれば、ユーザーへのサポートもするようにしています。

納品型のソフトウエア開発における体制の基本は、分業でした。開発チームと、保守運用だけをするチームに分ける。開発チームでも、顧客との対話には営業やプロジェクト・マネージャが間に入り、設計する人、テストをする人がいて、プログラマはプログラミングだけをするように分けることが効率が良いとされています。それは、納品型のソフトウエア開発が製造業をモデルにしているからであり、大量生産をする場合には有効な開発体制です。

ARCの、納品をしないソフトウエア開発では、開発サイクルを繰り返し、なおかつその繰り返しの単位を小さくしていくことがポイントになります。大量生産よりも、開発のスピードを上げていくことが重要です。

開発のスピードを上げるためには、コミュニケーション・ロスが発生する分業は向いていません。人数を少なくし、ピラミッド型の組織でなく、個々人が協力し合って進めていくような、コラボレーション型の組織を目指します。ARCでは、納品直前に人数を増やすといったような人員配置計画などはしませんし、多重請負などもってのほかです。

最少人数でチームを運営するにあたっては、チーム全体の意識や知識を全体的に共有しておくことが大事です。例えば「ペア・プログラミング」では、常時レビューをしているという効果もありますが、それよりも、たまに同じコードを見て話をしながらプログラミングをすることで、お互いの知識が補完されて共有される効果も大きいです。また「コードの共同所有」のために最近ではgitなどの分散リポジトリ管理ソフトを使いますが、「作ったソース・コードは誰の責任か」ということを意識しないようにしています。

たとえどんなに優秀であっても、自分の締め切りは守るが1人で抱え込んで仕事をするような人は、このチームには向いていません。また、個人主義で自分のスキルや経験を他人に渡したくない、というような価値観を持つ人も不要です。しかし、筆者がこれまで仕事をしてきた中で、ペア・プログラミングをしたりノウハウを伝えることを厭（いと）うプログラマに出会ったことは、あまりありません。むしろ、優秀なプログラマほど、チームに貢献することの重要性を分かっています。