仕様書を書くのを、やめた話です。
こんにちは、リノエッジ代表の原田祥吾＠ベトナムです。
突然ですが、仕様書を書くの、疲れませんか？
「ここのボタンを押すと、画面がこう遷移して、データはこう処理されて……」
頭の中には作りたいもののイメージがあるのに、それを開発会社に伝えるために、膨大なドキュメントを作る。その作業だけで何日も、ときには何週間も潰れてしまう。
そして苦労して伝えたはずなのに、出来上がってきたものを見て愕然とする。
「……いや、そうじゃないんだよな」
そんなとき、頭をよぎりませんか。「『いい感じでやっといて』の一言で通じたら、どれだけ楽だろう」と。
「丸投げはNG」と、みんな言うけれど
「システム開発 丸投げ」で検索してみてください。多くの記事が、同じことを言っています。
「丸投げは危険」「発注側にも責任がある」。
正しいと思います。実際、丸投げで炎上したプロジェクトを僕は何件も見てきました。そして白状すると、僕自身も長いこと「仕様書をください」と言う側の人間でした。書いてもらわないと、こちらが困るので。
でも、ずっと引っかかっていることがあるんです。
行きつけの店では「おまかせで」の一言が成立するじゃないですか。あれ、冷静に考えたら完全な丸投げです。でも失敗しない。むしろ自分で注文するより良いものが出てくる。
つまり問題は、丸投げするかどうかじゃない。相手が、あなたの文脈を持っているかどうかなんです。
嫌いな食材も、好みの火加減も知らない初めての店で「おまかせで」と言えば、そりゃ事故ります。だから僕は、あの「丸投げはNG」を「文脈を持っていない相手への丸投げはNG」と読んでいます。
ちなみに、ちゃんとした店ほど、初めての客には先に聞いてきますよね。「苦手なものはありますか？」と。あれが、文脈の取りに行き方です。この話はあとでもう一度出てきます。
仕様書とコードとプロトタイプが、別のことを言っていた
文脈の話をする前に、ドキュメントを信じすぎて起きたことを一つ話させてください。
うちで進めている、ある子育て支援アプリの案件です。あるとき気がつけば、仕様書と、ソースコードと、プロトタイプの3つが、それぞれ少しずつ別のことを言っている状態になっていました。
誰かがサボったわけではありません。仕様書は直され、コードは進み、プロトタイプは先を走る。動いているプロジェクトでは、放っておくとドキュメントと現実は自然にずれていくんです。そして、どれが正しいのか、誰にもわからなくなる。
このとき開発リードと話していて出た言葉があります。
「要件が間違っていたら、100時間かけた開発も無意味になる」
このひと言が、僕たちのやり方を変えました。100ページ近い仕様書を「これで合ってますか」とまるごと確認してもらうのをやめて、1問ずつ、「この画面のこの動き、こうですよね？」と確認する方式に変えたんです。
遠回りに見えますよね。でも、これが一番速かった。少なくとも、確認のたびに次の質問が減っていったのは事実です。
100ページの承認は、実は誰も全部読んでいません。読めるわけがないんです、本業がある人に。でも1問なら、誰でも即答できる。そして答えが積み重なるほど、チームはお客さんの文脈を吸収していきます。
文脈は「指示」では渡らない
じゃあ、文脈ってどうやったら共有できるのか。
僕がそれを最初に突きつけられたのは2012年、ホーチミンに来たばかりの頃でした。日本の大手メーカーの案件で「1ピクセルずれている」という品質指摘をベトナム人メンバーに伝えたら、真顔で聞き返されたんです。
「なぜ日本人は、そこにこだわるんですか？」
言葉に詰まりました。日本にいた頃の僕は、それを「品質」と呼んで、一度も疑ったことがなかったからです。この画面が誰に使われるのか、発注元がどんな基準でものを見ているのか。僕だけが知っていて、言葉にして渡したことがなかった。
その後、僕は一方的に指示するのをやめて、「どうしたらいいと思う？」と悩みごと相談するやり方に変えました。そうしたら、バラバラだった6人が、一つのチームになったんです。言われる前に気づく人たちになった。創業のころのこの話は、別の記事に書きました。
ちなみに「1ピクセルの質問」をしてきた本人が、いまのうちのCTOです。やり方は、いまも変わっていません。
ラボ型開発なら、仕様書が要らなくなる理由
「来月の商戦前に、あの入力画面をサクサクにしておいて」。半年付き合ったチームには、このくらいの言い方で通じる場面が増えていきます。同じメンバーがあなたのビジネスの数字と事情を聞き続けるから、文脈が貯まっていく。うちがラボ型（専属チーム）という形を続けている理由は、結局これです。単価の話ではなくて。
ただ、正直に言うと、ラボ型は万能ではありません。専属チームが文脈を吸収するまでには時間がかかるし、任せきりにはできず、対話の時間も必要です。契約した翌日から以心伝心、にはならない。ここは先に言っておきます。
文字より先に、動くものを見せる
それでも、認識のズレは起きます。人間なので。
そこで僕たちは、開発に入る前にAIで「動く完成予想図（モックアップ）」を作って見せることにしています。ポイントは速さです。いまのAIは、画面のモックアップを打ち合わせのその場で出せるところまで来ました。
「こんな画面イメージですか？」
「あ、ここはもう少し大きくしたいな」
「じゃあ、これでどうでしょう」
「そうそう、これこれ！」
このやり取りを、コードを書き始める前に済ませてしまう。文字で100往復していた確認が、動く画面を囲む1回の会話に変わります。
手戻りが何％減ったとか、かっこいい数字はここに書けません。ちゃんと測っていないので。ただ、完成してから「思っていたのと違う」と言われる、あの一番つらいやり取りが起きなくなった。順番を「作ってから見せる」から「見てから作る」に変えただけで、です。
熱量だけ、持ってきてください
長くなりました。ここまで読んでくださってありがとうございます。
もしいま、進まない開発プロジェクトや、これから始まる要件定義に頭を抱えているなら、これだけ持ち帰ってもらえたら十分です。
あなた一人で、すべてを完璧に決める必要はない。
完璧なドキュメントより、「こんなふうに楽になりたい」という熱量のほうが、僕たちにはずっと大事な入力です。文脈はこちらが取りに行きます。あの店の「苦手なものはありますか？」と同じように、1問ずつ。
まずは仕事の話でなくて構いません。「システム周りで、こんなことにモヤモヤしてるんだよね」——そんな雑談から始めませんか。
それと、ホーチミンに来ることがあればぜひ声をかけてください。行きつけのOKRA FoodBarにお連れします。おいしいものを食べながらなら、モヤモヤの一つや二つ、だいたい笑い話になるので。
【今回のまとめ】
- 丸投げの失敗は、丸投げのせいじゃない — 文脈を持たない相手に投げるから失敗する。初めての店で「おまかせ」が事故るのと同じ。
- 100ページの承認より、1問ずつの確認 — 分厚いドキュメントは誰も読めない。小さい確認の積み重ねが、チームに文脈を蓄積させる。
- 文字より先に、動くもの — AIモックアップを開発前に見せて、「思っていたのと違う」を完成前に潰す。
よくある質問
ラボ型開発と請負契約は、何が違うんですか？
請負契約は「仕様書に書かれたものを納品する」契約で、仕様書がすべての基準になります。ラボ型開発は専属チームを一定期間確保する契約で、仕様は走りながら1問ずつ固めていけます。仕様書が不要になるわけではありません。「分厚い事前ドキュメント」から「動くモックと確認の記録」へ形が変わる、というのが実感に近いです。詳しくはラボ型開発のサービスページにまとめています。
システム開発を丸投げしたい場合、発注側は何をすればいいですか？
残すべきは「判断」だけです。選択肢と判断材料を揃えるのはチームの仕事で、あなたが決めるのは「AとB、どちらの体験にしたいか」。それも1問ずつ聞かれる形なら、まとまった時間は要りません。逆に、文脈を渡す前に全部を任せると本文で書いた「初めての店のおまかせ」になります。何を渡せばいいかは無料チェックリストで確認できます。
開発が途中で止まっているプロジェクトでも相談できますか？
できます。仕様書とコードと実物が食い違って、どれが正しいのかわからない——という状態は、どのプロジェクトでも起きます。そういうときこそ、1問ずつの確認で「いま何が正しいか」を作り直すやり方が効きます。状況が整理できていなくても、モヤモヤのまま下の壁打ちで話してもらえれば大丈夫です。
モヤモヤが少し具体的になってきたら、下の壁打ちでそのまま話してみてください。
そのモヤモヤ、まず原田に話してみませんか
あなたのビジネスの現状を伺い、「どこで認識がズレているか」を一緒に探す壁打ち相手になります。文脈を共有した「ラボ型チーム」の作り方も、具体的にお話しできます。
15分の壁打ちを予約する → 無料チェックリストを見る
東京とベトナムの二拠点で、ITオフショア開発・海外進出支援事業を展開。「気合いより仕組み」を信条に、不透明になりがちな越境ビジネスを構造化する経営者。「個人のスキル」ではなく「再現性のある品質」を組織と顧客へ提供することにコミットしています。