カンバンの列設計で決めること｜完了の手前に何を置くか

カンバンの列設計でつまずくチームは、たいてい「工程をどう分けるか」から考え始めます。ところが板が止まる本当の原因は工程の分け方ではなく、完了の手前に溜まっている待ちが、どこにも列として存在していないことにあります。作業は終わっているのに完了になっていないカードが増え、理由を聞くと「先方の確認待ちです」「部長の承認待ちです」と返ってくる。その状態が板の上では「進行中」としか表示されていないなら、列設計はまだ仕事をしていません。この記事では、確認待ちや承認待ちをどう列にするか、列を増やしすぎると何が起きるか、仕掛かりの数をどう絞るかを、5人から数十人のチームで進行を預かる立場から整理します。

列設計が難しくなったのは、仕事の待ち時間が見えなくなったから

カンバンという考え方そのものは新しいものではありません。作業の状態を横に並べ、カードを左から右へ動かすという仕組みは、板と付箋があれば成立します。それでも列設計が改めて悩みの種になっているのは、チームの働き方が変わって、待ち時間の在り処が目で見えなくなったからです。

同じ部屋で働いていた時代は、誰かの机の上に書類が積まれていれば、そこで止まっていることが分かりました。隣の席の人が電話中なら、その案件が今日は動かないことも分かりました。1つの部屋に全員がいるという条件が、待ちの可視化を無料で引き受けていたわけです。

その条件が外れると、待ちは急に見えなくなります。在宅勤務や拠点分散、外部の協力者との分担が当たり前になったチームでは、カードが動かない理由が本人にしか分からない状態が生まれます。とりまとめる立場の人は、板を見ても「動いていない」ことしか分からず、なぜ動いていないのかを一件ずつチャットで聞いて回ることになります。この確認作業が、進行管理の時間の大半を食い潰します。

待ちが見えないと、まず信頼が落ちる

進捗が見えない状態が続くと、チームの中で起きることは決まっています。とりまとめる人が確認の回数を増やし、聞かれる側は「催促された」と感じ、催促を避けるために「進んでいます」と曖昧に答えるようになります。板の上の情報が実態からずれ始め、ずれた板は誰も見なくなります。

現場でよく聞くのは、導入から2週間ほどで誰もカードを動かさなくなったという話です。原因は道具の使い勝手ではなく、動かす意味がなかったことにあります。自分が持っているカードを「作業中」から動かせる先が「完了」しかないなら、確認待ちで止まっている人は永遠に「作業中」に置き続けるしかありません。動かせないカードは、動かさないカードになります。

工程の分割は、公的な整理でも「節目の確認」を含んでいる

開発や制作の工程を整理した公的なガイドラインでも、作業そのものと同じ重みで、段階の切り替わりにおける確認が位置づけられています。

節目ごとに、必要な成果物がそろっているか、次の段階へ進んでよいかを関係者で確認する。この確認を経ずに次の段階へ進むと、後工程で手戻りが生じやすくなる。 出典: ipa.go.jp

ここで言われている「関係者で確認する」という行為は、板の上ではカードが動かない時間として現れます。つまり確認は工程の外側にあるおまけではなく、工程そのものです。にもかかわらず、多くのチームの板には確認のための列がありません。作業の列だけを並べて、確認は各自の頭の中で処理させている。列設計の失敗のほとんどは、この一点に集約されます。

列は工程を表すものではなく、状態を表すもの

列設計を考えるときの出発点を、はっきり決めておきます。列は「誰が何をするか」ではなく、「そのカードがいまどういう状態か」を表します。この違いは言葉遊びに見えますが、運用に乗るかどうかを分けます。

工程で列を切ると、担当者ごとの列ができてしまう

工程を基準に列を作ると、「デザイン」「コーディング」「文章作成」「入稿」のような並びになります。一見すると自然ですが、この並びには構造的な弱点があります。工程は担当者と結びついているので、列がそのまま担当者の持ち場になり、板が「誰の仕事がどれだけ溜まっているか」を示す表に変わります。

