エンタープライズ向けプロダクトならではの悩みとは
システム構築と自社プロダクト開発の2つを事業の柱とするドリーム・アーツ。自社プロダクトとしては、大企業向けEIP型グループウェア「INSUITE」、BPM型Webデータベース「ひびきSm@rtDB（スマートDB）」、多店舗運営支援用コミュニケーションツール「Shopらん」などがよく知られ、国内有数の大企業・団体等への豊富な導入実績を持つ。
「自社プロダクトと言っても、事業領域はエンタープライズIT。一つひとつシステムを作り上げていくSIerの皆様もいろいろと苦労されていると思うが、プロダクトメーカーとしての我々も悩みは尽きない」と石田氏は語り、「エンタープライズプロダクトの悩み」として次の3点を挙げた（※順位は石田氏個人の感覚による）。
- 第1位：保守が困難
- 第2位：UIを変えにくい
- 第3位：ブラウザが古い
まず、「ブラウザが古い」という悩みについて、石田氏はある製品のサーバのログ（2016年2月時点）からユーザーエージェントの集計結果を紹介。それによると、ブラウザはIE（Internet Explorer）8が最も多く、29％を占めていた。IE8はWindows XPが最後にサポートしていたバージョンであり、IE6も5％含まれていたことから、石田氏は「Windows XPを使われているお客様もまだまだ多い。これがエンタープライズの現実」と指摘。
「UIを変えにくい」悩みについては、ある製品のバージョンアップ時にボタンの位置が「1ピクセルずれていた」という事例を紹介。見た目にはわからないレベルの違いだが、実際に「社内用のマニュアルでキャプチャをすべて撮り直さなければならない」というクレームにつながってしまったという。
「市場やお客様のニーズに応えていくためにも機能強化・追加などのバージョンアップは必須だが、なるべく旧バージョンと見た目が変わらないようにしなければならない。この事例のように“なるべく”というのが場合によっては“1ピクセルもずれないこと”を意味することもあり、慎重な対応が必要」（石田氏）
第1位の「保守が困難」という悩みについては、石田氏はいくつかの理由を提示した。1つは、オンプレミス環境が多いこと。最近ではエンタープライズシステムでもクラウドが増えてきたとはいえ、大多数は旧来のオンプレミス。顧客のサーバに自社製品をインストールすることになるが、“ファイアウォールの向こう側”で動いているため、ログ一つ取得するのにもかなりの手間がかかってしまう。
カスタマイズが多いことも理由の一つ。パッケージソフトを“素のまま”入れて使うことは稀で、顧客の業務に合わせたきめ細かなカスタマイズやアドオンによる機能追加を実施する場合が多い。当然そこまでは想定内なのだが、顧客側での「野良カスタマイズ」や「魔改造」のような想定外のことも多々起きているという。
そして、もう一つ大きな理由として挙げられるのが、多数のバージョンが存在すること。ドリーム・アーツでは、製品のリリースから6年間をサポート対象期間としている（この間に何か不具合等があれば、パッチリリースやアップデートリリースに対応）。そのため、同じ製品でもさまざまなバージョンが実際に使われている。
「『INSUITE』と『ひびきSm@rtDB』について、細かいマイナーバージョンアップも含めて6年間でどれくらいあるのか数えてみたところ、およそ100バージョン（！）あった。これだけのバージョンを保守していくのは、やはり大変な負荷がかかる」（石田氏）
窓口担当者が自分で簡単に再現環境を準備して検証可能に
続いて石田氏は、かつて全社的な課題となっていたという製品サポート対応について説明した。
ドリーム・アーツは東京本社のほか広島に開発拠点があり、さらに中国・大連にもオフショア拠点の開発センターを有する。そして、製品の総合問い合わせ窓口（お客様窓口）拠点は、沖縄・那覇市だ。
従来のサポート対応の流れとしては、まず、顧客から不具合等の問い合わせを受けた沖縄の窓口担当者が、東京本社に不具合検証を依頼。該当環境のカスタマイズなどは、東京ではなく大連の開発センターで行っているケースもあり、その場合、東京本社から大連に確認。連絡を受けた大連では、開発者がドキュメントを参照したり過去のソースコードを引っ張り出して環境を構築し、テストを実施したりするが……不具合の現象が問い合わせ内容どおりに再現されることは、実際にはほとんどない。顧客環境の詳細情報が十分ではないことが多いからだ。さらに広島の開発者にエスカレーションされることもあるが、そこでもやはり再現しないとなると、結局、沖縄の担当者に「ログや設定ファイルなどの追加情報の依頼」とともに差し戻されることになる。
「このように複数拠点間をぐるぐる回っているうちに、1か月以上経過してしまうことも珍しくなかった。長期間お待たせする上に問題が解決しないので、当然ながら、お客様を怒らせてしまう。こうした状況を改善するには、沖縄のお客様窓口で『お客様ごとの再現環境』を用意できればよいのではないかと考えた」（石田氏）
顧客ごとのサーバ構成や設定、カスタマイズ情報などがわかれば、たとえばAWS（Amazon Web Services）などのクラウドインフラ上に環境を構築すること自体は可能だろう。しかし、エンジニアではない窓口担当者がAmazon EC2のインスタンスを作成したり、コンソールを叩いて操作したりというのは現実的ではない。そこで石田氏が目を付けたのが、チャット上でシンプルなコマンドを投げるだけで複雑な処理をbotが自動実行してくれる「ChatOps」の活用だ。
「お客様窓口担当者が自分で操作してクラウド上にお客様の環境を再現し、問題の早期解決を図れるように、『さくっと構築』というツールを作った。基本的なChatOps環境の構成としては、チャットツール『Slack』とRubyベースのボットフレームワーク『Ruboty』、PaaS環境『Heroku』の組み合わせ。お客様固有のカスタマイズや設定情報はGitHubに集約する。これらを活用したチャットベースの操作によって、AWS上に再現環境を立ち上げることが可能。もちろん、自社製品についてすべてのバージョンの環境を準備できる」（石田氏）
ちなみにbotのキャラクターには、INSUITEのマスコットキャラクターである犬の「ポピー君」（popybot）を採用しているそうだ。
「さくっと構築」導入後のサポート業務のフローとしては、インシデントが発生したら、ひびきSm@rtDBに登録して管理。窓口担当者は、Slack上で自社製品のバージョンをはじめ顧客システム環境を指定し、簡単なコマンドを入力するだけでよい。あとはpopybotがAWS上にインスタンスを作成し、ネットワークやDNS設定も行って起動、カスタマイズや設定情報があればGitHubからダウンロードして、顧客システム環境を再現してくれる。再現環境が立ち上がったら、窓口担当者はすぐに不具合テストを実施して原因特定することが可能だ。結果に応じて「不具合です」「仕様です」「ブラウザの問題です」など適切に回答するとともに、不具合の場合には修正指示や改善要望を東京本社に送る。こうしたChatOpsの活用によるフロー改善により、サポートの対応スピードと品質が大幅に向上できたという。
また、チャットによるコミュニケーションの基本的なメリットとして、情報の共有・可視化にも役立っている。
「ひびきSm@rtDBの情報を集計して、担当者ごとのインシデント対応アサイン状況などを、定期的にpopybotがチャット上で知らせるようにしている。ここをタイムラインとして見ておけば、メールなどをいちいち確認しなくても素早い対応ができるし、チャットで現在の状況をまとめて流すことで『誰が何件抱えているのか？』『長期間滞留しているインシデントはないか？』などが一目瞭然で、みんなが把握できるようになった」（石田氏）
最後に石田氏は結びのメッセージとして、誰でも使える検証環境を用意できれば、エンタープライズ領域の保守業務も飛躍的に効率化できること、その実現方法としてChatOpsは有効であり、かつ簡単に始められることなどを語り、セッションを終えた。
お問い合わせ
株式会社ドリーム・アーツ
