はじめに

当記事は、プロトタイプ版と製品版アプリケーションの違いを列挙し、その結果を基に、プロ品質のシステムを開発することの難しさについて考察するポエムです。
長文ですが、伝えたいことは 「システム開発は難しい」 のみです。

本記事を書いた契機

昨今、良質なプログラミング教材が充実し、言語やフレームワークの進化も相まって、誰しもが簡単に動くアプリケーションを作れるようになりました。

更に、ここ数年の驚異的な生成AIの進化によって、短期間で驚くほどの規模・クオリティのアプリケーションを作れる時代となりました。
「数年後にはプログラマーは不要になる」という説も現実味を帯びてきたように思われます。

しかし、ITスキルの教育支援の充実、生成AIの登場によって、システム開発の難しさを完全に克服出来るのかと言うと、個人的にはNoだと思います。

確かに、生成AIのおかげでコーディング作業は随分と楽になりました。
私も実務・プライベート両方でコーディング時にChatGPTやClaude等の生成AIを活用しており、その驚異的な便利さや開発生産性の向上を実感しています。

それと同時に、テストコードの生成が意外とすんなり出来なかったり、プロンプト内容の反映漏れが発生したり等、思い通りに活用出来なかった経験も多々あります。
生成する内容の難易度・複雑度が増すほどそのような傾向が強くなり、時には 「自分で書いた方が早いのでは？」 と感じることもありました。

そのような経験が積み重なり、やがて

仕事や個人開発で、生成AIを活かしきれないように感じるのは何故か
やりたいことが複雑になると生成AIでは歯が立たなくなるのは何故か
生成AIのパワーを以てしても、自分が困難だと感じる課題の正体は何なのか

について考えるようになりました。

そしてある日、自分が感じている困難の原因の一つに 「プロトタイプ版と製品版の差」 があるのではないかと思い立ちました。

つまり、「とりあえずそれっぽく動く」レベルのソースコードを、お金を生み出す(あるいはお客さんがお金を払ってくれる)レベルにまで高めるには、乗り越えなければならない技術的ハードルが多々あり、
それらは小手先の技術情報や生成AIだけでは乗り越えられないのではないか？と考えたのです。

そこで、一度プロトタイプ版と製品版の違いを洗い出してみて、プロトタイプ版(＝とりあえずそれっぽく動くアプリケーション)を製品版のレベルに持ってくことの難しさについて考察してみることにしました。

（余談ですが、下の内容はClaudeを活用して推敲しています。このような「観点の洗い出し」系のタスクにおいては、生成AIは絶大な威力を発揮します。）

プロトタイプ版と製品版の違い

下のリストは、プロトタイプ版と製品版アプリケーションとの間で、品質面で違いが生じやすい項目を列挙したものです。
また、参考情報として、各項目にプロトタイプ版/製品版それぞれのレベル感や考慮事項を記載しています。

Webアプリケーションを想定していますが、モバイルアプリ開発においてもある程度当てはまるかと思います。

セキュリティ関連

認証・認可

プロトタイプ版

認証機能なし
Basic認証
フレームワーク・ライブラリの基本機能を用いたID/Password認証

製品版

SSO
OpenID/Connect
- IDトークン/アクセストークンの発行
- リフレッシュトークンによる更新
- トークン検証
多要素認証
パスキー認証
eKYC
Auth0
Firebase

ユーザー権限

プロトタイプ版

単一ロール
管理者/一般の2種類のみ

製品版

RBAC（Role-Based Access Control）による柔軟な権限管理
階層的な権限構造
- 組織、部門、グループ単位での権限付与
- ロールの継承関係の定義
権限の動的な付与・剥奪機能
細粒度のアクセス制御
- API単位での実行権限
- データ項目単位での参照/更新権限
- 時間帯による制限
監査ログによる権限変更の追跡
権限管理用の専用画面
- ロールの作成・編集
- 権限の一括設定
- 権限マトリクスの可視化
委譲可能な権限管理（代理権限）
テナント間でのクロスアカウント制御

データ保護

プロトタイプ版

平文でのデータ保存
基本的なパスワードハッシュ化（BCryptなど）
ローカル環境での開発用の自己証明書
開発環境のみのファイアウォール設定
バックアップなし、または手動バックアップのみ
開発用の固定暗号化キー
プレーンテキストでのログ出力

製品版