そうなると、カードを動かす動機が変わります。自分の列からカードを出すことが「仕事を減らすこと」になり、次の列へ押し込む圧力が生まれます。受け取る側は準備ができていないのにカードが積まれ、押し込まれた側は「まだ見ていない」カードを抱えます。板の上ではカードが右へ進んでいるのに、実態は何も進んでいないという状態がここで生まれます。

さらに、工程で切った列は仕事の種類が変わるたびに作り直しが必要になります。制作物によって工程の順序が変わるチームでは、ある案件は「デザイン」を飛ばし、別の案件は「入稿」が二度あるといったことが起きます。列に当てはまらないカードが増え、例外を説明する運用ルールが積み上がっていきます。

状態で列を切ると、待ちが自然に列になる

状態を基準にすると、並びは「未着手」「作業中」「確認待ち」「完了」のようになります。工程名が消え、代わりにそのカードが今どうなっているかだけが残ります。担当者は列ではなくカード側の情報として持ちます。

この切り方の利点は、待ちが列として自然に現れることです。誰かの手が離れて、他人の返事を待っている状態は、作業中とは明確に別の状態です。別の状態なら別の列に置くのが筋であって、それだけのことです。

もうひとつの利点は、仕事の種類が変わっても列が壊れないことです。デザインでも文章でも見積作成でも、「まだ手を付けていない」「いま手を動かしている」「他人の反応を待っている」「終わった」という状態は共通しています。列を状態で切っておけば、板をチームごとに作り直す必要が減ります。

「作業中」に入っているカードの半分は作業されていない

板を運用しているチームで一度やってみる価値があるのが、朝の時点で「作業中」に入っているカードを一件ずつ見て、今日その人が実際に手を動かす予定があるかを確認する作業です。多くの場合、実際に手が動くカードは一部で、残りは「相手の返事を待っている」「材料が揃うのを待っている」「他の案件を先にやっている」のいずれかです。

この確認を一度でもやると、「作業中」という列がどれだけ情報を持っていないかが分かります。作業中の枚数が20枚あっても、そのうち今日動くのが6枚なら、板が示している「20件が進行中」という情報は嘘です。とりまとめる立場の人が計画を立てる材料としては使えません。

完了の手前に何を置くかで、板の役に立ち方が変わる

ここが列設計の核心です。左側、つまり未着手から作業中までの並びは、どのチームでもだいたい似た形に落ち着きます。差が出るのは右側、完了の直前に何を置くかです。

確認待ちを列にする

まず置くべきは、作った本人以外の目が入る前の状態です。名前は「確認待ち」「レビュー中」「チェック待ち」のいずれでも構いませんが、意味は作業した人の手を離れ、別の人の反応を待っている状態で統一します。

この列を作ると、板の見え方が変わります。確認待ちにカードが10枚以上溜まっているなら、それは作る側の速度ではなく、確認する側の速度が律速になっているということです。人を増やすなら作る側ではなく確認する側であり、外注を検討するなら制作ではなくレビューです。列がなければ、この判断材料は板の上に一切現れません。

確認待ちの列を作るときに必ず決めておくことが2つあります。誰が確認するのかと、確認が終わったら誰がカードを動かすのかです。この2つが決まっていないと、確認待ちは「誰の担当でもないカードの置き場」になり、ゴミ箱と同じ役割を果たすようになります。実務としては、確認する人をカードの担当者欄に付け替える運用が分かりやすく、動かすのも確認した本人にするのが混乱が少ないやり方です。

承認待ちを列にする

確認と承認は分けたほうがよい場面があります。確認は内容が正しいかを見る行為で、承認は出してよいかを決める行為です。前者はチーム内で完結しますが、後者は上長や顧客など、チームの外側の人が関わることが多く、待ち時間の桁が変わります。

チームの外側が絡む待ちを内側の待ちと同じ列に入れると、板の詰まりの原因が読めなくなります。3日で返ってくる社内レビューと、2週間かかる顧客承認が同じ列に混ざっていると、その列の滞留は平均でしか語れず、対策の打ちようがありません。

承認待ちを別の列にすると、とりまとめる立場の人にできることが増えます。承認待ちの列だけを見て、依頼した日付が古い順に並べ、先方への催促をまとめて出せます。承認待ちが常に膨らんでいるなら、承認の頻度を上げる交渉、あるいは承認が要る条件そのものを見直す交渉の材料になります。これは板がなければ「なんとなく遅い」で終わっていた話です。

