2026 年企業軟件：從首次溝通到正式環境自主營運

Shipping code is an event. Owning software is a continuing obligation.

A software project can pass every sprint demo and still fail its customer. Perhaps nobody defined what available meant. Perhaps the vendor delivered source code but not infrastructure access. Perhaps AI generated features faster than the team could verify them. Perhaps an impressive dashboard measured deployments while customers waited hours for business-critical jobs.

This article follows one fictional enterprise project from initial discovery through procurement, negotiation, implementation, launch, incidents, and handover. Its example numbers, targets, and conversations are illustrative proposals, not industry benchmarks or legal advice. Along the way, we'll connect the decisions to published guidance from DORA, NIST, OWASP, and Google SRE.

The case: a logistics platform with real consequences

Northstar Logistics operates 2,000 vehicles across several countries. Its operations staff coordinate shipments through spreadsheets, email, and a legacy application. The company hires Harbor Software, an external development partner, to build a shipment visibility and exception-management platform.

Stakeholders:

Business hypothesis: reduce the median time to identify and assign a delayed shipment from 45 minutes to 15 minutes within 90 days of rollout, without increasing false alerts or manual workload.

Notice that the objective is not “build a dashboard.” A dashboard is one possible intervention. The outcome is faster, trustworthy decisions.

Phase 0 — Qualify the problem before selling a solution

The vendor runs discovery interviews with dispatchers, operations managers, security, and the legacy-system team. It maps a shipment's journey and records where data is missing or delayed.

Sample conversation:

Customer: We need live tracking for every vehicle.

Engineer: What decision becomes possible with live tracking that isn't possible today?

Customer: Dispatchers need to react before a delivery misses its window.

Engineer: Would a two-minute update plus a reliable delay alert meet that need? Continuous streaming changes mobile connectivity, storage, and support costs.

Customer: Let's test it with dispatchers rather than assume.

Artifacts: problem statement, current-state workflow, stakeholder map, data inventory, baseline metrics, assumptions register, risks, and a one-page business case.

Validation gate: sponsor and product owner confirm the problem, a measurable outcome, and the baseline measurement method. Run a small user observation or prototype before committing to architecture.

AI contribution: transcribe approved interviews, cluster recurring pain points, draft process maps, identify contradictory statements. Human check: verify every consequential finding against recordings, participants, or system evidence. Never send confidential interviews to an unapproved model.

Phase 1 — Negotiate scope, economics, and control

The parties choose a phased engagement instead of treating a fixed-price contract as a substitute for discovery.

Illustrative commercial proposal:

• Discovery: two weeks, fixed fee, producing a validated backlog, risk register, and delivery estimate.
• Pilot: eight weeks, limited to 100 vehicles and two dispatcher teams; price and scope capped.
• Expansion: funded after pilot acceptance, with explicit change control.
• Support: separate operational agreement defining hours, severity, escalation, and service credits if applicable.

Sample negotiation:

Customer procurement: We need a fixed deadline and fixed cost for all countries.

Vendor lead: We can fix the pilot budget and deadline. We cannot responsibly fix the full integration scope before inspecting the legacy interfaces. We propose a two-week discovery with an option to stop.

Customer CTO: We also need the ability to replace your team.

Vendor lead: Agreed. Repositories, infrastructure accounts, pipelines, documentation, and observability will live under your organization's control. We'll define an exit rehearsal as an acceptance condition.

Customer procurement: How do we handle new compliance requirements?

Vendor lead: We'll document their impact on scope, risk, cost, and schedule, and obtain written approval before changing the baseline.

Contract checklist: statement of work, deliverables, acceptance windows, change-request mechanism, IP ownership and third-party licensing, confidentiality, data processing, subcontractors, security incident notice, service/support responsibilities, termination assistance, source and infrastructure access, warranties, and dispute escalation. Legal counsel should adapt these terms to the jurisdiction.

Validation gate: both parties sign the scope baseline, assumptions, decision rights, acceptance method, and exit responsibilities. No one should confuse “code handed over” with “system operable independently.”

Phase 2 — Turn a business goal into testable specifications

Functional example

Story: As a dispatcher, I want delayed shipments ranked by urgency so I can assign interventions.

Acceptance criteria:

1. Given a shipment predicted to miss its delivery window by more than 20 minutes, when the forecast is updated, the shipment appears in the exception queue.
2. A dispatcher can acknowledge an alert and assign an owner.
3. Replayed telemetry does not create duplicate active alerts for the same shipment and rule version.
4. If location data is stale, the UI clearly shows its age rather than presenting it as current.
5. Every acknowledgment and assignment records actor, time, and shipment identifier.

