「プロにお任せします」と、後から「ここはこうして欲しい」を両立させる

「プロにお任せします」は失敗の原因とよく言われます。でも、経験のない企業がどうすれば良いか分からないのは当然です。問題は「お任せ」ではなく、進め方にあります。

リリース時に必ず出てくる「ここはこうして欲しかった」

システムが完成して初めて触ったとき、「ここはこういう操作にして欲しかった」「この画面、もう少し分かりやすくできませんか」という声が出てくることがあります。

これは発注側が悪いわけではありません。動くものを見て初めて気づくことは、システム開発では当たり前のように起きます。人は、抽象的な仕様書を読んで完成形を正確にイメージすることは苦手です。実際に触ってみると「なんか違う」という感覚が生まれます。

問題は、完成後にそれが発覚することです。完成後の修正は、開発中の修正に比べてコストが大きくなります。

こうした失敗の対策として、「要件の明確化が大切」「コミュニケーションをしっかり取りましょう」とよく言われます。

その通りなのですが、システム開発の経験がない企業にとって、これは難しい注文です。「そもそも何をどう明確にすればいいのか」が分からないからです。

書籍や解説動画では「業務要件を文章化する」「業務を洗い出す」といった説明があります。ただ、具体的にどんな粒度で、どこまで書けばいいのかは教えてくれません。「当社のこの業務、文章化するとしたら何ページになる？」という問いに答えてくれる資料はほとんどありません。

「業務の細かいところまで分からないから、プロに任せる」という判断は、実は合理的です。

ベンダーはシステムを作る専門家です。業務の詳細を把握した上で、最適な構成を提案してくれる——そういう期待を持つのは自然なことです。

失敗の本当の原因は「プロにお任せします」という姿勢ではなく、「お任せしたまま、確認の機会がなかった」プロジェクトの進め方にあります。完成するまで発注側が実物を見られない進め方では、どれだけ要件を文章化しても、最終的に「ここはこうして欲しかった」は出てきます。

完全型プロトタイプ開発では、本番と同等の機能と画面を持つプロトタイプを先に作ります。

このアプローチが「プロにお任せします」と「ここはこうして欲しい」を両立させる理由は、確認のタイミングにあります。

まずベンダーがプロトタイプを作ります。発注側は動くものを実際に触ります。触ってみて初めて気づいた「ここはこうして欲しい」を、そのまま伝えます。それをプロトタイプに反映して、また確認する。このサイクルを本開発の前に回します。

業務要件を文章化できなくても大丈夫です。実物を触りながら「違う」「これで合ってる」を判断するだけでいいからです。言葉にできない感覚的なフィードバックが、そのまま要件になります。

「プロにお任せ」した結果として出てきたプロトタイプを確認し、「ここはこうして欲しい」を伝え、修正してもらう。これが、両立の正体です。完成後ではなく、本開発の前にこのやり取りを済ませておくことで、「完成してから気づく」を防げます。