開発会社に「品質は大丈夫ですか」と聞くと、たいてい「テストはきちんとやります」という答えが返ってきます。それ以上詰められないまま、テスト工程に入ってしまう。システム開発の品質で発注側が困るのは、確かめ方が分からないことではなく、そもそも何をもって合格とするかを決めていないことです。この記事では、品質を上げる話ではなく、発注側が合格ラインをどう決めるかに絞って整理します。品質管理の手法や資格の話は出てきません。
この記事のポイント
- 品質が高いは測れないが合格ラインなら決められる
- 合格ラインを渡さないと開発会社は金額の範囲で仮置きする
- 数字だけでは基準にならず、測り方と判定者まで決めて初めて使える
- 品質にはお金がかかるので全部を高くせず払う先を選ぶ
目次
システム開発の品質は発注側で決まる
「システム開発 品質」で調べると、品質管理の手法や指標、役立つ資格といった記事が並びます。どれも内容は正しいのですが、発注側が読んでも次に何をすればいいのかが出てきません。それらが開発会社の中の仕事について書かれているからです。
発注側の立場でまず押さえたいのは、品質という言葉のうち自分が関われる範囲がどこかということです。そこが決まると、自分がやるべきことが1つに絞れます。
品質は3つに分かれるが発注側が触れるのは1つ
ソフトウェアの品質は、よく3つに分けて説明されます。仕様どおりに動くかというプロダクト品質、開発の進め方が適切かというプロセス品質、使う人が満足しているかというサービス品質です。
このうち、プロセス品質は開発会社の内部の話です。レビューをどう回すか、テストの手順をどう標準化するかは、発注側が指図する領域ではありませんし、指図しても良くなりません。サービス品質は稼働してから時間をかけて分かるもので、これも事前に決められる性質ではありません。
残るのがプロダクト品質です。ここだけは、発注側が先に「どこまでできていれば合格か」を決められます。というより、発注側が決めないと誰も決められません。開発会社は自社の業務を知らないからです。上位に並ぶ品質管理の記事が自分向けに読めないのは、扱っている範囲が違うからだと考えると、すっきりします。
この切り分けは、開発会社との会話でも役に立ちます。プロセス品質について「レビューはどうしていますか」と聞くこと自体は悪くありませんが、答えを聞いても発注側には評価しようがありません。それより、自社の業務でどうなっていれば合格かを渡したほうが、相手も動けます。踏み込む場所を1つに絞ると、会話が噛み合うようになります。
品質が高いは測れないが合格ラインは決められる
「品質の高いシステムを作ってほしい」という要望は、実は何も伝えていません。高いというのは比較の言葉で、何と比べて高いのかが決まらないと意味を持たないからです。開発会社の側も、この言葉を受け取っても手の動かしようがありません。
一方で「合格ライン」は決められます。満たしたか満たさないかで判定できる形になっているからです。たとえば「検索結果が3秒以内に出ること」なら、測れば白黒がつきます。「速いこと」との違いはそこだけです。
発注側がやるのは、品質を上げることではありません。合格の位置を決めることです。上げるのは開発会社の仕事で、位置を決めるのは発注側の仕事、と役割を分けると話が早くなります。
決めないと開発会社が金額の範囲で仮置きする
合格ラインを渡さないとどうなるか。開発会社は見積もり金額で作れる範囲を、暗黙の基準として置きます。これは手抜きではなく、決まっていないと作業が進まないからです。
問題は、その仮置きが書面のどこにも出てこないことです。稼働してから「検索に10秒かかる」と言っても、契約時の金額にその前提は入っていません。相手からすれば「その要求は伺っていません」となり、追加の費用と期間の話になります。
私の感覚では、発注側が損をしているように見える場面の多くは、この形です。悪い会社に当たったのではなく、決めていなかったことが後から費用として出てきているだけ、というケースが少なくありません。
仮置きの中身は、見積もりの金額から逆算されます。同じ機能でも、1秒で返す作りと10秒かかる作りでは、設計もサーバー構成も変わり、金額が変わります。提示された金額に合わせて作る以上、どこかの水準は必ず下がっているということです。それが自社にとって困る場所かどうかは、発注側にしか判断できません。
品質が悪いと言えるのは先に決めていた場合だけ
ここがこの記事でいちばん伝えたいところです。事前に合格ラインが無いと、検収の場で言えるのは「思っていたのと違う」だけになります。これは交渉になりません。相手も「仕様書どおりに作りました」としか返せず、話が平行線になります。
逆に、1行でも書いてあれば話の形が変わります。「検索は3秒以内と決めましたが、10秒かかっています」と言えば、満たしたか満たさないかの話になります。感想のぶつけ合いではなく、事実の確認になるわけです。
決めるのは、契約前でも要件定義の途中でも構いません。テストが始まる前であれば間に合います。決めた内容を承認の場でどう使うかはシステム開発の検収の基準と期間の決め方で扱っているので、検収の進め方まで知りたいときはそちらを見てみてください。
システム開発の品質の合格ラインの引き方
ここからは具体的な手順です。難しい作業ではありませんが、抜けやすいところがあります。
合格ラインは4点セットで決める
数字を1つ書けば基準になる、と思われがちですが、それだけでは足りません。決めるのは次の4つです。
- 数字（どの値なら合格か）
- 測るサンプル（どのデータ量・どの条件で測るか）
- 判定する人（誰が測って誰が合否を言うか）
- やり直しの回数（超えていたら何回まで直すか）
「検索は3秒以内」とだけ書いた場合を考えてみます。データが100件のときなのか、3年分の50万件のときなのかで結果はまるで違います。開発会社が自社の検証環境で測るのか、こちらが本番相当のデータで測るのかでも変わります。そして超えていたときに、1回直して終わりなのか、合格するまで続けるのかが決まっていません。
4つそろって初めて、検収の場で使える基準になります。逆に言えば、この4つが埋まらない項目は、まだ基準として書けていないということです。
| 決める項目 | 曖昧な書き方 | 基準になる書き方 |
|---|---|---|
| 数字 | 速く表示される | 検索結果が3秒以内に出る |
| 測るサンプル | 通常の使用時 | 3年分50万件・同時20人の状態で |
| 判定する人 | 双方で確認 | 受注側が測定し情報システム担当が立ち会う |
| やり直しの回数 | 必要に応じて改善 | 基準を満たすまで、期限は稼働2週間前 |
確かめ方が書けない言葉は言い直す
要件の打ち合わせで出てくる言葉のうち、そのままでは基準にならないものがあります。速い、使いやすい、安定して、柔軟に。このあたりが代表です。共通しているのは、確かめ方が書けないという点です。
見つけたらその場で言い直します。型は決まっていて、「誰が」「何をするとき」「どうなっていれば合格か」の3つを埋めるだけです。使いやすい、なら「受付担当が来客登録をするとき、画面の移動3回以内で終わる」といった形になります。
現場に聞くと、返ってくるのは業務の事実です。「今は紙を見ながら3画面またいでいて、来客を待たせてしまう」といった話が出てきます。これを技術用語に翻訳しようとしなくて構いません。業務の言葉のまま書いたほうが、開発会社にも正確に伝わります。
言い直しがどうしてもできない項目が出てくることもあります。その場合は、無理に基準を作らずに「今回は決めない」と決めてしまうほうが健全です。決めなかったという記録さえ残っていれば、稼働後に問題が出たときも「決めていなかったので今から相談する」という筋が通ります。曖昧なまま合格基準として書いてしまうほうが、後で揉めます。
全部を高くせずどこに払うかを選ぶ
合格ラインを決めるときに一度は考えたいのが、水準とお金の関係です。品質にはお金がかかります。応答を速くするにはサーバー構成が変わりますし、止まらないようにするには二重化の費用が乗ります。
全項目を高い水準で要求すると、構成が過剰になって損をします。かといって全部を低くすると、稼働後に困ります。選び方の目安は「止まると誰がいつから困るか」です。受注の締め切りに直結する画面と、月に1回の集計画面では、かけるべきお金が違います。
この問いは、社内で聞くと答えが出やすいのが特徴です。「このシステムが半日止まったら、何が止まりますか」と現場の管理者に聞けば、具体的な業務名が返ってきます。半日止まっても翌日に取り返せる業務と、その日のうちに出荷が止まる業務では、扱いが変わって当然です。全部が同じくらい大事という答えが返ってきたときは、止まった時間を半日から3日に伸ばして聞き直すと差が出ます。
なお、機能の抜けは検収で気づけますが、遅さや止まりやすさは数か月使ってから表に出るので、直すのが一番高くつきます。性能や可用性の具体的な値をどう決めるかは非機能要件を発注側が決めるための考え方にまとめてあるので、数値を詰める段階になったらそちらが使えます。
見積もりに品質の費目が入っているか
合格ラインを決めたら、それを確かめる作業が見積もりに入っているかを見ます。性能テスト、負荷試験、セキュリティ診断。こうした作業は、実施するなら工数として積まれているはずのものです。
行が無ければ、実施しない前提の見積もりだということです。それ自体は悪いことではありません。予算の都合で外すこともあります。大事なのは、外れていることを知らないまま進めないことです。実施しないなら実施しない前提で合意して、稼働後に速度の問題が出たら別途対応する、と決めておけば揉めません。
冒頭の「テストはきちんとやります」という返事も、この見方で確かめられます。どのテストが費目として入っているかを聞けば、言葉ではなく数字で返ってきます。検収・受入テスト確認シートを使うと、決めた基準と受け取る成果物を承認前に突き合わせられます。テストの種類ごとに何を受け取れるのかはシステム開発テストの種類と発注側が受け取る証跡で整理しています。
- Q. 品質は大丈夫かと聞くと「テストはきちんとやります」と返ってきます。どう聞き直せばいいですか
- A. 品質という言葉を使わずに聞きます。「性能テストは見積もりのどの行に入っていますか」「合否はどの数字で判定しますか」「測るときのデータ量はどれくらいを想定していますか」の3つが具体的です。答えが返ってこない場合、その作業が計画に入っていない可能性があります。言葉ではなく費目と数字で確かめるのが確実です。
- Q. 合格ラインは契約書に書く必要がありますか
- A. 契約書本体でなくても構いません。要件定義書や、テスト計画の合格基準として合意されていれば実務上は機能します。大事なのは形式ではなく、双方が同じものを見て合意した記録が残っていることです。口頭だけで決めた基準は、担当者が変わった時点で無かったことになります。
- Q. 品質管理の指標や手法は発注側も覚えるべきですか
- A. 覚えなくて構いません。バグ密度やテスト密度といった指標は、開発会社が自社の工程を管理するための道具です。発注側が同じ指標で議論しようとすると、かえって本筋から離れます。発注側が持つべきなのは、自社の業務でどうなっていれば合格かという基準のほうです。