データの暗号化
- 保存時の暗号化（encryption at rest）
- 通信時の暗号化（encryption in transit）
- 項目単位での選択的暗号化
- 暗号化キーのローテーション
個人情報の保護
- 特定個人情報の分離保存
- データマスキング
- 仮名化・匿名化処理
セキュアな鍵管理
- KMS（Key Management Service）の利用
- HSM（Hardware Security Module）の活用

Cookie管理

プロトタイプ版

sidなど、フレームワークが払い出した基本的なCookieのみ
開発環境での緩いSameSite設定
有効期限の設定なし
HTTPOnlyフラグの未設定
ローカル開発用のドメイン設定

製品版

Cookie管理システム
- GDPRに準拠したCookie同意バナー
- Cookie設定の段階的な同意オプション
- Cookie使用目的の明示と選択制御
- 同意状態の永続化と更新管理
セキュリティ設定
- Secure属性の適用
- HTTPOnly属性の適用
- SameSite属性の適切な設定（Strict/Lax）
- Path属性による適用範囲の制限
サードパーティCookie対策
- トラッキングCookieの制御
- クロスサイトCookieの管理
- サードパーティCookieの代替ソリューション
運用管理
- Cookie有効期限の適切な設定
- Cookie容量の最適化
- 不要Cookieの自動削除
- Cookie使用状況の監査ログ
プライバシー対応
- プライバシーポリシーとの連携
- 地域ごとの法規制対応
- オプトアウト機能の提供

パフォーマンス関連

N+1問題対応

プロトタイプ版

対策なし（単純なクエリ/脳死でORM使用）
Lazy Loadingをデフォルトのまま使用
ループ内でのデータ取得
関連テーブルへの都度アクセス

製品版

Eager Loading（プリフェッチ）の適切な使用
- includes/preload/with等の関連データ一括取得
- 必要な深さまでのネストされたプリフェッチ
JOIN句による最適化
- LEFT JOIN/INNER JOINの使い分け
- サブクエリやEXISTS句の活用
バッチ処理による一括取得
- IN句による関連データの一括取得
- バルクセレクトによるデータロード
ビューやマテリアライズドビューの活用

キャッシュ戦略

プロトタイプ版

キャッシュなし、または最小限の実装
アプリケーションのデフォルトキャッシュ設定
インメモリキャッシュのみ
固定のTTL設定

製品版

多層キャッシュ
- ブラウザキャッシュ（HTTP Cache-Control）
- CDNキャッシュ
- アプリケーションキャッシュ
- DBクエリキャッシュ
分散キャッシュ
- Redis/Memcachedの活用
- キャッシュの整合性管理
- リージョン別のキャッシュ配置
キャッシュ制御
- 動的TTL設定
- LRU/LFUなどの破棄戦略
- パターンベースのキャッシュ削除
- Stale-While-Revalidate
- キャッシュウォーミング
選択的キャッシュ
- ユーザー単位のキャッシュ
- リソース種別ごとのキャッシュ戦略
- 部分的キャッシュの活用
監視と運用
- キャッシュヒット率の監視
- メモリ使用量の制御
- キャッシュの自動スケーリング

同時実行制御

プロトタイプ版

シングルスレッド想定
単独ユーザー想定（複数人による同時実行制御なし）
トランザクション分離レベルはデフォルト設定
楽観的ロックなし
悲観的ロックなし
整合性チェックなし

製品版

スレッドセーフな実装
- トランザクション分離レベルの適切な設定
- セマフォによる同時実行数制御
- スレッドプールの管理
デッドロック対策
- タイムアウト設定
- リトライ機構
- ロックの取得順序の制御
排他制御
- 楽観的ロック（バージョン管理）
- 悲観的ロック（SELECT FOR UPDATE）
- 分散ロック（Redisなど）
データ整合性保護
- 更新衝突の検出と解決
- Lost Update対策
- ファントムリード対策
同時実行性能の最適化
- コネクションプールの設定
- クエリタイムアウトの設定
- ロック範囲の最小化

コネクションプール/トランザクション管理

プロトタイプ版

コネクションプールなし（実行の度に接続確立）
デフォルトのトランザクション設定
固定のコネクション数

製品版

