【ソフトウェア開発】オーバースペック

もちろん、【遊戯王】とは全く関係ありません。

ソフトウェア開発に関わる方の中で、このような言葉を聞いたことがある方はいらっしゃるでしょうか。

和製英語ですが、日本語では「過剰性能」と言います。

システムやソフトウェアの利用者が求めるよりも、更に高く持っている性能と、その性能を持つ機械装置の総称をいいます。仮にそれらの機能や性能が、利用者の邪魔でないものであったとしても、これはソフトウェア品質の観点から言えば

　バグ（不良／欠陥）

です。少なくとも、Ｂ２Ｂで注文を請けてから作成するソフトウェア開発においては、最初に見積ったコストやスケジュールは、注文内容に則したものであるはずだからです。

もしも、コストにもスケジュールにも一切影響を与えずに、オーバースペックの機能を盛り込んだとしましょう。ひょっとしたらお客さまは喜んでくれるかもしれませんね。

でも、本当にそれでいいんですか？

見積り時には、要求を満たす活動のために「必要なコスト」「必要なスケジュール」を見積もっていたはずなのに、その枠の中で収まって過剰性能を実装してしまった…と言うことは、言い換えれば

　ボッタクリ

しているということになりませんか？
もしも、コストやスケジュールに影響を与えてまで、過剰性能を盛り込んだとしたら、それはもう既に"マネジメント品質"上の不良と言えるでしょう。

Ｂ２Ｂでソフトウェア開発に従事することの『目的』は１つ。

　お客さまの"現状"困っている状況に対して、
　求める"理想"を実現し、現状の課題を解決する

ことです。それ以上でも、それ以下でもありません。そうすることで社会的に貢献するのが、ＩＴ企業のアイデンティティです。にもかかわらず、その目的に合致しないオーバースペックを盛り込むことは、顧客要求事項（仕様）を満たしているとは言えないのです。

たとえば、

　「システムとして品質を高めるために、
　　われわれが考えて便利な機能やレポートを開発に盛り込んだ」

と言い訳したとしても、それは品質を高めていることになるのでしょうか？

答えはNoです。

このような機能に限って実装が困難であることが後から判明して、苦労したことのある方はいないでしょうか。そうなってしまっては本末転倒以外のなにものでもありません。ビジネスにおいて、お客さまが求めていることはあくまでも『要求と一致したもの』であり、それ以上になることもそれ以下になることもありません。

結果的に、妥協することはあっても、お客さまが求めるものは、常に要求と一致するということなのです。

仮に、要求をすべて満たし、そのうえで便利な機能を実装したとします。
そこにかかった作業工数は？

余剰に請求していたのだとしたら、見積り精度は低くないですか？
追加で請求するとしたら、お客に事前に断りも入れずにすることですか？
請求しなかったとしても人件費はかかるわけですから、
確信犯的に会社に迷惑をかけていませんか？
請求させなかったのだとしたら、コンプライアンスに違反しませんか？

ということになります。

エンジニアとして自己満足はできるかもしれませんが、どう逃げ回ったところで社会に迷惑をかけることは避けられません。このことは、プロジェクトマネジメントの国際規格でもあるPMBOK（ISO 21500）の中でも「余計なこと」を意味する“金メッキ“（Gold Plating）として扱われており、避けるべきとものとされています。

また、PMBOKでは、品質とグレードの違いについても理解しておく必要があるとしています。低品質は問題ですが、低グレードは必ずしも問題とは限りません。これは、パソコンやテレビ、日用品などをイメージすると理解しやすいでしょう。

顧客は必ずしも高機能なものを要求しているとは限らず、必要最小限の機能やスペックで十分なこともあります。しかし、すぐに壊れてしまうようでは問題となるわけです。

たとえば、普段使いのバッグが欲しいだけなのに、金銀宝石があしらわれ、いかにもひったくりしてくださいと言わんばかりのバッグで、その辺のスーパーに買い物に行きたくなりますか？

オーバースペックは、逆に利用者を困らせるだけで終わることが多いのです。良かれと思ってやったことが、周囲に迷惑をかける…なんてことは、よくあることなのです。

仕事と趣味は異なります。

趣味の延長線上に仕事があってもかまいませんし、その方が幸福度があがるなんてことも言われていますが、だからと言って、自らの自己満足のため"だけ"に、会社やお客さまを含む社会に迷惑をかけていい道理は絶対に存在しません。

本当に重要なのは

　「品質とは成果物が要求と一致しており、使用に適していること。
　　そしてそのための活動や価値(相場)に対する適正価格で
　　ビジネスが成立していること。」

ただそれだけなのです。エンジニアである前に、一人のビジネスパーソンであることを忘れないようにしなくてはなりません。