2ニカゲツby ale / BUILD & RUN

2ヶ月で作れるもの、作れないもの ── 8週間の中身を、週ごとに開けてみる

2026.09.19 公開 / 2026.09.26 更新

「2ヶ月って、本当ですか」。初回のお打ち合わせで、だいたい一度は確認されます。サービス名が「ニカゲツ」なので当然だと思います。

結論から書くと、契約から8週間で初回リリースというのは契約書に書いてある期限です。守れなければ、こちらの責任です。ただし8週間で出せるのは、作らないものを先に決めているからでもあります。ここでは中身を週ごとに開けて、何をしていて、何をしていないかを書きます。

8週間の工程図。W1からW2で要件整理と画面設計、W3からW6で開発と週次確認、W7からW8で仕上げとリリース準備
8週間の区切り方。最初の2週間はコードをほとんど書きません。

W1〜W2 ── いちばん時間をかけるのは、作る前

最初の2週間は、コードをほとんど書きません。やっているのは、業務の聞き取りと画面構成の確定です。

聞くのは主に3つです。誰が使うのか。いまその業務をどうやっているのか。作ったあと、何を見て「うまくいった」と判断するのか。3つ目が抜けたまま進む案件は、だいたいあとで迷子になります。

この期間の発注側の負担が、実はいちばん重いです。週に2〜3時間は見ておいてください。現状の紙やエクセルを見せていただくのが早いので、資料を作り込む必要はありません。むしろ、いま実際に使っているものをそのまま見せてもらうほうが正確です。

2週目の終わりに画面構成が固まります。ここで初めて「10画面のうち、この3枚が本体だ」がはっきりします。

この順番を守ると、作る工程は短くなります。自社の業務システムを作ったときは、設計書を先に書き切っていたので、26画面の初版が4日で動きました。逆に言えば、設計書を書く時間はそのぶん前に取っています。研修事業の業務コンソールに、その内訳を書きました。

W3〜W6 ── 毎週、動くものを見てもらう

ここが開発の本番です。設計と実装とテストの大部分はAIと協働で進めます。ただし、何をどう作るかの判断と、テスト、動作確認は人がやります。AIが圧縮しているのは工数であって、責任ではありません。

この4週間で大事にしているのは、週に1回、実際に動く画面を見ていただくことです。スクリーンショットではなく、触れるものをお出しします。

なぜかというと、画面は見ないと分からないからです。「一覧に担当者を出してください」と最初に言われていても、実際に並んだ画面を見ると「担当者より期限が先のほうがいい」となる。これは仕様変更ではなく、正常な気づきです。完成してから言われると作り直しになりますが、3週目に言われれば5分で直ります。

だから毎週見せます。「完成してみたらイメージと違う」を防ぐ方法は、これ以外にないと思っています。

W7〜W8 ── 仕上げと、使い始める準備

最後の2週間は、細部の調整とリリースの準備です。エラーのときの表示、スマホでの見え方、データの初期投入、権限の確認。地味な作業が続きます。

あわせて、使い方の説明をします。マニュアルを渡して終わりではなく、実際の操作を一通りやってみていただく時間を取ります。ここで「この操作、毎日やるには面倒ですね」と出ることがあって、それは改善フェーズの最初の宿題になります。

8週目に初回リリース。ここから実際の業務で使い始めていただきます。

この8週間で作らないもの

決済、公的な本人確認、複雑な承認ルート、大規模なデータ移行、基幹システムとの連携。初期には含めていません。

技術的に無理なのではなく、順番の問題です。決済を入れるには審査と規約の準備が要りますし、そもそも「使ってもらえるか」が分かる前に決済を作るのは早い。承認ルートも同じで、実際に運用が始まってから「部長を挟むと止まる」と分かることが多い。先に作り込むほど、作り直しが高くつきます。

この「今回は作らない」を発注側でも先に決めておけると、初回の打ち合わせから話が進みます。決め方は開発会社に相談する前に、決めておくと話が早い3つのことに書きました。

マルチテナント化や、凝った権限設計も同様です。まず数社、数人で使ってみて、続きそうなら足す。その順番で組み立てています。

8週間の裏にある、割り切り

2ヶ月という期限は、速さを売りにしたいから設定しているわけではありません。期限を先に決めると、作るものを選ばざるを得なくなるからです。

期限がないと、機能は際限なく増えます。「せっかくだからこれも」が10個積み上がると、リリースは半年先に延びて、そのころには前提が変わっています。逆に8週間と決めてしまえば、「それは3ヶ月目に入れましょう」という会話が自然にできます。

リリース後の12ヶ月は月額の改善フェーズです。画面の追加も項目の変更も、その中でやっていきます。2ヶ月で完成させるのではなく、2ヶ月で使い始めて、そこから育てる。そういう設計です。

この2ヶ月+12ヶ月という形が金額としてどうなるかは、MVP開発の費用は、何で決まるのかに1年目の総額で並べてあります。

不安なら、ラフを見てから決めてください

初回お打ち合わせは60分、そのあと3営業日以内に画面構成のラフと見積もりをお出しします。ここまで費用はいただきません。

ラフには、8週間で作る画面が全部並びます。その枚数を見て、2ヶ月で現実的かどうかを判断していただくのがいちばん確実だと思います。

ラフと一緒に見積もりと契約書もお渡しします。契約書のどこを読めばいいかはシステム開発の契約書で、発注側が読むべき5つの場所に、どんな画面構成になるかの例は作れるものの例にあります。

よくあるご質問

本当に2ヶ月でリリースできますか?

契約開始から8週間を開発フェーズとして契約書に書いています。キャッチコピーではなく契約上の期限です。ただし範囲は画面数で区切っていて、決済や公的本人確認、基幹システム連携などは初期に含めていません。その割り切りがあるから8週間で出せます。

開発中、発注側の負担はどれくらいですか?

最初の2週間は週2〜3時間ほど見ておいてください。業務の説明と、画面構成の確認に時間が要ります。3週目以降は週1回30分の確認が中心になります。専門知識は不要で、窓口はご担当者おひとりで大丈夫です。

途中で作るものを変えたくなったらどうなりますか?

毎週動く画面を見ながら進めるので、変更は歓迎です。ただし画面数の枠は動かしません。1画面足すなら1画面減らす、という相談になります。枠を広げる場合は上位プランへの変更をご提案します。

作りたいものを、
ひとつだけ持ってきてください。

初回お打ち合わせは60分・オンライン可。画面構成のラフとお見積りまで費用はいただきません。

RELATED

続けて読む

「範囲と進め方を決める」の記事はガイドの一覧にまとめています。全12本を3つのテーマに分けて並べました。