複業エンジニアのタスク管理｜Notion・Togglで本業と両立する設計術

複業エンジニアとして副業を2〜3件抱えるようになると、「今日はどの案件のどこから手をつけるべきか」が分からなくなる瞬間が訪れます。Notion・Linear・Slack・Togglを行き来して迷っているうちに、平日夜の作業時間は20〜30分削られていきます。

この立ち上げコストの正体は、案件ごとにツールも思考モードも異なる複業特有の「コンテキストスイッチ」です。総論として「両立のコツ」を読んでも、自分のワークスペースに落とし込む段階で手が止まります。

本記事では、Notionを司令塔・Toggl Trackを時間記録・Linear/Jira等を実行レイヤーとして役割分担し、1つのダッシュボードに集約する具体的な運用設計を紹介します。想定読者は、本業を持ちながら副業案件を並行して進めているWebアプリケーションエンジニアで、各ツールの基本操作は理解しつつ「複業特有の運用設計」が確立できていない段階を想定しています。

読み終えたあとには、毎朝ダッシュボードを開けば今日着手すべきタスクが1画面で把握でき、Togglのタイマーをワンクリックで開始でき、月末の請求集計が自動化された状態へ近づくための、具体的なDB構造・テンプレート・運用ルールが手元に残ります。なお、時間捻出そのものの考え方は正社員エンジニアの副業時間管理術に整理してあるので、合わせて参考にしてください。本記事はその「具体ツール設定編」として位置付けています。

複業エンジニアのタスク管理が破綻する3つの典型パターン

複業のタスク管理が機能しなくなるとき、症状はばらついて見えても、根っこは似た構造に行き着きます。

パターンA「ツールが分散して、毎晩どこを開くか分からない」

本業のチケットはJira、副業AはNotion、副業BはLinear、コミュニケーションはSlackとChatworkで分散している。こうした状態では、平日21時に作業を始める際、まずどのツールから開くべきかを毎晩判断することになります。各ツールを開いて未読を見て頭の中で優先度を比較するだけで10〜20分が消え、月20営業日で5時間のロスになります。

パターンB「稼働時間の記録が雑で、月末の請求作業が苦痛」

タイマーは回しているが「副業A」「副業B」程度の分類しかしていないと、月末に「この時間は副業Aのどのタスクか」を思い出すためにSlackやNotionの履歴を遡る作業が発生します。複業は案件ごとに単価も契約形態も違うため、記録の精度が直接報酬に直結します。

パターンC「本業の頭のまま副業に入って、手が止まる」

本業を18時に終え、20時に副業のエディタを開いても、頭の中はまだ本業のミーティングで議論していた仕様の細部に占領されている。Notionを開いても着手先が定まらず、結局1時間ほどコードを書き始められない。これはツールではなく「思考モードの切り替え」の問題です。

共通する根本原因は「コンテキストスイッチコスト」

3パターンの本質はすべて同じで、コンテキストスイッチ後に集中状態へ戻るまでには時間がかかることに由来します。代表的な研究として、カリフォルニア大学アーバイン校のGloria Mark教授らの研究「The Cost of Interrupted Work: More Speed and Stress」では、業務中の作業中断後に元のタスクへ復帰するまでに相当な時間を要し、その間に作業スピードは上がるものの、ストレスと疲弊が増大することが示されています。

複業エンジニアの場合は「ツール切替」「クライアント切替」「思考モード切替」が三重で発生します。ツール選び以前に、コンテキストスイッチを最小化する運用設計を持つことが、複業を持続可能にする土台になります。

複業エンジニアの案件管理ダッシュボード設計の全体像

具体ツールの設定に入る前に、設計思想を整理します。機能ではなく役割で道具を割り当てるのが起点です。

3層構造（司令塔 / 時間記録 / 実行レイヤー）の役割分担

この3層を意識する利点は、「副業先のツールを自分のNotionに統合しようとして破綻する」失敗を未然に防げる点です。実行レイヤーは副業先のものをそのまま使い、Notionはそこへのリンクの集約点として機能させます。

なぜ「Notion 司令塔」を中心に据えるのか

司令塔のツールに求められる条件は、(1) 複数のDBを連動できる、(2) ビューやフィルタを柔軟に作れる、(3) 横断検索できる、(4) ページ本文に自由なメモや週次レビューを書き込める、の4点です。Notionはこれらを満たし、テンプレートをコピーしてDB構造ごと再利用できるため、案件増減時の運用変更コストが低く済みます。代替としてCodaやObsidianも考えられますが、本記事では普及度・テンプレート資産・モバイル対応を踏まえてNotionを前提に進めます。

案件追加・終了時のダッシュボード更新フロー

複業の案件は半年〜1年単位で入れ替わるため、終了案件の残骸が司令塔を汚染しないよう、最初に運用ルールを決めておきます。

