読者です 読者をやめる 読者になる 読者になる

アニメイトラボ開発者ブログ

株式会社アニメイトラボの開発者ブログです

アニメイトラボ開発者ブログ

developer.animatelab.com

非エンジニアが自然とChatOpsを使いこなせるようになった話

はじめまして！ アニメイトラボのサーバーサイドエンジニアの@MacoTasuです！ 本日で入社から二週間に経ちました！めでたい🙏

はじめての執筆ということもあり、前職での知見について書きたいと思います。自分が実際に前職でChatOpsを使った経験で、導入の経緯、良かったことなどについて書きたいと思います。

この記事はanimateLab AdventCalender2015の17日目です。

qiita.com

ChatOpsとは

ChatOpsとは、チャット上で何か特定の発言をしてそれに応じて特定のオペレーションを実行する方法です。
例えば、SlackのBotにメッセージを投げるだけで、データを取り込むなどですね。

ChatOpsをなぜ導入したのか

開発の規模が少人数のときは、すべてエンジニアが温かみある手作業で開発サーバーへのデータの取り込みやデプロイなどを行っていました。

開発サーバーへのデプロイは、エンジニア以外のポジションの人も行いたいケースがよくありますよね？
例を挙げると

  • プロダクトがどこまでできているか確認したいから最新のブランチを開発サーバーにデプロイしたい！
  • 作成したデータを目視確認したいから開発サーバーに取り込んでほしい！！
  • 外部の人に公開する用の環境を開発サーバーに用意したい！！！！
  • etc...

ぱっと考えただけでもいくつもでてきます。
チーム人数が少ない時は大丈夫だったのですが、開発規模が大きくなってくるとそうはいきません。
自分の経験なのですが、エンジニアが体調不良で休み、自分だけしかサーバーサイドエンジニアがいない状況の時に、一日データ取り込みとデプロイで終わってしまったということがありました。
こうなると本来の仕事が全く進みません。また、依頼が同時多発的に発生した場合はもっと危険。。。当たり前ですが、エンジニアは聖徳太子ではありません。頼んだ人も待たされるし、本人はテンパってるしで、誰も幸せにならない状態でした。つまるところ、

＿人人人人人人人人人人人人人人＿
＞　エンジニアがSPOFに！！！　＜
￣Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y￣

※SPOFとは

つらい。

ここで「エンジニアが仮に何らかの原因で全員休んでしまっても、開発を回すための仕組みがすぐにでも必要なのでは！？」と考えました。

...エンジニアが不在でも代わりに働いてくれる何か...そして、黙々と仕事をこなしてくれる...文句を言わず...あっ！...Bo...Botや！！！！

ということで「Botにすべてやらせればええんや！」となり、Botを使ったChatOpsを導入することになりました。

非エンジニアを巻き込むには？

組織的にChatOpsの導入に伴い、他職種の方々に浸透させるられるのか？という不安が頭をよぎると思います。
残念ながら銀の弾丸は思いついていないので、実際に自分がおこなった方法を紹介します。

まずはじめに実際にBotを用いたデプロイを自分で積極的に使っていきました。
こうすることで、実際に使ってみて便利なのかユーザ視点に立てるし、みんなが見ているSlack上で大胆に行うことで、他職種の方の目に自然に触れ徐々に周知できます。

Slackで

MacoTasu: bot-kun deploy master
bot-kun: デプロイを始めるね！

...

bot-kun:  @MacoTasuデプロイしたよ！！！！
ディレクター: (何かが勝手にデプロイしたぞ...!)
デザイナー: (何かが勝手にデプロイしたぞ...!)

こんな感じで徐々にBotの存在を広めていきました。
勘のいい人なら「エンジニアがいなくてもデプロイできるようになってる？」ということにこの時点で気づいたりしていました。

実はやったのはこれだけ。後はChatOpsの方法を説明してBotを使ってくださいと説明しただけなんです。
Botが何かしらの問題を解決する機能を持っている時点でそれは便利なのもの。便利なものは自然と使われるし、徐々に周知させていたこともあって導入に大きな障壁はありませんでした。

