プログラミングができない人がAIでどうやって開発に参加するか

2026/8/2

「コードが書けないから」と黙る時代は終わった——非エンジニアが開発の主役になる方法

ある企画会議で、業務改善ツールの要件を議論していたときのこと。現場を最もよく知る担当者が「私、技術のことは分からないので」と一歩引いた。その結果、できあがったツールは現場の実態とズレ、使われないまま放置された。よくある光景だ。だが今、この構図は崩れつつある。

この記事の主張:非エンジニアの参加範囲は「5つの工程」に広がった

コードが書けなくても、あなたは開発の重要な工程に主役として関われる。具体的には「業務整理」「要件定義」「画面確認」「受入テスト」「改善判断」の5つだ。この記事を読めば、どの工程で何をすればいいか、そしてエンジニアに任せるべき範囲との線引きが分かる。結果として、使われないツールを作る失敗を減らせる。

なぜ今、この問題が起きているのか

背景には、AIとローコード(コードをほとんど書かずにアプリを作る手法)の普及がある。従来、要件を「動くもの」に変える工程はエンジニアの専門領域だった。だが今は、生成AIが要件文から画面のたたき台を作り、修正指示も自然な日本語で通る場面が増えている。

これにより、開発のボトルネック(詰まりやすい箇所)が「作る技術」から「何を作るか決める判断」へと移った。判断の材料を最も持っているのは、コードを書けるエンジニアではなく、業務を知る現場担当者だ。ここに非エンジニアの出番が生まれている。

現場では何が起きているのか

変化1:要件を「文章」ではなく「画面イメージ」で確認できる

以前は、要件定義書という文字だらけの資料をやりとりしていた。読み解くのに専門知識が要り、現場担当者は判断できなかった。今はAIが要件から画面のモックアップ(見た目だけの試作画面)を短時間で生成する。「この配置だと使いにくい」と、現物を見て言えるようになった。

変化2:小さく作って早く見せるサイクルが回り始めた

ある物流会社では、在庫管理画面を「完成品」ではなく「たたき台」の状態で現場に見せる運用に変えた。担当者が触って「ここに数量の合計がほしい」と言うと、数日で反映される。完成後に「思っていたのと違う」と揉める従来のやり方より、手戻りが激減したという(筆者が取材した一例)。

変化3:改善提案が「感想」から「仕様」に昇格した

「使いにくい」という曖昧な感想は、以前は握りつぶされがちだった。だが画面を見ながら「この項目を上に、この色を目立たせて」と具体的に指示できるようになり、現場の声が仕様に反映されやすくなった。

従来の方法では対応できない理由

従来の開発は「ウォーターフォール」(工程を上流から下流へ一方通行で進める手法)が主流だった。要件を最初に固め、あとは作るだけ、という前提だ。この方式では、現場が完成品を見るのは最後で、そこで違和感に気づいても直す余地がない。

問題は、業務の要件は「作りながら見えてくる」ことが多い点にある。頭の中だけで完璧な要件は書けない。だからこそ、途中の画面を非エンジニアが繰り返し確認し、軌道修正する関与が不可欠になる。従来の「発注して待つ」姿勢では、この修正機会を活かせない。

経営・組織に与える影響

この変化は、単なる開発手法の話にとどまらず、組織の役割分担や評価にまで及ぶ。

| 領域 | 従来 | これから |

|---|---|---|

| 意思決定 | エンジニア/ベンダー主導 | 現場担当者が仕様判断に参加 |

| 人材要件 | 技術スキル偏重 | 業務理解+言語化力を重視 |

| 教育 | プログラミング研修 | 要件の書き方・テスト観点の研修 |

| 責任分担 | 作る責任=エンジニア | 「何を作るか」は現場も共同責任 |

| 評価 | 実装量で評価 | 業務課題の解決度で評価 |

特に重要なのは「責任分担」だ。非エンジニアが要件と受入テストに関わる以上、「頼んだのに使えない」という他責はもう通用しない。作る側と使う側が共同で品質に責任を持つ体制へ移る。これは推測を含むが、参加した現場ほど、できあがったツールへの納得感が高まる傾向がある。

