本書は個人タスク管理を扱った本ですが、残る二つ――プロジェクトタスク管理とパートナータスク管理についてかんたんに扱っておきます。

本章ではプロジェクトタスク管理の本質を端的に整理します。PMBOK のような体系や各種プロジェクト管理ツールの解説、あるいは即効性のあるテクニックの紹介等はしません。あくまでも個人タスク管理を体系化しようとする筆者の目線で整理したものです。読者なりに気付きやヒントを得てもらうことを期待します。

プロジェクトタスク管理の 3A

プロジェクトタスク管理の本質は 3A で表せると思います。

英語	キーワード	解説
Assign	アサイン	人にタスクを割り当てること
Adjust	調整	タスクの属性値を変えること
Alternate	全体と詳細	タスク全体の俯瞰と特定タスクの注視を行き来すること

Assign/アサイン

人にタスクを割り当てることです。

プロジェクトタスク管理には複数人のメンバーが存在するため、誰にどのタスクを割り当てるかという営みが必ず発生します。割り当てとは約束であり、タスクTをAさんに割り当てるとは、Aさんに「あなたはタスクTを責任を持ってちゃんと遂行してね」と課していることになります。なぜそんなことをするかというと、そうしないと進まないからですね。人は忘迷怠する生き物ですし、複数人ですと遠慮や手抜きも発生します（たとえば心理学的には社会的手抜きと呼ばれる現象が起きます）。意図的に管理をしなければままならないのです。

一方で、近年ではマネジメントレスの潮流も見られます。「マネージャーは要らない」「中間管理職を廃止しました」のような取り組みを聞いたことがある人もいるでしょう。要はタスクをこなせさえすればいいので、誰に管理されずとも自律的に行動できるならそれでいいわけです。といっても言葉で言うほどかんたんではなく、アサインという本質はすでに会社のルールやプロセス、仕事そのもの（たとえば管理職はまさに管理でご飯を食べています）、ときには契約にさえ入り込んでいます。そもそも大部分の人は労働者として管理されることに慣れきっていますし、自律的に進めるほど仕事にモチベーションもありません。まだまだマイノリティのやり方と言えるでしょうし、ここ数十年はマジョリティになることもないと思います。

マネジメントレスであってもタスク管理ツールは使います。後述の Alternate にも絡みますが、状況を知ってもらうためには結局ツールへの入力が必要だからです。そうしないと、いちいち本人に聞かないといけなくなります。仕事に集中してるのに聞かれたら集中が削がれます（割り込みといいます）し、定期的にヒアリングの場を設けるのはそれこそ管理的ですよね。これは見過ごされがちなことですが、 打ち合わせもタスクの一つ であり、打ち合わせをしている時点でアサインが発生しています。打ち合わせの多いマネジメントレスは、なんちゃってマネジメントレスでしかありません。

現在ではそこ（ツールへの入力）さえも放棄した潮流も出ています。ティール組織と呼ばれる組織のあり方です。ティール組織では無駄な制度やプロセスが省かれ、従業員の裁量が強く、心理的安全性も高くて、超高頻度なコミュニケーションを行えることが特徴です（と明言はされていませんが筆者はそう捉えています）。「何かあれば聞けばいい」とのメンタルモデルを持つ人は多いと思いますが、色んな制約があったりビジーだったりで中々そうもいかないでしょう。ティールならそれができるのです、というよりそうするための組織としてデザインされています。事例こそ色々ありますが、本質は驚くほど似通っていると感じます。というと難しそうですが、要は創業者数人で立ち上げたばかりのベンチャー企業のようなものです。事業のことだけに専念できて、変な制約や邪魔もなくて、気兼ねなくいつでも相談して、みたいなあの感じです。難しいのは、その感じをスケールさせる――組織規模が大きくなっても維持できるようにするところです。

Adjust/調整

ここでは 調整とはタスクの属性値を変えること です。

属性とはタスクが持つ特徴のことで、たとえば以下があります。

• 名前
• 状態（未着手/着手中/完了/中止など）
• 担当者
• 締切
• 開始日
• 優先度（高/中/低、1-5の5段階など）
• 費やした時間（工数と呼ばれることが多い）
• コメント

システマチックな言い方になりますが、プロジェクトタスク管理とはタスクの属性値を変える営みともいえます。以下にタスク T の属性値を変えていく例を示します。例では一タスクですが、実際は多数あるいは無数に存在します。

経過	イベント	.	名前	担当者	状態	優先度	締切	コメント
1	タスクTを新規につくる	.	T
2	Aさんを割り当てる	.	T	A
3	着手した	.	T	A	着手中
4	緊急ではないのでその旨	.	T	A	着手中			期限ないのでペンディング
5	状況変わって緊急に	.	T	A	着手中	高	2024/05/09	期限ないのでペンディング

このように状況に応じてタスクの属性値が変わっていく――と楽なのですが、タスクが勝手に変わることはありません。私達が能動的に変えるのです。ツールを使わない場合もありますが、その場合も頭の中で同じようなことをしています。しかし頭の中だと信用できませんし、引き出すのにも会話が要りますし、人によって何のタスクとどんな属性値を持っているかも違うので争いも起きがちです。調整の結果を記録することは必須であり、記録にはツールが要ります。つまりプロジェクトタスク管理ではツールが必須です。

ここで厄介なのが 調整が頻発する ことです。プロジェクトにイレギュラーはつきものですし、単に慌ただしい場合でも調整の量は増えます。一度ツールにタスクを入れ終えたから、あとは属性を変えればいいだけだ――ともなりません。新しいタスクが増えたり、既存のタスクが消えたりといったことは平気で起こります。これらをすべてをツールに反映できなければ、誰かの頭の中だけに留まってしまうことになります。そうなると前述したとおり、引き出すための会話つまりは会議が必要になって、でも人によって抱えているものが違うから齟齬が起きて、と時間と労力がみるみる消費されていきます。プロジェクトは大変になりがちですが、その主因は単にツールに反映ができていないことによる秩序の崩壊です。

この「調整の頻発によるツール反映の漏れ」に対抗する手段は、今のところ二つです。一つは単純にツールへの反映を徹底されることですが、通常そこまでのツールやスキルは備わっていないため現実的ではありません。もう一つは反応的状況に溺れることです。 反応的状況（Reactive Situation） とは、その時その時で起きたことに即座に反応する形で生き延びていくような状況を指します。慌ただしい世界は基本的にこれになります。反応的状況では調整（とツールへの反映）は追いつかず、ただただ目の前を見て瞬発的に反応し続けることしかできません。つまりタスク管理が通用しません。逆をいうと、タスク管理という面倒くさいことをしなくて済むとも言えます。それゆえ反応的状況はよく好まれます。プロジェクトが無駄に忙しくなりがちなのもそのためです。

Alternate/俯瞰と注視

タスク全体の俯瞰と、特定タスクへの注視を行き来することです。

Alternate は「交互に行き来する」の意です（※1）。木と森を見る、ボトムアップとトップダウン、全部と細部など似た言葉はたくさんあります。改めて言われるまでもない、現代人ならおそらく誰もが触れる考え方だと思いますが、プロジェクトタスク管理にも登場します。

• ※
  • 1 交互に、とあるのでイーブン（50% 50%）で行き来しなきゃいけないのかと思うかもしれませんが、そんなことはありません。20 80でもいいですし、5 95でもいいです。最適なバランスは状況次第ですし、人次第でもあるでしょう。大事なのはとにかく全体と詳細の両方を見ることです。

俯瞰

仕事には多数、ひょっとすると無数のタスクが存在し、これらは有機的に絡み合っています。たいていは階層的に整理されがちですが、人間関係や地理的経路のようにネットワーク状になっていることもあります。そもそもタスクは最初からすべて見えているとは限らず、何らかの目的や目標があって、そこから分解されていくものです。つまり重要なのはタスクというパーツ各々というより、それらが織りなす全体です。目標には届くのか、あとどれくらいで届くのか。状況はどうなっているのか。ヤバそうなところはないか――そういった大局的な目線は、タスク単体よりも、タスク達を取り巻く関係全体を眺めないと見えてきません。

では 眺めるためにどうするかというと、何とかしてタスクを並べる のです。リストにして並べたり（階層的に段々にして見せることも含む）、表に埋め込んだりすることもあれば、カンバンやボードといった形でカード状のものを配置したりします。個人の場合ですとデスクやデスクトップなどで適当に散らすこともできますが、プロジェクトタスク管理は複数人が見るものなので、並べ方は整然となるのが普通です。アナログな職場で我流に管理している場合や、医療現場におけるトリアージなど空間上の何か（この場合は治療対象という「人」）をタスクとみなす場合はそうでもないですが、あまり馴染みはないでしょう。ともかく、何とかしてタスクを並べて、俯瞰できるようにするわけです。

デジタルツールの場合、さらに俯瞰しやすくする仕組みがあります。特に「タスクが全部で 1000 個あります」となると眺めるだけでも一苦労ですので、絞り込む必要があります。ここで使うのがフィルタリングとソートです。 フィルタリング は指定条件に当てはまるものだけを表示するもので、「優先度が高いタスクのみ表示」とか「完了したタスクは非表示」とかいったことができます。「指定したキーワードにヒットしたものを表示」など「検索」は特に有名です。ソート は並び替え操作のことで、指定した順に並び替えます。昇順や降順は有名で、名前や日付でソートした経験は割と誰でもあるのではないでしょうか。

この二つを組み合わせると、相当柔軟に絞り込むことができます。一方で、絞り込むためにはその観点をちゃんと理解し、かつタスク側にも入力しておく必要があり、現実的には形骸化することも多いです。たとえば優先度が高いタスクのみフィルタリングしたい場合、すべてのタスクの優先度属性をちゃんと記入しておく必要があります。優先度が高いのに記入が漏れていたタスクは表示されません。こういうヌケモレが多いと、フィルタリング結果は信用できなくて形骸化します。もちろん、最初は上手くいっていても、忙しくなってきたり、単に面倒になってきたり、あるいはサボる人が出てきて他の人もそこに影響されて次第にサボり始めて、など色んな原因でもかんたんに形骸化していきます。結局、メンバーを会議で集めてその場でヒアリング、などという原始的なやり方になってしまうのは、あるあるではないでしょうか。

2024 年現在、生成 AI は盛り上がっていますので、そろそろ AI に尋ねるだけで上手い感じに並べてくれるツールが出てくると思います。ただ技術的に精度面で不安がありますので、キラーと呼べるほどの存在にはまだまだ至らないでしょう。たとえば不要な情報が並ぶことがある、ならまだマシですが、必要な情報が並ばないことがある、は怖くて容認できません。

注視

次に注視についてですが、これは特定のタスクを注視するということです。

タスク管理ツール的に言えば、あるタスクが表現されたページを開くことに相当します。このページにはタスクの属性値が書かれており、誰でもタスクの状況を知ることができたり、何なら書き足したりすることができます。近年ではコメントやメンションなどチャットの機能を備えたものもよく見られ、ある程度のコミュニケーションも担えてしまいます。

多機能に目が眩むこともありますが、 注視の本質はいつでも関係者なら誰でも自分の好きなタイミングで（そのタスクだけに）注目できること です。なぜそんなことがしたいかというと、状況を見たいから、または状況に介入したいからです。全体を俯瞰してもあたりをつけられるだけで、じゃあ具体的にどのタスクがどこで詰まっているのかといったことは、そのタスクを見ないとわかりません。そうでなくとも、仕事では色んな人が色んな都合で動いていますから、各自のペースで見れた方が良いに決まっています。場合によっては介入が必要なこともあるでしょう。このようなことを実現するためには、タスクごとにページを独立させ、いつでも誰でも見れるようにすればよいわけです。

