ユニファ開発者ブログ

ユニファ株式会社システム開発部メンバーによるブログです。

JIRA + re:dash + Slackで運用にかかった工数を週次で通知してみる

こんにちは、Webエンジニアの本間です。 最近、ランニングを始めまして、業務後に家の近くを走っています。 走り終わると頭の中のもやもやスッと抜けてて、とても爽快です。1人でできるスポーツですし、今後も続けていきたいなーと思っています。

さて話は変わりまして、弊社ではチケット管理にAtlassian社の JIRA を使っています。 チケットは、要望や機能追加、不具合修正などのコード修正を伴うものと、障害調査やエンジニア作業などコード修正を伴わないものがあり、後者を「運用作業」として区別して管理しています。

「運用作業」は新しい価値を生み出さない時間であるため、0かそれに近い値になっていることが望ましいです。 これを減らすためには色々な対策が必要になりますが、まずは「エンジニア自身がどれだけ運用作業に工数を使っているか、日々意識する」ことが大事なのではと考えました。

これを実現するため、毎週どれだけ運用作業に工数を使ったかSlackに通知する仕組みを作ったので、紹介しようと思います。(下のグラフが毎週月曜日の10時にSlackに通知されます)

f:id:ryu39:20180319100536p:plain

前提

以下の環境が揃っていることが前提です

  • JIRAを使っている
  • re:dash(0.12.0以上、できればv3.0.0以上)が稼働している、もしくはオンラインサービス版のre:dashを使用している
  • Slackを社内で使っている

やったこと

JIRA

JIRA上で必要な作業は、「運用作業にかかった工数を記録する」だけです。 弊社では、以下のルールで運用しています。

  • 運用作業をした場合、「運用」というラベルを貼る
  • 「開発工数」というカスタム属性を追加しており、ここに運用作業にかかった工数を分単位で入力する

re:dash

弊社では色々なデータの可視化に re:dash を社内に設置して、使っています。

このre:dash上で、JIRAから運用作業に関する情報を取得して、いい感じのグラフを作ります。

データソースの設定

re:dashでJIRAの情報を扱うためには、「JIRA(JQL)」というタイプのデータソースを追加する必要があります(v0.12.0で追加)。 re:dashに管理者権限でログインし、データソースを追加します。

f:id:ryu39:20180316172600p:plain

Type
「JIRA(JQL)」を選択
Name
「JIRA」など、わかりやすい名前をつける
JIRA URL
JIRAのトップページのURL
Username
JIRAにログインできるユーザーID
Password
Usernameに指定したユーザーのパスワード

ユーザーIDとパスワードを指定しないといけないので、re:dash専用ユーザーを1人作成して、このユーザーのIDとパスワードを指定するのがいいと思います。 保存したら「Test Connection」を実行します。「Success」と表示されれば、OKです。

上記に加えて、v3.0.0から追加された「Query Result」のデータソースを追加しておくと、JIRAから取得した結果に対してSQLで集計をかけられるので便利です。

f:id:ryu39:20180316173537p:plain

Type
「Query Result(Beta)」を選択
Name
「Query Result」など、わかりやすい名前をつける

JIRAからチケット一覧を取得

さきほど作成した「JIRA(JQL)」のデータソースを選択して、re:dashでJIRAのチケット情報一覧を取得してみます。

情報を取得するためには、JSONで条件を指定する必要があります。 参考までに弊社で設定しているJSON(セキュリティの関係で、一部変更しています)は以下のようになっています。

{
    "fields": "key,summary,status,created,customfield_99999,creator",
    "jql": "project = UNIFA AND labels = 運用 AND 開発工数  > 0 order by created DESC",
    "fieldMapping": {
        "customfield_99999": "developer_minutes"
    }
}
fields
取得したい列をカンマ区切りで指定
jql
チケットの絞り込み、ソート条件を指定。ここで、運用作業に関するチケットだけヒットするように指定する。JIRAのチケット検索画面で「Advanced」を選択すると表示されるので、それをそのままコピー&ペーストで問題なし。詳細はJIRAの 公式ドキュメント を参照
fieldMapping
カスタム属性(customfield_99999)は名前がわかりづらいので、わかりやすい名前に変更しています

