はじめに
こんにちは。RevCommでCorporate Engineeringチームで活動している川添です。
今回のブログでは、オンライン申し込みからお客様専用の環境構築までの一連の業務プロセスを自動化するテクニックについて解説していきたいと思います。業務効率化や自動化に興味がある方はぜひ参考にしてみてください。
自己紹介
まず自己紹介をしておきますと、私は2020年7月にRevCommに入社して、主にCorporate Engineering領域で活動しつつ、フルスタックチームとしても社内チーム横断プロジェクトの管理などをしております。
これまでの経歴としては、ITコンサルティングの会社で基幹システム導入など、いわゆるSIer業務のようなことを行い、業務プロセスとシステムの整理や設計などをやってきました。今回はそのような経験も活かして、どのようなシステムを構築したかをお話ししたいと思います。
1. プロジェクト背景
これまで、弊社ではオンラインで契約やお客様用のテナント発行までを完結することができるものはありませんでした。そのため、お客様がMiiTelを利用するためには、必ず弊社のメンバーと商談や打ち合わせをする必要があり、気軽に製品を試したいというニーズにお答えすることができていない部分がありました。
そこで、今回 MiiTel Meetings （旧称： MiiTel for Zoom ）の名称変更に伴う無償提供キャンペーンに合わせて、顧客満足度向上や作業効率化を目指し、オンライン申し込みのシステムを開発するプロジェクトが発足しました。
2. 業務プロセスを整理する
まず、どの部分を自動化すべきかを見極めるために、現行の業務プロセスをしっかりと理解することが重要です。業務プロセスを整理し、それぞれのステップがどのように影響しているかを把握する必要があります。この段階で各チームとの協力が必要となります。各部門の意見を収集し、業務プロセスを再設計することが求められます。
私はこの段階で業務フロー図を必ず作成するようにしています。
言葉でのやり取りは曖昧なもので、同じ会社のメンバーでもそれまでの経験や、所属しているチームによって言葉の定義が違ったり、イメージしているものが異なったりします。そのため、業務フロー図を書いて、認識齟齬をなくし抜け落ちているプロセスがないかを洗い出します。
この部分の整理が甘いと、後の開発のプロセスで手戻りが多くなってしまうので、丁寧に進めることをおすすめします。
イメージ図：
2-1. システム化するポイント・しないポイントの整理
業務フロー図を作成している中で、システム化（自動化）するポイントとしないポイントの整理も行います。オペレーションを自動化しない場合は、社内のどこかの部署にオペレーションを担当していただくことになります。
システム化すべき部分を見極めるのは難しいですが、「実装工数」・「確証性」・「納期」などがポイントになってくると思います。
「実装工数」や「納期」は言葉の通りです。「確証性」は、そのオペレーションが今後変更される可能性（逆に言えば変更されない可能性）がどれだけあるかを意味して書いています。オペレーションのやり方が今後ガラッと変わったり、細かくても何度も変わる可能性があれば、自動化しないほうがいいでしょう。
逆にオペレーションが変わらない可能性が高ければ、自動化してしまったほうがより効率的な仕組みを作ることができます。
3. アジャイル的なプロトタイプ開発
プロセスの整理ができたら、次にプロトタイプを作成しましょう。プロトタイプを作成する目的は、システムの全体像を把握し、各チームとの調整をスムーズに進めることにあります。アジャイル開発手法を取り入れることで、段階的にシステムを改善・拡張しながら、各チームと連携してより良いシステムを目指します。
見落としがないように進めたとしても、作ってみると意外と抜けているポイントがあったり、「実際やってみるとこうしたほうがいい」ということが発生しがちです。そのため、納期ギリギリに初めて動くものができましたというやり方より、小さく作って認識合わせを細かくするほうがいいと思います。
実際に今回のプロジェクトでも、解約のフローに関してのプロセスの見直しが起きました。解約を受け付ける際のデータの流れに各チームでの認識齟齬があり、プロトタイプ実装中に問題が発覚し再検討・再実装が必要となった部分がありました。
業務プロセスに関わるものは、部署やチーム横断的に多くの人が関わることが多いです。そのため、ボールの取りこぼしというのは絶対に発生するもの、くらいの認識で進めるといいかもしれません。
私の場合は、プロセスの見直しがある前提で、見直すべき箇所をいち早く見つけるためにプロトタイプでの実装をよく使います。
4. 全体のシステム構成
前置きが長くなってしまいましたが、ここからが実際のシステムの話です。実際にどのようなものをどのような技術で構成したかをお話したいと思います。
まず具体的な機能を紹介します。当システムではお客様が専用フォームに必要事項を入力するだけで、独自の環境が自動的に構築されるとともに、MiiTel Meetingsを使うためのセットアップも自動的に実行されます。
さらに、お客様が当システムを利用するにあたって、事前に利用規約に同意することが必須となっております。利用規約ページでお客様により同意操作が行われた際に、お客様のアカウント情報が自動的にメールで送信される機能も備えています。
以上により、お客様はオンライン上のフォーム入力だけでMiiTel Meetingsの利用を開始できます。
続いて、上記のシステムを構築するために用いた技術スタックを紹介します。システム全体の俯瞰図は以下のとおりです。
4.1 インフラ
インフラは全てAWS上で、後述のとおりサーバーレスアーキテクチャとなっています。常時アクセスされるものではないので、必要なときに必要なだけ稼働する仕組みにしています。
IaCはTerraform でベース部分は構築しており、バックエンドのAPIの管理はServerless Framework を活用しています。
4.2 フロントエンド
社内でも広く使われているReactを用いました。（create-react-app でプロジェクト作成しています）
オンライン申込みのフォームはWordPressで構築されているプロダクトLPに置くので、最終的にはビルドしたファイルをサーバに置くようにGitHub ActionsでCI/CDを組んでいます。
また、ページがサブディレクトリ配下でも正しく動くように、以下の設定をいれています。
package.json
{ "name": "revcomm-online-application-front", "version": "0.1.0", "private": false, "homepage": "https://miitel.com/jp/cpform/meetings/", … }
実装においては、使いやすく、わかりやすいUI/UXを心がけるようにしました。ページのデザインは社内のデザイナーが担当したものになりますが、使いやすさの観点でいくつか工夫をしています。
例えば、入力ミスがあった場合にはわかりやすいメッセージを出したり、メッセージの箇所までスクロールで遷移させたりしてお客様が気づきやすいように作っています。また、登録処理に時間がかかる場合は途中で離脱してしまわないよう、処理の進捗状況を画面に表示させてお客様がどれくらい待てばよいのかを知らせています。
後述しますがバックエンドはAWS Lambdaで実装しています。そのため、立ち上げがスムーズになるように、ページにアクセスされたときにヘルスチェックリクエストを送ってあらかじめバックエンドを立ち上げておく工夫も行っています。
const TopPage = (props) => { // コンポーネント初期化時にバックエンドを立ち上げておく useEffect(() => { (async () => { await APIClient.get("/api/health"); })(); }, []); }
4.3 バックエンド
バックエンドはAWSのサービスを利用しています。API GatewayとAWS Lambda上に、PythonのFast APIというWebフレームワークを用いて構築しています。
データベースは社内の既存システムを利用しているため、このシステム自体に対するデータベースはありません。
そのため、軽量かつバリデーションも簡単でありながらしっかりと行えるFast APIを選択しました。
バックエンドの実装で特に気をつけたポイントは、社内では「Adminエンドポイント」と呼んでいるAPIを実装しておいたことです。
これは、お客様が処理の途中で離脱してしまった場合や、社内オペレーションミスなどで特殊な作業をする必要があった場合に、データの整合性を後で取る運用のためのエンドポイントです。
あらかじめ作っておくことで、安心感も違いますし、柔軟な対応ができています。
4.4 バッチ
申込時に途中離脱が発生したかどうかをチェックしたり、解約の意思があった際に自動的にお客様の環境を停止したりする処理には、AWS Batchを利用しています。
そこまで重たい処理でもないのですが、一部処理に時間がかかる可能性があったり、処理件数が増えてきた場合に備えて初めからAWS Batchを使って実装しています。
4.5 監視
弊社ではDatadogをログやパフォーマンスの監視に用いているので、このサービスにおいてもそれを組み込んでいます。アラートを設定しておいて、何か問題があったときに検知できるようにしています。
お客様はこういった申込みシステムで、何かあったら問い合わせなどはせず離脱して終わってしまうことが多いので、何かあったときにシステムが検知できるかどうかは非常に重要です。
5. 結果と展望
プロセス整理から始まってリリースを行い、問題なくテナント発行がされる仕組みが構築できました。実際にお客様からの申し込みもあり、社内の対応を効率的に行うこともできています。
今回は、MiiTel Meetingsの無償キャンペーンのみの対応ですが、今後はより幅を広げて、より多くのお客様にRevCommのプロダクトを体験してもらうことができる仕組みを作りたいと考えています。