接続プール管理
- 最小/最大プールサイズの最適化
- アイドル接続の破棄制御
- コネクション再利用の監視
- フェイルオーバー設定
トランザクション制御
- 分散トランザクション対応
- ネストされたトランザクション
- トランザクションタイムアウト制御
- セーブポイントの活用
パフォーマンスチューニング
- コネクションリーク検知
- スロークエリのタイムアウト設定
- 接続数の動的スケーリング
- スレッドプールとの連携
監視と運用
- コネクション使用率の監視
- デッドコネクションの検知と除去
- トランザクションのデッドロック検知
- 接続エラーのリトライ制御

ユーザー体験

デザイン

プロトタイプ版

標準的なデザインテンプレートの使用
- デフォルトのカラーパレット
- 基本的なフォント設定
- 汎用的なアイコン
- 標準的なボタン/フォームデザイン
最小限の視覚的階層
- シンプルなレイアウト
- 基本的な余白設定
- 単調な視覚的リズム
限定的な装飾
- 最小限のアニメーション
- 基本的なホバーエフェクト
- シンプルな区切り線や枠線

製品版

ブランドアイデンティティの反映
- カスタムカラーパレット
- ブランド専用フォント
- オリジナルアイコンセット
- ロゴ/ブランド要素の適切な配置
洗練された視覚的階層
- タイポグラフィの階層設計
- 意図的な余白設計
- コントラストを活用した強弱表現
- 視線誘導を考慮したレイアウト
細部まで作り込まれた装飾
- 目的に応じたアニメーション
- インタラクティブな状態設計
- 独自のシャドウスタイル
- テクスチャや素材感の表現
デザインの一貫性担保
- グリッドシステムの厳格な適用
- 統一されたコンポーネント設計
- 一貫したトーン＆マナー

i18n（国際化）

プロトタイプ版

単一言語対応
- ハードコードされたメッセージ
- 固定の日付/時刻フォーマット
- 固定の数値フォーマット
- 単一通貨表示
基本的な文字エンコーディング
- UTF-8のみの対応
- 文字化け対策は最小限
ローカライズ未考慮
- 固定レイアウト
- 文字列長の考慮なし
- 画像/アイコンの固定使用

製品版

多言語サポート
- メッセージリソースの外部化
- 言語パッケージの管理
- フォールバック言語の設定
- 言語切り替え機能
ロケール対応
- 日付/時刻フォーマット
- 数値/通貨フォーマット
- 単位変換
- タイムゾーン管理
文字セット対応
- 複数エンコーディング対応
- 双方向テキスト対応
- 文字化け防止
- フォントファミリー管理
ローカライズ考慮
- 可変レイアウト
- 文字列長の自動調整
- 地域別コンテンツ管理
- 文化的配慮

アクセシビリティ

プロトタイプ版

基本的なHTMLマークアップ
- 見出しタグの基本的な使用
- altテキストの最小限の提供
- 標準的なフォームラベル
限定的なキーボード操作
- 基本的なタブ移動
- 主要機能のみのショートカット
シンプルなコントラスト
- デフォルトカラーの使用
- 基本的な可読性考慮
最小限のエラーフィードバック
- 単純なエラーメッセージ
- 基本的なフォームバリデーション

製品版

セマンティックなHTML実装
- ARIA属性の適切な使用
- ランドマーク要素の活用
- 適切な見出し階層
- フォーム要素の関連付け
- 非表示テキストの最適化
包括的な操作サポート
- 完全なキーボード操作対応
- タッチデバイス対応
- 音声入力対応
- ジェスチャー認識
- フォーカス管理
ビジュアルデザインの配慮
- WCAGガイドライン準拠
- カラーコントラスト最適化
- テキストサイズの柔軟性
- 画面の明るさ/コントラスト調整
- アニメーション制御
支援技術との連携
- スクリーンリーダー対応
- 拡大ツール対応
- 読み上げソフト最適化
- 代替入力デバイス対応
- 支援ソフトウェアとの互換性

コード品質

テスト

プロトタイプ版

手動テスト中心
- 開発者による動作確認
- 主要機能の目視確認
- アドホックなバグ修正
- 限定的なテストケース
単純なユニットテスト
- 一部コアロジックのみ
- 最小限のカバレッジ
- 基本的なアサーション
テスト環境
- ローカル環境のみ
- 単一ブラウザでの確認
- 限定的なデータセット

製品版

自動テスト体系
- ユニットテスト
- 統合テスト
- E2Eテスト
- パフォーマンステスト
- セキュリティテスト
品質基準の設定
- カバレッジ目標
- パフォーマンス基準
- コード品質メトリクス
- テスト優先度の定義
包括的なテストシナリオ
- 正常系/異常系
- エッジケース
- 並行処理
- 負荷状況
- データバリエーション
テストインフラ整備
- CI/CD連携
- テスト環境の自動構築
- テストデータ管理
- 結果レポーティング

