こんにちは。CTOの前田です。
この記事はロコガイド Advent Calendar 2020の8日目です。
弊社には社内ITシステムや機器管理を行う専門の部署として、ITシステム部が存在します。
日々の問い合わせ対応、困りごとの解消など、所謂helpdesk業務が重要業務の一つですが、内容はPCの故障から、ソフトウェア利用方法の問い合わせ、環境整備の依頼まで多岐にわたり、依頼者の作業のブロッカーになっているケースが多いため迅速な解決が求められます。
一方でこれらの対応だけではなく、中長期的な目標、全社の生産性を向上させるための抜本的な改善も重要な責務です。
これらの問い合わせ対応・自部門主導の改善活動の進捗を可視化し、ITシステム部の作業効率を改善させることを狙いとして行った「ワークフロー改善」についてご紹介します。
ワークフローの概要
依頼作業は全てSlack上で行われており、今までのSlackのスレッドでやり取りを行って各担当者が個人で管理をしていました。
しかし、個人管理では対応状況が不透明になってしまい、個人へのタスクの偏りや抜け漏れの検出も不可能です。
そこでチケット管理システムの導入を検討しましたが、以下のようにカジュアルな質問も非常に多く、チケット管理システムへ各依頼者が入力をする運用は依頼者に負担を強いてしまいます。
利用者の利便性と、部内での管理コストの軽減の双方を満たす構成として、Jira SoftwareとRubotyを組み合わせたワークフローを採用することに決めました。
Jira Softwareの採用理由
SlackのGroup Mentionの運用は一定根付いていたため、この運用を活かした形として以下の要件でワークフローの設計とチケット管理システムの比較を行いました。
- 依頼者は今までの運用を変える必要がないこと
- 依頼が全てチケットに起票され、対応状況のステータスが管理できること
- 中長期で取り組むタスクも同様に管理できること
社内では他部門も含めてGitHub Issue + ZenHubの活用が最も活発ですが、ITシステム部門の業務ワークフローの都合上、入退職などの人事情報を取り扱うこともあり、ITシステム部の管理領域へはアクセス制限が必須要件です。
アクセス制限を適切に行うためには、権限の制御が細やかに行える必要があります。
GitHub IssueやAsana, Redmine等の候補の中から、ワークフローの設計やIssueに記載する設定項目の自由度が高いこと、権限の細やかな設定などカスタマイズが最も柔軟に行えることからJira Softwareの採用を決めました。
Jira Softwareを中心としたワークフロー
Jira Softwareはカスタマイズ性に優れるがゆえに様々な利用形態がありますが、ITシステム部においては次世代ボードを中心として利用しています。
「Backlog」「Inquiry」「Current」「Done」「IceBox」の各ステータスレーンで管理をし、自部門で中長期で取り組むタスクについては、ロードマップ機能で期間を決め、取り組むタスクをぶら下げて管理をしています。
BacklogはITシステム部自部門が起票したIssueが全て入ってくる置き場です。日々発生するタスクや、アイデアがこのレーンに集積されます。
基本のフローとしてはBacklogから着手した or 近日着手するIssueはCurrentに移動し、完了するとDoneに移動する流れとなります。
こういった管理を始めるとどうしても長期間残存するIssueが発生してきますが、IceBoxはBacklogに長くストックされているIssueを退避してBacklogの見通しを良くするのに利用しています。
前述した社内からの依頼については自部門タスクとは緊急度が異なることが多く、滞留が依頼者を困らせてしまう結果につながってしまいます。
そのため、依頼対応は全てInquiryレーンにIssueが作成されるようにワークフローを組み、他のIssueにまぎれてしまわないように管理を行っています。
これらのワークフローを導入したことで、短期、中期の見通しが良くなり、短期的な問題のみではなく先々の計画についても議論がしやすくなりました。
ロードマップとボードの状態を毎週の定例で確認をすることで、相互のタスクの見通しが良くなったと実感しています。
Rubotyによる自動起票
ここまでの運用によって透明性は向上しますが、依頼者とのシームレスな連携は実現することが出来ていません。
ITシステム部ではその実現のためにChatbot(Ruboty)を利用して、依頼内容がJira Softwareに自動起票されるようにしています。
RubotyはRuby製のChatBotです。 「@ruboty ping」のように直接mentionを行うことでコマンド実行する使い方が一般的ですが、参加チャンネルの全発言を確認し、特定のパターンに合致した時に処理を実行することが出来ます。
以下は抜粋したサンプルコードです。*1
今回の利用ケースではRuboty::Handlers::Base.on メソッドに引き渡す all: true オプションが重要な働きをしています。
require 'ruboty' require 'jira-ruby' module Ruboty module Helpdesk class Handler < Handlers::Base MENTION_NAME = 't_hd' NOTIFY_CHANNEL = 'SLACKCHANNELID' on /@#{MENTION_NAME}(?<body>(.|\R)+)/, name: :post_to_jira, description: 'Create issue to helpdesk Jira organization.', all: true def post_to_jira(message) issue = jira_client.Issue.build issue.save!({ 'fields' => { 'summary' => truncate_summary(message.match_data[:body]), 'project' => { 'key' => project.key }, 'issuetype' => { 'id' => '10001' }, # Task IssueType 'description' => build_issue_description(message), } }) transition = jira_client.Transition.all(issue: issue).find { |t| t.name == 'Inquiry' } issue.transitions.build.save!('transition' => { 'id' => transition.id }) message.reply( build_reply_message(message, issue, assignee), to: NOTIFY_CHANNEL ) end end end end
all: trueを設定しない場合には、設定されたRUBOTY_NAME(デフォルトruboty)をprefixとして発言が正規表現がマッチするかを確認しています。
allを設定することでRUBOTY_NAMEを確認しなくなるため参加チャンネルの全発言を確認対象とすることができ、team mentionの捕捉が可能になります。
この機構があることで日々寄せられる依頼に対してチームで取り組むことが出来るようになったと実感しています。
最後に
今までご紹介した取り組みで、
- 依頼者は今までの運用を変える必要がないこと
- 依頼が全てチケットに起票され、対応状況のステータスが管理できること
- 中長期で取り組むタスクも同様に管理できること
以上の3要件を満たすことができました。
運用を開始して約1ヶ月ほどですが、作業状況の透明性が向上し、長期の見通しを定期的にチームで見直す事ができるようになりました。
実際にどれだけの課題を解決出来るか、全社が快適に働く環境をどれだけコストパフォーマンス高く構築出来るかはこれからの取組み次第ですが、部門全体で課題に対して取り組むためのベースは作ることが出来たかなと感じています。
PR
ITシステム部は自部門の問題解決だけではなく、全社の運用 / システム改善をアグレッシブに進めていきたいと考えています。
共にコーポレートエンジニアリングを行っていただける方、是非TwitterのDMなどでお声がけいただければ嬉しいです！
ご転職を考えられていなくとも、カジュアルにお話できると嬉しいです:-)
*1:サンプルコードにする過程で関連メソッドを全て削除しているためそのままでは動きません
