ユーザフレンドリーなSalesforce構築のために - 早期フィジビリティスタディのススメ - TECH BLOG

はじめに

みなさまこんにちは。

本日は、Salesforceをこれから導入しようとされている方々、すでにSalesforceを導入したがどうも思うように活用できていない、あるいはさらに他の分野でも活用したいとお考えの方々に向けて、考え方のヒントをご提示できればと思っています。

Salesforceは、ご存じのようにForce.comという極めて優れたプラットフォームを基本としています。 PaaSとして、さまざまなビジネスに広く適用できる、価値の高いクラウドサービスです。

一方で、ユーザー・インターフェース（UI）の表現力の面での不満の声はよく聞かれます。確かに、SalesforceのUIは、馴染のない方々にとってはとっつきにくい面があるように感じます。それはなぜでしょうか。

なぜ「SalesforceのUIは使いにくい」と感じられるのか

1990年代以降のクライアント・サーバ化の潮流、マーク・ベニオフCEOの言う"2nd Wave"の中で、日本企業のオフィスにおいてもPCでの業務が飛躍的に増加し、星の数ほどの業務システムが量産されてきました。そのほとんどはワンオフのフルスクラッチか、（大抵はコモディティ化した）特定業務に対するパッケージ製品です。そんな業務システムたちのUIには、規模も用途もバラバラであるにもかかわらず、実は暗黙的ながら比較的確固としたスタンダードが存在していると思っています。それは、「ツリー構造的な画面間の関係性」です。

メニュー画面から入り、業務をブレイクダウンしていく形で詳細画面へと遷移していく
画面間の階層構造が絶対的で、画面の遷移は先へ進むか後へ戻るかの2択がほとんど
業務の進行に合わせて、画面が遷移するよう最適化されている

こういった特色を持つ「画面のツリー構造」は、実はクライアント・サーバ時代に生み出されたものではなく、その前のメインフレーム時代からの遺産でもありました。オペレータが向き合う端末がWindowsベースでなく、メインフレームの文字通りの「端末機」であった時代から、この画面構造は「常識」であったと言えます。一つには、画面自体を一つ一つプログラミングして作らねばならないことから、極力プログラム上の分岐条件を減らしたいという事情もあったでしょう。ともかくも、この画面構造の常識は、もう何十年も受け継がれてきた伝統的なものであることは確かです。もちろん伝統的であることが悪、というわけではありません。実際この構造は極めてオペレーションフレンドリーであるという長所を持ちます。多くの場合、一業務に対してはそれぞれが最適化されているため、オペレーションする人は画面遷移に迷うことなく操作することができるのです。弱点としては、あまりに堅牢な構造であるため、業務プロセスに変化が起こったとたんに、改変を余儀なくされることです。しかも、システム全体の構造に変化を及ぼすにはあまりにも多大な労力を要するため、多くは新しいプロセスに合った画面を追加していくことになります。構築初期から時間が経つにつれ、画面の数は増え、ツリー構造の階層は深くなり......システム全体の複雑化は進行の一途をたどることが珍しくありません。一方、Salesforceの画面遷移の構造はどのようなものでしょうか。これまでの伝統的な構造を「ツリー構造的」と呼びましたが、対してSalesforceのそれは「ウェブ的な画面間の関係性」と言えると思います。ここで言う「ウェブ」はインターネットのテクノロジーと言うよりも、文字通りの「蜘蛛の巣」「網」という意味合いです。

常にタブが表示され、用意された画面にどこからでも遷移できる
画面間に階層構造がなく、関連する情報画面に遷移するルートが常に開かれている
オブジェクト間の関係性が、画面間の関係性にそのまま反映されている

