3
4

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 3 years have passed since last update.

[プロジェクト管理]EメールとExcelによる課題管理のデメリット、チケット管理ツールを利用する理由・メリットなど

Last updated at Posted at 2020-10-01

はじめに

記載途中。以下について考察をコメントでいただければ幸いです。

  • Eメールやインストールベースのスプレッドシート(Excel)によるタスク管理のデメリット
  • チケット管理システム(RedmineやBacklog)を使う理由

この記事の主題は、膨大な数の課題を扱う場合は、**EメールやExcelで管理するのは無理(というか悪)**であることを、チケット管理ツールに不慣れなクライアントに理解してもらうことです。
理解してもらいたい時に「これを読んでください。」と引用してもらうことを目指しています。

記述しようと思った動機としては「何度も説明して面倒になった」のが大きいです。
日本中で無駄なやりとりに貴重な労力がさかれている(=日本が誇る低生産性の一因?)と思うので、
その無駄をなくすことでささやかながら社会に貢献できればと思います。

※チケット管理ツールの機能や各製品の優劣とかは扱いません。

背景

システム・ソフトウェア開発プロジェクトでは多数の課題(Q&A、タスク、周知事項、バグ)が発生します。
これらを管理するツールとして、以下が一般的です。

  • Eメール
  • (インストールベースの)スプレッドシート・・・例.Excel
  • (Webベースの)スプレッドシート・・・例.Google SpreadSheet
  • チケット管理ツール・・・例.Redmine Backlog Github-Issueなど

システム開発をもっとも効率よく実施するためには「チケット管理ツール」の利用が推奨されます。(理由は後述)

ただ、初めて使う人にとっては、「慣れるまでちょっと大変」です。
このため普段、EメールやせいぜいExcelでしか課題管理していない(=それで間に合っている)人には、精神的な抵抗があります。
それがクライアント側のメンバーだったりするとつい遠慮して、先方のやり方にあわせてしまったりします。

が、間違いです。
チケット管理ツールを使わないことによる効率低下は一つ一つの課題を処理しているときはさほど目立ちませんが、数百、数千と積み重なるので、実際にはコミュニケーション効率・作業効率を大きく低下させています。

また、効率が悪いことで、限られた時間・予算で多数の課題と格闘しているメンバー(特にチケット管理ツール慣れしているプログラマ)のフラストレーションを高めます。

これらのマイナスは、納期遅延や品質低下という形で顕在化するので、クライアントにとっても損失です。

この投稿では、ふだんEメールやExcel(インストールベースのスプレッドシート)しか使ってない人に、「なぜシステム開発プロジェクトではEメールやExcelでなくチケット管理ツールを使うべきか」を理解してもらうための情報を整理します。

用語の定義

チケット・・・開発・運用にあたって出てくる様々なタスク・やりとりの総称。Q&A、周知事項、課題、バグ、要望など。

Eメールによる課題管理

メリット

ほとんどの会社・個人で利用されているので、以下のメリットがあります。

  • 操作慣れ
  • 導入作業が不要・・・サーバ設置、アカウント作成、操作説明/トレーニング/サポート

デメリット

以下のようなデメリットがあります。チケット管理ツールではこれらの問題が全て解決もしくは大幅に軽減できます。その結果、導入に要するコスト大幅に上回るメリットを享受できます。

  • 宛先入力ミス
    • 事故・・・外部の人に機密情報を漏えいしてしまう
    • 送信漏れ・・・必要な人に届かない
    • BCCにすべき人を全部CCやTOに入れてしまう
    • メンバーの増減のたびに漏れたり送信エラーが発生する
    • 上述したようなことを防ぐために無駄に神経を使う
  • 検索性が低い
    • 件名と違う話題がはじまりやすい
    • 件名と内容が違うと後から探すのが大変
  • 属性を付与できない
    • 担当者/誰にボールがあるのかわからない
    • 状態/完了?進行中?未着手?がわからない
    • 期限/いつまでに対応すべきかわからない
    • 優先度/どれを優先すればよいのかわからない。
    • 他課題との関連・依存関係(親子関係)/関連するやりとりを設定できないので探すのが大変
    • これらの属性がなく一覧表示できないため、全体を俯瞰して優先度、担当者、期限等をリバランスするのが大変
  • 情報不足により不毛なやりとりが増える
    • 上述した情報(担当、状態、期限、優先度)を確認するためのやりとりが発生
    • 情報の入力・形式を強制できないので、不具合や要望の際に把握したい情報が漏れるので逆質問発生
    • 画像を引用しづらい。類似の用語やキーワードがある場合、どの画面や機能を指しているかの逆質問発生
  • 対応漏れの発生
    • 見通しが悪いので対応が漏れる
    • 期限が近くなっても自動でリマインドしてくれないので対応が漏れる
    • 迷惑メールに振り分けられたり操作ミスでアーカイブしてしまったりで対応が漏れる
  • その他
    • 遅延・漏れがないように誰かが管理(状態チェック、督促など)しなければならない。
    • 業務を誰か(他社)に引き継ぐ時が大変。要件や仕様など意志決定に関わる情報が必須。メールだと探すのも、読むのも大変。

チケット管理ツールによるチケットの例

Q&Aの場合
解決済?オープン?
誰にボールがある?
いつまで?
画像引用で一目瞭然
バグの場合
(再現手順・利用環境など必須入力に)

関連する記事

私の経験だと、失敗するプロジェクトの多くは技術力不足ではありません。

体制に見合わないむちゃな納期などどう頑張っても無理なものは別として、まっとうな工期や体制があったとしても「課題管理(変更管理含む、いわゆるスコープ管理)」「コミュニケーション(ツールや指針、ステークホルダー管理含む)」が整ってないと容易に失敗(納期遅延、予算超過、機能不足、低品質)します。

余談

これは私の経験に基づく考え方ですが、Q&Aやデータのやり取りを「メールでやりたい」という情報システム会社があれば、おそらくそこは「使えない」可能性が高いと思います。

理由は単純で、「多数の課題を、全体を俯瞰して、漏れなく、効率よく処理することはメールでは不可能」ということを理解していないからです。

少なくともある程度の規模(10人月超えるくらい)のプロジェクトに責任を持つ立場として関わったことはないことは確実です。
下請け経験しかない会社で、指示待ちエンジニアしかいない可能性が高いです。
こういう会社は営業畑出身の経営者や幹部が幅をきかせていて、漠然とした話題(ビジョンとか経営課題とか)については口は達者だったりするので、クライアント(システムを発注する側)は勘違いしやすいようです。)

3
4
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
3
4

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?