3か月後、誰もボードを見なくなる
カンバン導入から3か月後の典型的な風景はだいたい同じです。
「進行中」の列だけがずらっと縦に伸びて、20枚以上カードが並んでいます。完了列はガラ空きか、逆に半年前に終わったカードが化石のように残っています。新しく入った案件のカードがいくつか「未着手」に積まれていますが、誰が担当かのアサインは曖昧です。週次の進行会議では、結局カードを見ずにスプレッドシートの一覧表を見ながら進捗を確認しています。
これは私の主観ではなく、Trelloで小規模チーム向け運用を紹介しているNotePMの記事やSELECK のWeb制作向け事例でも、「全社展開しようとするとリテラシーの差や属人化で続かないことがある」と触れられています。導入して定着させること自体がプロジェクトなんだ、という前提を最初に持たないと、たいていは形骸化します。
正直なところ、ツールを変えても同じことが起きます。Trelloで挫折した会社がNotionに乗り換えて、半年後にまた同じ問題で悩んでいるのを何度か見ました。問題はツールではなく、運用設計の方にあります。
カンバンが制作会社で続かない理由は、だいたい4パターンある
私の周りで聞いた挫折パターンを並べると、4つくらいに集約されます。粒度・判定・WIP・更新負担。順に書きます。
構造1：粒度の違うタスクが同じ列に並ぶ
「コーポレートサイト1本まるごと制作」と「バナー1枚の文言修正」が同じ「進行中」列に並んでいると、見た目の情報量がほぼ等価になります。実際には前者は数週間、後者は30分の作業です。これが起きると、列の長さでは案件の重さも納期の近さも判断できなくなり、何のためにボードを見ているのか分からなくなって、結局スプレッドシートに戻ります。
構造2：着手と完了の判定基準が個人差で揺れる
「これって着手したことになる？」「完了って、納品済み？それともディレクターチェック済み？」という会話が毎週発生する会社は危ない兆候です。
以前いたチームで、Aさんは見積もり送付の瞬間に「完了」へ動かしていて、月次の完了数が水増しされていたことがあります。Bさんはクライアント承認後まで動かさないタイプで、同じ月内に同じ列を見ても、全然違うものを指していました。判定基準が揺れる列は、ボード全体の信頼性を一気に削ります。
構造3：WIP制限が「無い」か「ただの数字」になっている
WIP（Work In Progress、進行中作業の上限数）の概念を知らないまま運用しているチームが多いです。アトラシアンの解説でも触れられている通り、WIP制限はカンバン方式の中核的な仕組みですが、Trelloの無料プランでは設定すらできません。仮にWIP上限を「8」と決めても、超えた瞬間に新規着手を許してしまうと、ただの飾りです。
構造4：ボードを更新する負担が、見る側に返ってこない
これがいちばん根が深くて、いちばん書きたいパターンです。
カードを動かすのは現場のメンバーですが、見て恩恵を受けるのはディレクターや経営層です。動かす側にメリットが感じられないと、月末あたりから更新が止まります。私が最初にカンバンを潰した時の振り返りでも、結局この一点に尽きました。現場が15秒かけてカードをドラッグしても、その15秒で本人に返ってくるものは何もないんですよね。
更新が止まり始めると、見ている側も「最新じゃない情報」を見るのが嫌になって、ボードを開かなくなります。すると現場はますます更新する気を失う、という負のループに入ります。サーバントワークスが公開しているWIP制限の算出シート解説でも、運用初期はチーム全員でカードの動かし方を合わせる時間を取るべきだと書かれています。最初の2週間にここをサボると、その後はずっと尾を引きます。
WIP制限を「制限のための制限」にしない設計
WIP制限の入れ方を間違えると、現場の反発を受けて速攻で外されます。私も最初の導入で「いきなりチームの上限を5に絞ろう」と言って、現場から3日で「無理です」が来ました。
続いた入れ方の起点は、観察期間を2週間とったところです。WIP制限をいきなり入れず、現状の進行中タスク数を毎日数えます。「平均7、最大12」みたいな数字が出てきたら、いきなり半分にせず、最大値の少し下、たとえば「10」あたりから始めます。
そのうえで、上限は個人ではなくチーム単位にします。「Aさんは3枚まで」というやり方は管理コストが上がる割に、効果が薄いです。「チーム全体の進行中は10枚まで」のほうが、メンバー同士で「いま誰の枠が空いているか」を会話する空気が生まれます。
並行して大事なのが、上限を超えそうになったときに何をするかを先に決めることです。新規案件を断るのか、「あとで対応」に逃すのか、優先度の低いカードを未着手に戻すのか。判断ルールを最初に文書化しておかないと、結局なし崩しで超えていきます。そして、WIP制限を入れると表面的には「断る案件」が増えるので、営業や経営層に「なぜ受けない案件があるのか」を説明できる状態をセットで用意します。ここをセットでやれない会社は、たぶんカンバン自体が向いていません。
タスク管理ツール比較Labのカンバン失敗パターン解説でも、「一気に直そうとせず、粒度から順に潰す」「完璧なルールより小さく変えて試す」と書かれていて、これは本当にそうです。最初から完成形を目指すと挫折します。
粒度の違うタスクを同居させる列設計
構造1で挙げた「サイト1本」と「バナー修正」の混在問題は、列の設計で解きます。
私が今やっているのは、ボード自体を2層に分ける運用です。
親ボード（案件レベル）：案件ひとつをカード1枚にします。列は「打診中」「受注済み・着手前」「進行中」「クライアント確認待ち」「納品済み」「クローズ」あたりが目安です。ここで見るのは案件の状態であって、タスクの状態ではありません。
子ボード（タスクレベル）：案件カードの中で、その案件のタスクを別ボードで管理します。「未着手」「今週やる」「進行中」「レビュー待ち」「完了」のような構成です。WIP制限はこちらにかけます。
この2層構造にすると、経営層やクライアント向けには親ボードを見せて、現場のディレクターやメンバーは子ボードで動く、という役割分担ができます。Asanaの公式記事でもボード／タイムライン／カレンダーなど複数ビューを切り替える運用が紹介されていますが、思想としては近いです。
Trelloでこれをやろうとすると、ボードをまたぐリンク運用がやや手間です。Premiumプラン（月額10ドル／ユーザー、Trello公式の料金表より）に上げてアドオン入れる必要が出てきます。Notionの場合はデータベース連携でこの2層は組めますが、Notion側の構築コストがそれなりにかかります。Asanaは標準でポートフォリオビューが用意されていて、複数プロジェクトを横串で見られるのが強みです。
ボードを「日次運用の中心」に置く動線
ボードが続かない最大の理由は、「ボードを開く理由がない」ことです。
カードを動かす作業が、別の場所（チャット、メール、スプレッドシート）で起きた決定の「事後反映」になっていると、必ず形骸化します。逆に、ボードを開かないと進まない動線を作ると、自然に更新されます。動線として効いたのは、朝会・コメント・週次振り返りの3つでした。
朝会は15分でいいので、その日各メンバーが何に着手するかを、ボード上のカードを動かしながら宣言します。口頭で「今日はAの修正やります」だけで終わると、ボードは更新されません。
コメントとメンションは、ボード上で完結させるルールにします。「あのカードのこの部分、こうしませんか？」というやりとりをSlackでやると、決定がSlack側に残ってボード側には反映されません。
週次の振り返りでは、3日以上動いていないカードを抽出して、なぜ止まっているかを話します。これがいちばん効きました。「進行中のカードが流れているか」を毎週見ることで、WIP制限の数字を盲信せずに、本当に詰まっている場所を直すことができます。クライアント待ちで止まっているのか、社内のレビュー待ちなのか、そもそもタスクが大きすぎて分割が必要なのか、止まる理由は毎回違います。サーバントワークスの解説でも、観察→計測→改善のサイクルが強調されていて、止まったカードを定例で扱うルートを作るのは続く運用の最後のピースです。
LOGLIKEでのカンバン運用例
ここから少しLOGLIKEの話をします。私が普段使っているからというのもありますが、「カンバンを単体機能ではなく、案件・顧客・請求と地続きで回す」という設計思想がこの記事の流れに沿うので、参考までに書かせてください。
LOGLIKEのカンバンボードは、課題管理機能と同じ案件の中に内包されています。ここがTrelloやNotion単体のボードと違うところで、カードは独立した付箋ではなく、案件に紐づく課題そのものです。
具体的な運用はこんな感じです。
案件を作ると、その中に課題（タスク）が登録されていきます。同じ課題が、リストビューでも、ガントチャートでも、カンバンボードでも見られます。ディレクターはガントで全体の納期を見て、メンバーはカンバンで自分のカードを動かす、という役割分担が同じ案件の中で完結します。
WIP制限の数字そのものを設定する機能は標準では強くないので、ここはチームのルールでカバーしています。私のチームでは「進行中列は10枚まで」と決めて、超えそうになったら「あとで対応」に逃す運用にしています。「あとで対応」はLOGLIKE独自の機能で、いったん横に置きたいけど忘れたくないタスクの受け皿として機能します。WIPから一時退避するときの置き場として、意外と便利です。
それから、ボードで動かしたカードの状態がダッシュボードに集約されます。経営層やマネージャー視点では、複数案件のカンバン状態を案件横断で一望できる画面が別途あって、「いま全社で進行中のタスクは何件か」「期限超過しているカードはいくつあるか」が把握できます。現場のカンバンを動かすこと自体が、上の数字を更新する動線になっているので、現場と経営の認識ズレが減りました。
TrelloやNotionのカンバンと比べると、ボード単体の自由度ではTrelloのカスタマイズ性やNotionのデータベース連携に分があります。LOGLIKEは「ボード単体で凝ったことをしたい人」には正直向きません。ラベル運用を細かく作り込んだり、Power-Upで拡張したり、というカスタマイズ性は薄めです。制作会社が案件管理と一体でカンバンを回したい、デザイン校正や請求書管理まで同じ画面に並べたい、という用途に寄せた設計なので、汎用ボードツールを探している人は別の選択肢を見たほうがいいです。
まとめ：カンバンは「ボード」ではなく「運用」を入れる
カンバンボードを導入して続かなかった経験は、私だけのものではないはずです。半年経つとボードが化石化していて、誰も開かない、というのは本当によく聞く話です。
続かない理由をツールのせいにしていると、何度乗り換えても同じことが起きます。粒度の違うタスクを同じ列に並べてしまう設計、WIP制限のないままの運用、ボードを開く動線が日次業務にない構造、このあたりが本丸です。
制作会社でカンバンを使うなら、最初の2週間は「WIP制限を入れずに、現在地の数字をただ数える」ところから始めるのが、結局いちばん早かったです。そのうえで親ボード／子ボードの2層を切って、朝会でカードを動かす習慣を作る。完成形から逆算するのではなく、いま動いているチームの実数に合わせて少しずつ削っていくほうが、続きます。
LOGLIKEは、案件・課題・カンバン・ガント・校正・請求を一つのツールで回す設計なので、「カンバンだけ単独で頑張る」状況を構造的に避けられます。「ボードが続かない」という心当たりがある方は、運用設計の見直しと合わせて一度触ってみてください。