Article 05

保守運用における情報共有の最適化:「メール+Excel(スプレッドシート)」とチケット管理ツールの違い

システム保守において「メール+Excel(スプレッドシート)」でのタスク管理が課題を招く理由と、チケット管理ツールがもたらすメリット

「メール+Excel(スプレッドシート)」でも保守のチケット管理ツールと同等の運用は「可能」である

システム保守やプロジェクト進行において、連絡手段としての「メール」と、進行管理表としての「Excel(またはGoogleスプレッドシート等)」を組み合わせた運用(本記事では「汎用ツールによる管理」と呼ばせていただきます)は、長年中心的な役割を果たしてきました。

社内外を問わず「誰でも使える」というアクセシビリティの高さや、エビデンスとしての確実性において、この2つのツールは非常に優れています。現在でも、運用フローをルール化し、担当者同士が工夫を凝らせば、「メール+Excel(スプレッドシート)」の組み合わせだけで保守業務を回すことは十分に可能です。


メールとExcel(スプレッドシート)でチケット管理を目指す時の課題

では、こうした「汎用ツールによる管理」において何が課題になるのでしょうか。
それは、システム保守特有である「複数のタスクが並行して動く」「ステータス(状態)が何度も変化する」「複数人が同時に一つの議題に関わる」といった事象に対し、人間側でのルールの徹底が必要になるということです。

【一例:メール運用の工夫と、それに伴う課題】

  • 【工夫】 スレッドを追えるよう、件名に必ず [進行中] [バグ報告] といったタグと管理番号を入れる。
    👉 【課題】 返信時に誰かがタグを消してしまったり、Re:が続くうちに別の話題にすり替わると、途端にルールが崩壊する。
  • 【工夫】 情報の属人化を防ぐため、関係者「全員」を必ずCCに入れる。
    👉 【課題】 新入社員や新しいエンジニアが途中参加した際、過去のCC履歴をすべてメールボックスから探し出し、意図的に転送して読ませる手間が発生する。
  • 【工夫】 現在進行中のタスクを把握するため、別途Excel等で作った「課題管理表」を週次で手動更新する。
    👉 【課題】 「連絡(メール)」と「ステータス(表)」の管理場所が分断されているため、更新忘れによる「これって今どうなってますか?」の確認コストが日々発生する。

これら汎用的なツールを組み合わせてチケット管理を代用しようとする運用において、課題が浮き彫りになるというレポートがあります。


チケット管理ツールへの移行について

「汎用ツールによる管理」の課題を解決するため、IT業界で広く普及しているのがチケット管理ツール(課題管理システム)の導入です。代表的なものとして「Backlog」や「Jira」などが挙げられます。

チケット管理ツール導入のメリット

ツールを導入することで、これまで手作業で行っていたルールが以下のように自動化・可視化されます。実際に、経済産業省などの行政機関がメールとExcelベースの情報管理からチケット管理(Backlog)へ移行し、業務効率化を実現したケースも報告されています。

  • 唯一の情報源(URL)の確保:システムが自動で「特定のURL(チケット)」を作ってくれます。そこにアクセスすれば、議題の最新ステータスと過去のやりとりの全貌が常に確認でき、メールのようにスレッドが分岐して迷子になることはありません。
  • CCの徹底は不要:そのURLを共有するだけで、途中参加のメンバーでも過去の経緯や変更履歴がすべて紐付いて読めます。
  • 最新ステータスの自動共有:「未対応 / 処理中 / 完了」というステータスがトピックに連動しており、1クリックで状態が可視化されます(スプレッドシートを手動更新して共有する必要がなくなります)。

ただし「例外」もあります(ツール導入が合わないケース)

ここまでメリットを挙げましたが、すべての企業・プロジェクトに最適(万能)というわけではありません。

【ツール導入が「逆効果」になり得る運用アンチパターン】

  • 自社プロセスへの不適合(オーバースペック)
    多機能な統合ツールを導入したものの、「複雑すぎて使いこなせない」というケースです。プロジェクト管理ツールの導入担当者を対象とした調査においても、約15%が「自社のプロジェクトに合わず継続利用を断念した」と回答しています。現場のリテラシーやプロセスの成熟度に見合わないオーバースペックなツールの選定は、メリットよりも運用負荷(学習コスト)を上回らせ、システム定着のハードルとなります。
  • 文脈が剥奪されたチケットによる「ピンポン現象」
    運用ルールが徹底されず、「エラーの件」というタイトルだけで完了条件(Acceptance Criteria)や背景情報が一切記載されない議題が作られるケースです。Backlogの公式ヘルプ(避けるべき例と対策)でも警告されている通り、このような「情報不足のチケット」は担当者が着手できず、確認連絡のためのステータス往復(ピンポン・パターン)を引き起こし、かえってコミュニケーションのオーバーヘッドを増大させます。
  • 課題の絶対数が少ない(管理のための管理)
    月に数件の依頼であったり、1回で完結するような単発の保守依頼であれば、わざわざチケットを発行してステータス管理をする工数に見合わず、管理そのものが目的化してしまいます。

業務頻度や関係者のリテラシーに合わせて、段階的な導入を行ったり、あえて「汎用ツールでの管理」を継続するという決断もフェアな選択肢の一つです。ツールの導入を真の成功に導くためには、ツールの高機能さに依存するのではなく、「組織の運用ルールにいかに適合させるか」を第一に設計する必要があります。


当社のスタンス:本来の目的は「本業への集中」

私たち自身も、メールというツールを排除することが目的ではありません。
大切なのは、「コミュニケーションの維持にかかっていた暗黙の労力(メタ作業)」をいかに無くすかということです。もし、お客様の設定した目的が「手軽な連絡」であればメールで十分ですが、「確実で追跡可能な保守」であれば、チケット管理ツールの導入が有力な選択肢となります。

タイガーテックのシステムの保守運用プランでは、お客様に本来の事業やクリエイティブな議論に集中していただくため、標準で「課題管理ツール(Backlog)へのご招待」と「Slack/Chatwork等でのダイレクト連携」を含めてご提供しています。

「言った・言わない」のストレスから解放された、透明性の高い保守運用体制をご提供しています。

現状の保守体制にご不満はありませんか?

「対応が遅い」「どこまで進んでいるか見えない」など、コミュニケーションに起因する保守の課題はツールと体制で解決できます。タイガーテックの保守乗り換え(引き継ぎ)についてお気軽にご相談ください。

保守運用について相談する
疑問は解決しましたか?

ページ内の目次

History
検索履歴

文章での質問も可能です。(例: EC-CUBEの保守は?)

サイト内の気になる単語を選択すると
ここに履歴が残ります