品質保証活動のあり方

品質の重要性は増大。

その第1の理由に、
Webや顧客に対する直接的なアクセスが可能になった結果、ユーザとシステムの距離が近づき、影響はすぐにユーザと企業収益に及ぶようになった。
第2の理由は、
ソフトウェア開発の劇的な変化。開発スケジュールは、マーケティング部門、あるいは顧客の需要そのものに左右される傾向が強まり、IT活用への需要や機会は増加し、これに伴って開発工程の内側は複雑化の度合いが増した。
こうような時代の変化に伴い、品質は期待されるパフォーマンスと、そのパフォーマンスの実現にかかるコストとのバランスで評価されるようになってきた。
ユニクロがヒットした最大の要因は、安くても品質が良かったと言われております。品質は　"企業における良心"　ともいえますね。
これからは何でもありの何がチャンスになるか分からない世の中なので”品質について”これまでの経験をもとに纏めて見ました。
ここで述べる品質保証活動（ＱＡ：Quality Assurance）はコンピュータ・ソフトウェアに関する品質保証についてです。ご参考になれば幸いです。
なお、本ブログはリタイア後niftyブログで作成していたものを移管しました。

１．品質保証活動とは
はじめに：品質保証活動のあり方
その２：歴史的な経緯
その３：品質の保証
その４：品質保証活動の独立性
その５：品質保証レベル
その６：実践的品質保証

２．ソフトウェアの品質
その１：ソフトウェアのライフサイクル
その２：ソフトウェアの品質特性
その３：バグについて
その４：プログラムの品質
その５：ドキュメントの品質

３．品質保証業務
その１：はじめに
その２：テストとは
その３：製品検査の流れ
その４：検査計画
その５：ドキュメントレビュー・検査
その６：検査項目作成
その７：中間品質検査
その８：作業監査
その９：受入検査
その１０：プログラム検査
その１１：合否判定

４．品質保証技術
その１：はじめに
その２：信頼性向上の実践
その３：設計の基本
その４：開発の体制
その５：工程の進め方
その６：プロジェクトの崩壊（逆発想）
その７：規格／規則／基準／規定／内規
その８：製品検査設備／ツール（治工具）
その９：変更管理システムの徹底

５．品質保証活動の実践
その１：リスク管理
その２：品質目標値設定
その３：品質会議／品質月報
その４：５Ｗｈｙによる動機的原因追求
その５：品質向上啓蒙活動
その６：アフターサービス

６．人材育成と人事管理
その１：品質保証部門の期待する人物像と特徴
その２：適材配置
その３：メンタルヘルス

７．品質保証に関する提言
その１：概要
その２：第三者による品質保証体制作り
その３：プロセスを変えよ
その４：工数見積もりの意義について
その５：終り：変化する要求

品質保証に関する提言（終り：変化する要求）

最後になりますが、

システムは、「契約時の曖昧性」、「その後の変動性」、「その結果としての膨張性」という三大特性がある。

そして、厳しいシステムの損益は、見積り／契約条件（即ち契約内容）で５－８割が決まり、プロジェクトが開始してシステム仕様が固まるまでに８－９割、システム開発で残りの１－２割が決まるとまで言われている。

「始めが肝心」であり、見積り／契約の重要性はいくら強調してもしすぎることはない。

このようなシステムに対して、要求が、開発に着手する前にどれだけ合意に達するかは、プロジェクトを成功に導く大きなポイントである。

通常は、８０～９０％が合意点に達していることが目標である。

それでも、要求は変わる。

要求の内容を正確に把握するのが難しいだけでなく、要求そのものが変化しやすいものであることから、長期の開発プロジェクトを成功させることが難しくなるわけである。

プロジェクトの期間は長くても１年である。

このため２年という期間が設定されたプロジェクトは、最初から成功させる意図が存在しないものということもできる。

成功の目算はあるのかと言われると、明確に答えることは出来ない。

実際には、要求は変化させないとか、リスクが存在しないとか、非現実的な制限を付けないと、成立しない計画になる。