非エンジニアが5工程で「やること・任せること」の線引き

役割を混同すると、越権になったり丸投げになったりする。下の図で整理する。

図: 開発工程を横軸に置き、上段に「非エンジニアが主役の工程(業務整理→要件定義→画面確認→受入テスト→改善判断)」、下段に「エンジニアに任せる工程(技術選定・設計・実装・セキュリティ・保守)」を並べた分担図。両者は要件定義と画面確認で重なり合う。

そのまま使える「要件伝達プロンプト」

AIや開発担当に要件を渡すとき、非エンジニアでも抜け漏れなく伝えられるテンプレートです。〈〉部分を埋めて使ってください。

```text

用途: 非エンジニアが業務ツールの要件をAI/開発者へ伝えるプロンプト

あなたは業務アプリの設計担当です。以下の情報から、画面イメージと

確認すべき点を整理してください。専門用語には短い説明を付けてください。

誰が使うか

〈例: 倉庫の在庫担当者、1日30回操作、PC操作は苦手〉

今困っていること

〈例: 在庫数を紙とExcelで二重管理していてズレる〉

このツールで実現したいこと

〈例: 入出庫を1画面で登録し、合計を自動計算したい〉

必ず表示・入力したい項目

〈例: 商品名、数量、日付、担当者名、合計欄〉

やってはいけないこと・制約

〈例: 在庫がマイナスになる登録は防ぎたい〉

出力してほしいもの

1. 画面レイアウトの説明(文章で)

2. 私が受入テストで確認すべきチェック項目

3. 判断が必要な論点(私に質問してほしい点)

```

受入テスト観点を洗い出すMermaidフロー

受入テスト(納品物が要件どおりか使う側が確認する工程)で、何を確認するかの判断手順です。

```mermaid

flowchart TD

A[画面を受け取る] --> B{通常業務の操作ができる?}

B -->|できない| C[操作手順を記録し差し戻し]

B -->|できる| D{異常な入力を防げる?}

D -->|防げない| E[NGパターンを列挙し報告]

D -->|防げる| F{現場の実データで正しい結果?}

F -->|ズレる| G[具体例つきで再現手順を共有]

F -->|正しい| H[合格・本番展開へ]

```

企業は何から始めるべきか

1. 現場担当者を要件定義の会議に必ず入れる:上流から巻き込むことで手戻りを防ぐ。オブザーバーでなく発言者として。

2. 「たたき台を早く見せる」運用を標準化する:完成を待たず、途中画面を現場が触る機会を制度に組み込む。

3. 受入テストの観点を研修する:プログラミングでなく「何を確認すべきか」を教える。上のフロー図が教材になる。

4. 評価基準を「解決度」に寄せる:実装量でなく、業務課題がどれだけ解けたかで評価する。

5. エンジニアに任せる範囲を明文化する:セキュリティや設計まで非エンジニアが口を出すと事故る。線引きを共有しておく。

まとめ

「コードが書けないから」と黙る必要はもうない。あなたは業務整理・要件定義・画面確認・受入テスト・改善判断という5つの工程で開発の主役になれる。まず最初の一歩として、次の企画で「たたき台の画面を早めに見せてほしい」と一言伝えることから始めてほしい。

実践チェックリスト

次に読む記事

よくある質問

Q. 結局、非エンジニアもプログラミングを学ぶべきですか?

必須ではありません。この記事で紹介した5工程は、コードを書けなくても参加できます。ただし「どこまで自動化できるか」の感覚があると要件の解像度が上がるため、簡単なローコードツールを触ってみる程度は有益です。

Q. 現場が要件に口を出すと、開発が遅くなりませんか?

短期的には確認の手間が増えますが、完成後の作り直しが減るため、多くの場合トータルでは速くなります。重要なのは「早い段階で・具体的に」関与することで、完成間際のちゃぶ台返しを避けることです。

Q. エンジニアとの役割分担で揉めないコツは?

「何を作るかは現場、どう作るかはエンジニア」という原則を最初に共有することです。設計やセキュリティなど技術判断に非エンジニアが介入すると事故のもとになるため、線引きを文書化しておくと衝突を防げます。