記事一覧

「あの実装、なぜこうしたの?」を撲滅する引き継ぎ運用──PRと作業記録で判断理由まで残す方法 担当者が異動・退職しても作業が止まらないチームを作るには、成果物だけでなく「なぜそう決めたか」を残すことが不可欠です。本記事はPMや業務責任者向けに、Pull Request(コードの変更依頼書）や作業記録を引き継ぎ書として使う具体的な運用を解説します。 この記事の結論 引き継ぎは「別ファイル」ではなく、日々のPR・作業記録に埋め込むのが最も続く。 残すべきは4点：①実装内容 ②判断理由 ③未対応事項 ④確認方法。 特に抜けやすいのは「判断理由」。採用案だけでなく却下した案を書くと後任が迷わない。 テンプレートを標準化し、レビュー時に空欄を指摘すれば品質が安定する。 AI（Claude Code等）に差分を渡せば、PR説明文の下書きを自動生成できる。 この記事が役立つ人 属人化した業務を抱え、担当者不在時に作業が止まった経験があるPM・チームリーダー。 外注・業務委託の成果物を受け取る立場で、後から質問が発生しがちな業務責任者。 前提：GitHub / GitLab などでPRやIssueを運用している、または導入を検討中のチーム。 補足：エンジニアでなくても対象です。PRは「変更内容と理由を記録する仕組み」であり、ドキュメント運用の一種として理解すれば十分活用できます。 なぜ「引き継げない」問題が起きるのか 原因の多くは「成果物は残るが、意思決定の過程が残らない」ことにあります。コードや資料そのものは見えても、なぜその方法を選んだかは担当者の頭の中にしか無い状態です。 さらに引き継ぎ書を「独立した特別なドキュメント」として作ろうとすると、作成コストが高く後回しになります。結果、退職・異動の直前に大量の情報を思い出しながら書くことになり、精度も網羅性も落ちます。 図: 「作業→記録→レビュー→蓄積」が日常のPRに組み込まれている状態と、「作業だけ進み、退職直前に記憶で引き継ぎ書を作る」状態の対比図。前者は情報が分散せず、後者は情報が担当者に集中して失われる。 解決するための5つのポイント 1. 引き継ぎ書は作らず「PR・作業記録に埋め込む」 結論：専用の引き継ぎ書を別途作るより、日々のPRに情報を残す方が続きます。 例えば「請求バッチの締め日を月末から25日に変更した」作業なら、変更した瞬間にPRへ理由を書きます。後日まとめて思い出す作業がなくなり、情報の鮮度も保てます。 実践方法：後述のPRテンプレートを標準化し、変更を提出する時点で記入を必須にします。 2. 「判断理由」は却下案とセットで書く 結論：採用した方法だけでなく、検討したが選ばなかった案とその理由を残すと、後任の再検討コストが激減します。 例：「非同期処理も検討したが、月次バッチで即時性が不要なため同期処理を採用」と書けば、後任が「なぜ非同期にしなかったのか」と蒸し返す無駄がなくなります。 実践方法：テンプレートに「検討した別案／不採用の理由」欄を必ず設けます。 3. 「未対応事項」を宿題リストとして明示する 結論：やり残しや妥協点を隠さず書くことが、後任の地雷回避につながります。 例：「エラー時のリトライは未実装。手動再実行で対応中。Issue 142で追跡」のように、未完了+対処法+追跡先をセットで残します。 実践方法：未対応はIssue化してリンクを貼り、口頭ベースの申し送りをゼロにします。 4. 「確認方法」を第三者が再現できる粒度で書く 結論：動作確認の手順を、その業務を知らない人が実行できるレベルで残します。 悪い例：「テスト済み」 良い例：「①管理画面〈URL〉にログイン ②請求一覧で25日締めと表示 ③CSV出力し金額が旧月末分と一致しないことを確認」 実践方法：確認手順を番号付きで書き、期待結果まで明記します。 5. レビューで「空欄」を必ず指摘する 結論：テンプレートを作っても、レビューで空欄を許すと形骸化します。 判断理由や確認方法が空のPRは、レビュー担当者が承認前に差し戻す運用にします。これによりチーム全体の記録品質が底上げされます。 実践方法：レビュー観点に「4項目が埋まっているか」を追加し、承認条件に含めます。 良い引き継ぎ／悪い引き継ぎの比較 | 観点 | 悪い引き継ぎ | 良い引き継ぎ | |||| | 実装内容 | 「修正しました」 | 「請求締め日を月末→25日に変更（対象：月次バッチ）」 | | 判断理由 | 記載なし | 「非同期案は即時性不要のため却下、同期を採用」 | | 未対応事項 | 口頭で「あと少し残ってる」 | 「リトライ未実装、Issue 142で追跡」 | | 確認方法 | 「テスト済み」 | 手順①〜③を番号付き＋期待結果で明記 | | 保存場所 | 個人メモ・チャット | PR本文・Issueに集約 | 強調：悪い例に共通するのは「担当者の頭の中を前提にしている」点です。良い例は「その業務を知らない人が読んでも動ける」ことを基準にしています。 そのまま使えるPR／作業記録テンプレート GitHub/GitLabのPRテンプレートや、社内ドキュメントの雛形としてそのまま貼り付けて使えます。 markdown 実装内容 何を変更したか（対象・範囲を具体的に）： 関連Issue / チケット：〈番号〉 判断理由 なぜこの方法を選んだか： 検討した別案と不採用の理由： 影響範囲・注意点： 未対応事項 [ ] 〈残タスク〉（対処法／追跡先：Issue 〈番号〉） [ ] 〈既知の制約〉 確認方法（第三者が再現できる粒度で） 1. 〈手順1〉 2. 〈手順2〉 → 期待結果：〈結果〉 3. 〈手順3〉 レビュー観点 [ ] 上記4項目に空欄がないか [ ] 未対応はIssue化されているか AIやツールで引き継ぎ作成を自動化する 記入負担を減らすには、変更内容をAIに渡してPR説明文の下書きを作らせるのが有効です。以下はClaude Code / Cursor 等に渡すプロンプト例です（下書きの叩き台であり、判断理由は必ず人間が補足します）。 text 用途：変更差分からPR説明文の下書きを生成（Claude Code / Cursor 想定） 以下の変更内容をもとに、PR説明文を作成してください。 出力は「実装内容／判断理由／未対応事項／確認方法」の4見出し構成にします。 制約： 事実は変更内容から拾い、推測部分は「※要確認」と明記する 判断理由が差分から読み取れない場合は「〈理由を記入〉」と空欄で残す 確認方法は第三者が再現できる番号付き手順にする 変更内容： 〈diffやコミットログ、または変更の概要を貼り付け〉 このほか、GitHub Actionsで「PR本文に4見出しが含まれているか」をチェックし、欠けていれば警告する運用も可能です（特定ツールに限らず、CIやレビュー botで代替できます）。 強調：AIはあくまで「下書き係」です。判断理由と未対応事項は業務の意図が絡むため、人間が最終確認する前提を崩さないでください。 実践チェックリスト [ ] PR／作業記録に「実装内容・判断理由・未対応事項・確認方法」の4欄がある [ ] 判断理由に「却下した案」も書かれている [ ] 未対応事項がIssue化され、追跡先リンクがある [ ] 確認方法が第三者に再現できる番号付き手順になっている [ ] レビュー時に空欄を差し戻すルールが承認条件に入っている [ ] AIで下書きを作る場合も、理由は人間が補足している まとめ 引き継ぎの本質は「成果物」ではなく「なぜそうしたか」を残すことです。専用ドキュメントを別に作るのではなく、日々のPR・作業記録に4項目（実装内容・判断理由・未対応事項・確認方法）を埋め込む運用が最も続きます。 最初の一歩：本記事のPRテンプレートをコピーし、次の1件のPRから適用してみてください。まずは「判断理由に却下案を書く」だけでも効果を実感できます。 次に読む記事 基礎：Issue管理入門──タスクの粒度と追跡リンクの付け方 実践：レビュー観点チェックリストの作り方──形骸化させない運用 発展：ADR（Architecture Decision Record）で意思決定を資産化する方法 よくある質問 Q. 非エンジニアの業務でもPRは使えますか？ A. 使えます。PRは「変更内容と理由を記録し、他者が確認する仕組み」であり、資料作成や設定変更の記録にも応用できます。GitHubのWikiやIssueでも同じ4項目を運用すれば効果は同じです。 Q. テンプレートを入れても書かれないのですが？ A. 記入を「レビューの承認条件」にするのが最も効きます。空欄のまま承認しない運用にすれば、書くことが自然に習慣化します。AIで下書きを作り記入コストを下げるのも有効です。 Q. 過去の作業には遡って記録すべきですか？ A. 全件は非現実的です。まず「属人化していて危険な業務」から優先し、判断理由と未対応事項だけでも残すと投資対効果が高くなります。

2026/8/2

複数人・複数AIの同時変更で壊れる原因と、PMが押さえる衝突防止の5原則 複数の開発者やAI（Claude Code、Cursorなど）が同じシステムを同時に触ると、「せっかくの修正が消えた」「動いていた機能が急に壊れた」が起きます。この記事では、非エンジニアのPMが原因を理解し、Git・ブランチ・Pull Requestといった仕組みでどう防ぐかを、専門用語を最小限にして解説します。読み終えると、チームに何を依頼すべきかが判断できます。 この記事の結論 衝突は「同じファイルの同じ箇所を、別々の人・AIが同時に変えた」ときに起きる（事実） 防止の核は「作業を分ける仕組み」＝ブランチ（作業の枝分かれ）と担当範囲の明確化 変更は必ずPull Request（変更を提案してレビューを受ける仕組み）を通して統合する 統合前に「自動チェック（テスト）」を通すと、壊れた状態の合流を防げる PMの役割はコードを書くことではなく、「誰がどこを・どう合流させるか」のルール設計 この記事が役立つ人 エンジニアやAIツールに開発を任せているが、進行管理に不安があるPM・ディレクター 「変更が消えた」「本番が壊れた」トラブルの原因を自分の言葉で理解したい方 前提知識は不要。GitやPull Requestという言葉を聞いたことがある程度でOKです。 なぜこの問題が起きるのか（背景と原因） システムのソースコードは「大量の文書ファイルの集合」です。複数人が同じ文書を同時に上書き保存すると、後から保存した人の内容で前の人の内容が消えます。これがシステム開発でも起きる、衝突の正体です。 さらに近年はAIコーディングツールが加わり、人間1人＋AI複数が並行して同じファイルを書き換える状況が増えました。AIは高速で広範囲を変更するため、人間同士より衝突が起きやすい傾向があります（筆者の観察）。 強調ボックス：衝突＝喧嘩ではない 「衝突（コンフリクト）」はGitが「どちらの変更を採用すべきか自動判断できない」と知らせる正常な警告です。放置や強制上書きが本当の事故を生みます。 mermaid graph TD A[元のファイル] B[Aさんが3行目を変更] A C[Bさん/AIが3行目を変更] B D{同じ場所を別内容に} C D D E[衝突発生：どちらを残す?] 図: 同じ箇所を同時変更すると、システムが判断できず衝突になる流れ 衝突を防ぐための5つのポイント 1. ソースを1か所で共有する（Gitという仕組み） 結論：全員が同じ「共有の正本」を見て作業すれば、バラバラのコピーで食い違うことを防げます。Gitはこの共有と履歴管理を担う仕組みで、GitHubやGitLabがその置き場所です。 具体例：メールでファイルを送り合う運用は「誰の版が最新か」が分からなくなり事故の温床。Gitなら履歴が全部残り、いつでも元に戻せます。 実践方法：PMは「作業は必ずGit上で。ローカルのコピーを直接本番に上げない」をチームの前提として合意します。 2. 担当範囲を分けて「同じ場所」を触らせない 結論：そもそも同じ箇所を同時に触らなければ、衝突の大半は起きません。機能・画面・フォルダ単位で担当を割ると効果的です。 具体例：「決済まわりはAさん、通知まわりはAIとBさん」のように分ける。逆に「共通設定ファイル」は全員が触りがちなので、変更を1人に集約します。 実践方法：タスク分解時に「触るファイル領域」を書き添える。AIに依頼するときも変更範囲を指定します。 3. ブランチ（作業の枝分かれ）で本番から隔離する 結論：各作業を「枝分かれした作業コピー」で行えば、途中の壊れた状態が他人や本番に影響しません。これがブランチです。 具体例：木の幹（本番）から枝を伸ばし、その枝で作業。完成したら幹に合流させる、というイメージです。 mermaid gitGraph commit id: "本番" branch featureA commit id: "Aの作業" checkout main branch featureB commit id: "Bの作業" checkout main merge featureA merge featureB 図: 幹（main）から枝を分け、完成したものだけを合流させる 実践方法：「1タスク＝1ブランチ」を基本ルールに。AIツールにも作業ごとにブランチを切らせます。 4. Pull Requestで「合流前に必ず確認」する 結論：Pull Request（プルリクエスト、略称PR）は「この変更を合流させたい」という提案書です。合流前に第三者が中身を確認できる関所になります。 具体例：Bさんの枝を幹に合流する前に、AさんがPR上で「この変更で問題ないか」を見る。AIが書いたコードも人間がPRでレビューします。 実践方法：PMは「PRなしの直接合流は禁止」「最低1人のレビュー承認を必須」をルール化。PMはコードでなく「変更の意図と影響範囲」を確認します。 5. 統合前に自動チェック（テスト）を通す 結論：合流前に「機能が壊れていないか」を自動で検査すれば、壊れた状態の合流を機械的に止められます。 具体例：PRを出すと自動でテストが走り、失敗すると合流ボタンがロックされる、という設定にできます。 実践方法：CI（継続的インテグレーション：変更のたび自動検査する仕組み）の導入をエンジニアに依頼。PMは「テストが緑（成功）でないと合流不可」の運用を守らせます。 | 仕組み | 役割 | PMが確認すること | |||| | Git | ソースの共有・履歴管理 | 全作業がGit上か | | 担当範囲 | 同時変更の予防 | 誰がどこを触るか明記 | | ブランチ | 作業の隔離 | 1タスク1ブランチか | | Pull Request | 合流前レビュー | 承認なしで合流していないか | | 自動テスト | 壊れの検知 | テスト成功が合流条件か | AIやツールで自動化する方法 AIコーディングツールに指示する際、ブランチ運用とPR作成まで含めて依頼すると、勝手に本番を書き換える事故を減らせます。以下はPMがそのまま渡せる指示テンプレートです（特定ツールに限定しません）。 markdown AIへの作業依頼テンプレート（コピペ用） あなたはチーム開発のルールに従うエンジニアです。以下を厳守してください。 作業ルール 1. main（本番）ブランチを直接変更しない 2. 作業前に「feature/〈タスク名〉」ブランチを作成する 3. 変更してよいファイル領域は〈対象フォルダ/ファイル〉のみ 4. 共通設定ファイル（〈ファイル名〉）は変更しない。必要なら先に相談 5. 作業後はPull Requestを作成し、以下を本文に記載： 変更の目的（1〜2文） 変更したファイル一覧 想定される影響範囲とリスク 6. テストがあれば実行し、結果を報告する タスク 〈やってほしいことを具体的に記述〉 GitHub Actions（変更時に自動で検査を走らせる仕組み）を使えば、PRごとにテストを強制できます。導入自体はエンジニアに任せ、PMは「この設定が有効か」を確認すれば十分です。 強調ボックス：AI特有の注意 AIは指示範囲を超えて広く書き換えることがあります。「変更してよい範囲」と「触ってはいけないファイル」を必ず明示してください。 実践チェックリスト [ ] 全員・全AIの作業がGit上で行われている [ ] タスクごとに「触るファイル領域」を割り当てている [ ] 1タスク＝1ブランチのルールが守られている [ ] mainへの直接変更を禁止している [ ] Pull Requestに最低1人のレビュー承認を必須にしている [ ] 統合前に自動テストが走り、成功が合流条件になっている [ ] AIへの依頼にブランチ・PR・変更範囲の指示を含めている まとめ（結論と最初に着手する行動） 衝突は「同じ場所を同時に変える」ことで起き、防止の鍵は作業を分けて、合流前に確認することです。ブランチで隔離し、Pull Requestで確認し、自動テストで壊れを止める——この3点をルール化すれば、人もAIも安全に並行作業できます。 最初の一歩：まず「mainへの直接変更禁止」と「PRレビュー承認必須」の2つを、チームに合意させてください。設定変更はエンジニアに依頼できます。 次に読む記事 基礎：「Gitとは何か——非エンジニアのための履歴管理入門」 実践：「Pull Requestレビューでバグを減らす観点チェックリスト」 発展：「GitHub Actionsで自動テストを導入し、壊れた合流をゼロにする」 よくある質問 Q. PMもGitやコードを覚える必要がありますか？ コードを書く必要はありません。ただし「ブランチ」「PR」「テスト」という言葉の意味と、それぞれが何を守る仕組みかは理解しておくと、進行管理とリスク判断が正確になります。 Q. 小さなチームでもブランチやPRは必要ですか？ 2人以上、あるいはAIを併用するなら必要です。人数が少ないほど「まあ大丈夫」と直接変更しがちですが、それが一番事故を招きます。ルールは小規模なうちに定着させる方が楽です。 Q. AIに任せれば衝突は自動で解決しますか？ 自動では解決しません。AIは高速に変更する分むしろ衝突を増やすことがあります。作業範囲の指定とPRによる人間の確認を組み合わせて、初めて安全になります。

2026/8/2

UIを先に作って確認してからDB接続へ｜手戻りを減らす開発の進め方 「動くものを見てから話したい」——非エンジニアのプロダクト担当者にとって、これは自然な感覚です。この記事では、画面を先に「見た目だけ」で作り、人が確認してからデータ接続に進む開発の流れを解説します。読み終えると、なぜ手戻りが減るのか、どう指示すればよいかが分かります。 この記事の結論 先に画面(見た目)を作り、人が確認してからデータを接続すると、作り直しが減る 見た目づくりに使う「仮のデータ」を Mock(モック) と呼び、これが早期確認のカギ Frontend(画面) と Backend(裏側) を分けて進めると、担当者ごとに並行作業できる プロダクト担当者は「見た目の確認」段階で仕様の齟齬を潰すのが最重要タスク AIツールを使えば、Mock画面の生成や仕様チェックを一部自動化できる この記事が役立つ人 エンジニアに開発を依頼する非エンジニアのプロダクト担当者・企画担当 「完成してから想像と違った」という手戻りに悩んだ経験がある人 開発の流れを理解して、適切なタイミングで確認・指示を出したい人 前提知識は不要です。専門用語はその都度やさしく説明します。 なぜこの問題が起きるのか(背景と原因) 多くの手戻りは「完成品を見て初めて認識のズレに気づく」ことで起きます。仕様書や口頭の説明だけでは、画面の使い勝手やボタンの位置まで正確には共有できません。 とくに画面(Frontend)と裏側(Backend)を同時に作ってしまうと、後から「やっぱりこの項目いらない」となったとき、両方を作り直す羽目になります。 用語メモ Frontend(フロントエンド)=利用者が実際に見て触る「画面」の部分。 Backend(バックエンド)=画面の裏で動く「データの保存・計算・処理」の部分。データベースやAPIがここに含まれる。 API=画面と裏側がデータをやり取りするための「窓口」。 図: 開発の流れ mermaid flowchart LR A[要件・仕様の整理] B[Mockで画面を作る<br/見た目だけ] B C{人間が確認<br/プロダクト担当} C |修正あり| B C |OK| D[Backend接続<br/DB・API] D E[結合テスト] E F[リリース] このように「画面OKが出てから裏側へ」進むことで、裏側の作り直しコストを避けられます。 解決するための5つのポイント 1. まず「Mock」で見た目だけの画面を作る 結論: 本物のデータをつながず、仮のデータで画面を先に作ります。これを Mock(モック)＝見せかけの仮データ・仮画面 と呼びます。 具体例: 商品一覧画面なら、実際のデータベースを用意せず「商品A ¥1,000／商品B ¥2,000」といった固定の仮データを埋め込んで表示します。 実践方法: エンジニアに「まずMockで画面を作って、確認させてほしい」と依頼します。この段階では動作の速さやデータの正確さは求めず、レイアウトと項目に集中します。 2. 人間の確認を「接続前」に必ず挟む 結論: 画面ができた時点で、実データをつなぐ前にプロダクト担当が確認します。ここが最大の手戻り防止ポイントです。 具体例: 「金額の横に税込表示が要る」「並び順は新着順にしたい」といった気づきは、画面を見て初めて出てきます。Mock段階なら修正が数時間で済みます。 実践方法: 確認では「項目の過不足」「操作の流れ」「表示ルール」の3点を見ます。後述のチェックリストを使ってください。 3. FrontendとBackendを分けて並行作業する 結論: 画面担当と裏側担当が同時に別々の作業を進められる体制にすると、開発が速くなります。 具体例: 画面担当がMockで見た目を詰めている間に、裏側担当はデータベースの設計を進める、という並行作業が可能です。 実践方法: 両者が「APIの仕様(どんなデータをどんな形で渡すか)」を先に合意しておくと、後の接続がスムーズです。プロダクト担当はこの合意の場に同席し、必要な項目が漏れていないか確認します。 4. 確認OK後にDB・APIを接続する 結論: 画面が承認されてから、裏側の本物のデータ処理(Backend)をつなぎます。 具体例: Mockの「商品A ¥1,000」の部分を、実際のデータベースから取得した本物の商品情報に差し替えます。画面の形は変えず、中身だけ本物にするイメージです。 実践方法: この段階での確認は「データが正しいか」「エラー時にどう表示されるか」に移ります。見た目の議論はすでに終わっているので、論点が絞られます。 5. 変更は「どの段階か」で影響を見極める 結論: 同じ変更依頼でも、Mock段階か接続後かで作業量が大きく変わります。早い段階の変更ほど安上がりです。 具体例: 「項目を1つ追加」も、Mock段階なら画面だけの修正。接続後だと画面・API・データベースの3箇所を直す必要があります。 実践方法: 変更を思いついたら、まず「今どの段階か」をエンジニアに確認します。緊急でなければ次のMock確認まで待つ判断も有効です。 | 変更のタイミング | 直す範囲 | おおよその手間(目安・推測) | |||| | Mock段階 | 画面のみ | 小 | | 接続後 | 画面＋API＋DB | 大 | | リリース後 | 上記＋データ移行・告知 | 特大 | ※手間は開発規模により変わります。上表は相対的な目安です。 AIやツールで自動化する方法 AIツールを使うと、Mock画面の生成や仕様の抜け漏れチェックを一部効率化できます。特定の製品に依存する必要はなく、手元の環境に合うものを選べば構いません。 Mock画面の生成: v0、Figma Make、Cursor、Claude Code などに「〈画面の説明〉のMockを仮データ付きで作って」と依頼すると、見た目の叩き台が短時間で出ます。 仕様チェック: 生成AIに仕様書を渡し、「不足している項目・矛盾を指摘して」と頼むと、確認前の下ごしらえになります。 接続後の確認自動化: GitHub Actions などで、表示崩れやエラーを自動テストする仕組みを組めます(エンジニア担当領域)。 そのまま使えるMock作成依頼プロンプト 生成AIツールにそのまま貼って使えるプロンプトです。〈〉部分を自分の案件に置き換えてください。 text 【役割】あなたはUI開発のアシスタントです。 【依頼】以下の画面を、実際のデータベースには接続せず、 仮データ(Mock)を埋め込んだ見た目だけの画面として作成してください。 画面名: 〈例: 商品一覧画面〉 表示したい項目: 〈例: 商品名・価格・在庫状況・カテゴリ〉 仮データ: 各項目のサンプルを3〜5件、それらしい値で用意 表示ルール: 〈例: 価格は税込・カンマ区切り、在庫0は「品切れ」表示〉 操作: 〈例: カテゴリで絞り込み、価格で並び替え〉 【出力の条件】 1. データ接続はまだ不要。仮データは画面内に直接埋め込む 2. レイアウトと項目の分かりやすさを最優先 3. 後でデータ接続しやすいよう、仮データ部分をまとめて記述 4. 確認者(非エンジニア)向けに、画面のポイントを箇条書きで補足 実践チェックリスト Mock画面を確認する際のチェック項目です。 [ ] 必要な項目がすべて表示されているか(過不足の確認) [ ] 表示ルール(税込・日付形式・並び順)は意図どおりか [ ] 操作の流れ(ボタン→次画面)が自然か [ ] エラーや空データ(該当0件)のときの表示を決めたか [ ] この画面で「本物のデータ」として何が必要かを裏側担当と共有したか [ ] 変更依頼は接続前に出し切ったか まとめ 「見た目を先に作り、人が確認してからデータをつなぐ」——この順番を守るだけで手戻りは大きく減ります。カギは、仮データ(Mock)の段階でプロダクト担当が仕様のズレを潰すことです。 最初の一歩: 次の開発依頼で「まずMockで画面を見せてほしい」と伝え、上のチェックリストで確認してみてください。 次に読む記事 基礎: 「FrontendとBackendの違いを図解｜開発依頼で困らない基本用語」 実践: 「API仕様の合意で失敗しない｜非エンジニアが確認すべき5項目」 発展: 「GitHub Actionsで画面の表示崩れを自動検知する仕組み」 よくある質問 Q. Mock段階のデータは本番でも使われますか? いいえ。Mockはあくまで確認用の仮データで、接続時に本物のデータへ差し替えられます。仮データの内容がそのまま公開されることはありません。 Q. 画面確認のとき、非エンジニアは何を見ればいいですか? 「項目の過不足」「表示ルール」「操作の流れ」の3点です。動作の速さや技術的な正確さは接続後の確認対象なので、この段階では気にしなくて構いません。 Q. FrontendとBackendを同時に作ってもらった方が速くないですか? 一見速く見えますが、仕様のズレが出たとき両方を直すことになり、結果的に遅くなりがちです。画面の承認を挟むことで、裏側の作り直しリスクを抑えられます。

2026/8/2

「言った/言わない」を防ぐ発注術：AIで画面案とデータ例を先に見せる認識合わせの実践法 システム発注で「イメージと違う」が起きるのは、言葉だけで要望を伝えるから。本記事は、AIで画面案・操作例・データ例を先に作り、開発前に認識をそろえる手順と、合意を証拠として残す方法を、非エンジニアの発注者・PM向けに解説します。 この記事の結論 言葉だけの要望伝達は解釈のズレを生み、手戻り・追加費用の主因になる AIを使えば発注者側でも「画面案・操作の流れ・データ例」を短時間で用意できる 具体物を見せた認識合わせは、抽象的な議論より数倍速く合意に至る（筆者の実感。効果は状況による） 合意内容は「画面案＋確定日＋変更理由」をセットで残すと後の紛争を防げる まずは1画面だけ画面案を作り、レビューで反応を確かめるのが最短の第一歩 この記事が役立つ人 システム開発を外部ベンダーや社内エンジニアに依頼する立場の方が対象です。以下に当てはまるなら効果があります。 要件定義や仕様のすり合わせで「認識のズレ」に悩んでいる 自分では画面設計やコードは書けないが、要望は明確にしたい 過去に「言った/言わない」で揉めた経験がある 前提知識は不要です。ChatGPTやClaudeなどの生成AI（文章や画像を作るAI）を、無料〜低額プランで触れる環境があれば始められます。 なぜ「言葉だけの発注」でズレが起きるのか 言葉は抽象的で、受け手の経験によって解釈が変わります。「使いやすい一覧画面」と伝えても、発注者は「検索付き」を想像し、開発者は「並び替え付き」を作る、といったズレが生まれます。 言葉の危険性は「省略」にあります。 発注者は自分の頭の中では完成イメージがあるため、当たり前だと思う条件を言い忘れます。開発者はその空白を自分の常識で埋めるため、両者の常識が違うほどズレが拡大します。 💡 筆者の経験（事例）：ある業務システムで「承認機能をつけて」とだけ伝えた結果、1段階承認で作られました。実際は3段階必要で、後から作り直しに2週間かかりました。「承認者は誰が何人か」を最初に図で示していれば防げた事例です。 図: 言葉だけの伝達では「発注者のイメージ」と「開発者の解釈」の間に隙間が生まれ、その隙間が手戻りとして顕在化する構図。具体物（画面案）を挟むと隙間が縮小する。 解決するための5つのポイント 1. 画面案を「絵」で見せて解釈の幅を消す 結論：文章より1枚の画面案のほうが、認識のズレを桁違いに減らせます。人は具体的な絵があると「ここは違う」と指摘しやすくなるためです。 具体例：「顧客一覧画面」なら、検索欄・列項目・ボタン配置を含んだ簡単なワイヤーフレーム（線画レベルの画面案）を用意します。AIに指示すればHTMLやSVGで叩き台を出せます。 実践方法：後述のプロンプトで、まず1画面だけ作り、ベンダーに「これで合っていますか」と確認します。 2. 操作の流れを「ステップ」で見せて抜け漏れを防ぐ 結論：画面単体でなく「操作の順番」を示すと、画面間の遷移漏れを発見できます。 具体例：「注文→在庫確認→承認→出荷指示」のように、誰が何をするかを矢印でつなぎます。Mermaid（テキストで図を描く記法）を使えば発注者でも書けます。 実践方法：フロー図をレビューで共有し、「この分岐（例：在庫がない場合）はどうなる？」を全員で埋めます。 3. データ例（サンプル）を見せて項目の過不足を洗い出す 結論：実際のデータ例を見せると、「この項目が足りない」が具体的に見えます。 具体例：顧客データなら「氏名・電話・登録日」だけでなく、実際の値（山田太郎／090xxxx／20240115）を数行分用意します。空欄や異常値の扱いも議論できます。 実践方法：AIにサンプルデータをCSVで生成させ、「この形式で保存されます」とベンダーと合意します。 4. 「やらないこと」を明記して範囲を固める 結論：作る機能だけでなく「今回は作らない機能」を書くと、範囲の膨張（スコープクリープ）を防げます。 具体例：「今回は検索機能まで。CSVエクスポートは次フェーズ」と明記します。曖昧なままだと「当然入ると思った」で揉めます。 実践方法：合意ドキュメントに「対象外」欄を必ず設けます。 5. 合意した内容に「日付」と「変更理由」を残す 結論：合意は口頭でなく、画面案・確定日・変更理由をセットで文書化します。これが「言った/言わない」への最大の防御です。 具体例：「顧客一覧の初期表示件数：20件（20240601確定）／50件から変更、表示速度優先のため」という粒度で残します。 実践方法：後述のテンプレートを議事録の末尾に貼り付けて運用します。 そのまま使えるAIプロンプト（画面案・操作例・データ例の生成） 以下をコピーし、〈〉部分を自分の案件に置き換えてAI（ChatGPT/Claude等）に貼り付けてください。 text 用途: システム発注前の認識合わせ資料をAIに作らせる指示 あなたはUI設計とデータ設計の補助をするアシスタントです。 非エンジニアの発注者にも分かる形で、以下3点を作ってください。 【対象システム】〈例：顧客管理システムの顧客一覧画面〉 【利用者】〈例：営業担当者、1日30回程度利用〉 【実現したいこと】〈例：顧客を素早く検索し、詳細を確認したい〉 出力1（画面案）: 単一のHTMLファイルで、指定画面のワイヤーフレームを作成 検索欄・一覧の列項目・主要ボタンを含める 装飾より構造を優先し、コメントで各要素の意図を書く 出力2（操作フロー）: Mermaid記法で、利用者の操作手順を図示 「例外時（該当なし等）」の分岐も含める 出力3（データ例）: 一覧に表示するサンプルデータを5行、CSV形式で 列名と、現実的なダミー値を含める 空欄・異常値の扱い方針もコメントで補足 不明な前提は勝手に決めず、確認質問を最後に3つ挙げてください。 最後の「確認質問」を出させるのがコツです。AIが仮定した点＝あなたが伝え忘れていた点なので、そのままベンダーへの確認事項になります。 そのまま使える操作フロー図（Mermaid） レビュー用のたたき台です。矢印と条件を書き換えて使ってください。 mermaid flowchart TD A[営業が顧客一覧を開く] B[検索条件を入力] B C{該当あり?} C |あり| D[一覧に表示] C |なし| E[「該当なし」を表示] D F[顧客をクリック] F G[詳細画面へ遷移] E B そのまま使える合意記録テンプレート 議事録の末尾に貼り、確定した項目だけ埋めます。 markdown 認識合わせ 合意記録 | 項目 | 合意内容 | 確定日 | 変更理由/備考 | ||||| | 〈顧客一覧の初期件数〉 | 〈20件〉 | 〈20240601〉 | 〈50→20、速度優先〉 | | 〈検索対象項目〉 | 〈氏名・電話〉 | 〈20240601〉 | 〈住所検索は次フェーズ〉 | 今回の対象外（作らないこと） 〈CSVエクスポート機能〉 〈スマホ専用画面〉 添付 画面案: 〈ファイル名/URL〉 操作フロー図: 〈ファイル名/URL〉 データ例: 〈ファイル名/URL〉 AIやツールで自動化する方法 毎回手作業でなく、仕組みにすると発注のたびに再利用できます。特定製品に依存しない方法を挙げます。 | やりたいこと | 使えるツール例 | 効果 | |||| | 画面案を対話で作る | ChatGPT / Claude | 文章の要望をHTML画面案に変換 | | 画面案をブラウザで確認 | Claude（Artifacts）等 | コード不要でその場で表示 | | フロー図を管理 | Mermaid対応のメモツール | テキストで図を版管理 | | 合意記録の蓄積 | Notion / スプレッドシート | 案件横断で検索・再利用 | ⚠️ 注意：AIが生成した画面案やデータ例は「たたき台」です。そのまま本番仕様にせず、必ず人の目でレビューしてください。AIは前提を勝手に補完するため、事実確認が前提です。 エンジニアがいる場合は、確定した画面案HTMLをGitで管理し、変更履歴を残すとさらに強固になります（この運用の要否はチーム規模による）。 実践チェックリスト [ ] 主要画面の「画面案（絵）」を最低1枚用意した [ ] 利用者の「操作フロー」を分岐込みで図示した [ ] 実際の値を含む「データ例」を数行作った [ ] 「今回作らないこと（対象外）」を明記した [ ] AIの「確認質問」をベンダーへの確認事項に反映した [ ] 合意内容を「日付＋変更理由」付きで文書化した [ ] 画面案・フロー・データ例を合意記録に添付した まとめ 言葉だけの発注はズレを前提とした伝達です。AIで画面案・操作例・データ例という「具体物」を先に作り、それを見ながら認識を合わせることで手戻りを大きく減らせます。合意は日付と理由をセットで残すことが最大の防御になります。 最初の一歩：一番重要な1画面だけ、本記事のプロンプトで画面案を作り、次回のレビューに持ち込んでください。反応の速さで効果を実感できるはずです。 次に読む記事 基礎：非エンジニアのための要件定義入門 ― 「要望」と「仕様」の違いを理解する 実践：ワイヤーフレームの書き方 ― AIに画面案を正しく作らせる指示のコツ 発展：ベンダーとの契約・スコープ管理 ― 変更要求を追加費用トラブルにしないための取り決め方 よくある質問 Q. 絵心もコードの知識もありませんが、画面案を作れますか？ A. 作れます。本記事のプロンプトをAIに貼れば、AIがHTMLの画面案を生成します。あなたの役割は「これで合っているか」を判断することで、ゼロから描く必要はありません。 Q. AIが作った画面案をそのままベンダーに渡してよいですか？ A. たたき台としてなら有効ですが、確定仕様として渡すのは避けてください。AIは不明点を勝手に補完するため、必ず「AIが出した確認質問」を潰し、人の合意を経てから共有します。 Q. 合意記録はどこまで細かく残すべきですか？ A. 「後で解釈が割れそうな数値・条件」を優先します。全項目を網羅する必要はなく、件数・対象範囲・例外時の挙動など、揉めやすい点に絞ると運用が続きます。

2026/8/2

企画書で悩む前に「動く試作品」で反応を得る：非エンジニアが失敗を減らす検証法 企画会議が「たぶん売れる/売れない」の水掛け論で止まっていませんか。本記事は、AIで画面や簡易機能を素早く作り、顧客や社内から本音の反応を引き出す進め方を解説します。何を確認し、どこで作り込みを止めるかの判断基準も示します。 この記事の結論 企画書の議論は「言葉の解釈違い」で空転しやすい。動く試作品（プロトタイプ）が判断を速める。 AIツールを使えば非エンジニアでも数時間〜数日で画面や簡易機能を作れる。 試作品で確認すべきは「顧客が本当に欲しがるか」「使いこなせるか」の2点に絞る。 作り込みすぎは最大のムダ。検証したい問いに答えられたら止めるのが原則。 反応データ（クリック・離脱・生の声）を記録し、次の意思決定に使う。 この記事が役立つ人 新規事業の企画が会議で止まりがちな経営者・事業責任者 「作る前に売れるか確かめたい」新規事業・DX担当者 エンジニアに依頼する前段階で仮説を検証したい人 前提知識は不要です。プログラミング経験がなくても、AIツールに指示を出せれば実践できます。 なぜこの問題が起きるのか（背景と原因） 企画書は文章と図で作られますが、読み手ごとに「良い画面」「便利な機能」の解釈が異なります。この解釈のズレが、会議での空転を生みます。 さらに人は、実物を見ないと的確な意見を言えません。「便利そう」という抽象的な感想は当てになりにくく、触れる試作品があって初めて「ここが使いにくい」という具体的な反応が出ます。 💡 筆者の見解：企画書の完成度を上げる時間より、粗くても動くものを見せる時間のほうが、意思決定の質を高めます。議論の材料が「想像」から「体験」に変わるためです。 従来は試作品を作るのにエンジニアと数週間が必要でした。しかしAIの登場で、非エンジニアが短時間で画面や簡易機能を作れるようになり、この壁が下がっています。 解決するための5つのポイント 1. 検証したい「問い」を1つに絞ってから作り始める 結論：試作品は「何を確かめたいか」が決まって初めて意味を持ちます。 例えば「中小企業の経理担当は、領収書をスマホ撮影するUIを使いこなせるか？」のように、一文で言い切れる問いを立てます。問いが曖昧だと、作ったものから何も学べません。 実践方法：作業前に「この試作品で〈確かめたいこと〉が分かる」と紙に書く。答えられないなら作らない。 2. 見た目だけの「画面モック」から始める 結論：多くの仮説は、機能が動かなくても画面だけで検証できます。 例：申込フォームの画面だけを見せ、「これなら使いますか」と聞く。実際にデータが保存されなくても、顧客の反応は取れます。画面モック（見た目だけの試作画面）は最速で作れます。 実践方法：AIに「〈サービス名〉の申込画面をHTMLで作って」と指示し、そのまま人に見せる。 3. 本当に必要な機能だけ「1つ」動かす 結論：全機能ではなく、価値の中心となる1機能だけを動かします。 例：AI議事録サービスなら「音声から要約が出る」部分だけ動けば十分。ログイン機能や課金画面は後回しにします。 ⚠️ 注意：「一応これも」と機能を足すほど、検証の焦点がぼやけ、時間も溶けます。 4. 反応を「数字」と「生の声」の両方で記録する 結論：印象ではなく記録に基づいて判断します。 | 記録する項目 | 取り方の例 | 分かること | |||| | クリック率 | ボタンが押された割合 | 関心の強さ | | 離脱ポイント | どこで操作をやめたか | つまずく箇所 | | 生の声 | 使用中の発言をメモ | 感情・違和感 | | 支払い意思 | 「いくらなら払う？」 | 事業性 | 実践方法：見せる相手ごとに上記をメモ。5〜10人で傾向が見えます。 5. 「作り込みすぎ」を止める判断基準を持つ 結論：検証の問いに答えが出たら、それ以上は作らないと決めます。 図: 作り込み判断フロー mermaid flowchart TD A[試作品を見せた] B{問いに<br/答えは出たか} B 出た C[作り込み停止<br/次の意思決定へ] B 出ない D{原因は試作品の<br/粗さか} D 粗さが原因 E[必要最小限だけ改善] D 仮説が曖昧 F[問いを立て直す] E A F A 💡 判断の目安：「この機能を足すと、どの問いに答えられるか」を即答できないなら、その作り込みは不要です。 AIやツールで自動化する方法 非エンジニアでも使える代表的な方法を挙げます。特定ツールが唯一の正解ではなく、手元にあるもので構いません。 Claude / ChatGPT：画面のHTMLや文章を生成。コピペでブラウザ表示可能。 Cursor / Claude Code：指示文だけで動くWebページや簡易機能を生成（エンジニア向けだが非エンジニアも入門可能）。 ノーコードツール：ドラッグ操作でフォームや画面を構築。 以下は、AIに試作品用の画面を作らせるプロンプトです。〈〉を自分の事業に置き換えてください。 text 用途: 新規事業の画面モックをAIに生成させるプロンプト あなたはUIデザイナー兼フロントエンド開発者です。 以下の条件で、単一のHTMLファイル（CSS内蔵、外部依存なし）を作成してください。 サービス概要 サービス名: 〈AI議事録メーカー〉 対象ユーザー: 〈中小企業の管理職〉 中心となる価値: 〈会議音声から要約と決定事項を自動抽出〉 作ってほしい画面 1. トップ画面（サービスの価値が一目で伝わるキャッチと申込ボタン） 2. 〈要約結果を表示する〉画面（サンプルデータを入れて動きが分かる状態に） 条件 スマホ表示に対応 ダミーデータで実際の使用イメージが伝わるようにする ボタンを押したら次の画面に切り替わる程度の簡単な動きを付ける 専門用語のラベルには短い補足を付ける 出力はHTMLコードのみ。ファイルとして保存すればブラウザで開ける状態にすること。 生成されたコードを 〈ファイル名〉.html として保存し、ダブルクリックで開けば試作品として人に見せられます。 📌 事例（筆者観測の一般例）：ある新規事業チームは、申込画面モックを5人の見込み顧客に見せ、「価格表示がないと不安」という共通の声を得ました。企画書段階では出なかった指摘で、方向修正に役立ったといいます。 実践チェックリスト [ ] この試作品で確かめたい「問い」を一文で書いた [ ] まず画面モックだけで検証できないか検討した [ ] 動かす機能を「価値の中心となる1つ」に絞った [ ] 見せる相手を5〜10人リストアップした [ ] クリック率・離脱・生の声・支払い意思を記録する準備をした [ ] 「答えが出たら止める」基準をチームで共有した [ ] AIプロンプトの〈〉を自社事業に置き換えた まとめ 企画書での議論が空転する原因は「解釈のズレ」です。AIで粗くても動く試作品を作れば、想像ではなく体験に基づく反応が得られます。 最初に着手する行動：確かめたい問いを一文で書き、上記プロンプトで画面モックを1枚作る。それを社内の1人に見せるところから始めてください。作り込みは、答えが出たら止めるのが鉄則です。 次に読む記事 基礎：ノーコードツールの選び方入門 — プログラミング不要で試作品を作る第一歩 実践：見込み顧客インタビューの質問設計 — 試作品から本音を引き出す聞き方 発展：MVP（実用最小限の製品）から本開発への移行判断 — いつエンジニアに依頼すべきか よくある質問 Q. AIが作った試作品を、本番のサービスにそのまま使えますか？ A. 基本的には使えません。試作品は「反応を得る」ことが目的で、セキュリティや安定性は考慮されていません。本番は改めて設計・開発する前提で割り切りましょう。 Q. プログラミングが全く分からなくても作れますか？ A. 画面モック程度なら、AIに指示してHTMLを生成し保存するだけで作れます。動く機能まで求める場合は、ノーコードツールやエンジニアの協力を組み合わせるとスムーズです。 Q. 何人に見せれば判断してよいですか？ A. 明確な正解はありませんが、5〜10人で共通した反応が見えることが多いです。全員が同じ箇所でつまずくなら、その問題は本物だと考えてよいでしょう。

2026/8/2

「なんとなく不便」を�can様化する:業務要望を5要素に分解する手順 「入力ミスが多い」「毎月バタバタする」——こうした曖昧な不満を、そのまま改善依頼にすると迷走します。本記事は現場の困りごとをフロー・例外・入力・出力・権限の5要素に分解し、AIで整理まで進める手順を示します。 この記事の結論 曖昧な要望は「不便な気持ち」であり、そのままでは改善もツール化もできない 業務フロー/例外条件/必要な入力/求める出力/権限の5要素に分解すると要件が固まる 分解は「誰が→何を受け取り→どう処理し→何を出し→誰が承認するか」を順に問うだけ AIに壁打ちさせると、抜けがちな「例外条件」を短時間で洗い出せる 分解結果は1枚の表にまとめ、関係者と合意してから改善に着手する この記事が役立つ人 現場の改善を任されたが、何から手をつけるか迷っている責任者・バックオフィス担当者向けです。プログラミング知識は不要で、「業務の困りごとを言語化して人やAIに正しく依頼したい」方を想定しています。 💡 前提:改善対象は「毎月/毎週など繰り返す業務」が最適です。年1回の作業は分解コストが見合わないことがあります。 なぜ「なんとなく不便」のまま止まるのか 不便の正体が言語化されていないためです。人は結果(遅い・ミスが多い)は感じても、その原因である処理の流れや例外を意識していません。依頼が「もっと楽にして」で止まると、受け手は何を作ればいいか判断できません。 もう一つの原因は例外条件の見落としです。普段の8割の流れは説明できても、「取引先が急ぎのとき」「金額が10万円超のとき」といった残り2割の分岐が抜け、後から作り直しになります。 図: 曖昧な要望が改善に至らない流れ 「不便」（感情） ↓ 言語化されない 「楽にして」（丸投げ） ↓ 要件が不明 受け手が判断できない → 手戻り・放置 解決するための5つのポイント 1. まず業務フローを「登場人物と順番」で書き出す 結論:改善の起点は、誰が何を順番にやるかの可視化です。頭の中の流れを外に出すだけで9割の課題が見えます。 具体例:請求書処理なら「①現場が請求書受領→②担当が内容確認→③上長が承認→④経理が支払登録」。この4ステップを箇条書きにするところから始めます。 実践方法:1業務につき5〜8ステップに収めます。細かすぎると分解が止まるため、まずは粗く書き、後で必要な箇所だけ詳細化します。 2. 例外条件を「もし〜なら」で強制的に洗い出す 結論:手戻りの最大原因は例外です。正常フローを書いた直後に、各ステップへ「もし〜だったら?」を必ず問います。 具体例:「もし金額が10万円超なら部長承認も必要」「もし請求書に不備があれば差し戻す」。この分岐が仕様の骨格になります。 実践方法:各ステップに最低1つ「例外はないか?」と問う習慣をつけます。後述のAIプロンプトが、この抜け漏れ防止に有効です。 3. 必要な入力を「様式・提供者・期限」で定義する 結論:業務は入力から始まります。何を・誰から・いつまでに受け取るかが曖昧だと、下流すべてが崩れます。 具体例:入力=「請求書PDF」、提供者=「各現場担当」、期限=「毎月5日まで」。この3点セットで受け取り条件が明確になります。 4. 求める出力を「形式・提出先・使い道」で定義する 結論:出力の姿が決まると、逆算で処理内容が決まります。ゴールから設計するのが鉄則です。 具体例:出力=「支払一覧CSV」、提出先=「会計システム」、使い道=「月次支払処理」。使い道まで書くと、必要な項目(取引先・金額・支払日)が自ずと定まります。 5. 権限を「実行者・承認者・閲覧者」で分ける 結論:誰が実行し、誰が承認し、誰が見られるかを分けないと、統制が効かず自動化もできません。 具体例:実行=経理担当、承認=部門長、閲覧=監査担当。金額により承認者が変わる場合は、ポイント2の例外条件と連動させます。 | 5要素 | 問いかけ | 記入例 | |||| | 業務フロー | 誰が順番に何をする? | 受領→確認→承認→登録 | | 例外条件 | もし〜だったら? | 10万円超は部長承認 | | 必要な入力 | 何を・誰から・いつ? | 請求書PDF/現場/5日まで | | 求める出力 | 形式・提出先・使い道? | CSV/会計システム/月次支払 | | 権限 | 実行・承認・閲覧は誰? | 経理/部門長/監査 | AIやツールで曖昧な要望を整理する方法 分解作業はAIとの壁打ちで加速します。特に例外条件の洗い出しは、AIに「他に考えられる分岐は?」と聞くと抜けが減ります。特定ツールは不要で、汎用の対話型AI(ChatGPT / Claude 等)で実行できます。 やり方は「困りごとを話す→AIが5要素で質問を返す→答える→表にまとめてもらう」の順です。以下のプロンプトをそのまま貼り付けて使えます。 そのまま使える業務要望ヒアリング用プロンプト text 用途: 曖昧な業務要望を5要素に分解する / 対話型AIに貼り付け あなたは業務分析の専門家です。私が話す「業務の困りごと」を、 以下の5要素に分解するための質問を、1つずつ順番にしてください。 【5要素】 1. 業務フロー（誰が/どの順番で/何をするか） 2. 例外条件（もし〜だったら、の分岐。特に金額・期限・不備） 3. 必要な入力（何を/誰から/いつまでに） 4. 求める出力（形式/提出先/使い道） 5. 権限（実行者/承認者/閲覧者） 【進め方】 一度に1〜2問だけ質問し、私の回答を待ってください 私が「例外はない」と言っても、想定される例外を3つ提案して確認してください 専門用語は使わず、平易な言葉で聞いてください すべて聞き終えたら、5要素を1枚の表にまとめてください 【私の困りごと】 〈ここに「〇〇が毎月大変」など今の不満をそのまま書く〉 ⚠️ 注意:AIの出力は叩き台です。特に権限と金額基準は社内規程と必ず突き合わせてください。AIが提案した数値をそのまま採用しないよう注意します。 分解が終わったら、合意形成のために流れを図にすると効果的です。以下のMermaid記法はコピペで図になります(対応ツールに貼り付け)。 そのまま使える業務フロー図(Mermaid) mermaid flowchart TD A[現場が請求書を受領] B[担当が内容確認] B C{金額は10万円超?} C |はい| D[部長が承認] C |いいえ| E[課長が承認] D F[経理が支払登録] E F B |不備あり| G[現場へ差し戻し] G A 体験談:ある管理部門で「月末の請求処理が毎回残業」という要望をこの手順で分解したところ、実は不便の8割が「不備差し戻しの往復」に集中していると判明しました。当初想定していた「システム導入」ではなく、入力様式の統一だけで大幅に改善できた、というのが分解の効果です(※一事例であり、効果は業務により異なります)。 実践チェックリスト [ ] 対象業務を5〜8ステップのフローで書き出した [ ] 各ステップに「もし〜なら」の例外を最低1つ確認した [ ] 入力を「何を/誰から/いつまでに」で定義した [ ] 出力を「形式/提出先/使い道」で定義した [ ] 権限を「実行/承認/閲覧」に分けた [ ] 金額・期限の基準を社内規程と突き合わせた [ ] 5要素の表を関係者に共有し合意を得た まとめ 曖昧な不便は「感情」であり、そのままでは改善できません。フロー・例外・入力・出力・権限の5要素に分解することで、初めて人にもAIにも正しく依頼できる状態になります。 まず着手すべきは、困っている業務を1つ選び、フローを5〜8ステップで書き出すことです。その後、本記事のプロンプトでAIに例外を洗い出させれば、半日で要件の骨格が固まります。 次に読む記事 基礎:「業務フロー図の書き方入門|記号と粒度の決め方」 実践:「例外条件の洗い出しチェックリスト|手戻りを防ぐ20の観点」 発展:「整理した業務要件をノーコードツールで自動化する手順」 よくある質問 Q. どの業務から分解を始めればいいですか? A. 「毎月/毎週繰り返す」かつ「関係者が不便を感じている」業務が最適です。頻度が高いほど改善効果が積み上がり、分解コストも回収しやすくなります。 Q. AIに任せれば人の確認は不要ですか? A. いいえ。AIは例外の洗い出しや文章化を得意としますが、金額基準や権限は社内規程に依存します。最終的な妥当性は必ず担当者と責任者が確認してください。 Q. 5要素すべてを埋められない業務はどうしますか? A. 空欄のまま関係者と共有して構いません。埋まらない箇所こそ認識が曖昧な部分であり、そこを議論の起点にすることで要件が明確になります。

2026/8/2

人もAIも増えると混乱するのはなぜ？PM向け・破綻しないチーム運営5つの防止策 参加者やAIツールが増えるほど、なぜか「言った・言わない」「勝手に変えた」「誰の責任？」が頻発します。本記事は非エンジニアのPMが、その原因を理解し、5つの防止策（共有コンテキスト・役割分担・変更履歴・レビュー・テスト）を今日から実装する方法を、コピペ資産付きで解説します。 この記事の結論 混乱の正体は「人数×AIの増加」による前提のズレ・変更の衝突・責任の曖昧化の3つ。 防ぐ核は「情報を1か所に集約し、誰が何をしたか追える状態」にすること。 共有コンテキスト／役割分担／変更履歴／レビュー／テストの5点セットで9割の事故は防げる（筆者の実務上の実感、断定ではない）。 AIを増やす前に「AIも1人のメンバー」として役割と履歴のルールに組み込むのが要点。 まず着手すべきは「共有コンテキストの1ページ化」。最も低コストで効果が出やすい。 この記事が役立つ人 チームや外部委託先、AIツールが増えて調整コストが膨らんでいるPM。 エンジニアではないが、開発・制作の進行管理を任されている人。 ChatGPTやClaudeなどの生成AIを業務に組み込み始めた組織のリーダー。 前提知識は不要です。「Git（変更履歴を管理する仕組み）」などの用語には都度説明を添えます。 なぜこの問題が起きるのか（背景と原因） 参加者が増えると、コミュニケーション経路の数は爆発的に増えます。3人なら3経路ですが、6人なら15経路。ここにAIが加わると、指示の解釈が人ごと・AIごとにブレていきます。 原因は主に3つです。整理すると次の表になります。 | 問題 | 起きる理由 | 典型的な症状 | |||| | 前提のズレ | 情報が各自の頭・チャットに散在 | 「その仕様聞いてない」の多発 | | 変更の衝突 | 同じ資料を別々に編集 | 上書きで作業が消える | | 責任の曖昧化 | 誰の判断か記録がない | 「AIがやった」で終わる | 重要：AIは「悪意なく自信満々に間違える」性質があります。人以上に前提共有と履歴管理が必要です。 図: 中央に「共有コンテキスト（1つの真実）」の箱を置き、そこから人A・人B・AI・外注へ矢印が伸びる放射状の図。逆に各自が勝手に情報源を持つと矢印が絡まる様子を対比で示す。 解決するための5つのポイント 1. 共有コンテキストを「1ページの真実」に集約する 結論：情報源を1か所に固定すれば前提のズレは激減します。散在が諸悪の根源です。 具体例：Aさんはメール、BさんはSlack、AIはその場の指示だけを見ている状態では、3者の前提が一致しません。 実践方法：NotionやGoogleドキュメント1枚に「目的・用語定義・決定事項・禁止事項」をまとめ、全員とAIがそれを参照するルールにします。AIには毎回このページを貼り付けて指示します。 2. 役割分担を「担当」でなく「決定権」で定義する 結論：作業分担でなく「誰が最終決定するか」を決めると、責任の曖昧化が消えます。 具体例：「デザイン担当」が3人いても、承認できる人が不明だと差し戻しが続きます。 実践方法：RACI（実行・承認・相談・報告の役割分担表）を簡易化し、各タスクに「決める人」を1人だけ置きます。AIは常に「実行」側で、決定はしないと明記します。 3. 変更履歴を残し「誰が・いつ・なぜ」を追えるようにする 結論：変更に理由と作成者が紐づくと、後戻りと責任追及が容易になります。 具体例：資料が勝手に書き換わり、理由も不明では原因調査に半日かかります。 実践方法：Git（変更を記録・巻き戻せる仕組み）が理想ですが、非エンジニアはGoogleドキュメントの「版管理」でも十分。変更時は必ず一言「なぜ変えたか」を残す運用にします。 4. レビューを「必須の関門」として仕組みに埋め込む 結論：レビューを人の善意でなくルールにすると、事故が本番前に止まります。 具体例：AIが生成した文章をノーチェックで公開し、誤情報が拡散するケースは実際に起きています。 実践方法：「AI・外注の成果物は必ず人が1人チェックしてから確定」を固定ルール化。チェック観点をリスト化しておくと属人化を防げます。 5. テストで「動く・正しい」を毎回確認する 結論：完成の定義を「テストに通ること」にすると、品質が個人の感覚に依存しなくなります。 具体例：「できました」の基準が人ごとに違うと、後工程で手戻りが発生します。 実践方法：開発なら自動テスト、非開発ならチェックリストを「テスト」代わりに使います。合格基準を先に決め、それを満たすまで「完了」と呼ばないことが肝心です。 体験メモ：筆者が関わったある案件では、AI出力を無レビューで運用し誤記が続出。上記1と4を導入しただけで手戻りが体感で半減しました（個別事例であり数値は保証しません）。 AIやツールで自動化する方法 5つのポイントは、ツールで「守らないと進めない」状態にできます。 共有コンテキスト：AIに毎回貼るのが面倒なら、Cursor / Claude Codeの設定ファイルにプロジェクト前提を書き、自動で読み込ませる。 レビュー・テスト：GitHub Actions（変更時に自動でチェックを走らせる仕組み）で、条件を満たさないと確定できないようにする。 役割分担：AIへの指示テンプレに「あなたの役割は実行のみ。決定はしない」と明記する。 そのまま使えるAIオンボーディング用プロンプト 新しくAIをチームに加えるとき、最初に貼るテンプレートです。 text 用途: チーム参加AIへの前提共有プロンプト あなたはこのプロジェクトの実行担当メンバーです。以下を厳守してください。 プロジェクトの目的 〈例：社内ヘルプページのリニューアル〉 共有コンテキスト（唯一の情報源） 参照する資料: 〈NotionのURL〉 用語定義: 〈例：本文=ユーザー向け説明文〉 禁止事項: 〈例：確定していない仕様を勝手に補完しない〉 あなたの役割 実行のみを担当し、最終決定はしない 判断が必要な点は「要確認」として一覧化して報告する 出力ルール 1. 変更した箇所は「変更点」「理由」をセットで明記する 2. 不確実な情報は「推測」と明示する 3. 完了条件: 〈チェックリスト項目〉をすべて満たすこと そのまま使える運用フロー図（Mermaid） 成果物が確定するまでの関門を可視化した図です。 mermaid flowchart TD A[タスク発生] B[共有コンテキストを参照] B C{担当は人かAIか} C |AI| D[AIが実行・変更点と理由を記録] C |人| E[人が実行・変更履歴を残す] D F[レビュー: 決定権を持つ人が確認] E F F G{テスト/チェックリスト合格?} G |No| B G |Yes| H[完了として確定] 実践チェックリスト [ ] 情報源となる「1ページの真実」を作り、URLを全員に共有した [ ] 各タスクに「決める人」を1人だけ設定した [ ] 変更時に「なぜ変えたか」を残すルールを合意した [ ] AI・外注の成果物は必ず人がレビューする関門を設けた [ ] 「完了」の基準をチェックリストまたはテストで定義した [ ] AIに役割（実行のみ）と参照先を伝えるテンプレを用意した まとめ 人とAIが増えると混乱するのは、情報の散在と履歴の欠如が原因です。共有コンテキスト・役割分担・変更履歴・レビュー・テストの5点で、その多くは防げます。 最初に着手すべきは「共有コンテキストの1ページ化」。最も低コストで、他の4施策の土台にもなります。今日、白紙のドキュメントに目的と用語定義を書くところから始めてください。 次に読む記事 基礎：非エンジニアのための「Gitと版管理」超入門 〜変更履歴が命を救う理由〜 実践：RACIを5分で作る 〜責任の曖昧さを消すタスク設計術〜 発展：GitHub Actionsでレビュー・テストを自動化する 〜守らないと進めない仕組み化〜 よくある質問 Q. AIが増えると、人が増えるときと対策は違いますか？ A. 基本は同じですが、AIは前提を勝手に補完し自信満々に誤る点が異なります。そのため共有コンテキストの明示とレビューを、人以上に厳格にする必要があります。 Q. 小規模チームでもここまで必要ですか？ A. 全部を一度に導入する必要はありません。まず「共有コンテキストの1ページ化」と「決める人を1人置く」だけでも効果が出ます。規模が拡大したらレビューとテストを足してください。 Q. Gitが使えないメンバーがいる場合は？ A. Googleドキュメントの版管理でも「誰が・いつ・なぜ変えたか」は十分追えます。重要なのはツールでなく「変更に理由を残す習慣」です。

2026/8/2

「AIに丸投げ」でも「全部人力」でもない——企画から公開までを人と複数AIで分担する設計図 ある事業責任者が「AIに要件を伝えたのに、出てきた画面がイメージと違う」と嘆いていました。原因はAIの能力ではなく、役割分担の設計が無かったことでした。一人のAIに企画も設計も実装もレビューも押し付ければ、責任の所在が曖昧になり、抜け漏れは誰も気づきません。人間の組織で「一人に全部やらせない」のと同じ発想が、AI活用にも必要です。 この記事の主張:AIは「一人」ではなく「チーム」として配置する 本記事の主張はシンプルです。AIを1つの万能アシスタントとして使うのをやめ、企画・設計・実装・レビュー・テストという工程ごとに別々の役割として分担させること。そして人間(PM・事業責任者)は「作業者」ではなく「意思決定者・受け入れ判定者」に回ることです。 この構成にすると、各工程の成果物が明確になり、AI同士が互いの出力をチェックし合う仕組みが作れます。結果として、冒頭のような「イメージと違うものが出てくる」事故を減らし、非エンジニアでも品質をコントロールしやすくなります。 なぜ今、この問題が起きているのか 生成AIの性能が上がり、「日本語で頼めば動くものが出てくる」段階に入りました。すると多くの現場で、企画から実装まで一つの会話ウィンドウに全部詰め込む使い方が広がっています。 しかしこれは、人間の組織に例えれば「一人の新人に企画・設計・開発・品質保証を同時にやらせ、しかも誰もレビューしない」状態です。AIは指示された範囲を器用にこなしますが、工程間の整合性や、前提の抜け漏れを自分から指摘することは苦手です(筆者の実務観察による意見)。だからこそ、工程を分けて役割を与える設計が効いてきます。 現場では何が起きているのか 変化1:企画と実装の「伝言ゲーム」が消える 従来は「PMが仕様書を書く→エンジニアが読んで実装する」という人から人への伝達で、解釈のズレが生まれていました。AIに工程を分担させると、前工程の成果物(例:要件定義書)をそのまま次工程のAIへ渡せるため、人を介した伝言ゲームが減ります。 変化2:レビューを「後回しにしない」文化が生まれる 人間の現場では、レビューは忙しさで省略されがちです。一方、AIをレビュー担当として常設すれば、設計や実装が出てくるたびに機械的にチェックが走ります。ある小規模開発チームでは、レビュー専用AIに「セキュリティ観点で問題点を列挙」と役割を固定したところ、人間が見落としていた入力チェック漏れを複数拾えた、という報告があります(事例、規模は小さく一般化には注意)。 変化3:非エンジニアが「判定者」として関与できる これまで画面やシステム内部の話は「エンジニアに任せるしかない」領域でした。工程ごとにAIが人間向けの説明つきで成果物を出すため、PMが各段階で「これで進めてよいか」を判断できるようになります。専門知識より「事業として正しいか」を問う力が重要になります。 従来の方法では対応できない理由 「優秀なAIを1つ選べばいい」という発想では、なぜ不十分なのか。理由は3つあります。 検算が効かない:同じAIが作ってレビューすると、自分のミスに気づきにくい。人間でも自己校正が甘くなるのと同じ構造です。 工程の成果物が残らない:一つの会話で進めると、企画・設計・実装が混ざり、後から「なぜこの設計にしたか」を追えません。 責任の切り分けができない:問題が起きたとき、企画のズレなのか実装のバグなのか特定できず、改善の打ち手が決まりません。 工程を分けることは、単なる作業分割ではなくトレーサビリティ(何をどう決めたかを追える状態)の確保でもあります。 役割分担の全体像 図: 人と複数AIの役割分担(横軸=工程、縦軸=担当) | 工程 | 主担当 | 人間(PM)の役割 | 成果物 | ||||| | 企画 | 企画AI | 事業ゴール・制約を提示、採否を判定 | 要件定義書 | | 設計 | 設計AI | 優先度・スコープを決定 | 画面設計・データ設計 | | 画面 | UIAI | ブランド・使いやすさを判断 | 画面仕様・文言 | | システム内部 | 実装AI | 予算・納期の制約を確認 | 実装コード | | レビュー | レビューAI | 指摘の重要度を判断 | 指摘リスト | | テスト | テストAI | 合格基準を決定 | テスト結果 | ポイントは、人間が全工程に「判定者」として1回ずつ登場することです。作業はAIに任せ、人間は「進める/戻す」の意思決定に集中します。 企画から公開までの流れ mermaid %% 用途: 人と複数AIによる開発フロー(企画から公開まで) flowchart TD A[事業ゴール・制約<br/人:PM] B[企画AI<br/要件定義書を作成] B C{人:PMが採否判定} C |差し戻し| B C |承認| D[設計AI<br/画面・データ設計] D E[UIAI<br/画面仕様・文言] E F[実装AI<br/システム内部を構築] F G[レビューAI<br/設計・実装をチェック] G H{人:PMが指摘の<br/重要度を判断} H |修正が必要| F H |OK| I[テストAI<br/動作・不具合を検証] I J{人:PMが<br/合格基準で判定} J |不合格| F J |合格| K[公開] この流れの肝は、AIが作った成果物を別のAIと人間がダブルでチェックする関門(◇の判定ポイント)があることです。関門を通らないと次工程に進めない設計にすることで、品質が担保されます。 そのまま使える「役割分担プロンプト」テンプレート 各工程のAIに「役割」を固定するためのプロンプトです。会話ごとに、または別々のAIツールに貼り付けて使えます。 markdown 用途: 各工程のAIに役割を固定するシステムプロンプト 使い方: 〈〉部分を自社の内容に置き換え、工程ごとに別会話で使用 【企画AI】 あなたは要件定義の専門家です。以下の事業ゴールから要件定義書を作成してください。 事業ゴール:〈例:リピート率を上げる会員向けお知らせ機能〉 制約:〈予算・納期・既存システム〉 出力:機能一覧/優先度(高中低)/対象外の明記/前提の確認質問 ※不明点は勝手に決めず、必ず質問として列挙すること。 【レビューAI】 あなたは第三者レビュアーです。以下の成果物を批判的に点検してください。 自分で作り直さず、指摘のみを行います。 観点:要件との不一致/抜け漏れ/セキュリティ/使いやすさ 出力:指摘を「重要度(高中低)+根拠+改善案」の表で列挙 ※「問題なし」と書く前に、必ず3つ以上の観点で検証した過程を示すこと。 【テストAI】 あなたはQA担当です。以下の要件に対するテスト項目を作成し、結果を判定してください。 出力:テスト項目/期待結果/実際の結果/合否 ※正常系だけでなく、異常系(空欄・不正な値・大量データ)を必ず含めること。 ※で始まる制約が重要です。AIは放っておくと「問題なし」で済ませがちなので、検証の過程を強制することで品質が上がります(筆者の実務での意見)。 経営・組織に与える影響 この分担構成は、開発のやり方を超えて組織のあり方を変えます。 意思決定:PMが「作れるか」ではなく「作るべきか」に集中でき、判断の質が上がる。 採用・人材:必要なのは全工程を一人で書ける人材より、AIの成果物を評価・判定できる人材。専門スキルより「良し悪しを見抜く目」の価値が上がる。 教育:新人が各工程のAI出力を「なぜこの指摘が妥当か」と学ぶことで、実務を早く体得できる可能性がある(推測)。 品質管理:関門(判定ポイント)を制度化することで、属人的なレビューを仕組みに変えられる。 責任分担:工程ごとに成果物が残るため、問題発生時に「どの工程で何を決めたか」を追える。 一方で注意点もあります。最終責任は人間が負うという原則を崩してはいけません。AIが承認したから、ではなく、人間が判定したから進める、という建て付けを守る必要があります。 企業は何から始めるべきか 1. 1つの小さな機能で試す:いきなり全社導入せず、影響の小さい機能で分担フローを回してみる。 2. 判定ポイントを2つだけ決める:最初は「企画承認」と「公開判定」の2関門から。慣れたらレビュー・テストを追加する。 3. 成果物の置き場を決める:要件定義書や指摘リストをどこに残すか(共有フォルダ等)を先に決める。追えることが品質の土台。 4. 役割プロンプトを社内資産にする:上記テンプレートを自社版に育て、誰が使っても同じ品質が出る状態を目指す。 5. 人間の「判定基準」を言語化する:何をもって合格とするかを事前に決める。基準が曖昧だと関門が機能しない。 まとめ AIは「一人の万能アシスタント」ではなく「工程ごとの役割を持つチーム」として配置する——これが本記事の主張です。人間(PM・事業責任者)は作業から降り、各工程の関門で「進める/戻す」を判定する意思決定者に回ります。 まず最初の一歩は、小さな機能を1つ選び、「企画承認」と「公開判定」の2つの関門を置いて流してみること。ここから、あなたの組織に合った分担図が育っていきます。 実践チェックリスト [ ] 企画・設計・実装・レビュー・テストを別々の役割として分けたか [ ] 各工程の成果物(要件定義書・指摘リスト等)を残す場所を決めたか [ ] 人間が判定する関門を最低2つ設けたか [ ] レビューAIと実装AIを同じ会話にせず、分離したか [ ] 役割プロンプトに「検証過程を示す」制約を入れたか [ ] 合格基準(何をもってOKか)を事前に言語化したか [ ] 最終責任は人間が負う建て付けになっているか 次に読む記事 基礎:「生成AIとは何か——非エンジニアのためのできること・できないこと入門」 実践:「レビューAIを使いこなす:『問題なし』と言わせない指示の書き方」 発展:「AIエージェントの自律実行と人間の承認ゲート設計——ガバナンスの作り方」 よくある質問 Q. 複数のAIツールを契約する必要がありますか? A. 必須ではありません。1つのツールでも、会話(セッション)を工程ごとに分ければ役割分担は実現できます。重要なのはツールの数ではなく、工程と成果物を分けることです。 Q. 非エンジニアでもレビューやテストの判定ができますか? A. できます。判定の中身は「事業として正しいか」「使う人が困らないか」が中心で、技術的な妥当性はレビューAIが指摘します。人間は指摘の重要度と、事業への影響を判断する役割です。 Q. AI同士のチェックは本当に信頼できますか? A. 万能ではありません。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つの工程で開発の主役になれる。まず最初の一歩として、次の企画で「たたき台の画面を早めに見せてほしい」と一言伝えることから始めてほしい。 実践チェックリスト [ ] 要件定義の会議に、現場を知る担当者が発言者として参加している [ ] 完成前の「たたき台画面」を現場が触る機会を設けている [ ] 要件伝達プロンプトで、抜け漏れなく要望を言語化した [ ] 受入テストで「通常操作・異常入力・実データ」の3観点を確認した [ ] エンジニアに任せる範囲(設計・セキュリティ等)を明文化した [ ] 改善提案を「感想」でなく「具体的な指示」の形にしている 次に読む記事 基礎:「非エンジニアのための要件定義入門——業務の困りごとを仕様に変える書き方」 実践:「ローコードツールの選び方——現場が自分で直せる範囲を見極める」 発展:「共同責任型の開発体制——作る側と使う側の評価制度をどう変えるか」 よくある質問 Q. 結局、非エンジニアもプログラミングを学ぶべきですか? 必須ではありません。この記事で紹介した5工程は、コードを書けなくても参加できます。ただし「どこまで自動化できるか」の感覚があると要件の解像度が上がるため、簡単なローコードツールを触ってみる程度は有益です。 Q. 現場が要件に口を出すと、開発が遅くなりませんか? 短期的には確認の手間が増えますが、完成後の作り直しが減るため、多くの場合トータルでは速くなります。重要なのは「早い段階で・具体的に」関与することで、完成間際のちゃぶ台返しを避けることです。 Q. エンジニアとの役割分担で揉めないコツは? 「何を作るかは現場、どう作るかはエンジニア」という原則を最初に共有することです。設計やセキュリティなど技術判断に非エンジニアが介入すると事故のもとになるため、線引きを文書化しておくと衝突を防げます。

2026/8/2

アイデアを1日で試作品に:非エンジニアがAIと対話して形にする5ステップ 「頭の中にある業務改善アイデアを、開発チームに頼まず自分で形にしたい」——そんな事業責任者・業務担当者へ。本記事はAIとの対話でアイデアを目的・利用者・機能・画面へ分解し、触れる試作品まで持っていく手順を、具体例とコピペ用プロンプト付きで解説します。 この記事の結論 アイデアを「目的→利用者→機能→画面」の順に分解すると、AIが的確に手伝える状態になる AIは分解と試作の作業を高速化するが、何が正しいかを決めるのはあなた(業務知識を持つ本人) 試作品は「見た目だけ動くモックアップ」で十分。完璧なシステムは不要 プロンプトを型にすれば、非エンジニアでも半日〜1日で触れる試作品に到達できる 最初にやるべきは「1文で目的を言語化する」こと。ここが曖昧だと全工程が崩れる 強調ボックス:試作品とは何か ここでいう試作品(プロトタイプ)は「画面をクリックすると次の画面に進む、見た目だけの模型」です。データベースや本番ロジックは不要。関係者に見せて「これで合ってる?」を確認するための道具です。 この記事が役立つ人 業務改善やサービスのアイデアはあるが、要件を言語化できず止まっている人 開発チームやベンダーに説明する前に、自分でイメージを固めたい人 「AIに丸投げしたら微妙なものが出てきた」経験がある人 前提条件は特にありません。ChatGPT・Claude などの対話AIと、後半で紹介する試作ツール(無料枠あり)が使えれば十分です。 なぜこの問題が起きるのか 多くのアイデアが試作にたどり着けない原因は、頭の中の「なんとなく」を、AIや開発者に渡せる粒度まで分解できていないことです。人は完成イメージを一度に思い描きますが、作るには順序立てた分解が必要です。 AIに丸投げすると失敗しがちなのも同じ理由です。目的や利用者が曖昧なままだと、AIは統計的にありそうな「平均的な機能」を出力します。あなたの業務固有の事情は、あなたしか知りません(筆者の意見)。 図: アイデアが試作品になるまでの分解ピラミッド 目的(なぜ作る) ← 1文で 利用者(誰が使う) ← 2〜3タイプ 機能(何ができる) ← 箇条書き5〜10個 画面(どう見える・操作する) ← 3〜6画面 解決するための5つのポイント 1. 目的を「1文」に絞ると、以降の判断軸ができる 結論:最初に目的を1文で書くと、機能を足すか捨てるかを迷わず判断できます。 具体例:「営業担当が外出先から日報を書くのが面倒」という課題なら、目的は「営業日報の入力時間を10分から2分に減らす」。この1文があれば「グラフ機能」は目的外だと即判断できます。 実践方法:AIに「この目的文は具体的で測定可能か、3案に書き直して」と依頼し、自分で1つ選ぶ。選ぶのはあなたの仕事です。 2. 利用者を2〜3タイプに具体化すると、機能の優先順位が決まる 結論:「誰が」を具体化すると、機能の要不要が自然に見えてきます。 具体例:日報アプリなら「①外回りの若手営業(スマホ中心・急いでいる)」「②確認する営業マネージャー(PC・一覧で見たい)」。この2人で必要な画面が変わります。 実践方法:AIに人物像(ペルソナ)の下書きを作らせ、実在の同僚を思い浮かべて修正します。「うちの田中さんならこう使わない」という補正はAIにできません。 3. 機能はMoSCoWで仕分けし、試作は「Must」だけに絞る 結論:全機能を作ろうとすると挫折します。試作は必須機能だけに絞ります。 MoSCoW(モスクワ)法は機能を4段階で仕分けする手法です。 | 区分 | 意味 | 日報アプリの例 | |||| | Must | ないと成立しない | 訪問先・商談内容の入力/送信 | | Should | あると良い | 音声入力 | | Could | 余裕があれば | テンプレート選択 | | Won't | 今回はやらない | 売上グラフ・分析 | 実践方法:機能を全部書き出し、AIに「MoSCoWで仕分け案を出して」と依頼。最終判断は業務を知るあなたが行います。 4. 画面は「利用者の1回の作業の流れ」で並べる 結論:機能一覧を、利用者が実際にたどる画面の順番に並べ替えると試作設計になります。 具体例:若手営業の流れは「ログイン → 今日の訪問先を選ぶ → 商談内容を入力 → 送信完了」の4画面。この流れを言葉で書けたら試作の設計図は完成です。 実践方法:後述のMermaid図でAIに画面遷移を書かせ、抜けや不自然な戻り道を目視で確認します。 5. 触れる試作品にして「関係者に見せる」までを1周とする 結論:頭の中で完璧にせず、粗くても触れる形にして人に見せることでアイデアが磨かれます。 具体例:あるバックオフィス担当者(筆者が支援した事例・詳細は簡略化)は、経費申請フローの試作を半日で作り、上長に見せた結果「承認ステップが1つ足りない」と即発覚。開発前に手戻りを防げました。 実践方法:試作ツールに画面遷移図を渡して生成させ、社内の想定利用者2〜3人にクリックしてもらいます。 強調ボックス:AIに任せてよい作業/自分がやる判断 任せてよい:文章の整形、選択肢の列挙、たたき台の生成、画面遷移の下書き。 自分がやる:目的の決定、利用者の実像補正、機能の取捨選択、「業務上ありえない」の指摘。 AIやツールで自動化する方法 対話AIで分解を進め、生成したMermaidをAIコーディングツールに渡すと、触れる試作品まで一気通貫で進められます。特定製品に依存しない汎用的な流れを示します。 図: ツールの役割分担 対話AI(ChatGPT/Claude)→ 分解・要件整理・Mermaid生成 ↓ 画面遷移図を渡す AIコーディング(Claude Code/Cursor/v0等)→ 動くモックHTML生成 ↓ ブラウザで確認 → 関係者に共有 そのまま使えるアイデア分解プロンプト 対話AIに貼り付け、〈〉を自分のアイデアに置き換えて使います。 text 用途: アイデアをAIと対話で分解するためのプロンプト あなたは新規サービスの要件整理を手伝うファシリテーターです。 私は非エンジニアの業務担当者です。以下のアイデアを、私が判断しやすい 形で段階的に分解してください。各段階で私に確認を取り、私の回答を待って から次に進んでください。勝手に先へ進めないでください。 私のアイデア 〈例:営業が外出先からスマホで日報を書くのが面倒なので楽にしたい〉 進めてほしい順番 1. 目的を「測定可能な1文」で3案提示(私が1つ選ぶ) 2. 想定利用者を2〜3タイプ、簡単なペルソナで提示 3. 必要そうな機能を列挙し、MoSCoW(Must/Should/Could/Won't)で仕分け案 4. Must機能だけで成立する画面の流れを、画面名のリストで提示 5. 上記4をMermaidのflowchartで出力 ルール 専門用語には短い説明を添える 各段階の最後に「この内容で合っていますか?修正はありますか?」と質問する そのまま使える画面遷移図(Mermaid) 対話AIが出力する形式の見本です。これをAIコーディングツールに渡すと試作HTMLになります。 mermaid flowchart TD A[ログイン画面] B[今日の訪問先一覧] B C[商談内容 入力画面] C D{必須項目は<br埋まっている?} D いいえ C D はい E[送信完了画面] B F[過去の日報を見る] そのまま使える試作生成プロンプト 上記Mermaidや画面リストを、AIコーディングツール(Claude Code / Cursor / v0 等)に渡します。 text 用途: 画面遷移図から触れるモックアップを生成する 以下の画面遷移をもとに、1つのHTMLファイルで動くモックアップを作って ください。ボタンを押すと画面が切り替わる程度で十分です。データベースや サーバー処理は不要。スマホ表示を優先。日本語UI。 画面遷移 〈ここに上のMermaidまたは画面リストを貼る〉 条件 見た目より「流れが確認できること」を優先 各画面にダミーの入力欄・ボタンを配置 1ファイルで完結し、ブラウザで開けばそのまま動くこと 実践チェックリスト [ ] 目的を「測定可能な1文」で書けた [ ] 利用者を2〜3タイプ、実在の人物を思い浮かべて具体化した [ ] 機能をMoSCoWで仕分けし、Mustを5個以内に絞った [ ] Must機能で成立する画面の流れを言葉で書けた [ ] AIにMermaidの画面遷移図を出させ、抜けを目視確認した [ ] 触れるモックアップを生成し、想定利用者2〜3人に見せた [ ] AIの出力を鵜呑みにせず「業務上おかしい点」を自分で補正した まとめ アイデアを試作品にする鍵は、AIに丸投げせず「目的→利用者→機能→画面」の順で分解し、各段階の判断を業務知識のある自分が下すことです。AIは高速な下書き係、あなたは最終決定者です。 最初に着手する行動:本記事の「アイデア分解プロンプト」を対話AIに貼り、目的の1文を決めるところから始めてください。ここが決まれば残りは驚くほど進みます。 次に読む記事 基礎:対話AIへの指示が上手くなる「プロンプトの型」入門 実践:MoSCoW法で機能の優先順位を30分で決めるワークショップ設計 発展:試作品を開発チーム・ベンダーに渡すための要件伝達ドキュメントの作り方 よくある質問 Q. プログラミングを全く知らなくても試作品は作れますか? A. はい。本記事の試作生成プロンプトを使えば、AIがHTMLを書きます。あなたはブラウザで開いて「流れが正しいか」を確認するだけです。コードを読む必要はありません。 Q. AIに全部任せた方が早いのでは? A. 下書きは任せて構いませんが、目的・利用者・機能の取捨選択は任せられません。AIは平均的な提案しかできず、あなたの業務固有の事情(承認フローや例外処理など)を知らないためです。 Q. 試作品はそのまま本番システムに使えますか? A. 使えません。試作品は関係者と認識を合わせる「模型」です。ただし試作で固めた要件と画面は、開発チームへの発注資料としてそのまま活用でき、手戻りを大きく減らせます。