このような状況に対して、
「ウオーターフォールモデル」、
非ウォーターフォール・モデル（「スパイラルモデル」や「プロトタイピング」）、
繰り返し型開発モデル（「インクリメンタル開発」や「イテレーティブ開発」）、
「アジャイルソフトウエア開発」、
オープンソースにおける開発方法「伽藍（がらん）方式」や「バザール方式」等、
といった開発方法やモデルが提案されております。

最後になりますが提言としては、
第一に、第三者に品質保証作業を委託する仕組みを作る必要がある。
第二に、品質の質の向上という点で、プロセスの改善が必要である。
第三として、詳細な作業の工数見積りは困難を喫すが計画を立て挑戦し開発にあった手法やモデルを適用する必要がある。


終わり。

品質保証に関する提言（その４：工数見積もりの意義について）

ソフトウェア開発における最大の問題の一つは、詳細な作業の工数が見積もれないことである。
現実には、事前調査に３週間、外部設計に５週間、詳細設計に１０週間、コーディングに2週間、テストに５週間などという形で予定が立てられる。
実際に「設計作業」と言っても、操作画面の構成を検討し、ファイルのレイアウト、メッセージのフォーマットなどを仕様の形にまとめる作業も入っているし、タスク分割、あるいは分割の根拠となる資料を作成する作業や、タスクの構造図を書くという作業もある。このような作業の中には、３０分や１時間で終わるものもある。
一方、「コーディング作業」でいえば、コンパイルオプションを決める作業や“コーディングベカラズ集”のようなものを作る作業も必要である。
チームのメンバーによっては、コーディングやテストの仕方、ツールの操作方法などに関してトレーニングを受ける必要もある。
こういった具体的な作業が必要であるにも拘らず、実際には大雑把に「設計に何ヵ月」という形でしか把握されていない。
こうなる理由は、このことについて考え続けていないからであり、考え続ける時間が確保できていないからである。

『プロジェクトが予定より１年も遅れるのはなぜなのか。それは１日の遅れが積み重なるからである。』
これは「ソフトウェア開発の神話」（「人月の神話」）の著者である、フレッド・ブルックスの言葉。

現実の混乱は、まさに、この言葉に集約されていると言える。現実は「１日の遅れ」を見ることはできない。
一体、今日は何を仕上げることになっていたのか、あるいは今週は何と何が終わっていなければならなかったのか、が見えない。
当人も、“何となく遅れているな．．．”というのは「感じ」られても、具体的に何が遅れているのか分からない。

「１日の遅れ」を認識するためには、どうしても「１日の予定」が必要なのである。

以下に、このように工数が読めない、あるいは工数が見積もれないことから、どのような問題が起きるかということについて考えて見る。

■今の作業がいつ終わるか分からない
その主な理由は、計画時に予想されていない作業が「その場になって」発生するのと、作業そのものは想定されていても、見積もった時間より多く掛かってしまうことである。
計画時に予想されていない作業が湧きだしてくるのは、作業を具体的にブレークダウンしていないから当然である。
また、一般にこの種のスケジュールが立てられるときには、ある程度の危険率が掛けられる。
危険率を掛けるのは、その時点で計画の甘さを感じているからであり、何かが湧き出してくることを予感している。
多くはスケジュールの中盤から後半にかけて、作業が行き詰まる形で出てくるため、結局、“危険率が必要であった”の神話が成立することになる。
実際の作業に入ったら、当初の予定を延ばす要因が次々と涌き出す。
しかもそれらの「遅れ」は、ほとんどが“自分の所業”ではない。
従って、この「遅れ」を回復するための動機は存在せず、遅れを主張することになる。
『予定外の作業が入ったのだから仕方ない』と。

見積もれない理由の多くは、それは前回のプロジェクト（今、遅れながら進行中のプロジェクト）の計画段階で詳細な工数を見積もらなかったことによって作業が遅れ、次のプロジェクトの開始時期に重なったことによって、次回も細かく見積もるための時間が確保できないまま、結局前回と同じ状態に突入する。
そしてこの問題は“マルチジョブ”が出来ないかぎり解決しない可能性がある。

