「わからないまま実装」をやめると、チームは速くなる

Posted at 2026-06-12

AI時代に詰まるのは実装ではなく「何を作るか」

AIコーディングツールの普及で、コードを書く速度は上がりました。

実装のたたき台、テストの雛形、リファクタリング、エラー調査。これらはAIでかなり速くなります。

しかし、開発チーム全体を見ると、次のような問題は残ります。

実装中に仕様の不明点が次々に出る
PdMやデザイナーとの認識ズレが後から分かる
見積もりより工数が膨らむ
レビューで設計方針の議論に戻る
「それは今回やるんだっけ」が何度も起きる
入社歴の浅いメンバーが暗黙知で止まる

つまり、AIで実装が速くなるほど、上流の曖昧さが目立ちます。

これからの開発チームに必要なのは、実装前に不確実性を見つける仕組みです。

この記事では、「わからないまま走る」状態をやめるための具体的なプロセス改善を、チームでそのまま試せる形に整理します。

手戻りは実装力不足ではなく、未解決の疑問から生まれる

実装中に手戻りが起きると、つい「もっと設計すべきだった」「もっと実装前に考えるべきだった」と反省しがちです。

しかし、もう少し分解すると、手戻りの原因はだいたい次のどれかです。

原因	起きること
要件の曖昧さ	何を満たせば完成か分からない
スコープの曖昧さ	今回やること、やらないことが曖昧
ドメイン知識不足	暗黙知を知らずに実装する
画面上の認識ズレ	テキスト仕様では気づかない漏れがある
外部依存	API制限やデータ構造の差分で詰まる
設計判断の未記録	なぜその設計にしたか後から分からない

実装者が優秀でも、これらが未解決のままなら迷います。

AIが速くコードを書いても、間違った前提で速く進むだけです。

だからこそ、実装に入る前に「何が分かっていないか」を見える化する必要があります。

「わからない」を責めずに、チームの入力に変える

不確実性の高いプロジェクトでは、「分からないことがある」のは普通です。

問題は、分からないことが見えないまま実装へ進むことです。

チームで持つべき合言葉は、これです。

わからないまま走らない

この言葉の意味は、慎重になりすぎて動かないことではありません。

分からないことを実装中に爆発させるのではなく、実装前に集め、整理し、判断できる状態にするということです。

そのために使える施策は次の6つです。

実例マッピングで要件を具体化する
仕様検討会で画面を見ながら認識を合わせる
質問箱で疑問と意思決定を流さない
設計合意をMarkdownで残す
バグバッシュとドッグフーディングで早く触る
AIにドキュメントを渡して領域を広げる

順番に見ていきます。

実例マッピングで「今回はやらないこと」まで決める

実例マッピングは、ユーザーストーリーを具体的なルール、例、質問に分解する手法です。

一般的には、次の4つを使って整理します。

種類	意味
Story	対象となるユーザーストーリー
Rule	守るべき業務ルールや条件
Example	具体的な入力、状態、期待結果
Question	まだ分からないこと

ポイントは、抽象的な要件をそのまま受け取らないことです。

たとえば、次の要件があるとします。

外部ツールと連携して、プロジェクトの情報を取り込めるようにする

このまま実装に入ると危険です。

実例マッピングでは、次のように具体化します。

## Story
ユーザーは外部ツールのプロジェクト情報を取り込める

## Rule
- 連携できるのは管理者だけ
- 取り込み対象は指定されたプロジェクトのみ
- 既存データと重複した場合は上書きしない
- API制限にかかった場合は再試行する

## Example
- 管理者が有効なURLを入力すると、プロジェクト一覧が取得される
- 一般ユーザーが連携しようとすると、権限エラーになる
- 既に存在するプロジェクトはスキップされる
- API制限にかかった場合、一定時間後に再実行できる

## Question
- API制限に何回まで再試行するか
- 取り込み失敗時にユーザーへどう通知するか
- 削除済みプロジェクトはどう扱うか
- 今回は双方向同期までやるか

ここで大切なのは、質問を悪いものとして扱わないことです。

質問が多いなら、そのストーリーはまだ実装準備ができていないと判断できます。

実例マッピングの進め方

おすすめは、見積もり前に30〜45分で実施することです。

参加者:

PdM
エンジニア
QA
デザイナー
必要ならCSや営業

