「タスクの見える化」が逆効果に？ADHDエンジニアのための最小限のカンバンボード運用術

普段からカンバンでタスク管理をしているエンジニアの方でも、ある時点でボードを見ただけで息が詰まることはありませんか。私はADHD傾向があり、かつて完璧に「見える化」されたボードを作ろうとして逆に手が止まった経験があります。細かいカラム、色分け、タグ、期限の洪水――最初は安心感があったのに、数日で判断疲れと注意散漫に襲われ、結局どれも動かなくなる。この記事では、そんな失敗から学んだ「最小限のカンバン」運用術を、ADHDの特性に寄り添いながら具体的に紹介します。

見える化が逆効果になる理由 — ADHD特性と実務のズレ
ADHDエンジニア向け：最小限カンバンの原則
実際のボード設計と運用手順（具体例付き）
日常ルーチンと注意トリガーの設計
判断基準とトレードオフ — なぜ「最小限」が効くのか
実践例：小さなプロジェクトでの適用（エンジニア事例）
トラブルシューティング：よくある落とし穴と対策
結論と次のアクション
よくある質問

見える化が逆効果になる理由 — ADHD特性と実務のズレ

多くのチームは「見える化 = よいこと」と教えられています。しかし、ADHDの特性と合わせると見える化が負担になりやすいです。具体的には次の点が問題になります。

視覚情報が多すぎると、感覚過敏で疲れることがあります。選択肢が増えると決断が遅くなる（決定疲労）。タスク数の増加や進捗の色分けが「やることリストの増大感」を生み、先送りを加速させます。急にハマるハイパーフォーカスの波が来ても、ボードが複雑だとどこに着手してよいかわからず無駄な時間が増えます。

例えば私の場合、細かなステータス(設計、実装、コードレビュー、QA、リリース準備など)を列に分けたボードを作ったところ、どの細分化が正しいのか迷い、1つのチケットで何度もカラムを移動してしまい、本来の進捗が見えにくくなりました。結果、日々の開発速度が落ち、ストレスだけが溜まりました。

次節では、そうした問題を避けるための原則を示します。

ADHDエンジニア向け：最小限カンバンの原則

ここでは運用をシンプルに保つための基本原則を説明します。多すぎる要素を削ぎ落とし、判断を少なくすることが目的です。

以下に重要な原則を示します。各項目は、なぜ必要かを簡潔に説明します。

列は最小限にする（ToDo / Doing / Done）
タスクは「次に何をするか」が明確な単位にする
色分けやラベルは必要最小限にする（緊急度だけなど）
WIP（同時進行数）に上限を設ける
デイリーチェックは短時間で終わるよう仕組み化する

上のリストはシンプルさのための最小限ルールです。列を減らすことで視覚的負荷を下げ、次のアクションが明確なタスクに分けることで意思決定を楽にします。色やラベルを限定することで注意の散乱を防ぎ、WIP上限が集中力の切り替えを抑えます。短い日次チェックは習慣化しやすく、怠け感を減らします。

実際の現場で、私は「ToDo / Doing / Blocked / Done」にして、Blockedは本当に外部依存かどうかを判断するためだけに使いました。その結果、ボードの見た目が落ち着き、作業に入りやすくなりました。

実際のボード設計と運用手順（具体例付き）

ここからは具体的なボード設計案と運用手順を示します。エンジニアとしてすぐ試せる内容に絞りました。

まずはボードの構成です。目的は「迷わず次の作業に入れること」です。

カラムは次のようにします。説明の後に、なぜこの構成が有効かを書きます。

Backlog（アイデア／未精査）
ToDo（着手準備完了）
Doing（現在作業中、WIP上限あり）
Blocked（外部待ち、短期ルールあり）
Done（完了）

Backlogは雑多なアイデアをためる場所です。ToDoは「今すぐ着手できる」状態にしたタスクのみ置きます。Doingは厳格にWIP上限を設け、並行作業を減らします。Blockedは「本当に待つべき」場合のみに限定し、待つ理由と担当者を書いておきます。

実例：リファクタリング案件が発生したとき、以前はBacklogから直接Doingに移していましたが、途中で仕様確認や見積もりが必要になり止まりました。現在はまずToDoで「必要な確認事項」タスクを作り、それが完了したらDoingへ移動するルールにしました。これによりDoingに入るタスクは必ず手が付けられる状態で、ハイパーフォーカス時に即座に深掘りできます。

毎日の運用は次のように短く回します。朝は3分でDoingを確認、終了時に5分でDoneの精査を行います。これだけで判断疲労が劇的に減りました。

