システム開発の品質基準はどう決める？見積承認の例で次へ進む条件をそろえる

品質基準を、業務の条件と判断の根拠へ分ける

システムの品質を考えるときは、「何ができれば業務の目的を満たすか」と、「何を確かめたら、その段階を終えてよいか」をつなげます。この記事では、その業務条件、確かめ方と記録、進むか保留するかの判断条件を一組にして説明します。

業務で必要な状態

営業が提出後の状態を確認でき、責任者が同じ版の見積を読める、という条件案です。画面が一度開くだけでは、この仕事を確かめたことになりません。

確かめる対象と方法

設計説明のどの箇所を読むか、開発側はどの操作と結果を試すか、発注側は誰の仕事として確認するかを分けます。それぞれ対象の版と、期待する状態を対応させます。

次へ進む判断の条件

必要な資料と記録がそろい、残る不一致や未決定を、判断できる人が読めるかを確かめます。確認した人と、次の段階へ進める権限を持つ人が同じとは限りません。

品質には、業務の動きだけでなく、必要な速さ、情報の扱い、停止時の仕事なども関係します。ただし、一般的な項目名へ数値を埋める前に、どの仕事で何に困るかを明らかにします。本稿は、見積承認の仕事を各段階でどう確かめるかに絞ります。速さや復旧などの要求を決める場合は、業務から非機能要求を具体化する方法を参照できます。

受入条件は、対象の業務や機能が満たすべき条件を具体化するものです。品質基準を使う場面では、その条件に加えて、設計・試験・業務確認のどの記録を読み、次へ進めるかを決めます。納品時の検収条件は対象と判断時点が違うため、納品物と検収の確かめ方をそろえる方法で別に扱っています。

IPAの定量的品質管理の紹介は、各工程で品質目標を設定し、データを測り、分析して対策する流れを示しています。2008〜2010年度の事業のアーカイブで、測る粒度には作業負荷も考慮しています。本稿では、その考え方を、目的と判断に使う記録を対応させる参考とし、全社共通の欠陥数や合格値にはしていません。

通常の見積で、何を確かめたいかを決める

まず対象にするのは、通常の見積確認案です。架空の識別名は見積M01。仕事は「営業が見積M01を提出し、責任者が承認可否を判断する」で、システムを操作する役割は、二案とも営業担当と承認責任者です。この役割は、見積を提出し内容を判断する業務上の担当であり、プロジェクトの品質判定者が確定したことを意味しません。

「見積の承認画面を作る」より、営業が何を提出し、責任者が何を同じものとして確認できればよいかを説明します。営業の画面と責任者の画面で別の版を見ていれば、見た目が整っていても、同じ見積について判断できません。

操作・結果・版を対応させる

設計の相談では、営業が提出する前の条件、提出後に確認できる状態、責任者が開く見積の版を、同じ仕事の流れで示してもらいます。「営業は提出を押す」「責任者は一覧を見る」と別々に説明するだけで終わらず、同じ対象をどう結び付けて確認するかを聞きます。

実際の案件では、提出を重ねた場合や変更した版の扱いも、必要な業務条件として相談します。ただし、この教材には版の実名、項目の値、画面の状態名、提出後の実際の保存記録はありません。決まっていない表示や状態を「実装済みの仕様」として足さず、必要な説明と確認の問いにします。

この案で確かめたい問いは、「設計説明・試験記録・発注側確認のどの段階で、何を証拠に次へ進むか」です。業務の期待を一つ置いただけで、設計や試験を終えたことにはなりません。次の三つの段階で、対象と根拠をつなげます。

設計・開発側試験・発注側確認の証拠をつなぐ

同じ見積を追っても、段階ごとに確かめられることは違います。設計説明は予定する動きの筋道を読むもの、試験記録は条件をそろえて実行した結果を読むもの、発注側の業務確認は仕事として必要な状態を確かめるものです。一つの資料で三つを代用しません。

確かめる人と、進める判断者を決める

