タイトルで言いたいことは言った。

完全リモートワークの生活をしている。自分以外のメンバーがどんなふうに働いているのか一切わからないが、「ボール」がどこに溜まっているのかはGitHubやSlackのやり取りを見ていればなんとなくわかる。

ここで言う「ボール」は、そのタスクを進めるためにアクションする人を指す。コードレビューを例にすれば、レビュー依頼を受けたら、レビュアーが「ボール」を持つし、レビュアーがレビューしていくつかコメントをしたら、今度はレビュイーが「ボール」を持つ。

誰かが「ボール」を抱えてしまうと、そのタスクはそれ以上進むことはない。

仕事が進まないときというのは、たいてい誰かが（自分かもしれない）「ボール」を抱えていることが多い。

そして、人間なので「ボール」を抱え込んでしまうことは一定ある。

なぜ「ボール」が溜まるか

「ボール」が溜まりやすい理由の種類は大きく二つある。組織の問題と個人の問題である。組織の構造上「ボール」が溜まりやすくなることはあり、それはそれで解決すべき問題だが、ここでは個人の範囲で述べる。

「ボール」の量は自分がコントロールしにくい部分だ。なので「ボール」が溜まっている状況自体は大きな問題ではないが、それらをどう対処するかは個人で差が出る部分だ。

2,3分で対応できそうなレビュー修正を数日寝かせているような状況を見たことがある。これだと終わる仕事も終わらない。完全リモートなので、なぜそういう状況になっているのか原因を把握することが難しい。完全リモートの良くないところの一つだ。

マインドセットの問題がありそうだ。ここからは想像も含めて「ボール」が溜まる理由を書いている。

• タスクが多すぎて優先度の判断すらできなくなっている

  • これはかなりやばい

  • 自分がこうなっていると思ったら助けを呼ぼう。

  • 誰かがこうなっていたらすぐに助けよう。

• 忙しいことに対する謎の幸福感

  • うまく言語化できないが、そういう感情はある

• やることがある安心感

  • やることがない状態を恐れるあまり、仕事を手放したくない人もいる。

  • 適度にタスクを追加で与えると、過去の「ボール」を手放してくれる傾向にある。

• 意図的にボールを抱え、自身の存在感を上げる

  • 恐ろしい話だが、かつてそういう人と働いたことがある。歪んだ生存戦略である。

  • 似たようなものとして、属人的な知識を溜め込む人もいる。

  • ただし、ボールを抱えている人を安直にそういう人だと判断してはいけない

• ボールを抱え込むことで生じる問題を理解していない（意識していない）

  • 意外とこういう人は多い。以下そういう人に向けて問題点と、対処法を書く。

「ボール」を溜めるとどんな問題が発生するか

• 仕事が進まない

  • シンプルにこれ。「ボール」を溜めている間は決して仕事が進むことはない

• 仕事の効率が落ちる

  • 自分も相手も仕事の効率が落ちる。

  • 「ボール」を溜めている期間に記憶が失われ、再びその仕事に取り掛かかるときに思い出すコストが余計にかかる

  • 相手にも同じ状況が発生する。相手の仕事の効率を下げている。

• 精神衛生上よくない

  • やらなきゃいけないことを抱えている状態はつらい。確定申告の時期は憂鬱だ。

  • 「ボール」を投げた方も気になる状態が続く。

「ボール」を溜めないために何ができるか

• 自分が「ボール」を抱えているかどうか知る

  • 「ボール」の有無を聞かれてパッと答えられない場合はきっと「ボール」を抱えている

• 「ボール」を管理する手段を作る

  • TODOリストが一番シンプルだが、手段は何でも良い。

• すぐ返せるものは最優先で返す

  • 考えることが減る

  • 自分はなにかの作業をしている途中でも、すぐに返せる場合はすぐに返すようにしている。短期的には効率が下がるが、長期的なメリットのほうが大きい。何に集中すべきか明確になる。

  • 100%の返答が厳しい場合でも、一次回答がすぐにできるならそれはすぐに行う。状況によってはそれで十分で、「ボール」が消えることもある。

  • なお、雑な中身で返すのはよくない。余計なやりとりが増えるきっかけになる。

• すぐに返せない場合は、「すぐに返せない」とすぐに返す

  • これができない人は多い。もちろん「ボール」は抱えている状態なので、TODOリストなどの管理に追加する。

  • 合わせていつ返せそうか伝えられるとなお良い

• 他に適任がいるかどうか探す

  • 丸投げにならないように注意

• 常に「ボール」を優先的に返す意識を持つ

  • 定期的にTODOリストを見る。対応する。

  • 究極は意識の問題になる。

「ボール」を返すことに集中しすぎて、自分の仕事が進まないのでは？