日常ルーチンと注意トリガーの設計

良いボードでも使い方を誤ると意味がありません。ここでは日常の習慣設計を説明します。目的は「迷わずルーチン化させ、立ち止まらないこと」です。

まず、毎日の始業時に行うことを決めます。朝のルーチンではDoingのカードを2つまでに絞ります。これはWIP上限の具体化で、脳の切り替え負担を下げます。次に、ポモドーロや短いタイマーを使って短時間で区切ると良いです。特にADHDでは短い締め切りが集中を誘発します。

次のリストはルーチンでチェックすべき項目を示します。リストの前に目的を説明します：朝と終業時にこれらを確認し、1日の成功確率を上げます。

Doingのカード数が上限を超えていないか
ToDoの先頭タスクが「具体的な次アクション」になっているか
Blockedの理由が明確で、期限や担当が書かれているか

上記を毎朝30秒で確認するだけで、不要な迷いが減ります。私の場合、ノイズになるラベルを消してから、朝の確認が習慣化され、午後の中だるみが大幅に減りました。

判断基準とトレードオフ — なぜ「最小限」が効くのか

ここではなぜ上の方法がADHDに効くのか、判断基準とトレードオフを説明します。ポイントは「合理的な単純化」と「失敗を前提にした調整」です。

合理的な単純化は、意思決定の数を減らすことで脳の負荷を下げます。一方で単純化しすぎるとチームの情報共有や期待値の齟齬が生じます。だからこそ、どこで妥協するかを明確にする必要があります。

判断基準の例を示します。ここでの目的は、どの項目を省略せずに残すか判断するための尺度です。

その情報が「次の行動」を決めるのに不可欠か
情報が増えることで判断時間がどれだけ増えるか（コスト）
情報が欠けることで起きるリスク（コミュニケーションコスト）

これらを天秤にかけて、例えば「担当者」と「期限」は残し、「細かいタグ」は後回しにする、といった判断ができます。私のチームでは、レビュー待ちのタスクには必ず「誰にレビュー依頼しているか」を書くルールだけ残し、優先度の色分けは廃止しました。優先度は日次ミーティングで口頭で補足する運用に変え、視覚負荷を減らしました。

実践例：小さなプロジェクトでの適用（エンジニア事例）

実際に1週間スプリントの小プロジェクトでやってみた記録を共有します。読者が真似しやすいように具体的に書きます。

プロジェクトは「APIのレスポンス改善（3人チーム、1週間）」です。初めにBacklogに全アイデアを放り込み、朝の時点でToDoに「計測方法を確定」「ボトルネック1の修正」「テストケース作成」の3タスクを置きました。Doingは同時に2件までに設定し、私（実装担当）は「ボトルネック1の修正」をDoingに入れてポモドーロで区切りながら進めました。

結果、週末までに主な改善をデプロイできました。なぜうまくいったかというと、Doingに入る前にタスクを「手を動かせる状態」にしておいたこと、WIPを制限して分散を防いだこと、そして日々の短い確認でBlockedをすぐ拾えたことです。

この実践例は小規模プロジェクト向けですが、同じ原則は大きなプロジェクトにも応用できます。ポイントは「まずシンプルに始め、必要なら徐々に情報を足す」ことです。

トラブルシューティング：よくある落とし穴と対策

運用していると、いくつかの典型的な問題に出くわします。ここでは発生しやすい問題と簡単な対策を示します。

まず、Doingがいつまでも減らない場合は、タスクが大きすぎる可能性があります。その場合はタスクを分解して「次の小さなアクション」を必ず作ります。次に、Blockedが溜まる場合は、Blockedの扱いを見直して「担当の責任」と「期限」を明確にします。最後に、ボードが再び複雑化してきたら、一度リセットして不要なラベルを削除するのが効果的です。

実例：ある時、レビュー待ちカードが10件溜まったとき、私たちはBlockedルールを見直し「レビュー担当が48時間以内にコメントしない場合はオーナーがフォローする」という短いルールを導入しました。これで滞留が解消しました。

結論と次のアクション

ここまで述べたことをまとめると、ADHD傾向のあるエンジニアにとっての最善策は「見える化を最小限に抑え、判断を減らすこと」です。列は少なく、タスクは必ず次のアクションを含み、WIPを制限して短い日次チェックをルーチン化する。そうすることで、ハイパーフォーカスを活かしつつ衝動や感覚過多に揺さぶられにくくなります。

今日から試せる具体的な次の一歩を3つだけ挙げます（短く実行できるものを優先しています）：