私たちは、最初の動くプロトタイプを最短数週間で作ることを目指しています。「受託開発は要件定義だけで数か月」という感覚からすると速く聞こえるかもしれませんが、魔法ではなく仕組みの話です。この記事では、なぜ数週間で出せるのか、そして「なぜ速く出すのか」を書きます。
なぜ速く作れるのか
定型部分はテンプレート基盤で済ませる。 業務システムの相当部分は、実はどの案件でも同じです。ログイン認証、ユーザーと権限の管理、管理画面の枠組み、データの一覧・検索・登録、通知。私たちはこの定型部分を Go / Next.js の自社テンプレートとして整備していて、案件はゼロからではなく「動く土台」から始まります。最初の1〜2か月で作るものが、初日からある状態です。
個別部分はAIで作る。 案件固有の業務ロジックや画面は、AI駆動の開発フローで作ります。やり方は別の記事に詳しく書きましたが、設計を人間が握り、関数単位でAIに書かせ、すべてのコードを検証して取り込む。実装の手が速くなるぶん、品質確認に時間を割けるのがAI開発の正しい使い方です。
ドキュメントを書く前に、動くものを見せる。 分厚い設計書を書いて合意してから作るのではなく、画面と動きで合意を取ります。文書をめぐる解釈のずれや、レビューの往復にかかる時間がなくなります。仕様の認識合わせとして、動くものに勝るドキュメントはありません。
速く出すのは「安く済ませる」ためではない
ここは誤解されやすいので強調しておきます。プロトタイプを数週間で出すのは、開発費を削るためではなく、間違いに早く気づくためです。
システム開発で一番高くつくのは、作り込んだ後に発覚する「思っていたのと違う」です。要件定義の時点では、顧客自身も本当に必要なものを言語化できていないことが多い。動くものを現場で触ってもらって初めて、「この情報も見たい」「この手順は実際の流れと逆だ」が出てきます。それなら、出てくるのを早くしたほうがいい。数週間で当てれば、軌道修正のコストは数日分です。1年後の納品時に発覚すれば、手戻りは数か月分になります。
数週間の中身
おおまかな流れはこうです。
- 最初の1週間：現場に入ってヒアリングと業務観察。解くべき課題と、プロトタイプで検証したいことを決めます。全機能ではなく「一番不確実な部分」に絞るのがポイントです
- 2〜3週目：テンプレート基盤の上に、対象の業務フローを実装。週次の定例で途中経過を見せながら進めます
- 数週間後：現場に当てて、実際の業務データ・実際の利用者で試します。ここからは「直す→当てる」のループです
プロトタイプ段階では、検証に関係ない部分の作り込みは意図的に省きます。ただしどこが「荒い」かは顧客と共有し、本番化の際に作り直す範囲を明確にしておきます。スピードのための割り切りと、品質の手抜きは別物です。
まとめ
数週間で出せるのは、定型部分のテンプレート化とAI開発フローという「仕組み」があるからです。そして速く出す目的は、コスト削減ではなく、間違いに早く気づいて修正コストを最小にすること。動くものを早く見たい方は、お問い合わせからご相談ください。