ボールを返すことに全力を注ぐとそうなる場合もある。何事も極端なのはよくない。ただ、多くの人は「ボール」を抱える側に偏っている傾向があるので、それを少しでも解消できればと思っている。自分の「ボール」を意識するところから初めてみるのはどうだろうか？

最後に、この「ボール」に対する意識は人によって異なる。相手に過度な期待を押し付けないように注意すること。気になることがある場合は対話による提案をしよう。

ポモドーロ・テクニックにハマっている。

一ヶ月ほど試してみたので、よりこのテクニックについていくつか気付いたことがある。ポモドーロ・テクニックに向いているタスクと、向いていないタスクがある。

ポモドーロに向いていないタスク

• 設計の初期段階など、思考の繰り返しが要求されるようなタスク

  • 集中よりも創造性が求められる場合、時間で区切るとむしろ逆効果になる

  • 時間を気にせず考え抜く方が自分は心地よく仕事が進められる

• コードレビュー

  • 特に大物や注意して見なければならない内容については時間で区切れるようなものではない。

  • ただ、軽微なものが大量にあるような場合は集中的にそれらを処理するために使えることもある（パッケージ上げなど）

• 障害対応など緊急性が高いタスク

  • 5分の休憩などを取っている場合ではない

ポモドーロに向いているタスク

• ある程度方針が見えているタスク

  • 上記の設計の初期段階が終わり、あとは手を動かすだけという状況は一番相性がいい。その手を集中して動かすことができる。

• 時間で区切れるタスク

  • 実現可能性の有無などを一次調査したい場合などに有効

ポモドーロに向いていないタスクでポモドーロを行ってもストレスが溜まるだけだし、ただの勤怠管理に成り下がってしまうので、このあたりの用法は見極めていきたいところ

修正依頼の意図があるならば、素直にその内容を書いたほうが良い。安易に質問形式を使うとチームが疲弊する。

質問形式のレビューとは

例えばユーザーのidを抽出したいときに以下のコードがあったとして

1user_ids = User.where(hoge).map(&:id)

それに対してレビュアーが

みたいな質問形式。これ、なるべくやめたほうが良い。

「この処理で必要なのはIDだけなので、pluck(:id)を使う方が効率が良いからそうしてほしい」という意図があるならば、シンプルにそう伝えれば良い。

上記の例は極端かもしれないが、以下のような書き方をしている人もいるのではないだろうか

質問形式によるレビューの「こじれ」

質問形式を取ってしまうと以下のような「こじれ」が発生する

• 真意を探る

  • 特に「なぜ？」と問われた場合に発生しがち。レビュイーからすると、レビュアーが何を問題視しているのか、どのような意図で質問しているのかを推測する必要が出てくる。「もっと良い方法があるのか？」「何か設計上の意図を確認したいのか？」など、レビュアーの意図が不明なため、レビュイーは様々な可能性を考慮し、本来のタスクから意識をそらすことになる。

• 防御的な姿勢を取る

  • レビューの仕方や人にもよるが、自分の書いたコードを否定されたように感じ、防御的な姿勢を取ってしまう場合がある。

• 無益な議論へと発展する

  • レビュイーが意図を汲み取れなかったり（大抵はできない）した場合に発生する。レビュアーからすると的外れな表面的な回答をレビュイーが行い、それに対してレビュアーがまた質問するという不毛な議論が発生する。

• コードが歪む

  • これはレビュアーに修正依頼の意図がなく、純粋な質問をした場合に発生しうる。真意を探りすぎたレビュアーが既存のコードを過剰に調整してしまい、結果としてコードが歪んでしまう場合がある。

質問形式自体にこういう「こじれ」のリスクが有ることを意識したほうが良い。

なぜレビュアーは質問形式を使ってしまうのか

以下のような理由がある。質問形式のレビューは楽なのだ。

• 指示することに対するためらいがある

• 具体的な修正案がわからない、自分が想定する修正が最適なのか自信がない

• レビュイーが自発的に気付き、修正することに対する教育的な期待を持っている

上二つの理由は心理的だったり技術的な問題であるため説明は省略するが、最後の理由は注意したい。確かにレビューのコメントでレビュイーが自身のコードの問題点に気付き、それの修正を行うことはあるが、それによる教育的なメリットはどれぐらいあるのだろうか。おそらくほぼ無いと言っていいだろう。仮にあったとしても、それは質問形式を行ったことによるものではない気がする。

より建設的なレビューをするために

