業務効率化のためのシステム導入－JIRA・Confluence（後編）－

本日はJIRA・Confluenceをどのような事例で導入したのか、あるEC通販企業での具体的な事例を用いて説明したいと思います。実現したことは、事業部や従業員個人からの、バックオフィス部門への依頼を全てJIRA上に統合することです。これにより、社内工数の削減やバックオフィス部門の工数の可視化に役立ちました。

具体的に何をしたかというと、JIRAのProjectと連動するJIRA Service Deskというツールを導入し、事業部や従業員個人からバックオフィス部門への依頼を最終的に上記サービスデスク経由でしか依頼を受け付けないよう業務プロセスを変更したのです。それまでは、メール・口頭依頼・MTG時の依頼など様々な依頼方法があったものを、全て一つのシステム経由でしか受付無いようルールを変更し仕組みを導入したのです。この記事では、どのようにそのようなやり方を実装していったのかを説明したいと思います。

なお、JIRA・Confluenceとは何か？という点は業務効率化のためのシステム導入－JIRA・Confluence（前編）－にて説明しておりますので、まだ記事を読んでいない方はそちらを読んでから、本記事をお読みください。

＜目次＞

＜前編＞

３．導入までの手順

３．１．社内要望により案件が発生する部署に導入

３．２．導入スケジュール・方法

４．導入により実現できたこと

４．１．開発課の事務的な定型業務の削減

４．２．マネジメント層の開発状況のリアルタイム把握

４．３．パフォーマンスの向上

３．導入までの手順

３．１．社内要望により案件が発生する部署に導入

まずこのEC通販企業では、バックオフィス部門には、システム部・コールセンター部・財務経理部・人事総務部・社内コンサル部の5つの部門がありましたので、どの部署から導入をしていくかを検討しました。その中で、真っ先に業務効率化の対象にしてJIRAServiceDeskの導入対象となったのはシステム部でした。なぜならシステム部だけは、事業部からの依頼に基づき案件を動かす割合が他のバックオフィス部門と比較して圧倒的に多かったのです。すなわち社内要望により案件が発生する部署が導入の第一条件となりました。システム部以外の部署は、事業部から頻繁に依頼が来るような構造では無かったのでいったんJIRAServiceDeskの初期の導入対象からは除外しました（※最終的には全バックオフィス部門に導入することになります）。

システム部は

・開発課・・・社内システムの開発・保守を担当

・社内インフラ課・・・PC・電話・ネットワークなどの開発を伴わない社内システムの保守を担当

・制作課・・・販促チラシ・販促PRページの企画・制作を担当

・運用課・・・システム化されていない運用を担当

という４つの課に分かれており、運用課以外の部署は基本依頼は事業部や他のバックオフィス部門起因で案件が発生するため、開発課・社内インフラ課・制作課の3つをJIRAServiceDesk構築の対象としました。

３．２．導入スケジュール・方法

それぞれの課ごとのサービスデスクの作成は私が手を動かして、各課の課長と確認しながら推進し、一つの課につき社内広報含めて、1ヶ月（4週間）程度のスピード感で依頼方法を切り替えていきました。これは導入を推進していたのが私一人でかつどのベンダーも使っていないという、最低限のリソースでの実現スケジュールですので、遅くとも一人専任担当がいればこれぐらいはできると思ってください。

ではこの1ヶ月（4週間）どのように区切って導入していったかを具体的に説明していきましょう。

＜導入スケジュールと導入方法＞

	蓮沼の実施事項	導入側の課の実施事項
1週目	・管理項目のヒアリングと設定 ・運用WFのヒアリングと設定 ※上記を２サイクル程度実施	・左記の決定MTGに参加・意見だし
2週目	・Confluenceで使い方マニュアルの作成 ・社内広報の実施 ※管理項目・運用WFの改訂要望があれば実施	・課内広報 ・テストデータを入力して、運用方法を確認 ・管理項目・運用WFを変更したい場合には蓮沼に連絡
3週目	・社内勉強会の実施	・社内勉強会に参加
4週目	※予備期間	※予備期間

まず1週目に導入側の課の課長とのMTGを最低2回入れ基本的な運用WFをこの時点で構築しておきます。1回目は実装に向けてのヒアリングがメインとなり、そのバックオフィス部門がどのような内容の依頼を事業部から受けていて、どのような項目が必要になるのか特定するのです。開発課を例にとると、

・どのような粒度でシステム担当者は事業部の担当からヒアリングしているのか

・ヒアリングの際にシステム担当が最低限確認しなければいけない項目は何か？ベターで管理しておいたほうが良い項目は何か？

・ヒアリングが終わったら、それを実現するまで開発課内でどのような流れとなるのか？

