レベル: 初級 Dan Orlando, Enterprise RIA Consultant, IBM
2009年 9月 01日 SaaS (Software as a Service) アプリケーションをスケジュール通りに、そして予算の範囲内で作成し、行った投資に対して、期待通りの高い収益を実現する上で欠かせない 10 のヒントを説明します。
デスクトップ・ベースのアプリケーションではなく、オンライン・サービスとして提供されるソフトウェアの人気が急激な勢いで高まっています。私はこれまで SaaS を中心としたビジネスにいくつも関わってきました。その経験のなかで集めたのが、SaaS アプリケーションのソフトウェア開発に特有の 10 の重要な要素です。これらの要素が、SaaS アプリケーションが成功するかどうか、そして (多くの場合) リリースに間に合うかどうかの鍵を握ります。この記事では、SaaS 開発について大局を見通せるようになることを目的に、これらの 10 の要素に関するヒントを紹介します。
 |
よく使われる頭字語
- API: Application Programming Interface
- DTD: Document Type Definition
- UI: User interface
- XML: Extensible Markup Language
|
|
1. UXD を最も重要なアセットにすること
インターネットの出現によってユーザー・エクスペリエンスへの関心はすっかり消し去られていましたが、この数年の間、明らかにソフトウェアの成功において重要な特性となっているユーザー・エクスペリエンスに再び注目が集まってきています。ユーザー・エクスペリエンスへの回帰が明らかになったのは、Web 2.0 という言葉が初めて業界用語として使われるようになった頃のことです。Web 2.0 はやがて、より意味のあるリッチ・インターネット・アプリケーション (RIA) という形に進化しました。この記事で意図的にユーザー・エクスペリエンス設計 (UXD) を最初のヒントとして取り上げているのは、ユーザー・エクスペリエンスはアプリケーションの特徴をわかりやすく表しており、コンピューターのユーザーがある特定のアプリケーションを他に優先して選ぶ直接的な理由となるからです。
図 1 と図 2 に 2 つの興味深い UXD 手法を示します。図 1 では、ページを固定したまま処理を行う手法を示しています。これは Adobe® Flex を使って作成されたシン RIA クライアント・アプリケーションなので、いわゆるページはもちろんありませんが、それでもこの手法は有効です。この手法を使用した図 1 のシナリオは、ユーザーがその個人アカウント設定を変更するというものです。この UXD 手法では設定を変更するために現在のアプリケーションの状態 (つまり、ページ) を変えることはしません。代わりにオーバーレイ・ウィンドウを表示し、そこでユーザーが必要な変更を行えるようにしています。ユーザーがこのウィンドウを閉じれば、実行中のタスクに戻ることができます。
図 1. ページを固定したまま処理を行う UXD 手法の例
図 2 は、図 1 に示したウィンドウをクローズアップして表示したものですが、この図には 2 つの状態が示されています。このシナリオではさらに具体的に、ユーザーが Company Information の値を変更するために、該当するタイトル・バーを選択するという前提になっています。ウィンドウ 1 にはウィンドウが最初に表示された状態を示し、ウィンドウ 2 にはユーザーが Company Information バーをクリックした後のウィンドウの状態を示します。この手法は、パネルそれぞれのタイトル・バーが選択されたときにパネルが上下にスライドする様子がアコーディオンに似ていることから、アコーディオン・メニューと呼ばれています。この振る舞いはユーザー・エクスペリエンスを向上させます。というのも、多数の設定をカテゴリー別に分類しなければならない場合、アコーディオン・メニューを使えばユーザーが素早く簡単に特定の値を見つけて更新できるためです。
図 2. アコーディオン・パネル
|
人間とコンピューターの対話
Forrester Research が人間とコンピューターとの対話について行った研究では、被験者が複数のアプリケーションのなかから特定のアプリケーションを選ぶ第一の理由として挙げたのは、決まってユーザビリティー中心の理由でした。私が経験した SaaS プロジェクトのうち、成功したどのプロジェクトにおいても、初期プログラム設計プロセスで真っ先にユーザビリティー・テストが行われていました。なかには、静的画像ファイルを使ってサンプル集団からアンケートをとっていた企業まであります。これは、大々的なソフトウェアの見直しには相当なコストがかかるためです。設計およびプロトタイプを作成する段階で十分な対策を取っておけば、企業は何百万ドルものコストを節約することができます。さらに開発チームもこの段階で、開発の対象とする市場での人間とコンピューターとの対話の傾向や、性質、特徴、そして好き嫌いを特定することができます。
|
|
2. 要件の変更に適応すること
ソフトウェア開発でどうしても避けられないものが 1 つあるとしたら、それはクライアントやカスタマー、または製品の所有者が、設計、計画、ダイアグラム作成、プロトタイプ作成のすべてが完了した後に、プロジェクトの要件を変更することです。大抵のプロジェクト・マネージャーは従来からの方法論の訓練を受けており、その訓練には、変更に対する耐性を持つための訓練も含まれています。製品が最初の公式リリースに近づけば近づくほど、変更によって「大打撃を受ける」レベルは危険なほどにまで上昇します。
ソフトウェア開発は急速に進化しているため、初期の開発プロセス中に中核的なプロジェクト管理手法が何回か変わることも珍しいことではありません。したがって、どのプロジェクトでも、新しい開発手法や既存の手法のバリエーションを実装できるように準備しておいてください。
3. オープン・スタンダードを採用すること
SaaS をベースとしたアプリケーションを提供する企業は、オープン・スタンダードの採用を検討することが欠かせません。なぜなら、他のデバイスや、プラットフォーム、サービス、Web アプリケーションなどにも対応していれば、将来繰り返されるリリースでコーディングが少なくなること、そして製品がより多くの利用者に受け入れられることになるからです。利用者は、1 つで複数のタスクをこなせる SaaS アプリケーションに真価を認め、惹かれます。一例として、図 3 に示す TweetDeck は、1 つのインターフェースで Twitter とFacebook のオープン API を使用するクロスプラットフォーム・アプリケーションです。TweetDeck は最もよく使われている Twitter クライアントの 1 つとして急速に人気を伸ばしています。その主な理由は、Twitter ユーザーはアプリケーションを切り替えなくても、その Facebook の友達の近況アップデートを表示できるからです。
図 3. Twitter と Facebook のオープン API を使用する、人気の TweetDeck アプリケーション
| |
コミュニティーの力
ソフトウェア・プロジェクトが終了した後、そのソフトウェアを開発した企業や個人がオープン・コミュニティーに何らかの貢献を行うことは珍しくありません。貢献の内容は、特定の目的を達成するために必要なカスタム・コード・ライブラリーであったり、変更すれば他の場所で利用できる再利用可能なソフトウェア・コンポーネントのセットであったりします。このようなオープンソース・ツールへの絶え間ない貢献によって、技術が自由に、急速に、そして常に進化する環境が育まれています。
|
|
オープン・スタンダード・ベースのツールを使用することによって、ライセンス料金は不要になるため、ビジネスの金銭的コストを大幅に減らすことができます。さらに、一から作成する場合よりも有利な出発点に立てることから、リソースのコストも減ります。その分のリソースは、ビジネスのニーズと問題に対処する上で必要なソース・コードの変更に当てることができます。例えば Twitter と Facebook の API を作成するとなると厄介な作業になるはずですが、TweetDeck の作成者たちがこの作業を行う必要はありません。そのため、彼らはユーザー・エクスペリエンスに大きく影響する機能をアプリケーションに組み込む作業に専念できるというわけです。
Twitter と Facebook が API の使用料を請求したとしたらどうなるでしょうか。その場合、TweetDeck は Twitter と Facebook に API 使用料を支払うために、利用者に毎月の使用料を請求することになるでしょう。あるいは、ユーザーは TweetDeck アプリケーションを使用するためだけに、Twitter と Facebook に月々の料金を支払わなければならないことも考えられます。その結果、TweetDeck、Twitter、Facebook には好ましくない影響がもたらされ、TweetDeck はもはや成功した SaaS アプリケーションとはみなされなくなるはずです。
4. 設計の前にワイヤーフレームを作成すること
ワイヤーフレームとは単に、ソフトウェア・プログラムの具体的な UI の状態を機能の観点から概念的に可視化したものです (図 4 を参照)。ワイヤーフレームに手の込んだデザインは必要ありません。ワイヤーフレームの目的は、設計要素に気を取られることなく、ビジネス機能に焦点を据えられるようにすることです。アプリケーションのビジネス機能が確立された後は、設計チームがアプリケーションの設計を開始できますが、ソフトウェアの外観に手を付ける前に、まずはソフトウェアを機能させることが先決です。
図 4. UI の概念を可視化するワイヤーフレーム
この一面は、SaaS 成功の第一の要素である UXD に密接に結びついています。ワイヤーフレームの作成と UXD の違いは、SaaS を成功させるためには、ソフトウェア開発の概念設計から実動に至るまでのライフサイクル全体で、UXD が常にプロセスに含まれていなければならないことです。ワイヤーフレームの作成に関しては常々、SaaS を不備なものにする以下の 2 つの誤りが見受けられます。
- 利害関係者たちが見たがっているのは、機能するものではなく、見栄えの良いものであるという理由で、チームが時期尚早に設計に取り掛かり、ワイヤーフレーム作成プロセスの一環として急遽、アプリケーションの設計テーマを作成し出すこと。
- アプリケーションの重要な状態がワイヤーフレームに含まれていないこと (つまり、アプリケーションが部分的にしかワイヤーフレームに取り込まれていないこと)。
興味深いことに、この SaaS を不備なものにする 2 つの原因のうち、2 番目の方は SaaS プロジェクトにとりわけ大きな弊害をもたらします。ワイヤーフレームの最も魅力的な点は、ワイヤーフレームを頼りに、包括的な製品要件のなかで足りない部分を顕在化できることです。ワイヤーフレームは、コアとなるアーキテクチャー設計の欠陥を、開発が始まる遙か前に明らかにするものとして知られています。その点を考えると、ワイヤーフレーム作成プロセスが完全なものであることを確実にすれば、ビジネスにとって時間とリソースという点でかなりの節約になることを想像するのは難しくありません。
完全なワイヤーフレーム一式には、100 以上の文書が含まれることもあります。それぞれのワイヤーフレームには、少なくとも 1 ページから 2 ページの説明を付けて、利害関係者がワイヤーフレームを精査するときに何を見ているのかを理解できるようにしてください。これらのワイヤーフレームは、利害関係者によって承認されるまでに改良の必要があるでしょうが、機能をコーティングした後に問題が見つかるよりも、ワイヤーフレームの作成中に問題を明らかにしたほうが得策です。
注: ワイヤーフレーム作成プロセスで UI を定義した文書の一式は、設計プロセスが始まった後、ピクチャー・ブックと呼ばれることもよくあります。
5. SaaS にはクラウド・インフラストラクチャーを提供すること
ネットワーク・インフラストラクチャーが SaaS の成功または失敗を決めると言うと、はじめは当たり前のように思えるかもしれません。けれども Web 上にあるほとんどの SaaS アプリケーションは、オンデマンドでスケーリングすることのできないインフラストラクチャーに縛られた、力量不足のハードウェアで実行されています。開発者としての私たちは、IaaS (Infrastructure as a Service) とも呼ばれる自らスケーリングできるクラウド・システムにアクセスできるものの、この優れた技術の導入は驚くほど遅れています。
この導入の遅れは、主にクラウド・インフラストラクチャーについての知識不足に起因している可能性があります。SaaS アプリケーションを実行するビジネスにとって、例えば Amazon EC2 (Amazon Elastic Compute Cloud) は莫大な節約となる可能性があります。しかし AWS (Amazon Web サービス) インフラストラクチャーに関する全般的な知識の欠如が原因となり、ほとんどのビジネスでは、すでに理解しているという理由でレガシー・システムに頼っています。その一方で、ISP によって提供される帯域幅は絶えず増え続けており、SaaS アプリケーションが成功すれば、オンデマンド・リソースを自動的にスケーリングするために一層高度なネットワーク・パフォーマンスが必要となってくることは確実です。
6. コードの作成に取り掛かる前に、完全な設計文書を作成すること
適切に動作するソフトウェアは、うまく進んでいるビジネスと同様、(開発プロセスの) 計画段階を十分重要視しており、これが SaaS アプリケーションを提供する企業として成功している企業の主な特徴です。高品質の設計文書は、設計を行う担当者にとってロードマップの役割を果たし、ソフトウェアのコードを作成する時間を大幅に短縮する可能性を秘めています。こうした理由から、成功する SaaS アプリケーションは一般に、スケジュール通りに、しかも予算内で完了するプロジェクトとなっています。
SaaS アプリケーションがスケジュールよりも遅れ、予算を上回ってくる場合、それはプロジェクトのアーキテクチャー設計の方針が十分に伝わっていないことが原因となっています。コードの一貫性を大規模な SaaS アプリケーション全体で維持するためには、適用可能な設計パターンと規約の完全な一式を確立し、効果的に開発チーム全体にその情報を行き渡らせることが欠かせません。そこで、設計方針を周知させる極めて効果的な方法となるのが、視覚野を利用した方法です。
視覚野を利用する
これまで 100 年の間行われてきた人間の思考と学習についての膨大な数の臨床研究では、人間は五感のうちの複数が学習プロセスに関わってくると、より短時間で学習できることが示されています。聴覚に加え、視覚が関わると、人間がその対象を覚える速度は約 7 倍近く速くなります。このことから、技術ソフトウェア文書では図やフロー・チャートのような視覚的な手掛かりが非常に効果的であるのもうなずけます。
図 5 に示すように、ソフトウェアのアーキテクチャー図とマイクロ・アーキテクチャー図は、RIA クライアントの基礎を確立して表現するのに便利な手段となり、開発チームがコードを編成するときに従う概要となります。これらの図は、構造という観点から見た一連のガイドラインおよび期待される内容も確立します。
図 5. プログラムの構造設計パターンを大まかに示す概要図
フロー・チャートも、プロセスや一連のイベントの流れを伝えるには非常に便利です。多くの場合、創意工夫を凝らせば凝らすほど、フロー・チャートはより効果的になります。図 6 は、オープンソースの Flex 対応 Swiz Framework が IoC (Inversion of Control: 制御の反転)、オブジェクト・イントロスペクション、依存性注入を実装する方法を視覚的に表現するために使用しているフロー・チャートです。これを見ると、フロー・チャートにどのような工夫が採り入れられているかがわかります。
図 6. オープンソースの Flex 対応 Swiz Framework のフロー・チャート
これまで方法特許を書く手伝いをしたり、申請を行ったり、あるいは何らかの形で方法特許に関わった経験があるとすれば、図 7 には馴染みがあるはずです。これは特に、複数の可能性を有するプロセスやメソッドを示す場合に効果を発揮します。その好例は、多数の機能が関連し、そのうちの一部には if - else や switch 文など、1 つ以上の条件が含まれるプロセスです。機能説明図は、技術的なビジネス・プロセスとソフトウェアを概説するには極めて重宝します。例えば、コードを企業の中央ソース・コード管理リポジトリーにコミットするプロセスを概説する場合などには、このタイプの図が最適です。
図 7. 条件付きプロセスまたはメソッドを段階的に説明する機能説明図
7. ユニット・テストにこだわること
一般に SaaS の最有力候補となるのは、大勢の開発者によって作成されたかなり大規模なアプリケーションです。大規模なアプリケーションの場合、ユニット・テストとの関係を表すデータは一貫しています。それは、ユニット・テストを後からの思い付きで実装したプロジェクトは悲惨な結果で失敗するということです。それとは逆に、成功している SaaS の場合、開発者はコードを作成する前にユニット・テストを作成し、さらには作成したユニット・テストを実行さえします。例えば、ServiceController というクラスを作成するという任務を課せられたとします。私は最初にこのクラスのコードを作成することはしません。代わりに、このクラスに含まれるメソッドに対してすべてのユニット・テスト・ケースを実行するクラスを作成します。実際にはクラスのコードを作成していないので、テスト・ケースは失敗することはわかっていますが、それでもさらに念を入れて、テスト・ケースを実行してみるはずです。
この段階でテスト・ケースを実行する目的は、常にテストにパスしてしまうようなバグが実際にユニット・テストに潜んでいる可能性を排除することです。異例なことに聞こえるかもしれませんが、このようなバグが気付かないうちに入り込んでしまうことは珍しくありません。しかし、すべてのユニット・テストに失敗すれば、実際のコードの作成に取り掛かれる状態であることがわかります。そして新しいクラスの作成が完了した時点で、もう一度ユニット・テストを実行するというわけです。すべてのテスト・ケースにパスするようであれば、新しいユニット・テスト・クラスをユニット・テスト自動化ライブラリーに追加し、すべてのビルドで実行させます。つまり、アプリケーションのために作成するユニット・テスト・ライブラリー全体が、私のビルド・プロセスの一部となるということです。実際、私はプロジェクトの構築を始める前から、すべてのユニット・テストを実行して、アプリケーション・コードの完全性が気付かないうちに損なわれていないことを確認しています。
私がプログラミングの世界で知っているなかで、このプロセスを徹底して実践している開発者はほんの少数しかいません。しかし彼らはこの業界で最も尊敬を集める高名な、そして高給取りの開発者として数えられています。昇給または昇進の近道を探しているのなら、ユニット・テストにこだわってください。
| |
不可解な日付変換機能の事例
私のある同僚が、日付の計算と変換を行って「先週」、「昨日」といった語句を表示する関数のコードを作成する前に、その関数のテスト・ケースを作成しました。テスト・ケースを完成した後、彼は関数のコードを作成し、そのコードに対してユニット・テストを実行したところ、不思議なことに、午前 0:01 から午後 11:59 にわたりテストを実行するとメソッドはテストにパスしましたが、正午から午前 11:59 にわたって実行するとテストに失敗しました。
ここで大きな疑問となるのは、このユニット・テストが一貫して毎時繰り返し可能なテストでなかったとしたら、このバグは発見されていただろうかという点です。定期的な手動でのテストでバグを見つけることは可能だったのでしょうか。それとも QA チームがバグを見つけることになるのでしょうか。いずれにしても、事の真相は、このアプリケーションはバグが含まれたままカスタマーに引き渡されていた可能性があったということです。アプリケーションがそのまま本番に移行されていたとしたら、約 15 年間のカスタマーとの関係は台無しになっていたかもしれません。
|
|
8. モグラ塚 (些細なこと) にこだわるのではなく、大きな山に挑むこと
パフォーマンス・ボトルネックの可能性は、デスクトップから実行される「シック」クライアント・アプリケーションでの場合に比べ、SaaS アプリケーションでは遙かに大きくなります。熟練プログラマーでさえも、SaaS アプリケーションとなると、関連するさまざまな可変要素のためにパフォーマンスのボトルネットを予測するのは難しい場合があると認めるはずです。SaaS アプリケーションが成功するか、失敗するかを左右するのは、開発チームが負荷テストとプロファイル作成を行っている間に、悪影響を及ぼすパフォーマンス・ヒットにどう対処するかです。
一般的には、パフォーマンスの最適化には 2 つのタイプしかありません。1 つはパフォーマンスに目立った影響を与える最適化、もう 1 つは顕著な成果はなさそうに見える最適化です。この 2 つの中間に位置する最適化はまれにしかありません。このことに関してよく使われる例えは、山とモグラ塚です。大抵、開発者はアプリケーションの実行中にコンピューターのプロセッサーやメモリーの能力を台無しにする山のように大きな問題に取り組むのではなく、パフォーマンス向上のために割り当てられた作業時間の大半を、モグラ塚を踏みつぶす (些細な問題に対処する) ために費やしています。ここでプログラマーとして気を付けなければならない重要な点は、モグラ塚に気を取られすぎて、大きな山が見えなくならないようにすることです。
モグラ塚に気を取られないようにするための最も簡単な方法は、アプリケーションのプロファイルを作成することです。プロファイルの作成は、アプリケーションでのシステム・リソースの使用方法を最適化する機会となるため、SaaS プロジェクトの成功にとって重要な作業となります (図 8 を参照)。アプリケーションのプロファイルを作成するときには、アプリケーションのどの部分が最もリソースを奪っているかを厳密に見極めることができ、パフォーマンスを向上させるための設計パターンを実装することができます。例えば、必要なガーベッジ・コレクションが行われずに大量のオブジェクトが再インスタンス化され、それによって、アプリケーションを実行している限り絶えずメモリーが食い尽くされていることがわかったとしたら、プロキシーを使用してオブジェクト・プールを実装する必要があることがわかります。
図 8. Eclipse でのアプリケーションのプロファイル作成
9. 成功を収めた他の SaaS プロジェクトから学ぶこと
他の成功した SaaS プロジェクトから学ぶ最も簡単な方法としては、まず、すでに活用している SaaS プログラムを選びます。次に、選択したソフトウェアと競合関係にあるソフトウェアを 2 つか 3 つ見つけ、これらのソフトウェアを実際に使ってみながら、興味を引かれた点、そしてそれぞれのアプリケーションを気に入った理由、あるいは気に入らなかった理由に関連する点を書き留めます。
私がアプリケーションのユーザビリティーとパフォーマンスに興味を引かれることはまれなので、これらの点に関して気付いたことがあれば、時間をかけてその理由を探るようにしています。それによって、大抵は何かを学ぶことができるからです。最近私が興味を持ったのはタスク管理アプリケーションです。その理由は主に、このアプリケーションの分野はむしろありふれていると思ったからですが、この特定の SaaS アプリケーションに関するユーザビリティーのレベルは驚くべきものでした。
このアプリケーションを約 2 時間かけてナビゲートし、その限界をテストするとともに、さまざまな機能のアクセシビリティーを評価しました。私は、とてつもない数の機能が組み込まれているアプリケーションを好みますが、それと同時にかなり軽量なアプリケーションであることも期待します。だからこそ、私は UI 設計に口やかましいのです。インターフェースが上手く編成されていなければ、多くの機能を備えたアプリケーションを使用するのは悪夢のような体験になってしまします。探している機能を見つけるには 30 分あっても足りないからです。この特定の SaaS アプリケーションを評価した結果、これまで私がインストールしたことのある他のタスク管理アプリケーションと比べ、UI の編成が独特で型にはまっていないことが、このアプリケーションを操作しやすくしている理由だという結論に至りました。
10. 後で使用可能なプロトタイプを作成すること
プロトタイプを作成するために使用したコードを最終製品でも使ったとしたら、それでもまだ、そのプロトタイプはプロトタイプと言えるでしょうか。
この質問に対する答えは、もちろんその通り、となります。ソフトウェア開発では、カスタマーは通常、実物の開発に投資する前に概念実証を目にしたいものです。プロトタイプは概念実証以外の何ものでもありませんが、賢い SaaS 開発者はプロトタイプを作成するために与えられた時間を活用しています。この期間に、どれだけのことをできるかを考えてみてください。
- アーキテクチャーの基礎を設計し、レイアウトする。
- カスタム XML DTD を作成することで SaaS データベース・スキーマを作成し、XML をプロトタイプのデータ・ソースとして使用する (スキーマを後でデータベース・エンジンにインポートすれば、ものの何分かで実物に変換することができます)。
- ファイルで宣言されているのが、クラス名と、そのクラスが最初に実装するインターフェースだけに過ぎないとしても、実際と同様のアプリケーションの構成パッケージ、インターフェース、クラス構造を作成する。
この手法にはいくつもの利点がありますが、そのうちの 2 つが SaaS 成功の鍵となります。1 つは、実際の製品を作成する段階で、かなり先んじたスタートを切れることです。そしてもう 1 つは、矛盾する設計パターンと不完全に設計されたアーキテクチャーは通常、その設計パターンとアーキテクチャーをベースにプロトタイプを作成するなかで、それぞれの醜い顔を表してくることです。そのため、実際の本番開発を始める前に、必要な変更を行うことができます。
まとめ
ソフトウェア開発の世界は急速に進化しているため、SaaS 開発の成功を握る主要な要素も、おそらく意外に早く変わってくることを覚悟しておいてください。成功の秘訣は、常に進化のプロセスを把握しておき、時代の変化の一歩先を行く態勢を整えることです。
参考文献 学ぶために
製品や技術を入手するために
議論するために
著者について | 
| | Dan Orlando はエンタープライズ規模の Flash プラットフォームに関するアーキテクト兼コンサルタントとして広く認められています。彼は RIA 支持者として、さまざまな雑誌や Web サイトに記事を発表しています (PHP Architect、Flash and Flex Developer Magazine、IBM developerWorks、Amazon Web Services、Adobe Developer Connection など)。また彼は『Flex 4 in Action』(Manning Press 刊) の共著者でもあります。 |
記事の評価
| 
