株式会社日立ソリューションズ
自社パッケージ製品のWebアプリケーションとメールフィルタ機能をRubyを用いて、即行マイグレーション!
オフィスで最も活用している連絡手段といえば「メールだ」と答えるビジネスパーソンは多いだろう。それだけ普及したメールだが、便利である反面、誰でも簡単に送信できるという一面もあり、誤送信による重大な企業情報漏洩につながる可能性も秘めている。そこで株式会社日立ソリューションズでは「活文Enterprise Mail Platform(旧名称:留め〜る)」という誤送信防止のためのソリューションを提供している。製品開発に携わる、日立ソリューションズの肥後様、中西様にお話を伺った。
誤送信による企業情報漏洩
一度でも情報漏洩を起こしてしまうと、信頼失墜による経済損失は非常に大きなものとなってしまう。「活文Enterprise Mail Platform」を開発することになったのも、プライバシー保護や危機管理意識の向上などによる、誤送信防止に対する企業ニーズの高まりからだった。
「長年、メールシステムのパッケージ販売や構築を担当していた関係で、メール誤送信の現場を何度も見てきました。個人がどれだけ注意してもやはり誤送信は起こってしまう。それをシステムで解決したいという要望が、2009年に『留め〜る』の開発に着手したきっかけでした」(肥後氏)
2014年の*1データでは「個人情報流出事故の18.5%がメールの誤送信によって発生した」とある。実際、過去1年間に絞って、メールに起因する企業情報漏洩を調べてみても、非常に多くの漏洩事故が誤送信によって起きている。特に、個人情報が記載された添付ファイルを間違った宛名に送ってしまう事故は多い。その中には、組織の存続を脅かすほどの影響を与えてしまった事故もある。
「ここ数年は、情報漏洩事故が立て続けに発生したことや、マイナンバー制度の導入に向けた動きもあり、個人情報の取り扱いに対する企業や行政のセキュリティー意識の高まりをより強く感じています。弊社のソリューションで、企業のメールガバナンスの向上をお手伝いできればと考えています」(肥後氏)
「活文Enterprise Mail Platform」は、その旧名称である「留め〜る」という名前からも推測できるように、ユーザーが送信したメールを、メールサーバー側で送信保留にする機能を核としたものだ。一定時間後に送信したり、送信する際には上長の承認を要求したりするなど、各種送信の際の設定はユーザー側で自由に決めることができる。「活文Enterprise Mail Platform」の環境を利用しているユーザーの送信キャンセル操作の95%が、保留開始後15分以内で行われていることから*2、単純に一定時間後に内容を再確認してから送信するだけでも、誤送信防止に対してかなりの効果が期待できるだろう。
Rubyを使ってマイグレーション
「活文Enterprise Mail Platform」は、メール送信の基盤となるメールソフトウェアの変更をきっかけに、システムの一部に関してRubyを使い、マイグレーションを実施した。ユーザーが操作することになるWebアプリケーション部分には、「Ruby on Rails」と「Bootstrap」を使って開発。また、メールフィルタの実装において、Rubyスクリプトを呼び出せる構成としたことで、フィルタの設定をRubyで書けるようになった。Webアプリケーションやメールフィルタなど、製品を構成するコンポーネントにおいてRubyを広く採用し、共通ロジックをライブラリ化することで、ソフトウェア開発の全体的な生産性や品質を高めることに成功している。
「ビジネス損失を最小限にするために、限られた時間の中で素早くマイグレーションを行う必要がありました。そこで、弊社でも多数の実績があるRubyを採用することになりました」(中西氏)
「Webアプリケーションの操作性向上のみならず、メールフィルタの設定についても自由度が高まりました。6ヶ月でマイグレーションできたということは、非常に効率の良い開発だったと思っています」(肥後氏)
Rubyを選定したことによって、開発効率が高まった半面、運用上でのパフォーマンスに対する懸念はないだろうか。
「現段階では特に問題になるようなことはありません。ただし、元々、C言語であったりJavaがメインで使われる分野でもあったりすることから、処理速度の向上に対する要望は大きいです。もちろん、サーバー台数を増やすことにより処理速度の向上を図ることもひとつの手ですが、サーバー1台当たりの処理速度向上をめざしたパフォーマンスチューニングに関しては、継続して改善を推し進めています」(中西氏)
以前とは違う社内でのRubyへの意識
日立ソリューションズは、Rubyを利用した大規模システムを多く手がけている。Rubyのノウハウがまだあまりない頃にRubyを使いたいと思っても、実際にプロジェクトで採用するには高い壁があった。しかし、Rubyセンタを立ち上げた5年ほど前に比べると、Rubyに対する社内の意識が大きく変化してきている。
「本案件でRubyを選んだのは、合理的な理由からでした。Javaでの開発だと開発期間的に難しいなという試算があったので、Rubyしかないと思っていました。Rubyを使うことに対する社内の壁は年々低くなってきていると感じています」(中西氏) Ruby開発のノウハウを蓄積し、技術的な後方支援を行っているRubyセンタから、各開発チームに対してスキルの移転が順調に進んでいることが社内全体でのRubyに対する意識を高めることにつながっているようだ
業務系システムでは常時安定した稼働を実現させるためにも、できるだけソフトウェアのバージョンを固定して長く使い続けたいという意識が働くものだ。RubyやRails本体の開発は今も活発に継続しており、バーションも早いテンポで上がって行く。 「活文Enterprise Mail Platform」のチームでは、RubyやRailsの開発に合わせてパッケージを改善していくことが、最終的にはユーザーのビジネスにプラスの効果を生み出すと考えている。
「最善のパッケージを提供するために、最新のテクノロジーを使って作られたシステムをお客様に提供していきたい」(中西氏)
「留め〜る」は「活文Enterprise Mail Platform」に
今春から「留め〜る」は、「活文」という日立ソリューションズを代表するブランド名を冠につけた「活文Enterprise Mail Platform」という新たな名称に変更して、サービス展開を行っている。「留め〜る」時代には、主に誤送信対策を目的としたサービスだったが、今後はメール通信の入り口部分のセキュリティーも対象としたり、「活文」ブランドを含む自社パッケージや他社製品と連携したりすることで、メールに関するトータルソリューションを提供する製品となっていく。
「Rubyの採用で、新たな要件に対するプロトタイプの作成、デモが容易となった。これから新たな機能を追加する際にも利点になってくる」(肥後氏)
*1(平成26年度)「個人情報の取り扱いにおける事故傾向に見る傾向と注意点」
一般財団法人日本情報経済社会推進協会プライバシマーク推進センター
*2 日立ソリューションズ調べ
※本事例に記載の内容は取材日時点(2016年3月)のものであり、現在変更されている可能性があります。
事例概要
- 会社名
- 株式会社日立ソリューションズ
- 活用分野
- メールプラットフォーム
- 利用技術
- Ruby on Rails
- Milter Manager
- Bootstrap
- sendmail
- PostgreSQL
- OpenLDAP
- ニーズおよび解決したかったこと
- 前提製品の制約により留め~るをマイグレーションする必要があり、留め~るを提案中の顧客対応やビジネス損失を最小限とするために、なるべく早急に製品リリースを行う必要があった。
- 留め~るをマイグレーションするにあたり、既存顧客がマイグレーション後の製品にアップグレードしても問題なく利用できるよう既機能の踏襲が必須要件であり、早い段階で実現可否・工数を見極めたかった。
- Webアプリケーションのリビルド対応に伴い、ユーザビリティ向上を目的としたデザイン、レイアウトの見直しを実施した。
- Ruby採用理由
- 日立ソリューションズは過去Rubyセンタの設立やRuby技術者の育成など、Ruby技術に力を入れている点や、今回の開発においても生産技術センタの支援が受けられるなどのメリットを考慮した。
- 新規実装したメールフィルタエンジンの仕様として、メールデータ処理がRubyの呼び出しとなっており、WebアプリケーションもRails適用と、なるべくRubyにすることで生産性・品質向上に繋がると考えた。
- 今回の開発で一番開発工数が大きいと想定されるWebアプリケーション部分は、実現可否・工数等の早期幹分けを目的とした反復開発モデルを適用した。Railsを使うことで機能仕様の早急なフィックスやユーザビリティテスティング等の適用による品質向上が見込めた。
- Ruby採用効果
- 元々5年近く開発かけてきた『留め~る』という製品を、5ヶ月間でマイグレーションすることができた。
- 製品構成する複数のコンポーネントにRubyを適用し、共通ロジックをライブラリ化することで、生産性の向上や修整箇所の局所化による保守性の向上が図れた。
- 既存のJavaシステムと比較して、問題発生時の再現確認や修整後の確認が容易になったことと、新たな要件に対するプロトタイプの作成・デモも容易となった。
※本事例に記載の内容は取材日時点(2016年1月)のものであり、現在変更されている可能性があります。