顧客テストにはあって、仕様決めのときにはないもの

SD

簡単そうで、なかなか答えがでない問題。

ただ、ここで最近の興味の対象となるのは、「なぜ顧客は仕様を分かっている（だからテストでは指摘ができる）のにそれを完全に正確に伝えられないのだろう？」というもの。言い換えると、「顧客は欲しいシステムの必要な動作を本当は知っている。仕様を決めている時点でそれを正確に引き出すにはどんなサポートができるのだろう？」という疑問だ。

さらに質問形式を続けると、「顧客テストにはあって、仕様決めのときにはないものはなんだろう？」「その本質的な違いはどこにあるんだろう？」

お客さまですらシステム全体のあるべき仕様を正しく把握していることは稀であって、だからこそ要件定義というフェーズがあったり、業務ごとに担当者を分けたりするし、決めたことを紙にまとめる。しかしそれでも、仕様は漏れる。
ぼくは「仕様決めのときになくて、顧客テストのときにある」のは「動くアプリケーション」と「それまでのコミュニケーションで培ってきた信頼関係」だと思う。受け入れテストといえど、純粋に仕様から落とし込むというよりは、できあがってきたアプリケーションの動作を開発チームとのコミュニケーションを通じてすり合わせられている。その上で、実際に動くアプリケーションを使って検証するから、この仕様は正しいと判断できるのだと思う。
だから、ぼくは「顧客テストを短いサイクルタイムで複数回を行うことでリスクを軽減するというアプローチ」のほうが、特に初めてお付き合いするお客様だったり、忙しいお客さまの場合、そして新規開発のシステムの場合は確実で、お互いにとってメリットがあると思う。動く物のレビュー＆フィードバックというコミュニケーションを増やすチャンスが多いからだ。
逆に、お付き合いが長かったり、そのシステムに専念できるお客さまだったり、既存システムのリプレース案件の場合は、仕様決めの段階できっちりと詰めるアプローチが有効だと思う。特に、仕様のほとんどが計算式な金融系のシステムなんかはそうだろう。重要な仕様は事前に十分に検証でき、結果的にリスクも下がると思う。
いずれにせよ、仕様決めのときにお客さまにサポートしてあげられるのは、「何故、そのような仕様にするのですか？」と、確認を繰り返しすことだろうと思う。ここをはずさなければ、後々細かい齟齬があったとしても、ぼくらの提供するサービスの本質的な価値は損なわないと思っている。
正しい仕様は、お客さまが最初から知っているわけではなく、開発チームのコミュニケーションを通じて生み出されるのだと思う。開発チームがITの知見をお客さまに提供することによって、よりよい業務やシステムに生まれ変わることも多いはずであり、だからこそぼくらはこの仕事にやりがいに感じるのだ。