ソフトウェアにも、声に出す確認が必要な場面がある
鉄道や工場の現場では、指差し呼称が使われています。
対象を指さし、声に出して確認することで、見落としを減らすための習慣です。
ソフトウェア開発では、そこまで目に見える形で確認することは少ないかもしれません。
ただ、私たちの仕事にも「一回間違えると面倒なことになる操作」はあります。
- 本番環境へのデプロイ
- DBマイグレーション
- 権限設定の変更
- メール配信
- 外部APIキーの差し替え
- 削除を含む管理画面操作
こういう場面では、指差し呼称の考え方を持ち込んでもよいと思っています。
ミスは注意力だけでは防ぎきれない
ミスが起きたとき、
「次から気をつけます」
で終わらせたくなることがあります。
もちろん気をつけることは必要です。
ただ、人間の注意力は疲れます。
急いでいるとき。
通知が多いとき。
似たような画面を何度も触っているとき。
本番と検証環境を行き来しているとき。
こういう状況では、注意力だけに頼るのは危ういです。
そのため、声に出す、チェックリストを見る、画面の環境名を確認する、といった仕組みで補いたいです。
予測の生産性とシフトレフト でも書いたように、問題が起きてから頑張るより、起きる前に止めるほうが楽です。
開発版の指差し呼称を作る
ソフトウェア開発でそのまま指を差す必要はありません。
大切なのは、無意識の操作を意識に戻すことです。
例えば、本番デプロイ前なら次のように確認します。
- ブランチ、ヨシ
- 対象環境、ヨシ
- マイグレーション内容、ヨシ
- 影響範囲、ヨシ
- ロールバック手順、ヨシ
少し大げさに見えるかもしれません。
ただ、危ない操作ほど、このくらいの引っかかりがあったほうが安心です。
声に出すのが難しければ、チェックリストに指を置くでもよいです。
Slackに「本番環境、対象確認済み」と書くのも近い効果があります。
本番環境では、確認の粒度を細かくする
本番作業で怖いのは、ひとつの勘違いがそのまま影響につながることです。
たとえば、管理画面で記事を更新するだけでも、
下書きなのか公開済みなのか。
対象の記事は合っているのか。
タイトルだけなのか本文も変えるのか。
画像やタグは触らないのか。
確認する点はいくつもあります。
開発者は、普段から似た画面を見慣れています。
見慣れているからこそ、確認を省いてしまうことがあります。
本番作業では、見慣れているものほど声に出す。
これは自分へのブレーキとして機能します。
AI時代ほど確認の型が必要になる
AIで作業が速くなると、確認を飛ばしたくなる場面も増えます。
コード生成、設定変更、SQL作成、ドキュメント更新。
AIは多くの作業を前に進めてくれます。
ただ、速く出てきたものほど、人間側の確認が必要です。
AIが作ったSQLを本番で実行する。
AIが提案した権限変更をそのまま入れる。
AIがまとめた手順を確認せず実行する。
これは危ないです。
AIの考え方を、自分の考え方に逆輸入する でも触れたように、AIの出力を使うほど、人間側の問いと確認が必要になります。
チームで使える形にする
指差し呼称は、個人の注意力を上げるだけではありません。
チームで同じ確認を共有するためにも使えます。
例えば、デプロイ前チェックをテンプレート化しておく。
本番操作の前に、Slackで決まった項目を貼る。
レビュー時に「この変更は本番データに触るか」を確認項目に入れる。
こうすると、確認が個人の経験に閉じません。
新しく入った人も、何を怖がるべきかがわかります。
未来の自分も、疲れている日に助けられます。
小さい確認ほど形にしておく
確認の仕組みは、重くしすぎると続きません。
毎回長いチェックリストを埋めるとなると、形だけになってしまいます。
そのため、まずは事故につながりやすい作業だけに絞るのがよさそうです。
たとえば、自分なら次の3つから始めます。
- 本番環境を触る前
- DBや権限を変更する前
- 外部に通知やメールを送る前
この3つだけでも、立ち止まる価値があります。
小さい確認を続けると、「これは一度止まったほうがよい作業だな」と身体が覚えていきます。
仕組みというと大げさですが、最初はそのくらいの感覚でよいと思っています。
まとめ
指差し呼称は、ソフトウェア開発にも合う考え方だと思います。
本番環境、権限、DB、メール配信、外部連携。
こうしたミスの重い作業では、無意識に進めない仕組みが必要です。
声に出す。
チェックリストを見る。
Slackに確認を書き残す。
どれも小さい行動ですが、ミスを防ぐ入口になります。
自分も危ない操作の前ほど、一度立ち止まる型を作っておきたいです。