品質保証技術（その５： 工程の進め方）

１．決めた工程を守ること

・ リーダは、自分でアロ－ダイアグラムを書くこと、最初のアロ－を最後まで貫くこと
・ 中味をよく見る、表面的な員数管理はダメ、バグが出たら中味をよくきけ(WHYを忘れずに）
・ ダメな物は、早めに作り直せ、後になると手の打ち様がない
・ レビュ－を確実に、レビュ－の徹底した推進あるのみ
・ それぞれの工程にフィ－ドバック機構を持て

２．量の管理から質の管理へ
・見かけの進捗よりも質の見極めが大切。質を含めて管理することが問題点の早期発見につながる。

３．問題点を発見したら
・ 計画を見直し、思い切って変更する。遅れ遅れの計画よりも、計画通り作業を進める方が良い。
・ 場合によっては、全体の作業をストップさせる。担当者を遊ばせても、ダメなものを増やすよりはよい。

４．工程の区切りを明確に
・ 「バグ０宣言」と「ＤＤ」の徹底により、総合的な品質が決まるといっても過言ではない。
－開発費用の「１００倍説」にあるように、不良の早期発見が重要。
－バグ０宣言を好い加減にし、後工程で不良摘出すると、余分な作業が発生する。
・ 中途半端なままで次工程に入らない。ＦＳ以降の日程については大日程を担当者全員に指示、かつ日程を担当者に納得させる。テスト工程の短縮は、バグ０宣言の徹底が最も効果的である。
・ 管理者は、ある種の勇気、決断が必要。”急がば回れ”ここで遅れても品質を良くする方が、最終的には得になるという強い信念を持つ。

５．進捗の良い部分は、徹底して先へ進める
・ 原価高にならないなら、結局は得。工程が進めば、新たな問題が出る。
・ ここは大丈夫というところを増やす。ダメなところを浮きぼりにする。

６．フォロー会議：絶えざる加速、しつこい管理
・ 全体会議は、月１回実施。サブリ－ダ会議は、週１回、ＰＴ以降は毎日。
・ リ－ダは毎日、ＰＴ以降は毎朝毎晩。
・ 個人面談、週一回。作業物件により、全担当者とプロジェクトリ－ダとの面談。

品質保証技術（その４： 開発の体制）

１．プロジェクト全体を見渡す人を置く

・ 管理面、技術面（チ－フレビュア）
・ プロジェクトの規模により、複数人でも良い
・ 但し、責任の明確化と緊密なコミュニケ－ションが必要

２．担当者とのコミュニケ－ション

・ 正確な状況把握と対策が可能なように、日頃のコミュニケ－ションが大切。
・ 担当者との定期的なヒアリングが有効。
・ 担当者間のベクトルあわせも必要。仲間意識を持たせるよう工夫する。

３．テストの重視

・ 設計なきテストはテストにならい。「テストは、最後の関門」。
・ プロジェクト発足時からテスト方法を検討し、準備する担当をおく。
・ テストの容易性を配慮したテストのし易い仕組みを、あらかじめプログラムに組み込むことが重要。

４．資料のファイリングを決める
・ ファイルの種類、ファイルする人、コピ－して配布する人。
・ 資料の一元管理。

【新しい事をやる場合の心構え！】
・新しい事をやれば、必ず失敗すると思え
・経験した事は出来る（本当は経験していないのに経験したと思っているのが最も恐い）
・流用せよ（流用調査は早めに切り上げてすぐ修正に入れ。仕様はコ－ディングを直すときに分かる。動いていても論理の汚いものは流用するな。長い目で見ると論理の汚いものはダメ、結果として高価になる）
・一見易さしそうでも未経験の人は危ない
・未経験者を使う場合はよく注意せよ。未経験者には設計をさせるな！（製造はＯＫ）
・経験者が得られない時は、出来るだけ頭の柔らかい人を選べ
・まねをせよ（但し、違いをハッキリさせよ）

品質保証技術（その３：設計の基本）

１．論理は、

シンプルに（常に、もっとシンプルにならないかといった美的感覚が必要）よく考えて、出来るだけ不要なものを作らない設計をせよと言う事。

これは、「原価低減の基本の第一」で、部品の点数を減ずる事に通ずる。

つまり、点数を減らす事により、構造がシンプルになり信頼性が向上し、同時に原価低減にもなるので、本当の原価低減である。

更に、信頼性が向上する事で顧客のためにもなる。

（１）設計者は、よく考えよ、作らないことが最も信頼性が高い

・ 基本設計をキチンとヤレ。夢に見るようになると一人前と言われている。

・ 言葉の定義をハッキリさせよ。このためのトラブルは多い。

・ キ－をハッキリさせることが、スペックの整理につながる。

章、節、項をキチンとすると、その配列を見ただけでスペックがハッキリする。

かつ、漏れがよく判る。頭の整理とスペックの整理となる。

・ 「すればよい」と「しなければならない」とは、等価である。

すればよいの発想では複雑化し、スッキリしない。「しなければならない」とおきかえて考えよ。

・ 少しズボラな精神の持ち主の方がよい設計が出来る。

（２）テ－ブル化し、インジケ－タを減らせ、ディメンションを減らせ

・ よく分からない物をテ－ブル化するのは難しい、しかしやらないとその物はどうなるのか？

・ テ－ブルは、拡張可能にし、テ－ブルの更新は、特定モジュ－ルに限定せよ

・ テストにおいても組み合わせがシンプルになるため信頼性が上がる

（３）Virtual化（性能が許す限り）せよ

・ 本質は、Ｍａｐｐｉｎｇ（テ－ブル変換）に有り

（４）概念の統合（Conceptual Integrity）が重要、マトリックス化し、ビジュアル化せよ

・ 何のために何をやっているのか？

・ 手段を考えるよりも目的を考えよ、目的をよく考えれば代案がでる。

２．標準化せよ（執念深くやれ）

（１）標準化は、そのグル－プの長がやれ（部の標準化は部長自らやれ）

・対象を狭く、限定せよ

（２）テ－ブルの標準化をせよ

・ システムとして考えよ（ex、Event Status Matrix)