二つの案とも、次の段階へ進める品質の判断者は未決定です。見積の内容を承認する責任者が、そのまま開発の品質を判断する権限まで持つとは限りません。IT発注担当は、業務責任者と開発側に、各段階の確認担当、技術的な説明をする担当、残る条件を読んで進め方を決める権限を確認します。

一人が複数の役割を兼ねる場合でも、何を確かめた立場かと、何を判断した立場かを残します。記録の作成者が、知らない技術的な結果や権限を推測して補う必要はありません。判断する相手が不明なら、その担当を決める話を先にします。

図で、同じ見積と段階ごとの確認をたどる

見る前の問い：「画面ができた」以外に、何を確認すれば次へ進めるでしょうか。図では通常の見積の仕事をたどり、設計の説明、開発側の試験、発注側の業務確認で、何の記録を必要とするかを見ます。下段の原価未定は、入力条件の違う別案として読みます。

解説図を原寸で見る

図から読む判断：三つの段階は、これから何を確かめるかの整理です。この教材には設計レビュー、試験、発注側確認の証拠がまだなく、矢印を進めた実績や、全段階の合格を示しません。原価未定の別案は期待する動きから決める必要があり、通常案を修正して成功した姿ではありません。

次の行動：IT発注担当は、営業責任者と開発側へ、通常の見積の期待する状態、段階ごとに示せる記録、品質を判断する担当を聞きます。原価未定の別案は、提出を止めるか仮保存して確認するかの判断を先に相談し、決まった版に合わせて設計と試験の対象をそろえます。

原価が未定の別案は、期待する動きから聞く

もう一つは、原価欄が未確定の別条件案です。対象は見積M02で、仕事は「見積M02の原価欄が未確定のときの扱いを相談する」。入力側の条件は原価欄が未確定です。通常の見積の条件と混ぜず、同じ架空会社の別の入力条件として扱います。

この案の期待する結果は未決定です。「提出を止めるか、仮保存して責任者へ確認するかを先に決め、決めた条件で試す」という問いを、業務側と開発側へ返します。提出を止める方法と、仮保存して確認する方法は候補で、どちらかを採用した記録ではありません。

二つの候補で、仕事への影響を聞く

提出を止めるなら、営業がどの不足に気付き、誰へ確認し、原価が分かった後にどう再開するかを相談します。仮保存して確認するなら、確定していない見積だと誰が分かり、責任者が何を判断し、確定後の版とどう区別するかを聞きます。いずれも、これから条件を具体化するための問いです。

開発側には、それぞれの方法で必要な設計や操作、保存される情報、確認方法を説明してもらいます。業務側には、どちらなら必要な見積の仕事を進められ、どの未確定を残せるかを聞きます。金額、承認限度、状態名、処理済みの値などを、記事の側で作って答えにしません。

返答がそろわない間は、この別条件についての確定判断を保留します。影響する設計や試験の範囲を開発側へ確認し、別の確定した仕事まで理由なく一括停止するのではなく、何が未定で何に影響するかを分けて相談します。通常案の確認を進めたことを、原価未定の案も確認済みという根拠にはしません。

試験を始める前提と、終える条件を分ける

品質基準を使って進め方を決めるには、「試験の準備ができた」と「期待する結果を確かめ終えた」を分けます。どちらも、対象の仕事と試験の目的に合わせて決める必要があります。

始める前に、対象と条件をそろえる

見積のどの版を試すか、どの条件の試験データと利用する役割を用意するか、何を操作し、何を期待する結果として比べるかを決めます。原価未定の案のように期待する動きが決まっていなければ、その条件の合否を判定する試験の前に、業務判断を受ける必要があります。

二つの案の試験環境は未決定です。実際に用いる環境、対象の版、必要な権限やデータを、開発側とそろえます。準備物の名前を一覧にしただけで、必要な人がその環境で確認できる状態になったとは扱いません。

終えるときは、未確認と不一致も読む