これはデジタルツール特有の機能であり、アナログツールだとこうはいきません。あるいは最低でも 1 タスク 1 紙片のような形で場所を取ることになるので、その場所に本人が出向く必要があります（異世界ギルドのクエスト掲示板をイメージしてもらればいいと思います）。またデジタルツールであっても、Web サービスレベルのものでなければこうはなりません。Excel による表や票で管理されたものは、俯瞰こそできますが、注視はできません。

ここまでを踏まえると、各メンバーが自分のペースで自律的に働けるかどうかは、注視の機能がどれだけ充実しているかにかかっている と言えます。Slack や Teams などビジネスチャットはすっかり有名となりましたが、なぜこれらのツールでリモートワークが捗るかというと、これらが注視機能的に優秀だからです。メッセージをやり取りできて、リアクションできて、ファイルを添付できて、必要ならメンションで通知も飛ばせて、しかもかんたんに使えて――とかなり優秀なのです。チャットはチャットであり、タスク管理ツールとして見るのは無理に聞こえますが、そうでもありません。ビジネスチャットには部屋の単位（ワークスペースやチーム → チャンネルやチャネル → スレッド）があり、これらがまさにページに相当します。1ページ1タスクというより1ページ1組織あるいは1ページ1目的になりがちですが、組織や目的はタスクの集合ということもできます。つまり「大きなタスクごとにページをつくることができ」「メッセージのやりとりという馴染みのあるやり方を重視したコンセプトの」「注視機能的に優秀なツール」ということもできるのです。もっとも、実際にそれでタスク管理ができているかというと、そんなことはなくて結局リモート会議地獄になるのですが。

この注視機能の洗練に注目したのが、次の章で述べるパートナータスク管理です。タスク管理とメッセージのやりとりを上手く融合しており、それでありながらビジネスではなく私生活としてかんたんに使えるというバランスも確保していて、上手いなと思います。この発想をもっと膨らませれば、プロジェクトタスク管理ももう一皮くらい剥けるのではないかなと筆者は考えています。その片鱗はある程度見えていて、後の章で紹介します（高度なタスク管理）。

Alternate モデル

プロジェクトタスク管理において俯瞰と注視がどのように実現されているか、についてはいくつかの段階があります。これを Alternate モデル と呼びます。

概略を示す前に用語を定義してます。俯瞰的な目線を マクロ（Macro） と呼び、注視的な目線を ミクロ（Micro） と呼ばせてください。

概略

以下のように 4 つの段階があります。

段階	名前	実現範囲	例
1	N-Micro	注視のみ	タスクが各自の脳内にのみ存在する
2	1-Macro	俯瞰のみ	メンバー全員が見る何とか票や何とかボード
3	1-Macro N-Micro	俯瞰と注視	固定的なビューを持つタスク管理ツール
4	N-Macro N-Micro	俯瞰と注視	ビューをカスタマイズできるタスク管理ツール

N-Micro

注視的な目線のみが存在する段階です。

最も単純な例は「各自の頭の中にのみタスクが存在する」状態です。ビジネスではなく、私生活や趣味の文脈だと基本的にはこれでしょう。いちいちタスク管理するのが面倒くさいし、それでも許される、かつ何とかなるからです。またビジネスであっても、少人数の場合はこれで通用することがあります。上手くやればティール組織のように「その都度コミュニケーションするから大丈夫」で済む世界もつくれますが、それができれば苦労はしないでしょうし、実際ティールのメンバーは精鋭揃いです（あるいは組織運用とメンバー教育にかなりの力とお金を入れているようです）。

この段階は原始的――テクノロジーや方法論が進んでおらず人手的で、場当たり的で、閉鎖的で、変更にも強くないといった体質の表れでもあり、労働環境の原始性との相関は高いと思います。特に就活や転職時だと「タスク管理はどのように行っていますか？」がキラークエスチョンになるでしょう。答えられなかったり、そもそもタスク管理を知らなかったりする場合は、おそらく原始的です。といっても、タスク管理は知らない方がマジョリティですから、気にしない人も多いと思います。肌感覚で言えば、タスク管理を使っている人の割合は「パソコンが使えて、チャットツールも使えて、必要に応じてソフトウェアをインストールしたり設定をカスタマイズしたりまでできる人」よりも少ないです。

他の例としては、タスクの進捗が物理的（あるいは画面越しに）見えるという形の注視もあります。作業所や現場など物理的に色々つくる場面だと、誰が何をどこまでつくっているかはある程度見えると思います。デジタルでも同じことで、たとえば共有フォルダに皆でファイルをアップロードしたり仕上げたりする場合、そこを見れば状況がわかります。といっても、これらは間接的な状況確認にすぎず、結局各自の脳内で各自がタスクを管理していることからは逃れられません。A さんは「もうできた」と言っているが、B さんは「いやそれはまだでしょ」と言っている、などが起きます。A さんの脳内ではタスクは完了しているが、B さんの脳内ではそうではないのですね。

N-Micro は、いわばメンバーの数（脳の数）だけ原本が存在するようなものです。俯瞰できないのはもちろん、タスク各々の状況を知ることさえ苦労します。

1-Macro

俯瞰的な目線のみが存在する段階です。

最も単純な例は「管理者の頭の中でのみ俯瞰が組み立てられている」状態です。これはリモートワークを行えるような大企業でもよく見られるものほどありふれたもので、管理者はメンバーと高頻度にコミュニケーションをして俯瞰を組み立てます。メンバーは、管理者と話さない限りは引き出せません。あるいはメンバー自身でも情報収集をすれば組み立てることはできますが、管理者ほど集められないのでたかが知れています。これは明らかに管理者が楽をするためだけの原始的な形態であり、管理者がボトルネックになります。管理者が優秀だとカバーできますが、拘束や束縛は厳しくなります。上下関係も激しくなりがちです。

このボトルネックを解消するために、何らかの俯瞰装置を用意するやり方もよく使われます。WBS やガントチャートといった言葉を聞いたことがあるでしょう。そうでなくとも、何々管理票とかボードとかいった形でタスクを見える化する取り組みは（タスク管理を知らなくても）自然に発生します。これだけでもプロジェクトタスク管理はまかなえますが、現代では不十分なことが多いです。というのも、このような俯瞰装置には「よりすぐりのタスク」だけが載るからです。よりすぐり以外のタスク（こぼれたタスク）は無視されます。が、現実は、特にデスクワークを伴う場合はそんな単純ではなく、仕事にも人にも色々あるわけで、こぼれたタスクも多いわけです。多いのに管理されない――そこでひずみが生じて、どこかで誰かが（ひどいと全員が）無茶をすることになります。管理者としても、何度も管理対象を変えるのは面倒くさいですし、自分が直接動くわけではないので痛くないですし、そもそも仕事の形態としてよりすぐりのタスクをもう変更できない（契約されていたりその内容で予算が降りていたり）状態になっていたり、など色々あるので融通が利きません。

総じて、トップダウンの強さと固定的な視野からは逃れられません。

1-Macro N-Micro

俯瞰と注視の双方をサポートした段階で、固定的なビューを持つタスク管理ツールを使っています。

タスクはツールに登録され、日々状況が更新されていきます。それらのデータから俯瞰的な見栄え（ビュー）をつくることもでき、このビューを見ることで管理者（必要ならメンバーも）は状況を把握できます。タスクごとのページもあるので、細かいフォローも可能です。また記録も残るので、記憶によるいいかげんな判断もなくせます。近年では DX――デジタルトランスフォーメーションが叫ばれていますが、DX も結局はデータ化とその俯瞰です。データドリブンという言葉も使われたりもします。プロジェクトタスク管理の、この第三段階は、いわばタスク管理に関する DX と言えます。

この段階ではツールの導入により「タスクが外に出て」「誰でも扱えるようになる」ので、管理の独占と不透明性を軽減できます。タスクという情報を共通言語にしてコミュニケーションが取れる と言い換えてもいいでしょう。メンバー同士で議論することもできます。とはいえ意思決定者がいた方が何かと便利ですから、管理者がその役割を担います。メンバー達でできるなら管理者自体が要りなくなります。

プロジェクトタスク管理におけるキャズム

第三段階とも呼べる 1-Macro N-Micro に至るには、非常に高いハードルがあります。これを プロジェクトタスク管理におけるキャズム と呼ばせてください。キャズムとは深い溝、の意味です。有名なのはイノベーター理論におけるもので、新製品を（少数のコアなファンを越えて）マジョリティに届けるのには非常に高いハードルがあるとしています。

1-Macro N-Micro もまさにそうで、タスク管理ツールの導入やメンバーのスキルはもちろん、形骸化させないよう日頃から入力しこれを使ってコミュニケーションを行うところまでやらねばなりません。これがとても難しいのです。「全員に同じデジタルツールを使わせる」「かつ常用させる」というと、いかに難しいかがイメージできるのではないでしょうか。

実際、この第三段階のツールは、主にクリエイティブな仕事をする人や組織で使われています。クリエイターは仕事柄、ツールの学習機会が多い生き物ですし、自分のペースで働くことの重要性もよく知っている（ペースを守るための努力に余念がない）からです。逆をいうと、クリエイターではない一般人が軽々と越えられるものではないのですね。

一般人の集団でキャズムを超えるには、長い時間をかけて啓蒙し続けなければなりません。ツールの費用や啓蒙役の人件費もしっかり確保する必要があります。つまりは経営者（あるいは大企業なら財布を握る役割や権限の者）の協力が必要不可欠です。再び DX の話になりますが、まさに DX もそうで、実質経営者次第と言えます。このことは IPA の DX 白書 2021 や マッキンゼーの緊急提言 でも強調されています。

プロジェクトタスク管理の場合、経営者ほど大きなスケールで見る必要はありませんが、タスク管理が適用される組織単位（チームやプロジェクト）内という範囲で同様の力学が働きます。マネージャーなのか、部長なのか、その他のキーマンなのかは状況次第ですが、その組織単位の経営者に相当する誰かの協力と投資が必要なのです。

N-Macro N-Micro

俯瞰と注視の双方をサポートした段階で、ビューをカスタマイズできるタスク管理ツールまたは仕組みを使っています。

第三段階の 1-Macro N-Micro では、ビューは固定的でした。ツールがサポートするビューしか使えなかったのです。「こういう観点で見たいのに……」といった要望があっても叶いません。叶わないので別のツールを探すか、それができなければ形骸化――結局打ち合わせをして人に聞いたりといったことになってしまいます。ツールの調査、移行、定着も大変で、そもそも探して済むのなら苦労はしません。形骸化はいつでもどこでも口を開けて、私達を待っています。

このような悲劇を防ぐためには、ツール側にビューをカスタマイズする機能があればいいのです。たとえば monday.com の Work Management では、ウィジェットという形でビューをつくれます。タスクの属性もカスタマイズできるので自由自在です。優先度を 1～5 の五段階にしたり、優先度とは別に緊急属性をつくって、この値が 1 だったら問答無用でそれから着手しろ、という運用をつくることもできます。ビューとしても、たとえば緊急属性を一覧化するウィジェットをつくればいいでしょう（普段は何も表示されないが、表示された場合は今すぐそれに取り掛かるのだとわかる）。これは一例ですが、このように各チーム各現場に合ったビューをつくることで融通を利かせられます。

API

カスタマイズ方法は一つだけではありません。もう一つ、API を用いたやり方もあります。

API とは「プログラムから呼び出されることを想定した、各機能各データへのアクセスの口」のことで、現代的なデジタルツールは内部的に API を組み合わせています。いわば API はパーツで、パーツを組み合わせて処理を実現するわけですね。このパーツは通常、外には公開されませんが、現代ではこれを公開する潮流があります。公開すれば、他の利用者に使ってもらえるからです。思わぬ使い方を実現してくれるかもしれませんし、そうでなくとも「最悪 API で使って何とかしてね」と逃げることもできます。

