孫子の開発指南（４）：兵は拙速を尊ぶ。（納品篇）

【▪️若き日の失敗】
若い時、道路工事をしていました。ある山道を作るときに工期が足りないから山の右と左から同時に掘削作業を指示しました。中央で道が合体するという画期的な施工方法です。

ご飯を食べるお気に入りのポイントから山頂がよく見えます。あと1週間で貫通だなぁ、というときになんか高さが合わないことに気がつきました。左右で1m、指示内容が間違っていたんです。

…若い私はみなかったことにしました。
…結果はしばらくご飯も食べられない状態になりましたw

【▪️確認作業の重要性】
それ以来、私は仕事をするとき「確認」がすごく多い。企画書を作るときも、骨子を書いたら確認してもらう。下絵を書いても確認してもらう。デジタルにしたらもう一度確認してもらう。

すっごく嫌なんです、手戻りが。やる気ナッシングになるもん。あの若かりしき日から、絶対に確認作業をさぼらないようになりましたw

商品・製品開発にも「確認」がとても大切です。設計書や図面、モックや試作品ができたときに関係者が集まって確認することをDR（デザインレビュー）といいます。システムなら動作テストかな。

【▪️納品物の品質向上】
開発の仕事はプロジェクトの規模によってやり方は変わると思うけれど、絶対に他人の目（できればお客様の目）で細かくチェックしてもらった方がいいです。

孫子はじっくり完璧なものを作ってからみせることを「巧遅」と呼びました。その反対で出来が悪くても素早く見せていくことを「拙速」と呼びました。そして「巧遅より拙速がいいよ（巧遅は拙速に如かず＝こうちはせっそくにしかず）」と教えます。

仕事を任されたときは、まず仕事の内容を細かく言語化して細かいタスクに切り分けます。タスクが少し進んだら拙速でも自分の理解に違いがないか確認をしてもらいます。絶対に引き出しに入れて温めてはいけないよ。後で必ずハマるからさw

確認の積み重ねが、実は納品物の品質だから。

一筆啓上いたします。
「今日の仕事は誰かに確認してもらった？」

シリーズアーカイブはこちらから。
孫子の開発指南序章  ：孫子の開発指南書
孫子の開発指南（１）：彼を知り己をしらば、百戦危うからず。（営業篇）
孫子の開発指南（２）：まず勝って、のちに戦いを求める。（設計篇）
孫子の開発指南（３）：よく戦うものは、人に致して致されず。（PM篇）
孫子の開発指南（４）：兵は拙速を尊ぶ。（納品篇）
孫子の開発指南（５）：戦わずして勝つ。（保守篇）

▪️English Version.

Sun Tzu’s Development Guide (4): Those Who Fight Value Clumsy Speed (Delivery Edition)

(Illustration: An image of Sun Tzu hurrying off to make a delivery.)

When I was young, I worked in road construction. One time, while building a mountain road, we were short on schedule. So I ordered simultaneous excavation from both the right and left sides of the mountain—a revolutionary method where the two sides would merge in the center.

From my favorite lunch spot, the mountain summit was clearly visible. When I thought, “In just one week, we’ll break through,” I noticed the heights didn’t match up—there was a one-meter discrepancy between the two sides because my instructions were off.

…I chose to pretend I hadn’t seen it. …The result? I ended up not being able to eat for a while. lol

Since then, I’ve become obsessed with “verification” in my work. Whether it’s drafting a proposal, sketching an initial idea, or finalizing a digital version, I have it checked every single time.

I absolutely hate rework—it kills my motivation. From those youthful days onward, I vowed never to slack on the verification process.

Verification is also crucial in product development. When design documents, blueprints, mock-ups, or prototypes are ready, stakeholders gather for a Design Review (DR). In systems, that might be equivalent to a functionality test.

No matter the project’s scale, having someone else’s eyes on the details (preferably the customer’s) is essential.

Sun Tzu taught that perfecting something painstakingly before showing it is “exquisitely slow” (巧遅), whereas quickly presenting something—despite its imperfections—is “clumsily fast” (拙速). And he said, “Clumsily fast is better than exquisitely slow.”

Ever been given a vague task like, “Do it roughly—I’m sure someone like Nogucchan can handle it”? When that happens, I break down the task into detailed steps and verify my understanding repeatedly. You must never let things simmer in your drawer—it’s a trap. lol

In the end, this continuous verification is what ensures the quality of your deliverables.

Signing off with today’s final stroke of the brush:
“Did someone verify your work today?”

ポスト LINEで送る シェアする URLをコピー