20
Help us understand the problem. What are the problem?

More than 5 years have passed since last update.

posted at

updated at

Organization

kpt-bot を使って KPT も Slack に集約しよう

この記事は Slack Advent Calendar 2016 の 13 日目を「代わりに投稿する」機能を使って乗っ取ろうとしたが先を越されてしまい「もう Advent Calendar 関係なく投稿したろか」と思った矢先に偶然空いた 17 日目を乗っ取った記事です。

KPT を行うツールも Slack に集約することで情報共有のハードルを下げ、改善の質を高めようという話です。

TL;DR

Slack に K バグを早期に発見した, P 遅延が発生した, T スケジュールを見直す のように接頭辞 K, P, T から始まる投稿をしておくと、それをまとめて整形してくれる Slack bot を作りました。

2016-12-16 0 28 30

KPT について

KPT は振り返りの手法・フレームワークの一つです。ある期間内の出来事を以下の3つに分類し、次の活動の品質・生産性向上を図るものです。

  • Keep: よかったこと、続けたいこと
  • Problem: うまくいかなかったこと、問題
  • Try: 試したいこと、改善案、挑戦

ミーティング前の仕込みが大事

無策でミーティングの場に特攻して KPT を挙げていくやり方もありますが、ミーティングの前に書き溜めておいた方が間違いなく質が高くなります。特に、事前にメンバーが閲覧出来る場所にまとまっているとなおよいです。

予め話す内容をまとめておく、知っておくことで議論の質が上がることはもちろん、ミーティングが終わった後に「そういえばアレも話せばよかった…」というような議題の上げ忘れも減ります。

また、誰かが目に見えるところに KPT を書き込むことで、「そういえば関連してこんなことも…」とか「その問題なら既に解決したよ」というような KPT の相乗効果が生まれます。情報はオープンな場所にあるだけで勝手に拡散・増幅するものです。

つまり、振り返りの質は振り返るミーティングよりも日常での仕込みによって決まるというわけです。

KPT を行うツールと課題

KPT tool などでググってもらえると既にいくつものツールがあることがわかります。

基本的にはチームで行うので、共同編集が可能な web アプリが多いようです。いずれも綺麗に整形できたりサインアップ不要でさっと使い始められるようになっています。

しかし、いかんせん新しいものを取り入れようとすると「普段使うツールになるまで時間がかかる」という課題があります。

弊社でも以前 http://www.retrospected.com/ というサービスを8人のチームで使っていたのですが、なかなか意見が集まりませんでした。

この web サイトを皆が常に開いているわけでなく、KPT の直前になって思い出して開いてみたら空だったとか、外出しているとこのサイトの共同編集ページにたどり着くのが難しくて書き漏らしてしまう、というような課題がありました。

「てきとうなところにメモしてあとでコピーすればよい」という指摘はまったく正しいのですが、この心理的ハードルは馬鹿にできないです。

解決策 1: GitHub に KPT メモをつくる

「普段使いのツールじゃないから手軽に書けない」のなら、普段使っている GitHub や Slack に書けばよい、Slack だと情報が流れてしまうので GitHub Issues にメモしていこう、ということになりました。

kpt.png

こんな感じです。

これは結構うまく機能しました。アイデアを思いついた時に大概 GitHub を開いているので、パッと書き込むことができます。

しかしまだちょっとした課題があります。

  • KPT 用の issue に辿り着くのに一手間
  • それぞれのコメントに散らばった KPT をあとでまとめるのが面倒
  • issue へ書き込まれた内容を通知として受け取っている人もそうでない人もいる

もっと目に見える場所に手軽にポストしたい、かつ運用負担を下げたいのです。

解決策 2: Slack に KPT メモをつくり、bot にまとめさせる

Slack (や類似したチャットアプリケーション)は私達にとって最も使用頻度の高いツールです。開発者はもちろん、そうでないメンバーも Slack には常駐していることが多いですし、また、スマートフォンからも気軽に閲覧・書き込みできるのも利点です。

Slack こそが最も気軽にアイデアをメモできる場所だと個人的には思っています。

ただ、如何せんチャットなので情報がどんどん流れていってしまいますし、専用のチャンネルを作ったとしてもばらばらに発言されたものを後でまとめるのはちょっとしんどいです。