コード構造

プロトタイプ版

単純なアーキテクチャ
- モノリシックな構造
- シンプルなファイル構成
- 最小限のディレクトリ階層
直接的な実装
- ハードコードされた値
- グローバル変数の使用
- 単純な関数群
限定的な抽象化
- 基本的なクラス設計
- シンプルなインターフェース
- 直接的な依存関係

製品版

堅牢なアーキテクチャ設計
- クリーンアーキテクチャ
- レイヤード構造
- ドメイン駆動設計
- マイクロサービス分割
モジュール化された実装
- 明確な責務分離
- 疎結合な設計
- 再利用可能なコンポーネント
- プラグイン機構
依存性管理
- 依存性の注入
- インターフェース駆動
- 抽象化レイヤーの定義
- 循環参照の排除
設計原則の適用
- SOLID原則準拠
- デザインパターンの活用
- テスタビリティの考慮
- 拡張性の確保

エラーハンドリング

プロトタイプ版

基本的なエラー対応
- 単純なtry-catch処理
- 標準エラーメッセージの表示
- コンソールへのエラーログ
- 最小限の例外クラス
シンプルなエラー通知
- 技術的なエラーコード表示
- システムメッセージの直接表示
- 単一言語のメッセージ
- 固定フォーマット
限定的な復旧処理
- エラー発生時の処理中断
- 単純なリトライ機構
- 手動でのリカバリー対応
- 基本的なクリーンアップ処理

製品版

体系的なエラー管理
- エラー階層の設計
- カスタム例外クラス
- 詳細なエラーコード体系
- 環境別のエラー設定
ユーザーフレンドリーな通知
- 分かりやすいエラーメッセージ
- 多言語対応メッセージ
- コンテキストに応じた表示
- 対処方法のガイダンス
高度な復旧機構
- 自動リトライ処理
- フォールバック機能
- トランザクション制御
- 状態復元機能

ドキュメント

プロトタイプ版

最小限のREADME
- セットアップ手順
- 基本的な使用方法
- 主要な機能の説明
シンプルな構成図
コードコメント
- 重要な処理のみ
- 一時的なメモ
動作確認シナリオ
- 基本パターンのみ
- 手動実行手順

製品版

システム設計書
- アーキテクチャ設計
- データモデル設計
- セキュリティ設計
- 性能要件と対策
API仕様書
- OpenAPI/Swagger準拠
- エラーハンドリング
- リクエスト制限
- バージョニング
運用ドキュメント
- 環境構築手順
- デプロイメントガイド
- 監視設定
- バックアップ/リストア
- インシデント対応
開発ガイド
- コーディング規約
- ブランチ戦略
- レビュー基準
- テスト方針
保守性向上
- トレーサビリティの確保
- 変更履歴の管理
- レビュー記録
- 技術的負債の管理

インフラストラクチャ

デプロイメント

プロトタイプ版

手動デプロイ
単一環境での直接更新
基本的なビルド/テスト

製品版

ビルド/テスト自動化
依存関係チェック
- セキュリティスキャン
- コード品質チェック
- テスト自動実行
- アーティファクト管理
デプロイメント戦略
- ブルーグリーンデプロイメント
- カナリアリリース
- フィーチャーフラグ制御
- ロールバック手順
データベース管理
- マイグレーション自動化
- バージョン管理
- ダウンタイムゼロ更新
- データバックフィル戦略
- スキーマ変更の後方互換性確保
環境管理
- 環境固有の設定管理
- シークレット管理
- 環境変数制御
- インフラのコード化（IaC）
監視・検証
- デプロイ前後の健全性チェック
- パフォーマンス変化の監視
- エラーレート監視
- ログ分析
リリース管理
- リリースノート自動生成
- 変更履歴管理
- 依存関係のバージョン管理
- ホットフィックス手順
コミュニケーション
- ステークホルダーへの通知
- メンテナンス告知
- インシデント対応プロセス
- チーム間連携
復旧計画
- 緊急ロールバック手順
- データベース復旧手順
- 障害時の切り戻し手順
- 障害報告テンプレート

スケーリング

プロトタイプ版

