【第2話_開発編】現場発の新プロダクト誕生ヒストリー

2020年10月にプレスリリースされた、ＡＲＩ3つ目のオリジナルプロダクトである「Mieta」。クラウド技術とコンタクトセンター業務知識というＡＲＩの強みを凝縮した「Mieta」だが、企画からリリースに至るまでの開発秘話を企画開発に携わったコアメンバーにインタビュー。このプロダクトが生まれた背景やこだわり、苦労話、今後の抱負などを聞かせてもらった。全3回でお届けする第2回目。今回はシステム開発面での苦労話やこだわりポイントを聞いた。

第1話：企画編
第2話：開発編（本記事）
第3話：学びと抱負編

ARIにおける今後のプロダクト開発の雛形を目指して

ーーMietaのシステムアーキテクチャを教えてください。

江田　アプリケーション部分は、過去の実績を踏まえて、フロントエンドはReact.jsで、API層はDjangoで構築しました。基盤部分はECS（Elastic Container Service）を用いたコンテナ構成です。CI/CDパイプラインはAWSのCodeシリーズを活用し、テストやリリースの自動化を実現させています。

DB部分は、Amazon Elasticsearch Serviceをデータレイクとして利用し、Lambdaを使ってAmazonConnectの情報を取り込んでいます。パフォーマンス条件をクリアするために、ヒストリカルデータはRDSに集計テーブルとして保持しています。

Mietaのシステム構成（一部イメージ）

井出　自分はLOOGUE （編集注）の運用面を見ているのですが、サービス運用開始後にお客様や機能が拡大していく中で、開発チームが色々苦労をしてきたのを横で見ていました。そこで今回のMietaでは、そうしたLOOGUEのノウハウを活かすことを心掛けました。

具体的には、マルチテナント的な構成やアカウント管理体系、共通機能や機能分割方針、など、スケーラビリティ・可用性・セキュリティ面など、運用面も最大限に考慮した設計ができたかと思っています。ですので、今後お客様が増えたり機能が拡大していっても、安心して対応できるはずです。

－－思う存分、拡販に専念してもらってよいというわけですね！

宮尾　ちょっとプレッシャーが・・・（苦笑）

井出　このMietaの基盤構成を、今後のARIプロダクト基盤のスタンダードにできたらという想いで考えました。もちろんニーズがあえば受託開発の案件でも活用できるのではないかと思います。

レポートシステムを軽く見てしまっていた

ーーシステム開発の面ではどんな苦労がありましたか？

江田　正直言うと、やる前はレポートシステムを少し舐めてしまっていました。情報を収集して加工して表示するだけでしょって。ただ実際は本当に大変でした...特に、似て非なる100近い膨大なデータ項目との格闘は忘れられません。塩見さんに明確な仕様は提示してもらっていたものの、細かい集計実装仕様の調整は最後まで大変だったですね。

Mietaのレポート表示項目とその計算式定義資料（一部抜粋）

何より一番大変だったのは「レポートの答え合わせ」ですね。テストを行うには、用意したテストデータや検証環境のAmazonConnectの指標に対して、個別に集計値の「正解」を用意する必要があります。これは本当に大変な作業でした。仕様を元に計算をしながら正解を作って、レポートの表示内容と突き合わせる地道な作業の繰り返しでした。またレポート画面UIについては、最後まで細かい調整が入りました。

こうした部分も含めて、若手メンバー達が本当に頑張ってくれました。チームのみんなには本当に感謝していますが、彼らは今回本当に成長したと思います。

インフラ製品エンジニアからプロダクト開発への挑戦

ーー塩見さんは元々コンタクトセンター製品のスペシャリストだったわけですが、今回ゼロからサービス開発に関わっていかがでしたか？

塩見　ずっとコンタクトセンター製品のエンジニア一筋でやってきて、AWSの知識もアプリケーション開発の知識も殆どゼロという状態からの始まりでした。正直、チームの皆さんと会話が成り立たないところからのスタートでした。

ーーどうやって乗り越えましたか？

塩見　出てくるキーワードを調べて、限界が来たところは皆さんに教えて頂きつつ、必死で勉強してくらいつきました。聞く情報を吸収するのが精一杯で、その中で何が正しいのか、今回については何が正解なのかを探すのは本当に大変でした。

井出　でも後半はかなり理解してくれていたと思いますよ。塩見さんは自分で手を動かしちゃんと理解してから着手したいタイプだとお見受けしたので、時間が許す限り、自分で考えてもらうスタイルを取りました。

結局ネットを検索して出てくる情報って、教科書的な推奨プランのことが多いじゃないですか。やっぱり現実的な現場運用とは乖離があることも多い。そういうことも塩見さんはちゃんと理解されていました。急がば回れではないですが、手を動かして自分でちゃんと消化してから前に進むスタイルが、最終的には良かったのではないかと思います。

塩見　そうですね。そうしているうちに、仕様の制約の中でサービスとサービスの繋がりが一本の道で結ばれて、自分の頭の中でイメージできるようになった気がします。

本当にお客様の課題を解決できるものにしたかった

ーー今回開発に際してこだわったポイントを教えてください

宮尾　本当にお客様の課題を解決できるプロダクトにしたい、という部分でしょうか。「作りたいもの作っても売れない」というのは、プロダクトと向き合ってきたR&Dの皆さんから色々フィードバックをもらっていました。「本当にお客様の求めているものは？」というのは常に忘れないように進めたつもりです。

江田　ファーストユーザーとなるお客様と納期が決まっていたこともあったので、こだわったというよりも、期日までに形にすることを優先させた部分もありました。カッコよく言えば、「形にすることにこだわった」ともいえますが、エンジニアとしてはこだわり切れなかった部分もあったというのが正直なところです。

高林　できるだけメンバーに任せようとした点ですかね。自分は幸いこうしたプロダクト開発の経験を複数重ねているのですが、サービスを企画してアーキを検討して、最終的にシステムを作って品質担保したという経験値をもったメンバーをARIの中に増やしたいというのがありました。今後エンジニアとして独り立ちしてく上で、大事な経験だと思っていますので。終盤少し踏み込むことになりましたが、メンバーのみんなは良い経験ができたのではと思っています。

～最終話：学びと抱負編に続く～

〜これから共に働く仲間へ〜

若手からベテランまで、日々わくわくしながら仕事をしています。
皆さんの持っているアイディアをソリューション化できるように一緒にチャレンジしましょう！

Facebookページも更新中！