カンバン方式のタスク管理｜列の作り方で回り方が変わる
カンバン方式のタスク管理を入れてみたものの、板が止まったまま動かない。カードだけが右にも左にも進まず増えていって、結局は誰かがチャットで「あれどうなってます」と聞いて回っている。進行のとりまとめをしている人から、この手の相談はよく出ます。
原因は、たいていの場合ツールの機能ではありません。列の切り方が、そのチームの実際の仕事の流れと合っていないだけです。カンバン方式のタスク管理は、板の上に何本の線を引くか、その線の間で何が起きたらカードを動かすのかを決めた時点で、回り方の大半が決まります。逆に言えば、列の設計をやり直すだけで、同じ道具のまま板は動き出します。
この記事では、カードが流れる仕組みをどう組み立てるか、どこで滞留しているのかをどう見つけるか、そして入れたあとにチームが使い続けてくれるようにするには何を決めておくのかを、順を追って整理します。
カンバン方式のタスク管理が広く使われるようになった背景
ボードに付箋を並べて仕事の状態を示す方式は、いまではソフトウェア開発だけでなく、制作、編集、営業、採用、バックオフィスまで幅広く使われています。5人から数十人規模のチームで「進行管理をどうするか」という話になったとき、選択肢の筆頭にボード型が挙がるのは、もはや珍しいことではありません。
工程表方式が抱えていた構造的な弱点
ボード型が広がる前、進行の管理はガントチャート型の工程表が主役でした。工程表は、いつ何が終わるはずかを時間軸で示せる点で優れています。ただし、運用の負荷が一箇所に集中するという構造的な弱点があります。
工程表を引き直せるのは、たいてい一人か二人です。線を引き直している間、他のメンバーはその表を見られません。見られたとしても、それは更新前の古い状態です。結果として、表は「更新した人の頭の中のスナップショット」になり、実態との差が日々開いていきます。現場では、更新が週に一度になった時点で、表と実態は別物になったと言われています。
さらに、工程表は「予定」を書く道具であって、「いまの状態」を書く道具ではありません。ある作業が予定より3日遅れているとき、工程表はバーを右にずらせば見た目は整いますが、なぜ遅れたのか、いま誰の手元で止まっているのかは表に残りません。とりまとめる立場の人が本当に知りたいのは後者です。
状態を書く方式への移り変わり
ボード型は、この関係を反転させます。列が「状態」を表し、カードがその状態のどこにあるかを示す。予定を書くのではなく、いまを書く。誰でも自分のカードを動かせるので、更新が一人に集中しません。
この考え方の源流としては、製造業の工程間で後工程が必要な分だけ前工程から引き取る仕組み、いわゆるトヨタ生産方式のかんばんがしばしば挙げられます。ただし、そこからソフトウェア開発の現場で使われる板へどう受け継がれたのかについては、解釈にいくつかの流れがあり、ここで定義や歴史を断定することは避けます。実務上重要なのは由来ではなく、「仕事を押し込むのではなく、空いた分だけ引き取る」という発想が、板の設計に反映されているかどうかです。
中小企業のデジタル化について公開されている資料では、おおむね次のような趣旨のことが繰り返し述べられています。
業務のどこに時間がかかっているのかを把握しないまま道具だけを導入しても、生産性の改善にはつながりにくい。まず工程を分解し、どこで仕事が止まっているのかを見えるようにすることが出発点になる。 出典: chusho.meti.go.jp
板を入れる目的も、まさにここにあります。作業を速くするための道具ではなく、どこで止まっているのかを見えるようにするための道具です。この順番を取り違えると、板は「作業一覧の置き場」になり、約2週間で誰も更新しなくなります。
導入が失敗するときの典型的な形
板の導入がうまくいかないとき、症状はだいたい3つに絞られます。1つ目は、カードが「進行中」に溜まり続けて右に流れない状態。2つ目は、板とチャットと表計算ソフトの3箇所に同じ情報が散らばり、どれが正なのか分からなくなる状態。3つ目は、とりまとめる人だけがカードを動かし、他のメンバーは見るだけになる状態です。
この3つはいずれも、機能の不足が原因ではありません。列の意味が曖昧なこと、カードを動かす条件が決まっていないこと、更新の責任が設計されていないことが原因です。順に見ていきます。
カードが流れるとはどういうことか
カンバン方式のタスク管理を回すうえで、最初に共有しておくべき前提があります。それは「カードは人が動かすものではなく、条件を満たしたときに動くもの」という考え方です。この前提を置くかどうかで、板の性格は大きく変わります。
列は状態であって、担当者でも工程の名前でもない
失敗している板を見ると、列が担当者名になっていることがよくあります。「田中」「佐藤」「外注さん」と並んでいる形です。一見わかりやすいのですが、この切り方では板が仕事の流れを表さなくなります。カードは人から人へ渡るのではなく、状態から状態へ進むからです。
同じ理由で、列を組織の部署名や工程名だけで切るのも危険です。「デザイン」「実装」「校正」と並べると、それぞれの列の中に「まだ着手していない」「作業中」「終わったが次に渡していない」が混ざります。混ざった時点で、その列の枚数は何も意味しなくなります。
列は「そのカードがいまどういう状態にあるか」で切ります。最小構成なら「これからやる」「やっている」「終わった」の3列です。担当者は列ではなくカードの属性として持たせます。誰がやっているかはカードを見れば分かる、どこまで進んでいるかは列を見れば分かる。この分担が守られている板は、遠目に見ても状況が読めます。
1枚のカードに書くべき最小の情報
カードに何を書くかは、板が使われ続けるかどうかを左右します。書くことが多すぎると誰も作らなくなり、少なすぎると誰も読まなくなります。
実務上、最低限そろえたいのは4つです。何をするのか（動詞で終わる一文）、誰の手元にあるのか（担当者）、いつまでに終わっているべきか（期限）、そして終わったと言える条件（完了条件）です。このうち抜けやすいのは4つ目の完了条件で、ここが空欄のカードは高い確率で滞留します。「バナーを作る」だけでは、初稿が上がった時点で終わりなのか、先方の確認が通った時点で終わりなのかが人によって違うからです。
逆に、書かなくてよいものもあります。細かい手順、経緯の説明、関係者とのやり取りの全文。これらはカードのコメント欄や添付資料に置き、カードの表面には出しません。表面に出すのは、板を上から眺めたときに読み取れる必要がある情報だけです。カードのタイトルが2行を超え始めたら、それは1枚に詰め込みすぎているか、分割すべき作業が混ざっているサインです。
完了の定義は列の中ではなく、列の間に置く
カードが流れる仕組みを作るうえで、いちばん効くのがこの一手です。「進行中」から「レビュー待ち」に動かしてよいのはどういう状態になったときか。「レビュー待ち」から「完了」に動かしてよいのは誰が何をしたときか。これを列と列の境目ごとに決めて、板の見えるところに書いておきます。
境目の条件が決まっていない板では、カードを動かす判断が毎回属人的になります。ある人は初稿ができた時点で右に動かし、別の人は確認が終わるまで動かさない。この差が積み重なると、板の見た目と実態がずれていきます。とりまとめる立場の人が「板を見ても状況が分からない」と感じるとき、原因はたいていここにあります。
境目の条件は、細かく書く必要はありません。「レビュー担当を指定してコメントを1件書いたら右へ」程度の粒度で十分です。大事なのは、その条件が全員にとって同じ意味になることです。決めたあとは、条件を満たしていないカードが右に動いていたら黙って左に戻す。これを2週間ほど続けると、動かし方は自然にそろいます。
板に乗せる仕事と、乗せない仕事を分ける
すべての仕事を板に乗せる必要はありません。むしろ、乗せすぎると板は使われなくなります。目安として、板に乗せるのは「他の人の手が必要になる仕事」と「途中で止まると誰かが困る仕事」です。5分で終わる自分だけの作業は、乗せなくても構いません。
この線引きを最初に決めておかないと、カードが数百枚に膨らんで、板を開くこと自体が負担になります。逆に、線引きを厳しくしすぎると、板に乗っていない仕事のほうが多くなり、板が実態を映さなくなります。運用を始めて1ヶ月ほど経ったところで、乗せる基準を一度見直すとちょうどよく落ち着きます。
列の作り方で回り方が変わる
ここからが本題です。同じチーム、同じ道具でも、列の設計が違えば板の回り方はまったく変わります。列は増やせば増やすほど詳しくなりますが、増やすほど更新の手間が増え、更新されない列が生まれます。
まず3列から始める
新しく板を作るとき、最初から細かい列を並べたくなりますが、おすすめしません。最初は「未着手」「進行中」「完了」の3列で始めて、運用しながら足りない列を足していくほうが、結果として早く安定します。
理由は単純で、どの列が必要かは、実際に回してみないと分からないからです。設計段階で「デザイン確認待ち」「先方確認待ち」「差し戻し」といった列を用意しても、そのチームで実際に滞留が発生する場所とはずれていることが多い。3列で1週間回すと、カードがどこで詰まるかが目に見えます。詰まった場所に列を1つ足す。この繰り返しが、そのチームに合った板を作ります。
3列で回すときのコツは、「進行中」に入ったカードには必ず担当者と期限が入っている状態を保つことです。担当者のいない進行中のカードは、進行中ではなく未着手です。ここを甘くすると、進行中の列が実質的なゴミ箱になります。
レビュー待ちと確認待ちは、独立した列にする
3列で回して最初に足したくなるのが、この列です。作業そのものは終わっているが、誰かの確認が済んでいないカード。これを「進行中」に置いたままにすると、進行中の枚数が実態より多く見えて、チームの余力が読めなくなります。
さらに重要なのは、この列に入ったカードは「自分では進められない」という点です。作った本人はもう手を離しており、動かせるのは確認する側です。つまりこの列は、他人の時間を待っている場所です。ここが長くなっているとき、遅れの原因は作業者ではなくレビューの体制にあります。列を分けておくと、その事実が板の上に自動的に表示されます。
社外の確認を待つ場合は、社内レビューとさらに分けます。社内の確認は催促できますが、社外の確認は相手の都合に依存します。この2つを同じ列に混ぜると、「催促すべきカード」と「待つしかないカード」が見分けられなくなり、結局は毎回カードを開いて確認することになります。
待ちは「誰の待ちか」で切る
列を足していくとき、原則を1つ持っておくと迷いません。それは「待ちの列は、誰の行動を待っているのかで切る」というものです。
自分たちの手が空くのを待っているのか、レビュー担当の時間を待っているのか、クライアントの返事を待っているのか、外部の納品を待っているのか。この4つは、詰まったときの打ち手がまったく違います。1つ目なら人を割り当てる、2つ目ならレビューの時間を確保する、3つ目なら催促の連絡を入れる、4つ目なら納期を再確認する。列が分かれていれば、板を見た瞬間に打ち手が決まります。
一方で、待ちの理由が同じカードを、案件別や担当者別にさらに細かく分けるのは避けます。それはカードの属性で表現できることであり、列を使う必要がありません。列を増やしてよいのは、打ち手が変わるときだけ。この基準を守ると、列は7つ前後で自然に収まります。
列が増えすぎたときの見分け方
列を足していくうちに、いつのまにか10列を超えていることがあります。増えすぎた板には、はっきりした症状が出ます。
1つ目は、常に空の列があること。3週間見ていて一度もカードが入らない列は、そのチームには不要な状態です。2つ目は、カードが1日のうちに2列以上まとめて動く列があること。これは、その2つの列の間に実質的な待ちが存在しないことを意味します。3つ目は、どの列に入れるべきか迷うカードが定期的に出ること。これは列の定義が重なっているサインです。
いずれの場合も、列を減らします。減らすときは、統合先の列にカードを移してから空の列を消す。この順番を守らないと、カードが行き場を失って一時的に板から消えます。列の削除は、週次の振り返りのタイミングでまとめてやると混乱が少なくなります。
縦の列だけでなく、横の帯も使う
多くのボード型ツールには、列とは別に横方向の区切り（スイムレーン）を置く機能があります。列が状態を表すのに対し、横の帯は「種類」を表すのに向いています。案件別、チーム別、あるいは「通常」と「急ぎ」の2本だけといった使い方です。
とくに効くのが、急ぎのカードを1本の帯にまとめる使い方です。割り込み仕事を通常のカードと同じ場所に混ぜると、通常の仕事がどれだけ押されているのかが見えなくなります。急ぎを別の帯に上げておくと、「今週は割り込みが5枚入った」という事実が板に残り、なぜ通常の仕事が進まなかったのかを後から説明できます。
ただし、帯も増やしすぎると列と同じ問題を起こします。帯は3本までを目安にして、それ以上分けたくなったらボード自体を分けるほうが見通しがよくなります。
滞留をどう見つけるか
板を作る目的は、どこで止まっているかを見えるようにすることです。ところが、板を導入しただけでは滞留は見えません。見つけるための読み方を決めておく必要があります。
滞留は枚数ではなく、日数で見る
板を眺めたとき、人はつい「カードが多い列」に目が行きます。しかし枚数が多い列が問題の列とは限りません。枚数が多くても、毎日入れ替わっているなら流れています。逆に、枚数が3枚しかなくても、その3枚が2週間動いていないなら、そこが最大の詰まりです。
見るべきは、各カードがその列に入ってから何日経っているかです。多くのボード型ツールには、カードが更新されていない期間を示す表示や、期限超過の色分けがあります。無い場合でも、カードに「この列に入った日」を書く運用にすれば代用できます。
目安として、進行中の列に5営業日以上とどまっているカードは、何かが起きていると考えて中身を確認します。レビュー待ちなら2営業日、社外の確認待ちなら5営業日を超えたら連絡を入れる、といった基準をチームで決めておくと、確認のタイミングが属人的になりません。
進行中の枚数に上限を置く
滞留を防ぐうえで、もっとも効果が分かりやすいのがこの手です。「進行中」の列に置けるカードの枚数に上限を決めて、上限に達している間は新しいカードを進行中に入れない、という約束にします。
上限の決め方は、担当者1人あたり2枚から3枚が出発点です。5人のチームなら進行中は10枚から15枚まで、という形になります。この上限に達したら、新しい仕事を始める前に、いま進行中のどれかを完了させるか、止まっている理由を解消しにいく。この順番が強制されることで、着手だけが増えて完了が増えない状態を防げます。
上限を入れると、最初のうちは窮屈に感じます。手が空いたように見える人が「新しいカードを取れない」と言い出すことも起こります。そういうときこそ、その人には止まっているカードの支援に回ってもらいます。これが、仕事を押し込むのではなく引き取るという発想の実践部分です。上限は運用の途中で調整して構いませんが、上限そのものを外してしまうと、板は元の状態一覧に戻ります。
週に一度、右から左に読む
板の読み方には順番があります。ふだんカードを作るときは左から右に見ますが、振り返りのときは右から左に読みます。
まず完了の列を見て、今週何が終わったかを確認します。次に確認待ち、レビュー待ちと左に戻りながら、それぞれの列で止まっているカードを1枚ずつ見ます。最後に未着手を見て、来週着手するものを決めます。この順番だと、最初に「終わったこと」を確認できるので会議の空気が悪くなりにくく、かつ止まっている場所を飛ばさずに拾えます。
左から見ると、未着手の山に時間を取られて、右側の詰まりまで到達しないまま時間切れになります。振り返りの会議が毎回「来週何をやるか」の話だけで終わっているチームは、読む順番を変えるだけで内容が変わります。所要時間は、カード30枚程度の板なら30分で十分回せます。
動かないカードにどう対処するか
止まっているカードを見つけたあと、何をするかを決めておきます。選択肢は4つしかありません。進める、分割する、預け先を変える、閉じる。
進めるのは、単に手が回っていなかった場合です。この場合は、その週のどこで手をつけるかまで決めます。分割するのは、カードが大きすぎて着手できていない場合です。1枚のカードが5営業日以上かかる見込みなら、着手できる単位まで割ります。預け先を変えるのは、担当者が抱えきれていない場合です。責める話ではなく、板の上で配分を直す作業として扱います。
そして4つ目、閉じる。これがいちばん見落とされます。約3ヶ月動いていないカードは、多くの場合すでに不要になっているか、誰も本気でやる気がない仕事です。閉じることを議題に載せられる板は健全です。閉じるのが後ろめたい場合は、「保留」の列を1つ作って、そこに移したうえで四半期に一度まとめて棚卸しする形にすると運用しやすくなります。
入れたあとに使い続けてもらうための設計
道具の導入で失敗する原因の大半は、機能ではなく定着です。とりまとめる立場の人が本当に気にしているのは、板が便利かどうかより、来月もチームが更新してくれているかどうかです。
更新する人を増やす
板が止まる典型的な形は、とりまとめる人だけがカードを動かしている状態です。こうなると、その人が休んだ週に板が丸ごと止まります。しかも、他のメンバーにとって板は「報告先」になり、自分の作業の道具ではなくなります。
更新する人を増やすには、更新の手間を減らすのがいちばん確実です。カードを動かすのにログインし直したり、必須項目を5つ埋めさせたりする設計になっていると、更新は続きません。カードを右に1つ動かす操作が、数秒で終わること。これが定着の最低条件です。
もう1つ効くのが、「板に書いていない進捗は報告として扱わない」という約束です。厳しく聞こえますが、二重管理をやめる宣言でもあります。チャットで報告し、板でも報告し、会議でも報告する状態が続くと、いちばん手間のかかる板から先に更新されなくなります。報告の入り口を板1つに絞ると、更新は自然に増えます。
会議の場で必ず板を開く
定着のための施策として、費用対効果がもっとも高いのがこれです。進捗確認の会議で、資料を作らずに板を映す。それだけで、板が最新でないと会議が成立しない状態が生まれます。
このとき大事なのは、会議のために板を整えないことです。会議の直前にとりまとめる人がカードを並べ直していると、結局その人だけが更新する構造に戻ります。板は普段の状態のまま映して、抜けているところはその場で本人に直してもらう。最初の数回は空白が目立ちますが、3週間もすれば板のほうが先に更新されるようになります。
会議の時間も短くなります。資料作成の時間がゼロになり、状況説明の時間も短くなるからです。カード30枚程度の板なら、週次の進捗確認は15分で終わる形まで持っていけます。
通知と板の役割を分ける
チャットツールと板を併用しているチームは多く、ここの役割分担を決めないと情報が二重化します。原則はシンプルで、話す場所と残す場所を分けることです。
議論、相談、雑談はチャットで行い、決まったことと今の状態は板に書く。チャットの会話は流れて消えるものとして扱い、後から参照する必要がある内容はカードのコメントに転記します。逆に、板の変更をすべてチャットに通知する設定にすると、チャットが更新通知で埋まって議論が流れます。通知は「自分が担当のカードが動いたとき」「期限が近いとき」程度に絞るのが現実的です。
なお、通知を細かく制御できるかどうかはツールによって差があります。導入前に確認しておくと、あとで運用の逃げ道がなくなる事態を避けられます。
一度に全部を移さない
既存の管理方法から板に移すとき、全案件を一度に移そうとすると失敗しやすくなります。移行の作業量が大きいうえに、うまくいかなかったときに戻る場所がなくなるからです。
現実的なのは、1つのチームか1つの案件だけを板に移し、他は既存のやり方のまま残す形です。1ヶ月ほど並走させて、板のほうが早いと現場が感じたら範囲を広げる。この進め方なら、列の設計を試行錯誤する余裕も生まれます。移行の途中で列を変えるのは、対象が1案件なら数分の作業ですが、全社に広げた後だと合意形成だけで数週間かかります。
道具を選ぶときに見るところ
ここまでは列と運用の話でした。最後に、道具そのものの選び方を整理します。カンバン方式のタスク管理ができるツールは数多くあり、機能表を並べて比べても差が見えにくいのが実情です。
いまの道具のままがよい場合
先に、乗り換える理由がない場合を挙げておきます。いまの道具で板が回っていて、メンバーが自分でカードを動かしていて、滞留が週次で拾えているなら、乗り換える必要はありません。ツールを変えると、列の定義もカードの書き方も一度リセットされます。回っている板をわざわざ止めるのは損です。
また、外部サービスとの自動連携が業務の中心にある場合や、ソースコードの管理と一体で動かしたい場合も、それらに強い道具を使い続けるほうが合理的です。板の使い勝手だけで選ぶと、周辺の作業が増えて結局は元に戻ります。
英語圏のメンバーがいる場合も同様で、画面の言語が日本語だけの道具は選択肢から外れます。この点は、機能の優劣ではなく前提条件の話です。
乗り換えを考える境目
一方で、次のような状態になっているなら、道具側に原因がある可能性があります。人数が増えるたびに料金が跳ね上がり、見るだけのメンバーにも同じ費用がかかっている。必要な機能が上位プランにあり、そのために全員分を上げる必要がある。ボードの数に制限があり、案件ごとに板を分けられない。無料の範囲を超えた瞬間に、料金の考え方が読みにくくなる。
料金体系の設計思想は、選ぶうえで意外に大きな差になります。機能で絞らず、区切るのは人数とボードの数だけという形の料金は、「この機能を使いたいから全員分を上位プランにする」という判断を不要にします。逆に、機能ごとにプランが分かれる形は、大きな組織で細かく最適化したい場合に向きます。どちらが優れているという話ではなく、チームの規模と使い方で合う形が変わります。
各サービスの料金は改定されるため、比較するときは必ず公式の料金ページで、いつ時点の金額か、税抜か税込かを確認してください。当サイトでも料金のページで、人数とボードの数だけで区切る考え方と、その時点の金額を公開しています。
主要なツールとの違いをどう調べるか
いま使っている道具と、検討している道具の違いを調べるとき、機能表の丸バツだけを見ても判断できません。同じ「カンバンボードあり」でも、列の数の上限、カードの表示項目、権限の細かさが違います。実際の比較は、自分たちが毎日やる操作が何手で終わるかで見るのが確実です。
主要なサービスごとの違いは、それぞれの比較ページにまとめてあります。付箋の手軽さで広く使われているサービスとの違いはTrelloとの比較に、タスクの依存関係やレポート機能まで含む多機能なサービスとの違いはAsanaとの比較にまとめています。文書とデータベースを一体で扱う自由度の高いツールとの向き不向きはNotionとの比較に、業務ごとの自動化に強いサービスとの違いはmonday.comとの比較に整理しました。
国内の開発現場で使われることの多い課題管理型のサービスとの違いはBacklogとの比較、日本語のボード型として近い位置にあるサービスとの違いはJootoとの比較にあります。どれから見ればよいか決まっていない場合は、比較の一覧から現在使っている道具を選ぶのが早道です。
機能そのものの範囲を先に把握したい場合は、できることのページに、列とカードの扱い、権限、通知の設計をまとめています。
移行のときに詰まるところ
道具を変えるとき、いちばん時間を取られるのはカードの移し替えです。案件が10件、カードが200枚あると、手作業では丸1日では終わりません。ここは、自動で取り込める仕組みがあるかどうかで作業量が桁違いになります。
ただし、自動移行が使える範囲はサービスによって限られます。当サイトの場合、自動で取り込めるのはTrelloからのみで、他のサービスからは手作業か表計算ソフト経由の取り込みになります。この点は先に把握しておかないと、移行計画が崩れます。移行手順の詳細はTrelloからの移行にまとめてあります。
もう1つ、社内で承認を取るときに必ず聞かれるのがデータの扱いです。どこにデータが保存され、誰がアクセスでき、退会したときにどうなるのか。ここは導入検討の初期に確認しておくと、後戻りが減ります。考え方は安全性の考え方に記載しています。運用上の細かい疑問はよくある質問にまとめてあるので、稟議の材料として先に目を通しておくと話が早く進みます。
比較ページから読み取れる、選ばれ方の傾向
各サービスとの比較ページを横断して眺めると、ボード型の道具が検討される場面には、いくつかのはっきりした型があることが分かります。
もっとも多いのは、無料で使い始めた板が人数の増加とともに窮屈になり、有料化の判断を迫られている場面です。この段階で問題になるのは機能ではなく、料金の増え方です。見るだけのメンバーにも作業者と同じ費用がかかる設計だと、10人を超えたあたりから金額が読みにくくなります。比較ページで料金の項目が最初に置かれているのは、この相談が多いからです。
次に多いのが、多機能なツールを入れたものの、機能の8割が使われていない状態です。設定項目が多い道具は、うまく使えば強力ですが、設定できる人が一人しかいないと、その人が離れた時点でメンテナンスが止まります。5人から数十人のチームでは、機能の多さより「設定を覚えなくても回るか」が効きます。
3つ目は、文書ツールやチャットツールの中でタスクを管理していて、進行の状態が読み取れなくなっている場面です。自由度の高い道具はどんな形にも作れる反面、チームごとに構造が違ってしまい、他の案件の板を見ても読めません。板の形が決まっていることは制約ですが、複数の案件を横断して見る立場の人にとっては利点になります。
一方で、比較ページでは自分たちの弱いところも明示しています。ソースコードのリポジトリ機能は持っていないこと、自動化や外部サービスとの連携では勝負していないこと、画面が日本語のみであること、自動で取り込めるのがTrelloだけであること。この4点に該当する要件が業務の中心にあるなら、比較の土俵に乗らないと考えたほうが早いです。比較の記事で自社に不利な条件を先に書いているのは、検討の途中で気づいて時間を無駄にする人を減らすためです。
最後に、どの比較ページにも共通して書かれていることを1つ挙げます。それは、道具を変えても列の設計は自動的には良くならない、という点です。いまの板が止まっている理由が列の切り方にあるなら、道具を変えた先で同じ列を作れば、同じところで止まります。移行を検討する前に、この記事で挙げた3列からの作り直しを、いまの道具のまま1週間試してみてください。それで回るようになるなら、乗り換えの判断は先送りできます。回らないのであれば、その原因が列の設計なのか、道具の制約なのかが、そこではっきりします。
Q1. カンバン方式のタスク管理は、最初にいくつの列から始めるのがよいですか？
「未着手」「進行中」「完了」の3列から始めるのが確実です。どの列が必要かは実際に回してみないと分かりません。1週間動かすとカードが詰まる場所が見えるので、そこに列を1つ足していきます。設計段階で細かい列を並べると、使われない列が生まれて更新が止まります。列は最終的に7つ前後に収まることが多いです。
Q2. 板が止まってしまう原因はどこにありますか？
多くの場合、列と列の境目でカードを動かしてよい条件が決まっていないことが原因です。ある人は初稿ができた時点で右に動かし、別の人は確認が終わるまで動かさないと、板の見た目と実態がずれます。境目ごとに「レビュー担当を指定してコメントを1件書いたら右へ」といった条件を決め、板の見えるところに書いておくと解消します。
Q3. 滞留しているカードはどうやって見つければよいですか？
枚数ではなく、その列に入ってからの日数で見ます。3枚しかない列でも、2週間動いていなければそこが最大の詰まりです。目安として進行中は5営業日、レビュー待ちは2営業日を超えたら中身を確認します。週次の振り返りでは、完了の列から左へ順に読むと、止まっている場所を飛ばさずに拾えます。
Q4. ツールを乗り換えるべきかどうかは、何で判断すればよいですか？
いまの道具で板が回っていて、メンバーが自分でカードを動かせているなら乗り換える必要はありません。判断が必要になるのは、人数が増えるたびに料金が跳ね上がる、必要な機能のために全員分を上位プランにする必要がある、ボード数の制限で案件ごとに板を分けられない、といった場合です。料金は改定されるため、必ず公式の料金ページで時点と税の扱いを確認してください。