単一サーバー構成
- モノリシックな展開
- 垂直スケーリングのみ
- 単一データベース接続

製品版

スケーラブルなアーキテクチャ
- マイクロサービス化
- コンテナ化対応
- サーバーレス構成
- 分散データベース
- キャッシュ層の分離
自動スケーリング機構
- 水平スケーリング
- 負荷ベースの自動拡張/縮小
- リソースの動的割り当て
- スケーリングポリシーの最適化
- バースト対応
高可用性設計
- 複数リージョン展開
- 災害復旧対応
- フェイルオーバー機構
- セッションレプリケーション
- データ同期機構
パフォーマンス最適化
- CDN活用
- ロードバランシング
- コネクションプールの最適化
- クエリ最適化
- リソースの使用効率化

セキュリティ

プロトタイプ版

基本的なアクセス制御
- シンプルなファイアウォール設定
- デフォルトセキュリティグループ
- 標準的なSSL/TLS設定
限定的な認証管理
- 共有アカウントの使用
- 基本的なパスワードポリシー
- 手動での認証情報管理
最小限の監視
- 基本的なメトリクス収集
- シンプルなアラート設定
- ログの一時保存

製品版

多層防御アーキテクチャ
- DMZの適切な構成
- セグメント分離
- WAF/IDS/IPSの導入
- DDoS対策
アクセス制御の強化
- ゼロトラストアーキテクチャ
- IAMポリシーの細分化
- 最小権限の原則適用
- 特権アクセス管理
ネットワークセキュリティ
- VPCフローログの有効化
- プライベートサブネット構成
- 暗号化通信の強制
- エンドポイントポリシー
認証基盤の整備
- ID管理の一元化
- MFAの強制
- 証明書の自動更新
- シークレット管理
インフラストラクチャの保護
- サーバー強化（ハードニング）
- 脆弱性スキャン
- パッチ管理の自動化
- コンテナセキュリティ

データ管理

ファイル保存

プロトタイプ版

ローカルストレージへの直接保存
単一サーバーでの管理
シンプルなディレクトリ構造
基本的なパーミッション設定
ファイル名の重複チェックなし
メタデータ管理なし

製品版

クラウドストレージ活用
- AWS S3/Azure Blob/GCS等の利用
- ライフサイクルポリシーの設定
- アクセス権限の詳細設定
CDN連携
- キャッシュ設定の最適化
- エッジロケーションの活用
堅牢なファイル管理
- 一意なファイル識別子の発行
- メタデータ/タグ管理
- バージョン管理
- 暗号化保存

バックアップ戦略

プロトタイプ版

バックアップなし、または手動バックアップのみ
単一の保存先
フルバックアップのみ
リストア手順未整備

製品版

定期バックアップ
- インクリメンタル/フルバックアップの併用
- 世代管理
- 地理的冗長化
リストア体制
- リストア手順の文書化
- リカバリポイント目標(RPO)の設定
- 目標復旧時間(RTO)の設定
- リストアの定期テスト
運用管理
- バックアップ監視
- 自動化されたバックアップ検証
- 暗号化バックアップ

データ削除ポリシー

プロトタイプ版

物理削除のみ
削除ログなし
一括削除機能なし
削除条件の未整備

製品版

論理/物理削除の使い分け
- 論理削除によるデータ復元可能性の確保
- カスケード削除の制御
- 定期的な物理削除バッチ
保持期間管理
- データ種別ごとの保持期間設定
- 法的要件に基づく保持ルール
- 自動アーカイブ/削除
削除操作の管理
- 削除承認フロー
- 削除操作の監査ログ
- バッチ削除の影響範囲確認
- 誤削除の防止機構

サービス統合

外部サービス連携

プロトタイプ版

最小限のAPI連携

製品版

CRM連携
マーケティングツール連携
ソーシャルメディア連携
メール配信サービス連携
チャットボット連携
アナリティクスツール連携
エラートラッキングサービス連携

運用監視

ログ出力

プロトタイプ版

console.log/標準出力のみ
ファイルへの単純な書き出し
デバッグ用の詳細ログ
ログローテーションなし
タイムスタンプのみの最小限の情報
環境変数による単純なログレベル切り替え

製品版

