要件が不明確な場合、どのように進めますか?

Question

Accepted Answer

曖昧性は実務では常態です。沈黙で静かに推測し、間違ったものを構築するのではなく、**積極的に不確実性を削減できること**を示す必要があります。

## なぜ重要なのか

```text
1. Ask the questions that change what you'd build
2. Find the goal behind the request (the "why")
3. State your assumptions in writing and confirm them
4. Build a thin slice, demo early, adjust fast
```

## 実例

```text
S: A ticket said "add a dashboard" with no detail on metrics or users.
T: Building blind risked weeks of wasted work.
A: I asked who'd use it and what decision it drove, wrote down three assumptions,
   and built a clickable prototype of the top two metrics first.
R: The demo surfaced that they actually needed exports, not charts. We pivoted
   after two days instead of two weeks.
```

## 優れた例と弱い例

```text
✓ Clarifies the "why," states assumptions, demos early
✗ Building the full thing on a guess
✗ Refusing to start until everything is spec'd
```

## なぜ重要なのか

明確な仕様は稀であり、成功するエンジニアは霧の中を進める能力を持つ者です。

根底にある目標を見つけることで、要求されたものをそのまま構築しつつも、実際には必要なものを見落とさないようになります。

早期に薄いスライスをデモンストレーションすることで、高くつく推測から安くて早い修正に変わります。