僕はチーム join 時に、Docker は初手で剥がすし、GitHub Actions でやっているワークフローの全体像を把握するのを次に行う、というのを基本的にはやっている。これはシステム構成やデプロイ周りの全貌を把握するのが好きなのと、何かが起きたときにコレをやっているのといないのとで問題切り分けの精度に圧倒的な差があるからなんだけど、join 直後にやるのが最適解とは限らない場面もある。
チームの人員構成として、テックリード業を既に担っている人が居る場合、追加人員にはテックリード未満の「プラスの工数として数えられる戦力」となって欲しい。この戦力というのは、「目の前に積み上がった問題を一緒に解いて欲しい」という期待。問題と言うよりも、既にタスクになっているものを消化したい、という期待の方が大きいと思う。
そういう期待があるときには、ちんたら Docker を剥がしている場合ではなく、何も考えずに docker compose up の 1 コマンドで環境構築を終わらせ、テストもローカルでは実行せず CI に任せても良いので、タスクを消化した量を稼がなければいけない。今実行しているコマンドが何なのかは一旦「おまじない」で構わない。
つまり、言われたことしか作業しない兵卒プログラマとしてのロールに下げる、というのが期待されている。
この期待と行動とが一致していないと、周りからはガッカリ評価を貰うことになる。
「今この瞬間にクリティカルではない問題に時間を費やしている」 「チームが相対している目前の問題に対して、一緒に戦ってくれない」
チームの本当の問題を見つけにかかるのは、もう少し信頼を稼いでから。将校の役割を期待されるようになってからで良い。兵卒は、ブラックボックスをブラックボックスのままとして扱うことも必要。
兵卒ロールとテスト
こういった兵卒ロールを保証するのが CI/CD である。
他のコードに影響を与えてしまうリスクは CI で担保されているので、変更したファイルの外の世界を全て把握している必要がない。デプロイに関する人類の叡智は YAML に落とされており、誰も具体的な 1 コマンドずつの手順を知らなかったとしても粛々と動き続けてくれる。
テストコードがある世界はすごくて、すべてのコードに「間違いなく動く自信」が無くても構わない世界に連れて行ってくれる。「自信は無いけどコンパイラは怒っていないし CI も通ってるので多分動くだろう」という曖昧な認識で作業を完了しても大丈夫なのだ。この状況を作り出すためには一定以上のテストカバレッジが必要になるが、いちど閾値を突破するとテストに信頼が置けるようになり、兵卒が兵卒として生きていられる環境が成立するようになる。
プログラマの教育では「書いた全ての行について、影響を説明できるようになれ」というのを口を酸っぱくして言ってきたが、これは実は兵卒ロールに対しては過剰な努力であって、CI さえ通ってれば気にしなくても良いのかもしれない。（というのは言い過ぎで、その気になれば追える能力を持った上で、意識的に自分で上下できるとより良いよね、ということを言いたい）
考えたきっかけ
テストコードが無い世界で、テストの導入を渋る人にどう説得するのか、テストのメリットとは何なのか、という話題を見て。
テストのメリットは手動テストの時間短縮と、考慮漏れに気づける場合があることだと思っている。時間短縮は素朴に短縮できるのでやればいいが、考慮漏れの方は、僕自身が全貌を把握しているプロジェクトでは、自分ではテストを必要としていないよなぁという感想を抱いた。逆に言うと全貌を把握していなくてもコードを書けるようになるのがメリットで、全貌を把握しないという選択肢があるし、それを要求されることもある。
実際、全貌を把握しきっていないプロジェクトだと型が欲しいしテストも助かる。型さえあれば勘でコードが書ける。*1
全貌を把握することは必要ないのかと言うと、テックリードやアーキテクトの役割なら必要だろう。意思決定をするためには、どこに問題があるのか、何に効くのかを知っていると良い。そして何をするとどこがどうなるのかをだいたい知っているなら、テストの嬉しさは少ない。つまりテストの期待は「テックリードではない誰か (数ヶ月後の TL 自身も含む) が最低限の成果を出せることを保証する」ことと言えるんじゃないか。