そこで、最初に紹介した kpt-bot に集計をやらせようと思いつきました。

kpt-bot について

Botkit 製の Slack bot です。

Botkit 自体は Slack だけでなく Facebook Messenger や Twilio IP Messaging にも対応しています。詳細は本家の GitHub レポジトリをご参照ください。

同じく代表的な bot フレームワークである hubot との違いは正直あまりよくわかっていませんが、メッセージの受信方法の多様性が特徴として挙げられるようです。

サッと試してみたい場合は botkit-studio-starter でシュッと遊んでみるのがよいと思います。

実装

1ファイルにねじ込めるぐらいの量しかない、かつごく基本的な機能しか使っていないのであまり書くことがありませんが…。

Node v7 / ES6

最近 JavaScript を書く量が減っていて勉強不足を感じていたので、Node v7 / ES6 で書きました。

bot 自体は3時間ぐらいで書いたのですが、 ES6 の文法をちゃんと勉強していなかったのでそのあたりの検索に一番時間を使ってしまいました。ES5 の文法でも書けてしまうので、これはもっと良い書き方があるんじゃないか…という気が拭えません。

書いていて思ったのですが、Botkit は Node.js 上で動作するので Babel も必要ないですし、純粋に ES6 を使って何か書いてみたい・作ってみたいと言う時にはおすすめかもしれません。

メッセージの待受け

kpt-bot は @kpt-bot summary 2016/12/01 2016/12/31 のような呼びかけに応答します。

hears メソッドの引数にて反応したいワードや正規表現を指定できます。マッチした値を取り出すことでコマンドラインライクな呼び出しも可能です。

controller.hears("^summary (.+)",["direct_message","direct_mention","mention"], (bot, message) => {
  const [from_date, to_date] = message.match[1].split(' ');
  ...
  bot.reply(message, summary);
}

Slack API を呼ぶ

Botkit 内で Slack API をコールするのは簡単です。

bot.api.callAPI('users.list', params, callback)

ただし全ての API を呼び出せるわけではなく、制限されている API を呼ぶと user_is_bot エラーが起きます。使える一覧は https://api.slack.com/bot-users にまとまっています。

callAPI に callback 関数を渡せるのは良いのですが、Promise 的なことをどうやるのかがわからない…。今回は callback ネストで済ませてしまいましたが、ご存知の方いたら教えてください。

動かす

まずはローカルで動かすにはこんな感じ。

git clone git@github.com:ohbarye/kpt-bot.git
npm install
SLACK_BOT_TOKEN=your-slack-bot-token node index.js

省略しますが、シンプルな Node.js アプリケーションなので heroku deploy も簡単です。

導入するとどうなる

さて、最も大事なこの KPT bot を実際に運用するとどうなるでしょうか?

先に述べたような発言のハードルや KPT 運用に伴う雑務が解消され、
皆が思いつきを気軽に投稿できるようになり、
提案漏れは減り、
その手軽さゆえ大小様々な改善提案が闊達になされるようになり、
KPT bot の発言ランキング機能(未実装)により誰もが KPT に情熱を注ぐようになり、
https://github.com/ohbarye/kpt-bot レポジトリにスターが1個ぐらいつくんじゃないかなと予想しています。

はい、実はまだ運用していません。

会社でやったことは「KPT bot を導入してはどうか?」という Try を GitHub Issues に書いただけです…。 :innocent:

もし採用されたら導入した結果も後日書ければと思います。

Quipper の Japan web team, native team で各々試してみることになりました。運用結果の報告もまたの機会に。

まとめ

KPT フレームワークを使った振り返りは、導入は簡単なので広く使われていると思います。しかし、簡単ゆえに「振り返るにもそれなりの技術が必要」という面が見過ごされているケースも少なくないんじゃないかなと個人的には思っています。

チームメンバーから KPT がなかなか挙がってこない、KPT ミーティングが盛り上がらない、というような問題がある時にはチームメンバーを促すだけではなく、正しいやり方・やりやすい運用がなされているかを振り返るべきかもしれません。

それでは2016年末、良い振り返りを!

Why not register and get more from Qiita?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
Sign upLogin
20
Help us understand the problem. What are the problem?