進行:

Storyを1つ選ぶ
Ruleを出す
RuleごとにExampleを出す
不明点はQuestionに逃がす
今回やらないことを決める
Questionが多ければ実装前に調査する

「やること」だけでなく「やらないこと」を決めるのが重要です。

スコープが曖昧なまま走ると、実装中に膨らみます。

仕様検討会はFigmaや画面を見ながらやる

テキストの仕様だけでは、認識ズレに気づけないことがあります。

特に画面や操作が関わる機能では、実際の見た目を見ながら話した方が早いです。

仕様検討会では、仮デザインやワイヤーフレームを見ながら、チーム全員でコメントします。

見る観点:

この表示はどの条件で出るか
空の状態はどう見せるか
エラー時はどうするか
権限がないユーザーには何を見せるか
ローディング中はどうするか
長い文字列はどう折り返すか
外部APIが失敗したときはどうするか

依頼テンプレート:

## 仕様検討会チェックリスト

### 状態
- 初期状態
- 読み込み中
- 成功
- 空
- エラー
- 権限なし

### データ
- 0件
- 1件
- 大量
- 重複
- 不正な値
- 外部API失敗

### 操作
- クリック後の動き
- 戻る操作
- 再実行
- キャンセル

### 確認したいこと
- 今回やること
- 今回やらないこと
- 実装前に決めること

仕様検討会は、長くやる必要はありません。

重要なのは、実装後に発見すると高いズレを、実装前に潰すことです。

質問箱で「誰がボールを持っているか」を見える化する

開発中に疑問が出るのは自然です。

問題は、疑問がチャットに流れて消えることです。

そこで、質問箱を作ります。

質問箱は、簡易ADRと課題管理の中間のようなものです。

項目例:

項目	内容
質問	何が分からないか
背景	なぜ確認が必要か
影響範囲	決まらないと何が止まるか
担当者	誰が回答するか
ステータス	未回答、確認中、決定、保留
決定内容	どう決めたか
決定日	いつ決めたか
関連リンク	PR、Issue、Figma、仕様書

質問箱の例:

## 質問
外部APIのRate Limitに達した場合、ユーザーには何を表示するか

## 背景
大量データの取り込み時にAPI制限へ到達する可能性がある

## 影響範囲
- 取り込み処理
- エラーメッセージ
- 再実行導線
- QA観点

## 担当者
PdM

## ステータス
確認中

## 決定内容
未決

朝会では、質問箱の未決だけを確認します。

昨日の進捗は？

ではなく、

いま誰の判断待ちで止まっているか？

を確認します。

これだけで、実装中の詰まりがかなり見えやすくなります。

設計合意はMarkdownでリポジトリに残す

設計方針は、口頭やチャットだけで決めると後から分からなくなります。

特に入社歴の浅いメンバーが多いチームでは、設計の背景が残っていないとレビューが属人化します。

そこで、設計合意をMarkdownで残します。

ADRは、設計判断を短く記録する方法として広く使われています。重要なのは、きれいな文書を作ることではなく、なぜその判断をしたのかを後から追えることです。

テンプレート:

# 設計メモ: 外部ツール連携の取り込み方式

## 背景

## 決めたいこと

## 選択肢
### 案A
- メリット:
- デメリット:

### 案B
- メリット:
- デメリット:

## 決定

## 理由

## 影響範囲

## 残課題

## レビュー時に見ること

設計メモは、PRレビューの基準になります。

レビューで「なぜこの実装なのか」という議論に戻るのではなく、合意済みの設計に沿っているかを確認できます。

バグバッシュとドッグフーディングで早く違和感を見つける

実装がある程度動くようになったら、開発チーム以外にも触ってもらいます。

バグバッシュは、短時間で集中的にバグや違和感を見つける活動です。

ドッグフーディングは、自分たち自身がユーザーとして製品を使うことです。

どちらも、実装後半でやるより早い段階でやる方が効果があります。

60分のバグバッシュ例

時間	内容
0〜5分	対象機能と観点を説明
5〜35分	各自で触る
35〜50分	見つけた問題を共有
50〜60分	優先度を決める

観点:

期待通りに使えるか
操作に迷うところはないか
エラー時の表示は分かりやすいか
データが多い場合でも使えるか
権限や表示制御に違和感はないか
ユーザーに説明しづらい箇所はないか