差し戻しをどう扱うかを先に決める

確認や承認の列を作ると、必ず出てくるのが差し戻しです。確認で問題が見つかったカードをどこに戻すか。ここには2つのやり方があり、どちらを選ぶかで板の情報量が変わります。

ひとつは、差し戻し用の列を作らず、カードを「作業中」に戻す方法です。列の数が増えないので板はすっきりしますが、そのカードが初回の作業なのか手戻りなのかが区別できなくなります。手戻りがどれだけ発生しているかを把握したいチームには向きません。

もうひとつは、カードにラベルや目印を付けて作業中に戻す方法です。列は増えないまま、手戻りの件数だけは数えられます。多くのチームにとってはこちらが現実的です。差し戻し専用の列を作るやり方もありますが、その列は「作業中と同じ状態のカードが入る列」なので、状態で切るという原則からは外れます。列を増やす前に、ラベルで足りないかを検討する価値があります。

「完了」の定義を列の名前で縛る

最後に、完了の列そのものについてです。完了が何を意味するのかがチーム内で揃っていないと、確認待ちや承認待ちの列を作っても効果が半減します。

よくあるずれは、作った人にとっての完了と、とりまとめる人にとっての完了が違うというものです。作った人は納品物を送った時点で完了だと思い、とりまとめる人は請求まで済んで完了だと思っている。この状態で「完了」の列を見ても、そこに入っているカードの意味は人によって違います。

対処は単純で、列の名前を具体的にすることです。「完了」ではなく「納品済み」、「done」ではなく「請求済み」のように、誰が読んでも同じ状態を指す言葉にします。名前を具体的にすると、その手前に足りない列も自然に見えてきます。納品済みという列を作ったチームは、その手前に「納品待ち」が必要かどうかを考えることになり、考えた結果として待ちが1つ可視化されます。

列を増やしすぎると、板は見られなくなる

ここまで「待ちを列にせよ」と書いてきましたが、そのまま突き進むと今度は逆の失敗が起きます。列は増やせば増やすほど情報が増えるように思えますが、実際には一定の数を超えたところで板の価値が急に落ちます。

横スクロールが発生した板は、全体像を失う

画面に収まらない板は、全体像を見るための道具としての役割を失います。カンバンの最大の利点は、チームの仕事の全部が一目で入ることです。横にスクロールしないと右端が見えない板は、その利点を捨てています。

一般的な画面の幅を考えると、列は5つから7つが目安になります。それ以上を並べたいなら、列を減らす工夫ではなく、板を分ける判断のほうが正しいことが多いです。

列が多い板でもうひとつ困るのが、朝礼や定例で板を画面共有したときです。全員で同じ画面を見ているのに、話題になっている列が画面外にあるという状況が起きます。共有画面を横に動かしながら話す会議は、参加者の集中を確実に削ります。

誰も動かさない列が生まれる

列を増やしたチームで観察されるのが、実質的に使われない列の発生です。設計した時点では意味があったのに、運用が始まると誰もそこにカードを置かない。あるいは置いたきり誰も動かさない。

こうなる原因は、その列に入るための条件と、出るための条件が決まっていないことにあります。「保留」や「その他」といった名前の列は特にそうなりやすく、判断に困ったカードの避難先として使われ、最終的にカードの墓場になります。

板を見直すときは、各列について「先月このカードが入った件数」と「出た件数」を数えてみる価値があります。入る件数が少ない列は統合の候補で、入るのに出ない列は運用ルールが欠けている列です。

列と担当者を1対1で結びつけない

列設計で避けたほうがよい形として、担当者ごとに列を作るやり方があります。「Aさん」「Bさん」「Cさん」という並びの板です。誰が何を持っているかは一目で分かりますが、この形には決定的な弱点があります。

仕事の状態が一切分からなくなることです。Aさんの列に8枚のカードがあるとして、そのうち今日手を動かすものはどれか、確認待ちで止まっているものはどれか、板からは読み取れません。担当者は列ではなくカードの属性として持ち、列は状態に使う。この原則を守ると、板は担当者が変わっても壊れません。

