チャットツール連携の開発を通して描く業務アプリケーションの未来〜「Qiita Engineer Summit 2021 Winter」イベントレポート
2021年12月17日、エンジニアとして活動している方を対象にしたオンライントークセッション「Qiita Engineer Summit 2021 Winter」が開催されました。こちらは、“Be a Contributor”がメインテーマとして据えられて、「エンジニアリングは社会に、そして世界にどう貢献できるのか？」を各企業が考え、取り組むそれぞれのエンジニアリングについて語るべく、Qiitaが主催したものとなります。
第1弾のセッションテーマは「チャットツール連携の開発を通して描く業務アプリケーションの未来」。今回は、大企業を中心に多くの企業が導入・活用している統合人事給与システム「COMPANY（カンパニー）」の開発・販売・サポート等を行う株式会社Works Human Intelligenceによるオープニングセッションの様子をお伝えします。
※本レポートでは、当日のセッショントーク内容の中からポイントとなる部分等を抽出して再編集しています。
登壇者情報
@goamix目次
業務アプリの不便を「チャットツール内アプリ」で解消する
其阿彌：今回のテーマが「チャットツール連携の開発を通して描く業務アプリケーションの未来」ということで、まずは私が昨年調べた、チャットツール利用率の割合についてご紹介します。
調査の全体数は26社というところで、多くはないのですが、その内訳を見てみると88%の企業（円グラフの紫以外）が利用していることがわかります。既にそういう意味では、チャットツール自体が「企業インフラ」と言ってもいいような状態になってきているなと、昨今思っています。
そんな中で、次は業務アプリケーションについてですが、今回は基幹系と支援系でざっくり分けて書いてみました。
其阿彌：「基幹系」と言っているのは、財務会計やSCM、人事給与などですね。弊社の製品「COMPANY」は統合人事システムということで、人事管理や給与計算、勤怠管理など、細かい人事領域における機能をかなり多く提供しています。
一方で「支援系」では、例えば有名どころだとSFA（営業支援システム）が挙げられるでしょう。他にも、CRM（顧客管理システム）や契約管理システム、プロジェクト管理システムなどが該当します。弊社も支援系として人事領域と連携したチャットツールを提供しています
では、チャットツールが企業インフラとして定着するに伴い、業務アプリケーションはどのように変わるのでしょうか？
業務アプリケーションと一言で言っても、ちょっと想像しづらいとは思いますので、今回は私のチームが開発している勤怠管理システムの有給休暇の申請をするという流れにそってお話をさせていただきます。よくあるシステム利用の流れというところで、リンクを開いて、ログインして、休暇申請の操作をします。
其阿彌：この簡単な流れだけを見ても、課題はこれだけ挙げられます(上記参照)。そして、これに対して「チャットツール内アプリ」というものが提供されています。ちょっと分かりづらいかもしれませんが、下の画面（右画像）は、Teams画面で各Teamsに対して各企業さんが専用のアプリを提供しているものとなります。
其阿彌：多くのアプリが提供されていて、これらを使うことによって、先程の課題をうまく緩和していくことができると考えています。例えばリンクを開くようなところだと、Teamsアプリ内でアプリ検索といった形で探せるので、どこにあるのかというのをいちいち探さなくても簡単に探せますし、Teamsアプリ内にショートカットを作るというようなこともできます。ログインについても、基本的にチャットツールに一度だけすればいいので、何度もする必要がありません。
別の観点でアプリが普及しているということもあり、特に人事部さんから聞くのは、「コミュニケーションを促進したいからチャットツールへログインしてもらいたい。そのためにアプリを色々増やしてチャットツールを使う動機付けをしたい」ということです。弊社では打刻機能も提供しているので、打刻を早くアプリ化して欲しいというお声をいただきます。
数年後にはiPaaS（システム連携）の仕組みが本格化する
其阿彌：弊社では2021年11月にMicrosoftさんとパートナーシップを組んで、Teamsとの連携機能を提供することを発表しています。私は今ここの開発をやっていて、リリースに向けて準備をしています。
こちら（上図）は簡単な構成図です。簡易版ですが、クライアントがあってTeamsがあって、今回はAzure Bot SeviceからAWSにつなげています。
では、業務アプリケーションとして見た変化はどうなっているのかというと、基本的には「バックエンドサービス」になります。どういう意味かというと、専用のUIがなくなっていくという事です。もちろん、シフト画面のような複雑なものは残るかなと思いますが、専用UIはどんどんとなくなっていき、バックエンド寄りになっていく。当然そうするとAPI提供がメインになってきて、モノリシックに作っていくメリットも少なくなってきて、マイクロサービス化が進んでいくということにも繋がります。
其阿彌：構成を表現するとこんな感じでして、フロントはチャットツールとして、ここでナビゲーションとか休暇の入力フォームといったところの役割を担っています。
一方で業務アプリケーション側は年間で4月に付与される有給休暇を付与する仕組みや、先程の入力フォームから受け取った休暇申請の登録APIを提供する、といった役割構成に変わる仕組みと考えています。
其阿彌：今は休暇申請だけの話をしましたが、会社を休む時は他にもすることはあると思います。実際に私の場合、休暇申請そのものよりは、どちらかというとチャットツールを使ってチームに連絡する、ステータスを休みにする、オフィスツールでスケジュールに休暇を入れて参加予定だったスケジュールを欠席にする、といったオペレーションを行います。
休みの時に色々やっていると面倒なので、もっと楽がしたいですよね。
其阿彌：これに対して、数年後になってくるとは思いますが、システムと統合する部分については新しくその領域のサービスが出てきて、使っていくことになると見ています。この領域は「iPaaS」と言われる領域で、勤怠システムやチャットツール、オフィスツールなどといった複数システムを連携させていくような仕組みに変わっていきます。先程の例でお伝えすると、休暇申請をすれば、各種申請や連絡、ステータス変更までしてくれる機能というわけです。
ちなみに、iPaaS製品として有名なところはZapierやWorkato、Mulesoft、Power Automateなどが挙げられるでしょう。
其阿彌：ここからさらに、もっと楽がしたいという感情が出てきて、フォーム入力も面倒だということになるでしょう。その場合、例えばチャットツールでBOTに向かって「今日休みます」とだけ言ったら何とかしてくれないかな、というのが当然要望として出てくるわけです。自然言語との適応が求められてくるというのが、割と見えている世界だと思います。
既にライブラリは出てきていて、実際に「今日休みます」って言葉を入力すると、システムの方でインテント（意図）として「休み」というキーワードから休暇システム、休暇申請の登録APIへとマッピングさせて、そこで持っているスロット（項目）へ値をマッピングしています。
「今日」という言葉であれば本日の日付に変えていきますし、日付指定があればその日付に変えます。発話者についても、特に指定がなければその本人がマッピングされるし、例えば「誰々さんが明日休む」と入れると、人を指定したマッピングがなされることになります。
其阿彌：先ほどもお伝えしたとおり、ここら辺はライブラリで色々と出てきていて、AzureだとLanguage Understanding（LUIS）があったり、AWSだとLex、GCPだとDialogflowといったところで提供されています。
また、マニュアルを探せないという課題が先ほどありましたが、「休暇申請したい」ということへの回答ができるようなツールも、ちゃんとライブラリとして用意されています。AzureであればQnA Maker、AWSではKendraというサービスが割と使い勝手として良く、組み合わせて使うこともできます。
「自然言語によるシステム連携」という未来も考えられる
其阿彌：弊社でも自然言語処理の需要という部分では、やはりChatBotが望まれているので、すでにリリースしている製品があります。具体的には、年末調整や勤怠など、従業員から人事に寄せられる膨大な問い合わせにチャット形式で自動回答するようなサービスとなっています。
社内では実証実験も行っていて、先ほどのライブラリ群を評価してみましょうという目的でやっています。色々あるQAの中でも「年末調整」に絞って、Slack連携を作ってパッと試してみました。
其阿彌：基盤選定から行ったのですが、結論から言いますと「QnA Maker」というライブラリを使いました。日本語対応していたのが当時はこれしかなかったのです。現在はKendraも日本語対応していますけどね。あとは実装量です。元々組み込まれているので実装量が少ないというのが、もう一つのメリットとしてもありました。
其阿彌：結果ですが自然言語処理のエンジンとしての採用は見送りました。いくつかの観点から見て概略すると、まずは回答精度ですね。弊社でも既に作っているものがあったのですが、そこと比較した時にちょっと現状よりも下がる。細かいチューニングをやってるわけじゃないので、どうしても下がっちゃいます。あとはコストですね、同じ程度かもしくはやや上がるというところで、ちょっとここも微妙でした。開発効率も標準機能だけなら良いのですが、弊社でやっているような複雑なChatBotだとちょっと機能が足りない。そんな感じでした。
今回は「保留」という結論でしたが、この領域はかなり進化が早いので、ここまで来ているのであれば、数年後に再評価すればその時には採用できるのではないかと個人的には見ています。
其阿彌：ここで、ちょっと近未来の話をしたいと思います。先ほど出てきたiPaaSですが、システム連携まわりの話でちょっと関わりがありまして、今なんかシステム連携となると、固定長やCSV、XML、APIだとREST、SOAP、RPC、GraphQLなど色々とあると思うんですけど、ここもきっちりとした定義が必要になるんですがここも楽がしたいですよね。
其阿彌：というところで、半分ネタなんですけども、自然言語によるシステム連携なんていうのも、先ほどのを組み合わせていくと出来なくもないのかなと個人的には考えています。ただし、これがまともに使えるのは早くても十数年後くらいかなとは思っています。
「今日休みます」って言えば、仲介してくれるエージェントみたいな感じでiPaaSが間にいて、勤怠システムに対しては休暇申請出してという風に連携をすればいいだけの話です。またチャットツールに対しては、ステータスを休みにしてチームメンバーに伝えて、とだけ設定する。オフィスツールに関しては、この人の休暇予定を作成して他のスケジュールを欠席にして、とだけ伝えれば良いような。そんなところです。
そういうファジーなシステム連携が実現できるんじゃないか、という風に考えています。
其阿彌：こういった形で、より多くの問題解決がアプリ連携を通してチャットツールへの適用ということで可能になっていきます。
楽しい機能を、楽しい環境で、楽しく開発しています
其阿彌：突然ですが、450万人という数字を出してみましたが、弊社製品（COMPANY）ユーザーの概算値です。先ほどの「より多くの問題解決」だけではなくて、より多くの「人」の問題解決も可能であるという風に、我々では考えています。
弊社は『「はたらく」を楽しく』、ということを目指してやっています。
そして、今回のセッションでは“裏テーマ”として、「楽しい機能を、楽しい環境で、楽しく開発しています」ということを伝えられたらいいかなとも思っていました。
其阿彌：あまり楽しい環境についてお話ができなかったので、ちょっとだけお話させていただきます。私の場合は、だいたい朝5時に起きて22時に寝ます。だいたい子供と一緒に寝ています。基本、生活は子供メインです。フレックスなので、子供の環境の変化に合わせています。
チームメンバーは夜型も多かったりするので、結構みんな自由に生活しています在宅勤務がメインなので、部署にもよりますけど、通勤はなくてすむ。もちろん、出社したい人は出社しています。
弊社に興味持っていただけたら、仕事についてはQiitaに弊社のOrganizationもあるので、見ていただけるとどんな感じで仕事をしているのかが垣間見えると思います。興味がある方は、ぜひ見ていただけたらと思います。
其阿彌：最後にSpecial Thanksということで、Marpに対してthanksを捧げたいと思っています。簡単にお伝えすると、この資料は全てMarkdownで作成しています。このページは以下のような感じで書くことで簡単に作れちゃいます。
其阿彌：凄くお世話になっているので宣伝しておきました。ご清聴いただきありがとうございました。
取材／文：長岡武司