を確認し、いったん現行のフローで開発課の依頼受付の項目・運用WF設定を行ってしまいます。もちろん現在困っていて改善したい点などもあればその場で聞いておき、それを実現するような管理項目・運用WFを設定します。2回目はプロトタイプの画面を見ながら、出来上がった管理項目や運用WFを実際に入力してから完結するまでを実演し、その際に改めて不備であったり、考慮漏れや「これもあった方が便利だ」とか、「やはりこの運用フローは変えたほうが良い」などの意見を引き出したうえで、改善をしていきます。

1週目の第1回MTGも第2回MTGも、基本は導入予定の課の課長のみ対象にしてやり取りを行います。これは関わるメンバーが複数人になってくると、それぞれ要望も違ったものが出てくるし、それらをすべて取り込むと際限が無いからです。そのため、課長が本来必要と思っている管理項目・運用WFにいったんは注力し、まずはそれを1週目で構築してしますのです。

2週目はこの期間で出来上がった画面等のハードコピーを活用しながら、Confluenceに利用者向けの操作マニュアルを作成します。1週目のヒアリングの時にこういった項目をいれてほしいという内容はヒアリングできているので、どのように操作すればよいのか？というマニュアルは１～２日程度時間があれば意外と簡単に作れてしまいます。そのうえで従業員への事前公報を開始します。今後社内運用がJIRAServiceDeskからのみとなり、E-mailや電話・会議での個別依頼が禁止になることを伝え、翌週に控えている社内勉強会の参加を促します。

一方、導入課側では課内に内部広報をし、テストデータなどをいれながら実際にそれで業務がまわるのかどうかテストをしてもらいます。実際にテストデータをいれてみると改めて、項目の要不要などにも気づけるので、内容は蓮沼側へフィードバックします。これにより蓮沼側では管理項目・運用WFの修正を実施します。

3週目は社内勉強会の実施をします。大体1時間もあれば十分でAgendaは主に2点を説明します。

・導入課への問い合わせ・依頼方法の統一（15分）

・問い合わせ・依頼方法の勉強会（45分）※質疑応答含

特に前者に関しては「何故、問い合わせを統一しなければいけないのか」という点を問い合わせを統一するメリットなどを説明しながら協力を依頼します。また大部分の社員は新しい方法を導入する際には、かなり便利になる場合でも心理的な抵抗感があることが常なので、後者で社内問い合わせの方法を事細かに勉強会にて説明します。

ここで質疑応答でよく聞かれたのが「どうしてもE-mailや電話で問い合わせをするのはダメなんですか？」ということです。これに関しては、「すべてダメです。もし認めてしまうと、E-mailや電話で問い合わせをする人がいる場合、裏では担当課の人間が依頼した内容をこのシステムに入力する運用となります。無駄な業務となりますので、最初からこのシステムに依頼者が入力してください。」と理由も含めて強い形で旧来のフローでは受け入れないことを説明しておきます。

4週目は予備週にしておき、１～3週目の実施事項の修正対応などがあれば、こちらで実施します。何らかの微修正は発生することを前提に余裕をもって予定を組んでおくのです。

４．導入により実現できたこと

導入により実現できたことを書いていきます。基本的には開発課・社内インフラ課・制作課ともに管理項目や運用ＷＦは異なりますが、実現できた効果はほぼ共通になっております。ここではその実現できた効果を先ほども取り上げた開発課を例に記載してみたいと思います。

４．１．開発課の事務的な定型業務の削減

まず圧倒的に目に見える成果となったのが、JIRA・Confluenceの導入により案件調整などに伴う不要業務が削減されたことです。これは実際にどのような業務が不要となり削減されていったのか、導入前・後で図示してみるとわかりやすいと思うので、まずは案件を各部署から開発課へ依頼するまでの仕事を見ていきましょう。

＜事例①　案件依頼までの導入前・後の比較＞

まずは案件依頼方法に関してです。導入前は案件依頼は大きく４つのプロセスからなりたっていました。

NO	プロセス名	実施者	実施内容
①	案件依頼	依頼者	システム課の人員に実現したい案件を会議などの直接依頼・E-mail・電話等の手段で依頼をする
②	案件リスト記載	システム課	依頼を受けて、案件リストに依頼案件を記載する 案件会議にあげるための情報が不足している場合には、利用者へのヒアリングも併せて実施し不足項目を埋める。
③	案件会議～担当者決定	システム課	週次のシステム課内の定例にて依頼案件を共有する 課長は各自の予定などを勘案しながら担当者を決定して、案件リストに担当者を割り振る
④	担当者連絡	システム課	担当者は依頼者に自分が担当になったことを連絡する 大まかな実現可能性・時期などを今後コミュニケーションをとることを連絡する

