Ccmmutty logo
Commutty IT
0 pv6 min read

AIを使った設計レビュー:非技術者でも気づける設計の落とし穴

https://cdn.magicode.io/media/notebox/e0bc9c1c-3c90-47ba-9fcf-2804fbb8a906.jpeg

設計書を前に立ち尽くすPMの現実

「設計レビューお願いします」と開発チームから渡される、びっしりと図表が描かれた設計書。
UML図、システム構成図、データベース設計書...技術的な記号や専門用語だらけの資料を前に、「とりあえず『お疲れ様でした』と言っておこうか」と思ったことはありませんか?
PM・システム企画として、設計の良し悪しを判断する責任は感じているものの、具体的に何をチェックすればいいのか分からない。これは多くの非技術者が抱える共通の悩みです。
しかし、生成AIを活用することで、技術的な詳細が分からなくても設計の本質的な問題を発見できることを実感しています。今日は、その具体的な手法をお伝えします。

非技術者が設計レビューで果たすべき役割とは?

まず、PMが設計レビューで何を見るべきかを整理しましょう。

技術者が見る観点

  • 技術的な実装可能性、性能特性
  • 設計パターンの適用、コードの保守性
  • セキュリティホール、パフォーマンスボトルネック

PMが見るべき観点

  • 業務要件との整合性:設計が要件を正しく実現できるか
  • 運用・保守の現実性:実際の運用で破綻しないか
  • 拡張性・変更容易性:将来の仕様変更に対応できるか
  • ステークホルダーへの影響:各関係者にとって使いやすい設計か
重要なのは、PMには「ビジネス視点」と「運用視点」という、技術者にはない強みがあることです。

AIを活用した設計レビューの6つのアプローチ

アプローチ1:設計意図の可視化

まず、設計書からAIに設計意図を読み取ってもらいます。
プロンプト例:
以下の設計書について、設計者がどのような意図で
この設計を採用したかを分析してください。

特に以下の観点で説明してください:
1. この設計で解決しようとしている課題は何か
2. なぜこのような構成を選択したのか
3. 他の設計選択肢と比べた利点は何か
4. この設計によるトレードオフは何か

【設計書】
[設計書の内容をここに貼り付け]
これにより得られる効果:
  • 設計の背景理解が深まる
  • 要件との整合性をチェックできる
  • 設計者との議論の土台ができる

アプローチ2:業務フロー観点での検証

設計がビジネスプロセスを正しく反映しているかをチェックします。
プロンプト例:
以下の設計について、実際の業務フローの観点で
問題となりそうな点を指摘してください。

【業務フロー】
[現在の業務プロセスを詳細に記載]

【設計内容】  
[設計書の内容をここに貼り付け]

チェック項目:
1. 業務の流れが設計に正しく反映されているか
2. 業務上必要な情報が適切に管理されているか
3. 承認・確認プロセスが設計に含まれているか
4. 例外処理が業務ルールと整合しているか

アプローチ3:運用シナリオでの設計評価

実際の運用場面を想定して設計の妥当性を検証します。
プロンプト例:
以下の設計について、実際の運用場面で発生しそうな
問題を予測してください。

運用シナリオ:
【平常時】月間処理件数1万件、同時利用者数50人
【繁忙期】月間処理件数5万件、同時利用者数200人  
【障害時】サーバー1台停止、ネットワーク遅延発生
【保守時】月次バッチ処理、データバックアップ

【設計内容】
[設計書の内容をここに貼り付け]

各シナリオで以下を評価してください:
1. 設計が想定する処理能力は十分か
2. 障害時の影響範囲は適切にコントロールされるか
3. 保守作業時の業務への影響は最小化されるか

アプローチ4:ステークホルダー影響分析

設計変更が各関係者に与える影響を分析します。
プロンプト例:
以下の設計について、各ステークホルダーへの影響を分析し、
配慮が不足している点を指摘してください。

【ステークホルダー】
- エンドユーザー:[詳細な特徴・制約]
- システム運用者:[運用体制・スキルレベル]  
- 経営陣:[重視する指標・制約条件]
- 外部連携先:[連携システム・制約事項]

【設計内容】
[設計書の内容をここに貼り付け]

分析項目:
1. 各ステークホルダーにとって使いやすい設計か
2. 運用負荷の増加や新たなスキル要求はないか
3. 費用対効果は各ステークホルダーにとって妥当か

アプローチ5:将来変更への対応力評価

設計の拡張性・変更容易性をビジネス観点で評価します。
プロンプト例:
以下の設計について、将来的に発生しそうな変更要求に対する
対応容易性を評価してください。

【予想される変更シナリオ】
- 事業拡大:利用者数10倍、処理量20倍
- 新サービス追加:[具体的な新機能の想定]
- 法制度変更:[業界特有の規制変更]
- 外部連携拡大:[新たなシステム連携]

【設計内容】
[設計書の内容をここに貼り付け]

評価項目:
1. 各変更シナリオへの対応コストは適切か
2. 設計変更時の業務影響は最小化できるか
3. 段階的な拡張・移行は可能か

アプローチ6:リスク・制約事項の洗い出し

