SaaS開発ほど面白いものはない - 要件は自社の仲間が決める
MixiやGree、そしてFace bookなどのSNSサービスが最近脚光を浴びている。そういうサービスも、オンライン上で提供されるものなので、広い意味ではSaaSと呼ばれて良いのかもしれないが、わたしがSaaSという範疇にいれたいのは、やはり企業が使う業務アプリケーションに限りたい。
代表的アプリケーションは、給与計算、勤怠管理、会計処理、顧客管理、営業管理などかと思う。それらが代表的と言えるのは、企業によって処理の違いがそれほどないことや、企業の業務の中で外に出しやすいことなどからか、と思う。
まだまだSaaS化されていない企業業務は山ほどあるわけで、SaaSがブレークした昨今、SaaSで処理できる企業業務はこれからもどんどん広がっていくことだろう。ベンチャー企業にとって絶好のチャンスだと思う。ところで、業務開発技術者にとってもSaaSの開発ほど、開発者冥利に尽きるものはない。その辺りの理由を、何回かに分けて、書いてみたい。
■要件は自社の仲間が決める
通常の受託開発では、要件定義、基本設計など膨大なドキュメントを書き、書き上げたものについて顧客にサインを強いることになる。顧客にとっては、まだ見たこともないアプリケーションを頭の中だけで作り、『ドキュメントで書かれた内容から逸脱するようなことを、万が一作る必要があれば、そのときは追加料金をいただきます』、と言われながらサインするわけで、プレッシャーの大きさは尋常なものではないだろう。
人間は完璧ではない。どうしても、細かい見落としなどが発生するだろう。サイン後に変更が必要になることはほぼ必須で、そのたびに追加費用が発生し、社内で追加予算の稟議を通す手間をかけることになる。
開発する側も、プログラマは普通、自分の腕を顧客に認めてもらいたいものである。最初にスコープとして決められた内容から逸脱する内容だとしても、もしそれが簡単と自分で分かっているなら、無償で実装して上げたくなるものだ。しかし、普通それは許されない。
正式な交渉を得て、実装について決め手いくことになる。この時、交渉ごとの基本であるが、交渉当事者間の知識量に大きな差がついている時には、より大きな知識をもつものが、その交渉を有利に持って行く事ができるわけで、こういう場合、開発する側が持つ知識量が当然大きい。プロジェクトマネージャはそれを利用しようとする。
このようなドキュメントにより発注側、要件定義側間の契約を明確にする方法は、程度の差はあれど、受託開発である限り絶対必要なものである。
ところが、自社で要件定義を行うことができれば、こんな面倒くさいことに惑わされることはない。SaaS開発なら、要件を決める人は、開発するシステムの分野の専門家。給与計算なら、ベテラン社会保険労務士、会計処理なら、会計士などになるが、あくまでも社内の仲間である。
もちろんこの専門家、簡単なことから、無理難題までいろいろと言ってくるだろう。簡単なことなら、彼にとって難しいだろうなと思うことを、『わたしの技術力のお陰で、こんなに短時間で実装できました』と、感謝させればよいだけだ。変更があることをあらかじめ予測して、実装する部位を簡単に切り替えることができるような作りにしていれば、簡単に、かなり大きな変更を実装できることになる。こういう時が、技術者冥利に尽きる時、だろう。
この時、注意するべきは、アジャイルの思想に、”you never use it”というのがあるが、変更があることを予想しすぎて、必要以上にコードを難しくすることは避けてもらいたい。アジャイルの方法論では、変更があり、その部位が変更を予想した作りになっていなかったとしたら、まず、その部分を変更を入れやすい作りにすることから始めることになる。そのことをリファクターと言う。リファクターまでは、コードの振る舞いは一切変わらず、実装だけが変わり、変更が容易な形になるだけである。その後、おもむろに変更が容易になった仕組みを利用して、必要な変更依頼を実装するのである。
ここでアジャイルという言葉が突然出てきたが、要するにSaaSの開発はおのずとアジャイルの方法論を使うことになるという意味で、使った。例えば、今議論している内容は、アジャイルのプラクティスでいうところの、『オンサイト顧客』 と同じことになる。
次に、依頼されて変更が難しいことと分かった場合。いろいろと説明して、あきらめてもらうなり、十分な時間をもらうようにすることになる。この時、誤解してもらいたくないことが1つある。難しいことの定義である。変更を入れる箇所は小さいが、それが与える範囲が広範囲に渡るので、危険すぎて変更できないというケース。この時は難しくないと、判定するようにしてもらいたい。リスクを無視しろと言っているのではない。リスクが極小になるような仕組みを、実装のなかに、常日頃から入れておく必要があるということである。
もっと抽象的な言い方をすれば、変更のサイズを、数値で表す場合。(変更料) ×(難易度) ×(リスク) の計算式で計算することになるが、この時のリスクのファクターが極小になるような仕組みを、必ず盛り込むということである。
具体的には、自動レグレッションテストコードを、常にコード作成と同時に作っておき、それを常にメンテナンスしておくこと、である。わたしはアジャイル開発で最も重要な思想はTDD（Test Driven Development）のプラクティスだと思っている。この辺りまた、別の機会にコラムとして書こうと思うので、その時に譲ることにする。
ちなみに給与計算や、会計処理などの計算系のアプリケーションで、変更がそのビジネスルールの実装の場合、比較的簡単にレグレッションテストが行える。ある程度のパターンの入力データを準備し、変更前と変更後で、その計算の結果が変わらないことを確認してやれば良いのである。わたしが経験した最初のSaaS、その当時はASPと呼ばれていたが、は給与計算で、そのうまみをフルに使うことができた。例えば、日割りの遡及機能が必要になり、エンハンスしてその機能を実装するとして、遡及の必要のない元データのまとまりを準備して、それを使って変更前の計算。その後変更後のコードで計算、結果が一致していることを確認。そのあと、遡及が必要な給与計算の入力データを、すべのパターンで準備して確認。もちろん新たに追加されたこの部分は手計算で計算があっていることを確認しなければならないが、次にまた別の変更をを入れるときは、もう必要はない。
しかし、最近のSaaSもどんどんUIが高度化しているが、UIのコードを自動テストの対象に入れるのは至難の業である。Web上での操作そのものをsimulationする形の自動テストツールもあるが、まだまだ使いにくいということが本当のところだろう。最近の動きは、その方向のテストはあきらめて、MVCパターンなどを利用して、UIロジックとApplicationロジックが明確に分かれるような作りにし、application ロジックの部分だけを自動テストの範囲として、UIロジック、普通はbusinesss層から来たものを単に1対1で表示するだけの非常に簡単なロジックの自動テストは行わないことだ。
技術者、特にプログラマにとってもっともうれしいことは、人がほしがっている機能を、簡単に実装してやり、業務の専門化に感謝され、さらに仲間のプログラマの尊敬を受けることである。少々給料が安くとも、それほどうれしいことはない。