株式会社富士通ソーシアルサイエンスラボラトリ

Ruby on Railsを使用してサービスレベル向上

株式会社SSLパワードサービス(以降SSL/PS)ではITILに準拠したサービスデスクを展開している。

システム開発ベンダーなどに代わってSSL/PSがカスタマーサービス業務を行うもので、電子メールや電話による問い合わせを24時間365日受け付ける。マニュアルやFAQ集に沿って対応が可能な内容についてはそのまま回答を行い、未知の問題や、特に高度な対応が必要な問い合わせについては開発元へエスカレーションする。

株式会社富士通ソーシアルサイエンスラボラトリ(以降富士通SSL)は、こうした業務を行っているSSL/PSに向けたサービスデスクシステムを開発した。今回はサービスデスクシステムを運用しているSSL/PSと、その開発元である富士通SSLにお話をうかがった。

業務プロセスの変革を押し進める

サービスデスクシステムは、業務効率化に加え、サービスレベルを確保し、顧客満足度を高めることを目的として開発された。 従来、SSL/PSでは複数のツールを組み合わせることでサービスデスク業務を行っていた。サービスデスクシステムを導入することにより、いくつものツール群の中でバラバラに実装されていた業務機能を統合するとともに、さまざまな形態で格納されている業務データの一元化を実現する。 また、それらを背景にして操作性の高いシステムを構築し、対応の遅延を起こりにくくしたり、新たなサービスの立ち上げを早くするなど、業務の効率化につなげる。定められた時間内に一次回答を行うといった、お客さまからの要求に確実にこたえることを担保できるシステムを目指した。

アジャイルによる開発

サービスデスクシステムは、SSL/PSによる業務全般にわたる広い範囲をカバーする必要があった。 すでに展開中の業務であるから必要な機能は何かというのは明らかであったが、それらをどのように実装しどのように構成すれば十分に機能を果たすことができ、なおかつ使いやすいシステムになるかという面ではその全容が明瞭であるとは言えなかった。

「作るものの詳細まで仕様書に落とし込んで構築を行うウォーターフォールよりも、実装案を都度お客様に見て頂きながら、また、実装の優先順位を考慮しながら開発するアジャイル開発が向いているのではないかと考えた。」(富士通SSL)

ルールに則ることで開発効率を高められるRails

社内にアジャイルによる開発の知見が十分にあったこともアジャイルを選択した要因の一つだ。今回の開発を担当した技術者もアジャイル開発プロジェクトに参加した経験を有するメンバーだった。特にその中でもRailsを採用した案件の経験があり、テストツールや、各種部品も豊富にあり、カスタマイズ性も高い等、使いなれてしまえば効率よく開発できるとの手ごたえを得ていた。

また、2013年頃からRailsを使った開発などを行っていたこともあり、ちょうどRailsの仕組を使って何か開発できないかと考えていたところにこの案件がきたことでRailsの採用を検討した。

「Railsは、Java、PHP、.NETなどの様々な言語を扱ってきた中で出会った一つ。今回のケースに合うものにどれがいちばんいいか選択した結果がRailsだったと考えている」(富士通SSL)

Railsを含むOSSを用いて開発するシステムを提案するにあたっては「サポートが不安である等、OSSを利用することに抵抗があるかもしれない」との懸念もあったが、SSL/PSに相談してみたところ「まったく問題はない。富士通SSLの技術力を信頼している。万一問題が発生したとしても何とかしてくれるでしょう」ということで今回の構成に決まった。

ユーザと開発者で共につくり上げる

2014年4月に開発に着手し、それから3か月後の2014年7月には最初の本番投入が行われた。引き続き段階的に機能が追加されていき、2015年3月には必要な機能をそろえられた。  全体的な仕様は事前に決めてあったが、それはおおまかなものに留められた。おおむね二週間に一度くらいの頻度でSSL/PS向けにデモを行い、よければ採用する、コメントがあれば取り込んでいく、というアジャイルのサイクルを繰り返すことで、詳細な仕様を決めていくとともに実装を進めていった。このサイクルは現在も続いている。

 

「日々のやりとりの中から吸い上げた要求を形にしてきてくれる。発注したら後は待っているだけ、ではなく、一緒になって作っている気持ちだった」(SSL/PS)

 

当初、SSL/PSにはアジャイル経験はなかったが、アジャイルではこのようなやり方するんだ、といったやりとりを交えながら開発を進めていった。

 

「リリースするたびにたくさんの要望が上がってくる。サービスレベルを上げるためにはこういうことが必要だといった問題意識が非常に高い方達なので、アジャイルを用いた開発がまさにフィットしたと思っている」(富士通SSL)

実際に大小さまざまな要望が出たが、様々な事情からすべてに対応することはできない。それぞれの要望に優先度をつけて、必要なものを実装していくという取捨選択はどうしても必要となる。それでも「アジャイルでは少なくともユーザと開発者が一緒に検討することができる。結果的にすべてを採用することはできなくても最終的にユーザの納得いく形に持っていけた、時にはこちらの想定を越えたものができたこともあって、最初にイメージしていた通り、いえ、それ以上のものができたという実感がある」(SSL/PS) 

Ruby/Railsを採用した効果

Railsを採用した効果は期待通りだったといえる。開発を続けていく中で調査を行うにあたり、参考にできる情報がネット上に多くあった。書籍も充実している。機能を実装するときには利用できそうなgemがいくつもあって選択できる。さらには言語やフレームワークの標準の動きが要件にあわない場合でも機能の拡張が容易であり、柔軟に対応することができたため効率よく開発を進められたそうだ。 gemなどの外部の資産を活用する際には機能面だけでなく、活発に更新されていることなども条件の一つとした。何年も前の時点で止まっているものは良い悪いという前に動かないものも少なくない、ため採用はきびしい。ただし、要件が固まっていて今後変化がない部分については1〜2年程度であれば古くてもよしとした。それは最終的には自分たちが面倒を見るとの考えがあったからだ。

「要望があるたびに、これがいいかな、こうしたほうがいいよね、といった実装方法の検討に加え、様々なツールを探し回って、その中からベストなものを提案する。それでOKをもらったときの満足感はすごく高かった」(富士通SSL)

「Ruby on Railsは、アジャイル開発のように段階的な開発を行うためのサポート機能が多く用意されているため、今回の開発を効率よく、かつ柔軟に進めることができた。その結果としてユーザにも満足いただくことができ、開発者としてとてもやりがいのあるプロジェクトだった」(富士通SSL)

※本事例に記載の内容は取材日時点(2015年9月)のものであり、現在変更されている可能性があります。