プロジェクト管理のチケット式ツールを選ぶ｜向くチームと運用の設計
プロジェクト管理でチケット式のツールを検討するとき、まず引っかかるのが言葉です。チケットという呼び方は開発の現場から広まったもので、そこでの前提を知らないまま導入すると、運用の途中で必ず食い違いが出ます。この記事では、チケットが実際には何を指しているのかを整理したうえで、どんなチームに向いているのか、設計で決めるべきことは何か、どこで破綻するのかを順番に扱います。
チケットとは、追跡番号の付いた作業の依頼のこと
チケットという言葉が指しているものは、実はそれほど複雑ではありません。1件の作業や課題に、番号を振って、状態と担当と期限を持たせたものです。番号が振られていることが最大の特徴で、これによって「あの件」ではなく番号で会話できるようになります。
もともとは、不具合の報告を受け付けて処理する仕組みから来ています。報告が来たら番号を振り、担当を決め、直したら閉じる。この流れを、不具合以外の作業にも広げたものが、いま多くのツールで使われているチケットです。
チケットが持っている情報は、おおむね次の通りです。
・番号 ・タイトルと説明 ・担当者 ・状態 ・期限 ・種別。不具合なのか、依頼なのか、改善なのか ・親子や関連の繋がり ・やり取りの履歴
このうち、他の管理方法と決定的に違うのはやり取りの履歴が1件ごとに残る点です。誰がいつ何を言ったか、いつ状態が変わったかが、その1件の中に時系列で積まれます。案件が終わったあとに経緯を確認したい場面で、この記録は非常に強く効きます。
もう1つの特徴が、閉じるという概念です。チケットは開いた状態で生まれ、処理されて閉じられます。開いているチケットの数が、いま抱えている仕事の量そのものになります。この数を減らすことが目的になるので、管理する側も作業する側も向いている方向が揃いやすいという利点があります。
カンバン型、工程表型とどう違うのか
進行を管理する道具の形は、大きく3つに分かれます。それぞれ得意なことが違うので、どれを主体にするかで運用が変わります。
**チケット型が得意なのは、1件ごとの経緯を残すことです。**依頼を受けて処理して閉じる、という流れが繰り返し発生する仕事に向いています。問い合わせ対応、不具合の修正、社内の申請処理などです。弱いのは、全体の流れを一目で見ることです。一覧は行が並んだ形になるので、どこが詰まっているかは絞り込まないと分かりません。
**カンバン型が得意なのは、いまの状況を一目で見ることです。**列に状態を並べ、カードを横に動かすので、どこに何件たまっているかが視覚的に分かります。弱いのは、件数が増えたときです。列に50枚のカードが積まれると、板としての利点が失われます。
**工程表型が得意なのは、日程の重なりを見ることです。**どの作業がいつからいつまでで、何が終わらないと次が始まらないのかが線で見えます。弱いのは、日々の更新です。線を引き直す手間が大きく、更新が追いつかなくなります。
実務では、この3つを排他的に選ぶ必要はありません。同じ情報を、見たい目的に応じて別の形で見るのが理想です。1件の経緯を追いたいときはチケットの詳細を見て、全体の詰まりを見たいときは板の形で見て、日程を確認したいときは線で見る。元のデータが1つなら、これは矛盾しません。
問題になるのは、形ごとに別の道具を使っている場合です。チケットのツールと工程表の表計算が別々にあると、必ずずれます。ずれた瞬間にどちらかが信用を失い、そちらは更新されなくなります。
チケット式が向くチーム、向かないチーム
チケット式が力を発揮するのは、次の条件が揃っているときです。
**外から依頼が飛んでくる仕事。**自分たちで計画を立てて進める仕事より、受け付けて処理する仕事に向いています。問い合わせ、修正依頼、申請、確認依頼。受け付けた記録が残り、取りこぼしが分かるという利点が最大限に効きます。
**1件あたりの経緯が長い仕事。**やり取りが何往復もするもの、判断が変わるもの、後から「なぜこうしたのか」を確認されるもの。履歴が1件の中にまとまっていることが決定的に有利になります。
**関わる人が多い仕事。**担当が途中で変わる、複数の部署をまたぐ、社外が関わる。誰の手元にあるのかが番号で追えることが重要になります。
逆に、向かないのは次のような場合です。
1件が短時間で終わる仕事。30分で終わる作業に番号を振って状態を管理するのは、管理のほうが重くなります。この場合は、単純な一覧か板の形で十分です。
**計画が主で、依頼が少ない仕事。**あらかじめ全体の段取りが決まっていて、それを順に進めていく仕事では、チケットの「受け付けて閉じる」という流れがうまく当てはまりません。工程表型のほうが自然です。
チームが小さく、口頭で足りる場合。3人以下で毎日顔を合わせているなら、番号を振る手間に見合う効果が出ないことがあります。ただし、後から記録を求められる仕事なら人数に関係なく価値があります。
判断の目安は1つです。**「先月のあの件、どういう経緯だったか」と聞かれる頻度が高いかどうか。**高いならチケット式が向いています。低いなら、もっと軽い形で足ります。
粒度をどう決めるかで、9割が決まる
チケット式の運用で最も失敗しやすいのが、1枚に何を書くかです。ここを外すと、どんなツールを使っても機能しません。
大きすぎる例。「サイトのリニューアル」で1枚。このチケットは3か月開いたままになります。状態が動かないので、進んでいるのか止まっているのか外から分かりません。履歴は延々と伸び、途中から読む人には追えなくなります。
小さすぎる例。「見出しの文字色を変える」で1枚。これが200枚並ぶと、一覧を見ること自体が苦痛になります。番号を振る手間、状態を動かす手間が、作業そのものより大きくなります。
**適切な目安は、1枚が半日から3日で終わる大きさです。**この範囲だと、状態が週に何回か動き、履歴が読める長さに収まり、枚数も手に負える範囲に留まります。
大きい仕事を扱うときは、親子の構造を使います。「サイトのリニューアル」を親にして、その下に半日から3日の子を並べる。親は進捗を見るための箱で、実際に動かすのは子です。ただし、階層を3段以上にすると誰も全体を把握できなくなるので、2段までに留めるのが実務的です。
粒度を決めるのは、依頼を受けた本人にやってもらうのが最も精度が高いです。とりまとめる側が全部を割ろうとすると、実務を知らないまま割ることになり、実態と合わない枚数が並びます。依頼は依頼のまま受け取り、受けた人が作業の単位に割る。この分担にしておくと、粒度のばらつきが自然に収まります。
状態の並びは、実際の流れをなぞる
チケットの状態をどう並べるかは、ツールの初期設定をそのまま使うと合わないことが多い部分です。設計するときの原則は3つです。
**1つ目、状態は実際の流れをなぞる。**理想の流れではなく、いま実際に起きている流れを書き出してください。受け付ける、判断する、作業する、確認する、閉じる。この5つで済むチームが大半です。
**2つ目、状態の数は5つから7つに収める。**多いと選ぶのに迷い、人によって選ぶものが変わります。集計した数字がぶれるので、結局は目視で確認することになります。
**3つ目、待ちの状態を必ず1つ入れる。**外部の事情で進められないものを入れる場所です。これが無いと、外部要因で止まっているものが作業中に紛れ込み、本当に動いているものと区別がつかなくなります。「先方確認待ち」「資料待ち」といった名前で1つ用意してください。
もう1つ、設計時に決めておくと後が楽になるのが、誰が状態を動かすかです。作業した人が完了まで動かすのか、確認した人が閉じるのか。ここを決めていないと、作業者が完了にしたものを誰も確認しないまま溜まるか、逆に確認待ちが渋滞します。
閉じる基準も文章で書いておいてください。「動くようになった」なのか「先方の承認が取れた」なのか。基準が人によって違うと、閉じた枚数という数字が意味を持たなくなります。ツールの中の説明欄に1行で書いてある状態が理想です。別のドキュメントに書いた基準は読まれません。
開発以外のチームで使うときに起きること
チケット式のツールの多くは、開発の現場で使われることを前提に作られています。それ以外のチームで使うと、いくつか摩擦が起きます。
**言葉が合いません。**課題、issue、バックログ、スプリント、といった言葉が画面に並びます。これらは開発の文脈では意味がありますが、営業や事務や制作の現場では通じません。名前を変えられるツールもあるので、導入時に自分たちの言葉に置き換えられるかを確認してください。置き換えられないなら、社内での呼び方を統一する説明が要ります。
**設定項目が多すぎます。**細かく設計できることは、開発チームにとっては利点です。しかし、設計する人がいないチームでは、初期設定のまま使うことになり、使わない項目が画面を埋めます。使わない項目が並んでいるだけで、入力する人の手は止まります。
**入力する項目が多すぎます。**優先度、種別、影響範囲、見積もり、といった項目を全部埋めることを求められると、1件を登録するのに5分かかります。これでは、口頭やチャットで依頼したほうが早くなり、ツールが使われなくなります。必須項目は、タイトルと担当と期限の3つに絞るのが現実的です。
**通知の量が多すぎます。**開発向けのツールは、細かい変更まで通知する設計になっていることがあります。通知が多いと人は切り、切った人には届かなくなります。導入時に通知の設定を全員分そろえておくと、この問題はかなり防げます。
すでに使っていて合わないと感じている場合、そのまま使い続けたほうがよい場合もあります。すでに全員が使い方を覚えていて、記録も溜まっているなら、乗り換えの摩擦のほうが大きいことがあります。設定で直せる範囲を試してから判断してください。
依頼を受け付ける入口を1つに絞る
チケット式が機能するかどうかは、実は道具の設定より入口の設計で決まります。登録されなかった依頼は、存在しない依頼として扱われるという前提が成り立っていないと、どんなに良い設計をしても一覧は実態を映しません。
現実には、依頼は複数の経路から飛んできます。チャット、メール、口頭、会議の場、廊下での立ち話。これを全部やめさせるのは無理です。だから、受け取ってから登録するまでの手順を決めるほうが現実的です。
決め方は2通りあります。
**受けた人が登録する形。**依頼を受けた担当者が、その場でチケットを作ります。利点は、内容を理解した人が書くので粒度が適切になること。欠点は、忙しいと後回しになり、そのまま忘れられることです。この形にするなら、「登録するまでは受けたことにならない」という合意を全員で持つ必要があります。
**依頼する側に登録してもらう形。**依頼者自身が入口から登録します。利点は、受ける側の負担が減り、依頼の量が可視化されること。欠点は、依頼者にとって手間が増えるので、慣れるまで抵抗があることです。この形にする場合、入力項目を極限まで減らすのが成功の条件になります。タイトルと、いつまでに欲しいかの2つだけで受け付ける形にすれば、チャットに書くのとほとんど変わりません。
どちらを選ぶにせよ、避けるべきなのは両方を中途半端に許すことです。「基本は依頼者が登録、忙しいときは受けた人が代わりに」という運用は、結局どちらもやらない状態に落ち着きます。
入口を絞った効果は、数か月後に数字で見えます。月に何件の依頼が来ているのか、そのうち何件が期限内に処理できたのか。**この2つの数字は、人を増やす相談をするときの唯一の材料になります。**口頭で「忙しい」と言っても伝わりませんが、受け付けた件数が半年で1.5倍になっているという事実は伝わります。
番号で呼べることの、想像以上の効き目
チケット式の利点として最も過小評価されているのが、番号で会話できることです。地味に見えて、実務では驚くほど効きます。
番号が無いと、会話は「先週お願いしたA社の見積もりの件」から始まります。この時点で、聞いている側は記憶をたどる必要があります。似た案件が複数あると、どれの話なのかを確認するやり取りが1往復増えます。
番号があれば「1024番の件」で通じます。番号を検索すれば、経緯も添付ファイルも過去の判断も全部その場にあります。説明する手間と、説明を聞く手間の両方が消えます。
この効果が最も大きいのは、担当が変わるときです。引き継ぎの場面で、口頭とメモで伝えられる情報は限られます。番号を渡せば、経緯がそのまま渡ります。人の入れ替わりが多いチームほど、この利点は大きくなります。
社外とのやり取りでも効きます。取引先に番号を伝えておくと、相手からの問い合わせが「例の件」ではなく番号で来るようになります。返信を書く前に状況を思い出す時間が要らなくなるので、返信そのものが速くなります。
ただし、番号を使う文化が定着するには時間がかかります。最初は誰も番号を書きません。とりまとめる立場の人が、自分の発言に必ず番号を添えることから始めるのが一番早いです。数週間で周りが真似し始めます。
社外の人をどこまで入れるか
チケット式の運用でよく詰まるのが、社外の関係者の扱いです。取引先、外注先、協力会社。この人たちを中に入れるかどうかで、設計が変わります。
**入れる場合の利点。**依頼と回答が1か所に残るので、言った言わないが起きません。相手の作業待ちの状態も見えるようになり、催促のタイミングが分かります。
**入れる場合の注意点は3つあります。**1つ目は、他の取引先の情報が見えてしまわないかです。案件ごとに見える範囲を分けられるかを、必ず確認してください。2つ目は、費用です。1ユーザーあたりの課金だと、短期の協力者を10人呼べば10人分かかります。3つ目は、相手に使い方を覚えてもらう手間です。相手にとっては1つの取引先のためだけに新しい道具を覚えることになるので、断られる可能性があります。
**入れない場合の運用。**社外とはメールやチャットでやり取りし、その内容を担当者がチケットに転記します。手間はかかりますが、情報の管理は単純です。転記が漏れると記録が欠けるので、やり取りが発生したら必ず1行残すというルールを決めておいてください。
現実的な落としどころとして多いのは、長く付き合う相手だけ中に入れて、単発の相手は外に置くという形です。半年以上続く関係なら覚えてもらう価値がありますし、単発なら転記のほうが早いです。
情報の扱いについては、個人情報や取引先の情報を含む記録を外部の仕組みに置くことになるので、社内の規程との整合を確認してください。判断に迷う場面では個人情報保護委員会の公開資料や、情報処理推進機構が出している中小企業向けの資料が参考になります。
チケットが溜まり続ける、という失敗
チケット式の運用で最も多い失敗が、開いたままのチケットが増え続けることです。300件開いている一覧は、実質的に情報がゼロの状態と変わりません。
溜まる原因は3つあります。
**1つ目は、閉じる基準が無いことです。**やらないと決まったものを閉じられず、いつかやるかもしれないものとして残ります。これが積み上がります。
**2つ目は、登録が簡単で処理が難しいことです。**思いついたことを片端から登録する文化があると、入る量が出る量を上回ります。登録する時点で「やるかどうか」を判断する場所が要ります。
**3つ目は、定期的に見直す場が無いことです。**溜まったものを見直す時間を取らないと、誰も減らせません。
対策は明快です。**未着手のまま30日経ったチケットは、進めるか、閉じるかを決める。**この判断を月に1回、30分だけ行います。閉じることに抵抗がある場合は、「やらないと決めた」という状態で閉じる形にすると心理的な抵抗が減ります。
もう1つ有効なのが、同時に開けるチケットの数に上限を置くやり方です。1人が同時に着手できるのは3件まで、と決めておくと、抱え込みが起きません。上限に達したら、新しく着手する前に何かを終わらせる必要が出ます。これは板の形で運用しているときに特に効きます。
移すときに、過去のチケットをどう扱うか
すでに何かを使っていて別の道具に移す場合、最初に決めるのは過去の記録の扱いです。ここを決めないまま移行を始めると、途中で止まります。
現実的な選択肢は3つあります。
**全部を移す。**書き出しと取り込みの機能が両側にあれば可能ですが、番号は振り直されることが多く、コメントの投稿者や日時が正確に再現されない場合もあります。過去の番号で会話していた履歴が、移した先では通じなくなる点は覚悟が要ります。
**開いているものだけを移す。**閉じたチケットは元の場所に残し、いま動いているものだけを新しい場所で作り直します。実務ではこの形が最も多く、また最も現実的です。開いている件数が50件程度なら、手で作り直しても半日で終わります。
**何も移さず、日付で切る。**移行日を決めて、それ以降の新規分だけを新しい場所で扱います。過去は元の場所を参照用に残します。元の側のプランを1つ落として、読むためだけに契約を続ける判断もあります。
どの形を選ぶにせよ、元の場所をいつまで残すのかを先に決めてください。「そのうち解約する」と考えていると、契約が残り続けるか、逆に何の準備もないまま解約されて記録が消えます。半年後の日付をカレンダーに入れて、そのときに判断すると決めておくのが確実です。
移行そのものより難しいのが、人の習慣です。新しい場所を作っても、慣れた場所を開く手が2週間は残ります。この期間に古い場所へ書き込まれたものが取り残されるので、移行後の最初の2週間は、古い場所を見に行く担当を決めておくと漏れが防げます。
費用の増え方は、道具によって大きく違う
チケット式のツールを選ぶとき、月額の表示だけを見比べても比較になりません。何を単位に課金されるかが違うからです。
公開されている条件を見ると、考え方の違いがはっきり分かります。
Backlogの現行プランは、人数ではなくプランごとの枠で決まる形です。公式の料金ページによれば、スタータープランが月額2,700円で30ユーザー、5プロジェクト、容量1GB。スタンダードプランが月額16,000円で100プロジェクト、容量30GB。プレミアムプランが月額27,000円でプロジェクト無制限、容量100GBとされています。いずれも税抜で、2026年9月時点の記載です。人数の出入りが多くても総額が変わらない形なので、外部の協力者が多いチームでは読みやすい料金体系です。
ただし、この体系は変わることが告知されています。
2026年12月31日：現在のプランの新規契約終了 出典: backlog.com
公式の告知によれば、2027年1月1日から新しいプランが始まり、エコノミー、ビジネス、プロフェッショナルの3つで構成されます。新しいフリープランでは、ユーザーの上限が10名から5名に変更されるとされています。無料の範囲で始めるつもりなら、この変更を織り込んで判断する必要があります。
一方、Trelloのように1ユーザーあたりの月額で課金される形もあります。公式の料金ページによると、無料プランはワークスペースあたり10ボード、10コラボレーターまで。有料はStandardが1ユーザーあたり年払いで月5米ドル、Premiumが10米ドル、Enterpriseが17.50米ドルと記載されています。この形は、少人数なら安く、人数が増えると線形に増えます。
サービスそのものが終わる場合もあります。Jootoは2027年7月31日をもって一般提供を終了すると公式に案内しており、2027年8月1日以降は登録データが順次削除される予定とされています。チケットの記録は、案件が終わったあとに参照される情報です。いつまで読めるのかは、選ぶ段階で必ず確認してください。
そのまま使い続けたほうがよい場合
替える話をしてきましたが、いまの道具をそのまま使い続けるのが正解である場合も明確にあります。すでに全員が使い方を覚えていて、記録も何年分か溜まっていて、日々更新されているなら、それは簡単には作れない状態です。**使われている道具を替えることそれ自体が、目に見えない費用を発生させます。**新しい場所を覚えてもらう時間、慣れるまでの混乱、過去の記録の扱い。これらは合計すると、月額の差より大きくなることがあります。
合わないと感じているなら、まず設定で直せる範囲を試してください。必須の入力項目を減らす、状態の数を減らす、通知を絞る、画面に出す項目を絞る。この4つだけで印象が変わることは珍しくありません。それでも合わないなら、そのときが検討の時期です。
選ぶときに確かめる4つのこと
ここまでを踏まえて、判断の順番を整理します。
**1つ目、記録の粒度が自分たちに合っているか。**1件ごとの経緯が必要なのか、全体の流れが見えれば足りるのか。前者ならチケット式が向き、後者なら板の形で十分です。
**2つ目、入力の必須項目を減らせるか。**タイトルと担当と期限だけで登録できるかどうかを、試用の段階で確認してください。ここが重いと、どれだけ良い機能があっても使われません。
**3つ目、見え方を切り替えられるか。**一覧で見る、板で見る、日程で見る。同じ情報を目的に応じて別の形で見られるかどうかが、複数の立場の人が使う場面では効いてきます。見たい表示が上位プラン限定になっていないかも確認してください。
**4つ目、費用の増え方が読めるか。**人数で増えるのか、案件やボードの数で区切られるのか。機能で絞らず、区切るのは人数とボードの数だけという形なら、必要な表示が使えないという詰まり方は起きません。区切り方は料金で確認できます。機能単位で何ができるのかはできることに整理してあります。
候補を1つずつ見比べたい場合は、Backlogとの比較、Asanaとの比較、Notionとの比較、monday.comとの比較、Jootoとの比較から、いま検討しているものを見るのが早いです。全体の一覧は比較の一覧にあります。板の形で使っているものから移す場合の手順はTrelloからの移行に、誰がどこまで見えるのかという設計は安全性の考え方にまとめました。導入前によく出る疑問はよくある質問にあり、条件を個別に確認したい場合はお問い合わせから聞けます。
最後に。チケット式の運用がうまくいっているかどうかは、1つの問いで確かめられます。**先週受け付けた依頼のうち、まだ誰も手をつけていないものを、聞かずに数えられるか。**数えられるなら仕組みは機能しています。数えられないなら、足りないのは機能ではなく、受け付けた時点で必ず1件を登録するという運用のほうです。
Q1. チケット式のツールは開発以外のチームでも使えますか？
使えますが、言葉と設定項目が開発向けになっている点に注意してください。課題やバックログといった呼び方が通じない場合は、名前を変えられるかを確認します。必須の入力項目はタイトルと担当と期限の3つに絞ってください。1件の登録に5分かかる設定だと、口頭やチャットで依頼したほうが早くなり使われなくなります。
Q2. チケット1枚の大きさはどれくらいが適切ですか？
1枚が半日から3日で終わる大きさが目安です。3か月かかる仕事を1枚にすると状態が動かず、進んでいるのか止まっているのか外から分かりません。逆に30分の作業を1枚にすると枚数が増えすぎます。大きい仕事は親子の構造を使い、階層は2段までに留めてください。
Q3. 開いたままのチケットが増え続けます。どうすればよいですか？
未着手のまま30日経ったものは、進めるか閉じるかを月に1回、30分だけ判断してください。やらないと決めたものは「やらない」という状態で閉じると抵抗が減ります。あわせて、1人が同時に着手できるのは3件までといった上限を置くと、抱え込みが起きにくくなります。
Q4. 料金は人数で増える形と、枠で決まる形のどちらがよいですか？
人の出入りが多いなら枠で決まる形が読みやすく、少人数で固定なら人数課金のほうが安く済みます。Backlogは枠で決まる形で、スタータープランが月額2,700円で30ユーザー5プロジェクトと公表されています。ただし2026年12月31日で現行プランの新規契約が終了し、2027年1月1日から新しいプランに変わると告知されています。