結論：「Backlog でお願いします」と言われたフリーランスが取れる選択肢は 4 つ。黙って従う・条件付きで受諾・自分のツール提案・受けない。クライアント規模と関係性で使い分ける。
「次の案件、進行は Backlog でお願いします」
新規クライアントからのメールに、こう書いてある。
すでに 5 社のクライアントを抱えていて、Asana が 2 社、Notion が 1 社、Backlog が 1 社、Excel 管理が 1 社。今、6 社目として新しい Backlog のアカウントが追加されようとしている。
パスワードマネージャーには 50 を超えるエントリ。新しい URL、新しいログイン、新しい運用ルール、新しい通知設定。
「承知しました、よろしくお願いいたします」とすぐ返信できるけど、その瞬間に自分の運営効率が 1 段下がるのが分かっています。
この記事は、「Backlog でお願いします」と言われたフリーランスが取れる、4 つの選択肢を解説します。
なぜ黙って従ってしまうのか
「Backlog でお願いします」と来たとき、ほとんどのフリーランスは即座に「はい」と返事します。
その理由は、構造的に説明できます。
1 つ目は、関係性を壊したくない心理。「いえ、別のツールを使わせていただきたく」と返事するのは、関係構築の最初の段階で「面倒な人」と思われるリスクがある。新規クライアントには特に強く働く心理です。
2 つ目は、選択肢を持っていない感覚。ツール選びは発注側の権限、というのが業界の伝統的な慣習。フリーランスから「別のツールでも」と提案できる、という発想自体を持っていない人が多い。
3 つ目は、メールに即答してしまう習慣。Backlog 指定のメールに対して、5 分以内に「承知しました」と返事するのが礼儀、と感じている。じっくり考えて返事を遅らせる、という選択肢が頭にない。
これらの心理は、フリーランス側に「我慢」だけを蓄積させていきます。
4 つの選択肢
「Backlog でお願いします」に対して、フリーランスが取れる選択肢は 4 つあります。
選択肢 1：黙って従う（デフォルト）
そのまま「承知しました」と返事して、Backlog で運用する。
これが向くケース：
- そのクライアントが大企業で、IT 部門が標準ツールを決めている
- 短期の単発案件で、6 社目のツールを 1〜2 ヶ月だけ我慢すれば終わる
- クライアント側の運用がすでに Backlog 中心に組まれていて、変える価値が小さい
判断基準は「ツール疲弊のコスト < 関係性維持の価値」かどうか。短期 / 単発 / 大企業案件なら、選択肢 1 が現実解になります。
選択肢 2：条件付きで受諾する
Backlog を使うが、運用範囲や運用方法に条件をつける。
切り出し方の例：
「Backlog でのご運用、承知いたしました。1 点ご相談ですが、修正対応の細かいやり取りは Slack のスレッドで進めて、Backlog にはマイルストーンと納品物だけ記録する、という運用でも問題ないでしょうか。修正履歴を Backlog に全部入れると、課題数が膨大になって相互に把握しにくくなる経験があるためです。」
このアプローチでは、Backlog を「全運用の中心」ではなく「主要マイルストーンの記録場所」として位置付ける。日常のやり取りは別ツールに分散できます。
合意が取れれば、Backlog にログインする頻度を週 1〜2 回まで下げられます。完全に避けるのは無理でも、運用負担を 50% 削減できる可能性があります。
選択肢 3：自分のツールに招待する提案を出す
「Backlog ではなく、私が使っているツールに、〇〇様の担当者の方をご招待する形で進められないでしょうか」と提案する。
切り出し方の例：
〇〇様
新規プロジェクトのご相談、ありがとうございます。
進行ツールについて、1 点ご相談させてください。
ご指定いただいた Backlog でも対応可能ですが、もしご検討いただけるなら、
私が使っているタスク管理ツール（Paqut）に、〇〇様の担当者の方を
ご招待する形でも進められます。
ご招待した側（私）の費用負担で、〇〇様にはアカウント登録のみで
ご参加いただけます。月額費用や追加課金はかかりません。
3 分でわかる説明ページを共有させてください：
https://www.paqut.net/for-client/
ご検討いただけますと幸いです。なお、Backlog でも問題なく対応
できますので、ご希望に合わせて進めさせていただきます。ポイントは、「Backlog で対応できる」を明示しながら、「もしよければ別の選択肢もある」と提示すること。クライアントには「断ってもいい」余白を残します。
これで通る確率は、クライアントの規模・性格・既存運用の固さによります。大企業の IT 統制下では難しいですが、小〜中規模の柔軟なクライアントなら通ることも多い。通らなくても、選択肢 1 か 2 に戻れます。
選択肢 4：受けない
最後の選択肢として、案件自体を受けない、もしくは条件交渉を強めるという判断もあります。
これが向くケース：
- クライアント数がすでに上限近くで、新規ツール追加のコストが大きい
- 単価が低く、ツール疲弊のコストを吸収できない
- 既に同じクライアントから複数の運用変更を求められていて、許容範囲を超えている
選択肢 4 は普段はあまり選びませんが、「全てのクライアントの要望に応える必要はない」という基本姿勢を持っておくと、選択肢 1〜3 を選ぶときの心理的な余裕が変わります。
「断れる」前提があると、選択肢 3 の提案も自然に出せるようになります。
4 つの選択肢の使い分け
クライアントとの関係性で使い分けます。
| クライアント | 推奨選択肢 |
|---|---|
| 大企業・IT 統制あり・継続案件 | 1（黙って従う） |
| 中規模・継続案件・運用が確立している | 2（条件付き受諾） |
| 中小規模・新規案件・運用がまだ柔軟 | 3（自分のツール提案） |
| 単価が合わない・ツール疲弊が限界 | 4（受けない） |
判断軸は次の 3 つを乗算した「総合価値」で考えます：
- そのクライアントとの関係性の重要度（長期パートナーシップになるか）
- 案件の単価と継続性
- 自分のツール疲弊度（あと何社追加に耐えられるか）
これらを掛け合わせて、選択肢 1〜4 を選びます。フリーランスの運営は、案件単位の判断と長期視点の判断が両方必要です。
メールに即答しない
どの選択肢を選ぶにせよ、「Backlog でお願いします」のメールに 5 分以内で返事する必要はありません。
「ご連絡ありがとうございます。進行ツールについて少し検討させてください、明日中にご返事いたします」と最初に書いておく。1 日ある時間で、上記 4 つの選択肢から自分の最適解を選ぶ。即答すると、ほぼ自動的に選択肢 1（黙って従う）に流れます。
24 時間あれば、選択肢 2 や 3 を選ぶ余地が生まれます。
クライアントを「悪者」にしない
最後に重要な観点として、「Backlog でお願いします」と指定するクライアントは、悪意があるわけでも、無神経でもありません。
クライアント側は、社内で「進行ツールは Backlog 」という運用ルールがあるから、それを当然のこととしてフリーランスに依頼している。「フリーランス側がツールを選べる時代になった」という認識を持っていないだけです。
選択肢 3 を提案するときも、「あなたが間違っている」ではなく、「もう 1 つの選択肢として」というスタンスで切り出すこと。これが通る確率と、長期的な関係性の両方を守ります。
関連記事
提案の伝え方全般は クライアントに新しいツールを提案するときの 3 つの伝え方、複数ツール使い分けの疲弊への対処は フリーランスが「呼ばれる側」として複数のツールを使い分ける疲弊への対処 を参照してください。
複数クライアント運営の全体像は 個人事業主が複数のクライアント案件をタスク管理ツールで回す方法 にまとめています。
Paqut で、選択肢 3 を実装する
選択肢 3（自分のツールに招待する提案）を Paqut なら 3 ステップで運用できます。
- 自分の個人ワークスペースを 3 分で作る（無料プランで OK）
- クライアントへの提案メールに /for-client/ ページの URL を貼る
- クライアントが OK したら、招待リンクを送る（相手は 30 秒で参加・追加料金 0 円）
「Backlog でお願いします」に対して、選択肢 1 ではなく選択肢 3 を選べる準備をしておく。それだけで、次の Backlog 指定のメールへの返事が変わります。