2026/8/2

AIにバグ原因を調査させる方法｜「修正役」と「確認役」を分けて誤修正を防ぐ実践手順 AIにコード修正を任せると、原因を取り違えたまま「直したつもり」で本番に反映され、別の不具合を生むことがあります。本記事では、AIを「原因調査役」「修正役」「確認役」に分け、一度の修正を無検証で反映しない仕組みを解説します。 この記事の結論 AIに1回で「原因特定→修正→反映」まで任せない。工程を分けると誤修正が激減する。 調査役・修正役・確認役の3ロールに分割する。同じAIでも「役割ごとに別セッション」で運用できる。 確認役は修正内容ではなく"再現テスト"で判定する。「動いた」の自己申告を信じない。 本番反映の前に必ず人間の承認ゲートを1つ置く。自動化してもここだけは残す。 まず「調査役プロンプト」と「確認チェックリスト」の2つを用意すれば今日から始められる。 この記事が役立つ人 対象は、AIコーディングツール(Claude Code、Cursor、GitHub Copilotなど)を使ってバグ修正をしている開発者・チームリーダーです。「AIが直したはずなのに再発する」「修正差分が大きすぎて怖い」と感じている方に向いています。 前提として、GitのようなバージョンContro（変更履歴を記録する仕組み）と、簡単なテストを実行できる環境があると効果的です。ただし手動確認でも本記事の考え方は使えます。 なぜ「AIの一発修正」で事故が起きるのか 原因は、AIが「もっともらしい修正」を出すことに最適化されているためです。原因が特定できていなくても、それっぽいコードを自信満々に提示します。これは推測であり断定ではありませんが、多くの現場で報告される傾向です。 さらに、同じAIが「修正」と「確認」を兼ねると、自分の修正を自分で肯定する構造になります。人間でもレビューを他者に任せるのはこのためです。AIも例外ではありません。 強調ボックス：一発修正の3大リスク ① 症状(エラーメッセージ)だけ消して真因が残る ② 関係ない箇所まで書き換えて副作用を生む ③ 「テスト通りました」の自己申告が検証されない 図: バグ対応の流れ。「①調査役=原因の仮説」→「②修正役=最小差分」→「③確認役=再現テストで検証」→「④人間承認」→「本番反映」。①②③は分離し、④は必ず人間が担当。 誤修正を防ぐ5つのポイント 1. 「修正させる前に、原因の仮説を言語化させる」 結論：コードを触らせる前に、AIに原因の仮説と根拠を文章で出させると精度が上がります。 具体例：「ログイン後に画面が真っ白」というバグで、いきなり修正させると認証処理を書き換えがちです。しかし先に「考えられる原因を3つ、根拠となるログ・コード行とともに挙げて」と指示すると、真因が「APIレスポンスのnull処理漏れ」だと判明することがあります。 実践方法：調査役プロンプトを固定文にします。「①症状 ②再現条件 ③原因候補3つと該当ファイル ④まだ確定できない点」を必ず出力させます。 2. 「修正役には"最小差分"だけを許可する」 結論：修正の範囲を「原因箇所のみ・最小の変更」に限定すると、副作用が減ります。 具体例：null処理漏れなら、変えるのは該当の1関数だけのはずです。もしAIが5ファイルを書き換えたら、それは黄信号です。 実践方法：修正役への指示に「変更は原因ファイルのみ。整形・リファクタリング・命名変更は禁止」と明記します。差分行数が想定より多ければ却下します。 3. 「確認役は"直ったか"でなく"再現しなくなったか"で判定する」 結論：確認の基準を「元の再現手順でバグが出ないこと」に固定します。修正内容の良し悪しではありません。 具体例：ポイント1で「①症状 ②再現条件」を記録済みなら、その再現条件をそのまま実行するだけで判定できます。「たぶん大丈夫」を排除できます。 実践方法：確認役には修正差分を見せず、再現手順と期待結果だけを渡します。「この手順で症状が出るか、Yes/Noで答え、根拠のログを添付」と指示します。 4. 「同じAIでも"役割を切り替えるセッション"にする」 結論：ロールごとに会話を分けるだけで、自己肯定バイアスを緩和できます。別ツール・別人を用意する必要はありません。 具体例：Claude Codeなら調査用チャットと確認用チャットを別に開く。確認用には修正前の情報を渡さず、白紙の状態で再現テストだけ依頼します。 実践方法：3つのプロンプトテンプレートを用意し、同じスレッドに混在させないルールにします。 5. 「本番反映の前に、人間の承認ゲートを1つ残す」 結論：どれだけ自動化しても、本番反映の直前だけは人間が承認します。ここを省くと事故の被害が最大化します。 具体例：確認役がYesを出しても、差分が20行あれば人間が「なぜこの変更で直るのか」を1分読む。理解できなければ差し戻します。 実践方法：Gitのプルリクエスト（変更をまとめて承認申請する仕組み）を承認ゲートにします。マージ権限を人間だけに残します。 | 役割 | 入力に渡すもの | 出力するもの | 渡さないもの | ||||| | 調査役 | 症状・ログ・コード | 原因候補と根拠 | — | | 修正役 | 確定した原因のみ | 最小差分 | 無関係な要望 | | 確認役 | 再現手順・期待結果 | Yes/Noと根拠ログ | 修正差分 | | 人間 | 差分と確認結果 | 承認/差し戻し | — | AIやツールで自動化する方法 工程分割は、既存ツールの組み合わせで自動化できます。特定製品が必須ではありません。以下は一例です。 調査・修正・確認の分離：Claude CodeやCursorで「役割ごとのプロンプト」をファイル保存し、都度読み込む。 再現テストの自動実行：確認役の判定を、PytestやJestなどの自動テストに置き換えると客観性が上がる。 承認ゲート：GitHub Actions（変更時に自動処理を走らせる仕組み）でテストを実行し、成功しても自動マージはしない設定にする。マージは人間が押す。 強調ボックス：自動化しても外さない1点 「テストが通る」＝「安全」ではありません。テストが元のバグを再現できていなければ、通っても意味がない。再現テストが先、修正は後の順序を守ってください。 図: GitHub Actionsを使う場合。プルリク作成→自動で再現テスト実行→結果をコメント表示→人間がマージボタンを押す（ここは自動化しない）。 体験メモ（筆者の運用例・一般化はできません）：調査役の出力に「まだ確定できない点」欄を足しただけで、AIが早合点で修正を始めるケースが体感で減りました。数値化はしていないため参考程度に捉えてください。 実践チェックリスト [ ] 修正前に「症状・再現条件」を文章で記録した [ ] 調査役に原因候補を3つ、根拠付きで出させた [ ] 修正役への指示に「最小差分・整形禁止」を明記した [ ] 確認役には差分を渡さず、再現手順だけで判定させた [ ] 確認は「Yes/No＋根拠ログ」の形式で受け取った [ ] 本番反映の前に人間の承認ゲートを通した [ ] 差分の内容を人間が読んで理解できた まとめ AIの誤修正は「1回で原因特定から反映まで任せる」ことで起きます。調査・修正・確認を分け、確認は再現テストで、反映前に人間承認を1つ残すのが解決の核心です。 最初に着手すべきは、「調査役プロンプト（症状・再現条件・原因候補3つ）」を1つ作ること。これだけで一発修正の事故が目に見えて減ります。 次に読む記事 基礎：AIコーディングツールの選び方｜Copilot・Cursor・Claude Codeの違いと使い分け 実践：バグ再現手順の書き方｜「動かない」を"必ず再現する条件"に変える技術 発展：GitHub Actionsで作るレビュー自動化｜自動マージを避けて安全に高速化する設計 よくある質問 Q. 役割を分けると手間が増えて遅くなりませんか？ A. 単純なバグでは確かに手数が増えます。ただし誤修正による再発・切り戻しの時間を含めると、複雑なバグほど分割した方が結果的に速くなる傾向があります。軽微な修正は分割を省く判断もありです。 Q. AIが1つしか使えません。それでも分離できますか？ A. できます。同じAIでもチャット（セッション）を分け、確認役には修正差分を渡さず再現手順だけを渡せば十分効果があります。重要なのはツールの数でなく「情報の渡し方」です。 Q. 確認役のAIが「Yes」と言えば本番反映してよいですか？ A. いいえ。確認役の判定は参考情報です。本番反映の直前は必ず人間が差分を読み、承認してください。この1ゲートを省くと自動化の事故が最大化します。

2026/8/2

この記事は有料です。続きは購入またはサブスクでご覧いただけます。

2026/8/1

マーケティングオートメーションとは何ですか？ マーケティングオートメーション(MA)は、見込み客の獲得から育成・分析までを自動化する仕組みです。 よくある質問 Q1. 導入のメリットは？ 配信や分析の手作業を削減し、リードを逃さず育成できます。 Q2. 無料で始められますか？ UNEEKMAはドライランで安全に試せます。

2026/6/30