インターネットもそうですが、なるべく情報や機能を公開して色んな人に使ってもらうという思想があります。一見すると、無料で公開していてビジネス的に筋が悪そうに見えますが、これで広まれば結果的にファンが増えたり存在感が増したりしてプラスになります。何より目先の利益にとらわれず、幅広く公開して人類に貢献するという意識は、現代ではリテラシーになりつつあるかもしれません。資本主義と相反するように見えますが、消費者もそういう持続的な目線を持ちつつあります（いわゆるサステナビリティですね。この言葉は環境破壊の抑制という文脈が強いですが）。そういう目線を持ってない企業は相手にしない、が起こり得ますし、エンジニアの方ならすでにツール選定において API の有無を見ているのではないでしょうか。

と、話を広げすぎたので戻しますが、要はタスク管理ツールも API を備えていることがあります。API を使ったプログラムを自分でつくって、お望みのデータを取得し、お望みの見せ方で見せればいいのです。無論これには専門的な開発能力が必要ですし、つくるのにも時間がかかります。ただ、その気になればカスタマイズできるよ、というわけです。

ビューの種類

タスクを俯瞰するビューには様々なあり方があります。ツールごとに異なりますし、前述の第四段階ではビュー自体をカスタマイズできるのでした。しかしながら、大まかな種類は限られています。

名前	一言で	事例やツール	特徴
リスト	一覧	⭕	つくりやすいが、読む気になりづらくタスクの詳細も見えづらい
テーブル	表	⭕	行と列で二次元的ゆえに情報密度が高いが、認知負荷が高くて疲れやすい
ボード	板	⭕	カードとその配置が直感的にわかりやすいが、色や見た目の情報量が多くて疲れやすい
チャート	図式	⭕	煩雑な情報を視覚的に表現できるが、色んなチャートがあり学習コストがかかる
ネットワーク	網	❌	ノード同士の繋がりを多次元的に表現できる（詳細は後の章）
センテンス	文章	❌	文章で書くため文脈を含められるが、タスク自体の情報量をあまり盛り込めない

ビューを選んだりつくったりしたいときは、この種類を頭に入れておくと良いでしょう。たとえば、これらを超越した魔法のようなビューはありません。所詮はタスクを集めて表示しているにすぎません。どちらかと言えば、そのビューに慣れてしまうこと、特に ビューを見る人全員が見慣れること が重要です。あちこち浮気するよりは、まずひとつを決めて使い潰すつもりで取り組んだ方が学べることが大きいです。ここを履き違えると、理想のビューをひたすら追い求める「ビューの亡者」になってしまいます。個人で、趣味でそうするのは好き勝手ですが、プロジェクトタスク管理という文脈でそうするのは迷惑以外の何者でもありません。

さて、種類との向き合い方を述べたところで、各種類の詳細に入りましょう。

リスト

リスト（List） とは箇条書きのことです。

1行1タスクで並べて表示します。並び順がありますので、フィルタリングやソートにより見やすくできることがあります。

メリットはつくりやすいことです。TODOリストもそうですが、手作業でつくるのも比較的容易いです。何せ並べるだけですからね。もちろん、どんな情報をどんな順番で並べればいいかは肝心です。極論、1000個のタスクがあったとして、タスク名だけをランダムに並べたとしても、ほとんど役に立ちません。タスク名と締切を表示して、締切の降順で並べる、だとだいぶマシでしょう。

デメリットはいくつかあります。

まずは読む気になりづらいことです。というのも、リストは全面的に言語情報に頼っているからです。下手すると文章ですらありません。もはや羅列です。言葉の羅列。これは人間にとって、非常に抵抗感のあるものです。特に娯楽を思い浮かべるとわかりやすいと思います。ストーリー性のあるものや面白い文章の方が読みやすいですし、言語情報よりは音声や絵や映像の方が消費しやすいですよね。タスクのリストは、ただの羅列ですから、読書が得意な人や活字中毒者でさえ読むのに抵抗があります。そういうわけでリストビューは実用上はほとんど使われず、他のビューをつくったり、あるいは打ち合わせを開いて直接聞いたりされます。リストは思ってる以上に手強い存在なのです。

もう一つ、タスクの詳細情報が見えづらい点も挙げられます。1行1タスクで、言語でしか表示できませんから、表示できる情報量に限りがあります。実際、現在のプロジェクトタスク管理ツールでは、次で紹介するテーブル形式が主流です（行と列で二次元になるので情報量が増える）。

テーブル

テーブル（Table） とは表形式のことです。

1行1タスクで並べますが、列も存在しており1列1属性に対応します。フィルタリングやソートは行を増減する調整ですが、テーブルでは表示列の調整（カスタマイズ）も可能です。また、列名をクリックするとソートになる（昇順と降順を交互に切り替えるなど）機能もよく知られています。

メリットは親和性と見やすさです。まず表計算ソフトの Excel が圧倒的な市民権を得ていますし、そうでなくとも表という概念はビジネスにおいて極めて身近です。社会人であれば、あるいは学生やアルバイトの段階で、ほぼ必ず触れる概念ではないでしょうか。圧倒的に日常に馴染んでいるのです。もちろん馴染みうんぬん以前に、行と列で二次元的に表示しているから見やすいとも言えます。当たり前のことを小難しく言っているように聞こえますが、表は本当に偉大な発明だと思いますし、現代でもまだまだ有力です。「テーブルビューを選んでおけば間違いなし」と言えるほど無難な選択肢でもあります。より大胆に言えば、テーブルビューでプロジェクトタスク管理が成立しないのなら、それ以前の問題がはらんでいます。プロジェクトタスク管理、特にビューによる俯瞰を機能させたいのなら、まずはテーブルビューで機能させるところを目指すのが良いでしょう。

デメリットはいくつかあります。

まずは疲れることです。タスク情報が隙間なく敷き詰められるので、ちゃんと読むと認知資源を見る見る食います。ネットサーフィンや SNS の巡回、あるいはメールやチャットの昇華とは比になりません。まるでタイムラインのように、高頻度にテーブルビューを見る方がたまにいらっしゃいますが、非常に疲れるので推奨しません。とはいえ工夫すれば消耗は抑えられます。たとえば細かい粒度は端折って表示する（大タスクレベルのみ表示するなど）、知りたい条件でフィルタリングやソートをかけるだけにする（目的特化）、あとはこれは他のビューにも言えることですが 欲しい情報が記入されてないのに読み取ろうとしない ことです。エスパーではないし、推測したところで外れることも多いですから、ちゃんと記入してもらうよう働きかけましょう（それが難しいのは前述、キャズムとして述べたとおりです）。

ボード

ボード（Board） とは板形式のことです。板というと聞き慣れませんが、掲示板や伝言板など何かを貼り付けるスペースを思い浮かべてください。

タスクは付箋やカードといった形で表現され、これを二次元空間に並べることで俯瞰できるようにします。自由に配置させるというよりは、整然と並ばせるものが多いです。特にプロジェクトタスク管理はカンバン方式の影響を受けていることが多く、未着手・進行中・完了といった領域が区切られていて、そこにタスクカードを配置し、また動かします。

メリットは見やすさです。リストのように言語の羅列ではなく、テーブルのように情報を詰め込んでもおらず、適度な余白とデザインの反映されたカードが並んでいる状態ですので、視覚的に易しいのです。カード内にもある程度の空間がありますし、ビュー側でサイズ調整もできますので、表示する情報も工夫できます。デザイナーの腕の見せ所でもありますね。

そして肝心なのは、カードであるため「場所を移す」という操作が使えることです。カンバンもまさにそうですが、たとえば開始したタスクがあれば、そのカードを未着手ゾーンから進行中ゾーンに移せばいいのです。ツール上ではドラッグして移動させるといった直感的な操作で行えます。これは「タスクの詳細ページを開いて、状態属性を未着手から進行中に変更する」みたいな操作よりもはるかにわかりやすいし、手間も少ないです。

これだけ見やすく、手間も少ないと、慌ただしいプロジェクト下でも使えます。みんなを集めて、会話しながらボードを見て「多すぎるからこのタスクは捨てるか」「これはもう終わったよね、完了に移すね」などささっと操作して状況反映できます。リストやテーブルだとそうはいきません。

デメリットは二つあります。まずは別の意味での疲れやすさがあることです。リストやテーブルよりもグラフィカル（視覚的）なので、視覚的にうるさくなることがあります。また空間的な配置にもなるので、空間認識が苦手な人にも負荷が高い傾向にあります。大まかな目安として、ボードが合う人とリストが合う人がいます。視覚性や空間認識に強い人はボードが合いますが、そうじゃない人は合わないかもしれずリストの方が馴染めたりします。次に、表示できるタスクの数が少ないため、実質的にアジャイルなど「1～2週間ごとにやることを決めてまわす」感じの仕事も仕方が要求される点です。仮にボード上に並べられるタスクが 20 個の場合、同時に扱えるのは 20 個までとなります。タスクが全部で 100 個あったとしても、扱いきれません。そのため「今月はこの 20 個にフォーカスしようか」など区切りを入れて、その分だけをボードで扱う、といった対処が必要なのです。

ボードビューはリストやテーブルよりも後発なので、使えるなら使いたいところです。しかし、合う合わないはあるので、合わないようなら無理しない方が良いでしょう。

チャート

チャート（Chart） とは図式形式のことです。

何とかチャート、何とかグラフ、何とか図（ダイアグラム）といった視覚化のやり方がありますが、そのあたり全般を指します。タスク管理としては、主にフレームワークとして整備されていることが多いです。

例:

• WBS
• PERT図
• ガントチャート
• バーンダウンチャート
• 累積フロー図

チャートの本質は、縦軸や横軸など「特定の軸」を選んで、それに基づいてデータ（この場合はタスクに関する情報）を配置し、兆候の良し悪しを視覚的にわかるようにすることです。特に危険な兆候を知るのに役立ちます。重なっていたら危ないとか、領域が広がったら危ないとか、線の傾きが大きくなると危ないなど、直感的に危なさを把握できます。何を知れるかはチャート次第ですので、そのチャート（のフレームワーク）をきちんと学ぶ必要があります。

色々なチャートを集めたビューはダッシュボードと呼ばれることもあります。タスク管理の文脈では聞きませんが、統計分析やセキュリティの文脈ではよく登場します。データドリブン経営などと言ったりもしますが、データを重視する潮流も近年は盛り上がっています。今後はダッシュボードレベルでチャートを重用したタスク管理ツールも出てくるかもしれませんね。

さて、メリデメに入りましょう。

メリットは煩雑な状況を視覚的かつかんたんに把握できることです。諸々のフレームワークは、それができるよう工夫が凝らされています。素人の思いつきでできることではありません。つまりチャートとは自らつくるものというより、何らかのフレームワークに基づいたもの（かつツール側がサポートしているもの）を使うものです。正しく使えば、視覚的にかんたんに俯瞰できるようになります。

デメリットは、まさにそのフレームワークの勉強が必要になることです。ツールによっては独自のチャートがサポートされていることもありますが、その場合もやはり読み方などを学ばねばなりません。もちろん学んで終わりではなく、実際にチャートを機能させ、それを読み解いて状況判断ができるようになるまでには訓練も必要です。

またチャートごとに適切な状況が想定されており、ご自身の状況と照らし合わせる必要があるかもしれません。たとえば WBS やガントチャートは、一度立てた計画のとおりに動くという安定的な場面に適していますし、バーンダウンチャートや累積フロー図などはアジャイル開発という「計画を動的に変える」「1-2週間など短期間の計画と実践を繰り返す」場面に適しています（なので計画よりも実績の可視化に比重を置く）。計画駆動な場面でバーンダウンチャートを使ったり、アジャイルな場面で WBS を使ったりするのはアンマッチでしょう。