■目前の業務以外のことに時間を割けない
実は先の問題よりもはるかに影響は大きく、広範囲に及ぶものであり、原因と結果が錯覚されている部分でもあるだけに、質の悪いものでもある。
たとえば心理面で、関係者はプロジェクトの進捗状況を隠そうとする意識が働く。
具体的な作業や、その工数、成果物などを明らかにしていないため、“今、やっている作業”に自信がないことなどが作用しているものと思われる。
工数が見えていないため、当然、自分にとって“余計”な作業を、ことごとく排除しようとする。
その結果、自分のスキルアップのために１日１時間も「勉強」に当てることができない。
他の人が書いた数枚の文書に“目を通す”ような作業も、当人にとっては『雑用』に見えてしまう。
或いはメールを読むことも『雑用』になるかもしれない。
組織において作業の見直しに取り懸かると、必ず、この種の「雑用」が槍玉に上げられる。
したがって、“優先順位を考えて作業をしよう”というスローガンも、彼にとって優先順位の高い作業は、コンカレント性にあるのではなく、自分の分担する作業にあるから、組織として何も変わることはない。

■仕様書ウォークスルーのドキュメントを、事前に読む事も出来ない
ウォークスルーの直前に１０分ぐらいでお茶を濁す程度にページをめくって、その場をやり過ごせた経験があるでしょう。
同じ理由で、メンバー相互のコード・ウォークスルーも出来ない。
それが、ソフトウェアの品質を確保する効果的な方法であることを理解していても、とても時間的に関わることは出来ない。
当然、今回の変更要求の仕様を「事前」に検討する時間もない。
実際にプロジェクトがスタートする前に、リーダークラスの人が事前に検討を終えていなければ、プロジェクトがスタートした後で、チーム内でコンカレントに作業が出来なくなる。
よく、メンバーの若手が、プロジェクトの初期の段階に、やることがなくてぶらぶらしている風景を目にすることがあるが、その殆どは、このような状況に陥っているものと予想される。
逆に、十分に検討しないまま仕事を分割して、各担当に割り振ってしまうのも、そうしなければ、メンバーが遊んでしまう、という理由も存在している。
当然、その結果として、具体的な設計に入ってから問題点が各所で表面化することになるし、もちろん、プロジェクトの後半に、彼らは地獄を味わうことになる．

■プロジェクトの進捗に対して、さらに効果的な進め方を検討することが出来ない
具体的な作業が明らかになっていないために、チーム内での作業の交換ができない。
一人でやる仕事なら、作業の順序はそれ程大きな意味を持たないが、チームで行うときには、比較的小さな単位で具体的な作業アイテムが明らかになっていて、その順序を制御することで、メンバー間の作業の待ち状態を避けることが出来る。
また幾つかの作業を事前に肩代わりしてあげることも出来る。
少々のトラブルがあっても、それが早い段階であればチームのメンバーがカバーして、遅れを表面化しないで済ませることも出来る。

作業展開は３日を限度に、工数を読む、ということは、作業の進捗を管理するために欠かすことができない。
「設計作業に１０週間」などと大雑把にしか把握していない以上、今日現在で作業が遅れているのかどうかを判断することは出来ない。

１日で終わる作業や数日で終わる作業などを中心に、長くても３日を限度として詳細な作業アイテムを把握することで、「予定より遅れたのか、予定より早く終わったのか」が見える。
作業が遅れたことが判明したとしても、残り１週間の時点ではなく、今はまだ設計作業に入って１週間目。
３週間のコーディング作業も、３週間かけて１つのモジュールをコーディングするようなことはない。

このようにして遅れを発見し、その原因を検討することで、この後、作業の把握状態の善し悪しを再検討してもよいし、遅れの原因が、単に担当者が風邪を引いて休んでしまったことにあるのなら、その後の作業をチームで吸収する方法を考えてもよい。

【チームが効果を増幅させる】
たとえば、５人それぞれの人に一つの仕事を割り当てるのと、５人で構成される１つのチームに５つの仕事を割り当てるのとでは全く違う。というより、違えることが出来る。
作業を細かく、且つ具体的に把握し、詳細に工数を読むことによって、チームとしての工数の合計を大幅に減らすことも可能になる。
勿論、プロジェクトの種類が、ある程度類似している事が条件となるが。
そして、このようなチームには、メンバー間の技術交流やスキルの向上という「おまけ」もついてくる。

