「完璧に準備してから始める」をやめてから、エンジニアとしてのアウトプットが変わった話

※ 30日間の無料体験。いつでも解約可能。

「設計が完璧に固まってから実装に入ろう」「もう少し調べてからプルリクを出そう」「完成度を上げてからレビューに出したい」。エンジニアとして働いていると、こういう思考が積み上がっていく時期がある。技術の世界では正確さや品質が問われる場面が多い。だから「準備が整ってから動く」という習慣は、むしろ真剣に仕事に向き合っているからこそ身につく側面もある。

しかし、この習慣がある時点から足かせになっていたことに気づいた。コードを書き始めるのが遅い。プルリクを出すのを躊躇する。アウトプットの速度が落ちていた。そして気づかないうちに、フィードバックを受ける機会自体が減っていた。チームのスプリントは回っているのに、自分のタスクだけが「まだ準備中」の状態で宙に浮いていた。

この記事では、「完璧に準備してから始める」という思考パターンをどう手放したか、そしてそのきっかけになった5冊の本について書いていく。コーディングの現場で実際に効いた3つの実践も紹介するので、明日から試してみてほしい。結論から言うと、完璧主義をやめることとアウトプットの質を上げることは矛盾しない。むしろ、60点で出して改善するサイクルを繰り返すことで、最終的な品質は高くなっていった。何年も「準備が整ってから動く」を繰り返してきた人でも、意識を変えるきっかけは小さな習慣から生まれる。

「完璧になってから動く」が習慣になっていった理由

こうした思考パターンが身につくのには、それなりの背景がある。エンジニアリングの仕事において、バグや設計ミスは後になって修正コストが跳ね上がる。「早めに間違いを発見する」という意識はチーム全体の生産性を上げる上で重要なことだ。だからこそ、「ちゃんと考えてから動く」という姿勢は、実際に現場で評価される場面もある。

もう一つの理由は、未熟さへの恐れだ。経験が浅いうちは、中途半端なアウトプットを出して批判されることへの恐れが、「もう少し準備してから出せばよかった」という後悔と結びつく。その繰り返しの中で、「完成してから出す」という行動パターンが強化されていく。これ自体は悪い習慣ではない。技術の深さを求める姿勢は、長期的な成長の土台になる。

問題は、この習慣が成長の機会を奪うことにある。フィードバックは「出した後」にしか得られない。完成度を上げてから出そうとする時間の中では、何も改善されない。準備に費やした時間は、実際のフィードバックサイクルに変換されなかった時間でもある。アウトプットを先延ばしにしている間、チームメンバーは小さな失敗と修正を繰り返しながら着実に成長している。この非対称性に気づいたとき、準備への執着を少しずつ手放す必要性を感じた。

「考えてから動く」が「考えて、止まる」になるとき

準備に時間をかけすぎると、思考が拡散してしまうことがある。設計を固めようとして関連する論文を調べ、実装方法を調べ、ベストプラクティスを調べているうちに、「最初に自分が解こうとしていた問題」から離れてしまうことがある。これは思考が「収束」ではなく「拡散」に向かっているサインだ。

エンジニアとして経験を積むにつれて、「知識の積み上げ」と「動き始めること」のバランスを取ることが重要になってくる。準備は必要だが、ある一定のラインを超えると「動いてみなければわからないこと」のほうが圧倒的に多くなる。そのラインを意識的に定めることが、「考えて止まる」状態を抜け出す鍵になる。実際に手を動かし始めてから見えてくる問題は、どれだけ事前に考えても見えないものが多い。

「アウトプットが遅い」という評価の背景にあること

チームで仕事をしていると、アウトプットの速度は他のメンバーとの比較で自然と見えてくる。「あの人は設計が終わらないうちに実装に入っているように見えるのに、なぜかきれいに仕上がってくる」という場面を目撃したことがある。話を聞くと、「最初から完璧を目指していない。動きながら設計を詰めていく」と言っていた。

完璧な準備を目指すエンジニアと、動きながら改善するエンジニア。この二人の成長速度の差は時間が経つにつれて広がっていく傾向がある。理由はシンプルで、フィードバックを受ける頻度が異なるからだ。1ヶ月で10回のフィードバックサイクルを回すエンジニアと、3回しか回せないエンジニアでは、同じ期間に得られる学びの量がまったく異なってくる。スプリントレビューやコードレビューは、出さない限り始まらない。