• 案件追加時: 案件マスタDBに1行追加 → Toggl の Client / Project を新規作成 → タスクDBに「キックオフ」タスクを1件登録
• 案件終了時: 案件マスタDBのステータスを「終了」に変更 → 関連タスクをアーカイブビューに退避 → Toggl の Project は「Archive」に移動
• 案件保留時: 案件マスタDBのステータスを「保留」にし、フィルタで「今日やること」ビューから自動除外

Notionで作る複業エンジニアの案件管理ダッシュボード

ここからが本記事の主役です。Notion上に「案件マスタDB」「タスクDB」「日次サマリーページ」の3つを連動させ、毎朝の判断コストをゼロに近づける設計を解説します。

案件マスタDBの作り方

案件マスタDBは、副業案件を1行=1案件として管理する「正本」のDBです。

「単価」「契約形態」をDBに入れておけば、月末の請求書作成時にこのDBを参照するだけで請求金額が確定します。

タスクDBの作り方

タスクDBは1行=1タスクで、全案件のタスクを横断的に管理します。案件マスタDBとRelationプロパティで連結することで、「副業Aのタスクだけ」「優先度の高いタスクだけ」といったビューを柔軟に作れます。

ポイントは、ステータスをNotion側で完璧に同期しないことです。副業先がLinearを正本としている場合、Notionの「ステータス」は自分の作業実態（着手したか、自分の手を離れたか）だけを管理し、副業先のレビュー進捗まで反映させようとはしません。

「今日やることビュー」の作成

ダッシュボードの中核がこのビューです。次のフィルタ・ソート設定で作成します。

• フィルタ1: ステータス が 未着手 または 進行中
• フィルタ2: 着手予定日 が 今日まで（または 締切 が 7日以内 のOR条件）
• フィルタ3: 案件マスタDBの ステータス が 進行中 の案件に紐づくタスクのみ
• ソート: 優先度（高→低） → 締切（昇順）
• 表示プロパティ: タスク名 / 案件名 / 優先度 / 締切 / 想定稼働時間 / 副業先チケットURL

このビューを作っておけば、平日夜にNotionを開いた瞬間、上から順番に片付けるだけになります。「どれをやるか」を考える時間をほぼゼロにできます。

週次レビューページのテンプレート

GTD（Getting Things Done）のウィークリーレビューを複業向けに絞り込むと、次の5項目に集約できます。Notionのテンプレートボタンで「新規ページ」テンプレートとして登録しましょう。

## 週次レビュー（YYYY-MM-DD）

### 1. 今週の稼働実績（案件別）
- 副業A: <Togglから転記> h（請求対象）
- 副業B: <Togglから転記> h（請求対象）
- 学習: <Togglから転記> h（請求対象外）

### 2. 月間稼働上限の進捗
- 副業A: 当月累計 X / 上限 Y h

### 3. 完了タスク（案件別）

### 4. 未完了タスクの再見積もり
- タスク名: 当初見積 X h / 実績 Y h / 持ち越し可否

### 5. 来週の最重要タスク（各案件1つ）
- 副業A: <タスク>
- 副業B: <タスク>

これを毎週日曜夜に10分書く習慣を持つだけで、月末の請求作業が半分完成した状態になります。

Toggl Trackで稼働時間を記録し、月末の請求作業を自動化する

Notion司令塔が「何をやるか」なら、Toggl Trackは「実際にどれだけ時間を使ったか」の記録レイヤーです。複業エンジニアにとっての設計の肝は、Client / Project / Tagの3階層を正しく使い分けることに尽きます。

Client / Project / Tag の使い分け

Tagは次のようなネーミングルールが扱いやすい例です。

請求関連:
  billable        … 請求対象の作業
  non-billable    … 学習・自主調査など請求対象外

作業内容:
  dev             … 実装・コーディング
  mtg             … MTG・オンライン打ち合わせ
  research        … 仕様調査・ドキュメント読解
  review          … コードレビュー対応

タスク紐付け:
  task-<NotionタスクID>  … NotionタスクとTogglエントリの紐付け

billable / non-billable を必ず付ける運用にすると、後述する月末の請求集計が一発で終わります。

Notion タスクと Toggl エントリを紐づける運用

Notionタスクに独自IDを振り、TogglエントリのタイトルまたはTagに含めるのが最も軽量な紐付け方法です。

[副業A] ユーザー登録画面のバリデーション実装 #A-0123
  Project: 副業A：個人開発SaaSのフロント支援
  Tags: billable, dev, task-A-0123

この命名規則を守れば、Toggl Reportsで task-A-0123 タグでフィルタするだけで、当該タスクの合計稼働時間が把握できます。週次レビューで「想定 vs 実績」の乖離を点検する材料にもなります。