Nonfunctional example

These are starting negotiation values, not promises that every system can or should meet. Define the population, exclusions, load profile, and measurement window before approving them.

Validation gate: product, engineering, security, and operations sign off on representative examples, failure behavior, data ownership, and measurable NFRs. Trace each critical requirement to a test or observable signal.

AI contribution: propose edge cases, convert approved requirements into draft Gherkin scenarios, review ambiguities. Human check: independently compare generated tests to the requirement; an AI can write a test that faithfully validates the wrong behavior.

Phase 3 — Architecture and risk decisions

The team chooses an incremental architecture: a telemetry ingestion adapter, event stream, shipment-state processor, alert rules service, operational API, and web UI. It deliberately avoids splitting every function into a microservice.

flowchart LR
  T[Vehicle telemetry] --> I[Ingestion adapter]
  I --> Q[Durable event stream]
  Q --> P[Shipment state processor]
  P --> D[(Operational data store)]
  P --> R[Alert rules]
  R --> D
  D --> A[API]
  A --> U[Dispatcher UI]
  P --> O[Metrics and traces]
  A --> O

ADR-004 — Asynchronous telemetry processing

• Context: connectivity is intermittent; messages may be duplicated or reordered.
• Decision: durable events, explicit idempotency keys, bounded retries, dead-letter handling, and freshness indicators.
• Alternatives: synchronous direct writes; batch imports.
• Consequences: additional operational complexity, eventual consistency, replay and schema-evolution obligations.
• Revisit when: volume, delay, or operational burden invalidates the assumptions.

Threat model: tenant isolation, forged telemetry, compromised API tokens, overprivileged service accounts, leaked location history, supply-chain compromise, and AI-agent access to production secrets.

Validation gate: architecture review checks failure modes, load estimates, security boundaries, ADR trade-offs, and a working vertical slice. A diagram alone is not evidence.

Phase 4 — Agree on how the team communicates

Communication is an engineering control when it preserves decisions and surfaces uncertainty.

Example weekly update:

Status: Amber — telemetry integration

Completed: replay-safe ingestion prototype, 14 integration tests.

Evidence: duplicate events no longer create duplicate shipment-state transitions in the test environment.

Risk: partner API rate limit is undocumented; pilot throughput may be affected.

Decision needed by Thursday: authorize a partner load test or accept a lower initial fleet limit.

Owner: Northstar integration lead. Next update: Friday 15:00.

Validation gate: decisions have owners and deadlines; risks have mitigation or explicit acceptance. A green status without evidence is not a control.

Phase 5 — Build with AI, without outsourcing accountability

AI can help throughout the lifecycle, but different tasks require different permissions and verification.

Example AI-agent policy:

agent_policy:
  approved_tools: [repository_reader, test_runner, issue_tracker]
  default_permissions: read_only
  allowed_changes: [feature_branch, pull_request]
  prohibited: [production_deploy, secret_read, permission_grants]
  required_checks:
    - human_code_owner_review
    - automated_tests
    - dependency_and_secret_scans
    - security_review_for_sensitive_changes
  audit:
    record_agent_identity: true
    record_tool_actions: true

This is a conceptual policy, not a vendor-specific enforceable configuration. Enforce permissions in the actual identity, repository, CI, and infrastructure systems. Treat retrieved documents, issue descriptions, and tool output as untrusted inputs to agents.

A useful AI evaluation compares similar work over time: cycle time, review burden, escaped defects, rework, and customer outcomes. Do not infer productivity from generated lines of code or number of prompts. Use matched tasks or staged pilots where possible; control for task complexity and team differences.

DORA's 2025 research reported widespread AI adoption and positive associations with throughput and product performance, while finding a negative association with delivery stability. That is a warning against equating faster code production with a healthier delivery system. DORA 2025.

OWASP SAMM's AI-assisted development guidance similarly emphasizes approved tools, scoped permissions, source and licensing policies, and deterministic verification beyond AI-based review: OWASP SAMM guidance.

Phase 6 — Define objective release gates

The team creates a Definition of Done for a feature and a stricter production release gate for a deployable change.

Feature done: reviewed acceptance criteria, passing relevant tests, observability included, documentation updated, no unapproved critical security findings, and product-owner acceptance for user-facing behavior.

Production gate:

