--- title: Backlogを使いづらいと感じる理由｜ブログ｜HubSpotやCSS設計に明るい半田 惇志の個人サイト description: Backlog、仕事で触る機会は少なくありません。付き合いも長く10年近く触っています。が、最近使うたびにどうにも据わりが悪い感じがあります。そのモヤモヤの正体を、ちょっと言語化してみました。 image: https://assialiholic.net/hubfs/img/common/logo.svg --- [![Thiking Saladのロゴ](https://assialiholic.net/hubfs/img/common/logo.svg)](https://assialiholic.net) HubSpotやCSS設計に明るい半田のウェブサイトです。 ウェブサイトの本質は情報を伝えることですので、それを言い訳にデザインは全体的に工事中です。 - - [半田について](https://assialiholic.net/about) - [ブログ](https://assialiholic.net/blog) Sep - [業務コミュニケーション](https://assialiholic.net/blog/tag/業務コミュニケーション) # Backlogを使いづらいと感じる理由 シェア： - - Backlog、仕事で触る機会は少なくありません。付き合いも長く10年近く触っています。が、最近使うたびにどうにも据わりが悪い感じがあります。そのモヤモヤの正体を、ちょっと言語化してみました。 前提として私はここ数年はずっとNotionでタスク管理をしており、NotionとBacklogでは設計思想が全然違うのでそこのギャップに違和感を感じている、というだけの話です。 ## 情報の再整理ができない たぶん一番大きいのは、これです。 Backlogでは、一度書いたコメントは消えません。正確には編集も削除もできますが、基本的には課題を開けば時系列のログとして延々と表示され続けます。つまり、書いたものがそのまま最終的な成果物として残り続ける。 そうなると何が起きるかというと、**雑に書けなくなる**。 思いつきレベルのメモ、途中経過の共有、ちょっとした確認事項。そういうものを気軽に投げると、それが未来永劫ログとして表示され続けます。かといって気にせず雑に書き続ければ、課題を開いた瞬間「コメント247件」みたいなことになり、どこに何が書いてあるのかわからないノイズの塊が出来上がります。 そしてノイズの塊を作りたくないから、余計に「これは書くべきか」「書くならどう書くべきか」と考え込むことになる。情報を残すことの心理的ハードルが上がるという、なかなか本末転倒な状況です。 この問題に対する処方箋は、当然ながら「使う側が工夫する」しかありません。私自身、かつてJBUG札幌で[「大事なことはコメントだけに書くなぁ！」](https://assialiholic.tectri.co.jp/blog/technology/jbug-sapporo03)というLTをしています。要するに、ツールの構造上こうなってしまうので、人間側がルールを決めて運用しましょう、という話です。 言っていることは今でも正しいと思っていますが、裏を返せば「そういう工夫を強いられるツールである」ということでもあります。 ## Notionは「雑に書いて後から整理」ができる Notionでは、とりあえず思いついたことをページのどこかに雑に書き殴っておいて、後から見出しを付けたり、順番を入れ替えたり、不要になった部分を消したり、メモしておきたい部分に雑にコメントを入れておいたりできます。書いた内容は「その時点の発言」ではなく「編集可能なコンテンツ」なので、いつでも再構成できる。 雑に書く → 後で整理する、という二段構えが取れるので、書き出しのハードルも、メモ入れのハードルも限りなく低くなります。そして整理のフェーズになって初めて「読み手にとってわかりやすいか」「残すべき重要なログはどれか」を考えればいい。 Backlogには、この二段構えがありません。課題の概要欄は編集できるので例外ですが、コメントとして流れていったものは基本的に再整理の対象外です。書いた瞬間が完成形。だから、書く瞬間に全部考えなければならない。あと概要欄に重要な情報を蓄積していくにしても、単純に概要欄の記法と実際の表示が分離されており「プレビュー」しないと最終的に期待通りの見た目になっているか確認出来ないのが面倒です。 ## Backlogは「コミュニケーションログ」主体である これはBacklogが「コメント」を情報の主体に据えているから起きていることだと思っています。 Backlogの思想はおそらく「経緯を余すことなく残す」です。誰がいつ何を言って、どういう判断が下されて、その結果どうなったか。それが全部時系列で追える。プロジェクト管理ツールとしては、これは明確に一つの正解です。特に受発注が絡む現場や、後から「言った言わない」を検証する必要がある現場では、圧倒的に強いでしょう。 ## 自分の仕事の仕方としてコミュニケーションログは主体ではない Notionにせよ、Googleドキュメントにせよ、スプレッドシートにせよ、コメント機能はあります。しかしそれらにおけるコメントは、**主体ではありません**。 主体はあくまで、そこに最終的に残されるコンテンツ（仕様・経緯・結果・その他残すべきと判断した重要なログ）です。コメントはそのコンテンツをより良い形に導くための、一時的なコミュニケーション手段に過ぎない。「この表現わかりにくくないですか？」「たしかに、直しました」というやり取りは、本文が直った時点で役目を終えます。 だからこれらのツールのコメントには、**「解決」という概念があります**。 解決したコメントは畳まれて視界から消え、本文だけが残る。コメントとは一時的なものである、とツール自体が明言しています。 Backlogのコメントには、この「解決」がありません。当然です。Backlogにおいてコメントは一時的な手段ではなく、それ自体が残すべき記録だからです。解決して畳んでしまったら、経緯が残らなくなってしまう。 結局思想の違いと言えばそれまでですが、「常にコメントがコンテンツとして表示されている」という状況にちょっと違和感を感じてしまいます（昔はそんなこと感じてなかったんですが）。 ## まとめ まとめると、私がBacklogに感じている使いづらさは、 - 書いた情報を後から再整理できない（概要欄は別として） - そのため、書く時点で「どう綺麗に残すか」を考えなければならない（雑にコメントを入れ続けるとノイズになる） - コメントが一時的な手段ではなく、残すべき記録として扱われている - 結果として、コメントを書くたびに毎回それを考えさせられる という辺りです。要するに、コメント欄に文字を打ち込むたびに、頭の片隅で情報設計をやらされている感じがあります。今はとりあえずタスクを前に進めたいだけなんだよなー。 繰り返しになりますが、これはBacklogが悪いという話ではなく、「経緯を余すことなく残す」というツールの思想と、「残すべき情報は選別する」「いつでも再整理する」という私の作法が噛み合っていない、という相性の問題です。 シェア： - - ## コメント ## 関連記事 ## 人気の記事 - [半田について](https://assialiholic.net/about) - [ブログ](https://assialiholic.net/blog) © Atsushi Handa Powered by [HubSpot.](https://www.hubspot.jp/) ```json { "@context" : "https://schema.org", "@type" : "BlogPosting", "author" : { "@type" : "Person", "name" : "半田惇志", "url" : "https://assialiholic.net/blog/author/atsushi-handa" }, "datePublished" : "2026-09-09T15:44:11.000Z", "headline" : "Backlogを使いづらいと感じる理由", "mainEntityOfPage" : { "@id" : "https://assialiholic.net/blog/backlog-why-i-find-it-hard-to-use", "@type" : "WebPage" }, "publisher" : { "@type" : "Organization", "logo" : { "@type" : "ImageObject" } } } ```