「良かれと思って直しておきました」で、最終版がわからなくなるバグ。助け合いにも、ロックが要る

② 担当のバグ

「良かれと思って直しておきました」

2026.10.30

※本記事にはプロモーション（広告）が含まれています。

『良かれと思って直しておきました』――。この記事では、ビジネスの現場で起きるこの現象の裏にある「OSのバグ」を、アーキテクトの視点で解剖します。

よくある場面

夕飯のカレー。煮込んでいる途中の鍋を、通りがかった家族が味見して、塩をひとつまみ足していきます。しばらくして、別の家族も味見をして、またひとつまみ。作っていた本人はそれを知らずに、仕上げにもうひとつまみ。

できあがったカレーは、しょっぱい。でも、誰も悪いことはしていません。全員が「良かれと思って」塩を足しただけです。そして、誰が入れすぎたのかは、もう誰にもわかりません。職場でも、これと同じことが起きています。

先輩が作った資料を見ていて、フッターの不備と、いくつかの誤字脱字に気づきました。先輩は忙しそうです。これくらいなら、自分が直しておけばいい。良かれと思って、手元のファイルを修正して共有しました。

ところが、先輩も同じ時間に、同じ資料を直していました。先輩のファイルには、先輩が加えた変更。自分のファイルには、フッターと誤字の修正。どちらも「最新版」です。しかも、自分が直したのは、最終版ではありませんでした。

フォルダには「資料_v5」「資料_v5_修正」「資料_v5_最終」が並び、どれが本当の最終版なのか、誰にもわからなくなりました。結局、二つのファイルを見比べて、手作業で統合し直すことに。誤字を直したはずの時間は、混乱を片づける時間に変わってしまいました。

システムの世界では、二つの処理が同じデータを同時に書き換えると、片方の更新がもう片方に上書きされて消えてしまいます。「ロストアップデート（更新の消失）」と呼ばれる、よく知られた不具合です。

だから多くのシステムは、書き込む前に「今から私が書きます」と宣言して、ほかの処理が触れないように鍵をかけます。これを「ロック」といいます。職場の「良かれと思って」には、このロックがありません。

1つ目は、善意は「宣言」にならないことです。「直しておきました」は、書き込んだあとの報告です。書き込む前の確認ではありません。持ち主である先輩は、ほかの誰かが同じファイルを触っていることを知りませんでした。

2つ目は、二人が書き込んだ瞬間に、最終版の持ち主が消えることです。どちらのファイルが正しいのかを決める人がいなくなります。ファイル名の「最終」や「修正」は、持ち主の代わりにはなりません。「最終」とつけた瞬間に、次の「最終_2」が生まれる準備が整います。

3つ目は、善意は振り返られないことです。混乱が起きても、直した側は良かれと思っていたので責められません。先輩も、手伝ってくれた後輩を責めにくい。誰の手順の問題でもないことになり、次も同じことが起きます。

小さな誤字の修正が、なぜ大きな混乱になるのか。それは、修正の中身ではなく、書き込みの手順が設計されていないからです。あなたの「良かれと思って」は、誰のロックを外しているでしょうか？

他人のファイルに手を入れる前に、持ち主に一言だけ確認します。返事が来るまでは、書き込みません。

「誤字を見つけたので、今から直してもいいですか？今、このファイルを触っていますか？」

システムのロックと同じで、大事なのは「今、誰が書いているか」を全員がわかる状態にすることです。

確認にかかるのは10秒です。混乱を片づけるのにかかる時間とは、比べものになりません。

ここまでが、最初の一手です。この一手を習慣にして、同じバグを繰り返さない仕組みにするための残りの手順は、noteで公開しています。

ここから先の具体的な解決策・コマンドは、noteの記事で公開しています。

『エンジニアリング組織論への招待』（広木大地）
チームの問題を「不確実性」と「コミュニケーション」の構造から読み解く一冊。誰が決め、誰が書き込むのかを設計するという考え方のヒントになる。
▶ 楽天で探す
▶ 耳で読むなら：新作続々追加！オーディオブック聴くなら – audiobook.jp