参加者は、開発者だけにしない方がよいです。

CS、営業、サポート、デザイナーなど、ユーザーに近い人に触ってもらうと、仕様書では出てこない違和感が見つかります。

AIはドキュメントがあるほど強くなる

AIを活用するなら、チームの合意や設計をMarkdownで残す価値はさらに上がります。

なぜなら、AIに渡せるからです。

AIに渡しやすい情報:

実例マッピングの結果
質問箱の決定済み項目
設計メモ
仕様検討会の決定
バグバッシュで見つかった問題
テスト観点

依頼例:

以下の設計メモと質問箱の決定内容をもとに、テスト観点を作ってください。

出力:
- 正常系
- 異常系
- 権限
- 外部API失敗
- データ0件
- 大量データ
- 今回テストしないこと

AIに丸投げするのではなく、チームで合意した文脈を渡して補助してもらうのがポイントです。

ドキュメントがないと、AIは推測します。

ドキュメントがあると、AIはチームの判断に沿って動きやすくなります。

開発指標で「急がば回れ」を説明する

上流に時間を使うと、一時的に実装速度が落ちたように見えます。

そのため、プロセス改善は感覚だけで進めると反発が出やすいです。

開発指標で見ると説明しやすくなります。

見るべき指標:

指標	見たいこと
サイクルタイム	着手から完了までの時間
PR作成数	実装の流量
PRレビュー待ち時間	レビューで詰まっていないか
手戻り件数	実装後の認識ズレ
見積もり比	見積もりに対して膨らんだか
未決質問数	上流の不確実性が残っているか
SPACEサーベイ	開発者体験が悪化していないか

SPACEフレームワークは、開発者生産性を1つの数字だけで見ない考え方です。

Satisfaction、Performance、Activity、Communication、Efficiencyという複数の観点で見るため、「PR数は増えたが疲弊している」といった状態も拾いやすくなります。

プロセス改善後に見たい変化

実装中に出る質問が減る
PRレビューで仕様議論に戻る回数が減る
見積もり超過が減る
手戻りが減る
PR作成数が安定して増える
メンバーの「迷い」が減る

最初は一時的に速度が落ちても問題ありません。

不確実性を上流で潰せるようになると、その後の実装が速くなります。

2週間で試すプロセス改善プラン

大きく変える必要はありません。

まずは2週間だけ、1つの機能で試します。

1日目: 実例マッピング

やること:

Storyを1つ選ぶ
Ruleを出す
Exampleを出す
Questionを出す
やらないことを決める

成果物:

## Story

## Rule

## Example

## Question

## 今回やらないこと

2〜3日目: 仕様検討会

やること:

Figmaや画面案を見る
状態ごとに確認する
仕様漏れを質問箱に入れる
決まったことを記録する

成果物:

## 仕様検討メモ

- 決まったこと:
- 未決:
- やらないこと:
- 実装前に確認すること:

4〜5日目: 設計合意

やること:

設計案をMarkdownにする
選択肢を比較する
決定理由を書く
レビュー観点を決める

成果物:

## 設計合意

- 採用案:
- 採用理由:
- 捨てた案:
- 影響範囲:
- レビュー観点:

2週目: 実装、バグバッシュ、計測

やること:

小さなPRに分けて実装する
質問箱を毎朝見る
動くものを早めに触る
バグバッシュを実施する
サイクルタイムと手戻りを見る

成果物:

## ふりかえり

- 実装中に出た質問:
- 手戻り:
- バグバッシュで見つかったこと:
- 次回上流で潰したいこと:
- 指標の変化:

明日から変えるならこの3つ

いきなりプロセス全体を変える必要はありません。

明日から変えるなら、まずはこの3つです。

実装前に「Question」と「今回やらないこと」を書く
実装中の疑問をチャットで流さず質問箱に残す
設計判断をMarkdownで残し、レビュー基準にする

AI時代の開発では、コードを書く速度はどんどん上がります。

だからこそ、わからないまま走る危険も大きくなります。

不確実性をなくすことはできません。

しかし、見える場所に出し、チームで判断し、記録してから進むことはできます。

それが、AI時代に「速く、でも手戻り少なく」開発するための現実的なプロセス改善です。

参考リンク

作成日: 2026-06-03

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up