構造化ログ
- JSON形式での出力
- タグ/メタデータの付与
- リクエストIDによる追跡
- ユーザーIDの関連付け
ログレベル制御
- 環境ごとの出力レベル管理
- 動的なログレベル変更
- カテゴリ別のログレベル設定
- サンプリングレート制御
集中管理
- ログ集約基盤との連携
- 分散トレーシング
- リアルタイムモニタリング
- ログの長期保存と検索
運用管理
- ログローテーション
- 容量管理
- 自動アーカイブ
- センシティブ情報のマスキング
- パフォーマンス影響の最小化

モニタリング

プロトタイプ版

プロセス稼働確認
メモリ使用量の確認
単純なエラー検知

製品版

システムメトリクス収集
- CPU/メモリ/ディスク使用率
- スレッド数、ヒープサイズ
- ガベージコレクション統計
- ネットワークI/O
- コネクションプール状態
アプリケーションメトリクス
- リクエスト数/レスポンスタイム
- エラーレート/ステータスコード
- キャッシュヒット率
- ジョブ実行状況
- カスタムメトリクス
アラート管理
- しきい値ベースのアラート
- 異常検知ベースのアラート
- アラートの重要度設定
- 通知チャネルの制御
- エスカレーションルール
可視化・分析
- リアルタイムダッシュボード
- トレンド分析
- 相関分析
- カスタムレポート
運用管理
- メトリクス保存期間管理
- アクセス制御
- バックアップ
- 監査ログ

アナリティクス

データ収集

プロトタイプ版

基本的なアクセスログのみ

製品版

ユーザー行動分析
コンバージョントラッキング
ファネル分析
A/Bテスト機能
ヒートマップ分析
リアルタイムモニタリング
カスタムイベントトラッキング
プライバシー設定に基づくデータ収集制御

コンプライアンス

法令対応

プロトタイプ版

なし

製品版

包括的な法令遵守体制
- GDPRコンプライアンス
  - データ保護影響評価
  - 越境データ移転対応
  - データポータビリティ
- 個人情報保護法対応
  - 利用目的の明確化
  - 適切な同意取得
  - 安全管理措置
  - 第三者提供制限
セキュリティ対策
- 暗号化要件への対応
- アクセス制御の厳格化
- 監査証跡の保持
- インシデント対応体制
運用体制の整備
- 内部規程の策定
- 従業員教育
- 委託先管理
- 定期的な監査
ユーザー権利対応
- 開示請求への対応
- 訂正・削除要求対応
- 利用停止手続き
- 苦情処理体制

ライセンス管理

プロトタイプ版

基本的な依存関係管理
- package.jsonでの記録
- 簡易的なバージョン固定
- オープンソースの利用確認
最小限のライセンス確認
- 主要ライブラリの確認
- 互換性の簡易チェック
開発環境での管理
- ローカル開発者の利用記録
- テスト用ライセンスの使用

製品版

包括的なライセンス追跡
- ソフトウェアライセンスの棚卸
- 商用ライセンスの取得管理
- サブスクリプション管理
- ユーザー数/接続数の監視
依存関係の管理
- サードパーティライブラリの追跡
- ライセンス条項の遵守確認
- 脆弱性スキャン連携
- バージョン更新管理
コンプライアンス対応
- ライセンス監査対応
- 使用許諾証書の管理
- 権利関係の文書化
- 輸出管理規制対応
運用管理体制
- ライセンス費用の予算管理
- 更新時期の管理
- 契約更新手続き
- 利用状況の可視化
セキュリティ管理
- ライセンスキーの安全管理
- アクティベーション管理
- 不正利用の防止
- 監査ログの保持

SEO対策

プロトタイプ版

基本的なメタタグのみ

製品版

構造化データ（Schema.org）の実装
パフォーマンス最適化（Core Web Vitals対応）
適切なURLルーティング設計
サイトマップXML生成
robots.txt最適化
OGP（Open Graph Protocol）対応
モバイルフレンドリー対応
ページネーション最適化
多言語SEO対応

収益化

課金/決済機能

プロトタイプ版

モック決済またはテスト用決済のみ

製品版

複数の決済手段対応（クレジットカード、電子マネー、キャリア決済など）
定期課金システム
請求書発行機能
税率管理（国際対応）
返金処理決済エラーハンドリング
不正利用検知
決済情報の暗号化
PCI DSS準拠（必要な場合）

広告管理

プロトタイプ版

なし

製品版

複数の広告ネットワーク対応
広告表示の最適化（レスポンシブ対応）
広告ブロッカー検知
広告パフォーマンス測定
ユーザーセグメントに基づく広告出し分け
広告在庫管理
広告収益レポーティング
プライバシーポリシー対応

