八百茄子 は ソフトウェアエンジニア１名による小さな工房です
週末に スキルアップ と 八百茄子 向けのコンテンツ作成に勤しんでおります
ご提供コンテンツ
tools にて
八百茄子 の作成したツールをご紹介しています
knowhow にて、
2x年の組込み系ソフトウェア開発エンジニアとして得た知識・ノウハウに
7年以上 管理職を務めてて得た知識・ノウハウ、
個人開発（ぺーぺー）で得た知識・ノウハウを記録・共有します
エンジニアは技術が命
技術を磨いて、実績を積み上げて、自身の市場価値を高めていきましょう！！
得られた経験やアウトプットしたコンテンツで
みなさまの誰か一人にでも喜ばれる何かができたらいいな、と思います (・∀・)
子どもたちの未来が少しでもよりよいものとなりますように (*´ω｀*)
よろしくお願い致します (´・ω・`)
タスク管理がうまくいかないとき、原因は「やる気」や「根性」が足りないからではないです
本当の原因は たいてい次のどれかに集約されます
問題は 仕事が “管理できる形” になっていないこと になります
私がタスク管理で大事にしているのは、次の ７つ です。
この記事では この７つをひとつの流れ として整理します
タスク管理で最初にやるべきことは 仕事をそのまま管理しようとしないこと になります
例えば、こんな言葉はよく使われます
でも、これらは実際にはタスクではなく 仕事の塊 です
このままだと、
という状態になります
そこで必要になるのが WBS（Work Breakdown Structure） です
WBS とは、ひと言で言えば、
大きな仕事を、管理できる単位まで分けること
です
たとえば「Windowsツールを作る」なら、こんなふうに分けられます
これだけでも、かなり見通しが良くなります
タスク管理は、
「仕事を前に進めるために、まず分けること」
から始まります
WBSで分けるときに大事なのが 抜け漏れとダブりを減らすこと になります
ここで役立つのが MECE（Mutually Exclusive, Collectively Exhaustive） という 「漏れなく、ダブりなく」 という考え方です
難しそうに聞こえますが、実務ではとてもシンプルです
たとえば「ツールを完成させるために必要な作業」を考えるとき、
ただ思いつきで並べるのではなく、切り口を分けて整理します
例：
こうして分類しておくと、
といった、ありがちな漏れを防ぎやすくなります
タスク管理で怖いのは 「見えていない仕事」、「担当者が割り当たっていない仕事」 ですMECE はその見えていない仕事をあぶり出すための考え方です
分割してタスク管理項目に入れることは面倒な作業かもわかりませんが、
とても重要ですので、必ず MECE でタスク分割をしましょう
WBS で分けても、まだタスクが大きすぎることがあります
例えば
これでも まだ数日〜数週間 かかるかもしれません
ここで私が大事にしているのが、１週間程度で終わる粒度まで分けること です
なぜ１週間程度が良いのかというと、理由は３つあります
１カ月タスクだと、「今どこまで進んでいるか」が曖昧になります
でも１週間タスクなら、進んでいるか遅れているかがかなり明確になります
タスクが大きいと、問題の発見が遅れます
１週間単位なら、「この切り方は無理だった」「想定より重い」に早く気づけます
現実の仕事は 予定どおりに進まないのが普通です
だからこそ、細かく分かれている方が、後から組み替えやすいです
ポイントは 「終わった／終わっていない」が明確に言えるか です
タスク管理では 曖昧な完了条件のタスクが一番危ない です
終わっている／終わっていないが明確にわかることでどこまで進捗しているかも見やすくなります
タスクを終わらせることは達成感を生むことができて、次々のタスクを進めやすくなります
タスク管理では、締切（終了日）ばかりが注目されがちです
もちろん終了日は大事ですが、実際に仕事が進むかどうかを左右するのは 「いつ終わるか」より「いつ始めるか」 です
だから私は、各タスクに
を入れることを大事にしています
そして特に重要なのが 「着手日にちゃんと着手すること」です
タスクが遅れる原因の多くは、見積もりのミスよりも、
といった、着手遅れです
例えば ３日で終わるタスクでも、
となれば、見積もり自体は正しくても、全体は遅れます
つまり、終了日だけを見ていても 遅れの本当の原因は見えない ことが多いです
開始日を設定し、その日に着手することを意識すると、タスクは「いつかやるもの」ではなく、
「その日に始める予定のもの」
になります
これだけで、計画の実行力がかなり変わります
また、着手日が明確だと、
も見えやすくなります
タスク管理は 締切管理ではなく、着手管理でもある と考えましょう
タスク管理で特に危険なのが
中身が曖昧なタスクを、そのまま実行タスクとして置いてしまうこと
です
例えば こんなタスクです
こうしたタスクは必要ですが、そのままだと
という問題が起きます
こういうときに私がやるのは まず 「明確にするためのタスク」、「明確になったあとに分割するタスク」 を作ること です
例えば
などです。
そしてそのあとに、
という流れにします
つまり、
不明なものは、いきなり作業せずに、まずは “分かる状態にする仕事” に変える
ということです
計画を立てるときにありがちなのが、
まだ分かっていないのに、分かっている前提でスケジュールを引いてしまうことです
でも現実的なタスク管理は、むしろ逆で、
を分けて扱う方が強いです
不確実性を隠すのではなく、 不確実性そのものを管理対象にする ことが大事です
タスクを分けて、日付を入れただけでは、まだ足りません
なぜなら、仕事は 個々のタスクの集まり ではなく、順番・依存関係・重なりを持った流れ だからです
そこで有効なのが ガントチャートによる視覚化 です
ガントチャートの本当の価値は スケジュールを図として並べることではなく、
「どこが危ないか」「どこが危なくなるか」を見える状態にすること
にあります
たとえばガントチャートにすると、次のようなことが見えます
つまり、ガントチャートは単なる予定表ではなく 進捗・リスク・課題を可視化するための道具 です
進捗管理というと、「遅れていないか監視するもの」という印象を持たれがちです
でも本来の目的はそうではなく、問題が大きくなる前に気づける状態を作ること にあります
進捗管理で見るべきなのは、単なる完了率ではなく、
といった、将来の遅れにつながる兆候 です
見える化の目的は、「管理している感」を出すことではなく、早めに手を打てるようにすること です
タスク管理を本当に機能させるために、私はもうひとつ大事だと思っていることがあります
それが 日々、状況やログを記録すること です
計画を立てるだけでは、現実の仕事には勝てません
実際の現場では、
といったことが普通に起きます
だからこそ その日の状況を、関係者が見れるところに、わかるように、残しておくこと がとても重要です
日々の記録があると、急に誰かが入ってきても、
が伝えやすくなります
つまり、ログは単なるメモではなく、「途中からでも状況を理解できる状態」を作るもの です
これは個人作業でも、チーム作業でもかなり効きます
もうひとつ大きいのが 後から振り返りに使えること です
例えば ログがあると、
が見えてきます
これがないと、振り返りはどうしても
で終わってしまいます
でもログがあると、感想ではなく、事実ベースで改善できる ようになります
将来に多様な仕事があったときに、過去の作業ではどうしていたか、これを知れることは大きな財産となります
これは意外と大事ですが、ログは 「自分が何をやっていたか」を守る記録 にもなります
特に、割り込みが多い仕事や、見えにくい調整業務が多い仕事では、
が、後から説明できることが重要です
ログは単なる管理のためではなく 実態を見えるようにするための記録 でもあります
ここまでの内容をまとめると、私が考えるタスク管理の本質は次の通りです
仕事の塊を、そのまま管理しない
管理できる単位まで分解する
抜け漏れ・ダブりを減らし、見えていない仕事をなくす
進捗確認・遅延検知・再計画がしやすくなる
特に大事なのは、着手日に着手すること
「いつ終わるか」だけでなく、「いつ始めるか」を管理する
曖昧なものをそのまま実行しない
まずは「分かる状態にする仕事」に変える
進捗・依存関係・リスク・課題を見える状態にする
急なヘルプや引き継ぎに対応しやすくなり、後から振り返りや改善にも使える
つまりタスク管理とは、単なるToDoリストではなく、
仕事を前に進めるための「設計」と「運用」の仕組み
だと思っています
仕事が詰まるとき、原因は「頑張りが足りない」ことではなく、
たいてい 仕事が見える形になっていないこと です
逆に言えば、
この状態が作れれば、仕事はかなり前に進みやすくなります
私は、タスク管理は「管理のための管理」ではなく、
実際に仕事を進めるための設計図であり、運用の土台
だと考えています
もしタスク管理がうまくいかないと感じているなら、
まず見直すべきは根性ではなく、仕事を “見える状態” にできているかどうか かもしれません
この記事がみなさまの仕事にお役に立てたら幸いです