システム開発の「仕様策定」にAIを使う場合・使わない場合を比較してみた
はじめに
仕事柄、フリーランスの方と複数クライアントの案件に関わっている事が多いのですが要件定義や仕様書作成のやり方が現場によってかなり違うことに気づきます。最近はAI(ChatGPTやClaudeなど)に仕様のたたき台を作らせる現場も増えてきた一方で、あえて人手だけで進める現場もまだまだ多いです。
両方のやり方を経験してみて感じたメリット・デメリットを整理してみました。
比較表(ざっくり)
| 観点 | AIを使う | AIを使わない(人手のみ) |
|---|---|---|
| スピード | 速い(たたき台がすぐ出る) | 遅い(ゼロから書き起こす) |
| 抜け漏れチェック | 気づきやすい(観点の指摘が得意) | 担当者の経験に依存 |
| 業務・業界特有の勘所 | 弱い(一般論になりがち) | 強い(現場の暗黙知が反映される) |
| 責任の所在 | 曖昧になりがち | 明確(書いた人が責任を持つ) |
| ドキュメントの一貫性 | 高い(表記ゆれが少ない) | 属人的(書く人によってばらつく) |
| ステークホルダーとの合意形成 | AI単体では難しい | 対話の中で自然に合意形成できる |
以下、それぞれ詳しく見ていきます。
AIを使う場合のメリット
たたき台作成が圧倒的に速い
「ユーザー登録機能の仕様書を書いて」と依頼するだけで、項目立てされた骨子がすぐに出てきます。白紙から書き始めるより、たたき台を直していく方が精神的にも楽です。
抜け漏れの指摘が得意
「異常系は考慮した?」「権限がない場合の挙動は?」のように、人間が見落としがちな観点を機械的に洗い出してくれます。レビューの一次チェックとして優秀です。
表記の一貫性が保たれる
用語の統一や文体の揺れが少なく、ドキュメントとしての読みやすさが安定します。複数人で書いた仕様書にありがちな「書く人によって粒度が違う」問題が起きにくいです。
AIを使う場合のデメリット
業界・現場固有の勘所を拾いきれない
「この業界だとこの処理は法律上こう扱う必要がある」「このクライアントは過去にこの仕様で炎上した」といった、その場にいないと分からない文脈をAIは知りません。一般論としては正しくても、現場的にはズレた仕様になることがあります。
もっともらしい誤りに気づきにくい
文章として整っているぶん、内容が間違っていても「それっぽく」見えてしまい、レビューが甘くなるリスクがあります。特に非エンジニアの発注者が内容を鵜呑みにしてしまうケースには注意が必要です。
合意形成のプロセスが飛ばされがち
仕様は本来、関係者間の対話や調整を経て固まっていくものですが、AIが一発で「それっぽい仕様書」を出してしまうことで、本来必要な擦り合わせが省略されてしまう危険があります。
AIを使わない場合のメリット
現場の文脈が反映されやすい
担当者が過去のトラブルや業界特有の事情を踏まえて書くので、実務に即した仕様になりやすいです。
書く過程自体が理解を深める
ゼロから仕様書を書く過程で、要件の矛盾や曖昧さに自分自身で気づくことがよくあります。「書きながら考える」ことの価値は意外と大きいです。
責任の所在が明確
誰が何を意図して書いたかがはっきりしているので、後から「なぜこの仕様になったのか」を追いやすいです。
AIを使わない場合のデメリット
時間がかかる
特に定型的な部分(CRUD操作の仕様など)まで律儀に手書きすると、かなりの時間を消費します。
担当者のスキル・経験に品質が依存する
抜け漏れのチェックや観点の広さは、結局のところ書く人の経験値に左右されます。属人化しやすいポイントです。
実践的な使い分け
今のところ自分がしっくりきているのは、以下のような役割分担です。
- まず自分(人間)で要件のコアになる部分(何をなぜ作るか、業務フロー)を整理する
- 定型的な仕様項目の洗い出しや、抜け漏れチェックの一次パスをAIに任せる
- AIが出した仕様案を、業界知識や過去の経験と照らし合わせて自分で修正する
- 最終的な合意形成は必ず人間同士の対話で行う
「AIに仕様を書かせる」のではなく「AIをレビュアー兼たたき台生成係として使う」くらいの距離感が、今のところ一番バランスが良いと感じています。
まとめ
AIは仕様策定のスピードと抜け漏れチェックには明確に貢献しますが、業界固有の勘所や合意形成のプロセスまでは代替できません。「速さ」と「現場感」はトレードオフになりやすいので、案件の性質(定型的か、業界特有の複雑さがあるか)によって使い分けるのが現実的だと感じています。