逆に、工数を読まなかったチームでは、数年経ってもメンバーのスキルが変わらないということもしばしば見られる。

このようなことから、“工数を読む”ということを脇に追いやったままでは、その組織が抱える多くの問題を、何一つ改善することも叶わない。

明らかに、改善しなければならない項目がいくつか提起され、それに取り懸かっても、結局は「時間がとれない」という“事実”の前に、すごすごと『改善の旗印』を降ろさざるを得ないことになる。

このようなことからも、詳細な計画を立てることは、プロセスのレベルを改善するための第一歩である。　

品質保証に関する提言（その３：プロセスを変えよ）

第三者に品質保証をしてもらうことを前提とすると、先ず始めに、第三者にテストをしてもらえるようなテスト仕様を作成し、設計作業のテストを委託することから始める必要がある。

これが出来ることが前提で、次に、第三者に品質保証作業を委託する。

これは、これまでに述べてきた品質保証作業を代行してもらえればよい。

と言うことであるが、もっとも大切な品質の質の向上という点では、次に述べるプロセスの改善が必要である。

バグは、一連の作業が上手く流れていない結果として招き入れられている。

したがって、結果を変えたければ過程、すなわちプロセスを変えなければならない。

ソフトウェア開発に於けるプロセスは、組織の体制や作業手順、さらには各人の発想パターンがそれに該当する。

これらが同じである限り、同じようなバグが入り込む。

特に明確な作業手順を持たない開発組織の場合、各人の思考パターンがプロセスの大きな割合を占めてしまう。

バグ発生の仕組みが、パラメータのチェック漏れにあると判明した場合も、なぜチェックが為されなかったのか、さらにはどうして最初に設計書が書かれなかったのかが問われなければならない。

そうして初めて、どうすれば設計書が書けるのか、どうすればレビューが出来るのかといったプロセスの改善に至ることが出来る。

そうやって真の原因に至れば、何らかのプロセスが変更される筈である。

こうした真の原因に至らないかぎり、同じような性質のバグが毎回侵入してくる。

そしてそのような組織では、「ソフトウェアの開発は、誰がやってもこんなもんだ。バグなんて無くならない」ということになってしまう。

何故、改革／改善ができないかの「問題」は以下の３つの領域に存在し、一つの問題が他領域の問題の「原因」となっている。

特に、プロセスに関する問題の殆どは、他の２つの領域に起因する問題の影響を受けている。

したがって、３つの領域に対して同時に働き掛けないと、期待する結果が得られない。

・プロセス（仕事の仕方の領域）

・アーキテクチャの領域

・意識／組織の領域

殆どの改革／改善の取り組みはこの領域である。

作業手順の確立や、ＣＭＭの取り組み、それらの取り組みを支援する各種の手法や技法の修得などが含まれる。

以下に、その中の代表的なものを列挙。

○作業の手順的なものとしては、

・要求仕様の作成と管理

・スケジュールの立案と進捗管理

・作業手順の確立

・協力会社管理

・構成管理と変更制御の仕組み

・レビューの仕方・運用

・チームの運営と組織内の協調の仕組み

・成果物、およびプロセスデータの測定と判断の仕組み等

○技法的なものとしては、

・レビュー技法

・サイズの見積もり技法

・スケジュールの見積もり技法

・分析・設計技法

・テスト技法等

これらの技法の習得や、作業手順の確立を実現するには、次の２つの領域に大きく依存する。

・アーキテクチャの領域

・意識／組織の領域

アーキテクチャ領域の問題というのは、

・そのシステムの設計思想が間違っていた

・使用している言語が障害になっていた

・あるいは、システム構成上、拡張性などの品質が考慮されていなかった等。

例えば、適切なＯＳやリアルタイムモニターが搭載されていないという状況や、システムの殆どがＣで書かれているような状況では、製品の表面上は簡単な機能の変更のように見えても、実際の変更作業は大変な作業になることが考えられる。

また、グローバルデータが氾濫していて、内容の更新のタイミングが把握できないような状況とか、流れの制御の為に「フラグ」が多用されていた、関数の呼び出し構造が複雑で、図式化出来ないような状況では、一つの修正行為が、新たな不具合を作り込んでしまう可能性が高く、プロセスの「変更制御」の取り組みも出来ない。