ネットワーク

ネットワーク（Network） とは網形式のことです。

網というと直訳的でわかりづらいですが、点を線で結んだような構造を指します。点のことをノード、線のことをエッジと呼ぶこともあります。理論としては専門的ですが、人間関係、ウェブサイトや書籍の言及関係など身近にもよく見られる構造です。これをタスクにも適用します。つまり、タスクとタスクの関係を描いたネットワークを見せるのだと考えられます――と濁しているのは、ネットワーク形式のビューがまだ存在しない からです。

そもそもネットワーク構造をつくるためには、タスクとタスクを日頃から接続する（何らかの関係性があるのでその旨を登録する）必要があるのですが、通常そんなことはしません。プロジェクトタスク管理としても想定された動きではありません。ツールによっては言及先と言及元を表示する程度の機能を持つもの（Redmine や GitHub Issues）もありますが、あくまでもタスク各々つまりは俯瞰ではなく注視の話であって、すべてのタスクの接続関係をネットワークのビューで俯瞰することはできません。もう一つ、ワークフロー機能を備えたツールがあり、ネットワーク形式で見せることが多いですが、これは「処理の流れ（ワークフロー）」のビューであってタスクのビューではありません。ワークフロー機能は、タスク管理というよりはビジュアルプログラミングの話になります。

最近ではノートベースのツールが出てきており、これをタスク管理用途で使えば一応できないことはないのですが、高度な話なので後の章で述べます（文芸的タスク管理）。

そういうわけで現状事例がないため、メリット・デメリットの記載は割愛します。

(余談) ビジュアルプログラミングとタスク管理、Automation

ビジュアルプログラミングとは、ビジュアルに（視覚的に）プログラミングを行うことです。何らかの処理を行うパーツを配置して、どのパーツからどのパーツにどんな情報を渡すか、といったことも考えて、まるでパズルのようにつなぎ合わせることで全体の処理をつくります。

パーツの品揃えと働きは理解する必要がありますが、難易度的にはゲームと大差がなく、もちろん個人差はありますが未経験の小中高生でも使えるようになれます。教育用の Scratch が有名です。

これは プログラミングという難しい営みも、ビジュアルだと比較的かんたんにこなせるようになる とも言え、近年ではノーコード（プログラムコードを一切書かない）・ローコード（ほとんど書かない）と呼ばれるジャンルも出てきました。たとえば、プログラマーではないバックオフィス業務の人が、自分で、ビジュアルプログラミングを使って、業務改善ツールをつくる――なんてことも可能になりつつあります。日本ではサイボウズの kintone が知られていると思います。

さて、このような着眼は、タスク管理にも来ています。それが Automation と呼ばれる機能です。Automation は直訳すると「自動化」で、タスクに関する操作を自動化するための仕組みです。以前の章の「省力化する」にて少し述べましたが、「XXX が起きたら YYYY を行う」という形で事前に処理を定義しておくと、XXXX が起きただけで YYYY が自動で処理されるようになります。お決まりの「ワークフロー（処理の流れ）」があったら、それを Automation で自動化しておくと楽になるわけです。別の言い方をすれば、Automation とは（タスクの操作に関するワークフローの）自動化を行う仕組みである とも言えます。

少々小難しくなりましたが、要点は 3 点です。

• 1: ビジュアルプログラミングという、プログラミングを比較的かんたんに行う手段がある
• 2: ビジュアルプログラミングの流れはビジネスにも降りてきており、一般の人でも処理を組み立てることができつつある
• 3: タスク管理にも降りてきており、一部ツールはすでにサポートしている。タスクの操作を自動化できる

よって、ビジュアルプログラミングに慣れ親しんでおくと、今後 Automation にも頼りやすくなるでしょう。

センテンス

センテンス（Sentense） とは文章形式のことです。

センテンス型のビューも既存事例はありません。強いて言えば、生成 AI の力でつくれないこともないですが、結果の正しさを保証できないため実用性はあまり高くないでしょう。というわけで、当面は私たち自身が手作業でつくることになります。何をつくるかというと、 俯瞰できるような状況を「文章として」事前に書いておきます。

例を示します。書籍をつくるプロジェクトだと考えてください。Before はリストビューで、After はセンテンスビューです。

Before（リストビュー）:

• ✅目次案
• 43% 第1章
• 20% 第2章
• 00% 第3章
• 16 参考文献

After（センテンスビュー）:

まずは「✅目次」をつくる。小説におけるプロットと同様、羅針盤があった方が書きやすいから。ここは譲れない。本文に入る前に必ず目次は確定させる。ただし仮でよい。どうせ変わる。

その後は「1章(43/100)」、「2章(20/100)」、「3章」と進めていく。各章は独立しており、並行して進められるが、1章だけは基礎用語を導入するため、先にひととおり完成させるべきである。

「参考文献(16件)」は執筆の都度、追記していくべきである。全章書き終えたあとに改めて整備するため、章執筆中は雑で良いが、urlや書名など必要な情報は必ず揃えること。また後でリンクを直すのも手間なので、リンクの正しさは都度確認すること。

センテンスビューでは文章による補足が書き込まれています。ここまでビューはタスクを上手いこと並べて表示するものでしたが、単に表示するだけでなく、文章も書いています。もちろんタスクの情報が見えないと話にならないので、それはツールの力で自動で表示します。上記例で言えば「✅」や「43/100」などがそうです。これらはいちいち手作業では書きません。その他詳細は後の章で扱います（文芸的タスク管理）。

メリットは文脈がわかることです。ビューには通常、タスクが並ぶだけでしたが、センテンスビューでは文章にて文脈も書いているので意思決定がしやすくなります。上記例で言えば、何をどのように書いていけばいいかが書いてあるので、チームで振り返った時でも気付きやすいですよね。「1章を先に完成させるべきじゃないのか」とか「2章がちょっと進んでるけど、1章にもっと注力するべきでは」など気付きやすいはずです。

このようにガイドライン的な簡潔な文章を書いて羅針盤にするアプローチでは現代のビジネスでもよく使われます。転職活動をしたことがある方はよく見かけると思いますが、働き方や哲学といったものを文章化して紹介している会社は珍しくありません。パーパス経営とか、企業理念とか、そういった言葉を耳にする機会も増えてきたのではないでしょうか。また、自己啓発の分野でもミッションステートメントなど、自分の人生観を言語化して掲げる取り組みはよく知られています。文章的な羅針盤は古くからよく知られたテクニックです。それをタスク管理の、ビューにも生かしたものがセンテンスビューです。

次にデメリットですが、文章を書くのが大変です。文章力の話ではなく、合意形成の面で、という意味です。プロジェクトタスク管理では、ビューはメンバー全員が見る可能性があるものですから、全員が納得できる文章が求められます。文脈は「これでいいですよね？」と決める必要があります。曖昧は許されません。曖昧な状態を反映したところでセンテンスビューの旨味はありませんし、さして意味のない文章は読み飛ばされて形骸化するだけです。

文章力の話ではないと書きましたが、この点も地味にキツイかもしれません。というのも、センテンスビューでは、あまりタスクの情報を出せません。テーブルビューはもちろん、リストビューよりも情報量は低くなります。ということは、あまり広範囲を俯瞰したビューはつくれないことになります。センテンスビューをいくつもつくらねばならなくなるかもしれません。たとえばタスクが100個あった場合、テーブルやリストだと数個以内のビューで足りるでしょうが、センテンスだと数個ではすみません、仮に 10 個ごとにつくるとしても 10 センテンスになります。中々にハードですね。それから、ガイドラインと書きましたが、状況が変われば微修正は当然入るので、センテンスも修正します――と、要は 文章を書いたり修正したりという営みが生じます。文章が苦手な人にはキツイですし、得意でない人でもキツイでしょう。

さらに言えば、現状ツールが無いこともデメリットでしょうか。特にタスクの情報を自動で表示するものがありません。上述した例のような文中の展開を行えるツールはまだないと思います。センテンスビューを実現したければ、前述の第四段階でも述べたように、ツールの API を駆使して、自分達でそういう仕組みをつくらねばなりません。

シャドータスクを上手く扱う

ビューの話はここで終わるとして、次にプロジェクトタスク管理が上手く行かない主因の一つを取り上げます。シャドータスクです。

シャドータスク

シャドータスク（Shadow Task） とは、タスク管理ツール上で管理されてはいないが、事実上タスクと呼べるレベルで存在しており、私達のリソース――時間や体力やお金や精神を食っているものを指します。残業を勤務管理に計上しないことをサービス残業と呼びますが、同じようなものです。管理はしていないが、実際には存在しているわけで、それなりに（どころかたいていは「かなり」）負担になっています。

シャドータスクの例:

• コミュニケーション全般
  • 仕事に関する相談や議論
  • 当日発生した打ち合わせ（緊急 or 思いつきのいずれかが多い）
  • その場で行う指導や教育
  • 根回し
• 社内雑務全般
  • 全社から降ってきた依頼対応
  • イベント運営のお手伝い
  • 備品やシステムなどの故障・障害に伴う対応
  • 同上、アップデートやバージョンアップ
• 穴埋め全般
  • 業務の引き継ぎ（特に突発的なものなど業務の一環として正式に準備・計画されていないもの）
• メンテナンス
  • 始業前や就業後の準備
  • デスク、デスクトップ、その他情報の整理整頓
  • 昼食や休憩や買い出し（移動時間含む）
• キャッチアップ
  • 業界動向や顧客の学習
  • ドキュメントや書籍の読解
  • 雑談の場やイベントへの顔出しや寄り道
• ツール
  • タスク管理ツールの学習や操作
  • メールやチャットの操作
  • PCの準備、設置、起動、終了、撤収
• プロセス
  • 手順
  • 手続き
  • フロー
• 通勤・出社

シャドータスクは至るところに、想像以上に存在しています。インパクトのある例として通勤が挙げられます。パンデミックによりリモートワークでも通用することがわかった組織では、通勤も業務時間に含めたり（※1）、交通費を全面的に立替精算にしたりしています。長らくシャドーだった通勤をすくいあげたわけです。

• ※
  • 1 会社として正式には認めていないが、現場の融通で含める、とのバランスもあります。この件に限らず、現場で融通を利かせることは組織力学または処世術としてよくあることです。このようなことが必要なのも、正式なルールに厳密に従っていえばシャドータスクに忙殺されてしまうからです。もちろん、行き過ぎるとコンプライアンスを犯してしまい損害に通じることもあります。

シャドータスクを捉えることの重要性

通勤の例だけでもよくわかりますが、シャドータスクは私たち従業員にとって都合が悪いものです。それなりに負担があるのに、タスク管理上は計上されないので、完全にこちらが割りを食ってしまいます。

ここで「直接関係がないタスクなのだから管理しなくてもいいのでは」と思われるかもしれません。一見するとたしかにそうですし、実際シャドータスクも全部ツールに入れても邪魔なだけでしょう。そうではなく、シャドータスクによりリソースをそれなりに消費しているという事実がある 点が重要ですよ、という話です。

たとえば都内のオフィスへの通勤に片道 1.5 時間かかる人がいたとします。この人は人混みが非常に苦手で、片道分通った後は 30 分休憩をはさまないといけない体質だとします。また給料も十分ではなく、家賃を押さえるために郊外に住んでいます。さて、この人の 1 日の持ち時間は定時分の 8 時間（7.5 時間とかでもいいです）だと見ていいでしょうか。答えはノーです。実際には「2時間のタスク」を「1日2回」抱えているようなもので、より率直に言えば毎日 4 時間のサービス残業をしています。そんな状態で、毎日 8 時間も働くのはかなり不利でしょう――このような事情は、プロジェクトタスク管理ツール上では見えません。