「完璧主義」という言葉の中身を分解してみると

「完璧主義」という言葉は、しばしばネガティブな文脈で使われる。しかし、その中身を丁寧に分解してみると、問題の本質が見えてくる。完璧主義には2種類ある。一つは「高い基準を持ち、それに向けて改善し続ける」という健全な完璧主義。もう一つは「失敗への恐れから、完成したと判断できるまで動き出せない」という不健全な完璧主義だ。

エンジニアの仕事において、前者は成長の原動力になる。コードレビューで指摘を受けたとき、次のプルリクでそこを改善しようとする姿勢は、前者の完璧主義から来ている。問題になるのは後者だ。「このコードを出したら批判されるかもしれない」「設計が甘いと思われるかもしれない」という恐れが、アウトプットのタイミングを遅らせる。この恐れは、裏を返せば「他者の評価への依存」でもある。

アウトプットの完成度を他者の基準で定義しようとするとき、それは「出せるレベルに達するまで動かない」という形でブレーキになる。自分の仕事のアウトプットを「60点で出す」という感覚を持てるかどうか。これが、この習慣を変えるための最初のカギだった。60点で出したプルリクから返ってくるフィードバックは、多くの場合「設計・方向性に対するもの」だ。このフィードバックこそが、100点を目指す前に受けておくべき最も重要な情報だとわかってくる。

「60点で出す」がなぜ難しいのか

60点でプルリクを出すことは、頭ではわかっていても実行が難しい。なぜか。それは「60点」の基準を自分で設定しなければならないからだ。他者からの評価を基準にしているうちは、60点の定義ができない。100点かどうかわからないから、出せない。この状態では「完成度の判断」を他者に依存し続けることになる。

ここで必要になるのは、「自分の中の基準を持つこと」だ。「この問いに対して、今の自分が出せる範囲で答えを出した」という感覚を持てるかどうか。これは技術的なスキルではなく、思考の習慣だ。「ゼロ秒思考」の著者・赤羽雄二氏は「メモを書く速度で思考の質は変わる」と述べている。素早く手を動かすことで思考が完結するという発想は、エンジニアのプルリク作成や設計ドキュメントの作成にもそのまま応用できる。「書きながら考える」ことで、準備が終わる前に動き出すことができる。

「動きながら完成させる」思考を身につけるために

動きながら完成させる習慣は、意識的に練習しなければ身につかない。一つの方法は、「作業に入る前に今日この作業でどこまで完成させるかを先に言語化する」ことだ。ゴールを設定してから動くと、「完璧になるまで動けない」という状態が起きにくくなる。今日の作業のゴールが「認証機能の基本実装をプルリクに出す」であれば、それが完成したら出す。エラーハンドリングやリファクタリングは次のプルリクでやる。スコープを分割することで、完璧主義の対象を狭めていく。

もう一つの方法は、「今日のハイライトを決めること」だ。時間術大全の著者ジェイク・ナップとジョン・ゼラツキーは、1日に1つの「ハイライト」を決めることを推奨している。今日最も集中すべき1件を決めてしまえば、完璧主義の対象を絞り込むことができる。「全部完璧にしよう」から「このハイライトだけは集中して仕上げよう。その他は70%でいい」という思考シフトが自然と起きてくる。

アウトプットの質とスピードを変えた5冊

ここからは、「完璧に準備してから始める」という習慣を変えるきっかけになった5冊を紹介する。いずれもAudibleで配信されており、コーディング中や通勤中に耳で聴けるため、繰り返しインプットするのに適している。これらの本をすべて読み終えてから動こうとする必要はない。1冊の中から1つの習慣を取り出して試してみる。その繰り返しが、考えすぎを手放すプロセスになる。

ゼロ秒思考（赤羽雄二）

「頭の中にあることを、1分間でメモに書き出す」というシンプルなトレーニングを軸に、思考の速度と質を上げる方法を解説する一冊だ。この本が「動き始めること」に効いてくる理由は、「考えること」と「書き出すこと」を同時に行うことで、思考が完結しやすくなるという点にある。エンジニアが設計を練るときに「頭の中だけで考え続ける」より「ラフでもいいから紙に書き出す」ほうが速く考えがまとまることが多い。