月末の請求書作成までのレポートエクスポート手順

月末の請求集計は次の3ステップで完了します。

1. Toggl Reports → Summary を開く
2. 期間を「前月」、Client（または Project）でグルーピング、Tagフィルタで billable を選択
3. CSVエクスポート → スプレッドシート/請求書ツールに貼り付け

Notion案件マスタDBの「単価」「単価単位」と突き合わせれば、請求金額が自動算出できます。

「請求対象外」工数の見える化で稼働実態を把握する

non-billable タグで学習・調査・コードリーディングの時間を切り分けて記録しておくと、実際の稼働は請求時間より2〜3割多いケースが珍しくないことに気付きます。この可視化は、(1) 単価交渉の根拠、(2) 学習時間の整理、(3) 案件継続の判断、のいずれにも材料を供給します。

副業先が指定するツール（Linear / Jira / GitHub Projects）との付き合い方

副業案件では、副業先が自社のチケット管理ツールを指定するケースが多くあります。これらを無理にNotionに統合せず、役割を絞った連動に留めるのが破綻しない設計です。

Linear / Jira / GitHub Projects 別の連携運用パターン

二重管理を避ける原則

副業先ツールを使う際に最も避けたいのが、Notion側にステータスを詳細に書き写す二重管理です。原則は次の2点に集約されます。

• 副業先ツールが正本となる項目（ステータス・コメント・レビュー進捗）はNotionに転記しない
• Notionには「自分の作業状態（着手予定日・優先度・自己ステータス）」だけを置く

副業先のチケット詳細を確認したいときは、Notionの「副業先チケットURL」をワンクリックで開く運用に徹します。

副業先ツールの通知設定の絞り込み

本業中にSlackやLinearの通知が鳴ると集中が切れます。実際には「自分宛のメンション」「自分が担当者のチケット更新」だけ通知が来れば十分です。

• Slack: 副業先ワークスペースは Direct messages, mentions & keywords only に設定
• Linear / Jira: 自分にアサイン or メンションされた変更のみ通知
• GitHub: Participating and @mentions に統一
• メール: 副業先ドメインの自動通知は専用フォルダに振り分け、1日2回まとめてチェック

通知を絞ったぶん、決まった時間（朝・昼休み・本業終了後）に副業先の動きをまとめてキャッチアップする運用にシフトします。

本業と副業の切り替えを最小化するデイリースタートルーティン

ツール設計が整っても、毎晩のセッション開始時に「何から始めようか」と考え込んでいては、コンテキストスイッチコストは下がりません。判断ではなく手順でセッションに入る設計をルーティン化します。

平日夜セッションの5ステップ

平日夜21時から作業を始める前提で、次の5ステップを「儀式」として固定します。

1. Notionの「今日やることビュー」を開く（10秒）
2. 最上段のタスクを1つ選び、本文を開いて副業先チケットURLをクリック（30秒）
3. Togglのタイマーを開始（Project = 該当案件、Tag = billable / dev 等を選択、10秒）
4. 副業先のチケットを画面の半分に、エディタを残り半分に配置（1分）
5. 25分の作業ブロック（ポモドーロ）に入る

2分以内にコードを書き始められる状態を目指します。慣れたら無意識に流れるようになります。

土日セッションの組み立て

土日は長く時間が取れるぶん、複数案件をまたいで作業すると生産性が落ちます。1日を2〜3ブロックに区切り、各ブロックは1案件に専念するのが鉄則です。

ブロックの切り替え時には、後述する「3分シャットダウン」を必ず挟みます。家事や子育てとの両立については、育児中のフリーランスエンジニアの両立術も合わせて参考にしてください。

本業から副業に切り替える前の「3分シャットダウン」習慣

本業18時から副業20時まで2時間あっても、本業の頭のまま副業に入ると最初の30分を失います。これを防ぐのが「3分シャットダウン」です。

• 1分目: 本業Slackの自分宛未読を既読化、明日朝の「再開メモ」を1行残す
• 2分目: 本業のブラウザタブを全部閉じ、副業用ブラウザプロファイルに切り替え
• 3分目: Notionの「今日やることビュー」を開き、最初のタスクを1つ口に出して読む

3分目の「声に出す」が脳のモードを「本業の続きを考える」から「次のタスクを実行する」に切り替えるアンカーになります。

ChatGPT・Claudeで複業のタスク整理を加速する活用法

最後に、AIツールを「思考コストの外注先」として位置付ける使い方を紹介します。コンテキストスイッチで疲弊した脳の代わりに、AIに整理役を担ってもらう発想です。

週次レビューでのAI活用

週末に作業メモがSlackや作業ログに散らばっている状態は、複業ではよくあります。次のプロンプトでClaudeやChatGPTに整理してもらうと、週次レビューの土台が15分でできます。