おわりに

いかがだったでしょうか。製品版は開発するにあたって考慮すべき項目が沢山あることを、何となくご理解いただけたら嬉しいです。

製品版開発の場合、当然アプリケーションの提供機能と併せて上記で挙げた項目を対応するわけですから、やはり 「システム開発は難しい」 と言わざるを得ません。

また、上記の内容をエンジニア１人で全てカバーすることは現実的でないことも想像できるかと思います。

どれ程優秀な大工でも麻布台ヒルズを一人で建築出来ないように、プロ品質のアプリケーションも、エンジニア１人で作り上げることは難しいです。
そのようなアプリケーションは、複数人のエンジニア・ステークホルダーが互いに協力し合って初めて開発できるものだと私は考えています。

その意味では、 システムはコミュニケーションで作り上げる ものであり、エンジニアは技術的知見や実装力を磨くだけでなく、やはりコミュニケーション能力を高める努力をすべきだと私は思います。

最後に、上に書いたプロトタイプ版と製品版の差を、生成AIは埋めることが出来るのか？についての私見を述べたいと思います。

果たしてこの先、プロンプトと仕様を書いたyamlファイルを生成AIに渡せば、誰でも簡単にSaaSをリリース出来る日が来るのでしょうか？

私は来ないと思います。

そのことは、上に挙げた製品版レベルの対応を全て生成AIにやらせようとするとどうなるか？を考えれば納得していただけると思います。

システム開発の難しさは要件の数×各要件の複雑性で大体決まります。
上に挙げた対応を守らせた上でアプリケーション機能の実装を行う場合、システムの複雑性が爆発的に跳ね上がり、生成AIの計算量の上限を余裕で超えると私は思います。

また、生成AIは「文脈」の理解と記憶が苦手です。
多くの人が、やり取りが長くなるにつれて生成AIの回答の質が落ちる経験をしていると思います。

一般的なシステム開発は技術的な要件だけで物事が進む訳ではなく、顧客やユーザーからの要求、要求内容の変化、法令改正への対応、予算・納期といったプロジェクト制約など、人間側の都合も大きく影響します（むしろ、そちらの方がウェイトが大きいです）。

そういったビジネス面での膨大かつ複雑な文脈を生成AIにインプットし、理解させて、それに則ったコードを生成させることは難しい(現実的ではない)と私は考えます。

最大の理由は、生成AIはコミュニケーションを担えないことです。

システム開発は顧客含むステークホルダーとのコミュニケーションを通じて推進していくものですが、生成AIはステークホルダーとの対外的なコミュニケーションを担当することが出来ません。敢えて意地悪な書き方をすると、末端の作業者との1on1のやり取りしか出来ない存在です。
つまり、生成AIには本質的にシステム開発を推進させる力がありません。

そもそも、生成AIはコミュニケーションが取れる存在ではありません。「報告・連絡・相談」の中で、報告(＝自分の作業結果の共有)しか行うことが出来ません。不明瞭な仕様についての質問や、要求事項の確認、現状の課題についての相談などを自ら行うことはありません。
ただひたすら、プロンプトの内容を愚直に、局所最適的に実装することのみ行います。

そのため、生成AIは開発メンバーのスキルの代替にはなり得ても、開発メンバーそのものの代替にはなり得ない存在です。
このことは、「スキルは優秀だが連絡も相談もしてこない部下と一緒に働きたいか？」を考えると分かりやすいと思います。

まとめると、

製品版システム開発における考慮事項は膨大で、生成AIのみでは対応しきれない
生成AIはコミュニケーションを担えない

この２つが、私が誰でも簡単にシステム開発出来るようになると思わない理由です。
エンジニアは引き続き、技術力の研鑽と泥臭い戦いが求められると私は思っています。

ここまで読んで下さりありがとうございました。
日本のIT産業に光あれ！

Appendix

下の記事は、個人開発において遵守すべき法令等にも触れていて非常に有益でした。
上のリストでコンプライアンスについても挙げたので共有させていただきます。

また、下の方は生成AIを使ってシステム開発の難しさと真っ向勝負しているな、と私が感じているアカウントです。

いかにして製品版クオリティのシステムをAI活用して最速で作るか？について真摯に考えている方だと私は思ってます。

実務における生成AI活用方法(=AI駆動開発)についてご興味ある方はフォローをおススメします。