完璧を求めて妥協ができない。中途半端なものを出して「できない奴だ」と思われたくない。「先のばし」や「完璧主義」を脱するための方法を、『おい、とりあえず終わらせろ』を書いたエンジニアのnwiizo（ぬうぃぞう）氏が伝えます。（構成／ダイヤモンド社書籍編集局）
Photo: Adobe Stock
小さく出し直す
上司からフィードバックをもらったら、取り組むべきは選別です。
すべてを改善しようとしないこと。
他者から見て必要な改善だけ選び、小さく出し直します。
指摘されたことを最優先で潰しつつ、自分の仮説検証は別トラックで走らせる。
1回で10個より、10回で10個。
現に、プログラムの修正を1回で全部やろうとしたレビュー依頼は、なかなか通らなかった。反対に1か所ずつ直したものは、その日のうちに取り込まれた。
全部を一度に直そうとするのは、改善における完璧主義だ。
いかに行動に変換するか
受け手の失敗として顕著なのは、ひとつは「無視」でしょう。
傷つきたくないから蓋をする。
もうひとつは、言われた通りにそのまま直すこと。
考えたくないから脳を止める。
どちらも、自分の頭を使わないことで楽をしています。
必要なのは、受け取った指摘を自分の中で一度分解し、「何を直すか」「なぜ直すか」「どう直すか」を再構成してから動くことです。
受け取った言葉を検証し、自分なりに咀嚼し、行動に変えて戻す。
たとえば、上司から「この資料、結論がわかりにくい」と言われたとき、結論を太字にするだけで終わる人と、「どこでわかりにくくなったんだろう。次回は冒頭に結論を置いてみよう」と行動に落とす人がいます。
1年後、前者はまだ「結論がわかりにくい」と言われていて、後者は「構成がうまい人」と呼ばれているでしょう。
その差を生んだのは才能ではなく、フィードバックを自分の行動に変換したかだけです。
「自分は成長している」という感覚に騙されない
経験上、この変換をしない人が多いと感じています。
長年コードを書いてきたのに、同じ種類の設計ミスを繰り返す。なぜそうなるかというと、経験を積むこと自体が「自分は成長している」という実感を生んでしまうからです。
手を動かした時間が長いほど、「これだけやったんだからうまくなっているはずだ」と思いたくなる。
でも実際には、同じやり方を繰り返しているだけだ。
何を隠そう、私自身がそうでした。
5年目くらいまで、経験の量で勝負していた。たくさんコードを書いて、たくさんレビューを受けました。
でも、ある日気づいたのです。まったく同じ種類の指摘を3年間ずっと受けていたことに。
気づけたのは、メモに書き出してからでした。「自分は詰め込みすぎてしまう」ということがわかると、「分けた方がいいか？」と問えるようになった。
経験の量だけでは、成長は保証されません。経験から原則を抜き出す習慣があってこそ、成長するのです。
具体的なフィードバックには、抽象的な学びが埋まっています。
「グラフを増やして」と言われて、「数字の根拠が見えにくかった」が本当の問題だったとしましょう。この1回のやりとりから、「意思決定者は根拠を視覚で確認したがる」というパターンを抜き出せます。
すると次に別の資料を作るとき、「この資料の読み手は何で判断するか」と最初から考えられるようになる。
具体的な指摘を、その場の修正だけで消費するのは勿体ない。
1回のフィードバックから、10回使える原則を抜き出すのが、一番賢い方法です。
本書の内容
まえがき 完璧を目指して、今日も終わらなかった
「もう少し良くしてから」の罠
「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回出せ
小さな成功が「地味な確信」を育てる ―― 「高揚感のある自信」より「地味な確信」
失敗など構わない ―― 仮説があれば
あとがき ―― あなたが終わらせたものを、誰かが待っている
私のおすすめの本を紹介します ―― とりあえず終わらせるために効く本たち