・ 人の転用が効く

・ 大きく間違う事がなくなる

（３）高級言語化をせよ

・保守／流用を考えるとReadability＞Writabilityである

（４）経験や、成果のFormulate化（内規、規格の原動力となる）

・ドキュメント化が大切、まず「メモ」の作成から始めよ

（５）部品化せよ

・ プロジェクトの開始時点で何を部品化するかを考えよ

・ 部品化は難しい問題である、小さすぎる部品は、部品でない

・ 高級言語の世界で考えよ

・ 適用範囲を限定せよ

・ 部品化を奨励する管理体制が必要

（６）実績有る論理を使え

・新幹線は、新しい技術は何もないと言われているから信頼性が高い

３．ＤＲ：デザインレビュ－の徹底

（１）ドキュメントのビジュアル化

・ レビュ－するための客観的なドキュメントが少ない。

・ ドキュメントに力を入れよ。ソフトウェアはドキュメントでしかビジュアル化出来ない。

（２）チ－フレビュア制の徹底

・ レビュ－結果を採点表示／レビュ－成果分析し、レビュ－のビジュアル化を図れ。

・ 説明者を被害者とするな。レビュアは加害者になるな。

レビュ－は、次の手を考えさせる、弱点を素直にだせる、皆で補わないと／サポートしないと効果がない。

（３）集中レビュ－を実施せよ

・基本仕様書、機能仕様書に効果がある。

・基本仕様書は、システム規模によるが合宿による集中レビュ－が効果的である。

（４）段階的レビュ－の実施

・ 特に設計ドキュメントに効果がある

・ 問題点の早期発見、再発防止

・ 担当者のレベルアップ

・ 全部出来てしまうと、変更しづらい

（５）繰り返しレビュ－の徹底

・ 規模の大きいシステムに効果がある

・ 全体を見通せるほど優れた人はまれ、いないと思った方がよい

（６）チェック回路は本体より事故が多い

・検出回路の誤動作が多いということを認識する必要が有る。

・チェックは、ダウンするポテンシャルを増やす。

チェック強化をしてダウンを増やすのがよいか、チェックを甘くしなるべくダウンさせないのが良いか、よくメリット／デメリットを考えること。基本的には、安全原理の安全設計。

（７）危険物には念には念を入れよ

・特に、ＯＳの核の修正や、ＤＢの修正や、ジャ－ナルの修正は心臓手術と同じであり、死の危険を伴う。細心の注意と細心のチェックが必要。

・ベテランをレビュ－に参加させよ。

【ＤＲ成功のポイント】

・ アローダイヤにレビュー工程を明示する事。

・ タイムリーに明確な仕様書が作成される事。

・ 適切なメンバーの参加。

・ ＤＲ用チェックリストの整備。

・ 過去の不良事例の整備・編集と検索。

・ ＤＲの事前準備（ＤＲ用資料の事前配布）が必要。

４．より上流工程でのテストの徹底

（１）テスト計画

・ＦＳ（機能仕様書）の段階で計画せよ。ＦＳの一章でよいから、まずは計画せよ

－テスト方針／テスト戦略等の方針レベルのことを書く

－テスト手段については、環境の定義、シミュレ－トの方法、使用ツ－ル等を細かに書く

－確認内容は、アウトプットが何で、何をもって完了とするかを明確にする

・テスト環境仕様書を作成せよ

－テストプログラム（ＴＰ）、テスト環境等を書いたもの

－ノウハウを個人のものではなく、チ－ムのものとする。順次更新し充実させていくことが大切

・プログラムは、my program　→　our program　の意識改革を徹底させよ

・ＴＰ体系の整備をせよ

－一つのＴＰに含む機能は単一から複数へ体系化せよ

－管理台帳は必須

（２）単体テスト

・机上デバッグ

－摘出不良の目標値設定。総摘出不良の６０％以上が望ましい（デバッグの基本は机上）

－担当者一人一人がバグ曲線を毎日記入

・モジュールテスト

－チェックリスト、ＴＰ作成日程を工程表に入れる

－担当者一人一人がバグ曲線を毎日記入

（３）連動テスト

