窓口担当者が自分で簡単に再現環境を準備して検証可能に
続いて石田氏は、かつて全社的な課題となっていたという製品サポート対応について説明した。
ドリーム・アーツは東京本社のほか広島に開発拠点があり、さらに中国・大連にもオフショア拠点の開発センターを有する。そして、製品の総合問い合わせ窓口（お客様窓口）拠点は、沖縄・那覇市だ。
従来のサポート対応の流れとしては、まず、顧客から不具合等の問い合わせを受けた沖縄の窓口担当者が、東京本社に不具合検証を依頼。該当環境のカスタマイズなどは、東京ではなく大連の開発センターで行っているケースもあり、その場合、東京本社から大連に確認。連絡を受けた大連では、開発者がドキュメントを参照したり過去のソースコードを引っ張り出して環境を構築し、テストを実施したりするが……不具合の現象が問い合わせ内容どおりに再現されることは、実際にはほとんどない。顧客環境の詳細情報が十分ではないことが多いからだ。さらに広島の開発者にエスカレーションされることもあるが、そこでもやはり再現しないとなると、結局、沖縄の担当者に「ログや設定ファイルなどの追加情報の依頼」とともに差し戻されることになる。
「このように複数拠点間をぐるぐる回っているうちに、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は有効であり、かつ簡単に始められることなどを語り、セッションを終えた。
お問い合わせ
株式会社ドリーム・アーツ
