大きなプロジェクトを小さなタスクに分解する方法

「ECサイトを作る」「モバイルアプリを作る」「論文を完成させる」これらはタスクではありません。成果物です。そして成果物は、今何をすべきかを教えてくれるものとしては最悪です。 プロジェクトが大きくて抽象的すぎると、脳はどこから始めればいいかわかりません。だから自然なことをします：何もしない。先延ばしにして、罪悪感を覚え、さらに先延ばしにする。最初のステップが不明確だからプロジェクトは停滞したままです。

良いタスクとは、約2時間以内に完了できるものです。それ以上かかるなら、大きすぎるのでさらに分解する必要があります。 「認証システムを構築する」は大きすぎます。次のように分解しましょう：「サインアップフォームを作成」「メールバリデーションを追加」「ログインエンドポイントを構築」「セッション管理を設定」「パスワードリセットフローを追加」それぞれ1セッションで完了でき、明確な終了点があります。

完成品を考えてみましょう。完成したらどう見えますか？そこから逆算します。 主要な部分は何ですか？おそらくフロントエンド、バックエンド、データベース、デプロイでしょう。各部分の中で、機能は何ですか？各機能の中で、個別のタスクは何ですか？ 基本的にツリーを構築しているのです。プロジェクトが幹、主要部分が枝、機能がより小さな枝、タスクが葉です。作業するのは葉だけです。

タスクができたら、カンバンボードに並べましょう。30個の小さなタスクを見る方が、1つの巨大なプロジェクトを見つめるよりずっと怖くありません。そして「完了」にカードを動かすたびに、小さな達成感を得られます。 これらの小さな達成感は積み重なります。1週間後、完了列を見て、本当に進歩したことに気づきます。不可能に思えたプロジェクトが今は20%完了し、その勢いが前に進む力になります。

よくある間違いは、始める前にすべてのタスクを計画しようとすることです。それは分析麻痺の変装です。 次の1〜2週間分のタスクを十分に分解しましょう。作業を始めてください。進めるうちに予想しなかったタスクが見つかります。出てきたら追加してください。計画は生きたドキュメントであるべきで、厳格な設計図ではありません。 目標は完璧な計画ではありません。目標は次に何をすべきかを知ることです。明確な次のタスクがある限り、進歩しています。