「お客様からの修正依頼、担当には伝えた。でも、いつ返せるのかはまた聞かないと分からない。」
メールを転送し、Excelへ依頼を書き写し、返事がない人に確認する。夕方には、上司や顧客へ説明するために情報を集め直す。自分が手を止めると案件も止まりそうで、休む前にも気が抜けない——この記事は、そんな顧客・協力会社・他部署の間で、取り次ぎと進行管理を担う担当者に向けたものです。
Backlogを入れるだけで、この負担がなくなるわけではありません。依頼の粒度、更新責任、状態の定義は人が決める必要があります。そのうえで、メールと添付Excelを中心にした運用から、仕事ごとに依頼・やり取り・担当・期限をまとめることで、どの手間を減らせるかを考えます。
先に結論
導入理由は「Excelでは管理できない」ではありません。あなたが毎回、取り次ぎ・転記・催促をしないと回らない仕事を、関係者が同じ課題を見て進める形へ変えられるかです。既存ツールで同じ運用が無理なく回っているなら、追加導入を急ぐ必要はありません。
依頼メールに返信があっても、未完了の作業は別に確認する
例えば、一通のメールで複数の修正を頼まれた場合を考えてみます。以下は説明のために作った例で、実際の導入事例ではありません。
顧客から「画像の差し替え、文言の修正、公開日の確認」が一通のメールで届きました。制作担当へ転送し、管理表にも登録します。画像は完了、文言は顧客の回答待ち、公開日は別部署の判断待ちです。さらに顧客の追加指示が別件名のメールに届きます。
ここで困るのは、メールを検索できないことではありません。3つの作業それぞれについて、どこまで終わったか、誰の返事を待っているかを、メールを読み返して確認することです。「メールは返信済み」でも、依頼全体が完了したとは限りません。
Excelでも、画像・文言・公開日の依頼を別々の行に書き、担当者、期限、進捗、関連メールへのリンクを付ければ管理できます。ただ、顧客から追加指示が来たときは、誰かが該当する行を書き直す必要があります。作業が終わったときにも更新し、返事が来なければ確認しなければなりません。
Backlogに変えても、登録・更新・確認は必要です。比べたいのは、顧客のメールを制作担当へ転送する、担当の返事をExcelへ写す、上司向けに進捗をまとめ直す、といった作業を減らせるかです。関係者が同じ課題へ直接書き込む運用にできなければ、ツールを変えても取り次ぎや転記は残ります。
公式4事例では、表の更新・取り次ぎ・準備・催促の負担が減った
以下はBacklog公式の導入企業インタビューに基づきます。各社が報告した経験であり、第三者による比較試験でも、同じ効果が自社で出る保証でもありません。Microsoft 365に対する優位性を示す事例としては扱いません。
1．ガントを手で直す代わりに、期限・状態の更新で進捗を表示する：JICE
一般財団法人国土技術研究センター（JICE）は、導入前、Excelでガントチャートを作り、担当者ごとの作業予定を定例会議で確認していました。項目が増えると更新が大変になり、ガントチャートも手動で調整していたと説明しています。
導入後は、Backlogに作業の期限や状態を入力すると、その内容がガントチャートなどに反映されるようになりました。会議でも同じ画面を共有し、作業の状況を聞きながら、その場で状態を更新しています。
減ったのは、進捗を表示するためにExcelのガントチャートを手で調整する負担です。Backlogは、入力した期限や状態から進捗を表示する役割を担っています。担当者への状況確認や「いつ始めるか」の判断が不要になったのではなく、それらを確認しながら同じ画面で更新できるようになった、という話です。
これは同団体の従来のExcel運用との比較であり、すべてのExcel管理で同じ手間がかかるという意味ではありません。また、先の見通しが立ちにくい研究・検討業務では、導入後もタスクの分け方を試行錯誤しています。
2．顧客と担当者が同じ課題を見て、取り次ぎを減らす：ベイジ
Web制作会社のベイジは、顧客や外部パートナーも同じプロジェクトへ招待し、制作の進捗や連絡を共有しています。担当者が状態を更新することで、ディレクターへ毎回報告する手間が省けたと説明。修正の追記が膨らんでいたスプレッドシート時代と比べ、コミュニケーションの負担も減ったとしています。
担当者が助かるのは、顧客側と社内側で別々に情報を持ち、担当者が橋渡しし続ける状態を変えることです。ただし同社は、職種ごとの役割を説明し、入力形式や課題の粒度も調整しています。顧客を招待するだけの運用ではありません。通知に気づくためのチャット連携も併用しています。
社外に見せる情報の範囲は、自社の契約・機密性・権限に合わせて設計してください。同社の「同じプロジェクトに参加する」方法を、すべての案件へそのまま適用する必要はありません。
ベイジの公式導入事例を読む／社外参加・セキュリティの確認事項
3．必要な作業を繰り返し使い、毎回の洗い出しを減らす：東芝DMI
東芝デジタルマーケティングイニシアティブは、シリーズで開催するウェビナーの準備にBacklogを使っています。初めは約10個のタスクで進めていましたが、実施するうちに必要な作業の抜けが見つかり、約100項目へ整理していきました。
例えば、登壇者の写真・プロフィールの回収、司会台本、広告バナー、告知などです。同社は、社外発表の承認に1週間を見込む申請も挙げています。開催直前に思い出しても間に合わない作業を、準備の一覧に含めておく必要がありました。
Backlogでは、整理した作業を次の開催回にも登録し、その回の未完了の作業を顧客と一緒に確認しています。開催回をマイルストーンで分け、一覧を絞り込みます。まとめて確認する細かな作業はチェックリスト、個別に進捗を追う作業は別の課題として扱っています。
つまり、Backlogが担ったのは、繰り返し使う作業一覧を登録し、開催回ごとの進捗を共有することです。必要な作業を洗い出したのは担当者たちです。毎回ゼロから考えるやり方から、整理した項目を使って準備するやり方に変えた結果、企画の具体化は約2か月から約1か月になったと報告しています。
会議前日までに更新し、顧客も同じ一覧を確認するルールも設けています。急ぎの連絡はチャットで行い、決まったことはBacklogへ記録。この運用と作業一覧の整備を含む成果であり、Backlogを入れただけで準備期間が半分になったわけではありません。
なお、導入前にどのツールでウェビナーを管理していたかは、事例から断定できません。同社は作業の再登録に日付調整とCSV登録を使っており、次回分の準備もすべて自動になったわけではありません。
4．聞き返しと人力の催促を減らす：アイティメディア
アイティメディアは、依頼時の情報不足による往復を減らすため、用途別の依頼テンプレートを整備しています。さらにBacklog APIとGoogleスプレッドシートを組み合わせ、未担当・期限切れの課題をチャットへ通知する仕組みを構築。以前のツールに残っていた1年以上未更新の133件が、導入後にはゼロになったと報告しています。
これはBacklogを契約すれば標準機能だけで同じ結果が出る、という話ではありません。テンプレート、通知条件、外部連携、定着の支援を組み合わせた成果です。「依頼を受けたが情報不足で始められない」「誰かが毎回催促している」という部門には、依頼の書き方や通知も含めて、聞き返し・催促を減らす方法を検討できます。
Excel＋チャットでも、更新担当・作業の分け方・状態・確認項目を決めれば管理できる
これらはBacklogでも必要です。導入前に、進行中の案件一つを使って決めてください。以下は運用設計の例で、Backlogの標準設定や各社事例の再現ではありません。
依頼の記録先を一つにし、更新する人とタイミングを決める
- 依頼の正本を一つにし、依頼を受けた人・依頼した人のどちらが登録するかを決める
- 担当・期限・完了条件をそろえてから引き受ける。不足情報の確認者も決める
- 着手、提出、差し戻し、期限変更など、仕事が変わったときに更新する
- メール・口頭・チャットで決まった内容を、誰が正本へ残すか決める
- 急ぎの連絡先と回答期限を決める。「記録したから伝わった」と扱わない
タスクの粒度：別々に完了する仕事は分ける
「Webサイト修正」だけでは、何が残っているのか判断できません。一つの担当・期限・完了条件で追える単位にします。例えば画像差し替えと公開日承認は、担当や完了するタイミングが異なるなら分けます。逆に同じ担当が続けて行う細かな操作まで分けると、更新負担が増えます。
進捗は「80％」だけでなく、完了した件数と残作業で説明する
| 状態の例 | その状態にする条件 |
|---|---|
| 未着手 | 担当・期限・完了条件は合意済み。作業はまだ開始していない |
| 作業中 | 担当者が着手済み。残作業と次の確認予定を説明できる |
| 確認待ち | 成果物を提出済み。確認者・提出先・回答期限が分かる |
| 保留 | 止めている理由、再開条件、判断する人が分かる |
| 完了 | 合意した受入条件を満たし、確認者が了承。必要な証跡が残っている |
数値を使うなら「対象10件中、確認済み7件」のように分母と完了基準を明記します。ただし、各件の難易度が異なる場合、7件完了を工数70％完了とはみなしません。件数、残作業、完了見込みを分けて確認します。
会議では、遅れ・回答待ち・判断が必要な作業を確認する
- 期限に間に合わない可能性がある仕事はどれか
- 止まっている理由と、次に動く人は誰か
- 誰の判断・回答を、いつまでに必要としているか
- 遅れた場合、後続の仕事や顧客への約束にどう影響するか
- 期限変更・担当変更・優先順位の判断が必要か
この運用が共有Excelとチャットで無理なく続き、顧客・協力会社も必要な情報へアクセスできるなら、既存ツールを使い続ける案は十分に合理的です。Microsoft 365などで既に管理が回っている会社へ、履歴や共有の機能だけを理由にBacklogを勧めるものではありません。
取り次ぎ・催促・資料更新に追われるチームは、Backlogで減らせる作業を確かめる
次の負担が実際に残っているチームが、比較の対象です。
- 顧客・協力会社との往復が多い：管理者がメールを転送し、返信を表へ反映し、別の相手に伝え直している
- 他部署の依頼を受ける：依頼情報の聞き返し、担当割り振り、未対応の催促が特定の人へ集中している
- 同種の案件を繰り返す：前回の作業や判断を毎回探し、段取りを作り直している
- 管理表の整備に時間がかかる：一覧・ガント・会議資料を保つための更新が、案件の判断より重い
Backlogなら、これらを課題単位の登録・更新・会話へ寄せる運用を試せます。新しい機能の数より大切なのは、取り次ぎや集約を減らしても、依頼する人・作業する人・判断する人が仕事を進められることです。メール中心の会社でも、外部の相手が参加できず転記がすべて残るなら、期待する効果は小さくなります。
急ぎはチャットで連絡し、決まった内容と進捗はBacklogに書く
チャットを捨てる必要はありません。「急ぎで確認してほしい」「相談したい」は普段の連絡手段を使い、正式な依頼・決定・成果物・状態は課題へ残す、と役割を分けます。チャットには課題へのリンクを添え、同じ説明を両方へ書き続けない運用を目指します。
公式事例でもチャット連携や通知の工夫が使われています。ただし、通知を出すだけでは担当者の了承や対応を保証しません。見落としたときの確認方法、通知条件、連携の保守担当も必要です。APIなどを使う追加自動化の開発・運用費は、利用料とは別に見積もってください。
上司へは「便利になる」より、やめる作業と費用を説明する
提案前に、現在の案件で次の3つを記録します。個別の作業時間を二重に数えないようにし、改善後の登録・更新時間も含めて比較してください。
- 取り次ぎ・転記：誰がどの情報を別の場所へ移しているか。その件数と所要時間
- 聞き返し・催促：情報不足、担当未決定、回答待ちで発生する確認の件数
- 集計・会議準備：状況を一覧にそろえる時間と、資料を作り直す時間
同じ運用ルールで既存ツールの改善案とBacklog案を比べます。ルール改善だけで減る時間を、Backlog固有の効果にしないことが大切です。削減時間は、そのまま給与や現金が減る額でもありません。
社内説明の例
現在、○○業務で依頼・回答がメールに分かれ、○○担当が転記と確認を担っています。まず依頼の粒度と更新ルールをそろえます。そのうえで、既存ツール案とBacklog案を実案件で比較し、取り次ぎ・催促・資料更新がどれだけ残るかを確認します。追加の利用料と初期準備、日々の更新負担も含め、○○作業を置き換えられるかで導入を判断します。
利用料はBacklogの料金・プランの記事、初期費用と創出時間の試算は費用対効果シミュレーターで確認できます。実測前の数字は見込みとして扱い、連携開発や教育の負担も省かずに比較してください。
最初は、取り次ぎが多い案件を一つ選ぶ
全社のメールを一度になくす必要はありません。関係者が参加でき、依頼と回答が複数回発生する案件を一つ選びます。何を課題として分け、誰が登録・更新し、どの転記や報告をやめるかを決めてから試してください。
検証するのは「画面が見やすいか」だけではありません。依頼者が状況を自分で確認できたか、担当者が更新を続けられたか、管理者の仲介作業が減ったかです。合わなければ既存ツールの改善案へ戻せるよう、残すExcelと移す情報も先に決めます。
導入判断の全体像はBacklogが自社に向くかを確かめる基準、具体的な検証手順は次の記事で整理しています。
公式事例は2026年9月28日に確認。掲載内容は各社の取材当時の運用・経験です。運用設計例と社内説明例は当サイトの提案であり、導入効果を保証するものではありません。