基本的にはデータと画面が1対1になるため、データの一元性が保ちやすく、そのシステムが担うビジネス機能の全体最適が図りやすくなります。業務プロセスに変更があった場合にも、必要な情報に変化がなければ、画面の関係性を組み替える、ことによるとオペレーションの手順を変えるだけで対処が可能になる柔軟性が長所と言えるでしょう。その反面、ある画面に至るルートが基本的に一本化されている「ツリー構造」に対して、「ウェブ構造」ではルートが多数存在するということになります。画面遷移がそのままオペレーションのフローを表すことの多い、つまり画面に従って進めばオペレーションが完遂できる「ツリー構造」に比べ、遷移が固定されていない「ウェブ構造」ではオペレーションのフローに従ってオペレータが画面遷移をコントロールする必要がままあります。平たく言うと、自分がどの画面を開いているのか、どのルートを取れば目的の画面にたどり着けるのかを見失う......いわゆる「迷子」になりかねないということです。先ほど、「ウェブ構造」でいう「ウェブ」はインターネットテクノロジーのことでなく......という言い方をしましたが、こういった画面遷移を容易にした背景には、やはりHTMLがあると思っています。「ハイパーリンク」という概念が、画面遷移のハードルを大きく下げました。ウェブページ上のUIやUX（ユーザーエクスペリエンス）設計は未だ発展途上にあると思いますが、ルートを問わず画面遷移できるという概念は人間にはやや受け入れがたく、「迷子」の問題はウェブページデザイン上でも常に付きまとう、現在進行形の問題でもあります。ナビゲーションとして、「パンくず」や「フットパス」などと呼ばれる、デザイン上の階層構造をツリー構造的に表したハイパーリンクを表示する手法も、この問題への対処として比較的早期に登場した解決方法です。人間はやはり、ツリー構造の方が理解しやすいのです。しかしながら、ある画面が扱う情報と、その情報同士の関連性を把握できていれば、実はウェブ構造の方が効率は良くなります。いちいちメニューまで戻らずとも、目的地とそこへの連結点がイメージできているので、最短距離でたどり着くようショートカットできるからです。つまり、慣れ親しんでさえしまえばウェブ構造の方が使いやすい、という理屈なのですが、ニューカマーにはやはり優しくない。結果として敬遠されるままに慣れ親しまれない、使いにくい印象をぬぐえないので使われない......という悪循環に陥りがちなことも確かです。

ユーザを迷子にしないために

そこで、「この手順で進めば、オペレーションが完遂できる」という推奨ルートを作成する必要があります。テクノロジー的には「ウェブ構造」なのですが、「お約束」を作って「ツリー構造」的に扱う工夫をするわけです。このためには、単に「Salesforceを利用した業務フローの設計」を行うだけでは不十分でしょう。フローを完遂するにあたって、機能的な不足が実際にはなくとも、ユーザ側が暗黙的に期待している「オペレーションを完遂するための指示は画面が行ってくれる」という構造には必ずしもなっていないからです。 Visualforceを駆使して、従来のようなツリー構造の画面群を作り上げることは可能でしょう。極論すれば、従来型の要件定義を行い、全画面をVisualforceで個別開発してしまえばいいのです。しかしそれでは、Force.comの柔軟性、実装速度の優位性をスポイルしてしまいます。 Salesforceのアーキテクチャを採用する多くのユーザがSalesforceに期待しているところは、まさにこの柔軟性と実装速度の優位性にあるはずです。しかも、それだけでなく年3回の定期バージョンアップのたびに稼働担保を取るためのテストや改修が必要になってしまい、継続運用の簡便さまで失ってしまいます。これでは本末転倒と言わざるを得ないでしょう。もちろん、局所的には機能要件を充たせずにVisualforceで実装すべきところは出てくるはずです。しかし、それはあくまで最後の手段であり、原則的には標準機能での実装を中心に考えるべきでしょう。このジレンマ――標準画面中心ではユーザが迷子になりかねず、Visualforceで個別開発した画面を中心にしてはSalesforceアーキテクチャの優位性を損なう――を解消するにはどうすればいいのか。一つの解は、早期のフィジビリティスタディ（実行可能性調査）にあると考えています。