このうち、一番時間がかかっていたのは②のシステム課のメンバーが行う案件依頼リスト記載タスクでした。これは①の案件依頼が来てからそのまま聞いたことや書いてある内容を転記するだけではなく、システム課内の案件会議にあげるための情報を依頼者にヒアリングする必要性があったからです。

システム開発などの案件に慣れておりITリテラシーの高い依頼者であれば、社内の開発優先順位などがどのように決まっていき必要な依頼事項はなんであるかなどが適切に理解できているのですが、このEC通販企業の場合大部分の依頼者はシステム開発に慣れておらず依頼時の精度が低い状態でした。例えばシステム課内の案件会議にかけるためには最低以下のような内容を事前に利用者からヒアリングしておく必要がありました。

・依頼背景

・事業側がやりたいこと

・具体的なシステムでの実現方法

・改修対象システム

・希望納期

・実現時の効果（売上XXXX万円向上が見込まれるなど）

・案件種類（バグ・保守案件）

これらの項目を整理して伝えてくれる依頼者は導入前には社内にはほぼいない状態でした。そのため、システム課のメンバーは依頼がある都度依頼者に上記の内容を確認する必要があったのです。

また、依頼者側も確認を受けてすぐに答えられる場合は良いのですが、例えば実現時の効果などはビジネスをある程度理解していないと回答できないため、一担当者ではその場での回答を行うことが出来ず回答まで１～２週間を要することもありました。結果として開発着手までの期間が長くなっていきボトルネックとなっていました。

導入後はこの②の案件リスト記載のタスクがほぼほぼなくなりました。なぜならば依頼の窓口がJIRAServiceDeskに一本化されたことにより、上記に書いた項目が入力必須項目として依頼者に目に見える形で提示されたからです。これまでは依頼者が口頭・E-mail・電話などで依頼をしていたため、上記のような項目を意識することなく依頼をしていましたが、「依頼に必要な項目」として必須項目化されたことで、必要な情報を整理したうえで依頼をするようになり、かつそのまま入力内容がシステムに連動されるので、わざわざシステム課の人間が咀嚼してエクセルに転記する必要もなくなりました。

また地味に時間がかかっていた④の担当者連絡のタスクも完全に消滅しました。これは導入前は案件会議で割り振られた担当者が、自分が担当になったこと・大体の開発スケジュールなどを依頼者に連絡していたのですが、導入後はシステムで利用者を割り振り運用WFで”着手済”の状態にすると自動で利用者にメールが飛ぶように変更したのです。これによって、ある種無駄な業務が削られることになりました。

これは定性的なシステム課の課長の感想になるのですが、案件依頼の①～④までのプロセスでどの程度業務が削減されたかを確認したところ、6~7割は削減したという回答がありました。やはり②の内容を精査するのにかなりの時間を費やしていたので、それが少なくとも依頼者が意識して入力することで、その必要性がほとんどなくなったことが効果としては大きかったです。

次に、実際に依頼を受けた後で案件の進捗がどのようにして行われ行ったのかを導入前・後で比較してみましょう。

＜案件着手後の導入前・後の比較＞

開発課では案件進捗の都度エクセルファイルを更新し、依頼者にテストやリリース確認を要求する場合は都度都度E-mailにて確認を依頼する運用を行っておりました。なお、案件が発生してから終了するまでは、以下の運用WFに則って案件が進捗し、上記の案件進捗記載というのは③以降のプロセスを説明しています。

＜開発課の運用WF＞

開発課の案件を進めるプロセス内において、依頼者＝開発課の場合には内部で完結するのですが、基本的には依頼者に確認を依頼するプロセスが２つ存在していました。

⑤ユーザテスト中：テスト環境で開発内容の挙動等を確認

⑧本番リリース確認完了：本番環境で⑤でリリースしたものと同じ内容が実現されていることを確認

の２つのプロセスですなのですが、このの依頼者への接続が開発側にとっては手間となっていたのです。

JIRA・Confluenceの導入前は、他の部署に依頼するプロセスは、

・エクセルに進捗を登録する。

・依頼者へE-mailへ依頼内容を記載してテスト・リリースの確認を行う

と2つのSTEPで作業を依頼しており、毎回定型的な内容を説明するのにいちいちメールを打たなければいけませんでした。

これをJIRA・Confluence導入後は、

・JIRAの進捗を開発者が更新する

を行うと、特定のステータスに達した際に、JIRAの機能で自動でE-mailで依頼者にテストやリリースの確認を依頼するメールが送られるように設定をしました。作業自体が１つのSTEPで済むようになり、手間がかかっていた依頼するという行為そのものが無くなりました。案件を行うと、必ず1案件に対して⑤と⑧で依頼者への依頼行為は発生するため、この依頼するプロセスが簡略化されたことがかなりの開発者の効率化につながったのです。

