本エントリは、ChatOps Advent Calendar の 25日目の記事です。昨日の記事は、@TasukuNakanoさんで「Rubotyが殺されるところを見届けた話をします」でした。
メリークリスマス！今年も残すところあと少しになりました。私はこの一年 bot に関わる仕事をしてきました。これまで取り組んできたことの反省と、これから取り組んでいきたいことについてまとめたいと思います。
hubot への期待と現実
私の所属する L is B では、ビジネス向けメッセンジャー direct を提供しています。チャットを通して業務の効率化を目指しています。この目標にとって hubot は魅力的かつ現実的なツールだったので、お客さまからの要望を反映しつつ hubot をベースにした SDK を提供してきました。
これまで、日報作成、案件管理、議事録代行、スケジュール管理、TODO管理、勤怠管理といったいろいろな業務用ボットを作成してきました。最近は blog でRaspberryPiでの動作なども紹介しています。
最初の評価は高いものがあります。しかし、なかなか継続利用されません。ちょうど @kotatsu360 さんが「ChatOpsのバッドノウハウ」を公開されていますが、まさにそんな感じで非常に共感できます。
それでも負けずに挑戦してきた、いくつかの取り組みを紹介したいと思います。
仮説1： 業務に沿った bot が作りにくい？
最初に考えていたのは、継続利用されないのは、ユーザの期待するような bot がないからで、誰でも bot を作りやすくすれば、もっと利用されるのではないか、というものでした。
オンラインで簡単に bot を作ることができるプロトタイプを作ったりもしました。でも、ちょっと考えればわかることですが、bot の内部がどのように作られているかなんて、bot を利用する人にとっては関係ないことです。むしろ、現場に合った細かい調整が効かないと使い勝手はよくなりません。
仮説2： チャットのコマンドは覚えるのが大変？
次に考えたのは、コマンドの入力が大変だから bot に何と話しかければいいかわからなくなって、めんどくさくなって話しかけなくなり、継続利用されないというものです。
そこで、hubot 内蔵の httpd を利用して、hubot の操作をチャット経由だけではなく、Webアプリからできるようにしたこともありました。しかし、これも「前より便利になったね」との声は頂きましたが、継続利用という点に関してはなかなか改善されません。
仮説3： 業務が自動化されていない？
そもそも hubot は、何ができるのでしょうか。何でもできるフレームワークですが、その範囲は hubot が動作するサーバや、そこからつながるインターネットの「世界」に限定されます。実際の業務は、もしかしたらまだオンラインではなかったり、オンラインだとしても接続できる環境ではないのかもしれません。
限定された「世界」でジョブを実行する人工知能
一般的な会話をする bot として、ELIZA が有名です。Twitter の bot のような人工無能と呼ばれる会話プログラムの基礎といえます。
その一方で、特定のことしか知らず・できないけれども、指示を受けつけて実際の行動に移せるタイプの bot があります。1971年に発表されたSHRDLU はその代表で、積み木の世界に閉じていますが、指示を受けとって積み木を操作できました。hubot の起源ともいえるでしょう。
Person: PICK UP A BIG RED BLOCK.
Computer: OK. (does it)
hubot を業務利用するためには
下の図は DEIS と呼ばれる、オープンソースの PaaS プロジェクトからの引用です。上の図と似てないでしょうか？
docker が登場し、ソフトウェアはコンテナ化されて、サービスは積み木を組み立てるように構成することができるようになってきました。そんな DevOps が普及してきたからこそ、hubot はチャットを通して業務代行ができて、非常に賢い bot として振る舞うことができると考えるようになってきました。つまり、業務フローが自動化できた後こそ、hubot が活躍できるということです。この仮説が正しいのかはまだ検討中で、来年にかけて取り組んでいきたいと思います。
さいごに
来年は、ビッグデータや Deep Learning といった技術を基盤にしたサービスがさらに普及して、業務プロセスの自動化が進むんじゃないかと考えています。LisB では、データサイエンティスト、ロボティクスなどに興味を持つメンバーを募集しています！