・ＰＣＬ消化予定曲線の進捗を全力を挙げて守る

・工程を表面上進めるだけでプログラムテストとはならない

品質保証技術（その２：信頼性向上の実践）

【信頼性の夜明け】
信頼性が強く意識されるようになったのは、システムが複雑で大規模になり、システムの故障の影響が極めて大きくなってきたため、故障発生を未然に防止する必要性が大きくなってきたことによると言われている。
信頼性の問題として最初に取り上げられたのは、第二次世界大戦でのレーダシステムだと言われている。
レーダシステムは有効なシステムではあるが、故障が余りにも多く信頼性という概念を考えさせるきっかけになったと言われている。
同じ第二次世界大戦中、アメリカは大量の軍用機を極東に配備したが、半分以上が使い物にならなかった。
電子機器や予備品の故障が余りにも多かった。
そこで政府はメーカに故障をしない機器を作るよう厳しい要求をした。
メーカは、図面通りに製造すべく製造工程を厳しく管理し、厳密な検査を行ったが改善の兆しは見えなかった。
これらの経緯から設計時になにを盛り込めばよいかを懸命に研究し信頼性という概念が起こった。

【信頼性とは】
ＪＩＳでは、「アイテムが与えられた条件で規定の期間中、要求された機能を果たすことができる性質」と定義されている。
アイテムとは、信頼性の対象となるシステム(系)、サブシステム、機器、装置、部品、素子などの総称、又はいずれかを指す。

信頼性をもう少し具体的に考えてみると、耐久性，保全性，設計信頼性の要素で考えることができる。

・ 耐久性とは、対象としているシステムが故障するまでの時間によって評価される。
システムが修理できるものについての耐久性は、平均故障間隔（ＭＴＢＦ）によって評価される。

・ 保全性とは、システムが故障したときどのくらいで修理できるかによって評価され、平均修復時間（ＭＴＴＲ）として表現される。
通常耐久性が増せばコストがかさむ。
そこで多少故障する可能性があっても定期的に点検して故障の発生を予知し、早めに修復できれば信頼性は確保されると考えられる。
つまり耐久性と保全性のバランスで信頼性を確保している。

・ これに対して、システム自体の故障に対してロバスト（コンピューターのプログラムが，
起こったエラーを自動的に対処して処理を続行）するように設計しようというのが設計信頼性である。
例えば、ある部分が故障してもそれがシステムに致命的な影響を与えないようなフェールセーフ設計、あるいは人間の誤動作を阻止するためのフールプルーフの仕組みを取り入れることで信頼性を高める。

【信頼性の定義】
信頼性を表す用語の代表例（ＲＡＳＩＳ）。
（１）Reliability　　　信頼性（ＭＴＢＦ：平均故障間隔）
（２）Availability　　 可溶性（稼働率＝ＭＴＢＦ／（ＭＴＢＦ＋ＭＴＴＲ））
（３）Serviceability　 保守性（ＭＴＴＲ：平均修復時間）
（４）Integrity　　　 完全性（正確さや誤り制御）

品質保証技術（その１：はじめに）

品質向上技術としては、
品質管理手法として欠陥混入防止技術(1)、欠陥検出技術(2)(3)を用いた手法が一般的に実施されている（下記参照）。

「バグ三原則」
（１）不良は作り込まないほどよい
（２）作り込んでしまった不良は早く見つけるほどよい
（３）見つけた不良は正しく直すほどよい

品質の確保に必要なコストは、
製品のライフサイクルにおいて下流にいけばいくほど高くなることがわかっている。

このため、できるだけ上流で品質を確保することが得策であり、各工程の作業結果に対してレビューを行うことが重要である。

品質の作り込みは、要求仕様と設計及び各工程段階で作り込めと言われる所以である。
即ち、設計者は、製品に対して機能,性能,操作性,品質,原価,納期と言った全てに対して責任を持たねばならない。

品質の中で最も重要な「信頼性向上の実践」に関しては設計面,工程面での配慮について述べる。
品質の向上と均一化、原価低減、納期短縮に役立つよう、下記項目を主眼に社会の変化や製品の進化に伴い常に革新的な改善に努めなければならない。

・ 新しい品質評価手法への取り組み
・ 品質評価精度の向上
・ 品質評価作業の能率向上／効率向上

【品質は各工程のレビューで作り込め】
テスト段階以前で品質を作り込むには、インスペクションなどの厳密なレビュー技法を用いるしか方法はない。
欠陥の殆どは実際に動作させて見れば分かる。
しかしながらソースに変換されていない段階では、実際に動作させて見ることは出来ない。
インスペクションは、「実際に動作させる」ことに匹敵するものでなければならないし、そのつもりでレビューする必要がある。
各々の工程の成果物も、それに耐えられるよう工夫すること。
大事なことはインスペクションが出来るようにドキュメントの内容を工夫することである。
また、ドキュメントの単位を、時代の要請にあわせて小さくする工夫が必要である。
小さくして頻繁にインスペクションを実施すべきである。
小さくしても、前にレビューしたドキュメントと矛盾するようなことのないように、ドキュメントの構成や書かれる内容を工夫すること。