＼回答があります！／

• 

  北野勝久

  エンジニア

  2年前
  
  こんにちは。株式会社スタディストで執行役員VPoEとして開発組織にまつわる様々な業務を行っている北野と申します。
  コンテキストスイッチの切り替えに対する言及ではないですが、エンジニアの仕事とマネジメントの仕事とでは、スケジュール管理のあり方は異なっていると個人的には考えています。
  
  この考えは、SpeeeのVPoE大場さんの、以下の発表に影響を受けています。
  https://speakerdeck.com/koichiro/railsdm2019-on-the-lonely-rail-of-engineering-management?slide=26
  
  上記のスライドでも言及がありますが、マネジメントの役割に必要なコンテキストスイッチの方法論はおそらく一般的にイメージされている、「まとまった時間をどう確保するか」という考え方とは逆で、複数の仕事の差し込みがあることを受け入れた上で、どう切り替えを高速化させていくかだと捉えています。
  
  私の場合は以下を意識して管理しています。
  
  ・必ずしも即レスである必要はないが、着手したボールを抱えすぎない
  ・ひとつひとつの仕事で、過去経緯を思い出しやすい状態を維持する（ドキュメント・コミュニケーション管理）
  ・話題ごとに、必要な関係者を一時的な場に切り出す（例: Slackの一時的なチャンネル作成）
  ・リマインダをうまく使い、目の前の忘れられるタスクを意識的に忘れる
  ・カレンダーのまとまった時間確保は大事に（打ち合わせの時間帯を寄せる）
  
  ひとつのご参考になればと思います。
  view数 9
  • 3
  • 3

• 

  山本隼汰

  エンジニア

  2年前
  コンテキストの切り替えが発生するのは仕方ないと思いつつ、例えば私はこんなことはやってみてました
  
  ・コンテキストスイッチが発生しやすいタイミングと自分が集中したい作業を実施するタイミングを意図的にずらす
  → 例えば、勤務時間を少し調整して、朝早い時間や夜の少し遅い時間に対応したりはしてました（朝の方がよいですね）
  → コンテキストスイッチが起きない時間で捌ける分は確実に進捗するようになります。ちょっとした安心感を生み出せます
  
  ・後から突発的に事象や対応しないといけない案件が発覚することを防ぐために、事前に情報やアラートを出せる場を用意しておく
  → 例えば朝会とかでもいいし、定期的な業務があるならその中に組み込むでもいいし。
  → コンテキストスイッチが予見できる状態をある程度作るためにやってました。そしたら他の人がおっしゃってるみたく、未来の自分が思い出すための作業ができますし
  view数 9
  • 1

• 

  Dai Fujihara

  プロジェクトマネジメント

  2年前
  こんにちは。
  
  複数の企業と並行して仕事をしています。これをはじめたときに、やることの切り替えと同時に、「このお客さまとは今何を話していて、次何やるんだっけ？」という情報の切り替えが必要になり、いろいろ試した結果、以下の方法で現在はやっています。
  
  ・ひとつの仕事中は他の仕事をしない
  私の場合はMTGが多いのですが、その時間はお客さまの時間なので、並行作業をできるだけしないようにしています。ただ、急ぎのSlackなどはありえるので、その場合はさっと答える Or あとで答えますね と回答するようにしています。
  
  ・仕事ごとにログページを作ってメモしておく
  Notionを使ってますが、ひとつの仕事で1ページを作り、今日やったことのメモ、つぎやることのメモを残します。MTG前にこれを読み返せばすぐに対応できるようになりました。
  
  ・宿題は可能な限りすぐ終わらせる
  MTG後にこちらの宿題があれば、すぐに終わらせてから次の顧客の仕事に取り掛かります。MTG後にすぐやったほうが、スイッチの切替もいらないですし、MTGがぜんぶ終わってから宿題をぜんぶやるより、とりかかりやすく感じています。
  昔、宿題に追われすぎて夜遅くまでかかってしまっていたので、ボールをできるだけ持たないように、すぐできることはすぐやる癖をつけました。
  
  あとは一日の最後に時間があれば、集中してやれるタスク（資料作りなど）をやっています。
  
  日々のやり取りはSlackが多いですが、「Slackを見てすぐ答えて！」というお客さんがいれば（今のところあまりありませんが）、「Slackは見てるけどすぐ反応できない場合もある。本当に急ぐときは電話してください」と事前に伝えるようにしています。
  
  参考になればです。
  view数 9
  • 1
  • 1
  • 2

• 

  横江 亮佑

  エンジニア

  2年前
  『エンジニアの立場としては○時〜○時の時間は緊急時の対応を除いて開発に集中するための予定を押さえる』
  これいいですよね、私もやってます。
  
  マネージャーとしては周囲から相談されやすい雰囲気であることが大事なので、
  突発のミーティングが入ること自体は、おおむねいいことだと思います。
  一方で、定例ミーティングは怪しいことが多いので、隔週にできないか参加メンバーと相談してみるのもオススメです。
  
  お問い合わせや突然のタスクは、自分しかできないものもありますが、
  ４割くらいは自分がやったほうが速いからやってることだったりするので、
  「@marumarusan すみません、これ見てもらえますか！ わからないところは聞いてくだされば！」と、思い切ってメンバーに振っちゃうのがいいかもしれません。
  
  いろいろ工夫しても、会議と会議の30分の合間とかは発生するので、
  その時間用にやる細かいタスク（プルリクのレビューなど）はあらかじめ用意しておくと、
  生産性の低下で悩むことが少し減るかもしれません。
  
  bowyer-app さんのお仕事を見ていないぶん的はずれなことばかり言っていたらすみませんが……、
  お役に立てましたら幸いです。
  view数 8
  • 3

• 

  大橋桃太郎

  プロジェクトマネジメント

  2年前
  皆さんとは少し違う切り口になりそうだと感じたので回答させていただくのですが、常に同時のコンテキストを持っておくことで何がきても切り替えが発生しない状態にしておく。というのを自分はやっているかもしれません（性格特性や職種もありそうです）
  
  多数のアジェンダに触れることができる一方で、深く考えるのにはコツや、瞬発力が必要なので、よく知らない対象にはあまり使えないのですが。
  
  別切り口として参考になりましたら、、！
  view数 10