業務システムこそプロトタイピングは効果的な理由

プロトタイピングは万能の手法ではなく、対象領域によって効果の大きさがかなり変わります。結論から言うと、社内業務システムや業務委託先向けのBtoBシステムのような「業務システム」は、プロトタイピングと特に相性のいい領域です。理由は、そこにある不確実性の種類にあります。

業務システムの不確実性は「ビジネスロジックの認識合わせ」に集中している

業務システム開発で要件が食い違う原因の大半は、技術的に難しいからではありません。「承認フローで差し戻しが発生したときステータスをどこに戻すか」「担当者が退職した場合、進行中の案件はどう引き継がれるか」といった、業務担当者の頭の中にしかない暗黙のルールを、発注側と開発側がどこまで正確に共有できているか、という認識合わせの問題です。

こうした業務ルールは、既に業務が回っている以上、現場の担当者・管理部門・経営層といった既知のステークホルダーの中に必ず答えが存在します。つまり不確実性の性質は「未知の情報を新たに発見する」ことではなく、「既に存在する知識をどれだけ正確に引き出せるか」です。この種の不確実性は、動くものを見せて反応を引き出すプロトタイピングと非常に相性がいいものです。

仕様書よりも「動く画面」の方が正確に伝わる

ステータス遷移や承認フローのような業務ロジックは、文章の仕様書として書き出すと分量が膨らみ、読み手によって解釈がぶれやすくなります。

type OrderStatus =
  | 'draft'
  | 'pending_approval'
  | 'approved'
  | 'rejected'
  | 'in_progress'
  | 'completed'
  | 'cancelled';

こうした状態遷移は列挙してしまえば技術的にはシンプルですが、「却下されたらdraftに戻すのか、それとも却下専用の状態を経由するのか」「in_progressの途中でキャンセルは可能か」といった枝分かれは、文章の仕様書だと読み飛ばされがちです。一方、実際に画面を操作して「却下ボタンを押すとどうなるか」を目の前で確認してもらうと、業務担当者は仕様書を読むよりずっと速く、かつ正確に「それは違う、却下されたら経理の確認待ちに戻るはず」といった具体的な指摘を返してくれます。プロトタイピングが有効なのは、この「動くものを見せた方が、文章より正確なフィードバックが速く返ってくる」という性質を、業務システムの持つ閉じた・列挙可能なドメインが最大限に活かせるからです。

逆に、この前提が崩れる領域もある

この効果は、「答えとなる業務知識が既に組織の中に存在している」という前提の上に成り立っています。裏を返せば、答えがまだ組織のどこにも存在しない——市場に出してみないと誰も分からない——という種類の不確実性に対しては、同じ理屈は通用しません。この違いについては別の記事で扱います。

まとめ

業務システム開発の不確実性の正体は、多くの場合「未知の発見」ではなく「既知の認識合わせ」です。既知の知識を持つ既知のステークホルダーが相手であれば、文章の仕様書より動くプロトタイプを見せる方が、正確なフィードバックを速く引き出せます。プロトタイピングが業務システムと特に相性がいいのは、この閉じたドメインの認識合わせという構造に、手法の強みがそのまま噛み合うからです。