人ごとの状況を見たいときは、列を分けるのではなく担当者での絞り込みを使います。多くのボード型のタスク管理ツールがこの絞り込みを備えているので、できることのような機能の説明ページで、担当者による絞り込みと状態の列を両立できるかを確かめておくと選定が早く進みます。

仕掛かりの数を絞ると、詰まりが自分から出てくる

列設計と対で考えるべきなのが、各列に同時に置けるカードの上限です。仕掛かり、つまり手を付けたが終わっていない仕事の数を絞るという考え方で、列設計の効果を実際の進み方に変える仕組みでもあります。

なぜ絞るのかを、チームに説明できるようにする

上限を設ける目的は、仕事を制限することではなく、詰まりを表面化させることです。上限がない板では、前の工程で作られたカードが後ろの工程にどんどん積まれていきます。積まれても列は縦に伸びるだけで、誰も困りません。困らないので、詰まりは放置されます。

上限を設けると、積めなくなった時点で前の工程の人が手を止めることになります。手が止まると、その人は「なぜ止まっているのか」を考えざるを得ません。上限の本当の役割は、後ろの工程で起きている詰まりを、前の工程の人に自分ごととして伝えることです。

この説明を先にしておかないと、上限は「作業量の制限」と受け取られて反発を招きます。上限は個人の評価に使わない、という点も同時に伝えておく必要があります。

上限の決め方

最初の上限は、精緻に計算するより、粗く決めて後から直すほうがうまくいきます。実務的な目安として使われているのが、その列を担当する人数に1.5を掛けた数です。4人で回している列なら上限は6枚、という決め方になります。

なぜ人数ぴったりではないかというと、正当な待ちが存在するからです。1人が1枚しか持てない設計にすると、確認待ちで手が空いた人が次の仕事に着手できません。かといって余裕を持たせすぎると上限が機能しません。人数の1.5倍前後は、その中間として使いやすい数です。

確認待ちや承認待ちの列については、少し考え方が変わります。これらの列は自分たちの手が動いていない時間なので、上限を厳しめに設定する価値があります。承認待ちの上限を5枚に決めておけば、6枚目を入れたい時点で「そろそろ先方に催促しよう」という行動が発生します。上限は催促の合図としても働きます。

上限に当たったときにやること

上限に達したら、新しいカードを入れる前に、その列にあるカードを1枚出すことを優先します。ここで大事なのは、出すために手伝うという選択を許すことです。

確認待ちが上限に達したら、作る側の人が確認に回る。承認待ちが上限に達したら、とりまとめる人が催促に回る。自分の担当工程ではないから待つ、という判断をしないことが、上限を設けた意味を生かす条件になります。

上限に当たる回数が多い列は、そこが慢性的なボトルネックです。そこだけ人を増やす、そこだけ手順を簡略化する、そこだけ外注する、といった判断が、板の記録から根拠を持って出せるようになります。

上限を守れないなら、列の設計のほうが間違っている

運用してみて上限がどうしても守れない列が出てきたら、上限の数字を上げる前に、その列の定義を疑ってください。守れない列にはたいてい、性質の違う仕事が混ざっています。

たとえば確認待ちの列に、30分で終わる誤字チェックと、数日かかる仕様レビューが同居している場合、この列に単一の上限を課すのは無理があります。列を分けるか、カードの粒度を揃えるかのどちらかが必要です。

上限は列設計の健康診断として使えます。守れる上限が設定できる列は、定義がはっきりした列です。守れない列は、定義が曖昧な列です。

チームの規模で、並べ方の現実解は変わる

同じ考え方でも、人数によって落とし所は変わります。目安として整理しておきます。

チームの規模	列の数の目安	置くべき待ちの列	板の分け方
5人前後	4から5	確認待ちのみ	1枚で足りる
10人から20人	5から6	確認待ちと承認待ち	案件種別で2から3枚
30人以上	5から7	確認待ち、承認待ち、外部待ち	チーム単位で分割

5人前後のチーム

