はじめに

「プログラマが知るべき 97 のこと」の「28.「魔法」に頼りすぎてはいけない」を読んで考えたことについて書きたいと思います。

ここでいう「魔法」とは、「仕事が上手く回るために他人が行っている工夫」という意味合いで使われています。

目に見えにくい細かな工夫で仕事が上手く回るため、「魔法」と呼んでいるのだと思います。

この章で書かれている覚えるべき原則は「他人のする仕事は実際より簡単に見える」というものです。

それは「魔法」は他人からは見えにくいからです。

この原則を改めて心に刻みながら日々の業務を振り返ったときに、気を付けるべきことがいくつかあったなと思ったので忘れないように書いておこうと思います。

誰かがいつもやってくれている作業を巻き取るときは絶対に想定以上の時間が掛かる

定常業務はやればやるほど慣れてきて早くこなせるようになっているでしょうし、生産性が高い人であればそういった定常業務を効率的にこなすために細かい工夫をたくさん重ねていると思います。

そういった人の作業を巻き取るときには「時間が掛かる」ということをしっかり認識しておくべきです。

「思いのほか時間が掛かった」となってしまうことが個人的には多いです。

巻き取る際に一緒に進める上での工夫などを聞いておくと、こういったことは少し避けられるようになるかなと思います。

開発タスクなどを投げる際には、自分があまり開発に関わっていない部分であればどれくらい時間が掛かりそうかを実務担当者としっかりコミュニケーションを取って擦り合わせるべきです。

自分には見えていないが実装に時間が掛かるところなどが必ず 1 つや 2 つあると思います。

こういったコミュニケーションが取れていないと、自分はバッファを含めた妥当なスケジュールで依頼していると思っていても、相手からは「いつもタイトなスケジュールで依頼してきやがる」と思われていた、みたいなことが起こりかねません。

また自身が依頼を受ける側のときにもどれくらいの工数が掛かるのかをしっかり伝えないといけないと思いました。

私の立場上、大体開発依頼は Biz 職から直接渡される場合がほとんどなので、具体的にどんなことをしているのか依頼側は分かっていません。

そのため丁寧に説明していかないと自分や自分のチームに無理をさせてしまうことになったり、チーム全体の開発ディレクション力も高まっていかなかったりしてしまうので、しっかりと話していかないとなと思いました。

自分の想像以上にチームが上手く回っているときは、「自分の想定していたより簡単な仕事だった」のではなく「誰かが上手く回るように工夫を重ねてくれて」います。

上手く行っている要因を特定しないと再現性がありませんし、ある人がいるから上手くいっているのに、その人をチームから外してしまうなどの間違った意思決定もしてしまいかねません。

レトロスペクティブの場を設けて、「なぜ上手くいっているのか」をしっかり確認し、「この状態を継続するためにどうしたら良いか」「プロジェクトの状態をより良くしていくためにはさらにどんなことをすれば良いか」というのをチームで確認するのを忘れてはいけないなと思いました。

「他人のする仕事は実際より簡単に見える」ということについて考えたことを言語化してみました。

自身の頭の整理のために書いているものですが、誰かの参考になれば幸いです。