皆様、初めまして！ KDDI ウェブコミュニケーションズ 運用部の矢田と申します。
このたびは弊社で内製した「Twilioを使った運用ツール」についてご紹介できたらと思い、三回に分けて記事を執筆することにしました。
各回のトピックは以下となります。
- 第1回 自己紹介、開発経緯〜使用技術検討 <- 今回はここです！
- 第2回 ツール開発の準備〜実装内容の紹介（ブラウザ架電〜通知〜自動連続架電）
- 第3回 実装内容の紹介（エスカレリスト更新）〜番外
やや長丁場になりますが、緩く見ていただければと思います。
自己紹介
改めてはじめまして！
KDDIウェブコミュニケーションズ 矢田と申します。
技術本部 運用部でインフラエンジニアとして働いています。
主な仕事は、CPIやTwilioをはじめ、各サービスで使用しているサーバーやネットワーク機器の運用保守をすることです。
サービスを安定稼働させるためのメンテナンス・障害対応が日常業務ですが、業務効率化を目的としたツールの開発も行なっております。
今回はTwilioを使った運用ツールを開発した話をさせていただければと思います。
開発のきっかけ
まずは運用部の体制ですが、障害の一次対応を行なう監視チームと、二次対応を行なう運用チームに分かれています。
障害の内容によって監視チームから運用チームへ対応を引き継ぐものがあるのですが、この際の連絡手段としてチャットと電話を使っています。チャットに依頼内容の概要を書き、電話で詳細説明をする。このような連携を取っています。
この連携の部分にいくつか課題があると感じていたため、何か改善できないか考えた結果、今回の運用ツールを思いつきました。
開発前にあった課題
① 運用チームのメンバーに繋がるまで順番に架電するのに手間がかかる
運用チーム8名の誰か1名に繋がるまで架電する運用だったため、電話がつながらなかった場合は、次の人に手動で架電していました。
深夜など、時間帯によっては1巡することもあり、ただただ電話をかけ続けるというのが何とも無駄な作業に感じていました。
② 架電リストの更新がめんどくさい
架電する順番をリスト化していたのですが、対応頻度をできるだけ均等にするため、1回対応した人はリストの最後尾にするルールでした。
そのため、架電が終わると架電リストを毎回手作業で更新する必要がありました。
③ 誰に繋がったか、いちいちチャットに書くのがめんどくさい
概要の報告を書いたチャットにレスする形で、誰に対応を依頼したのか追記していました。
些細なことかもしれませんが、これにもめんどくささを感じていました。
課題解決と書くとかっこいいですが、こうして振り返ると「めんどくさいことをやりたくない」と考えたのが開発のきっかけだったと思います。
検討開始（内製することにした理由）
この業務改善を考えた時点で、世の中にある多くの既製品についての情報収集・比較検討も始めていました。
どの製品も非常に魅力的でしたが、若干かゆいところに手が届かなかったり、逆にオーバースペックだったり……。中々決め手にかける状況が続いていた際に、某社が開催されたエンジニア向けセミナーに参加しました。
そこで私と同じようにサービスの運用保守を担当しているエンジニアが、内製で運用ツールを開発した話を聞き、
「既製品でピンと来ないなら、自分たちで作っちゃえばいいんじゃない？」
というスイッチが入りました。
そこから既製品の選定を中止し、自分で作るための準備を始めました。
使用技術検討
自分たちで内製する方針が決まったため、まずは使用技術の検討を始めました。
検討した内容は以下の3つです。
- フロントエンド（実際に使うときに見る画面）
- バックエンド（裏側で動く処理部分）
- 他ツールの使用（要件に沿って検討）
それぞれ検討した技術、最終的に選んだ技術・理由を記載していきます。
フロントエンド（実際に使うときに見る画面）
- 検討した技術
- React , Vue.js(JavaScript) , Angular , HTML5 , CSS3 , Bootstrap , JavaScript
まずサイトの表示部分を作ろうとしたときに、以下の選択肢が生まれました。
- フレームワーク(Reactや Vue.js)を使わずに、HTML5 , CSS3 , Bootstrap , JavaScriptでフルスクラッチする
- フレームワークを使って構築 , サーバサイドのやりとりをJavaScriptで行う
今回のツール開発では、私は2番を選びました。「使ったことのない技術を使ってみたかったから」です。
加えると、「フレームワークの方が後々拡張しやすそうと思った」というのもあります。
過去にHTML5 , CSS3 , BootStrap , JavaScriptでフルスクラッチしたサイトを作ったことがあるのですが、その際、後々の追加や凝った動作を行おうとするとやりづらくなる印象を受けていました。
また今回のサイトでは、似たような機能を持ったボタンやリストをいくつも作る要件があったため、フレームワークの方が取り回しがしやすいと思ってフルスクラッチをやめました。
フレームワークをいざ使おうと決めたもののどれを使えばいいのか。
ここにしばらく時間を要しました。
Angularは大規模なサイト開発には向いているものの学習コストが高く、今回1人での作成ということもあり、時間的にも規模的にも不採用となりました。
Vue.jsは過去に触ったこともあり、小規模〜中規模向きのため、採用検討ではあったのですが、使ったことのないフレームワークにしたかったので不採用。
Reactが小規模向きのフレームワークということを知り、かつ触ったことのないフレームワークであったこともあり、今回採用となりました。（ただ学習コストはそれなりです。JSXに慣れるのに時間がかかりました。）
また後述しますが、今回はバックエンドとして採用したPHPとの連携のため、JavaScriptを使用しました。
今思うと他に選択肢があったと思いますが、JavaScript – PHPの連携部分を過去に作ったことがあったため、フレームワークで触ったことのない技術を採用する分、技術は経験のあるものを採用することにしました。
バックエンド（裏側で動く処理部分）
バックエンドで今回考えていた必須要件が、
- エスカレ架電のメンバーリストをDBで管理したい
- DBをサイト上のボタンなどから操作したい
- すでにある程度触ったことのある技術にしたい
でした。
DBを使用したいと思った際に、真っ先に思いついたのはMySQLでした。
過去にPHPを用いてMySQLのDBを操作するコードを書いたことがあったため、今回に活かすことができそうだと感じてMySQLを採用。
また上記の内容から、PHPを使用することにしました。
今改めて作り直すのであれば、Pythonにしてもいいかも？ とは思います。（しっかりと書いたことがないので）
他ツールの使用（要件に沿って検討）
- 検討した連携内容
- チャットツール(Teams)との連携
- ブラウザから架電を可能にする技術
今回内製したエスカレツールは、エスカレーションという性質上
- チャットでエスカレーションする内容を周知
- 担当者にツールから架電を行う
という必須要件がありました。
弊社で使用しているチャットツールがTeamsである都合上、チャットツールへの自動通知、チャットからDBの更新を行うためにTeams APIを使用しました。
ツール（ブラウザ）から架電を行えるようにしたいという要件については、Twilioが筆頭にあがりました。
当時触ったことがあり、かつ実装へのハードルの低さを考えたときに、Twilioが採用となりました。
採用した技術をまとめると、
- フロントエンド：React , JavaScript
- バックエンド ：MySQL , PHP
- 他ツール ：Teams API , Twilio
となりました。
比較的コンパクトに収まったように思います。
