トヨタ生産方式（TPS）の中心は、手法ではなく、考え方のようだ・・・

　このまえ、あるところで、トヨタ生産方式の話を聞いてきたんだけど（リンク先、はい、とかいいえを適当にクリックしてると、見れるようになる・・？？）、それによると、よく、トヨタ生産方式というと、カンバンとか、手法に注目されることが多いけど、手法が大事なのではなく、その考え方が重要なようだ。

　手法から入ると、一時的うまく言っても、ものの見方が変わってないから、一過性でおわるそうな。
　見える化なんかもそうらしい。

　そうじゃなくって、考え方が大事で、「共通の価値観とベクトル」を持つって言うことが大切らしい。
　それにより、コミュニケーションも円滑に進むと。。。

　なるほどお。。。

UML等各種ダイアグラムのエラーチェック体系化（その２：エラーチェック体系）

　昨日からはじめたUML等各種ダイアグラムのエラーチェック体系化（すみません、題名を短くしました。それと、ダイアグラム（図）と書くところを、ダイアログと何箇所か書いてました。すみませんm(__)m。直しておきました）。

　昨日も書いたように、はじめに「（１）まず、ダイアグラムにおける矛盾というものを考える。」から入りたいと思います。

　ダイアグラムのエラーチェックをするわけですが、そもそも、エラーはどんなところに起こりえて、どういうチェックになるのか？という話です。

---

■ダイアグラムの作成過程

　まず、UMLでもDFDでもなんでも、ダイアグラムを作るときには、

・ダイアグラムを記述するのに必要な情報をあつめて　　　（入力）
・それらを作成手順に従って作成し　　　　　　　　　　（処理）
・作成結果（成果物）としてまとめ、配布、保存する　　（出力）

という過程を通ると思います。つまり、ダイアグラム作成にも

　　　　　入力→処理→出力

があるわけです。

---

■作成過程とエラーチェック

　この過程において、どのようなチェックが可能であるか？ということを考えます。

・ダイアグラムの入力に関するチェック

　これは、前の工程から、本工程（対象ダイアグラムを作成する工程）に対して必要な情報を取り入れる部分に関するチェックになります。
　つまり、ダイアグラム作成のための必要なデータがちゃんと記載されているかどうか、前工程までに出ていない話を突如持ち出していないか（たとえば、誰も作っていない入力データが突如現れたり）といったことをチェックします。


・ダイアグラムの処理に関するチェック
　これは、入力値を事前条件、出力結果を事後条件として、検証していくことになります。
　処理としての妥当性をチェックするわけです。

・ダイアグラムの出力に関するチェック
　出てきた出力結果（成果物）が、他の成果物と矛盾してないかどうかチェックするものです。
　たとえば、DFDの上位プロセスで、あるファイルに書き出しすると書いておきながら、
　そのプロセスの詳細説明をしたDFDで、どのプロセスもそのファイルに書き出ししていないときが相当します。

---

■エラーチェックの体系化と補完関係

上記のエラーをまとめて体系化すると、以下のような感じになります。

入力時：入力時矛盾チェック
　　　　　＝入力データが前工程で作成されていて、利用可能になっているか

　　↓

処理　：検証
　　　　　＝入力データと出力データの変換の妥当性、正当性

　　↓

出力時：成果物矛盾チェック
　　　　　＝作成した成果物が、他の成果物の記述と矛盾してないかどうか

そして、処理における検証が意味あるものになるためには、入力時のデータが正しいものでなければ意味ありません。
（例：毎月の売上合計額をだすとき、毎日の売上が間違っていたら、合計金額を出す手法は間違ってなくても、毎月の売上は間違い）
そして、検証結果が正しくないと出た場合、出力をチェックしても意味ありません。それ、まちがってますから。
さらに、せっかく出力しても、成果物が他の成果物と矛盾していたら、利用できません。
（前月の売上合計を元に翌月の発注量をきめるが、売上合計を出すのに３ヶ月かかる・・・とか）

ということで、「入力時矛盾チェック」、「検証」、「成果物矛盾チェック」は、どれか１つをやればいいというものではなく、補完関係にあります。

　ちなみに、「入力時矛盾チェック」、「成果物矛盾チェック」は、外部プロセスとの一貫性ということで、外部一貫性、
　検証は、そのプロセス内における一貫性ということで、内部一貫性と、いえるかもしれません。

---

■エラーチェックとコスト

ここで、これらのエラーチェックを吟味してみると、実現するためのコストが違うことに気づきます。

入力時：入力時矛盾チェック
　　　　　＝入力データが前工程で作成されていて、利用可能になっているか
　　　　　→入力が、前工程に存在するかをチェックすればよい
　　↓

処理　：検証
　　　　　＝入力データと出力データの変換の妥当性、正当性
　　　　　→検証を行う
　　↓

出力時：成果物矛盾チェック
　　　　　＝作成した成果物が、他の成果物の記述と矛盾してないかどうか
　　　　　→成果物間の関連性を調べればよい

　「入力が、前工程に存在するかをチェックすればよい」というのは、仮に前工程のダイアグラムに関する情報が、すべてRDBに入っていたとしたら（この連載では、その方法を示します。ダイアグラムをRDBに入れる汎用的手法を）、これから使おうとする項目が、そのRDB内にはいっているか、SELECTをかければよいだけのことになります。

　検証については、いろんな検証法がでているくらいなので、結構大変です。

　成果物矛盾チェックは、成果物間の関係を調べるため、関係が簡単に調べられればいいですが、そうとは限りません。

---

　そこで、以下、簡単に出来る、「入力が、前工程に存在するかをチェック」について考えます。
　この簡単なチェックで、どれほどの効果があるのか、ということに関して調べていきます。

　ただ、その前に、抽象的な話が続いたので、次回は、ここまでの話を、UML＋Strutsの例を出して、もっと具体的に説明したいと思います。