Commissioning software: choosing a vendor, what it costs, and how projects fail

検収は「動いたら合格」ではなく、支払い義務と責任追及期限が同時に確定する法律行為です。請負と準委任で何が変わるか、民法562〜564条の3つの武器と636条の落とし穴、637条の『知った時から1年』、非エンジニアでも実行できる受け入れテストの作り方、そして2026年1月施行の新法が発注者側に課す制約まで、一次法令で裏を取って整理します。

A buyer's guide to requirements definition and the RFP for commissioned software. Roughly one project in five ships on time and on budget and still leaves its users unhappy — this covers the four things only a buyer can write, a minimum RFP that fits on three to five pages, why over-specifying technology makes proposals worse, and why acceptance criteria belong in writing before you sign.

システム開発の総コスト（TCO）を発注者視点で解説。見積書に出てこない6つの費用、5年分を積み上げる計算シート、相見積もりで総コストの差が出る4つのポイント、そして補助金でクラウド利用料が最大2年分しか対象にならない落とし穴まで、公式の一次情報に基づいて整理します。

In what order should you systematize work that runs on phone, fax, and Excel? Drawing on a real Minister of Economy, Trade and Industry Award-winning lumber-distribution DX (multi-stage trade flow, permission separation), this guide concretely explains a buyer-facing roadmap—business inventory → prioritization → phased systematization—as a way to proceed without failing.

A buyer's-eye guide to system-development contract types. When to use contract-for-work (deliverable + non-conformity liability), quasi-mandate (effort + duty of care), and lab-type; plus how to handle IP, acceptance testing, and additional requirements — systematized from real projects including a METI Minister's Award winner and a payment platform with zero production double-charges.

A practical guide to not losing out when gathering competitive quotes for system development. From a buyer's perspective, it explains how to read a quote's breakdown (person-months, non-functional, maintenance), the danger signals of a quote that's too cheap, and how to compare correctly on identical requirements. It systematizes—drawing on real-project experience—the multi-axis scoring that lets you look at price last, plus the anti-patterns of competitive bidding.

The causes of failed system-development projects converge on four structural flaws: blind hand-off, multi-tier subcontracting, broken communication, and neglected technical debt. This practical guide reasons the selection criteria backward from those typical patterns and — from the buyer's perspective — systematizes how to spot a development company you can hold to quality gates like testing, type safety, and security audits.

Should you build a system in-house or outsource it? Is SaaS enough, or should you build from scratch? This explains a framework for SMB and startup decision-makers to judge with axes rather than gut feel. From the four axes — the core of differentiation, change frequency, specialization, and TCO — to a hybrid strategy and a third option, one-person × generative AI, it systematizes the call from real-project know-how.

You want to adopt generative AI for your business but get stuck at the PoC (proof of concept) — this explains the cause and the breakthrough from the buyer's perspective. From the real walls that produce 'stuck at PoC' (type-safe boundaries, resilience, cost, observability, security), to the judgment between API usage and self-hosting, to the key points of commissioning in-housing support, it systematizes the topic from real-project know-how such as an enterprise AI platform for a broadcaster.

Against the backdrop of the '2025 cliff,' how to modernize legacy systems and analog operations (phone, fax, Excel). From the buyer's perspective, it explains a staged migration approach that doesn't fail, how to think about costs, design so the field keeps using it, and the use of subsidies — drawn from the real example of an METI-Minister's-Award-winning lumber-distribution DX.

An explanation of preventing double charges and balance inconsistencies in payment/billing systems with the structure of the code, not the carefulness of operations. The core of payment reliability — idempotency keys, atomic transactions, and webhook deduplication — and a checklist buyers should demand of vendors, systematized from the real example of a payments platform that maintains 0 double charges during production operation.

From the buyer's perspective, this explains the market rate of system development (person-month unit prices, ranges by development type) and how to spot the breakdown and validity of estimates. Why estimates differ several-fold for the same requirements, the 'omissions' lurking in cheap estimates, how to think about operations/maintenance costs, and how one-person × generative AI changes the cost structure — systematized from real-project know-how.

Why does a prototype quickly built with AI (vibe-coded) break in production? It explains the 'absence of verification gates' that produces the gap between demo and production, and concrete measures to raise AI-generated code to production quality — type-safe boundaries, tests, security, idempotency — from the buyer's perspective, drawn from real-project know-how of supporting production operations verification-first.