ChatOpsという話をしたときに、
社内で認識のすれ違いがあったりしたので、少しまとめてみました。
間違いがあれば指摘して頂ければ泣いて喜びます。

ChatOpsの歴史

hubotのリリース

2011年、hubotというchatbotフレームワークがGitHubよりリリースされました。

hubotは拡張性が高い、非常に良くできたフレームワークでした。
redis、MySQL、yamlと様々なツールを使って、データを保持することができ、
slack、Hipchat、IRCなど、様々なチャットツールと接続するアダプタを用意することが容易でした。

機能の再利用性も高かったため、hubotは様々な人に利用されるchatbotフレームワークとなりました。

PuppetConf 2012において、GitHubはhubotを用いたChatOpsという概念を発表します。

この発表においてhubotは、ciの実行、Pull Request のmerge、自動デプロイ、log出力、リソースグラフの出力。
など様々な役割を持っていました。

ChatOpsの主な利点としては、下記の４点が挙げられています。

この発表時点のChatOpsという概念は、
人がchatbotにメッセージを送り、タスクを実行させる。
そして、その結果をチーム全体で共有するといったものでした。

しかしながら、時間の経過とともにその概念は変化していきます。

現在、SentryやDatadog、Mackerel、NewRelicなど、SaaS自体がChatサービスと連携する機能を持つようになりました。

その結果、ChatOpsという概念が、SaaSなどのツールも含みはじめました。
ChatBotはChatOpsのさらなる効率化を図るツール
という位置づけで話をされることさえあります。

現在ChatOpsの概念は、どちらが主流なのかは分かりません。
もしかしたら、SaaSを含んだ概念はある種特殊なものかも知れません。
とはいえ、ChatOpsという開発手法には、ChatBotを含まない可能性もありうるというところだけ
認識しておくと、無駄なすれ違いを発生させないかも知れません。