ミスをした人が謝り、「次から気をつけます」と約束する。それなのに、また同じ失敗が起きる。そんな職場では、何が見落とされているのでしょうか。『おい、とりあえず終わらせろ』を書いたエンジニアのnwiizo（ぬうぃぞう）氏が、自身の経験から伝えます。（構成／ダイヤモンド社書籍編集局）
Photo: Adobe Stock
「自分が悪い」で止まると、次の失敗は防げない
提出したものがダメだったとき、落ち込むかもしれません。
でもそこで思い出してほしいのが、「反省」と「省察」は違うということです。
省察は、そこから「何が起きたか」「なぜそうなったか」「次にどうするか」と検証につなげます。「何が見えていなかったか」を問うのです。
しかし、「自分がダメだった」で止まる反省はそこで思考が止まります。
実際、私が本番でデータベースが落ちた夜もまさにそうでした。
原因を、「デプロイ前の確認を怠った自分が悪い」と片付けるのは簡単だったけど、「何が見えていなかったか」と問い直したら、別のものが浮かんだのです。
確認に使うステージング環境には、本番の100分の1のデータしか入っていなくて、つまり誰がどれだけ丁寧に確認しても、その負荷の問題は再現しなかった。
原因は「私の不注意」ではなく、「本番を再現しない確認環境」の方にありました。「私が悪い」で止めていたら、次は別の誰かが、同じ環境で、同じ事故を起こしてしまう。
優れたチームは「誰が悪かったか」を問わない
エンジニアの世界には、「ポストモーテム（事後検証）」という文化があります。
障害が起きた後、関係者で集まって何が起きたかを振り返る。
このとき優れたチームは「誰が悪かったか」を問いません。「どういう状況なら、誰がやっても同じことが起きたか」を問う。
これをブレームレス（責めない）ポストモーテムと呼びます。
犯人を捜すと、人は情報を隠す。隠された情報は、次の障害をまた呼ぶ。
省察が「何が見えていなかったか」を問うのは、この構造と同じです。
きつい指摘を受けたら、15分離れてみる
個人を責めずに構造を見るには、感情と行動の間に「間（ま）」が要ります。
コードレビューで「この設計、根本から変えた方がいい」と書かれた日、すぐにSlackを閉じてコーヒーを淹れに行きました。
戻ったのは15分後です。画面に向かったとき、さっきまで「全否定された」と感じていた気持ちが、「どの部分が問題なのか」という問いに変わっていた。
感情と行動の間に15分の「間」を置いただけで、レビュアーの言葉が脅威ではなく情報として読めるようになったのです。
必要なのは「落ち込まないこと」ではなく、「落ち込んだ後に何を見るかを決めておくこと」です。
先に感情と行動の間に「間」を入れる。
次に、その出来事を短く記録する。最後に、「見えていなかった前提」を考える。
この順番を守れば、きついフィードバックも燃料に変えやすくなります。
本書の内容
まえがき 完璧を目指して、今日も終わらなかった
「もう少し良くしてから」の罠
「60点で出す」という革命
私たちには「終わらせる技術」が必要だ
第1章 おい、部屋を掃除しろ ―― 「完了」の正体を知る
「擬似完了感」のループに陥ってはいけない
「部屋の掃除」は終わらせるための小さな練習 ―― 小さな完了は複利のように効く
「わかってから出す」は動かない言い訳
あなたの「まだ60点」は、相手の「もう十分」かもしれない
「真面目な完璧主義」は「怠惰な先延ばし癖」と同じ
「良い」の基準を自分の中だけにとどめるな
先延ばしは「明日の自分への丸投げ」で進行する
「今日こそ頑張ろう」を繰り返さないための5ステップ
第2章 おい、やることを絞れ ―― ステップ1「決めろ」
何も聞かないまま2週間過ごすな
スコープを絞れ
「良い感じ」は測れないから終了条件を言語化する
ゴールは近い未来に置く
60点とは妥協ではなく「何を捨てるかを選ぶ」こと ―― 優秀なエンジニアも「諦めること」を決めて動く
早く聞く人が一番偉い ―― 「この方向で合ってますか？」を最初の30分で聞く
「山の間で立ちすくむロバ」になるな ―― 「十分良い」を選ぶ
小さな決定を頭の外に出す
第3章 おい、完了を祝え ―― ステップ2「分けろ」
やるべきなのに手が動かないのは、タスクがでかすぎるから ―― 「根性」より「構造」を疑え
「ただ手を動かせば終わる作業」に悩まないために ―― 「わからなさ」には5つの層がある
「全部わからない」は、書き出す前の幻想
完了を祝え
自分の「動ける粒度」を知る
動いたから見えた問題は前進の証拠
第4章 おい、手を動かせ ―― ステップ3「始めろ」
完璧な準備は、永遠に来ない ―― 方向だけ確認してから走れ
やる気を待つな ―― でも、体調は本当に大事だ
「本来の自分」という幻想を捨てる ―― 言語化も60点でいい
無駄かどうかの「判断そのもの」を消す環境設計
「美しい暮らし」の話にしないこと
「馬鹿げた小ささ」が効く ―― 「毎日30分」が失敗を作る
完璧主義者こそ、AIに叩き台を作らせろ
思わず始めてしまう「トリガー」を設定せよ
「失敗しても致命傷にならない構造」を先に作る
通知を切れ、視野を狭めろ ―― 「どうせ何をやっても変わらない」という冷笑は完璧主義の変形
第5章 おい、60点で出せ ―― ステップ4「出せ」
成果物と人間の価値は別物 ―― 「もし後輩がこれを出してきたら？」と想像する
シンプルなものをシンプルなまま出せ ―― 「早く終わってしまった気まずさ」を超える
早めのフィードバックは自分の死角に気づかせてくれる ―― アウトプットの質を落とす記憶の書き換えに抗う
「評価されたい」と「60点で出す」は両立する
助けが必要な状態を、ひとりで抱え込まない ―― 「60点で出す」のを許されるための関係性の作り方
「後戻りできないポイント」を外さない ―― 完了が先、改善は後
第6章 おい、いいからやり直せ ―― ステップ5「回せ」
「未来に向けたアドバイス」を受け取れ ―― 相手を評価者モードから助言者モードに変える問い
場当たり的な改善は「言葉の裏」を読むことで防げる
フィードバックの価値は受け手の準備で半分決まる ―― 解決法ではなく問題を言語化する
1回のフィードバックから10回使える原則を抜き出せ ―― 「自分は成長している」という感覚に騙されない
優れたチームは「誰が悪かったか」を問わない ―― 感情の処理と構造の理解を分ける
100回夢見るより60点で3回出せ
小さな成功が「地味な確信」を育てる ―― 「高揚感のある自信」より「地味な確信」
失敗など構わない ―― 仮説があれば
あとがき ―― あなたが終わらせたものを、誰かが待っている
私のおすすめの本を紹介します ―― とりあえず終わらせるために効く本たち