別の例を挙げます。上位部門の審査と承認が何かと求められるチームがあるとします。審査には資料や打ち合わせの準備、打ち合わせへの参加、参加後は議事録の記入と共有が必要だとします。一回の審査あたり平均して 45 分費やしてるとします。もちろんこれは雑務にかかる時間にすぎず、他にも上長の審査が始まるまでの時間待ちもあります（たとえば 3 日後であるなら 3 日待たないといけません。この審査は一人あたり 1 日 1 ～ 3 回行っています――この場合、事実上一人あたり 1 ～ 2 時間を費やしていることになります。が、タスク管理上では管理されていないと、「タスクの進みが思ったより遅いぞ？」「なぜだ？」となってしまいます。単純計算でも 1 ～ 2 時間抜けているのに、実際は待ちもありますし、仕事と審査とでは頭を切り替えたりもしますよね、そういったことも踏まえると、筆者としては毎日半日近く飛んでいるに等しいのではと感じます。

他にも例は無数にあると思いますが、要するにタスク管理ツールが示す情報だけでは足りないのです。特にシャドータスクは、思っている以上に私たち従業員のリソースを食いつぶしています。結果として 「なぜだかわからないが、タスクの進行が想定より遅い」現象や「まともにタスクをこなせる人材が少ない」現象が起きます。当たり前ですよね、シャドータスクに引っ張られているわけですから。また、上手くやれている人も、シャドータスクにも負けずに頑張れている「強い人」にすぎません。

このような現象を シャドーエフェクト（Shadow Effect） と呼ばせてください。ようやく結論になりますが、なぜシャドータスクを捉えることが重要かというと、シャドーエフェクトを減らす手がかりになるからです。よくわからないまま振り回されるのではなく、具体的にこういうシャドータスクがあって、これだけの影響が出ているから、こういう対処をしよう、と建設的に改善していけばシャドーエフェクトは減らせます。

シャドーエフェクトは意識的に目を向け、減らして行かねばなりません。分かりづらいがゆえに無自覚である人や組織も少なくないからです。意識的にやらねば土俵にすら立てません。

シャドータスクの扱い方

プロジェクトタスク管理において、シャドーエフェクトを減らすには――シャドータスクを見つけて対処するにはどうすればいいでしょうか。

まず前提としてシャドータスクには二種類あります。そのプロジェクトに関するタスク（ ダイレクトシャドー ）と、そうではないタスク（ インダイレクトシャドー ）です。上記の例で言えば、通勤はインダイレクトシャドーです。通勤というタスク自体は通常、プロジェクトとは何の関係もないはずです。ただし出張など例外もあります。一方、上位部門の審査はダイレクトシャドーでしょう。このような審査はプロジェクトの一環として行うはずです。対処は ダイレクトシャドーかどうかで変わる ので、この区別は意識してください。

対処のアプローチは三点あります。

• 1: キャパシティベースのタスク管理を行い、シャドーエフェクトの影響を考慮する
• 2: バッファとスラックを確保し、各自がシャドータスクに対処する余裕をつくる
• 3: ダイレクトシャドーをタスク管理する

1: キャパシティベースのタスク管理

キャパシティ（Capacity） とはあるチームの、ある期間における処理能力を指します。たとえば 1 週間で大体 15 タスク消化できるのなら、キャパシティは 15 です。15 タスク以上は割り当てない方が良い、と判断できるでしょう。キャパシティの細かい計算方法や精度の高め方は色々ありますが割愛します。重要なのは「処理能力ベース」で考えて、それ以上は積まない、という考え方です。カンバン はまさにキャパシティベースと言えます。

この考え方を採用すると、シャドーエフェクトをスルーできます。というより シャドーエフェクトが存在する前提でのキャパシティを採用します。これを シャドー・ベースド・キャパシティ（Shadow Based Capacity, SBC） と呼ばせてください。本当にチームにとって無理のないキャパシティを考えると、自然とそうなります。たとえば定時間が 8 時間だとして、シャドータスクのせいで実質 5 時間くらいしか働けない人が 3 人いたとしても、無理のないキャパシティを想定すれば、チームのキャパシティは「その 3 人分については 5 時間働いた程度のもの」になります。「3 時間分働いてないじゃないか」と怒ったり、無理やり働かせたりするのではなく、このキャパシティが現実的なラインなのだからこれでいい、とするのです。

理屈上は難しくないですが、実際に SBC を採用するのは中々に困難です。まずキャパシティの計算頻度と見積もり精度をある程度安定させなくてはなりません。アジャイル開発というソフトウェア開発手法ではこの手の理論を扱っていますが、エンジニア向けですし練習も要ります。

もう一つ、難しさを助長しているのが「強い人」の存在です。「強い人」とはシャドータスクの負荷に慣れていて、かつ耐えることができる人達です。彼らは SBC の視点を持てませんし、持てても行動にまでは落とし込めません。別に SBC にしなくても何とかなるので、あえて SBC にしようとは考えないのです。部屋が汚くても別に生活できるのならわざわざ掃除しないのと同じです。どころか、SBC にすると、その分労働時間が減って生産性も減ります。別に耐えられるのに、わざわざ減らすかというと、減らさないでしょう。時間給が絡んでいるならなおさらです。そういうわけで、「強い人」が多ければ多いほど、SBC は適用しづらくなります――といっても難しい話ではなく、単にその人に合ったキャパシティを尊重しましょう、というだけの話ですが、ビジネスでは「強い人」が正義になりがちです。特に日本は平等思想が強いですし、すでに強い人ベースでビジネスが回っていますので、彼らのペースを強要されがちなのです。強くない人達は、そういう経験が一度は、あるいは何度もあるのではないでしょうか。

2: バッファとスラック

バッファ（Buffer） とはイレギュラーに備えるための時間的余裕を指します。仕事でも（一週間あれば終われそうだけど）見積もりは二週間で出す、とかしますよね。これは「一週間分のバッファを積んでおく」などと表現されます。2 倍という数字に絶対性はありません。数日積むとか、1.2 倍積むとかいったなどもありえます。いずれにせよ、ある程度積んでおくことは経験則として重要です。仕事は何が起こるかわからないものですし、やってみてわかることも多くて、それらに合わせて修正する時間も要るからです。

バッファの必要性はシャドータスクについても言えます。バッファを積んでおくと、思わぬシャドーエフェクトが生じてもバッファの分を使って対応できるようになります。通常、バッファはシャドータスクのために確保するものではありませんが、シャドータスクは（見えていないだけで）ありふれているので、日頃から なんだかんだシャドータスクに邪魔されることは割とよくある 想定で過ごすのが無難だったりします。どの程度積むかは状況次第ですが、一週間のスパンで考えるとすると「半日」くらいのバッファをまずは積んでみると良いでしょう。何かと融通が利いて助かるという体験が出来ると思います。といっても、バカ正直に「私は半日分はサボります」とは言えませんので、現実的には自分の意識として心がけるか、冒頭の例のようにしれっと積んでおく形になります。チームメンバーを騙すようで気が引けるかもしれませんが、お互い様です。バカ正直に「シャドータスクのバッファを積みましょう」というと、正論や法規で語らなきゃいけない人達（特に上司など）は立場上潰さないといけなくなりますし、前述の「強い人」達を説き伏せるのも難しいので、しれっと、で良いのです。もちろん正直に議論できるに越したことはありませんが、その場合は 1: の SBC で良いでしょう。

スラック（Slack） とは恒常的な余裕を指します。ここでいう余裕とは時間的にも精神的にも、です。たとえば毎日 1 時間、仕事にとらわれず雑談したりのんびり休んだりする時間を取れるでしょうか。昼休憩のことではなく、昼休憩を差っ引いた現在の定時間 7～8 時間において、1 時間取れるかという話です。これは毎日 1 時間のスラックを確保していると言えます。スラックのおかげで気分転換や休憩ができますし、雑談から親密感を醸成したり思いがけないアイデアが出たりもします。私たちは資本主義的価値観に縛られており、真面目に忙しなく働かねばならないととらわれがちですが、案外そうでもないです（もちろんスラックが許されない状況や仕事もあります）。スラックを取り上げた書籍 もありますし、1on1 ミーティングという取り組みにて業務時間中に雑談をする例も今や珍しくありません。また、（これはスラックというより労働時間量の絶対性に対するカウンターですが）週休3日制の働き方を採用した企業もあります。

スラックがあれば、シャドータスクの対応に時間を使うこともできます。特に「別に余裕なんて要らない」という人でも、シャドータスクは存在しているので重宝します。仮にシャドータスクさえないとしたら、普通に仕事をすればいいのです。重要なのは スラックが存在する（必要なら使える） ところにあります。なければ使えませんが、あれば使えます。要らなければ使わなければいい。在ることに意味があります。現状スラックを正式に採用した事例はまだ無いと思いますが、今後は魅力の一つになるでしょう。たとえば「毎日 1 時間のスラックがあります」といわれたら、どうでしょうか。魅力的な職場に見えてきませんか。

3: ダイレクトシャドーのタスク管理

シャドータスクがダイレクトシャドー――つまり仕事に直接関係している（けど管理されてなくて見えてない）ものであるならば、それを見えるようにすればいい、というのも対処の一つです。具体的にどんなタスクがあるかをきちんと言語化して、タスク化して、担当者を決めて、必要なら期限も決めて、と普通にタスク管理をします。

重要なのは普段の流れに仕込むことです。ツール上で担当者を決めて「空いたときにやっておいてね」ではなく、普段の仕事の流れに組み込むということです。たとえば毎日、朝会にてビューを見ながら今日何をするかを決めている場合、（ちゃんと管理すると決めた）ダイレクトシャドーについても、他の正式なタスクと同じように扱うのです。プロジェクトの一環として、仕事の一つとして、ちゃんと対応します。もし言語化すらできていないのなら、まずは「メンバー全員でダイレクトシャドーを言語化する会」を開催するとか、メンバー全員に「ダイレクトシャドーを洗い出す（想定時間: 1時間）」タスクを割り当てるなどが必要かもしれません。しつこいようですが、空いた時間でお願いしますではなく、業務の一環として正式にダイレクトシャドーと向き合うということです。

と、一般論だけ書いてもわかりづらいですが、いわゆる「改善」は典型的な例でしょう。何らかのダイレクトシャドーを何とかするために、何かを改善する必要はしばしばあります。その改善活動をタスクにするのです。

ちなみにインダイレクトシャドー――仕事に直接関係しないシャドータスクについては扱っていないことに注意してください。というより、扱っても困りますよね。たとえばAさんがリモートワークをしていて、「近所の犬の鳴き声がうるさくて集中できない」「このうるささに耐えるためには耳栓や薬や瞑想といった手続きが必要で、毎日平均 30 分を要している」として、じゃあこの A さんの犬の鳴き声対処タスクをプロジェクトタスク管理するかというと、ノーですよね。これは A さんが自分で対処するべきことです。プロジェクトで行うことではありません。前述のバッファやスラックを使う（ここでメンバーと雑談して対処方法を相談するなどはもちろんアリです）のでもいいですし、キャパシティベースにて最初から 30 分少ない前提でのキャパシティを踏まえる、でも良いです。

プロジェクトタスク管理がついでに管理しているもの

