仕様ミス、仕様取込漏れ

各社、各チーム、呼び方は色々あるでしょう。

　・仕様検討漏れ
　・仕様誤理解
　・仕様ミス
　・仕様取込漏れ
　・仕様検討不足

まぁとにかく、まとめて言ってしまえば「"仕様"を明確に定めることができないまま、次工程に進んでしまった」不良全般のことを指します。

細かいことを言えば上記で挙げた不良はそれぞれ意味が異なるもので、それぞれごとに対策や再発防止策も変わってくるのですが、あまり細かく分類しすぎると品質を「管理」することが冗長的になってしまい、本来の目的を見失ってしまいかねません。

プロジェクトマネジメントは「管理」することが目的なのではなく、「管理」という手段を以って、

　プロジェクトを安定的に成功させること、そのコントロール

が目的です。この大前提を見失わないようにしなければなりません。

また、中堅あたりまでのエンジニアの中には「仕様書」と「設計書」の違いだったり、「要件定義」と「基本設計」の違いを明確に理解していないまま開発する人も少なくありません。私がこれまでに在籍していた会社でもそうです。

そんな中から叩き上げでスライドしたマネージャーがマネジメントすれば、当然ながら超上流工程や上流工程で定めるべき「仕様」がなんなのか不明瞭なままプロジェクトが進行するケースも後を絶たなくなるのは自明です。

「仕様」とは、お客さまが製品やサービスなどに求められている条件のことです。国際規格的には『顧客の要求事項』とも言います。

仕様 - Wikipedia

私たちＢ２Ｂでソフトウェア開発を担う企業では特に、作るものに関して要求される特定の形状・構造・寸法・成分・精度・性能・製造法・試験方法などの細やかな定義や規定を明確にしたもののことを「仕様」と呼ぶことが多いかも知れません。

製品specのことを仕様と呼びますからこれはこれで間違いではありません。

ちなみに、ＩＴ業界では「お客さまが仕様を提示してくれない」なんて理由で、スケジュール遅延などを平気でしてしまうエンジニアやプロジェクトチームが存在しますが、これも理解が伴っていない証拠です。

お客さまが「仕様」を提示してくれることなんてほとんどありません。

お客さま…ことユーザーに限って言えば、そこまでＩＴリテラシーに詳しいはずがないからです（詳しければ、自分たちで作った方が正確に要望通りのものが作れるでしょうし）。

お客さまが提示するのは「要求」です。

「要求」はたいていの場合

　「現状の不満」と「未来の理想」

のギャップを推し量って捻出されるものです。その「要求」をＩＴシステムとして解決するためにエンジニア側の手によって提示する実現手段や、実現した結果の理想像こそが「仕様」であり「要件」なのです。

つまり「仕様ミス」や「仕様検討漏れ」と言うのは、

お客さまの提示してきた「要求」を理解できないまま、あるいは汲み取れないまま設計／製造してしまって、本当にお客さまが望んでいる製品やサービスにはなっていない状態

の不良を指しているということです。基本的にはエンジニア側の責任となっていることは多いのではないでしょうか。

条件/原因

まず問題を「問題だ」と認識した時、その原因を特定するためいろいろ調査すると思いますが、「仕様のミス」「仕様の検討漏れ」は次の条件のいずれかを満たしたときにそう断定します。

　・ 要件/仕様に紐づく「要求」が存在しない
　・ 要求に紐づく「要件」「仕様」が存在しない
　・ お客さまの要求そのものや背景を理解する力量が不足している

これら超上流工程では「絶対解」や「唯一解」がない…すなわちアルゴリズムだけでは解決しない工程だけに、なによりもお客さまの「要求」だけでなく、そういった要求が出てくるほど悩まれている現状や業務内容をしっかりと理解しておかないと、正しい品質の確認ができません。

そのため、この工程は機械的なチェックだけでなく、レビュアーとなる人の知識量や理解力も大きく品質に影響することになってきます。よって、当該工程ではなく、次工程以降で検出された場合などは、

　・ レビュアーの力量またはレビュー自体が不足している

と言った原因も見逃してはいけません。

対策

対策するのは、次の通りです。