予定した条件のどれを確かめ、どれが未実施で、期待と違う結果が何かを読めるようにします。営業の提出後の状態と、責任者が見る同じ版の対応を確認した記録が必要です。画面が一度表示されたことや、不具合件数の一つの数字だけで、仕事の全条件を満たしたとは判断できません。

この二案の基準値や停止条件は未決定です。普遍的な欠陥の許容数や試験件数を置かず、今回の対象と影響に応じて、何が不足すれば次の判断を保留するかを担当者とそろえます。数値を使う場合も、数える範囲や根拠が説明できることが必要です。

ISTQB®と同シラバス著者によるCTFL v4.0.1の5.1.3節は、活動を始める前提と、完了を判断する条件を、試験の目的に応じて定める考え方を示しています。本稿の見積の例や、具体的な確認記録の組み方は独自の教材です。教育用シラバスの例示を、当該案件で合意した基準として置いていません。

予定や予算の制約で試験を続けられなくなる場合も、品質の条件を満たしたこととは分けます。未実施の条件、不一致、業務への影響、残るリスクを明らかにし、権限を持つ関係者へ進め方を相談します。この教材には、そのような判断やリスクの受入を行った事実はありません。

回答後に基準の版と再確認する範囲を直す

回答が届いたら、元の問いと対象に答えているかを確認します。「開発会社が対応できると言った」とだけ残さず、通常の見積と原価未定の別案を分け、どの条件が決まり、どの質問が残ったかを示します。

• 業務の動きと証拠が具体化したら

  対象、操作、期待する状態、示す資料や記録、確認担当、品質を判断する人を対応させます。実際にその方法で確かめられるかを関係者と読み合わせ、採用する条件とその版を区別します。説明が来た段階を、試験済みや受入済みとは扱いません。

• 設計だけ説明が得られたら

  設計で分かった範囲を残し、開発側がどの条件で試験するか、発注側は何を業務として確認するかを続けて聞きます。一段階の説明を、別の段階の結果へ流用しません。

• 原価未定の扱いが残ったら

  未回答の内容、答える業務側の担当、開発側に説明してもらう方法と影響、次に判断する時点を明らかにします。その条件の確定と合否は保留し、既に決まった別の範囲との関係を確認します。

条件が変わったら、前の結果を残す

1. 変更前と変更後を分ける。以前の条件と、それに対応する設計説明や試験記録を組にして残します。新しい回答でどこを変えたか、誰が採用する判断をしたかを説明できるようにします。
2. 影響する対象を開発側に示してもらう。提出前の条件、提出後に見える状態、責任者が確認する版の扱いが変わるなら、関連する設計と操作を洗い出します。この記事で、実際の変更箇所が確定したという意味ではありません。
3. 新しい条件で再確認する。変わった内容と関係する操作を、同じ対象の版・入力条件・役割・期待する状態にそろえて確かめます。前の条件で通った結果を、新しい条件の合格へ自動的に引き継ぎません。
4. 判定の根拠と残る条件を返す。何が一致し、どこが未実施や不一致かを品質の判断者へ渡します。記録を書いただけで次へ進めた扱いにせず、その判断の対象と残る条件を残します。

二つの案の実際の結果は、いずれも未確認です。対応案、合意、試験、判定はそれぞれ段階が違います。個々の機能について入力・例外・役割を受入条件へ落とす方法は、要件定義の受入条件を具体化する方法でも確認できます。

まとめ：見積の仕事と、次へ進む根拠をそろえる

印刷会社の見積承認で品質基準を考えるなら、営業の提出後の状態と、責任者が同じ版を確認できるという業務の期待から始めます。設計はそのつながりを説明し、開発側試験は条件と実行結果を示し、発注側確認は必要な仕事として確かめます。各段階で必要な記録と、次へ進む判断をする人を対応させます。

原価未定の別案は、期待する動きが未決定です。提出を止めるか仮保存して確認するかを、業務側と開発側へ聞き、決まった条件の版に合わせて再確認の範囲を直します。証拠や担当が分からないまま、確認済み・合格・受入済みとは補いません。