また導入をするのが比較的簡単だった別の背景として、他のチームではすでにBotを用いて色々自動化していたので、Botを導入することで便利になるということが、みんなの意識の中にあったのも大きく影響していると思います。

導入して良くなった3つのポイント

  • エンジニア以外の職種の人がエンジニアの仕事をこなせるようになった

Chatという誰でも使えるインターフェースを通して、エンジニアの仕事をこなせるようにしたことで、皆が気軽に開発環境に対して様々な操作をできるようになりました。
今まではエンジニアに頼みに行って、対応が終わるのを待って次の仕事にとりかかるといったことをしていたのが、Botにメッセージを送るだけで、瞬時にオペレーションが開始されるのですぐに次の仕事に取り掛かることができていました。大きな業務改善ですね。

  • 逆にBotで自動化できない？という提案が出るようになった

Botを使いこなすことで、開発に頼まなくてもエンジニアの業務がある程度できるようになるということをメンバーが理解すると、「Botを使って◯◯を自動化できないか？」という相談が出るようになりました。
もちろん、エンジニアたるもの、自動化できそうなものは見つけ次第そうしていくのですが、全てに気付けるというわけではありません。
そういった意味でも、エンジニアが今まで見えてなかった範囲の問題が表に出てきて、それを解決できるきっかけができたのですごく良かったです

  • エンジニアが本来の費やすべき職務に時間を避けるようになった

本来これをしたくて導入したので、これはもちろん解決できました。

全体的に問題解決がなされ、開発効率が向上しました。

Botを使ったChatOpsの課題について

  • Botのメンテナンスが開発者依存になりがち

Botを作った人が特定の誰かの場合、Botに何かしらの不具合があった時に直すのが開発者依存になりがちです。
何かに依存しすぎることはSPOFになりうるので、個人的にはあまり好ましくないと思います。
Botのコードは勢いで作成した面もあって、自分のGithubのRepositoryに作成していました。
そうしたことで、そのコードは開発した自分だけが保守するという印象を周囲に与えていたのが良くなかったかなと反省しています。
組織で使うものは所属する組織のRepositoryに作る。こうすると、みんなで保守していく意識が強くなるのかなと思いました。

  • コマンドが増えるとBotに送るコマンドの記法が覚えられない

Botにおくるコマンドが増えると、記法を覚えるのが大変という問題がでてきます。
例えば、

bot-kun: deploy <対象のサーバー> <デプロイするブランチ>

上記のようなコマンドの指定があった場合に、指定の順序を間違えてしまったりなどはあるあるだとおもいます。
Readmeにコマンドの指定方法を書いているので、それを見に行けばいいのですが、毎回それを見に行くのは大変です。
解決方法として、空白区切りではなくkey => valueな感じで指定できるようにしてあげて順序依存を無くすというのも一つの手です。
が、その方法だとkeyの分もメッセージを打つ必要があります。結果的に、文字列を入力するのが面倒に感じることにつながってしまいます。
この解決策として、「snippetおじさん」と言われていたぐらいsnippetを使っていたので、それを使って

`deploy

とチャットの入力欄に入力すると、デプロイに必要なコマンドがそこで自動展開されるように設定していました。
これを使えばkey => valueを使っても簡単に入力できるので問題ないです。
※snippetを使う際におすすめのMacアプリでDashというものがあるので是非使ってみてください。

Goで自作Botを作ってみよう

この記事を読んで自作Botを作って実際に動かしたいと思った人のために、Goのpackageをいくつか紹介したいと思います。

IRCにBotを導入するには@m0t0k1ch1氏作のapeを使うと簡単に導入できます。詳しくは彼のブログをご参照ください。

また、SlackにBotを導入させるのに@shogo82148氏作のapeのslack版のape-slackを導入できます。こちらも詳しくは彼のブログをご参照ください。

最後に

繰り返しになりますがChatOpsを使う最大のメリットは、ポジションに関係なくエンジニアがやるべき仕事をChatを通してできるようになることだと思います。
同じ問題を抱えているような方は、あらゆる手動作業をBotに逃がして是非ChatOpsを実践してみてはいかがでしょうか？

以上です。ここまでお読みいただきありがとうございました！