管理も過ぎれば毒です。管理が過ぎれば過ぎるほど融通が利かなくなり、そのための対応に疲弊しながらも本来の仕事に費やせる余地も小さいというダブルパンチを喰らいます。やる気も削がれますし、満足度が下がります。何なら「管理を乗り切るために頑張る・誤魔化す」ことが目的化してしまい、プロジェクト自体が形骸化してしまいます。現実は綺麗事ではないですし、そういう場面を見たことがある（何なら現在進行で巻き込まれている）人も少なくないのではないでしょうか。この手の現象は法則としても知られており、たとえばグッドハートの法則があります。

それでも昔は結果さえ伴えば良しとされてきましたが、現在はそうではないはずですし、そうあってはならないとさえ思います。細かく管理しすぎるマイクロマネジメントを好む人は少ないでしょうし、組織のパラダイムも暴力的恐怖政治的なトップダウン → 階級 → 成果主義と階層 → 平等でフラット → 自律と秩序（ティール組織）との変遷を辿ってきています。無論、状況が余談を許さないことはありえますが、前提にしてはならないと思います。かといって何も管理しないと秩序も何もあったものではありません。

話をタスク管理に戻しましょう。プロジェクトタスク管理についても案外色んなものを管理しており、管理過多になりがちです。この点を自覚した上で、管理のしすぎという毒を薄めるのが重要です。本節ではそのヒントをお届けします。

5つの管理対象

タスク管理という言葉の裏には、思っているよりも多くの管理対象が存在します。5 つにまとめることができます。

名前	日本語で	解説	例
Progress	進捗	ゴールに対する進行具合	37%/100
Quality	質	状態の良さや安定性	エラー発生率は2%、73%が満足度が高いと回答
Process	プロセス	順序やルールへの踏襲具合	手順、手続き、形式、法規、規則規約
Resource	リソース	総量に対する消費具合	時間、お金
Property	専有	所有感と従順性	出社や会議など場への参加、（江戸時代の）参勤交代

愚直に捉えると タスク管理＝タスクの進捗管理 です。それ以上でもそれ以下でもありません。タスク管理とはタスクを終わらせるためのものであって、終わらせるために、どこまで進んでるかを可視化したいのです。3A の本質 としてアサイン、調整、俯瞰と注視を挙げましたが、結局やりたいことは 進捗を知りたい。ただそれだけです。進捗がわかれば、特に遅れがわかれば対処を打てるからです。

しかし実際には進捗以外も管理されがちです。質も、プロセスも、リソースも、下手すると専有も管理されます。もちろん現実は進捗が見えただけで上手くいくほど単純ではなく、癖の強い人間を上手く動かすためにも管理は役立ちますが、前述のとおり、やりすぎると毒になります。これらを自覚し、要らない部分をどれだけ削れるかがポイントとなります。

では、各管理対象の詳細を見ていきましょう。対象の性質がわかれば取捨選択――管理するかどうか、あるいはどこまで管理するかを判断するのに役立ちます。

進捗の管理

進捗の管理 とは、タスクの進行具合を管理することです。何らかのゴールがあって、それに向かってどこまで進んでいるかを見ます。シンプルだと「終わったかどうか」の二値で見ますし、まだやってない・着手中・終わったの三値もよく見られます。もう少し細かいと、パーセンテージなどで表現します。

どこまで管理するかは管理者（いないならチーム全員）の腕の見せ所です。早い話、問題無くタスクをこなせていけるなら「終わったかどうか」をたまに確認する程度でも良いのです。その程度で済むのに「毎日 1-100 のパーセンテージで記入しろ」「毎朝報告しろ」などと管理するにはやりすぎです。これがビジネスの文脈だと「それが仕事だろ」「プロフェッショナルだからこそだろ」などと正当化されますが、ただの単純化や現行踏襲にすぎません。

進捗の管理は加算方式が良い です。できるだけ管理しない、という前提があって、それで上手くいかない場合は「上手くいく程度に」少しずつ管理を追加していきます。もちろん結局は加算を重ねて厳しい管理になってしまうこともあります。

進捗の管理が厳しくなりがちな理由は二つで、管理者の都合と報告者の都合です。

まず管理者の都合とは、他にやることがない管理者が管理という仕事を無理に捻出する、あるいは自分の仕事を守るために管理にしがみついている等を指します。通常、組織が大きくなってくるとこれが増えます。組織力学として自然なメカニズムです。ここに抗うには、ティール組織など「健全な組織体系のままで大きくなる」設計が必要です。他にも、単に管理者の資質が未熟なこともあります。たとえば結果が出るまで待つことに耐えられなくて、安直に見たがるという心理があります。このような耐性をネガティブ・ケイパビリティと呼ぶこともあります。ネガティブ・ケイパビリティが低いわけです。もう一つ、管理をするとその管理指標でコミュニケーションを取れるという（管理者から見た）メリットがあります。責任の所在を曖昧にしたり、進行が遅れていることの免罪符に使ったりできるわけです。作文や数字いじりとの相性もいいですし、真面目につくられていたら心理上、報告先も甘くなります。さらに言えば、管理の名目で暇や寂しさや紛らわせたり、部下を詰めて楽しんだりといった隠れ職権乱用もあります。

次に報告者の都合とは、仕事上の報告先と向き合う報告者による都合を指します。たとえば契約で「毎週詳細な進捗レポートを提出しなさい」となっていたとしたら、それはもう管理過多であろうがやるしかありませんよね。実際は上述したとおり形骸化するわけですが、大事故が起こらない限り調査のメスは入らないので長らく続いたりします――と、これだけ見ると報告先が悪いように聞こえますが、そうではないのです。そもそもそんな契約になってしまわないよう、報告先と接する報告者側が何とかしなければなりません。また、ここまで露骨ではなく、契約など強制力がなかったとしても、管理者と同様、報告者が残念だとその力学が降ってくることがよくあります。鶴の一声、はまさにその一例です。それでも管理者のレイヤーで食い止められたらいいのですが、管理者が事なかれ主義だったりするとイエスマンになってしまい、現場にまで降りてきます。

いずれにせよ人の問題です。管理者にせよ報告者にせよ、管理を担う権限の強い人達が厳しくしまっているにすぎません。進捗の管理を緩和できるかどうかは、このような人をいかに是正できるか、あるいはそもそも巻き込まないかにかかっています。

ここで「ルールやプロセスとして決められているから仕方ないというケースがある」との疑問を抱かれるかもしれませんが、本当にそうでしょうか。後述する「質の管理」については、たしかに決められているケースもありますが、進捗の管理についてはいかがでしょうか。契約で決めてしまったケースを除けば、結局管理者や報告者の都合に帰着できると筆者は考えます。要は厳しめの管理という常識しか知らないから、それ以外のあり方がわからないのです。タスク管理を学ぶ重要性の一つが、まさにここにあります。管理の固定観念から脱するためです。

もう一つ、言及しておきたいのは「大事」でしょうか。何か大きな事件や事故が起きたときに、バカ真面目に厳しい対応を全体に敷く現象はご存知の方も多いでしょう。ひとりのポカによって従業員全員が不便を食らう経験はあるあるだと思います。その積み重ねで不便な業務環境を強いられている界隈さえあります。これも固定観念があると「仕方ない」と思うかもしれませんが、そんなことはなくて、管理者や報告者の都合にすぎません。「従業員が社用車で事故を起こしたので今後社用車は一切廃止します。公共交通機関を使ってください」くらいに馬鹿げたことです。現代では消費者の目が厳しいため、気持ちはわからないでもないですが、だからといって安直な一律適用は思考停止でしかありません。

まとめ:

• 進捗は加算方式で管理するのが良い
  • できるだけ管理を少なくして、問題があるなら少しずつ増やしていく
• 進捗の管理は厳しくなりだちだが、その理由は人にある
  • 管理者と報告者
  • 人として、あるいは組織力学として自然な現象でもある
  • 緩めたいなら是正するか、そもそもそういう人を巻き込まない・発生させないようにする

質の管理

質の管理 とは、タスクそのものではなくエージェント（タスクを遂行する側の人や仕組み）やアウトプット（タスクによって生み出した何か）の「良さ」を管理することです。よく知られているのは品質管理です。

質の管理では「質」を定量的に定義、計測して、基準値を下回らないように監視することを目指します。定量化が難しいものでも、人に尋ねて分類したり動向を見てその数や傾向を追うなどすれば定量化できますし、すぐに見つからない・わからない場合は頑張ってひねり出します。タスク管理からは外れますが、プロダクトマネジメントではまさにそのような指標として North Star Metric（北極星指標）を探しに行きます。ちゃんと管理するために、何とかして数字に落とし込むわけです。

質の管理は厳しく行うこと――特に安定させること がセオリーとなっています。事故やエラーが起こる率が「わかりません」は論外ですし、未来永劫ゼロですは無理にしても、できるだけ下げたいですよね。あるいはブランドなど付加価値を勝負する世界では高品質を担保せねばなりず、そのために高品質とは何かを定量に落とし込んで、客観的に判断できるようにすることを徹底させます。手間もお金もかかる営みですが、そうすることでようやく顧客に選ばれるサービスになります。

タスク管理との関わりですが、質の監視や向上といった活動がタスクとして存在する（Q-Task と呼ばせてください）、との対応になります。ここまで見てきたとおり、タスク管理は直接仕事にかかわるものばかりが重視されがちですから、この手のタスクはこぼれがちです。下手をするとシャドータスクになっていることもあります。前任者がいなくなった途端、ぼろぼろになる現象はよくありますが、それはその人がシャドータスクの Q-Task をたくさんこなしていたからだったりします。小説の話になりますが、近年ではまさにその立場から見たカタルシスを味わうジャンル（なろう系という一小説ジャンルのサブジャンル「追放系」）もあるほどです。

Q-Task のタスク管理の仕方ですが、まずタスクとしてしっかり認識させることです。シャドータスクであるならきちんと掬い上げて正式なタスクにするべきですし、他のタスクの最中に行う「ついで」や「一応手順ではあるが明確化されていないもの」であるなら、切り離して別途タスクにするか、明確化します。要は Q-Task を舐めないでください、ちゃんと正式にタスクとして尊重してくださいということです。

次に、可能なら以下も導入したいです。なお品質管理をご存知の方は、目新しいことは言ってませんのでスキップしてください。

• 言語化・定量化
  • 前述したとおり、そもそも質とは何かをきちんと定量化する
  • 定量化が難しい場合、少なくとも言語化はする
• 自動化
  • 人間による監視には限界があるので、機械やプログラムで自動で行えるようにする
  • 普段様子は自由に見れるようにしておくと、なおよい
  • 問題が起きそうなときだけ通知する（普段は気にしなくてもいい）、とさらによい
• 専任化
  • Q-Task を集中的に、あるいは重点的に担う専任者をつくる（アサインする）
• レビュー
  • 質についてちゃんとチェックする場（会議体）を設ける
• カジュアルな会話ができる関係
  • 質についての疑問や違和感をさらっと口にできる関係をつくる
  • あとで大事になるのを防ぎやすい

アプローチとしては二つあって、機械やプログラムによって徹底的に自動化するか、逆にレビューなどで人間の目を繰り返し通したりチーム全員の総意をもって通したりするか、の二択です。両方を採用することもできますが、リソース的に厳しく、傾向としてもどちらか一方に偏ると思います。もちろんこれらの活動もタスクとして尊重します。最後の会話については、タスク化というよりはそういう関係をつくるための余暇活動を業務時間に組み入れるイメージです（バッファとスラック）。Q-Task はかんたんに形骸化、あるいはシャドータスク化しやすいので注意してください。

最後に Q-Task の見直しも継続的に行ないます。特に手間暇が大きすぎたり、必要性が薄かったりすると形骸化しやすいです。そういう意味でも、上述したとおり専任化できるかどうかが鍵になります。品質管理部門、のような専用部門はありがちですが、対応が広く浅くなったり部門側がボトルネックになって形骸化したりなど中々難しいです。チームに質の専門家がいるのが理想ですね。ソフトウェア開発では「QAエンジニア」という、まさにそういう役割もあります。