この規模では、列を増やすより減らすほうが効きます。全員がお互いの状況をだいたい把握しているので、板に求められるのは記憶の補助です。「未着手」「作業中」「確認待ち」「完了」の4列で足ります。

この規模で承認待ちの列まで作ると、そこに入るカードが週に数枚しかなく、空の列を眺めることになります。空の列は板の情報密度を下げるので、承認の待ちが実際に問題になってから足せば十分です。

上限についても、この規模なら厳密に運用する必要はありません。確認待ちだけ上限を決めておき、そこが溜まったら全員で確認に回る、という取り決めがあれば機能します。

10人から20人のチーム

この規模から、板が「全員が見る場所」になります。互いの状況を把握しきれなくなるので、板に書かれていない情報は共有されていないものとして扱う必要が出てきます。

承認待ちの列を独立させる価値が出るのもこの規模からです。承認する人が特定の1人か2人に集中し、その人の処理速度がチーム全体の速度を決めるようになります。承認待ちの列があれば、その人の負荷が数字で見えます。

板を複数枚に分けるかどうかも、この規模で判断が要ります。1枚の板に全員のカードを入れると、自分に関係のないカードが視界の大半を占めるようになります。案件の種類や顧客ごとに板を分け、とりまとめる人だけが全体を横断して見る、という形が現実的です。この場合、道具側が複数の板をまたいで検索や絞り込みができるかどうかが選定の分かれ目になるので、候補を並べて確認しておくと安全です。比較の一覧には主要なボード型ツールの違いが並べてあるので、板の分割を前提にした比較の出発点として使えます。

30人以上のチーム

この規模になると、1枚の板で全体を管理することは諦めたほうが早いです。チームや工程の単位で板を分け、それぞれの板が自分たちの列設計を持つ形になります。

そのうえで必要になるのが、板をまたいだ待ちの扱いです。ある板の「完了」が別の板の「未着手」になる関係が生まれ、その受け渡しの間にカードが行方不明になる事故が起きます。受け渡し用の列を両方の板に作り、名前を揃えておくと事故が減ります。

この規模では、外部の協力者が板に入る場面も増えます。誰にどこまで見せるかという設計が必要になるため、権限の考え方は道具を選ぶ段階で確認しておく項目です。データの扱いや権限の設計については安全性の考え方にまとめられている内容が、社内で説明する際の下敷きになります。

列の名前の付け方で、運用が続くかどうかが決まる

列設計というと構成の話に集中しがちですが、実際に運用が続くかどうかは名前で決まる部分が大きいです。

名前は「状態」で書き、「動作」で書かない

「レビューする」ではなく「レビュー待ち」、「承認する」ではなく「承認待ち」。動作で書くと、その列に入っているカードは「これからやること」なのか「やっている最中」なのかが曖昧になります。状態で書けば、カードが今どうなっているかだけを表せます。

英語と日本語の混在も、思っている以上に運用を鈍らせます。「To Do」「Doing」「レビュー待ち」「Done」のような並びは、チーム内に英語が得意でない人がいると、それだけで参加のハードルになります。画面が日本語で統一できる道具を選ぶことは、地味ですが定着率に効きます。

誰が動かすかを名前に含める

上級者向けの工夫として、列の名前に主語を入れる方法があります。「先方確認待ち」「上長承認待ち」「制作チーム確認待ち」のように書くと、そのカードのボールを誰が持っているかが列名だけで分かります。

この書き方の利点は、催促の宛先が板から読めることです。とりまとめる人が朝に板を眺めて、先方確認待ちが溜まっていれば先方へ、上長承認待ちが溜まっていれば上長へ、と行動が直結します。

欠点は、列が増えやすいことです。待ちの相手ごとに列を作ると、あっという間に画面幅を超えます。主語を入れるのは、待ちの相手が2種類か3種類に収まるチームまでにしておくのが無難です。

名前を変えるときの手順

列の名前や構成を変えるときに気を付けることがあります。予告なく変えると、チームは板を信用しなくなります。

変更する前に、なぜ変えるのかと、変えたあとにカードをどう動かすのかを文章にして共有します。そのうえで、変更は月曜の朝など区切りのタイミングで行い、変更後1週間はとりまとめる人が板を見て、間違った列に入っているカードを黙って直します。この期間に「間違っている」と指摘すると、指摘された人は板を触らなくなります。

