仕事におけるスイッチングコストとフロー

はじめに（なぜこのテーマを考えたのか）

複数のプロジェクトを同時に抱えていると、作業そのものより「頭を切り替えること」に疲れて、1日の終わりに消耗だけが残る感覚があります。僕はプログラマーではなく、資料作成・説明・調整が主戦場のマーケティングシステムエンジニアです。
ここ最近、「スイッチングコスト（タスク切り替えの負担）」が生産性を削り、フロー（没入）の芽を摘んでいるのでは？という仮説に強いリアリティを感じました。モブプログラミングに関する記事を読んだことも契機になり、「コード以外の仕事にどう応用できるのか？」を思考ログとして残しておきます。これは誰かに教える記事ではなく、自分の考えを整えるための記録です。専門外（認知科学・組織心理など）はシミュレーションして考えてみた前提で書いています。

考察プロセス（仮説 → 観察 → モデル化 → 介入案）

1) 仮説：生産性を落としているのは「作業量」ではなく「切り替え頻度」

• 体感：実働は増やしているのにアウトプット感が薄い。
• 仮説：案件間の切り替えで「思い出し」「文脈の再構築」「集中の立ち上げ」に時間とエネルギーを浪費している。
• 直感的モデル（自作）：
  • 1回の切り替えコスト ≒ 再集中に要するリードタイム（数分〜数十分）＋メンタルドレイン
  • 1日の切り替え回数 × コスト ＝ 失われる“見えない労働時間”

2) 観察：僕の仕事の特徴

• 関係者は多いが、手を動かすフェーズは個人作業になりがち（資料・説明・調整文書）。
• レビューは非同期で飛び交い、修正の往復が発生。
• 複数案件を“少しずつ”進めると、一日が「立ち上げ直しの連続」になってしまう。

3) 参照枠：モブプログラミングのエッセンスを抽出

※プログラミング外領域への比喩的応用として読んだメモ。

• エッセンス1：同じ文脈を複数人で共有すると、質問待ち・レビュー待ち等の待ちが減り、作業が流れる。
• エッセンス2：個人フロー × チームフロー × リーンフロー（在庫＝未完作業の最小化）が重なると速度が出る。
• 自分なりの翻訳：“切り替えない設計”を先に作ることで、フローの確率を上げる。

4) モデル化：非コード業務における“モブ的”設計

• ドキュメント・ジャムセッション：Google Docs等で骨子だけを数人で一気に叩き出す（10〜20分）。
• 80%レビューを短時間で：完成前に全員から同時にコメントをもらい、手戻りを早期に潰す。
• ペアライティング：構成・メッセージの思考部分だけを誰かとライブで固め、細部の整形は後で一人でやる。
  → どれも「個人で白紙に向かう時間」を減らす工夫。最初の“立ち上がり”に人を集めるのがポイント。

5) 介入案（自分用の運用ルール案）

A. WIP（仕掛かり）制限

• 同時並行の“深く関与する案件”は最大2つまで。
• それ以外は「レビュー中心」「報告待ち」に関与の深さを明示する。

B. 時間ブロック

• 午前は案件A、午後は案件B。切り替えは1日1回以下を基本。
• 緊急対応は“別レーン”（15分以内の軽作業のみ）で処理し、本流は崩さない。

C. スイッチアウト・メモ

• 中断前に**「次にやる3手」**だけ書き残す。復帰時のリロード時間を削減。

D. 初期段階の“モブ的”関与

• 重要資料は骨子づくりの10〜20分だけ関係者を招集。後半は非同期で進める。

E. テンプレート化

• 説明資料の定型スライド（前提・目的・論点・選択肢・判断基準・決定・宿題）を“型”として先に置く。

個人としての考え（今の時点での整理）

• 「少しずつ進める」のが実は一番しんどい。切り替えるたびに脳が再起動する。
• レビューは“同時に短時間”が効く。同じ文脈で一気にコメントをもらった方が効率的。
• “関与の深さ”を最初に設計することが大事。全部を抱え込まず、骨子だけ／レビューだけ、という役割分担を自分の中で明示する。
• 「次の3手」メモを残すだけで復帰が格段に楽になる。
• 疲労の正体は“作業時間”より“切り替え回数”だと強く感じる。

※ここに書いたのはあくまで考えの整理であって、まだ実践していない。

まとめ（自分のための運用チェックリスト）

• 深く関与する案件は同時2つまで
• 午前/午後で時間ブロックし、切り替えは1回以下
• 中断前に**「次の3手」**を必ず書く
• 重要資料は**骨子ジャム（10〜20分）**を人を集めてやる
• 80%完成で同時レビューを回して手戻りを圧縮
• 役割は骨子/実装/レビューで深さを明示する
• 成果ではなく切り替え回数と復帰時間を観察する

おわりに（今の感覚と次の問い）

今の僕は、「仕事量に疲れているのではなく、切り替えに疲れている」という実感が強い。
当面は、ここに書いた考えをベースにしばらく試してみて、

• 体感疲労は下がるか
• 復帰時間（再集中までのリードタイム）は短くなるか
• 手戻り回数は減るか

を観察してみるつもりです。

実践の結果については、また別のブログでまとめるかもしれません。

次の問いはこれです。

“切り替えない設計”をチーム運営にどこまで組み込めるか？
個人最適で作ったルールを、どの単位（課、PJ、依頼元との契約の仕方）で拡張できるか？

専門外の部分は仮説ベースなので、観察と微修正を繰り返していきます。フローが生まれる“条件”を、自分の現場に合う言葉と仕組みに翻訳し続けること。それが今の僕のテーマです。

参考にした記事

今回の思考整理にあたり、以下の記事を参考にしました。
モブプログラミングを扱った記事ですが、フローを生むための設計や切り替えコスト削減の考え方に多くの示唆を得ました。

• Publickey:
  • モブプログラミングは、なぜ5人が1台のPCで仕事をしているのに生産的になれるのか（中編）
  • モブプログラミングは、なぜ5人が1台のPCで仕事をしているのに生産的になれるのか（後編）