1. Build is reproducible and artifacts have provenance.
2. Unit, integration, contract, and risk-relevant end-to-end tests pass.
3. Dependency, secrets, and static-security checks satisfy policy.
4. Performance checks meet the agreed load envelope.
5. Database migrations are forward/backward compatible or have a safe plan.
6. Feature flags, canary rollout, and rollback or roll-forward procedures are rehearsed.
7. Dashboards and alerts cover the new critical path.
8. Named owner accepts residual risks and authorizes release.

Failure example: the generated code passes unit tests but accidentally allows one tenant to query another tenant's shipments. The negative authorization suite fails. The pipeline blocks release even though the feature demo looks correct.

Validation gate: store the evidence in the PR, build, test report, and release record. Exceptions require a named approver, expiry date, mitigation, and follow-up issue.

NIST's Secure Software Development Framework provides a useful organizing model: prepare the organization, protect software, produce well-secured software, and respond to vulnerabilities.

Phase 7 — SLIs, SLOs, SLAs, and operational negotiation

An SLI measures service behavior. An SLO defines a reliability target. An SLA is a contractual commitment with measurement terms and potentially remedies.

For the pilot, Northstar and Harbor propose:

• Availability SLI: successful eligible API requests / all eligible API requests, with explicit rules for timeouts and excluded traffic.
• Availability SLO: at least 99.9% over a rolling 30-day window.
• Freshness SLI: share of accepted events visible to dispatchers within 120 seconds.
• Freshness SLO: at least 95% over seven days.
• Support SLA: severity-based response and escalation commitments, distinct from time-to-resolution promises.

For one million eligible requests in the SLO window, a 99.9% target allows 1,000 unsuccessful requests. If the system records 1,300, it misses the objective. A 99.9% time-based target corresponds to about 43.2 minutes of unavailability in 30 days, but request-based and time-based budgets are not interchangeable.

Example support negotiation:

Customer: We want all incidents fixed within one hour.

Operations lead: We can commit to a 15-minute acknowledgment for Sev-1 incidents with 24/7 coverage, but cannot guarantee every root cause is resolved in an hour. Let's separately define restoration targets, escalation, communication intervals, and service remedies.

Customer: What if we lose tracking during a carrier outage?

Operations lead: The system should mark the data stale, queue retries where possible, and report dependency impact. The contract needs to distinguish our controllable failures from upstream outages without hiding the user's experience.

Illustrative severity matrix:

Do not copy these commitments into a contract without verifying staffing, monitoring, holidays, time zones, and actual ability to respond.

Error-budget policy: when the service exhausts its agreed budget, pause discretionary risky releases and prioritize reliability, with exceptions for urgent security and recovery work. Google's SRE error-budget policy example illustrates how to formalize that decision without using reliability as a punishment.

Phase 8 — Measure the entire system, not just the developers

Create a measurement plan before the pilot. Every metric needs a definition, event source, owner, review cadence, and response when it moves.

DORA now defines five software-delivery performance metrics, including deployment rework rate. Use its current definitions rather than an outdated four-metric slide: DORA metrics guide.

Example instrumentation

shipment_alert_created{shipment_id, rule_version, timestamp}
shipment_alert_assigned{shipment_id, actor_id, timestamp}
telemetry_accepted{event_id, source, timestamp}
telemetry_visible{event_id, timestamp}
deployment_completed{service, version, timestamp}
incident_opened{severity, service, timestamp}
incident_restored{incident_id, timestamp}

This is an event schema illustration, not a recommendation to put shipment IDs, event IDs, or actor IDs into Prometheus metric labels. High-cardinality identifiers belong in appropriately protected logs, traces, or event stores; aggregate metrics should use bounded labels. Protect personal and location data with access controls and retention limits.

How to validate a metric

For alert-to-assignment time, verify the start event represents an actionable alert, not a background recalculation; use consistent clocks; exclude test data; inspect missing assignments; compare median and p90; segment by region and shift; and sample raw records manually. Without these checks, a falling median might simply mean the team stopped recording difficult cases.

For AI-assisted changes, establish a baseline and compare review time, escaped defects, change fail rate, and outcomes. Label changes consistently, note mixed human/AI work, and avoid ranking individual engineers. An observational improvement is not proof that AI caused it.

Phase 9 — Run a pilot and decide with evidence

Pilot plan: 100 vehicles, two teams, four weeks of live operation after readiness approval. Compare against a baseline and, where feasible, a similar team not yet using the new workflow.

Illustrative pilot results:

Steering committee decision: do not declare complete success based on one favorable number. Extend the pilot for two weeks, prioritize freshness and p90 delays, and then reassess. The contract's acceptance criteria and change-control mechanism determine whether this is remediation within scope or new work.

