１．論理は、
シンプルに（常に、もっとシンプルにならないかといった美的感覚が必要）よく考えて、出来るだけ不要なものを作らない設計をせよと言う事。
これは、「原価低減の基本の第一」で、部品の点数を減ずる事に通ずる。
つまり、点数を減らす事により、構造がシンプルになり信頼性が向上し、同時に原価低減にもなるので、本当の原価低減である。
更に、信頼性が向上する事で顧客のためにもなる。
（１）設計者は、よく考えよ、作らないことが最も信頼性が高い
・ 基本設計をキチンとヤレ。夢に見るようになると一人前と言われている。
・ 言葉の定義をハッキリさせよ。このためのトラブルは多い。
・ キ－をハッキリさせることが、スペックの整理につながる。
章、節、項をキチンとすると、その配列を見ただけでスペックがハッキリする。
かつ、漏れがよく判る。頭の整理とスペックの整理となる。
・ 「すればよい」と「しなければならない」とは、等価である。
すればよいの発想では複雑化し、スッキリしない。「しなければならない」とおきかえて考えよ。
・ 少しズボラな精神の持ち主の方がよい設計が出来る。
（２）テ－ブル化し、インジケ－タを減らせ、ディメンションを減らせ
・ よく分からない物をテ－ブル化するのは難しい、しかしやらないとその物はどうなるのか？
・ テ－ブルは、拡張可能にし、テ－ブルの更新は、特定モジュ－ルに限定せよ
・ テストにおいても組み合わせがシンプルになるため信頼性が上がる
（３）Virtual化（性能が許す限り）せよ
・ 本質は、Ｍａｐｐｉｎｇ（テ－ブル変換）に有り
（４）概念の統合（Conceptual Integrity）が重要、マトリックス化し、ビジュアル化せよ
・ 何のために何をやっているのか？
・ 手段を考えるよりも目的を考えよ、目的をよく考えれば代案がでる。
２．標準化せよ（執念深くやれ）
（１）標準化は、そのグル－プの長がやれ（部の標準化は部長自らやれ）
・対象を狭く、限定せよ
（２）テ－ブルの標準化をせよ
・ システムとして考えよ（ex、Event Status Matrix)
・ 人の転用が効く
・ 大きく間違う事がなくなる
（３）高級言語化をせよ
・保守／流用を考えるとReadability＞Writabilityである
（４）経験や、成果のFormulate化（内規、規格の原動力となる）
・ドキュメント化が大切、まず「メモ」の作成から始めよ
（５）部品化せよ
・ プロジェクトの開始時点で何を部品化するかを考えよ
・ 部品化は難しい問題である、小さすぎる部品は、部品でない
・ 高級言語の世界で考えよ
・ 適用範囲を限定せよ
・ 部品化を奨励する管理体制が必要
（６）実績有る論理を使え
・新幹線は、新しい技術は何もないと言われているから信頼性が高い
３．ＤＲ：デザインレビュ－の徹底
（１）ドキュメントのビジュアル化
・ レビュ－するための客観的なドキュメントが少ない。
・ ドキュメントに力を入れよ。ソフトウェアはドキュメントでしかビジュアル化出来ない。
（２）チ－フレビュア制の徹底
・ レビュ－結果を採点表示／レビュ－成果分析し、レビュ－のビジュアル化を図れ。
・ 説明者を被害者とするな。レビュアは加害者になるな。
レビュ－は、次の手を考えさせる、弱点を素直にだせる、皆で補わないと／サポートしないと効果がない。
（３）集中レビュ－を実施せよ
・基本仕様書、機能仕様書に効果がある。
・基本仕様書は、システム規模によるが合宿による集中レビュ－が効果的である。
（４）段階的レビュ－の実施
・ 特に設計ドキュメントに効果がある
・ 問題点の早期発見、再発防止
・ 担当者のレベルアップ
・ 全部出来てしまうと、変更しづらい
（５）繰り返しレビュ－の徹底
・ 規模の大きいシステムに効果がある
・ 全体を見通せるほど優れた人はまれ、いないと思った方がよい
（６）チェック回路は本体より事故が多い
・検出回路の誤動作が多いということを認識する必要が有る。
・チェックは、ダウンするポテンシャルを増やす。
チェック強化をしてダウンを増やすのがよいか、チェックを甘くしなるべくダウンさせないのが良いか、よくメリット／デメリットを考えること。基本的には、安全原理の安全設計。
（７）危険物には念には念を入れよ
・特に、ＯＳの核の修正や、ＤＢの修正や、ジャ－ナルの修正は心臓手術と同じであり、死の危険を伴う。細心の注意と細心のチェックが必要。
・ベテランをレビュ－に参加させよ。
【ＤＲ成功のポイント】
・ アローダイヤにレビュー工程を明示する事。
・ タイムリーに明確な仕様書が作成される事。
・ 適切なメンバーの参加。
・ ＤＲ用チェックリストの整備。
・ 過去の不良事例の整備・編集と検索。
・ ＤＲの事前準備（ＤＲ用資料の事前配布）が必要。
４．より上流工程でのテストの徹底
（１）テスト計画
・ＦＳ（機能仕様書）の段階で計画せよ。ＦＳの一章でよいから、まずは計画せよ
－テスト方針／テスト戦略等の方針レベルのことを書く
－テスト手段については、環境の定義、シミュレ－トの方法、使用ツ－ル等を細かに書く
－確認内容は、アウトプットが何で、何をもって完了とするかを明確にする
・テスト環境仕様書を作成せよ
－テストプログラム（ＴＰ）、テスト環境等を書いたもの
－ノウハウを個人のものではなく、チ－ムのものとする。順次更新し充実させていくことが大切
・プログラムは、my program → our program の意識改革を徹底させよ
・ＴＰ体系の整備をせよ
－一つのＴＰに含む機能は単一から複数へ体系化せよ
－管理台帳は必須
（２）単体テスト
・机上デバッグ
－摘出不良の目標値設定。総摘出不良の６０％以上が望ましい（デバッグの基本は机上）
－担当者一人一人がバグ曲線を毎日記入
・モジュールテスト
－チェックリスト、ＴＰ作成日程を工程表に入れる
－担当者一人一人がバグ曲線を毎日記入
（３）連動テスト
・ＰＣＬ消化予定曲線の進捗を全力を挙げて守る
・工程を表面上進めるだけでプログラムテストとはならない