設計に内在するリスクと制約事項を明確化します。
プロンプト例:
以下の設計について、潜在的なリスクと制約事項を
ビジネス観点で洗い出してください。

【設計内容】
[設計書の内容をここに貼り付け]

【プロジェクト制約】
- 予算上限:[金額]
- 開発期間:[期間]  
- 人的リソース:[体制・スキル]
- 技術的制約:[既存システム・規制等]

リスク分析項目:
1. 設計の複雑さによる開発リスク
2. 技術的依存関係によるリスク
3. 運用・保守での継続的なリスク
4. 事業継続性へのリスク

実践事例:顧客管理システム刷新での成果

プロジェクト概要

製造業(従業員500名)の顧客管理システム刷新プロジェクト

AI設計レビューで発見した主な問題

1. 業務フローとの乖離
  • 問題:設計上は顧客情報の一元管理だが、実際の営業プロセスでは部門別管理が必要
  • 影響:営業効率の低下、データの重複管理
  • 対策:部門別ビューと全社ビューを両立する設計に変更
2. 運用負荷の過小評価
  • 問題:データ整合性チェックが手動運用前提の設計
  • 影響:月次で2人日の手作業が発生、運用ミスのリスク
  • 対策:自動チェック機能と例外レポート機能を追加
3. 将来拡張性の問題
  • 問題:海外展開時の多通貨・多言語対応が困難な設計
  • 影響:将来の事業拡大時に大幅なシステム改修が必要
  • 対策:国際化対応を前提とした設計に変更

結果と効果

設計品質の向上:
  • 設計変更による追加コスト:当初予算の3%(通常10-15%)
  • 開発中の仕様変更:60%削減(20件→8件)
  • 受入テスト不合格率:80%削減(10件→2件)
運用開始後の効果:
  • 運用作業時間:50%削減(月20時間→10時間)
  • ユーザー満足度:従来比30%向上
  • システム障害:90%削減(月2件→月0.2件)

設計レビュー実践のためのチェックテンプレート

基本レビューテンプレート

1. 要件整合性チェック
- [ ] 機能要件がすべて設計に反映されているか
- [ ] 非機能要件(性能・セキュリティ等)が考慮されているか
- [ ] 業務フローが正しく設計に反映されているか

2. 運用現実性チェック
- [ ] 運用体制・スキルで対応可能な設計か
- [ ] 保守・メンテナンス作業は現実的か
- [ ] 障害時の対応手順は明確か

3. ステークホルダー配慮チェック
- [ ] エンドユーザーにとって使いやすい設計か
- [ ] システム管理者の負荷は適切か
- [ ] 経営指標への影響は想定通りか

4. 将来対応力チェック  
- [ ] 事業拡大に対応できる設計か
- [ ] 新機能追加時の影響は局所化されるか
- [ ] 技術進歩への対応は考慮されているか

5. リスク・制約チェック
- [ ] 技術的リスクは適切に管理されているか
- [ ] 予算・期間制約は現実的か
- [ ] 外部依存関係は明確化されているか

分野別チェックポイント

【ECサイト】
  • 決済フローの複雑さは適切か
  • 在庫管理の整合性は保たれるか
  • セール時のアクセス集中に対応できるか
【基幹システム】
  • 既存データの移行計画は現実的か
  • 並行稼働期間の業務負荷は適切か
  • 承認ワークフローは業務に合致しているか
【情報共有システム】
  • 情報の分類・検索方法は直感的か
  • アクセス権限設定は運用しやすいか
  • 情報の更新・削除ルールは明確か

よくある質問と対策

Q: AIの分析結果が技術的すぎて理解できません
A: AIに「非技術者向けに、ビジネス影響を中心に説明し直して」と依頼しましょう。具体的な業務シーンでの問題として説明してもらうと理解しやすくなります。
Q: 開発チームから「設計は技術的な判断」と言われました
A: 「技術的詳細は信頼している。ただし、ビジネス要件との整合性と運用の現実性について確認させて欲しい」という姿勢で臨みましょう。
Q: AIの指摘が多すぎて優先順位がつけられません
A: AIに「指摘した問題を、ビジネス影響度と対応コストで優先順位をつけて」と依頼してください。その結果を基に、開発チームと議論しましょう。

まとめ:設計品質向上のパートナーとしてのAI活用

設計レビューにおいて、PMの役割は技術的な正しさを判断することではありません。
ビジネス視点と運用視点から設計の妥当性を評価し、プロジェクトの成功確率を高めることが真の価値です。
AIという強力なパートナーを得た今、技術的な詳細が分からなくても、設計の本質的な問題を発見し、チーム全体の品質意識を向上させることができるようになりました。
次の設計レビューから、ぜひAIを活用してみてください。きっと「こんな視点もあったのか」という新しい発見があるはずです。
そして、その発見が、プロジェクト成功への確実な一歩となるでしょう。

次回は「テスト工程での生成AI活用術」をお届け予定です。テスト設計からバグ分析まで、品質向上のためのAI活用法を詳しく解説しますので、お楽しみに!

Discussion

コメントにはログインが必要です。