早期フィジビリティスタディのススメ

Salesforceを導入したい大まかな業務領域を見定めたら、その業務プロセスを分解し、ひとまず標準機能を用いてオペレーションをシミュレートできる環境を作ってしまいます（このシミュレーション環境には必ずしも有料のユーザライセンスは必要ありません。Developer環境でも十分機能するでしょう）。その上で、ユーザ側と開発側との双方が揃ってシミュレーションを実施し、その業務領域にSalesforceが適しているかどうかを見定めるのです。この際に気を付けるべきは、画面一つ一つの細部に拘泥するのではなく、「業務全体の流れ」がよどみなく行えるかどうかに主眼を置くということです。シミュレーション環境構築の際に、標準機能で賄えないことが明らかな部分は、「個別開発」するものとして置いておきます。このシミュレーションがつまり早期フィジビリティスタディなわけですが、その目的は標準画面での技術的な機能の限界を見定めるとともに、業務が流れるルートを明らかにして、エンドユーザへの「推奨ルート」として定義するところにあります。ここまでの作業は、望むらくは既に開発作業の一環となるいわゆる「要件定義」の前段階、計画段階で行っておくべきものです。 Salesforceアーキテクチャを用いてのオペレーション遂行のイメージができ、標準機能での限界点を見極められていれば、要件定義に入る段階では詳細な機能要件に論点を絞って議論が行えます。要件定義時点での誤解から生じる後々の手戻りや、ユーザ側と開発側の知識ギャップから生じる要件定義自体の紛糾も最小限に抑えられるのではないでしょうか。要件定義以降は、上で定義した「推奨ルート」のエンドユーザへの提示の仕方を具体化していかねばなりません。方法としてはいくつもあるでしょうが、大きくは実装上の工夫とルール作りの二つに分けられると考えます。実装上の工夫とは、たとえば表示するタブを必要最小限に絞ったり、あえて関連リストをレイアウトから外したり、最初に表示されるビューを固定したりといったものになるでしょう。標準画面の自由度をあえて制限することで、ルートを明確化するのです。ルール作りは言葉通りのものですが、推奨ルートの画面遷移図と画面マニュアルをセットにして、エンドユーザが行うべき画面手順を、エンドユーザ目線で丁寧に語ることです。単純に一つの画面を語るのではなく、その画面の前工程と後工程を意識できる体裁にすることが必要だと思います。

おわりに

冒頭に述べたように、Salesforceのアーキテクチャは非常に強力なPaaSとして機能します。しかしながら、私見では最も短期間に力を発揮でき、相対的に価値が高いのはSaaSとしてのありよう、Sales CloudとService Cloudであろうと考えます。なぜならこの2つのサービスはクラウドを利用したSFAとCRMの分野において、規模の大小を問わないスタンダードとして、連綿と蓄積されてきたベストプラクティスの結晶であるからです。コンピュータ・システムの洗練度、完成度だけでなく、利用のモデルとして想定されているプロセスそのものが、グローバル・スタンダードとしての価値を内包している――言い換えれば、ここまで述べてきた「推奨ルート」を既に内包しているのです。ただし、これもここまで見てきたように、UIとしては必ずしも「推奨ルート」が一目瞭然になっているわけではありません。そこがいわゆる「とっつきにくさ」につながるわけですが、ユーザの実情に合わせ、適度なカスタマイズでユーザの利用環境に「適応」させるだけで、その使い勝手は格段に上がると考えています。業務システムの開発、それが効果を表すためには、業務とシステムとの双方向の「適応」が不可欠です。 Salesforceのアーキテクチャは、検討の最初期から「動く環境」を用意できます。それは、業務とシステムの「適応」を模索するに際し、極めて大きなアドバンテージとなります。このアドバンテージを遺憾なく発揮させるために、計画段階でのフィジビリティスタディは大きな意味を持っているのです。