もう一つ、質を確保する活動には向き・不向きが表れるので、向いてない人に強要しないことも何気に重要です。作家の世界でも質の保証は編集者が担ったりしますが、一般的には分業・分担が望ましいとされます。一方で、全く質を考慮しない人のフォローが大変なこともあり――など、このあたりは突き詰めると非常に奥が深いものとなっています。

まとめ:

• 質は厳しく管理して安定化させるのがセオリー
• その上でタスク管理するには:
  • 1: とにもかくにも、まずは Q-Task をタスクとしてちゃんと捉える
  • 2: 自動化か、人間レビューか、どちらかを採用する
    • 特に重要なのは専任者のアサインと、道中の活動もちゃんとタスク化すること
  • 3: 形骸化やシャドータスク化も起こり得るので継続的に見直す
• 向き不向きが激しいので、誰にどれだけやらせるかの見極めや調整もおそらく必要

プロセスの管理

プロセスの管理 とは、手順を管理することです。

タスク管理には「手順」や「手続き」として表れます。タスクの出来（前述でいう「質」もそうですね）を確保し、安定させるために、みんなこれこれの通りに作業してくださいね、とするのです。再現性という言い方をすることもあります。いつ誰が行っても同じ結果が出るようにしたいわけです。手続きは公式的な手順のことです。チームで決めたものはただの手順ですが、会社や業界や法律レベルで決まった手順は手続きと言えます。いずれにせよ本質は手順であり、指定された作業を指定された順番で行え、というものです。プロセスと手順は同義と考えて差し支えありません。

プロセスは典型的なシャドータスクになりがちです。たとえばタスク T の見積時間が 3 時間（3 時間で終わらせてほしい）だとして、そのうち従うべきプロセスの部分で 1.5 時間食われるとしたら、T の「プロセスに従う以外の活動」は 1.5 時間しか残っていないことになります。前者を プロセス活動、後者を 非プロセス活動 と呼ばせてください。つまりタスクはプロセス活動と非プロセス活動から成るわけですが、両者とも捕捉できていないと見積もりが甘くなります。どちらかがシャドータスクになりがちです。

もし T が難解なタスクで、「アイデアを形にするのに 3 時間くらいかかりそう」「形にした後、正式に採用してもらうまでの諸々のプロセスが 1.5 時間」だとしたら、T の見積もりは 4.5 時間が正しいでしょう。これを 3 時間にしちゃうと、プロセス活動の 1.5 時間は外せませんから、アイデアを形にする非プロセスの部分を 3 → 1.5 時間に圧縮するしかなくなります。アイデアの質が落ちてしまうわけです。落としたくない場合、おそらくどこかで時間を捻出するでしょう（つまりシャドータスク化している）。これを防ぎたいなら、ちゃんと 4.5 時間と見積もるか、あるいはタスク T を「形にする」「プロセスに則って採用する」の二つに分けるべきです――と、これは非プロセス時間がシャドータスク化する例ですが、逆もあります。プロセスは慣れてくると麻痺してくるので、「自分達が使ってるプロセスには 1.5 時間かかる」という事実を忘れがちです。

ここまではシャドータスク化――本当は存在しているのに無いものとみなされてる（から課外でカバーする、場合によっては諦める）について見てきましたが、もちろん管理過多もあります。やり方なんて自由でいいのに無理やりプロセスを適用したり、プロセス自体は必要だけど細かすぎて無駄に時間がかかったり、あるいはプロセスの中に承認ステップがあるが承認者が忙しくてボトルネックになっていたりします。これらと全部向き合うのはバカらしいことが多いですから、やはりシャドータスク化します。プロセスという活動のそれなりを占める部分がタスク管理上は表れていないので、タスク管理全体が形骸化します。

では、どのように対処していけばいいのでしょうか。まずは状況を整理します。

• プロセス活動
  • 1: 必要な部分
  • 2: 過剰な部分
• 3: 非プロセス活動

1: ～ 3: の三つがあります。3: は非プロセス活動なので割愛します。

1: は必要なのでちゃんとタスク化します。上記の例で言えば、タスク T を二つに分けてます。あるいは、プロセスを包含するタスク側でプロセス活動分も考慮しても良いです。例で言えば、4.5 時間で見積もってますよね。

2: は過剰なのでなくします。進捗の管理の項で加算方式を勧めましたが、似た発想をします。要らないものはとりあえずやめて、それで様子を見てください。問題が出たのなら、そのときにプロセスを追加すればいいのです。

私たちはビジネスの文脈だとなぜかやたらとプロセスを定めたがりますが、そんなことをしなくても行えるタスクは案外多いです。プロセスを定めるのは再現性が欲しいからであり、昔の工業的大量生産時代の名残ではありますが、本当に再現性は必要でしょうか。個人に任せて、やり方も任せて、結果をチェックする、ではダメなのでしょうか。プロセス至上という固定観念を一度取っ払って、冷静に「このプロセスは本当に必要なのか」と自問自答してみると良いでしょう。

なお、プロセスの管理でも邪悪な管理者は顔を出します。管理者としては「そのとおりに則っているかを見ればいい」というかんたんなお仕事で済ませられるので、しがみつく人は多いのです。自分の邪悪さに自覚がないこともあります。プロセスは正しいのだから当然ではないか、というわけです。プロセス原理主義 と呼ぶ人もします。法律でたとえてもわかりやすいと思います。法律は絶対的に正しいのだから当然でしょ、と。もっとも法律の場合は大まかな部分しか規定していませんし、個人で勝手に追加することもできませんが、プロセスは違います。管理者（あるいはその上位者）によってかんたんに追加できます。暴走化しやすいのです。自覚がないどころか、善意に基づいていることさえあります。地獄への道は善意で舗装されている、とはヨーロッパのことわざですが、まさにそうです。

プロセスの管理者の対処は、より困難を極めます。進捗の管理者と同様の難しさに加えて、上述のとおり法律のような信念もあるからです。事実上、不可能と言ってもいいと思います。できることは多くありません。管理者から離れるか、表向きは従うふりをするか、あるいは（より上位と組んだりチームで結託したりして）追放するかです。現代のセオリーでは管理の少ない仕組み（組織）を最初からつくる、かつそれを維持し続ける、が一つの解となっています。

まとめ:

• プロセスの管理はシャドータスク化しやすい
  • タスク = プロセス活動 + 非プロセス活動であり、どちらかがシャドーになる
• プロセス活動には必要な部分と過剰な部分があり、後者をいかに削れるかが重要
• 邪悪な管理者はここでも顔を出す
  • 法律を絶対視するかのような信念があり、なお手強い
  • 真面目に対処するなら、従うふりや追放など苛烈なものが必要

リソースの管理

リソースの管理 とは時間やお金を管理することです。活動には資源を消費しますが、資源には総量があるため使い切らないよう注視する必要があります。

タスク管理では「消費量を記録・申告させる」という形で表れます。タスクのページに「かかった時間」を書いておけとか、毎日どの仕事にどれだけ時間使ったか記録しておいて月一で提出しろとか、お金を使いたいならその前に承認依頼を出せ、残業したいなら事前に申請しろなどです。

これらもまたシャドータスク化、特にプロジェクトとは直接関係がないインダイレクトシャドーとみなされやすいです。要は時間にせよお金にせよ各個人が使うものなので、本人自身が把握して計上もしてね、となりがちなのです。この計上はビジネスではコンプライアンスにも絡んできますし、個人であっても生活の生死に関わってきます。信頼を測るバロメーターとしても見られるので、インダイレクトシャドーと言えど無闇に削れないのです。どころか「必要だから」と正当化されがちです。

では、対処としてはどうすればいいでしょうか。ここまでの繰り返しまたは応用になりますが、以下のとおりです。

• ちゃんとタスク化する
  • お金や道具や設備など、仕事として必要になるものの申請はわかりやすい
  • スポットで必要になるかもしれないものについては、事前にタスク化して「プール」しておき、使うときに持ってくる
• バッファやスラックを設ける
  • 各個人、必要な記録や申告があればここで吸収する
• 記録会や申告会を開催する
  • 打ち合わせの一種として「リソースの記録や申告を行う場」を設ける
  • この場では皆が手を止めて、記録や申告の作業に集中する
  • メンバーで集まると「あれ忘れてない？」「あれもあるよね」など補完しあえるので、後々のバタバタを未然に防ぎやすい
• 専任化する
  • 名前をつけるならリソースマネージャー、あるいはリソースウォッチャー
  • プロジェクト内のリソース管理に目を光らせたり、必要な手続きを行ったりする専任者
  • 業務は苦手だが、こういうフォローや雑務は好きという人が適任
• 自動化・省力化する
  • 特に記録は、人間がちまちま行うのは全くもって非生産的な営みなので、できれば自動化したい
  • そうでなくともできるだけ手間がかからないよう、必要最小限のプロセスで済ませたい
  • いわゆる IT、もっといえば DX の出番
    • 楽に行えるようなツールを使う、設計する、何ならつくる

社内システムがあるから大丈夫、経理部が居るから大丈夫といった話ではないことに注意してください。むしろ個人やチームといった小さな単位において、リソース管理がシャドータスクとして猛威をふるいがちだから対処しましょうね、という話です。

この他、リソースの管理自体も減らせるなら減らしたいです。

時間については、本当にバカ真面目に記録する必要があるのか、など再考の余地があります。プロセスを変える権限がなくても、運用面で工夫することはできます。あまりにひどいとコンプライアンスに反してしまいますが、そもそも数字で厳密に管理すること自体に無理があります。ただ、表向きはそんな事は言えないので、裏でうまくやるのです。逆に管理者が邪悪だと悪用されたりもします（たとえば残業を申告させずにサービス残業にする）し、現状は悪用面の方が蔓延りがちだと思います。

お金については、申告のプロセスを減らせる可能性があります。お金が大事なのはそうですが、だからといって無闇にプロセスを複雑にするのは典型的な管理脳です。近年では色々なやり方が開拓され始めており、たとえば以下があります。

• 誰でも無条件に使えるが、誰がいつ何のために何円使おうとしたかは全部見える（透明性）
  • 皆に見えているので悪さはできませんし、してもすぐわかります
• 各社員や各チームに自由に使えるお金やカードを支給する、あるいは立替精算できるようにする
  • 各人が有償のツール、特に SaaS を使うのに重宝します
• 承認者をランダムにする
  • たとえば金額に応じて n 人分、チームメンバーの誰かがランダムに承認者になる等
  • 承認者が管理者ひとりに集中してボトルネックになるのを防げます

Rate Limit（使える上限を設定しておく）と併用すると、なお効果的です。銀行でも上限引き出し額の設定ができますし、世間で話題の ChatGPT でも、プログラマー用の API は使った分だけ課金するモデルなのですが、誤って使いすぎて破滅しないよう課金額の上限を設定できるようになっています。プログラムはループ構造をつくって一秒に何万回リクエストする、なんてこともかんたんにできますので、トークン（使用時に使うパスワードなるもの）が漏れると悪用されて使われまくります。「40000 ドル請求が来てるんだけど……」なんて事故が起こり得るのです。しかし上限が設定されていると、上限以降はエラーになってそれ以上進まないので事故は起こりません。最近ではさらに改善されて事前購入制（50ドル買ったとしたら50ドル分しか使えない、それ以上は再び購入が必要）になりました。

と、少し話が逸れましたが、工夫は意外とできるのです。リソース管理というと、時間やお金を扱うという性質上、つい絶対視して過剰に管理しがちですが、本当にそこまで必要なのかを見直して、上手く融通を利かせてください。

