マルチタスクは攻めの思考で少し楽になる(かもしれない)
人間は機械ではない。
CPUは人間の脳に例えられることが多いが、脳とCPUにはクリティカルに異なる点がある。
それはタスク切替時のオーバーヘッドだ。
私は昨年の11月から、初期開発が終わったWebシステムの保守の現場に携わっている。
保守を経験するのはエンジニアのキャリアの中では初めてだったが、これまでとは違いマルチにスキルを発揮しながら、マルチタスクをこなすというのを要求されたように感じる。
その過程で得た、人間の脳の特徴に沿ったマルチタスクの進め方について、簡単にまとめて置こうと思う。
下記の内容は、あくまで経験則やネット上に溢れた情報を実践して感覚として得た内容を書いたものだ。
だから学術的な根拠に薄く、万人に当てはまるものではないことを最初に断っておく。
背景
保守の現場では、大まかにわけて下記のような業務を担った。
- クライアントからの問い合わせ対応
- 定常的な監視やメンテナンス
- 要望に応じた既存機能の改修
日々、機能改修のチケット対応や依頼されているタスクをこなしながら、時々やってくる問い合わせに対応する。
問合せ内容が急ぎの内容の場合もあるので、クライアントからのチャットには常に注意を払っておく必要がある。
また、これに加えて
自分が、現場で使用されている言語・FW・サーバサイド(クラウド)について全て未経験の内容、という個人的な状況もあった。
さらに、
- 保守の予算が少なく、使える工数がほぼ1人月に限られている
- したがって手を動かして仕事をするのは、全部自分
といった課題もあった。
課題:あれもこれもそれもフルリモートでやらなきゃいけない
月に1回のリリースまでに改修を終わらせるために、この日までにこの機能改修は終わらせるというのがある程度決まっている。
その中で、必要な知識を都度インプットしながら、既存のコードを理解し、文書化されていない仕様については、メンバーに確認を取ったりレクチャーを依頼したりといった進め方をしていた。
だが、クライアント対応も同時にやるため、別件の問合せが入ったり、隣の部署から改修部分についての相談が来たりすることもあり、作業に集中できずになかなか改修が進まない場面もあった。
また、プルリクまでこぎつけても、リーダーが別案件で忙しく、保守現場に割ける工数的予算も限られており、レビューがなかなか進まないということもあった。
そんな中で、追加開発チームのスケジュールが遅延しており、保守チームである私に一部の工程の協力要請も来ることになった。
なおかつ自分はフルリモートの勤務形態でやらせてもらっており、メンバーが今何をしているか、声をかけられる状況かが見えない中で、進める必要があった。
根本的な解決策:攻めのコンテキストスイッチを作り出す
よく人間の脳とCPUが対比して説明される。
CPUの仕組みを少し勉強すればわかるが、CPUは一つのスレッドを最大限活用するために、高速にタスクを切り替えながら演算処理を進めている。
そこでは目まぐるしい速度でコンテキストスイッチが発生している。
タスクの割り込みが発生する場面もたくさん発生する。
プログラマーのためのCPU 入門 CPU は如何にしてソフトウェアを高速に実行するか | Takenobu Tani |本 | 通販 | Amazon
それでもCPUは高速で処理速度を維持できる。
なぜCPUが、演算処理において人間の脳よりも優れているかというと、
- 処理する内容が究極的には0か1かという形式化された命令文である
- コンテキストスイッチのオーバーヘッドが、人間の脳よりも極端に小さい
というのが理由だろう。
でも人間の脳はそうではない
- こなすべきタスクは定型化されていないことのほうが多い
- コンテキストスイッチのオーバーヘッドが大きい
されに、これに加えて
- 人間は生物であり、体調や精神の状況によってパフォーマンスが変わる
- 人間は感情を持っている
というのも大きな要素として無視できない。
これらを考えると、マルチタスクを進めるうえで障害となってくるのは
- タスクに追われている感覚
- 自分以外の他のものに現在のタスクを妨害される感覚
- タスクの解決方法に見通しがつかない感覚
なのではないだろうかと感じている。
これらを解消していくには、結論として攻めの姿勢で仕事を進める意識を徹底的に貫くしかないと思う。
ここに来て精神論になるが、それを維持するための具体的な行動指針については、下記に4つの解決策として記述させてもらった。
メンタル的には問題に追われるよりも、問題を追いかけるほうが楽というのは、肌感覚的に正しいと感じている。
おそらく主体的に動くとか当事者意識を持って働くとかいった、ひどく曖昧で経営者にとって都合の良い言葉として語られがちな内容とも言える。
だが、やるかやられるかの真剣勝負の場面を考えてみてほしい。
その場面において、「やられたらどうしよう、うまくいかなかったらどうしよう、自分にできるだろうか」、などと考えてる人間が、コンマ数秒が生死を分ける場面で果たして勝てるだろうか?
そういう場面で勝つのは、「やられる前にやってやる。徹底的に息の根を止めてやる。」、と考えて臨んでいる人間なのではないだろうか?
解決策1:先回りしてレスを送る
情報の主導権を相手に渡さないために、自ら情報を拾って、自ら質問していくようにすると、レスに追われている感覚からは自然とおさらばできると感じた。
クライアントとのミーティングの議事録とか、Slackの他人のスレッドから、勝手に情報を拾えばいい。
今現場で何が最も優先的に取り組むべき内容なのかについては、常にこちらから情報を取りにいく。
もし状況が変わったら、何が変わったのかについて議事録から拾える情報は自分から拾って、朝会や夕会で自分から質問をする準備をしておく。
あらかじめ考えられるような場面が想定できるなら、先んじて伺いを立てたり、相手から状況や情報を引き出すように働きかけるようにコミュニケーションを取ってみる。
もし意思決定がされていない内容があるなら、自分なりに仮説を立てて、提案としてまとめて、上長がYesかNoか判断するだけにできるように、自分から働きかける。
自分から攻めるレスは、頭をフル回転させながら、文章表現もある程度考えないといけない仕事ではある。
だが、「あれどうなってる?」「これやってほしい」「ここはこうじゃなくてこう」とか、どんどん相手からレスが来るよりは、精神的には断然ラクになれる。
解決策2:目標時間を決めて集中して終わらせる
仕事はダラダラやればいくらでも工数を膨れ上がらせることができる。
期限や期日という制約が決まっていないと、いくらでも作り込んだり必要以上に凝ったりもできる。
とくにマルチタスクな現場で、時間の制約を意識せずに漫然とタスクを進めていると、差し込みの連絡やタスクによって、既存のタスクはいつまでも遅延するという状況が発生する。
これを回避するために、1日の時間の中に、自分用の締切をつくる。
例えば、タスクAは10時から11時で一度区切りをつけて、上長に報告する、とか13時から14時半は全てのレスに返信しない、その代わりに重めのタスクにじっくり取り組み、段取りをまとめるとかである。
フルタイムで働いていたら、1日の労働時間は7~8時間ぐらいだと思う。
人間の集中力は長くても50分程度しか持たないと言われているから、自ら時間割を作り出して、短期集中して作業に没頭できる状況を工夫して作っていくことが、大事なのではないだろうか?
解決策3:通話や出社をうまくつかう
わからないことの質問をまとめたり、相談事項を文章にまとめたりする時間が、やたらと長くなってしまうのであれば、上長やメンバーを捕まえて5~10分通話して解決する。
だいたいリーダーとかPMという職種は忙しい。
だが、できる人ほど直接通話や会話で解決することの便利さを知っている。
相談したい内容をまとめるのに30分かけるより、相手を捕まえて5分話す、ほうがコスパが良いこともある。
また、フルリモートだと、相手のスケジュールカレンダーが埋まっていて、いつ声をかけていいかわからないという状況や、割と重要だから早く相談したいけど、前送ったレスにも返信してくれないという場面もある。
そうなったら出社して直接相手を捕まえるという手段に打って出よう。
業務時間中に忙しくても、コーヒー休憩やランチの時間には、相手に隙が生まれる。
その隙に、ありったけの相談事項を叩き込む。
そうすると、相手の中でのこちらの優先度意識も変わって、それ以降のレスにも反応が良くなることもある。
解決策4:とにかく文書化する
色んなタスクがあって、全部が新しいことのように見えるが、よく観察するとやったことあることの使いまわしが効く内容だったり前にやったことの知識を一部流用する内容だったりすることは、よくある。
実際のタスク進行で問題になるのは、それを思い出したり、引っ張り出してくるときの、認知コストや検索コストやコミュニケーションコストであることがほとんどだ。
1日8時間、月に20営業日しかない中で、フルリモートで非同期にコミュニケーションしながら、マルチにタスクを進めていくなら、上記のようなコストは完全に無視できなくなってくる。
むしろ、上記に上げたコストこそがボトルネックになるとも言える。
これを回避して、生産性を底上げするためにはとにかく文書化して残すということだ。
文書化といっても、かっちりした文章を書けということではない。
- タスク対応のログをチケットに残して、別人が見てもタスク再開できるようにする
- wikiにないクラウドの操作をしたら、スクショと簡単な手順だけ書いてwikiをつくっておく
- 今日やること、やったこと、わからないことを都度メモして、朝会や夕会で助言をもらいやすくする
という程度のことだ。
一つ一つは小さなことのように見える。
だが、これが10個、50個、100個と積み重なっていくことが、タスク進行に大きな変化を生み出す。
「この程度のことであれば、覚えておけばすぐできるからいいか」「めったに使わない手順だし残す必要もないだろう」 という囁きが頭に聞こえたら、それこそが罠だ。
そういった小さなサボりの積み重ねが開発体験や納品物や対応品質の低下を、中長期的に招いていくことに、そろそろ気がつこう。
もちろん、やり始めたころは時間もかかるし、何の意味があるんだ、と思うかもしれない。
でもそういった小さな積み重ねが、必ず未来の自分や、未来の後任者を助ける武器になってくれるはずだ。
まとめ:仕事に没頭できる状況を自ら作り出す
仕事をしてたらいくらでも不満なんか出せる。
- 既存のソースがいけてないし、バグもある
- ドキュメントが整備されてなくて聞かないとわからない
- クライアントが情報の足りない問合せをしてくる
- クライアントのレスが遅い
- 予算と時間が足りない
- レビュアーがプルリクを見てくれない
- PMが忙しくてレスを見てくれない
だが、全てが揃った現場なんてこの世に一体いくら存在するのだろうか?
人間は不完全で未完成な生き物で、それが集まって仕事をしている。
ならば現場はカオスになって当たり前だ。
だけど、みんなその中で、それなりに情熱をもって前向きに仕事をしていると信じたい。
であれば、不満を抱いて文句を垂れながら、相手に改善してもらうのを待っているべきではない。
自らできることに進んで取り組み、仕事のやり方や仕事の仕組みをスマートに変えていくのが、大人のやり方なのではないだろうか?
相手にコンテキストスイッチを発生させられて、受動的に集中を阻害されるのではなく、能動的にタスクをコントロールして、一つ一つを集中して終わらせる。
追われる感覚ではなく、獲物を追う感覚で仕事を捌くことで、攻めのコンテキストスイッチを発生させるように仕事をしていきたい。
※この投稿は、私のはてなブログから抜粋したものです『週報33 マルチタスクは攻めの思考で少し楽になる(かもしれない) - キムチのきもち』
Discussion