列の変更は、そう頻繁にやるものではありません。目安として、四半期に1回を上限に考えておくと、チームが変更に疲れずに済みます。

道具を選ぶ段階で確かめておくこと

列設計の考え方が固まったら、その設計を実際に載せられる道具かどうかを確認する段階になります。板の見た目はどれも似ていますが、列にまつわる細かい仕様は道具によってかなり違います。

列の上限を道具側で設定できるか

仕掛かりの上限を運用ルールとして口約束にすると、忙しくなった週から守られなくなります。列ごとの上限を道具側に設定でき、超えたときに色や警告で分かる仕組みがあるかどうかは、確認しておく価値がある項目です。

この機能の有無は道具によって差があり、上位プランでのみ使える形になっていることもあります。付箋の枚数を数える運用で代替することもできますが、人が数えている限り、忙しい週には数えられなくなります。

板を横断して待ちを見られるか

板を複数枚に分けるチームでは、「全部の板の承認待ちを一覧で見たい」という要求が必ず出てきます。この横断ができるかどうかで、とりまとめる人の作業時間が変わります。

カード型のツールを長く使っているチームがつまずきやすい点でもあるので、乗り換えを検討している場合は現状の板の枚数と、横断で見たい条件を先に整理しておくと比較が速く終わります。Trelloとの比較やAsanaとの比較には、板の持ち方や画面の作りの違いが整理されているので、いまの使い方をそのまま移せるかを判断する材料になります。

列の並べ替えと、過去の記録が残るか

列を作り直したときに、過去のカードがどう扱われるかも確認しておく項目です。列を削除したらそこにあったカードの履歴も消える道具では、後から「あの時期は承認待ちが何日かかっていたか」を振り返れません。

自由度の高いデータベース型の道具を使っているチームでは、この点が逆に問題になることもあります。表示の形をいくらでも変えられる反面、設定した人以外には構造が分からなくなる現象が起きます。Notionとの比較には、自由に作れることと、チーム全員が同じ画面を理解できることの間にある緊張関係が整理されています。

費用の増え方が読めるか

列設計とは直接関係ないように見えて、実は影響するのが費用の仕組みです。機能ごとにプランが分かれている道具では、「上限の設定を使いたいから上位プランに上げてほしい」という社内交渉が発生します。交渉が通らなければ、設計した運用は載せられません。

料金の考え方として、機能で絞らず、区切るのは人数とボードの数だけという形を採っているツールもあります。この形だと、使いたい機能のために交渉する場面が消える代わりに、人数が増えると費用が素直に伸びます。どちらが向いているかはチームの増え方によるので、料金のような価格ページで数え方を確認しておくと見積もりがぶれません。プランや金額は変わるものなので、社内で共有する際は必ず参照した時点を添えてください。

なお、業務管理ツールの中には提供の終了が発表されているものもあります。Jootoとの比較のような比較ページでは、そうした提供状況にも触れられているので、移行先を検討している場合は先に目を通しておくと無駄が減ります。開発の課題管理と紐づけて運用しているチームであれば、Backlogとの比較やmonday.comとの比較で、板以外の機能をどこまで必要としているかを整理しておくと、選定の軸が定まります。

比較ページの構成から読み取れる、列設計でつまずく場所

各ツールの比較ページが何を論点にしているかを並べると、チームが列設計で実際に困る場所が浮かび上がります。比較の項目は、ツールを作る側が「ここで判断が分かれる」と考えている場所だからです。

論点は機能の多さではなく、運用の続けやすさに寄っている

比較の一覧に並ぶ項目を見ると、機能の数を競う形にはなっていません。人数の数え方、外部の協力者をどう招くか、日本語で使えるか、既存のデータをどう持ち込むか、といった運用側の論点が中心です。

これは列設計の話と地続きです。どれだけ良い列を設計しても、チームの半分が画面を読めなければ運用は続きません。外部の協力者を招くたびに費用が跳ね上がるなら、確認待ちの列は社内だけの運用になり、外部との待ちは板の外に残ります。列設計が機能するかどうかは、板の外側の条件でかなりの部分が決まります。