まとめ:

• リソースの管理は、時間やお金の記録や申告という形でシャドータスク化する
• 対処としては、ここまで挙げてきた内容の応用
  • シャドータスクをちゃんとタスク化する
  • バッファやスラックを設けて個別に対処
  • 専任化、自動化と省力化 etc
  • また記録会や申告会など、リソース管理用の場を設けるのもアリ
• そもそも管理自体も減らしたい
  • 時間については、記録の手間を減らしたい
  • お金については、申告の手間を減らしたい
  • いずれにせよやり方は色々ある

専有の管理

専有の管理 とは人を人質のように管理することです。別の言い方をすると「物として所有する」とも言えます。物は全面的に所有者のものであり、物の事情は考えません。そもそも物に意思などありません。物は所有者がいつでも好き勝手できるように、所有者の手元に置いておくと便利です――と、このような発想を人に適用したのが専有です。私物化と言っても差し支えありません。

私たちは何かと専有されがちです。私生活でも束縛がきつい、門限、過保護といった言葉がありますし、仕事では言わずもがな会社が従業員を専有します。この専有ですが、さすがに現代では本当に物のように、たとえば奴隷のように扱われることは通常ないでしょう。代わりに規則と場をつくって、それに従わせようとします。専有の特徴は拘束であり、時間と場所を拘束してきます。典型的なサラリーマンやアルバイトには就業時間がありますし、店舗やオフィスへの出社も義務付けられます。何を当たり前のことを……、と思うかもしれませんが、そもそも拘束とは絶対的に必要なものでしょうか。答えはノーです。特に最近ではパンデミックの影響でリモートワークが加速し、出社しなくて仕事が通用することは広く知られてきました。現地での対応が必要な仕事もまだまだ多いですが、今後技術や方法論の発展につれて減ってくるでしょう。

専有とは拘束であり、拘束にはコストがかかりますが、タスク管理ではここが計上されません。つまり専有に絡む行動がタスク化されておらず、しかし必要なことなので各自対応している――というわけで、ここもシャドータスク化しています。通勤とサービス残業の話はすでに述べましたが、通勤とはまさに専有を満たすためのシャドータスクです。

タスク管理が上手くいかない、特に思ったように消化されないときは、実は専有が足を引っ張っていることも多いです。あえて強調しますが、専有は思っている以上に足を引っ張っています。通勤はわかりやすいですが、他にもあります。道具や設備が一つしかなくてそこに集まらないといけないとか、定例会議や重要イベントが設定されていて事実上集まらないと排斥されるなど、拘束が求められるシチュエーションはそこかしこに転がっています。一つ一つは軽微でも、積み重なるとかなりの負担になります。拘束という言葉がわかりづらければ「予定」と言い換えても構いません。仕事の名目でやたら拘束されるという現実は、いわばやたら予定を組まれることにも等しい。日常生活で言えば一日に何人もの人と会ったり、旅行のスケジュールを過密にするようなものです。移動時間だけでも相当費やしていますし、何より疲れますよね。それと同じことが平然とまかり通っています。さらに厄介なのは人が社会的動物であり、一緒の場を過ごすだけで満足してしまう生物であることでしょう。要は仕事した気になりやすいのです。専有のコストがかなりかかっているにもかかわらず。

では、専有にはどう対処すればいいでしょうか。

まずはシャドータスクの対処と同様、キャパシティベースによる無理のない見積もりと、バッファとスラックによる余裕の確保は使えます。

しかし、専有は思っているよりも蔓延っており放置していると辛いですし、勝手にはなくならないので、意識的に減らしていくことこそが重要です。そのためには「拘束せずに働くには？」「拘束せずにタスクをこなすには？」を考えなくてはなりません。拘束に抗うあり方を 脱拘束 と呼ばせてください。専有に対処するには脱拘束を目指したい。

では脱拘束には何が必要でしょうか。方法論とツールです。たとえばリモートワークも、それを行うためのやり方と道具がなければやりようがありません。知識を知らないと始まらないのと一緒で、無知の中で自ら編み出すのは現実的ではありません（そもそもそんなことにたっぷり費やせる時間がありません、ないしは与えられません）。脱拘束は、これだけで本を何冊も書けてしまうほどボリューミーなものですが、いくつか紹介します。

• 非同期コミュニケーション
  • お互いがお互いの時間を専有して、リアルタイムにやりとりするコミュニケーションは「同期的」
  • 一方、手紙やメールやチャットなど、各自のペースで読み書きするコミュニケーションは「非同期的」
  • 脱拘束には後者の非同期的なやり方が必要になります。脱拘束は非同期的なやり方をどれだけ採用できるかがすべてです
  • 現代ではまだまだ同期的なやり方が主流であり、「リアルで顔を合わせて喋れないと仕事にならないでしょ」と考える人も多いです、それほどに難しい
• QWIC
  • 非同期コミュニケーションの主なあり方の総称
  • Q&A、Wiki、Issues、Chatの略です
  • Chat（チャット）については Teams など、リモートワークの必須ツールとしてご存知の方も多いと思います
  • Wiki（ウィキ）は Wikipedia やゲーム攻略ウィキなどで知っている人も多そうですが、チャットよりも情報を整理・検索しやすいです
  • Issues（イシュー）は GitHub Issues などのことで、1 話題 1 ページで話題ごとに独立して議論を行うスタイルに適しています
  • Q&A は Q&A サイトのことで、Yahoo!知恵袋、教えてGoo、Stack OverFlow や Quora など Web サービスとしてはよく知られており、質疑応答スタイルのコミュニケーションに特化します
• Communication Injection/コミュニケーションの注入
  • 私達は人間なので非同期的なやり方だけだと足りません。欲求不満で耐えられませんし、信頼関係や親近感も育みにくい
  • なので、脱拘束とはいっても、従来の同期的なコミュニケーションも意識的に差し込む必要があります
  • つまり、以下のように考えます
    • ❌同期コミュニケーションのみ
    • 🔺同期コミュニケーションがメイン、非同期はサブ
    • ⭕非同期コミュニケーションがメイン、同期はサブ
  • 非同期的なやり方がメインという前提で、同期的なコミュニケーションを 必要に応じて注入する と考えます
• 個人タスク管理
  • 脱拘束が進行すると、各人には自律性が求められます
    • 言われないと動けない人や、場の雰囲気に流されることを生業とする人には務まりません
  • 気合で何とかなるものではなく、やり方や考え方の工夫が必要です
  • 実はこれは仕事から私生活まで、個人の行動をいかに上手くやるか――個人タスク管理と同義です
    • 余談ですが、本書はまさにこの個人タスク管理を扱おうとしています

本書でも何度か言及した DX――デジタルトランスフォーメーションは、私達のあり方をデジタルの流儀に合わせるというものです。同様に、脱拘束についても、私達のあり方を非同期コミュニケーションに合わせます。そこまでしなければ脱拘束、もっと言えば専有の軽減はできません。しかし、これができたら、専有にかかっていたコストがかなり浮きます。実際にリモートワークができている企業では、各人はライフをしっかりと担保しつつワークも行えていると思います。それで業績を伸ばしている企業も少なくありません。

一方で、GAFAM など名だたる企業でも出社に回帰する動きは珍しくないように、脱拘束は取り組み続けるのが難しい営みでもあります。そもそも方法論からして、あまり盛り上がっていません。上記の QWIC と Communication Injection は筆者の造語です。筆者が造語できてしまうほどに未開拓な領域なのです。もちろん、世界中で全くないかと言われるとそうでもなく、高度に脱拘束できている組織やチームも珍しくはありません。ただ一般層だったり大きな組織への適用だったりという文脈では、正直まだまだだなという印象です。

筆者としては生成 AI が台風の目になると考えています。非同期コミュニケーションは「読み書き」が大変ですが、生成 AI は要約や翻訳が得意なのでカバーできます。自分のコンテンツを学習させたり、音声や映像もつくれたりするので、将来的には疑似人格もつくれるでしょう。A さんと打ち合わせするのではなく、A さんの AI 疑似人格と打ち合わせをする、のような未来もありえると思っています。よく「人は人と直接会って話したい生き物なので同期コミュニケーションはなくならない」という人がいますが、別にゼロにする必要はなくて、適度に注入すれば事足ります。それよりも私たちは自分の生活（ライフ）が大事であり、すでにライフを重視・尊重する潮流は来ています。何なら水準も上がっています。特にパンデミックによるリモートワークがこれを後押ししました。そもそもライフのあり方は人それぞれですから、専有とは合わず、非同期コミュニーションは必然なのです。奴隷が当たり前だった時代はなくなりました。現代は奴隷ほどひどくはありませんが、拘束という意味ではひどいままです。今は単に手段がないから同期的なやり方に頼っているだけですが、上記でも軽く触れたように手段はもうあります。この先、手段がさらに整備・啓蒙されれば、非同期にシフトしていくことは避けられないと思います。大胆に言えば、現代人が拘束から解放される動きがこれからおこっていくと思っています。

と、脱拘束の話が盛り上がってしまいましたが、お許しください。専有の軽減には脱拘束が必要ですが、脱拘束という考え方はまだまだ難しい（というより自覚や馴染みがなくてとっつきづらい）ため、意図的に紙面を割かせていただきました。他にも専有を軽減するあり方や、そもそも専有を容認する潮流もありえるかもしれませんが、本書の範囲を越えるため割愛します。

まとめ:

• 私たちは専有を管理されている――時間と場所を拘束されがちである
• 専有には思っている以上に足を引っ張られているが、タスク管理上は出てこないので気づきにくい
• 専有に対処するにはシャドータスクの対策が有効だが、それ以上に専有自体を減らす脱拘束が必要
• 脱拘束という営みは難しい
  • 難しいが、できないことはなくて、手段の目処はついているし事例もある
  • 特にリモートワークは脱拘束の好例
  • 筆者の予想（そして願望でもあるのですが）では、今後盛り上がることは避けられないと考える

まとめ

• プロジェクトタスク管理の本質は 3A
  • Assign アサイン、人にタスクを割り当てる
  • Adjust 調整、タスクの属性値を変える
  • Alternate 全体と詳細、タスク全体の状況を眺める（俯瞰）と特定のタスクの詳細を見る（注視）の行き来
  • これらを上手くやれればそれでいいし、やれるなら別に管理は要らない
• 俯瞰と注視をどれだけ行えるかはツールの能力であり、段階がある
  • Alternate モデル、計 4 段階
  • タスク管理ツールを使う段階はレベル 3 であり、キャズム（深い溝）が存在するほど難しい
  • つまりプロジェクトタスク管理は成立そのものが難しい営みである
    • 実際に結局成り行き任せのコミュニケーション過多で何とか乗り切るという原始的なスタイルになりがち
    • DX と同様でツールをちゃんと使う、そのやり方や考え方に自分たちが合わせるといった姿勢のシフトがそもそも必要
• 俯瞰を行うためのビューにも種類があり、一長一短である
  • リスト（一覧）、テーブル（表）、ボード、チャート、ネットワーク、センテンス（文章）など
  • 後ろに行くほど後発だが学習コストも高い、またネットワークとセンテンスは事例自体が無いか少ない
  • 現状無難なのはテーブルであり、まずはテーブルで上手くまわすことを目指したい
• タスク管理に計上されない隠れタスク「シャドータスク」が存在する
  • 対処としてはキャパシティベース、バッファとスラック、シャドータスクをちゃんとタスク化して管理する等がある
• プロジェクトタスク管理は、実は周辺の要素の管理もしてしまっている
  • 進捗、質、プロセス、リソース、専有
  • しかしこれらはタスク管理としては計上されない（シャドータスク化している）
  • 管理も過ぎれば毒、意識的に減らしていく努力が必要