• 提案をする（コスト：低）

  • 提案形式で済むのなら、積極的に提案形式でレビューしたほうが良い。先に述べた通り質問形式は「こじれ」を引き起こすリスクを持っている

  • 答えを与えることに対する教育的なデメリットを感じる人もいるが、それは無いし、自発的な修正による教育的なメリットもない。もしそれが期待できるような状況ならば、「勉強も兼ねて周辺を調査し、最適だと思う手法を提案してください」ぐらいまで伝えた方が良い。

• 純粋な質問であることを伝える（コスト：低）

  • 疑問に思ったときに使う。「ask」や「純粋な質問なのですが、」をつけるだけでいい。レビュアーが余計な真意を探る「こじれ」を減らせる。

• 具体的な指摘をする（コスト：中）

  • 何が問題なのかを伝え、それと期待する修正内容を伝えるとより良い。

• 指摘内容の意図や背景を伝える（コスト：高）

  • 技術的な差やドメインの差がある場合に必要になる。

コストの高いレビューをレビュアーに期待するのはやめる

自分がレビューするときはこれらのことを意識していきたいが、一方で人のレビューにこれらを期待するのは少し虫が良すぎるかもしれない。なぜレビュアーが質問形式を使うのかと言うと、それが楽だからだ。

雑なレビューを受け取ると少しがっかりすることもあるが、まずはレビューのために時間を割いてくれた相手に感謝の気持ちを持つようにしよう。

.gitignoreとは違い、既に管理されているファイルの変更を無視したい。

環境依存の関係でどうしても変更したいが、全体には影響させたくないときに使う。

1git update-index --skip-worktree [ファイル名]

git update-index はインデックスを更新する。インデックスはワーキングツリーとリポジトリの中間に位置するステージングエリアのこと。

これの--skip-worktreeオプションでファイルの変更を無視する。

この操作を取り消すには --no-skip-worktree を使う

1git update-index --no-skip-worktree [ファイル名]

注意点

--no-skip-worktree を使うと、変更を検知することができなくなる。そのため、変更を取り込めないことによる別のトラブルが発生する場合がある。後述する--assume-unchangedの方が目的に合っている場合もある。

--assume-unchangedオプション

似たようなオプションで、--assume-unchangedがある。--skip-worktreeがファイルの変更を無視するのに対して、--assume-unchangedはローカルでのファイル変更が無いと仮定するように指示する。

使用目的としては、自動生成されるファイルなど、頻繁に更新されるけど頻繁に変更を追跡しなくても良いものに対して使う。ファイル変更の監視をしなくて良くなるので、パフォーマンスが向上する。

1git update-index --assume-unchanged [ファイル名]

この操作を取り消すには--no-assume-unchangedを使う

1git update-index --no-assume-unchanged [ファイル名]

--skip-worktreeと--assume-unchangedの違い

ローカルとリポジトリでそれぞれファイルの更新が行われ、マージされたときの挙動が異なる

• assume-unchanged：ローカルの変更は破棄。リポジトリが取り込まれる

• skip-worktree：ローカルの変更を維持。リポジトリの変更は取り込まれない。

設定ファイルにおける軽微な調整を無視したいときなどは、将来の変更が取り込まれる--assume-unchangedの方が向いていそう。

無視したファイルを確認する

1git ls-files -v | grep '^[Ssh]'

git ls-files -vで先頭にSがついているものが--no-skip-worktree指定したもの。--assume-unchangedを指定したものについては小文字のsがつく。マージ中にコンフリクトしたものは小文字のhで表示される。grepでそれらを抽出している。

参考

• Git - git-update-index Documentation

大きいところから説明するほうがわかりやすい。

ICANN (Internet Corporation for Assigned Names and Numbers)

インターネットのアドレス空間をグローバルに管理する非営利団体がある。

IANA（Internet Assigned Numbers Authority）を通じて、各地域のRIRにASNのブロックを割り当てている。

RIR (Regional Internet Registry)

各地域におけるIPアドレスとASNの割り当てと管理を担当する組織

世界には5つある

• ARIN (American Registry for Internet Numbers): 北米地域

• RIPE NCC (Réseaux IP Européens Network Coordination Centre): ヨーロッパ、中東、中央アジア地域

• APNIC (Asia-Pacific Network Information Centre): アジア太平洋地域

• LACNIC (Latin America and Caribbean Network Information Centre): 中南米、カリブ地域

• AFRINIC (African Network Information Centre): アフリカ地域

ASN（Autonomous System Number：自律システム番号）

インターネット上でネットワークを識別するために使用される番号。主にインターネットサービスプロバイダー（ISP）や大規模ネットワークを管理する組織に割り当てられる。

この分類があるおかげでルーティングの効率化ができている。

IPの情報を取得するときに、プライベートIPアドレスではASNは割り振られない。IPの情報を使ったロジックを書くときはこれを使って開発時かどうか判定できる。