木こりのジレンマのさらに手前
はじめに
この記事は DevLOVE Advent Calendar 2020 13日目の記事だ。
この記事は「テーマ① 自分の周りの○○問題を問題提起する！」を扱う。そして、扱いたい問題は「木こりの問題のさらに手前」だ。
木こりのジレンマ
ある木こりが、がんばって木を切っている。
通りがかった旅人がその様子を眺めていたが、斧を振るう勢いのわりに、なかなか木が切れていない。
見ると木こりの使っている斧がこぼれしているようなので、旅人は言った。「斧を研いだほうがいいのでは？」
すると、木こりは言った。
「わかっちゃいるんだけどね、木を切るのに忙しくて、それどころじゃないよ」
忙しさ故に技術的負債と向き合えていなかったり、自己研鑽に時間を割けていなかったり、という問題を「木こりのジレンマ」になぞらえる例は、もしかしたら聞いたことがあるかもしれない。
しかしこの木こり、「わかっちゃいる」のだ。やったほうがいい、ということはわかっているのだ。でも、そういう場合ばかりではない。
「テストを書く意義がピンときていません」
リグレッションテストの環境は整っているが、ユニットテストの環境は整っていないような場合。最終的にはリグレッションテストが防波堤となっているがゆえに、ユニットテストを書くことが習慣化していないメンバーからするとその意義が感じられていない、ということが実際にあった。
そう、木こりのジレンマ風にいうと「わかっちゃいない」のだ。
先人の努力により切迫した状況がなくなった
さて、ではなぜこのような「わかっちゃいない」状況が起こるのだろうか。これにはいくつか要因があるだろうが、薪に臥し胆を嘗めた先人が「ひどい目にあわないよう」環境を整えてくれたから、というケースがままある。
どういうことか？例えば、こういうことだ。
インシデント多発地帯の生存者
テストがろくに整備されていないレガシーシステム。祈るような気持ちでリリースを行い、リリースした端から障害対応を余儀なくされる。
こんな環境では疲弊してしまう。そこで、誰かが一年発起してテスト整備を行う。単体テストを書けるような設計にはなっていないから、せめて水際対策にとリグレッションテストを実装する。
月日はながれ、そのシステムはリグレッションのおかげで不具合が出づらいものになっていた。リリース時に何も問題が起きなくなったのだ。
皮肉なことに、その状況ゆえに新人たちは「リリース時には問題が起きうる」ということを知らない。知らないがために、わざわざテストを整備しようとも思わないのだ。
問いかけ：チームとしては改善しつつ、「わかっちゃいる」状態にもっていくには？
さて、今回のアドベントの主題である問題提起だ。
チームとしては改善しつつ、「わかっちゃいる」状態にもっていくには？
環境を整える→環境が安定する→新しい人は環境を安定化させるインセンティブがない→負債を貯める→環境が死ぬ→環境を整える…
どうしたって課題に直面した人は「わからざるをえない」し、「わからなくてもいい」ように環境を整えていくだろう。一方で課題に直面していないと、「わかる」機会がどんどんなくなっていく。かといって「わかる」機会を持つために、環境を整備しないというのは本末転倒にも思える。Chaos Monkey的な取り組みをやればいいのだろうか…などと、ぐるぐるとしてしまう。
はて、どうしたものか。
この議題についてはDevLOVEのdiscordで議論できれば、と考えている。ぜひふるってご参加を。
この記事が気に入ったらサポートをしてみませんか？