Output went up but speed did not: a one-day AIDD with planning, dev and business
AIでアウトプットは増えたのに、なぜ速くならないのか──企画 × 開発 × ビジネスで挑んだ 1Day AIDD
B · Useful, limited Practitioner account by a planner and a dev lead at LY Corporation's LINE Research platform of a one-day cross-functional build; clear diagnosis of where AI gains stall, but one workshop, no time or quality measurements.
Summary based on the full text·Original: about 8 minutes to read
In short
A LY Corporation tech blog post (late October 2026; date from the URL) by a product planner and a development lead on LINE Research, a survey platform. Each role, business, planning and development, already used AI and produced more, yet features did not reach users any faster. Their diagnosis: the bottleneck was the silo structure between roles, not any single step. A one-day in-person workshop, with the final decision-maker in the room, took a cross-tabulation MVP from requirements to a staging deployment with tests passing. The bottleneck then moved to decisions.
Key numbers
- dozensspec questions with options the AI raised during requirements analysis, each decided on the spot
- 4units implemented in the afternoon: aggregation core, admin API, frontend, integration checks
- 3conditions the authors give for repeating it: narrow scope, decision-maker present, all context in AI-readable form
- 6 August 2026date of the in-person AIDD Workshop in Fukuoka
As reported by the source.
Japanese·Web page·opens techblog.lycorp.co.jp
What it reports
- Before: business gave problems to planning, planning wrote a spec, development pushed back, planning took it away and came back. Questions during build piled up as Q&A and specs were redone. Planning acted as translator but could not read code or see primary customer input.
- Preparation: a pre-workshop sheet fixed a one-sentence goal, constraints, scope and the final decision-maker. Planning wrote the spec with AI and made HTML mock-ups; requirements went into Markdown. Development brought an AI-oriented docs repo, a spec repo and a PR-review Agent Skill.
- The hardest preparation step was setting up planners and business staff: GitHub accounts, AI coding tools, skills.
- On the day (from 10:00): reverse-engineer the code and analyse requirements; write user stories and plans; build four units; build, test, deploy to staging and check with real data.
- The AI's business overview from code alone was wrong; it was redone with business documents. The AI raised dozens of spec questions with options (CSV encoding, access after a permission change, sync or async), decided one by one on the spot instead of over days.
- Output: a working cross-tab MVP (single, multiple and matrix questions, CSV/ZIP export), backend and frontend tests and regression tests passing, staging deployment, no process rework.
- Not done: QA on staging, recorded evidence for permission-denial checks, review of the large volume of AI-generated design documents.
- Outside the workshop, AI-driven work cut development load but concentrated decisions on planners and business owners. The next experiment is to rank decisions by importance and delegate low-stakes ones, with AI agents enforcing the reporting of what was decided.
How they got it
Participants' own account of one internal workshop, with a before-and-after process comparison. No measurement of cycle time, effort or defects.
Limits
- One workshop on a deliberately narrow feature; speed gains are described as felt, not measured.
- The team's AI context sits in individual members' local environments, not a shared resource.
- GitHub access for non-developers, device performance, AI platform latency and cost are named as barriers.
- Review and QA of AI-generated volume is an open problem the authors flag.
Why it matters for companies
The post names a common pattern: per-role AI use raises output but not delivery speed, because handoffs between functions set the pace. The fix tested here is organisational: the people who decide sit with the builders, and all functions put their context where the AI can read it. Once that works, decisions become the constraint, so companies need explicit rules for which decisions can be delegated and how they are recorded.
Key passages in translation
Japanese original
結論から言えば、ボトルネックは工程の外、チームの構造にありました。
In short, the bottleneck was outside the process steps, in the structure of the team.
Japanese original
この日に実感した変化を一言で言うなら、速くなったというより、深くなったです。
If we had to name the change we felt that day in one word, it got deeper rather than faster.
Japanese original
AIによってサイロ化は解消されましたが、その結果、ボトルネックは意思決定へと移りました。
AI removed the silos, but as a result the bottleneck moved to decision-making.
Summary based on the full text. Read the original for the full argument and data.Read the original on techblog.lycorp.co.jp