上記以外にも設定可能な属性はあります。詳しくは、re:dashの 公式ドキュメント を参照してください。

ここで「Execute」を実行すると、運用作業のチケットが新しく作成された順に100件取得することができます。

この結果を元にグラフを作っても良いのですが、「Query Result」のデータソースを使って、週次での工数を集計したグラフにしてみようと思います。 新しいクエリを作る前にこのクエリを保存し、 URLの末尾に記載されている数字 をメモしてください。

QueryResultで週次で集計

JIRA(JQL)だけでは週次での集計ができないので、Query Resultのクエリランナーを使います。 「Query Result」は、OSS版ではv3.0.0から追加された機能なのですが、他クエリの結果をsqliteのインメモリに保存して、そこに対してSQLを実行できるものになります。 SQLが使えれば、週次での集計もそれほど難しくないのでやってみます。

まずデータソースで先ほど設定した「Query Result(Beta)」のデータソースを選びます。

次に、とりあえずJIRAのチケット一覧のクエリ結果が取得できるか、確認してみます。 クエリ番号には、さきほどメモしたURLの末尾の数字を指定します。

SELECT * FROM QUERY_クエリ番号

問題なく結果が表示されるようであれば、週次で開発工数(developer_minutes)を合計するSQLを書いてみます。

週への変換は、 sqlite の strftime 関数が使えるため、こちらを使っています。 ただし、JIRAとSQLが想定する日時形式の文字列が異なるせいか、そのまま関数に渡してもエラーになってしまったため substr 関数で先頭から日付部分の文字列を切り出して変換しています。 (ここは、もっとよい方法があれば、是非アドバイスいただきたいです)

最終的には以下のようなSQLになっています。 (このSQLだと、チケットが1つもない週は行として表示されません。実際はもう少し複雑なSQLにして、チケットがない週は工数0として表示されるようにしています)

SELECT strftime('%Y年%W週', substr(created, 0, 11)) AS created_week,
       SUM(developer_minutes) AS developer_minutes
FROM query_クエリ番号
GROUP BY strftime('%Y年%W週', substr(created, 0, 11))

実行すると、「年週」と「合計工数」の結果が表示されます。

f:id:ryu39:20180316192907p:plain

あとは「年週」をX軸に、「合計工数」をY軸にとってグラフを作れば、週ごとの運用工数の遷移グラフができます。

f:id:ryu39:20180316193058p:plain

最後に スケジュールを設定 します。設定を行わないと結果がずっと変わらないため。 今回は、日次で更新するようにスケジュール設定しています。

ここまでできたら グラフを表示した状態のURL をメモしておいてください。

Slack

まず 公式のSlack App を追加します。「Add to Slack」を押して、次の画面で「Authorize」を選択すればOKです。

次にre:dashのグラフを表示したいチャンネルにredash appをinviteします。名前を変更していなければ /invite @redash でいけるはずです。

ここまでできたら、先ほどメモしたre:dashのグラフのURLを貼り付けてつぶやいてみてください。 数秒経ってredash appがグラフを表示してくれたら成功です!!

f:id:ryu39:20180319100536p:plain

あとはSlackのreminderの機能を使って、週次で通知するようにすれば完成です。 以下の例では、毎週月曜日の10時に通知するようにしています。

/remind #チャンネル名 “re:dashのグラフURL” at 10:00 every Monday

まとめ

今回、JIRAに保存されている運用工数のデータをre:dashとSlackを使って、定期的に集計して通知する仕組みを作りました。 社内で稼働中のインフラやサービスの機能を活用し、コードレス、追加のインフラなしでうまいこと実現できたかな、と感じています。

この施策によって、運用工数の状況を可視化することはできたと思うので、これを0にするために色々取り組んで行きたいなと思っています。

以上になります、最後までご覧いただきありがとうございました。