できないことが先に書かれている意味

できることのページには、できることと同じ場所に、できないことも書かれています。ソースコードのリポジトリ機能は持たない、自動化や外部サービス連携の豊富さでは勝負しない、画面は日本語のみ、自動で取り込めるのは1つのサービスからだけ、という内容です。

とりまとめる立場から見ると、この情報は機能一覧より役に立ちます。列を自動で動かす仕組みを組みたいチームや、開発の履歴と紐づけて管理したいチームは、その時点で候補から外せるからです。検討にかけられる時間は限られているので、外せる条件が早く分かるほど選定は速く終わります。

移行についても同じで、自動で取り込めるのが1つのサービスからだけであることがTrelloからの移行に明記されています。他のツールから移る場合は手作業が発生するという前提で計画を立てることになり、その手間を先に見積もれます。列を作り直す機会としては、移行のタイミングがいちばん抵抗が少ないので、手作業になるならそこで列設計も一緒に見直してしまうのが効率的です。

疑問の集まる場所を先に読んでおく

よくある質問のようなページには、実際に検討している人がどこで手を止めるかが集まっています。人数の数え方、外部の人を招いたときの扱い、データを持ち出せるか、といった項目です。

列設計の観点で言えば、「データを持ち出せるか」は特に確認しておく価値があります。列ごとの滞留日数を自分たちで集計したいと考えたとき、データを取り出せなければ手作業で数えるしかありません。振り返りを続ける気があるチームほど、この項目を先に見ておくべきです。

結局のところ、列設計で変わるのは判断の速さ

列を1つ増やしたからといって、仕事の量は減りません。減るのは「なぜ止まっているのか」を聞いて回る時間と、止まっていることに気づくまでの時間です。

完了の手前に確認待ちと承認待ちを置いたチームでは、朝に板を開いた時点で、今日どこへ働きかけるべきかが分かります。確認待ちが厚ければ確認する人へ、承認待ちが厚ければ承認する人へ。この判断が板の上で完結するようになると、とりまとめる立場の人の仕事は、状況を集めることから、集まった状況に手を打つことへ移ります。

列設計とは、作業の順番を決めることではありません。チームが自分たちの詰まりを自分で見つけられるように、待ちに名前を与える作業です。完了の手前に何を置くか。そこだけを決め直せば、板は今日から違う情報を返してきます。

Q1. カンバンの列はいくつが適切ですか？

画面を横にスクロールせずに全体が見える範囲、目安として5つから7つに収めてください。5人前後のチームなら「未着手」「作業中」「確認待ち」「完了」の4列で足ります。それ以上並べたくなったら、列を増やすのではなく板を分ける判断のほうが適切なことが多いです。横スクロールが必要な板は、一目で全体を把握するという最大の利点を失います。

Q2. 確認待ちと承認待ちは分けたほうがよいですか？

待ち時間の桁が違うなら分けてください。社内レビューは数日、顧客や上長の承認は2週間かかることもあり、同じ列に混ぜると滞留の原因が読めなくなります。10人以上のチームで、承認する人が1人か2人に集中しているなら分ける価値があります。5人前後で承認の待ちが週に数枚しか出ないうちは、確認待ちだけで十分です。

Q3. 列ごとの上限は何枚に設定すればよいですか？

最初はその列を担当する人数の1.5倍を目安にしてください。4人なら6枚です。人数ぴったりだと確認待ちで手が空いた人が動けなくなり、余裕を持たせすぎると上限が機能しません。確認待ちや承認待ちは自分たちの手が止まっている時間なので、5枚程度と厳しめに設定し、超えたら催促する合図として使うと運用に乗ります。

Q4. 途中で列の構成を変えても大丈夫ですか？

変えて構いませんが、予告なしに変えるとチームが板を信用しなくなります。なぜ変えるのかとカードをどう動かすのかを先に文章で共有し、月曜の朝など区切りで切り替えてください。切り替え後1週間は、間違った列に入っているカードをとりまとめ役が黙って直します。指摘すると触らなくなるためです。変更の頻度は四半期に1回を上限に考えると疲れずに済みます。