なぜ「バグゼロ納品」は品質の証明にならないのか
テストが証明するのは、システムが仕様どおりに動くことです。仕様そのものが業務に合っているかは、証明していません。
この2つは別のことであり、その差が生まれる場所で多くのプロジェクトが失敗します。現場で繰り返し起きる3つの型があります。
- ロジックは正しいが、操作が増えた。従来3ステップで終わっていた業務が8ステップになりました。現場は結局Excelに戻ります。
- 仕様どおりだが、実データで壊れた。仕様はきれいなサンプルデータを前提に書かれていました。実データには空欄、重複コード、特殊文字があり、初週で処理が止まります。
- 機能は正しいが、目的が違った。ご要望は「Excel出力ボタン」でした。本当の目的は毎週月曜の本部向け報告書の作成でした。ボタンは正しく実装され、報告書作成の負担は変わりません。
3つとも検収は通ります。そして3つとも失敗したプロジェクトです。
使われないシステムはどれだけの損失を生むのか
使われないシステムの損失は、初期開発費だけではありません。稼働している限り、損失は毎日発生し続けます。
社内システムの場合、損失は時間として現れます。以下は自社の数値で試算していただくための計算式です。
| 変数 | 仮の値 | 結果 |
| 1人あたり1日の追加所要時間 | 30分 | — |
| 利用者数 | 100名 | 1日あたり50人時 |
| 年間稼働日数 | 250日 | 年間12,500人時 |
これは調査データではなく、試算の枠組みです。自社の実数に置き換えてご確認ください。多くの場合、想定より大きくなります。
顧客向けアプリケーションの場合、損失は各画面遷移と読み込み待ちの中に分散します。問題は、この損失がどの報告書にも現れないため、誰の責任にもならない点です。
代理店・システムインテグレーターの場合、損失は信用として現れます。「動くが結果が出ない」成果物を納品したとき、エンドクライアントは戻ってきませんし、理由も告げません。
受託開発の品質はどの指標で測るべきか
受託開発の品質は、4つの指標を併用して測ります。1つの指標だけでは、最も危険な失敗——仕様どおりだが使われていない状態——を検出できません。
| 指標 | 定義 | 測定者 | 頻度 |
| 検収時の不具合密度 | 検収時に検出した不具合数 ÷ 規模 | 開発側 | 工程末 |
| 本番流出不具合率 | 本番で発見した不具合数 ÷ 全不具合数 | 開発側 | スプリントごと |
| 業務完了率 | 業務の完了件数 ÷ 開始件数 | ログから取得 | 週次 |
| 利用継続率 | 90日後の稼働ユーザー数 ÷ 付与アカウント数 | 双方 | 月次 |
前半2つは開発側の指標です。後半2つは本番稼働後にしか測れません。多くの契約にこの2つが入っていない理由がここにあります。
実務上重要な点を1つ。計測用のログ設計は、リリース前に組み込む必要があります。リリース後に追加すると比較対象となる初期データが失われ、以降の改善効果を証明できなくなります。
VAONはどのように品質を担保しているのか
VAONは3層のレビュー体制を採用しています。各層は、前の層では見えない種類の不具合を捕捉します。
| 層 | 実施者 | 捕捉する不具合 |
| ① 受入基準に基づくセルフチェック | 実装担当者 | 合意した受入基準との差異 |
| ② 開発者クロスレビュー | 当該箇所に関与していない開発者 | ロジックの誤り、重複、例外処理の欠落 |
| ③ 業務観点での検収 | BrSE（Bridge System Engineer・ブリッジSE） | コードは正しいが業務が成立しない状態 |
決定的なのは第3層です。第1層と第2層はシステムを仕様と照合します。第3層はシステムを実際の業務と照合します。業務と技術の両方を理解する人材が必要なため、多くのオフショア体制ではこの層が省略されています。
あわせて、前述の4指標を定例レビューでお客様に提示します。数値が芳しくない場合も同様です。早期に把握した悪い数値は、後から判明する場合よりはるかに安く済みます。
保証（瑕疵対応）と改善はどう違うのか
保証と改善は範囲が異なります。この2つを契約上で切り分けていないことが、納品後の紛争で最も多い原因です。
| 保証（瑕疵対応） | リリース後の改善 | |
| 対象 | 契約した仕様との差異 | 仕様は正しいが、実利用から見て変更が必要な事象 |
| 費用負担 | 開発側 | 事前の取り決めによる。契約時に明記が必要 |
| 判断根拠 | 仕様書 | 実利用データと利用者フィードバック |
VAONは、上限工数を明記したうえで、リリース後の改善サイクル1回を契約範囲に含めます。最初の事象が発生した時点で範囲を議論する必要がなくなります。
契約前に開発会社へ確認すべき5つの質問
以下の5問は、VAONを含むどの開発会社にもお使いいただけます。いずれかで曖昧な回答が返る場合、それ自体がリスクの兆候です。
- 直近プロジェクトの本番流出不具合率の実績値はいくつですか。
- 受入基準は御社が書きますか、当社が書きますか。
- リリース後の改善は契約範囲に含まれますか。上限工数はどの程度ですか。
- 本番障害の発生時、誰が何分以内に一次対応を開始しますか。
- テストケースは受入基準から生成しますか、既存コードから生成しますか。
特に5問目が重要です。コードから生成したテストは、そのコードが現在行っている動作を追認するだけであり、仕様との乖離を検出できません。
この測定が必要ないケース
測定が常に費用に見合うわけではありません。次の3つのケースでは不要です。
- 短期のPoC。目的は技術的な実現性の検証であり、運用成果ではありません。
- 利用者20名未満の社内システム。業務完了率と月次の定性フィードバックだけで実態は把握できます。指標を増やしても書類仕事が増えるだけです。
- ログへのアクセスやエンドユーザーへの接触が許可されない場合。データがなければ、どの指標も推測にすぎません。この場合は責任範囲を契約時に整理し直すべきです。
限界を明示することも品質保証の一部です。あらゆる状況で全てを測定できると約束する会社は、実際にその業務を経験していない可能性があります。
次の一歩
すでに納品済みのシステムについて、どのような成果が出ているか把握できていない場合、追加投資を判断する前に現状評価を行うことをおすすめします。
VAONは現状評価をご提供しています。現在お使いの受入基準の確認、既存データで即座に測定可能な指標の特定、次期開発の前にログ追加が必要な箇所の洗い出しを行い、短い報告書としてお渡しします。契約の義務は発生しません。
お問い合わせ：sales@ai.vaon.com.vn ／ Webサイト：https://vaon.com.vn/ja