システム開発経験の浅い顧客との合意形成では、視覚的・体験的なレビューを重視し、開発側が積極的にリードすることで、後工程のトラブルを防ぎます。

顧客がシステム開発の経験が浅く、レビューの能力や知識に欠けている場合、設計書のレビューと承認プロセスは、通常の方法ではうまくいきません。単に設計書を渡して「レビューしてください」と言うだけでは、形式的な承認しか得られず、後工程での手戻りや「言った言わない」のトラブルにつながるリスクが非常に高まります。

このような状況では、開発側が顧客を積極的にリードし、顧客が理解できる形での情報提供と、具体的なアクションを促すレビュープロセスを設計する必要があります。顧客の理解を深め、安心して承認してもらうためのアプローチを以下に解説します。

最も重要なのは、「顧客の視点」に立ち、「視覚的」かつ「体験的」なレビューを重視することです。

1. 徹底的な平易化と視覚化:
   • 専門用語の排除: 設計書からシステム開発の専門用語（例: CRUD、トランザクション、正規化、API、レイヤードアーキテクチャ）を極力排除し、顧客の業務用語に置き換えるか、平易な言葉で説明します。
   • 図の多用: 文字ばかりの記述ではなく、フローチャート、画面遷移図、簡単なシステム構成図、データフロー図などを多用し、視覚的に理解しやすいようにします。
   • 具体例の提示: 抽象的な説明だけでなく、「この画面でこのボタンを押すと、この画面に遷移し、この情報が表示されます」といった具体的なシナリオや操作例を提示します。
   • プロトタイプ・モックアップの作成:
     • 画面: 画面設計書は、静的な画像だけでなく、クリック可能なモックアップ（Figma, Adobe XD, PowerPointなど）や、簡易的なプロトタイプ（HTML/CSS/JSなど）を作成し、顧客が実際に操作感を体験できるようにします。
     • 帳票: 帳票は、実際の出力イメージをPDFなどで提示します。
     • 外部インターフェース: 顧客が直接見る部分ではないため、そのインターフェースが「何をするのか」「何を得られるのか」を業務視点で説明します。
2. レビュー観点の明確化とチェックリストの提供:
   • 顧客に「何を見てほしいのか」を具体的に伝えます。
   • 「この画面に、必要な情報は全て表示されていますか？」
   • 「このボタンを押したときの動きは、業務の流れと合っていますか？」
   • 「この帳票に、集計してほしい項目は全て含まれていますか？」
   • 「このシステムで処理してほしい業務は、全てカバーされていますか？（抜け漏れはありませんか？）」
   • 「このシステムに期待するスピードや使いやすさは、この設計で実現できそうですか？」
   • 「このシステムが止まると困る時間帯や、セキュリティで特に気をつけたい点はありますか？」
   • といった、業務視点での具体的な質問リストやチェックリストを事前に作成し、提供します。
3. レビュー範囲の限定と分割:
   • 一度に全ての設計書をレビューさせるのではなく、画面、帳票、バッチ処理など、顧客が理解しやすい単位に分割してレビューを進めます。
   • 特に、顧客が直接触れる「外部仕様」の部分（画面、帳票、外部インターフェースの業務的な振る舞い）に重点を置きます。インフラや内部設計の技術的な部分は、その影響を業務視点で説明するに留めます。

1. インタラクティブなウォークスルー:
   • 会議形式: 一方的な説明ではなく、対話形式の会議を設けます。
   • 開発側が操作・説明: 開発側がプロトタイプやモックアップを操作しながら、具体的な業務シナリオに沿ってシステムの動きを説明します。
   • 顧客に操作体験を促す: 実際に顧客にモックアップを触ってもらい、「もしこの場合だったらどうしますか？」などと質問を投げかけ、積極的に参加を促します。
   • 質問しやすい雰囲気作り: どんな些細な質問でも歓迎する姿勢を示し、顧客が疑問や懸念を率直に表明できる雰囲気を作ります。
2. 非機能要件の「業務影響」での説明:
   • 性能: 「この処理は、最大でこれくらいの時間がかかりますが、業務に支障はありませんか？」「もしもっと早くしたい場合、追加でこれくらいのコストがかかります」
   • 可用性: 「システムが止まる可能性はこれくらいですが、止まった場合、業務にどのような影響がありますか？」「もし止まらないようにするには、追加でこれくらいの費用がかかります」
   • セキュリティ: 「このデータは、このレベルで保護されますが、これで十分ですか？」「もしもっと厳重にする場合、操作が複雑になる可能性があります」
   • 運用・保守: 「システム稼働後、何か問題があった場合、ここを見れば原因が分かります。運用担当者の方にとって、分かりやすいですか？」
3. フィードバックの引き出し方:
   • 「ここが分かりません」「これは違う気がする」といった抽象的なフィードバックでも、開発側が具体的に掘り下げて聞き出す努力をします。
   • 「どの部分が分かりませんか？」「具体的に、何がどう違うと感じますか？」「もしこうだったら、もっと良いですか？」といった質問で、顧客の意図を正確に把握します。
   • 顧客の意見を否定せず、まずは受け止めて、その背景にある業務課題や要望を理解しようと努めます。

1. 承認対象の明確化:
   • 顧客に承認を求めるのは、「外部仕様（画面、帳票、外部インターフェースの業務的な振る舞い）と、非機能要件の業務影響」に限定します。インフラの技術的な詳細や、内部設計のコードレベルの設計は、顧客の承認対象から外します（ただし、その影響は説明します）。
   • 承認する設計書の版数を明確に示します。
2. 承認方法の選択:
   • 顧客が技術に不慣れな場合、Gitコミットによる承認は避けるべきです。
   • 推奨:
     • 署名付きPDF: MarkdownファイルをPDFに変換し、印刷して手書き署名をもらうか、電子署名サービス（DocuSignなど）を利用して署名をもらいます。これが最も法的効力が高く、非技術者にも分かりやすい方法です。
     • 承認メール/チャット: 最終合意内容をまとめたメールを送り、顧客からの「承認します」という返信をもって承認とします。このメールは証拠として保管します。チャットツールの場合も同様です。
   • 承認欄への記載: 承認方法に応じて、Markdownの承認欄に「署名済みPDF参照」「承認メール（日付、差出人）参照」などと明記します。
3. 承認の重みの説明:
   • 承認は単なる形式ではなく、「この内容でシステムを開発します」という最終的な合意であり、これ以降の変更は追加費用や納期延長につながる可能性があることを、丁寧に説明し、理解を求めます。

• 顧客向けサマリーの提供: 技術的な詳細が詰まった基本設計書とは別に、顧客がいつでも参照できる**「顧客向けサマリー」**（主要機能一覧、画面イメージ集、主要な非機能要件の目標値など）を作成し、提供すると親切です。
• 保管場所の明確化: 承認済みの設計書がどこに保管され、いつでも参照できるかを顧客に伝えます。

顧客がレビュー能力に欠けている場合、開発側は「設計書を渡す」だけでなく、「顧客が理解し、安心して合意できるプロセスを提供する」責任があります。これは、時間と手間がかかるように見えますが、結果として後工程での手戻りやトラブルを大幅に削減し、プロジェクト全体の経済性と成功確率を高めることにつながります。顧客を「パートナー」として捉え、根気強くコミュニケーションを重ねることが成功の鍵です。