著者の赤羽氏はマッキンゼーで14年間経営コンサルタントとして働いた経験を持ち、本書のメソッドは組織の現場で実際に使われてきたものだ。コーディングを始める前に、今日のタスクと解くべき問いを1分でメモに書き出す習慣をつけてみると、「準備に時間をかけすぎる」という状態が自然と減ってくる。Audibleで繰り返し聴くことで、「書きながら考える」アプローチを日常の判断に染み込ませていける。通勤中や昼休みに耳から繰り返しインプットすることで、習慣として定着しやすくなる。

すぐやる！「行動力」を高める科学的な方法（菅原洋平）

「すぐやれない」のは意志力の問題ではなく、脳と環境の設計の問題だという観点から、行動力を上げる具体的な方法を解説する一冊だ。著者の菅原洋平氏は作業療法士として脳と行動の関係を研究してきた専門家で、神経科学・認知科学に基づいた行動変容の方法を提案している。

エンジニアが「完璧に準備してから始めよう」と思うとき、その背景には脳の防衛反応が働いていることが多い。本書が解き明かすのは、「なぜ人は先延ばしにするのか」という仕組みと、それを乗り越えるための環境設計だ。「まず30秒だけやってみる」という着手のハードルを下げる方法は、設計フェーズからコーディングへ移行するタイミングでそのまま使える。着手してしまえば続けられる、という脳の仕組みを知っておくだけで、動き出しが変わる。Audibleで通勤中に聴きながら、翌朝の仕事に即応用できる密度の高さがある。

エッセンシャル思考（グレッグ・マキューン）

完璧主義とエッセンシャル思考は、一見相反するように見えるが実は補完的な関係にある。完璧主義が「すべてを完璧にしたい」という方向に向かうのに対し、エッセンシャル思考は「本質的なものだけを完璧にし、それ以外は手放す」という方向に向かう。エンジニアにとっての実用は、「このプルリクで今回本当に解くべき問題は何か」を最初に定義することだ。「何でもやろうとする」から「これだけに集中する」に切り替えたとき、アウトプットの質とスピードは同時に上がる。スコープを絞ることで、完璧主義の対象が狭まり、動き出しが速くなる。

著者のグレッグ・マキューン氏はシリコンバレーのビジネスパーソンを対象にしたコンサルタントで、本書は世界中のエンジニアやビジネスパーソンに読まれている一冊だ。Audibleで通勤中や作業合間に繰り返し聴くことで、「何を選ぶか」の判断力が日常に染み込んでいく。特に業務量が増え続けているタイミングで聴き直すと、断捨離すべきタスクが明確に見えてくる。

時間術大全（ジェイク・ナップ、ジョン・ゼラツキー）

本書の核心にある「ハイライト戦略」は、「今日1日で最も重要な1つのこと」を朝一番に決めることだ。この習慣が完璧主義と相性が良いのは、ハイライトを決めることで「今日の完璧主義の対象」が絞り込まれるからだ。「全部完璧にしよう」から「このハイライトだけは完璧にしよう。その他は70%でいい」という思考シフトが起きる。1日の設計を先に決めることで、完璧主義が向かう先を絞り込める。

著者の一人であるジェイク・ナップ氏はGoogleデザインスプリントの生みの親として知られており、本書の方法論は実際の開発現場から生まれたものだ。実際にこの習慣を取り入れてから、「どこかで何か大切なことを見落としているかもしれない」という漠然とした不安が減った。ハイライトを決めることで、1日の終わりに「今日やるべきことはやった」と言える基準が生まれる。Audibleで通勤中に繰り返し聴くことで、この時間設計の思考が日常に定着していく。

大事なことに集中する（カル・ニューポート）

完璧主義と深い集中は密接に関わっている。完璧主義が問題になるのは多くの場合、「表面的な作業を多く抱えながら、すべてを完璧に仕上げようとする」ときだ。一方で深い集中状態（ディープ・ワーク）に入ることができれば、短い時間でも質の高いアウトプットが生まれやすくなる。本書が特にエンジニアに刺さるのは、「知的集中を要する作業に徹底的に向き合うことが、キャリアの差別化につながる」という主張だ。

単純作業やマルチタスクに時間を使うのではなく、深い思考が必要な問題に集中した時間を積み上げることで、技術者としての競争力が生まれる。「浅い作業」と「深い作業」を区別し、1日の中でディープ・ワークの時間をどこに置くかを設計できるエンジニアは、同じ8時間でも得られるアウトプットの密度が変わる。Audibleで繰り返し聴きながら、コーディングセッションの設計に応用していける一冊だ。

