創業から13年。いまやSansanの社員数は600名以上に上り、直近では毎年約100名ずつ増えているという。だが、社員が増え、ビジネスの幅が広がれば、おのずと経営層などの上位役職者が決裁すべき案件の数は増えていく。万が一、意思決定のスピードが遅くなれば、ビジネスの成長を滞らせてしまうブレーキになりかねない。これも、同社がワークフローの在り方を抜本的に見直したいと考えた大きな理由であった。
「今後のビジネスの拡大を見据え、変化対応力に富んでいて、会社が大きくなってもスピードを落とさないでいられるワークフローを導入したいという目標を掲げました」と本山氏は語る。
Sansanは、ServiceNowのワークフローを導入する以前は、国内のシステム会社が開発したSaaS型BPM製品のワークフロー機能を利用していた。
しかし、このワークフローは承認経路の再設定やルール変更などの設定方法が非常に複雑で、「使いこなせる1人の社員が職人的に変更作業を行っていました」と本山氏は振り返る。これでは、その社員だけに変更作業が集中するため、組織の拡大や頻繁な組織変更に合わせて承認経路を柔軟に引き直すことは難しい。最低限の技術さえあれば、誰もが簡単に使いこなせるワークフローに変更したいと考えていた。
また、以前のワークフローはPCによる操作を前提として画面設計されているため、スマートフォンなどのモバイル端末では使いにくいことも課題であった。
「他の会社も同様だと思いますが、上位役職者は打ち合わせや外出などが多いことから、PCよりもスマートフォンなどを使って決裁する機会が多いのです。以前のワークフローのインターフェイスはPCに合わせて設計されていたので、無理やり画面を大きくして申請内容を確認したり、承認ボタンを探したりといった作業を余儀なくされていました」（本山氏） ただでさえ上位役職者には決裁が集中し、多忙になるため、なるべく作業の負担を減らし、スピーディに決裁できるUI、UXを備えたシステムが理想だ。もちろん、申請する社員の側にとっても、UI、UXの改善には業務効率化などのメリットがある。
これらの点を踏まえ、本山氏は複数社のワークフローを検討した。その中で、最も同社のニーズにかなっていると評価したのがServiceNowのワークフローであった。
本山氏は、ServiceNowのワークフローを選定した理由として、
①複雑なフロー設定やその変更にも柔軟に対応できるデベロッパーエクスペリエンス（開発者体験）が高いこと
②フロー上の申請および承認内容について、自由に意見やコメントが書き込めるコミュニケーション機能を備えていること
③モバイル端末に対応する優れたUI、UXが設計できること
の3つを挙げた。
組織変更に合わせて頻繁にワークフローを組み直すためには、開発のしやすいプラットフォームであることが何よりも重要だ。本山氏がServiceNowのデベロッパーエクスペリエンスの高さを評価した理由はここにある。
「他社のワークフローと比較したところ、ServiceNowのワークフローはAPI連携できる外部システムの幅が広く、開発の過程で不明な点が発生した場合は、解決方法を確認できるドキュメントも充実していました。さらに、ユーザー同士のコミュニティ活動も非常に盛んで、開発に関わる経験などの情報交換ができることも心強く感じました」（本山氏）
2つ目のコミュニケーション機能については、実は以前のワークフローにも同様の機能が搭載されており、活用していたという。
「以前のワークフローには、申請案件ごとの画面上にチャットのスペースが設けられており、承認に直接関わらない人にも『＠名前』を選んでメッセージを送れば、その案件に関する意見やコメントがやり取りできる仕組みになっていました。便利な機能だったので、新しいワークフローでも利用したいと考えました」と本山氏は語る。
そこで、ServiceNowならではの開発のしやすさが生かされた。ServiceNowのワークフローに搭載されているチャット機能に自社でカスタマイズを行い、以前のワークフローと同じように申請画面上でチャットによるコミュニケーションができるようにした。結果として、モバイル端末に対応するServiceNowのワークフローでUI、UXは向上し、自由な設計環境も手にすることができた。
