なぜARCなのか

なぜARCなのか

AgileとRuby（Rails）とCloudの組み合わせに「ARC」という名前を付けて、改めて考えてみると、筆者のこの数年の経験は、すべてARCの実践であったように思います。ARCに取り組み始めるきっかけは、2006年に筆者が書いたブログ記事「ディフェンシブな開発」と「改善型開発」まで遡ります。

・「ディフェンシブな開発 ～ SIビジネスの致命的欠陥」

・「改善型開発 ～ システムを作るのではなく育てるという発想」

「ディフェンシブな開発」では、システム開発業界に潜むビジネスモデルとしての課題を考察し、「改善型開発」では、その解決策としての今までの常識を覆す方法論を提示しました。そこで提示した方法は、「顧客とのプロジェクトの一番初めにリリースを行い、その後は、保守と改修を繰り返すことで、システムの改善を推進する」というものでした。当時は、それはただの妄想に近い仮説に過ぎませんでした。

ただ、「改善型開発」の記事の最後には、こんな風に書いています。

「重要なのは、なるべく早く動くものを作り上げるための技術、そして、作ったものを容易に変更するための技術である。また、システムの導入形態（デプロイメント）についても、考えなおすためのテクノロジーが必要となるだろう。前者については、Agileがヒントになり、後者については、SaaS（Software as a Service）の考え方がヒントになるだろう。」

この文章からは、今で言うARCがシステム開発業界の問題を解決する鍵になるのではないかという考えが見て取れますが、やはり時期尚早な感は否めませんでした。

では何故、今「ARC」なのでしょうか。前述の記事を書いた当時、まだアジャイルは一部のプログラマのものでした。しかし、アジャイル誕生から10年が経ち、長引く不況の影響や、IT投資の見直しが続くことなどから、外部環境の変化もあって、顧客企業にまでアジャイルという言葉が届くようになってきたのです。

また記事を書いた当時はよく言われていたのが、Ruby技術者の不足です。これも数年の時を経て、Ruby技術者が非常に増えてきた印象があります。そして、クラウドについても、ここに来て一気に普及が始まりました。特に、IaaS/PaaSと呼ばれるインフラ層を提供するサービスは出揃い、成熟しつつあります。つまり、業界を変える可能性を秘めたアジャイル、Ruby、クラウドというそれぞれの技術要素が実践期に入りつつあるということなのです。

特に、クラウドは技術としてだけでなく、ビジネスモデルとしても今までの業界と構造が違っています。図2に示したように、従来のシステム開発の世界では製造業を業界モデルの参考としてきました。お客様への納品という1点のゴールを目指してシステムをつくり込みます。顧客にとっては納品された瞬間が最高で、その後は変わらないシステムを償却するまで使い続けます。ハードウェアという箱もの重視の日本らしいモデルです。

一方で、クラウドの世界では納品がありません。ユーザはいつでも使い始めることができ、使いたいときに使いたいだけ使うというサービスです。システムの機能や品質は、利用する瞬間が常に最新で最高な状態になることが価値となり、「所有」ではなく「利用」という「形の無い財」の提供がクラウドのビジネスモデルです。前者の製造業での品質の考え方を「Point of Sales」と呼び、後者のサービス業での考え方を「Point of Use」と呼ぶようです。

"Point of Use"で大事なこと

筆者達が"Point of Use"でWebアプリケーションを開発し運用をしていく中で、重視している品質は、「継続性」と「保守性」です。

まず、サービスがダウンしないかどうか、という観点と、ユーザ数が増えた際にスケールアウトできるかどうか、という観点から「継続性」を重視しています。ユーザはサービスを利用してお金を支払うというビジネスモデルのために、サービスを止めずに提供し続けられるかどうかは、ビジネスを継続できるかどうかに直結しています。"Point of Use"では納品というタイミングがないため、ずっと開発も運用も続きます。そこにゴールはなく、安定して継続していくことが重要になってくるのです。

また、ユーザからの要望は使い始めてから必ず出てきますが、それに対応し続けられるかどうかも重要な観点です。いかにスピーディに改修していくことが出来るか、もしくは不具合を修正していけるか、そのためには「保守性」が高くないと実現できません。ビジネスをとりまく環境の変化についていけるかどうか、「保守性」の高さが鍵を握っています。

その「継続性」と「保守性」の高さを実現出来るのがアジャイル、Ruby、クラウドのARCです。