このような時、プロセスの改善とは、別に、アーキテクチャの問題を特定し、その状況の改善に同時に取り組む必要がある。

この種の改革／改善の取り組みにおいて問題となるのがこの領域である。

先ず、意識の領域に関する問題としては、

・どうせ書いたって誰も見やしないじゃないか

・レビューなんてやったって時間がもったいない

・「その日の遅れがその日に分かる」ような詳細なスケジュールなんて書いてられない

・そんな時間があったら、１行でもコードを書いているほうがまし

・どうせ予定と一致することなんてありえないのだから、適当でいいじゃない等

言うまでもなく、このような考え方の下では何も変わらないし、何も取り組めないことは言うまでもない。

実際には、このようなあからさまな抵抗を示すことは少ないが、多くは、“やり過ごし”という“手法”が使われる。

それだけに逆に厄介である。

要は、仕事の意義とか、何のために新しい技術を身に付けるのか、何のためにプロセスを改善するのか、という点に関して、一定の理解と認識がないと、何も進めることはできない。

組織やチームの在り方とか、成果物の測定やプロセスの測定の意味も、その上でなければ理解できない。

「幸福」の原点が、仕事を上手く仕上げるところにあるということに合意が出来なければ、一緒に仕事をしていくことも、一緒にこの種の改革／改善に取り組むことも出来ない。

そのためにも、意識の領域に潜む問題をクリアしていかなければならない。

ただ、この領域の問題の幾つかは、組織の領域の問題から派生している。

次に、組織の領域の問題としては、

・評価基準や

・それに伴う昇進・昇給の仕組み

・減点主義的風潮の存在

・“言い出しっぺ”が損をする仕組みなど

が挙げられる。

この種の取り組みのためには、現実の仕事の合間を縫って勉強しなければならず、そのことが評価される仕組みが無かったり、取り組みが当初の目論見通りの効果を上げなかったときは、その責任を追及されたり、評価を下げるような仕組みの下では、この種の取り組みに対して「忙しさ」を理由に“やり過ごす”しかない。

この種の取り組みは、実に複雑で厄介である。

したがって、「組織」はむしろ、そのような人を積極的に「支援」し、「評価」すべきである。

この領域のもう一つの問題は、それぞれの人の「役割；守備範囲と責任範囲等」が明確にされていないことである。

品質保証に関する提言（その２：第三者による品質保証体制作り）

ここでいう第三者による品質保証とは、品質保証部門が第三者としての立場で品質保証する体制を作ることである。
最終的には、第三者に品質保証作業を委託することが目標であり、第三者に品質保証をしてもらうことを前提としている。
そのためには、設計作業のテストを委託できるようにしなければならない。
先ず始めに、第三者にテストをしてもらえるようなテスト仕様の作成から始める必要がある。

【テスト仕様のあり方】
要求仕様は「検証可能」でなければならない。
つまり、エラーのケースも含めて、そこに書かれていることが、実際に実現していることを客観的に検証できなければならない。
事前にそのような要求仕様書が作成されていなければ、テスト仕様も作れない、その結果、実際にそれが実現しているのかどうかはテスト者の主観で判断することになる。
したがって、要求仕様書が書き上がったら、テストの責任者は、要求仕様がテスト可能な表現で書かれていること、そこに表現されていることでテストが出来るのかどうかをチェックする必要がある。

テストには、設計者によるテストと評価者（設計テスト責任者であっても良いが品質保証部門の方が望ましい）によるテストがある。
「自分のソフトウェアを自分でテストするな」と言われているが、結合テストに入る前の段階では、設計者によるテストがベターであると言える。
評価者がやることは、以降の結合テストや運用テストに耐えうる状態かどうかの判断と評価である。

テスト計画を作ることは重要な仕事であって、製品の開発と並行して作成すること。
機能仕様書の一部として作成することが望ましい。
別冊で作成してもよいが機能仕様書と同等に完了させること。
テスト計画者（テストの責任者）は、要求仕様書が文書化されたらテスト可能性の観点からレビューすること。
テスト計画の本格的な作成は、要求仕様書がフィックスした後に開始すべきである。

