外部の会社に開発を頼むとき、多くの企業がまず「見積もりをください」と言います。当たり前の順序に見えますが、この順序そのものが、実は多くのものを取り逃がす原因になっています。見積もりを固めるために仕様を確定させ、仕様を確定させるために要件を洗い出し、その間に市場も自社の優先順位も動き続けている。ようやく契約が結ばれ、開発が始まる頃には、最初に固めた仕様がすでに古くなっていることも珍しくありません。エンジニアの採用が思うように進まず、かといって外注すれば見積もりと仕様確定に何週間も取られる。事業やマーケティングの責任者であれば、この板挟みに一度は覚えがあるのではないでしょうか。
弊社Respectifyが提供するRespectify STUDIOでは、この順序を逆にしています。見積もりや仕様書を固める前に、週に一度、動くものを持っていく。本稿では、この週次スプリント・週次デモという進め方の実務と、なぜこの順序のほうが理にかなっているのかを、事業責任者の視点で整理します。海外でFDE（Forward Deployed Engineer）と呼ばれる型についての基礎知識は、姉妹記事「FDEとは何か」で解説しています。
従来の外注のリズムで失われているもの
一般的な受託開発・外注のリズムは、おおむね次の順序で進みます。要件のヒアリング、見積もりの提示、契約、仕様の確定、開発、そして納品。それぞれの工程は単体で見れば妥当ですが、直列につながることで、いくつかの意図しない副作用が生まれます。
第一に、意思決定の鮮度が失われます。見積もりの前提となる仕様は、契約時点の状況をもとに固定されます。ところが事業の優先順位は、月次の数字や競合の動き、経営会議での一言で簡単に変わります。仕様確定から納品までの間に前提が変わっても、契約に縛られた仕様はそのままです。変更するには、追加見積もりや契約変更という別の手続きが必要になり、現場の判断とシステム開発の間に距離が生まれます。
第二に、認識合わせの機会が減ります。仕様書は文章と図で書かれますが、文章は読み手によって解釈が分かれます。「入力項目を減らす」という一文だけでも、発注側が思い描く画面と、開発側が実装する画面は容易に食い違います。「これでお願いします」と合意した仕様書が、納品されたものを見て初めて「思っていたものと違う」と気づかれるのは、珍しい話ではありません。認識のズレは、動くものを見るまで発見されないことが多いのです。
第三に、フィードバックのループが長くなります。仕様確定から納品までの間、発注側は基本的に「待つ」立場になります。数週間から数か月、動くものに触れる機会がないまま進み、フィードバックを返せるのは納品の直前か、その後になってからです。フィードバックが遅れるほど、方向転換のコストは大きくなります。この論点は、外注か内製かという判断軸を扱った姉妹記事「AI実装は外注すべきか内製すべきか」でも詳しく取り上げています。
第四に、リスクの前払いが起きます。見積もりを出すということは、発注側にとっては「まだ動かして確かめていないものに、先に金額を約束する」ことを意味します。ベンダー側も、まだ手を動かしていない段階で工数を見積もらざるを得ません。結果として、双方がリスクを織り込んだ金額で合意することになり、その分バッファが積まれます。見積もりという行為自体が、不確かさをお金に変換する作業だとも言えます。
こうした副作用は、担当者の能力や誠実さの問題ではありません。「作る前にすべてを決めてしまう」という前提に立つ進め方そのものに、構造的に組み込まれた性質です。仕様書という文書の完成度をいくら上げても、この四つの問題は解決しません。問題の所在は文書の質ではなく、「作る前に決める」という順序そのものにあるからです。
さらに、要件のヒアリングから見積もり提示、契約締結、仕様確定までの各工程は、それぞれ単体でも一定の日数を要します。担当者間のスケジュール調整や社内稟議を挟めば、開発が始まる前の段階だけで数週間から一か月以上かかることも珍しくありません。事業の意思決定サイクルが週次・月次で回っている企業にとって、この「まだ何も動いていない期間」の長さ自体が、機会損失に直結します。
週次リズムの実務：月曜に決め、平日で作り、金曜に見せる
Respectify STUDIOでは、この前提を置き換えています。最初にすべての仕様を確定させるのではなく、まず「やりたいことの1枚リスト」、つまりバックログを作ることから始めます。仕様を固めることに時間を使うのではなく、優先順位を合意することに時間を使い、あとは毎週動くものを見ながら詳細を詰めていく、という順序の入れ替えです。
バックログという1枚のリストが仕様書の代わりになる
進め方はシンプルです。最初の週に、社内に散らばっている「作りたいもの」「直したいもの」を洗い出し、売上へのインパクトが大きい順に並べます。この1枚のリストが、従来の仕様書の代わりを果たします。分厚い要件定義書を最初に作り込むのではなく、「何を、どの順番でやるか」だけをまず合意するという発想です。仕様書は「完成形をどう作るか」を事前に固定する文書ですが、バックログは「次に何から手をつけるか」だけを決める文書であり、常に並び替えられることが前提になっています。この違いが、週次のリズムを支える土台になっています。
バックログに載る項目は、最初の洗い出しで終わりではありません。事業側で新しいアイデアが出るたびに、あるいは金曜のデモで気づいた改善点が出るたびに、随時追加されていきます。並び順の基準は一貫して「売上へのインパクトの大きさ」であり、思いつきの順や声の大きさで決めるものではありません。この基準が明確であるほど、月曜の意思決定は速くなります。何を優先すべきかを毎回ゼロから議論するのではなく、すでにある基準に沿って上から順に拾っていくだけで、今週着手する項目が決まります。
月曜・平日・金曜のサイクル
そこから先は、次のリズムで回します。
- 月曜: バックログを見ながら、今週着手する項目を2〜3件に絞って決めます。前の週のデモで出たフィードバックがあれば、ここで反映します。件数をあえて絞るのは、一週間で「完成した状態」まで持っていける規模に留めるためです。中途半端な状態のものを積み上げるより、小さくても動く状態のものを毎週積み上げるほうが、次の判断がしやすくなります。
- 平日: 決めた項目をビルドします。Claude Codeのようなツールを使い、エンジニアでない担当者でも動くものを組み上げられる進め方については、姉妹記事「Claude Codeを業務実装に使うという方法論」で扱っています。
- 金曜: できあがったものをデモで確認します。画面越しに実際に触ってもらい、その場で意見をもらいます。
- 並び替え: デモで出たフィードバックをもとに、バックログの並びをその場で更新します。優先順位が変われば、来週着手する項目も変わります。
このリズムの核心は、「並び替え」に契約変更や追加見積もりの手続きが要らない、という点にあります。仕様書のバージョン管理も、変更管理のための社内稟議も発生しません。バックログという1枚のリストの並びを変えるだけで、翌週の作業内容が変わります。
ある一週間の流れ
たとえば、ある成長期のB2B SaaS企業を想定してみます。月曜の朝、バックログの上位を確認すると、前の週のデモで挙がった「フォームの入力項目を減らしてほしい」という指摘への対応が1件、もともと上位にあった「休眠リード向けの案内ページ」の新規制作が1件、合わせて2件が今週の対象として決まります。平日は、この2件を「完成した状態」まで仕上げることに集中します。中途半端な進捗を複数抱えるのではなく、少ない件数を確実に動く状態まで持っていくことを優先します。
金曜の午後、できあがった2件をデモで確認します。フォームの修正はそのまま合格しますが、案内ページのほうは「この訴求よりも、価格ページへの導線を先に直したほうが商談化率に効きそうだ」という意見が出ます。その場でバックログの並びを更新し、価格ページの導線修正を来週の上位に繰り上げます。案内ページの続きは、優先順位が下がった分だけ後ろに回ります。ここまでの一連のやり取りに、追加の見積もり依頼も、契約書の巻き直しも発生しません。バックログという1枚のリストの並びを書き換えただけです。
なぜ見積もりより先に、動くものを持っていくのか
この進め方が成立する理由は、大きく二つあります。
認識合わせは実物が最速
一つ目は、認識合わせは実物が最速だということです。仕様書の文章をいくら練っても、読み手の頭の中にあるイメージと、書き手が意図したイメージが完全に一致することはまれです。一方、動く画面を見せれば、「ここが違う」「ここは思った通り」という反応がその場で返ってきます。金曜のデモが機能するのは、まさにこの性質によるものです。
ソフトウェアの見積もり手法を体系化したSteve McConnellが広めた「不確実性のコーン」という考え方では、プロジェクトの初期段階、つまり要件がまだ固まっていない段階での見積もりは、最終的な実績値に対して大きくぶれる可能性があるとされています。初期の構想段階で立てた見積もりは、実績に対して数倍単位の幅でずれることもあり得るとされ、プロジェクトが進み詳細が明らかになるにつれて、その幅は徐々に狭まっていくとされています（参照：Construx「Software Development's Cone of Uncertainty」(2019年))。つまり見積もりが最も不正確なのは、まさに「仕様を固める」ために時間をかけているその段階だという逆説です。だとすれば、不確かな見積もりに時間を使うより、小さく作って実物で確かめるほうが、不確実性を早く減らせるという結論になります。金曜のデモは、この不確実性を毎週一段階ずつ狭めていく場だとも言い換えられます。
AIによって「作ってから直す」が成立する
二つ目は、AIによって制作の原価が下がり、「作ってから直す」という進め方が経済的に成立するようになったことです。ソフトウェア開発では長らく、変更のコストは工程が進むほど指数関数的に増えると考えられてきました。要件定義の段階で直すのは安いが、リリース後に直すのは高くつく、という考え方です。
しかし、アジャイル領域で長く執筆してきたMike Cohnは、この「変更コストの曲線」はすでに過去のものになりつつあると指摘しています。IDEや自動テスト、モジュール化された設計によって曲線はかなり平らになっており、AIによるコード生成・修正の高速化が、この傾向をさらに押し進めていると述べたうえで、「変更コストの主な要因は、開発の手間そのものより、フィードバックの遅れに移りつつある」と結論づけています（参照：Mountain Goat Software「The Cost of Change Curve Is Outdated」(2026年))。作り直すコストが下がれば、最初から完璧な仕様を目指す必要性そのものが薄れます。週次で小さく作り、金曜のデモで得たフィードバックをもとに翌週作り直す、という進め方は、この「変更コストが下がった」という前提があって初めて経済的に成立します。
ただし、AIが常に開発を速くするわけではない、という点は誇張せずに補足しておく必要があります。AIの安全性評価を専門とするMETRが2025年に実施した無作為化比較試験では、大規模で複雑な既存のオープンソースリポジトリを保守する熟練エンジニアが、AIツールを使った場合にむしろ完了時間が19%長くなったという結果が報告されています（参照：METR「Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity」(2025年))。この調査が対象にしたのは、100万行を超えるような複雑で歴史の長いコードベースの保守作業です。週次スプリントで扱うような、スコープを2〜3件に絞った小さな単位の新規ビルドとは前提が異なります。AIが原価を下げるのは万能薬としてではなく、「小さく作って、フィードバックをもとに直す」というサイクルの規模とテンポに噛み合ったときだ、という理解が実態に近いといえます。
リスクの前払いをなくす効果
この二つの理由は、冒頭で挙げた「リスクの前払い」の問題にもそのまま効いてきます。見積もりに積まれるバッファは、突き詰めれば「まだ作っていないものの不確かさ」に対する保険料です。動くものを毎週確認できれば、その不確かさは週を追うごとに減っていきます。不確かさが減れば、あらかじめ保険料として積んでおくべき金額も小さくて済みます。見積もりより先に動くものを持っていくという順序は、単に進め方の好みの問題ではなく、双方が背負うリスクの総量そのものを減らす効果を持っています。
これを可能にする契約形態
週次で優先順位を変え続けるという進め方は、成果物の範囲と金額を最初に固定する請負契約とは相性がよくありません。請負契約は「何を作るか」を契約時点で確定させることが前提であり、バックログの並びが毎週変わることを想定した設計にはなっていないためです。並び順が変わるたびに追加見積もりや契約変更が必要になれば、週次のリズムはそこで止まってしまいます。
Respectify STUDIOでは、これを準委任・月額定額という契約形態で提供しています。稼働の目安と月額をあらかじめ決め、月単位で更新・停止ができる仕組みです。バックログの並びが毎週変わっても、そのたびに見積もりを取り直す必要がありません。発注側にとっても、都度の稟議を経ずに起案者の裁量で進められる金額に収まりやすいという利点があります。何を作るかではなく、どれだけの時間を確保するかを契約の単位にすることで、契約とバックログの並び替えを切り離しているのが、この仕組みの要点です。
この設計が効いてくるのは、特に稟議のたびに仕様書と金額をセットで説明し直さなければならない場面です。月額が固定されていれば、社内に説明すべきなのは「何にいくら使ったか」ではなく「今月何が動くようになったか」で済みます。バックログの並びが変わったことを都度、決裁者に説明し直す必要がないというのは、事業側の立場から見ても実務上の負担が小さい仕組みです。
見方を変えると、準委任・月額定額は、先に触れた「リスクの前払い」を契約の形でも軽くする仕組みだといえます。請負契約は、まだ動かして確かめていない成果物に金額を固定するため、双方がリスクを織り込んだバッファを積みます。月単位で更新・停止ができる準委任契約は、確かめられていない将来の成果物にではなく、直近一か月の稼働に対して金額を約束する形です。約束の対象を「まだ見ぬ完成品」から「一定の稼働時間」に移すことで、双方が抱える不確かさそのものを小さくしています。費用感と契約形態の詳細は、姉妹記事「FDE型支援の費用感と契約形態」で扱っています。
アジャイル一般論との違い
「それは要するにアジャイル開発、スクラムのことでは」という反応もよくいただきます。似ている部分があるのは事実です。短い周期で区切り、動くものを確認しながら進めるという骨格は共通しています。ただし、両者が定めている対象は異なります。
Ken SchwaberとJeff Sutherlandが公開する『2020 Scrum Guide』を見ると、Scrumが規定しているのは、プロダクトオーナー・スクラムマスター・開発者から成る「スクラムチーム」という単位の働き方です。スプリントの長さは1か月以内とされ、スプリントレビューの目的は「スプリントの成果を検査し、今後の適応を判断すること」と説明されています。一方で、このガイドには、発注者・ベンダー間の契約関係についての記述は含まれていません（参照：Scrum.org「The 2020 Scrum Guide」(2020年))。つまりScrumは、あくまで開発チームの内部で完結する仕事の進め方を定めたフレームワークであり、クライアントとベンダーの間で何を約束するかを規定するものではないのです。
Respectify STUDIOの週次スプリント・週次デモが違うのは、まさにこの点です。金曜のデモにクライアント自身が毎週参加し、その場でバックログの並びを変える権限を持つ、という関与の設計そのものが、ベンダーとクライアントの間で交わす約束になっています。社内でスクラムを実践している開発会社は少なくありませんが、その週次リズムをクライアントとの関係にそのまま開き、優先順位を変える主導権をクライアント側に渡している例は多くありません。アジャイルが「開発チームがどう働くか」の話であるのに対し、この進め方は「発注者と支援者がどう約束するか」の話だといえます。
「アジャイル型で開発します」と謳う会社に発注しても、この違いは埋まらないことがあります。開発チームの内部運用がスクラムに沿っていても、クライアント向けの成果報告が月次のマイルストーンレビューにまとめられていたり、優先順位の変更が正式な変更依頼書を介さないと反映されなかったりすれば、クライアント側から見た体験は従来の請負型と変わりません。内部の開発手法がアジャイルかどうかと、クライアントが毎週の意思決定に関与できるかどうかは、別の軸にある問題です。Respectify STUDIOが約束しているのは前者ではなく後者、つまり毎週デモに参加し、その場でバックログの並びを動かせるという、クライアント側の関与そのものです。
よくある疑問
週次でこの進め方を紹介すると、決まって出てくる疑問がいくつかあります。
品質は大丈夫なのかという疑問には、むしろ小さい単位のほうが品質を担保しやすい、と答えています。一週間で「完成」まで持っていける規模に絞っているため、その週のうちに動作確認とレビューが完結します。数か月分の仕様を一度に作り込むより、毎週小さな完成物を積み重ねるほうが、不具合の発見と修正のサイクルは短くなります。数か月分の仕様を一度にレビューしようとすると、確認すべき範囲が広すぎて見落としが生まれやすくなりますが、週単位の小さな完成物であれば、金曜のデモという場でその都度目を通すことができます。
要件定義書は本当に不要なのかという疑問もよく受けます。不要というより、役割が変わると考えるのが正確です。細かい仕様の一字一句を事前に固める文書の代わりに、優先順位を明文化したバックログが置き換わります。何を作るかの詳細は、着手する週になってから、デモで得た情報をもとに詰めていきます。
進捗はどう管理するのかという点については、追加の進捗会議やステータスレポートを別途設けていません。バックログの消化ペースと、金曜のデモそのものが進捗報告を兼ねています。今週何が動くようになったかを毎週その目で確認できる以上、それとは別に「進捗はどうですか」と尋ねる会議を挟む必要性が薄れます。
エンジニアがいない会社でも本当に回せるのかという疑問もよく受けます。回せます。この進め方を支えているのは、Claude Codeのようなツールによって、実装そのものにかかる時間が短くなっているという前提です。エンジニアでない担当者が要件を整理し、AIを使って実装するという方法論については、姉妹記事「Claude Codeを業務実装に使うという方法論」で具体的に扱っています。むしろ社内にエンジニアがいないことは、週次リズムを採用しない理由にはならず、外部のFDE型支援を活用する動機のひとつになります。
途中でやめられるのかという点も、意思決定者としては気になるところだと思います。準委任・月額定額という契約形態は、月単位での更新・停止を前提にしています。バックログを消化しきって当面の課題がひと段落した、あるいは社内で採用が決まり内製に切り替える、といった判断があれば、その月をもって止められます。請負契約のように「契約した成果物をすべて納品するまで終われない」という縛りがない点も、見積もりより先に動くものを試すという進め方と噛み合っています。
やりたいことが際限なく増えて、稼働をオーバーしないかという懸念も自然なものです。稼働の目安は月額とセットであらかじめ決まっているため、一週間で着手できるのは、そのなかで完成まで持っていける2〜3件に限られます。バックログにどれだけ項目が積み上がっても、消化できる量は稼働の枠に収まる分だけです。増えていくのはリストの下の方に並ぶ「まだ着手していない項目」であって、その週の作業量そのものが膨らむわけではありません。
向いている会社、向いていない会社
すべての開発にこの進め方が適しているわけではありません。優先順位が事業のフェーズによって頻繁に変わり、意思決定者がデモを見てその場で判断できる体制にある会社には向いています。特に、サイトやCRM、営業・マーケティングまわりの実装のように、市場の反応を見ながら方向修正を重ねる性質の高い領域とは相性がよい進め方です。
向いているかどうかを判断する目安は、大きく三つあります。一つ目は、優先順位を決める人が社内にはっきりしていて、その人が毎週時間を確保できるかどうかです。金曜のデモに参加できる人がいなければ、並び替えは起きません。二つ目は、「完璧な最終形」より「まず動くものを見て判断したい」という姿勢があるかどうかです。最初から完成度の高い仕様書を求める文化が強い組織では、週次で粗いものが出てくること自体に抵抗が生まれることがあります。三つ目は、扱う対象が、法規制や既存システムとの厳密な整合性よりも、事業成果への貢献度で優先順位を決められる領域かどうかです。
逆に、金融機関の基幹システムのように、要件を厳密に固定してから作り込むことが法規制や安全性の観点で必須な領域や、意思決定者が毎週デモに参加できない体制の会社では、週次で並び替えるという前提そのものが機能しにくくなります。金曜のデモに誰も出てこず、フィードバックが返ってこなければ、バックログの並びは更新されず、リズムは形骸化します。週次スプリント・週次デモは万能な進め方ではなく、「優先順位が動きやすい」「決裁者がその場で判断できる」という二つの条件が揃って初めて効果を発揮する進め方だと捉えるのが実態に近いでしょう。
FDE型支援における位置づけ
この週次スプリント・週次デモという進め方は、単独の工夫というより、FDE型支援が成果を出すための土台になっています。姉妹記事「FDEとは何か」で触れているとおり、FDEという働き方の核心は、顧客の現場に入り込み、優先順位が変わるたびに実装を作り直しながら、動くものを継続的に更新し続けることにあります。この「作り直しながら更新し続ける」という性質を、実務のリズムとして具体化したものが、月曜に決め、平日で作り、金曜に見せるというサイクルです。
裏を返せば、FDE型の支援を名乗っていても、成果物の受け渡しが月次や四半期単位のマイルストーンでしか行われないのであれば、それは名前だけがFDE型で、実務のリズムは従来の受託開発のままだということになります。週次で動くものが届き、週次で優先順位を動かせるかどうかは、FDE型支援が看板どおりに機能しているかを見極める、実務上のわかりやすい目安になります。
FDEとSIer・受託開発の違い、あるいはFDEと常駐型のSESとの違いについては、それぞれ姉妹記事「FDEとSIer・受託開発の違い」「FDEは「常駐SES」なのか」で扱っています。本稿で紹介した週次スプリント・週次デモというリズムは、それらの記事で述べている「納品して終わりにしない」「常駐ではなく成果への関与で語る」という性質を、実務の具体的な手順として落とし込んだものだと位置づけられます。
まとめ
見積もり・仕様確定・納品待ちという従来の外注のリズムは、意思決定の鮮度、認識合わせの機会、フィードバックのループ、そしてリスクの前払いという四つの点で犠牲を伴いがちです。この犠牲は、担当者の力量ではなく「作る前にすべてを決めてしまう」という順序そのものから生まれています。
Respectify STUDIOの週次スプリント・週次デモは、バックログという1枚のリストを仕様書の代わりに置き、月曜に今週の2〜3件を決め、平日でビルドし、金曜のデモでその場で並び替えるというリズムで、この犠牲を避けています。見積もりより先に動くものを持っていくのは、認識合わせが実物のほうが速いことと、AIによって「作ってから直す」ことの原価が下がったことの両方が理由です。これを支えているのが準委任・月額定額という契約形態であり、開発チーム内の働き方を定めるアジャイル・スクラムとは、ベンダーとクライアントの間の約束であるという点で性質が異なります。ただし万能な進め方ではなく、優先順位が動きやすく、決裁者がその場で判断できるという条件が揃って初めて力を発揮する進め方だという点も、あわせて押さえておく必要があります。
見積もりを待つ間に事業は動き続けます。仕様を固めることに時間を使うより、まず小さく動くものを見て、その反応から次の一手を決める。この順序の入れ替えが、変化の速い事業フェーズにいる会社にとって、外注のリズムを組み直す一つの選択肢になるはずです。
こうした週次のリズムで動くものを届け続ける支援については、Respectify STUDIOで詳しくご紹介しています。専属チームが準委任・月額定額でつき、毎週デモで動くものが届く進め方です。自社の状況に合わせた進め方について相談したい方は、無料相談からお気軽にお問い合わせください。
