「案件を増やしたい。でも、今の案件だけでも確認に追われている。もう一件引き受けたら、どこかで抜けそうだ。」
担当者は増えたのに、「あの件はどうなった?」「次は誰に頼む?」が自分に戻ってくる。会議前には一人ずつ状況を聞き、管理表を書き直す。休む前も、取引先への回答が止まらないか気になる。この記事は、複数の案件を抱え、社内・他部署・協力会社の仕事を追っている責任者に向けたものです。
先に結論
担当者が自分の作業を登録・更新し、困ったことを早めに伝えられるようにする。そのうえで責任者は、遅れ・回答待ち・判断が必要な作業を確認する。Backlogを検討するのは、この進め方で毎回の状況確認や管理表への転記が減るか確かめるためです。ExcelやMicrosoft 365で既に無理なく回っているなら、追加導入を急ぐ必要はありません。
案件を増やす前に、責任者へ戻ってくる確認を減らす
数件でも複数部署と協力会社が関われば、確認する相手や作業は増えます。逆に件数が多くても、担当者が決まった手順で完了まで進められるなら、今の仕組みで対応できることもあります。
- 進捗を聞かないと、管理表が更新されない。
- 別部署の回答待ちや協力会社の遅れに、締め切り直前に気づく。
- 「対応しました」と聞いても、次の担当へ渡ったか確認し直す。
- 会議では全員の状況を聞くだけで時間が過ぎ、対策を決めきれない。
- 仕事を任せたはずなのに、登録・期限確認・催促は自分がしている。
こうした状態なら、増員しても責任者の確認先が増えるだけになりかねません。先に変えたいのは、担当者の報告を集めて、責任者が一人で一覧を最新にするやり方です。ただし、作業量が多すぎる、必要な技能がない、決裁者が判断しない、といった問題は管理ツールだけでは解消しません。
公式事例では、案件の増加に合わせて担当者自身の登録・更新を進めている
以下はBacklog公式の企業インタビューの要約です。各社が報告した経験であり、同じ効果が自社でも出る保証や、Microsoft 365との比較試験ではありません。
西部ガスは、進捗を探す負担を減らして並行案件を増やした
西部ガスホールディングスのマーケティングDXグループは、Excel・メール・社内チャットで施策を管理していました。関係部署や社外パートナーが多く、誰が何をいつまでに行うのか確認するのに手間がかかっていました。
導入後は作業ごとの担当・進捗をBacklogで共有し、作業が終わったら次の担当へ渡す運用に変更。週次の打ち合わせでも同じ画面を使い、止まった課題には声をかけています。導入前はキャンペーン2件を並行するのがやっとでしたが、導入後は10件以上のプロジェクトを同時に管理できるようになったと報告しています。
これは売上や一人当たりの生産量が5倍になったという数字ではありません。条件を揃えた比較でもないため、自社の計画に「5倍」を使わず、進捗確認が案件追加の妨げになっていないかを点検する事例として読みます。西部ガスの公式事例
西武ライオンズは、代わりに登録する期間を経て担当者へ任せた
西武ライオンズのMDチームでは、商品ごとのExcel管理が売上拡大やメンバー増加に伴って難しくなり、タスク漏れが発生していました。広報部では、繁忙期に約200件のタスクを並行して進めています。
導入当初は、不慣れなメンバーの代わりに課題を登録し、要領をつかんでもらいました。登録の習慣がついてから、課題登録と週次会議の進行を徐々に任せています。全体が使いこなせるまで1〜2か月程度だったと説明しています。
アカウントを渡してすぐ任せたのではなく、見本を示してから、担当者自身が登録・更新する形へ移した点が参考になります。自社でも説明や練習を支える時間は見込む必要があります。西武ライオンズの公式事例
東急は、期限の理由と完了条件を書いてもらい、確認の往復を減らす運用を整えた
東急のシステム刷新では関係者が多いため、システム部門がすべてのタスクを登録する方法ではなく、参加者自身による登録が必要でした。以前、エンジニア向けツールがビジネス部門に定着しなかった経験もあります。
Backlogの採用後も、課題の書き方や完了条件を明文化し、使い方を教えています。依頼テンプレートには期限の理由と完了条件を記載。「その日を過ぎると何が困るのか」が伝わらない問題に対応しました。導入後は、ビジネス部門が期限や論点を整理して相談するようになったと報告しています。入力欄を用意するだけでなく、相手が着手・判断できる書き方を揃えたことが参考になります。東急の公式事例
責任者が毎回聞かなくても、次の担当が作業を始められるようにする
ここからは当サイトが作った説明用の例で、実際の導入企業の出来事ではありません。販促ページの公開を来週に控えています。制作担当はデザインを完成させましたが、営業の内容確認はまだです。法務へ確認を頼む人も決まっていません。管理表には「進行中」とだけ書かれています。責任者は制作・営業・法務へ順に聞いて、ようやく公開に間に合わない可能性に気づきます。
Excelでも、工程を分け、担当・期限・完了条件・回答待ちの相手を記載すれば、この状態は改善できます。Backlogを使う場合も同じように作業を分けます。
| 作業 | 次に動く人 | 終わったと判断する条件 |
|---|---|---|
| ページのデザインを作る | 制作担当 | 営業が確認できる案と参照先を提出 |
| 掲載内容を確認する | 営業担当 | 修正点を記載、または修正なしと回答 |
| 法務確認を依頼する | 依頼担当 | 確認対象・回答期限を添えて法務へ依頼 |
| 法務の回答を確認して公開可否を決める | 判断する責任者 | 回答を踏まえて公開可否と条件を記録 |
この表だけで「Backlogなら解決する」とは言えません。違いを試すのは、その後です。制作担当は案を提出した課題に参照先を書き、営業担当は同じ課題で回答する。責任者がメールの返事を管理表へ写すのではなく、実際に作業した人が更新する。営業の確認を別課題にするなら、その課題への参照先も付けます。
担当者を変えるタイミングは、「送ったとき」なのか「次の人が引き受けたとき」なのかまで決めます。通知を送っても、相手が引き受けたとは限りません。受け付けた旨をコメントし、引き受けられないときは期限前に相談するルールが必要です。
責任者は全員の状況を聞き直す代わりに、未着手・期限超過・判断待ちの作業を一覧で確認します。確認を一切しないのではなく、書かれていない状況を毎回聞く負担を減らし、止まった理由と対策を確認する運用を目指します。
担当者に任せるには、登録・更新・相談のルールを先に決める
- 誰が登録するか:依頼者が登録し、作業担当が内容と期限を確認する。口頭で頼んだ場合も、誰が記録するか決める。
- どこで作業を分けるか:担当・期限・完了条件が別になる仕事は分ける。細かな確認項目まで無条件に別課題にはしない。
- いつ更新するか:着手、成果物提出、回答待ち、期限変更など、状況が変わったときに担当者が更新する。
- 回答待ちをどう書くか:誰に何をいつ頼み、いつまで待つかを書く。待っている間も確認を追う人を決める。
- いつ相談するか:期限を守れない見込み、担当や優先順位を決められない場合、顧客への回答に判断が必要な場合は締め切り前に相談する。
依頼の記入例:販促ページの掲載内容確認
お願いすること:商品名・価格・注意書きを確認し、修正点を回答してください。
参照先:ページ案と価格表へのリンク。
回答期限:木曜15時。金曜の法務確認に間に合わせるため。
完了条件:修正箇所と修正文を回答、または修正なしと明記。
困ったとき:確認できない項目や期限に間に合わない見込みがあれば、分かった時点で依頼者へ相談。
「ちゃんと更新して」と注意し続ける前に、担当者が書けない理由も確認してください。作業が大きすぎる、判断者が不明、入力項目が多すぎる、メールと管理ツールへ二重に報告している。こうした負担を残したままでは、ツールを変えても更新は定着しません。
ExcelやMicrosoft 365で同じ運用が回るなら、今の仕組みを使い続ける
共同編集のExcelに作業を分けて記載し、担当者が更新する。Teamsから該当行や資料を参照し、相談事項と決定を残す。この方法で案件全体を確認でき、責任者の転記や催促が少ないなら、Backlogを追加する理由は弱くなります。
Backlogを試す理由があるのは、ルールを整えたうえでも、作業一覧とやり取りを往復する、管理表へ報告を写す、関係者へ別々に状況を説明する負担が残っている場合です。作業ごとの担当・期限・やり取りを同じ課題で扱い、どれだけ手順を減らせるか確認します。
顧客や協力会社がBacklogを使えず、メールの内容を責任者がすべて転記するなら、その負担は残ります。社外参加の許可や共有する情報の範囲も必要です。社外参加とセキュリティの確認事項を先に確認してください。
急ぎの相談はいつものチャットで行い、決まった作業・期限・変更理由は該当課題に記載する使い方もできます。西武ライオンズはTeams連携も利用しています。通知が届くことと、担当者が対応することは別です。メールからの依頼管理を見直す場合は、取り次ぎ・転記・催促を減らす記事も参照してください。
上司には「何件増やせるか」より、責任者の確認がどれだけ減ったかを示す
「他社が10案件を回せたので、自社も増やせます」では導入の根拠になりません。まず現在の案件数を保ったまま、確認負担と納期の守り方が変わるかを調べます。
- 責任者の確認・転記時間:状況を聞く、返事を追う、管理表を書き直す、会議用にまとめる時間を分けて記録する。
- 担当者の登録・更新時間:責任者が楽になっても、チーム全体の入力負担が増えすぎていないか確かめる。
- 遅れに気づいたタイミング:締め切り当日でなく、対策を取れる時点で分かったか記録する。
- 残った代行作業:誰の課題を責任者が登録・更新し続けているか確認する。
例えば責任者の確認・転記が一日60分から35分へ減れば、月20日で約8.3時間です。時間単価4,000円なら約3.3万円分の時間に相当します。これは計算方法を示す仮の数字で、給与支払いが3.3万円減るという意味ではありません。担当者側の追加作業、利用料、導入費用も含めて比較します。
実作業の人手が足りない場合、責任者の確認が減っても案件は増やせません。売上増を見込むなら、作業を担当できる人員と受注の見込みは別に説明する必要があります。費用対効果シミュレーターでは、人数・一人当たりの時間・削減率・初期費用などを変えて試算できます。利用料は料金とプランの記事で確認できます。
まず一案件で、責任者が代わりに更新しなくても進むか試す
- 今の方法で確認負担を記録する:責任者の確認・転記と担当者の報告作業を記録。案件数や繁忙度も残す。
- 同じ運用ルールで試す:担当・期限・完了条件・回答待ちの書き方を揃える。ルール改善で減った手間と、ツールで減った手間を分けて振り返る。
- 登録の見本を示してから担当者に任せる:責任者が代行し続けて定着したと判断しない。
- 会議では止まった仕事を確認する:遅れの理由、回答が必要な相手、責任者が決めることを確認する。
- 続けるかを負担と進捗の両方で決める:二重報告がなくなり、担当者が更新を続けられ、期限前に相談が上がるかを確かめる。
Backlogを導入する理由は、責任者がすべて覚え、すべて聞き、すべて書き直す状態を変えられるかどうかです。登録と更新を担当者に任せられ、その結果として確認の負担が減るなら、継続費用を含めて検討できます。任せられない原因が残るなら、先に運用を直す必要があります。
公式事例は2026年9月28日に確認。事例の内容は取材当時の運用と各社の報告です。販促ページの場面、記入例、試行手順、費用の計算例は当サイトの提案であり、導入効果を保証しません。