統合テストのテスト項目の本格的な作成は、機能設計書がフィックスした後に開始すべきで、単体テスト項目は、詳細設計が完了した後に開始する。

テストは、今のところ省くことができない。
それは、きちんと仕様を実現しているという保証がないからである。
その確信があるのなら、品質保証の観点からのテストで足りるわけで、その確信がない以上、設計者によるテストはもちろん、仕様に沿って第三者による「評価」をも受けなければならない。

テスト計画を作成するためには、
スケジュールを含めて、プロジェクトの計画が必要である。
その枠の中で、
・テスト方針／テスト戦略、
・ＤＤ／ＭＴ／ＰＴ／ＴＴのフェーズ分け、
・テストの方法やＰＣＬ作成計画と言った作戦、体制は
・テストツール、テストの準備や手順は
・合否の判定は
・結果データの収集は
・バグ報告のルート等は
と言ったことを決めていかなければならない。
特にテストツールは、テスト手法、テスト環境等を記載しノウハウを個人からチーム（my program → our program）のものにする。
さらに、具体的なテストでの確認項目としては、下記のような観点からそれぞれのテストマトリックスを作成すること。
結果は確認項目だけでなく、テスト手段、確認内容が明らかであることと出来ればテスト手段／確認内容はパターンとして別表でまとめておきマトリックスからポイントするのが望ましい。
このためには機能仕様書がしっかりしていないとマトリックスは作成できない。
・整合性(製品間／製品内コンポーネント間)
・排他制御
・障害処理
・正常時／異常時の終了処理
・外部パラメタとその組合せ
・シーケンスとシーケンスの組合せ
・シリアライズとタイミング等

テスト責任者の役割として、
・テスト計画を立案
・要求仕様の検証可能性をチェック
・テストを容易にするための設計方法などのアイデアをフィードバック
・品質保証部署との連携

テスト仕様は、ある機能が正しく実行されることを確認するために、どのようなテストを行うかが記述され、さらにどのような結果であればよいかが記述されていなければならない。
一般的にはチェックリストで記述する。
テスト実施者は、それに沿って作業を進める。

要求仕様は、一般的に電子化されているのでそれに手を加えテスト仕様（簡単なものであればチェックリストでテスト仕様を代用しても良い）を作成すると良い。

チェックリストは、プログラムが仕様どおり正しく動作することを確認するためのテストが、網羅的に実行できることを目的とする。
チェックリストの文書には、期待される結果を記述したものを含めること。
組織としてのテスト計画を作成すること。
そして、品質保証部門は、すべてのテストがテスト計画に従っているかどうかを確認することが重要である。

独立部隊の編成について：大規模システムの場合は必須
合理的テスト計画の立案、冶工具の事前準備、品質、進捗度の客観的把握等を行うためにも独立テスト部隊を設計の中に組織すべきである。
テスト部隊が各パートの未完成時期から全体の組合せテストを始めることにより、全体の整合性の事前確認が客観的に出来るし、遅れている部隊にハッパを掛ける事にも役立つ。
悪い実態にも気づかず、「単体テストは順調に進んでいます」と言うような楽観主義の早期是正にも役立つ。
独立テスト部隊は、テスト方式の設計をキチンとやるべきである。
本来多くのテストをしなければならないのに、限られた期間での選択したテストケースで品質を確保しようと言うことだから、シッカリした方式設計が必要である。
また、単位時間当たりに確認できるテストケースの数を稼がなければならないのだから、テストの実行も結果の確認も極力自動化できるようにしなければならない。
当然のことながら,テストプログラムの設計、テストデータの設計、テスト冶工具の設計も最初にやっておくべきことである。

テスト方式の設計に関しては、契約上の検収条件をキチンと把握し、検収に耐えうることを最低限のテスト条件として設計しなければならない。
検収条件は契約時にキチンと確認されていなければならないが、実際に検収試験を受けようとすると難しい問題が出てくることもありうる。
検収されないかぎり、契約は完了しないのだから、万一、検収に困難をきす事実が判明したら、速やかに関係者で善処策を協議すること。