DevLOVE関西 200回目で紹介した、私の個人指針。迂闊に採用すると大怪我する取扱注意なものだとは思います。
出典はClean Coderで、訳書は2012年。薄い本ですが、今回取り上げるのその中でもさらに一部です。
"緊急時の規律"(CleanCoder)にはいろいろ納得した。
— irof (@irof) 2012年8月28日
「本番は練習のように、練習は本番のように」なども同系統の言葉かと思います。
どういうもの？
Clean CoderはCleanシリーズ2冊目です。Clean Code、Clean CoderのほかにClean Architecture、Clean Agile、Clean Craftsmanshipなど。 多分一番有名（かつ誤解されている）のがClean Architectureですが、それはそれとして。
「緊急時の規律」はClean Coderの「第11章 プレッシャー」にある「プレッシャーから逃れる」の一節です。 引用します。
緊急時になれば、自分が何を信じているのかがわかる。規律を守っていれば、その規律を本当に信じているということだ。逆にいうと、緊急時に普段の行動を変えて仕舞えば、その行動を信じていないということだ。
平常時にTDDの規律を守り、緊急時にそれを守らないとすれば、TDDの効果を心から信じていないということだ。平常時にコードをクリーンに保ち、緊急時に乱雑にするのであれば、乱雑が速度を落とすことを信じていないのだ。平常時にペアを組まず、緊急時にペアを組むのであれば、ペアの方が効率的だと信じているのだ。
緊急時に安心して守れるような規律を選ぼう。 そして、それを常に守ろう 。規律を守ることが緊急時から逃れる最善の方法である。
ピンチに陥っても行動を変えてはいけない。規律が最善の方法であれば、緊急時になっても守るべきである。
うむ。
Clean Coderは流石に今読むには古く感じるかもしれない。であればClean Craftsmanshipを読むといいと思う。
訳書は2022年8月で、最近のことを汲んでClean Code&Clean Coderを要約加筆したものという位置付けかな。 「緊急時の規律」は書かれていなさそう？ですが、規律推しは強くなっている印象です。
私の適用方法
素直に読むと「緊急時も規律を守りましょう」となると思うのですが、私は緊急時に規律を守るのは前提として、平時の行動を見直す言葉として使っています。 「平常時にペアを組まず、緊急時にペアを組むのであれば、ペアの方が効率的だと信じているのだ。」に重点を置いている感じですね。
緊急時の振る舞いを見て、平時もその通りにやる。緊急時にダブルチェックするのなら、いつでもダブルチェックする。 「平時はそんなコストをかけられない」などの障壁はありますが、そこは行き止まりじゃないと思うんです。緊急時にやっている行動を、平時でもできるようにチューニングして、緊急時も平時も同じ方法でやれるようにできないかを考えて取り組むのです。
そもそもだけど、「緊急時だけやること」は二次災害を生むものです。不具合の修正時に不具合が発生する確率は高くなるものです。慌てると碌なことはありません。 緊急対応では二次災害が起こることを前提に、緊急時には先に挙げたダブルチェックのような発生を抑える仕組みや、発生したものに対処できるワークアラウンドを組むのはよくやられる有効な対処法です。 それらが緊急時にできるのであれば、平時にできないものか？を真面目に考えるのが転用です。事後対応を体質改善に持ち込む形です。
もちろん全てに適用できるものではないですが、ソフトウェア業界は物理制約がなんとかなるものが多く、実際にたくさんの「このコストは無視できるからいつもやろう」が行われるようになっています。 たとえば一昔前は「コンパイルは時間がかかるからコンパイルエラーが起きないように事前にチェックしてからコンパイルしよう」でした。20年前の書籍にはベストプラクティスとして挙げられてたりします。いまコンパイルに時間がかかるから人力でというのはごく一部を除いてないでしょう。（たまにコンパイルエラーをPRレビューで指摘することはありますが、無駄だと思います。） テストも大きな泥団子であったテストの塊が分解され、「テストで不具合が見つからないように事前にレビューしてからテストしよう」となっていたものの一部は「テストしたらよくね？」になっているものもあります。自動化されたテストはだいたいそう。12年前になりますが 自動受け入れテストはユーザー受け入れテストの露払い と言うことを書いています。何も珍しいことではないです。 これらはコストが十分に小さくなった結果として「特定の時だけ行っていたものが常時行われるようになった」という例ですが、緊急時に行われる「高コストだから普段はできないこと」も効率化は可能でしょうし、そうすれば平時に転用可能になるはずです。コンピューターを使用した効率化は私たちプログラマの得意領域でしょう。
緊急時にやることを平時に転用したい理由はいくつかあります。
- 緊急時に初めてやることがうまくできるとは限らない。
- 緊急時にできることを普段やらないのは勿体無い。
一つ目。「緊急時だから」と言って手順外のことをすると高い確率で事故ります。ここでいう「高い確率」は1割とかなのでノーコンテキストで数値だけ見れば高くはないように見えるかもですが「1割で死ぬ」ようなギャンブルは誰もしたくないはず。1%でもしなくて済むならやりたくないです。そういう意味での「高い確率」で事故は起こります。緊急時にやる可能性のある手順であれば、普段からやっておくのが良いと思うんです。その手順を繰り返し行なえば手順の検証もできますし、うまくできるようにもなります。良いことしかない。
二つ目。「緊急だから」と言って特権が与えられることはしばしばあります。 普段は見れない情報にアクセスできるとか、普段は必要な承認がスキップできるとか。 それが「緊急時」と言うシビアな時にできるなら、なぜ平時にやらないんだ？平時は手を抜いているのか？と言う話です。 これは 「遅れ」なんてない に書いたリカバリの話にも通じるんですが、平時に手抜きなんてしてるはずもありません。 緊急時にやるべきは「頑張る」ではなく、いつも通りに全力を出すことだと思います。 平時に手枷足枷があって全力を出せないのなら、それを取り除きたいものです。
他にも理由は挙げられる気はしますが、緊急時から平時に転用できるものを転用することは有用です。 平時の効率も上がるし、緊急時の事故も減る。もちろん全部できるわけではないので、こんな感じ。
やることの総量も減ってるよね。
「緊急時こそいつも通りにやろう」とは逆方向の動きです。Clean Coderに書かれている「緊急時に安心して守れるような規律を選ぼう」を私はこのように解釈しています。とはいえ、これに則った発言をすると「そんなことしちゃっていいんですか？」のような反応を貰うことも多かったり。でも反応してくれるなら丁寧にコミュニケーションすればいいんですが、フィードバックが得られないと「言ってるからやっていいんだ」となっていないか不安になります。とはいえ、自分たちで作ったルールのせいで鈍足化しているのなら、撤廃すべきだと思うんです。ルールを作ったのは違う人や部署かもしれないけれど、物理法則ではないのだから少なくともその現場や会社によって作られたものでしょう。そう言う意味で「自分たちで作った」と言っています。
私はこの手のプロセス改善は開発者自身が行うべきことだと思っています。 たとえば組織パターンには「開発者がプロセスをコントロールする」があります。
「開発者がプロセスをコントロールする」パターン（パターン名としては呼びづらい名前が多いのが組織パターンの扱いづらさ。でもいい名前思いつかない。。）は、ソフトウェア開発プロセスの最初から最後まであらゆる活動の中心である開発者がプロセスの舵取りをするものです。「プロセス改善は開発者の職責でない」のように思っている方々は正直多いかと思いますが、補完パターンも含め読んでいただけると分かると思いますので、組織パターンの一読をお勧めします。機会があれば書きたいとは思うんだけど、流石に本稿からは割愛。
具体例
いくつか思いつくものを書いておきます。今回書いている内容だけでは説明しきれない飛躍などもありますが、具体例ってそう言うものだと思います。
緊急リリース
緊急時に平時とは異なるリリースフローが取られることはしばしばあります。原因は「そんなフローを回していたら時間がかかりすぎる」とかだったりするのですが、緊急リリースは得てして作業ミスや想定外の操作により二次災害に繋がるものです。リリース作業をする方もドキドキしながらやるので心臓にもよろしくありません。
緊急時も平時と全く同じリリースフローを辿れるようにしましょう。
平時のリリースフローに多重の承認が必要で時間がかかり、緊急時にそれをスキップして良いなら、平時に必要な理由が謎なので撤廃しましょう。緊急時も同じ承認をしているのであれば転用するポイントはありませんが、別の承認でもって簡略化しているのであれば、その簡略化された承認を平時に持ち込みましょう。緊急時だけいる偉い人にしかその権限がないのであれば、その権限を平時も居る人が振るえるように委譲しましょう。
平時に行っているテストが緊急リリース時にスキップして良いのであれば、平時もスキップしましょう。緊急時はリリースを先にしてテストを後にする？であれば平時もそのようにしましょう。「テスト済みのものだけがリリースされる」と言う状態を緊急時に守らなくていいのであれば、平時も守る正当な理由はありません。緊急時はリリースが遅れるリスクとテスト不足のリスクのトレードオフで判断しているのであれば、平時もそのトレードオフをしましょう。「緊急時の振る舞いを平時に取り込む」ではこうなりますが、もちろん「緊急時にも平時通りやる」も取り組む必要はあります。たとえば「テストを効率化して緊急時でも実施できるように高速化する」です。達成すればトレードオフする必要はなく、緊急時もテストしてからリリースしましょう。あ、「テストを後にする」は考えなしにやるのはNGですが、真っ当にシフトライトを検討できるものであればぜひやるべきだと思います。
前述はテストの例ですが、レビューも同様ですし、ドキュメントも同様です。 平時はドキュメントが書かれていないとリリースできないなら、緊急時もその規律を守るのが良いです。緊急時にドキュメントを後回しにするなら、平時も同様に後回しにしましょう。
障害調査
「障害」というと本番障害をイメージするかもですが、ここではあらゆるフェーズでの障害を指します。障害が発生した、緊急だ。ここまではOKでしょう。 障害の調査方法がフェーズ（環境）によって違うことはよくあります。それでいいんでしたっけ？が緊急時の規律の適用。
検証環境でデバッグログを出して調査しているのであれば、本番でもデバッグログを出していないと障害の切り分けができないということです。ログレベルは同じにしておきましょう。本番でデバッグログが多すぎて止めるのであれば、検証環境も同様に止めておきましょう。それだと効率が悪いのであれば、本番障害という緊急の中でも緊急の時に縛りプレイをすることになりますので、その方が私は嫌です。
これはデータベースなどのアクセス権限も同じで、テスト時にデータベースを覗きながら不具合対応をしているのであれば、本番環境でもデータベースを覗けるようにしておく必要があります。でなければ、本番障害（以下略）。
緊急時に焦点をあわせて、その時に使える道具を洗練させるのが良いと思います。一昔前はハードやネットワーク、その他のモニョモニョした制約でなかなかそういうことはやりづらかったので、本番環境と検証環境が違うのは当たり前だったりしました。最近は言及されることも減った気がする 12factor appに「本番／検証一致」があります。12factor appは継続的デプロイに主眼が置かれていますが、環境の一致をIaCなどでやると必然的にアクセス経路やセキュリティ設定なども同等になってきます。本番と一致した環境で開発時から障害調査のやり方を洗練させよう。それが結果的に本番での適切な設定を育てることになるし、緊急時中の緊急時である本番障害の時もいつも通りの調べ方ができるようになり、結果的に良い方向に行くと思うんです。
この文脈だと「緊急時にやれることだけに普段のやれることを制限する」に見えるかもなんですが、そうでもないんだ、と言うだけ言ってみる。著しく効率落とすようなら適用しなきゃいいだけですからね。
関連
この内容に少し関係するのがJJUG CCC 2024 Fallで話した 「役立つログに取り組もう」の114ページです。
構図としては開発や調査が「緊急時」で本番運用が「平時」になりますが、調査の時にログを見るのであれば、本番運用でもそのログが見えるようにしておくのがいいと思います。
コードレビュー
コードレビューにおける緊急時は、時間制約がある中でのコードレビューです。本番障害のリカバリ時のレビューも該当しなくもないのですが、本番障害の対応でコードを修正するという文脈では他の要因も混ざるので、別枠で考えてみてください。プルリクエストを採用して差分レビューを実施するプロセスにおいて「一つのプルリクエストに膨大な変更が含まれる」や「膨大な数のプルリクエストのレビュー依頼が積まれている」というのが緊急時です。
なぜかよくあるのが「変更量が多いから」とレビューの仕方を変えるものです。 変更を見切れない量の変更で、GitHub上でも差分が多すぎて表示されず「差分レビューなんて無理でしょ？」と言ってくる状態になると、えいやでapproveしたりmergeしたりすることがあったりなかったりします。変更が多いからと言ってレビューの仕方を変えるのは緊急時の規律を守れていません。変更が多いものこそ時間をかけてレビューしなければ意味がないはずなのに、変更量が一定を超えると急にレビューにかかる時間が短くなるのは異常と見るべきでしょう。この緊急事態においてプルリクエストレビュープロセスをとっているならば、真っ当な対応があるとすればリジェクトくらいでしょう。
変更が多いからと言って要点だけを確認するようなレビュースタイルに変えるのであれば、変更が少ない平時もそうしましょう。変更が見切れないからマージをして、マージ後にテストやmainで確認することにしているのであれば、平時でもそうしましょう。その方がプルリクエストの滞留時間も減りますし、レビューに費やす時間も短く済みます。
この考え方を進めると、プルリクエストのマージをブロックする条件は「テストやlintなどのチェックを破壊していない場合において、それらが通っている」に行き着いたりします。プルリクエストが全く知らない人からくるOSSや、現場に参画したばかりで何をやらかすかわからない人の振る舞いを確認する必要がある場合、経験の浅い人など教育目的などは別の話ですが、そうでない一般的な現場のプロセスにおいてプルリクエストをゲートで品質担保するのは精度は高くありませんし、前述のような緊急時は突き抜けがちという問題を抱えていると思います。
この話は 脱ブランチファースト （タイトルも内容もいまいちだったなぁとたびたび思うエントリ）で書いているものだったりします。
膨大な数のプルリクエストに対するコードレビューに関してはがTidy First?でも言及されています。こちらはTidyはむしろ特別扱いする方なので、「緊急時も平時も同じように」とは違う話です。要はバランスだよ、うん。
まとめ
（セッションスライドの1ページ。全体は未公開です。）
ということで 緊急時にやっていることを平時でもやる。緊急時だけ許されているパワーを平時も振るう。 そうしたいと思っています。「やっちゃいけない」は思い込みかもしれないし、そんな深い理由がないこともあったりなかったりです。プロセスを改善するための改善案をゼロベースで考えるのはなかなか難しいのですが、緊急時にやっていることにヒントは転がっていたりします。どこかの誰かが言っている有難いプロセスより、自分たちがやったことのあるものなのでイメージもつきやすいし取り込みやすいと思うんです。
最後に念の為。先頭に書いた通り取扱注意です。前掲の図でも「緊急時にだけやること」を残している通り、何でもかんでも取り入れればいいってもんじゃないです。取り入れれるものを取り入れて、平時も実施することで試行回数を増やして洗練し、緊急時に実績のある方法で立ち向かえる領域を増やす。私は保守的な人間なので緊急時の安定の方を重視していて、平時の効率化は副産物だったりはします。安定ありきの効率化だと思います。
追記：「共通部分を大きくする」表現
平時にしかやらないこともあるので、共通部分を大きくする図のほうがわかりやすいかなと思いました。
— HARADA Kiro (@haradakiro) 2025年2月11日
で、緊急時にやることといえば、一時的に1日あたりのトータル時間制約を外すくらいかな。休憩もいつも通り。
あ、スペシャルおやつを追加するもあるな。
描いてみた。
先の図と比較して、作者の力点の違いを答えよ（240文字以内、10点）