最後に、この会社では開発課の進捗を週次で部長会という経営層～部長が集合する場所で発表していました。ここでも一部の資料の作成がJIRA・Confluenceの導入後は不要となりました。

＜部長会報告の前・後＞

毎週木曜に部長会があったので、導入前は開発課内では水曜の午前中までに案件リストを更新し、それを元に開発課の課長が

・進捗報告用のパワポ（開発状況をお天気マークで示したもの、今週のリリーステーマ・来週のリリーステーマ・今月のリリース予定テーマ）

・案件数の状況（対応前・開発中・対応完了）などをエクセル化したもの

を作成し報告するという流れになっていました。

導入後はリストの更新までは変わらないですが、開発課の課長は

・進捗報告用のパワポ（開発状況をお天気マークで示したもの、今週のリリーステーマ・来週のリリーステーマ・今月のリリース予定テーマ）

のみの作成でよくなりました。というのもJIRAでプロジェクト内の案件などをきれいに可視化できるツールなどが自動で実装されているので、案件数の推移などは実際にJIRAの画面を見ればよいだけになったからです。導入前は案件リストを元に、報告用のグラフ化したエクセル資料を作成していましたが、それらの機能はJIRA上に実装されているのでその必要が無くなったのです。

このようにそれまで本来開発にはつきものの事務的な定型作業を削減できたのがまずは一つ目の大きな成果として挙げられます。

４．２．マネジメント層の開発状況リアルタイム把握

事務的な定型業務の削減とは直接関係ない部長会参加者（経営層～部長）にもメリットはありました。それが2つ目の上記の最後の箇所で触れたマネジメント報告の箇所で、具体的には「週次の開発課の報告を聞かないでも、リアルタイムで開発状況が把握できる」ようになったことでした。

導入前は週次でしかもそれは水曜午前のデータの状態の報告を木曜日にうけていましたが、導入後は部長会参加者、すなわちマネジメント層は気になったら直接JIRAの対象ページを見れば進捗はリアルタイムでわかるようになたのです。もちろんJIRAで見れるのはエクセル上の案件の推移ですので、どのようにそれを解釈すればよいのか？などは部長会での報告を受けないとわからない事には変わりはないですが、少なくとも

・今どの案件が動いているのか？

・自部署で依頼した案件はどのような状況なのか？

・担当者はどのぐらい案件を抱えているのか？

などはリアルタイムで把握できるようになるので、週次の報告を待つストレスが部長会に参加をしている事業部側のマネジメント層にも無くなりました。

４．３．開発課のパフォーマンスの向上

こういった開発課の不要な業務の削減や、マネジメント層が効率的に案件状況を把握できるようになったことで、3つ目ですがこの会社の開発課の開発キャパシティが目に見えて向上するというメリットが発生しました。

導入前までは開発課のメンバー4人で、見積もりベースで約1.9～2.2月／月程度の開発がやっとの状態でした。これは４．１で述べた開発者が事務的な定型作業を実施していたというのももちろんあるのですが、４．２で述べたようにマネジメント層がリアルタイムで案件を把握できないため「この案件どうなっているの？」などマネジメント層に頻繁に聞かれたりすることが多く、その対応に時間を取られていたことに由来します。通常4人であれば最大限まで稼働出来たら4人月／月ですから、約半分はこういった進捗・確認系の業務に開発課のリソースがとられていたのです。

これがJIRA・Confluenceを導入した結果、数ヶ月で見積もりベースで約2.7～3.0人月／月程度の開発ができるようになるまで改善しました。これはフローなどを統一し、かつ運用WFによって利用者にもリアルタイムで案件の状況を見れるようにしたため、それらの確認に費やすタスクが開発課から消滅したことに由来します。

このように開発課という本来システム開発に注力してほしい部署に、コア業務では無いものをある程度の自動化により削減することにより、より本業であるシステム開発に注力するような体制を実現したのです。特にこの企業のようなEC通販の場合、システム開発の総量が増えれば増えるほど、売上を増やす機会がそれだけ増えますので、かなりのインパクトになりました。

本日はJIRA・Confluenceの導入方法を具体的にどのように行っていったのかを説明しました。ぜひともこの部署を読まれている方も、自社のバックオフィス部門に導入し、事務的な定型業務の削減→パフォーマンス向上のサイクルを実現してもらえたら嬉しいです。

お見積もりをご希望の場合は、お気軽にお問合せフォームよりご連絡ください

お問い合わせはこちら