本書で紹介されている「ディープ・ワークのスケジュール化」は、エンジニアの働き方にそのまま転用できる。朝の2時間を通知オフにして設計や実装に充てる。その時間は完璧主義であっていい。しかしその時間以外は「浅い作業」として速く処理する。この使い分けが、アウトプットの量と質を両立させる構造を作ってくれる。

「完璧主義」を手放すための、最初の3つの行動

5冊の内容を日常の仕事に落とし込むために、実践してみて効果があった3つの行動を紹介する。どれもすぐに試せるシンプルなものだ。まず1つだけ選んで、明日から試してみてほしい。特別な準備は必要ない。今日の仕事から始められる。

①「今日のプルリクの完成定義」を先に書く

作業を始める前に、「このプルリクで今日実装する範囲」を3行以内で書いておく。スコープが明確になると、「ここまで来たら出せる」というラインが見えてくる。完璧主義の対象が「プルリク全体」から「今日のスコープ内」に絞られる。この習慣はゼロ秒思考のアプローチと相性が良く、1分で書き出すだけでいい。

「今日のゴールは何か」を書いておくことで、作業中に方向が変わりにくくなる。エラーハンドリングやリファクタリングなど「今日のスコープ外」のことが気になり始めたら、別のメモに書き出しておき、次のプルリクでやることにする。この「外に出す」行為が、完璧主義のブレーキを緩めてくれる。

②「60%で出す日」を週に1回意図的に作る

すべてのプルリクを60%で出す必要はない。しかし、意識的に「今週はこのタスクだけ60%で出してみる」という実験をしてみることをお勧めする。60%で出したプルリクに返ってくるフィードバックは、多くの場合「60%の完成度に対するもの」ではなく「設計・方向性に対するもの」だ。

このフィードバックこそが、100%を目指す前に受けておくべき情報だとわかってくる。プルリクの説明文に「今の時点でのレビュー観点」と「残りのスコープ」を書いておくことで、レビュアーも判断しやすくなる。「60%で出す」ことが迷惑になるのではなく、チームの判断コストを下げることにつながるという感覚がついてくる。

③「まず5分だけやってみる」から着手する

「すぐやる！」で学んだ最もシンプルな実践は、「とにかく5分だけ着手する」という方法だ。5分経っても続けたくなければやめていい。ほとんどの場合、5分経ったら続けている。これはエンジニアがタスクを先延ばしにするときの仕組みを逆用している。

人は「やる前のほうがやっている最中より心理的コストが高く感じる」という傾向がある。着手してしまえば、止まることのほうが難しくなる。「完璧な準備が整ってから始めよう」という思考が働き始めたら、まず5分だけエディタを開いてコードを書いてみる。それだけで、準備不足の不安よりも「実際に動かしながら確認する」モードに切り替わりやすくなる。

よくある質問

まとめ

「完璧に準備してから始める」という習慣は、丁寧さや誠実さから来ている場合が多い。しかし、その習慣がアウトプットのタイミングを後ろ倒しにし、フィードバックを受ける機会を減らしているとすれば、一度立ち止まって考えてみる価値がある。成長のエンジンはフィードバックサイクルであり、そのサイクルを速くするためには「出す」タイミングを前に引き寄せる必要がある。

今回紹介した5冊はそれぞれ異なる切り口で「動き出すための思考」を教えてくれる。ゼロ秒思考は「書きながら考える」速度を上げ、すぐやる！は「着手のハードル」を下げ、エッセンシャル思考は「やらないことを決める」勇気を与え、時間術大全は「今日1つに集中する」設計を助け、大事なことに集中するは「深い仕事の時間」の価値を示してくれる。この5冊は仕事の哲学そのものを問い直すための入り口になる。

すべてを一気に読む必要はない。まず1冊選んで、Audibleで聴きながら翌日の仕事に応用してみることから始めてほしい。耳でインプットしながら手を動かすサイクルが生まれると、「完璧主義」の呪縛が少しずつ薄れていく感覚が出てくるはずだ。Audibleには30日間の無料体験がある。今日ここで1冊選んで、明日の仕事から「60%で出してみる」という実験を始めてみてほしい。

※ 30日間の無料体験。いつでも解約可能。