Validation gate: documented go/no-go decision, evidence pack, residual risks, and named owner for every unresolved issue.

Phase 10 — Operate, respond, learn

At 09:12, telemetry ingestion falls behind after a partner sends a burst of messages.

Example incident communications:

09:20 — Initial notice: We are investigating delayed shipment updates affecting some dispatchers. Current location timestamps remain visible. Next update by 09:50.

09:42 — Progress: Ingestion backlog is elevated. We have reduced nonessential processing and are draining the queue. No evidence of lost accepted events so far; verification continues.

10:18 — Restoration: Processing delay has returned within the operational threshold. We will monitor recovery and publish a post-incident review within three business days.

The postmortem documents impact, detection delay, timeline, contributing factors, what worked, and corrective actions. Avoid blaming individuals; focus on system improvements.

Example follow-up: add backlog-based autoscaling within tested limits, replay a production-like burst in staging, and introduce an alert on the freshness SLI rather than relying solely on CPU utilization.

Validation gate: run the new test, verify alerts fire, assign remediation owners, and confirm that the same failure mode is less likely or less damaging. Closing the incident ticket is not equivalent to closing the risk.

Phase 11 — Handover and the ownership test

A mature handover is not a ZIP file and a farewell meeting. Northstar should be able to deploy, restore, diagnose, and evolve the system without depending on Harbor's undocumented knowledge.

Exit rehearsal: Northstar engineers, using their own identities, provision a nonproduction environment, deploy a release, rotate a secret, diagnose a simulated outage, restore data from backup, and make a small approved change. Harbor observes but does not operate the keyboard.

Handover evidence: repository and artifact ownership; infrastructure-as-code; architecture and ADRs; API/schema contracts; access and credential inventories; runbooks; dashboards; on-call routing; dependency/license inventory; backup restoration records; known risks; costs; and a transition support plan.

Validation gate: the customer performs the exit rehearsal successfully, with agreed exceptions tracked to resolution. Ownership becomes a demonstrated capability, not a contract adjective.

A reusable gate matrix

What to automate—and what not to

Automate repeatable evidence collection: builds, tests, security scans, deployment records, service indicators, change logs, and cost allocation. Use AI to reduce clerical work and broaden analysis. Keep accountable human decisions at business acceptance, security exceptions, architectural trade-offs, contractual changes, and high-impact production operations.

The deeper point is that AI makes the gap between producing code and owning outcomes more visible. If generated code accelerates delivery but review, integration, operations, and customer learning remain bottlenecks, the organization has only moved the queue.

In 2026, enterprise software maturity should be judged less by how quickly a team produces artifacts and more by whether it can prove value, explain decisions, recover from failure, control risk, and transfer operational independence.

Further reading and research basis

These are primary or authoritative practitioner sources. They support the frameworks and general findings above; the fictional scenario, dialogue, targets, and pilot data are original teaching examples.

1. DORA — Software Delivery Performance Metrics. Current five-metric definitions, measurement pitfalls, and application-level comparisons. https://dora.dev/guides/dora-metrics/
2. Google Cloud / DORA — 2025 State of AI-Assisted Software Development. Research on AI adoption, organizational capabilities, throughput, product performance, and stability. https://cloud.google.com/resources/content/2025-dora-ai-assisted-software-development-report
3. Google Cloud — Announcing the 2025 DORA Report. Summary of survey findings and their interpretation. https://cloud.google.com/blog/products/ai-machine-learning/announcing-the-2025-dora-report
4. NIST — Secure Software Development Framework (SP 800-218). Secure development practices and governance. https://csrc.nist.gov/projects/SSDF
5. NIST NCCoE — DevSecOps Notional Reference Model. Lifecycle gates, supply-chain provenance, and AI-assisted DevSecOps considerations. https://pages.nist.gov/nccoe-devsecops/notational-reference-model.html
6. OWASP SAMM — Guidance for AI-Assisted Development. AI governance, security testing, tools, autonomy, and verification. https://owaspsamm.org/docs/guides/ai-assisted-development/
7. Google SRE Workbook — Error Budget Policy. Operational policy example for balancing releases and reliability. https://sre.google/workbook/error-budget-policy/
8. UK Government Digital Service — Service Level Objectives. Practical service objectives and continuous improvement. https://gds-way.digital.cabinet-office.gov.uk/standards/slo.html

What is the strongest proof of ownership you've seen in an enterprise handover: source-code access, a successful restore, or the customer's ability to ship the next feature without the vendor?