直接の対話を重視するクラウドの活用

直接の対話を重視するクラウドの活用

チームの人数を少なく維持するためには、ツールの活用は欠かせません。ARCでは、ツールも、クラウドで提供されるサービスを利用します。特に、IaaS/PaaSを活用してクラウドのサービスを提供するビジネスをする場合、エンドユーザーが利用するサービスのためにすら資産を持たないので、開発チームが利用する環境も、資産を持たずにクラウドを利用する形を目指しています。

そうすることで、さらにキャッシュ・フロー重視の、ベンチャーに向いた経営を行うことができますし、なるべく自分たちの本業以外はクラウドを使うことで、本来目指すべきゴールのために投資を集中させることができます。

SonicGardenでは、表1に示すクラウド・サービスを主に使っています。すべてクラウドで提供されています。シンプルなものが多く、フリーミアムで無料で試すことができるのもポイントです。

購入型のソフトウエアの場合は、一括で購入となるので、なるべく1つのベンダーから、使うかどうかは置いておいても、より多くの機能がついたものを選ぶ傾向にあったと思います。その方が、割引もしてもらえたからでしょう。しかし、クラウドで利用するようになると、多機能なものを選ぶよりは、シンプルで機能特化したものを選んで組み合わせて使う方が、良い効果を生んでいるように思います。

クラウドで提供されるサービスの良い点として、いつでも使い始めることができるという点のほかに、インターネットにつながればどこからでも利用できるという点があります。場所がどこでも構わないという点と、利用する端末のデバイスにも依存しないで利用できる点が重用です。

SonicGardenでは、カナダに1名スタッフがいますが、日々の業務は問題なくこなせています。また、外出することが多い営業担当は、iPhoneやiPadなどを使って社外からでも情報共有できるため、わざわざ移動して帰社する必要はありません。また、必要な機器はノートPCだけなので、個人で利用しているPCを使って業務をすることも可能にしています。クラウドだからできる新しいワーク・スタイルです。

ただし、SonicGardenで重視しているのは、作り手であるプログラマが顧客やエンドユーザーと直接対話することです。直接の対話といっても、実際に会いに行くというのではなく、youRoomやSkypeを使って行います。クラウドのツールを利用はしますが、プログラマが顧客やエンドユーザーと直接話をするようにしています。営業などが間に入って伝言ゲームをするのではありません。

そうすることで、プログラマ自身からの提案もできますし、顧客の生の要望を聞くことができるようになります。直接の顧客との対話は、プログラマのモチベーションも向上させます。以前までは、訪問して会うか電話するくらいしか直接に対話する手段がなかったため、効率を考えて、プログラマが動くのではなく、営業や別の担当者が仲介していたかもしれません。クラウドのツールを使うことで、その物理的な壁が崩れたのです。

表1: SonicGardenで利用中のクラウド

動くサービスを重視するマネージメント

ARCでは、顧客やエンドユーザーにとっての価値は「動くサービス」でしかないと考えています。いくら立派なドキュメントがあったとしても、実際に動かないものは何の価値もないと考えます。なぜならば、顧客が支払う対価であるお金や時間は、製品そのものに対するものではなく、利用している時間に対して支払われるものだからです。

納品型のソフトウエア開発の場合は、完成前に周到なテストを用意し、そのテストでの結果をもって品質確認を行っていたと思います。一方、利用型のクラウドのソフトウエア開発の場合は、ユーザーによって、継続的に利用されます。バージョン・アップも継続的に行われますし、ユーザー数の増加に応じてスケール・アウトしていきます。

そうした中で、より重視するのは、テストの再現性です。1度きりの納品ではないので、いつでもテストを実施できる状態でなければいけません。そのため、「テスト駆動開発」は欠かせません。自動で実行できるテスト・コードを用意するために、テスト・コードから先に作っていくのです。

前述の納品型で言うテストと区別するためにも、「BDD（ビヘイビア駆動開発）」と呼ぶこともあります。SonicGardenでは、BDDのためのツールとして、RSpecとCucumberを使っています。テスト・コードとしては、最近では特に後者のCucumberを重視するようになってきました。

クラウドのサービスでは、継続的にバージョン・アップを行っていきます。そうすることで、利用者が離れることを防ぐとともに、新しいユーザー層の獲得を狙っていきます。2005年当時に流行したWeb2.0での「永遠のベータ」と同じ考え方です。

あるところで完成、という形ではないため、WBS（Work Breakdown Structure）のような構造的な作業構造にするのは困難です。この点も、納品型のマネージメントをクラウドに適用しようとして失敗しがちな点です。「永遠のベータ」を続けるためには、実際に顧客に提供する価値となるストーリ（機能）を、順次開発していくというやり方が向いています。

作業にはよく、締め切りと何段階かの優先順位を付けますが、それはあまり意味はありません。必要なのは、どれくらいかかるかと、直列につながった優先順位だけです。プログラマたちは、並べたタスクを上から順に、なるべく早く実装していくだけのシンプルな管理で十分です。

長い期間にわたって、必要とされる機能を順次追加していくとしたら、大事なことは変更コストが上がっていかないようにする「変更容易性」です。このためには、2つの方針が考えられます。1つは「どんな変化が起こったとしても対応できるように見通して準備をしておく」という方針。もう1つは「なるべく身軽な状態にしておき、どんな変化が起きたとしても素早く対応できる構えをしておく」という方針です。

ARCのアジャイルでは、後者の方針を採用します。常に身軽でいること、そして、変化に対応できる準備をしておくことを、マネージメントの基本においています。そのためにも、クラウドを活用して資産レスであることや、テスト駆動開発やリファクタリングでソース・コードをシンプルに保っていること、Rubyの良さを生かしたプログラミングをすること、などを心がけるのです。

実際、変化を見通すことは困難です。システムだけでなくビジネス環境なども考えると、本当に将来の変化を予測できるかというと、現実的ではありません。そんなことができるのなら、誰でも大金持ちになっているはずです。