以下は、副業A・副業Bの今週の作業メモです。これを以下のフォーマットで整理してください。

【出力フォーマット】
1. 案件別の完了タスク一覧
2. 未完了タスクと持ち越し理由
3. 来週の最重要タスク候補（各案件1つ、根拠付き）
4. 想定稼働時間と実績稼働時間の乖離が大きいタスク

【作業メモ】
（ここにSlack発言、Notionデイリーログ、コミットメッセージ等を貼る）

完成形をいきなり求めず、たたき台を作ってもらってから自分で微修正するスタンスが扱いやすいやり方です。

仕様書・要件定義の要約と Notion への取り込み

副業先から渡される仕様書PDFや要件定義書をAIに次の観点で要約させると、Notionへの取り込みが楽になります。

以下の仕様書を、エンジニア視点で次の観点で整理してください。

1. 実装すべき主要機能（箇条書き）
2. 想定される技術的な論点・確認すべき事項
3. 不明点・前提が曖昧な部分（クライアントへの確認候補）
4. 想定工数の粗い見積もり（小・中・大の3段階）

出力はそのままNotionタスクDBに転記できる粒度になります。AIの読み違いは混じるため、最終確認は人間が行う前提です。

工数見積もりのドラフト作成

Notionタスクのタイトルを列挙して「これらの工数を見積もってください」と依頼すると、自分の主観だけに頼らない見積もりのドラフトが得られます。複業では自分の楽観バイアスで見積もりが甘くなりがちなため、AIの「もう少しかかる可能性」を併記する出力は牽制として機能します。

AI活用で気をつけたいこと（守秘義務・コード・顧客情報の扱い）: 副業先のNDA対象となる仕様書・ソースコード・顧客情報をAIに貼る前には、利用するAIサービスの「学習データ利用ポリシー」を必ず確認してください。一般に、無料プランは入力データを将来のモデル学習に使う可能性がある一方、Enterpriseプラン・APIプランでは学習対象外となるケースが多いです（OpenAIのデータ利用ポリシー、AnthropicのCommercial Terms等を参照）。社内チャット履歴・本番DB内容・顧客個人情報は原則AIに貼らず、貼る必要がある場合は副業先に事前確認を取るのが安全です。

複業エンジニアのタスク管理を継続するためのチェックリスト

仕組みも3週間で形骸化しては意味がありません。最後に、運用を継続するためのチェックリストを「導入時 / 週次 / 月次」の3段階で整理します。

導入時チェックリスト

• Notionに案件マスタDB・タスクDB・週次レビューテンプレートの3点が揃っている
• 案件マスタDBに「単価」「契約形態」「Toggl Project名」まで埋まっている
• Togglの Client / Project / Tag がNotion案件マスタと完全に整合している
• 「今日やることビュー」が稼働中の全案件のタスクを正しく抽出している
• 副業先ツール（Linear / Jira / GitHub Projects 等）の通知が自分宛のみに絞られている
• 「3分シャットダウン」「平日夜5ステップ」をカレンダー等でリマインドしている

週次チェックリスト

日曜夜21時など、毎週同じ時刻に10分確保するだけで運用が安定します。

• 週次レビューページを作成し、案件別の稼働時間を記入した
• 月間稼働上限に対する累計進捗を案件ごとに確認した
• 完了タスクのアーカイブと、未完了タスクの持ち越し可否を判断した
• 来週の各案件の最重要タスクを1つずつ言語化した
• 「想定 vs 実績」の乖離が大きいタスクを抽出し、見積もり方法を振り返った

月次チェックリスト

月末は請求作業に追われるため、月末2〜3日前から少しずつ進めるのが理想です。

• Toggl Reports で前月のbillable時間を Client 別に集計、CSVエクスポートした
• Notion案件マスタDBの単価・契約形態と突き合わせ、請求金額を確定した
• 月間稼働上限を超えた案件があれば、超過理由を案件マスタDBにメモした
• non-billable時間とbillable時間の比率を見て、稼働実態の傾向を把握した
• 継続・終了・条件変更を判断すべき案件がないかを点検した
• 翌月のカレンダーに、本業の繁忙期と副業のマイルストーンを書き込んだ

複業を持続可能にするのは、根性ではなく仕組みです。ここで紹介した運用設計を一度作り込めば、案件が1件増えても、必要な追加工数はDBへの1行追加とToggl Projectの新規作成だけになります。日々の判断コストを減らした分、本業のキャリアにも副業の成果にも時間を回せるはずです。

複業を本格化させる段階で案件の安定供給が課題になってきたときには、フリーランス向けの案件マッチングサービスWorkeeのような、エンジニア領域に特化したプラットフォームの活用も選択肢に入ります。本記事の仕組みで「複業を回す力」を整えておけば、新しい案件が増えても破綻しにくい運用基盤として機能します。