割り込みタスクに対処する
日々沢山の割り込みタスクが発生する。レビューや質問、相談、依頼された確認など。最近割り込みタスクで疲れてしまうことが多い。メインのタスクがなかなか進まないのと決断の多さが原因だと考えている。
タスクを捌き切った！と思ってもメインのタスクが全然進んでいなかったということが何度かあった。そのとき、自分は複数のタスクを捌き切った達成感よりもメインのタスクが進んでいなかったガッカリ感の方が大きく感じてしまった。
レビューや質問、相談、確認には決断が求められるものもある。こうした方がいいと決めるのには体力がいる。いわゆる決断疲れが起きてしまっているのだと思う。
割り込みタスクが発生するのは仕方がない。自分もレビューを依頼したり、質問したり、相談したり、確認依頼をしたりする。なので、割り込みタスクで疲れないようにするための対策を挙げてみる。
すぐに対応できるものはすぐこなす
GTD (Getting Things Done) のように2分でできることはやってしまう。そしてすぐに忘れてToDoリストや頭の中に残さない。「あれやらなきゃ」というプレッシャーをなくす。
優先度をつける
期限や優先度を聞き、メインのタスクと優先度順に並び替える。後回しにしてもよければ余裕のあるときに考える。
他の人に任せる
自分に余裕がなければ他の人に任せる。常に他の人に任せていたら、タスクを頼まれなくなってしまうので余裕がないときに使う。
考えるリソースを使いすぎない
自分の考えるリソースを使いすぎない。自分で結論まですべて考えず、依頼側にも考えてもらう。要点だけ考えて別途調査が必要な場合は任せるなど。
割り込みタスクで疲れる原因と対処法を考えた。メインのタスクに集中できるように割り込みタスクで疲れないようにしたい。
ビックバンリリースを避ける
Webサービスのリリースの話。ビックバンリリースは簡単に言えば大きなリリースのこと。ビッグバンとまでいかずとも、大きなリリースを避けて小さくリリースしたいと思っている。
どれくらいが大きいかの明確な基準はないが、以下のようなリリースは個人的には大きいリリースだと思う。
- 着手開始からリリースまで数週間以上かかる
- リリースに含まれる変更ファイル数が数十ファイル以上ある
- リリースに含まれる変更行数が数百、数千行以上ある
数十や数百の「数」もかなりものによるので、曖昧で申し訳ない。主観的に大きいなと感じたらそれは大きいと見なしてもいいのかもしれないとも思う。また、リリースするのが怖いと感じたら大きなリリースのサインでありうる（ただし、クリティカルな機能に対する変更や初めて触れる機能に対する変更だからといった理由を除く）。
大きなリリースを避けたい理由は沢山ある。
- 実装
- 時間がかかる
- テスト
- 影響範囲が読みにくくなる
- 確認箇所が多い
- PRレビュー
- 変更ファイル数や行数が多い
- レビューし始めるのに気合がいる
- まとまったレビュー時間を要する
- コメント数が多くなる
- レビューの往復回数が多くなる
- レビューに時間がかかる
- リリース
- リリース時期が予測しにくい
- 不具合や障害が発生したときの切り戻しが大変
（PRレビューをすることが多いのでPRレビューの項目が多くなってしまっている） これらのデメリット、リスクを避けたいので、大きなリリースを避けて小さくリリースしたい。
小さくリリースするために、実装に着手し始める前にあらかじめ小さくリリースできないか、計画をする。分割してリリースできるものはないか、リファクタリングだけ先にリリースできないか、ユーザーに見えない範囲でリリースできないか等、切り出してリリースできるものを探す。
リリースを小さくすることによるデメリットは当然ある。PRの数が多くなり、レビューの数が増える。リリースの待ち時間や作業の手間の回数が増える。しかし、トータルで見るとコストも安く、リスクも小さいように思う。また、リリースの待ち時間を減らすためにビルドやデプロイ時間の短縮に力を入れたり、リリース手順の簡略化など取れる手はある。
大きなリリースを避けて、小さくリリースしたいということを書いてきた。大きなリリースを避けて、小さくリリースしたい。
プロキシになっていないか
人から質問を受けて、別の人に確認をするプロキシになってあることがある。このプロキシについて考える。
プロキシは自分が回答を持たない、判断できない、決められない場合に発生する。また、自分はわからないが、誰に聞けばよいかを知っている場合に起こる。そうでない場合は「すみません。自分はわからないです。」と回答して終わる。
プロキシになったとき、「あ、プロキシになってる。意味がないな。」と感じることがある。しかし、「これは自分が確認した方がいいな」と思うときもある。違いは自分が間に入ることで会話がスムーズになるかどうかのように思う。自分を介することによって往復の回数が増えるようであれば、自分を挟む必要はない。質問者と回答者の業務上の関わりが薄く、質問者が聞きにくそうだと思ったら自分が聞く方が速く解決へ向かう。ただ、次回からは回答者へ直接するようにお願いする。また、質問を翻訳する必要があると判断した場合も自分が間に入る。エンジニアとビジネスサイド間でよく見かける。これは相手が理解できる言葉で話す歩み寄りを頑張って欲しいと思う。
質問のプロキシについて考えた。質問と回答を受け流すただのプロキシは意味がない。プロキシになるのであれば、会話がスムーズになるプロキシになろう。
ミーティングでやった方がいいと思うこと
ミーティングでやった方がいいと思うことを書く。
- 資料を事前に読んでもらう
- ミーティングの前に資料を共有して目を通してもらう
- 前提知識の共有に時間がかかって、本題までたどり着けない・本題について話す時間が短くなることがある
- 目的を設定する
- 何について話して何が達成出来たら良いのか目的を設定する
- 目的がないと話すべきことを話し忘れたり、話さなくてもいいことを話したりしてしまう
- 貴重な時間を無闇に消費してしまう恐れがある
- 解散のタイミングも見失いやすい
- アジェンダを見せる
- ミーティング中は画面共有でアジェンダを見せる（オンラインミーティングの場合）
- 今何について話しているかを示し、話の脱線を防止する
- 決まったことをメモする
- ミーティングで決まったことをメモする
- 決定したことについての参加者の認識を揃える
- ミーティング後に忘れるのを防ぐ
他にも色々あると思う。パッと思い浮かんだものを書いた。自分がファシリテーションする際にはこれらをできていると、ミーティングがスムーズに進むことが多い。
文章を速く読めるようになりたい
自分は文章を読むのが遅いと思っている。速く読めるようになって沢山文章を読めるようになりたい。
文章を読み進められなかった - なんでもノートで頭の中で声を出していると書いた。「頭の中で声を出すってどういうこと？」という方は以下の記事を読むといいかもしれません。
頭の中で声を出して読んでいるので、読むスピードは喋るスピードになる。喋るスピードが自分の文章を読むスピードの限界だ。冒頭にも書いた通り、このスピードは遅いと感じている。もっと速く読むために最近トライしていることがある。
1つ目は文章の漢字とカタカナだけを読むことだ（日本語の文章に限る）。ひらがなを読み飛ばすことで読む総量が減るのでスピードが上がる。日本語の文章は漢字とカタカナと送り仮名だけ読めば大意を掴めることがままある。ただ、読むスピードは上がるが単語や文のつながりを自分の頭で補完しながら読むので疲れる。何の話してたっけ？と頭に入ってないことも多い。
2つ目は自分が興味のある箇所だけ読むことだ。読まないことで読みたい文章の量を増やすトンチっぽい。これは読書術の本によく書いてある方法だ。主に本を読むときに使うテクニックになる。本はすべて読まないといけないという考えを捨てる。読んでいて自分のためにならないと判断したら読み飛ばす。目次を見て、自分が興味のある箇所や重要そうなところだけ読む。という感じで取り入れている。
あと、本の場合、太字や赤字だけ読めばいいのでは？と思ったこともあるが、さすがに読み飛ばしすぎな気もするのでやっていない。
改善の余地あり。
文章を読み進められなかった
高校生の頃、文章を読み進められない時期があった。単語や文の意味を正確に理解しないと文の最初から読み直すみたいなことをしてしまっていた。完璧主義的なところがここにまで出ていた。1つの文章を読むのにとにかく時間がかかって文章を読むのが苦痛だった。
さすがにヤバいと思って、ネットで調べた。ヤバいと思っていたので人にはあまり相談しなかった。ネットからの情報かは覚えていないが、最終的にたどり着いた方法は音読だった。音読して無理やり読み進めた。音読している最中に単語や文の細かい意味を考える余裕はないので、とにかく文章を読み進めることに成功した。最初は文字通り声に出して読んでいた。それから段々と口を動かすだけになり、頭の中で声を出すだけになった。音読をするようにしてからは読み進められない現象は起きなくなった。
文章を読み進められなかった時期と克服法を振り返った。今も頭の中で声を出して読んでいる。もし再発したら音読から始めよう。
