忘れ去られた日本のIT技術～DOAと品質管理

最近、上流工程のモデリング技術として、DOAを見直している。
その過程で、忘れ去られた日本のIT技術とその歴史があるように感じた。
考えたことをラフにメモ。

【DOA(Data Oriented Analysis)】

DOAはデータモデリングというモデリング技法、上流工程の設計技術の一つ。
DOAは日本独自で発展してきた歴史がある。
椿正明さんのTHモデル。
佐藤正美さんのT字形ER。
渡辺幸三さんの渡辺式DOA。

THモデルは古くは1970年代から発展してきたようだ。
他のDOAも、日本で、メインフレーム上の業務システムを開発する経験から育まれてきた。
歴史があるからこそ、DOAを知れば知るほどノウハウがある。

例えば、エンティティにはリソースとイベントの2種類がある。
イベントには必ずタイムスタンプ（日付）が振られて、業務の流れに従ってイベントが変わる。
リソースとイベントの個数を比較した時、普通はイベントはリソースの2割ぐらいしか作られていない時が多い。
つまり、リソースの組み合わせでいくらでもイベントを作る可能性があるし、新規ビジネスを起こすチャンスがあることも意味している。

DOAは業務ノウハウの塊なのだ。
そういうノウハウがあるだけでも、要件定義や設計の品質が上がる。

DOAは上流工程に特化した技術。
メインフレーム時代は、DOAを極めることで、モデリング技法を設計者が習得して、モデリング技術を高めてきた歴史があるのだろう。

しかし、現在を見渡すと、DOAは殆ど使われていないと思う。
OOA（Object Oriented Analysis）やUMLに押されて、皆忘れている。

DOAは習得が難しい。
THモデルやT字形ERは優れているかもしれないが、記法が独自で分かりにくい。
佐藤正美さんの本「論理データベース論考―データ設計の方法:数学の基礎とT字形ER手法」は、論理学を絡めている技法もあるので、哲学みたいで受け入れがたい。
渡辺幸三さんの本「業務別データベース設計のためのデータモデリング入門」「生産管理・原価管理システムのためのデータモデリング」だけは例外で読みやすいが。

DOAの弱点は、所詮は箱に過ぎないこと。
逆に、OOAの利点の一つは、上流工程と下流工程を一気通貫で設計と開発を一緒にできること。
つまり、UMLで設計して、ソースをそのまま出力すればいい。
実際はそんなことはないけれども、DOAに比べれば、オブジェクト指向プログラミング言語と相性がいい。

また、オブジェクト指向言語とDOAの相性が悪い弱点もある。
いわゆる、ORマッピングが面倒で、フレームワークで吸収できなかった歴史がある。
しかし、最近は、ActiveRecordのように、ORマッピングを意識しなくても、普通にDBをプログラミング言語で操作できるようになった。

そして、日本独自で発展してきたDOAがIT業界で忘れ去られた最大の理由は、ERPという汎用的な業務パッケージ製品を作れなかったことに尽きるのではなかろうか？
DOAのモデリング技術とDOAで培われた業務ノウハウで、SAPのようなERPを日本で作って販売できたはず。
しかし、日本では著作権やら業界の慣行が厳しくて、パッケージ製品を作ることができない風土があったのではなかろうか？

また、DOAのノウハウがあるにも関わらず、GoFのようなデザインパターンに業務ノウハウが整理されていない。
海外では、「The Data Model Resource Book」「Data Model Patterns」「アナリシスパターン―再利用可能なオブジェクトモデル (Object Technology Series)」のように業務パターンがまとめられているのに、日本人が書いた書籍がない。
但し、「実践的データモデリング入門 (DB magazine selection)」には「The Data Model Resource Book」「Data Model Patterns」の一部のパターンが紹介されている。

だから、若い日本人技術者のモデルとなるような業務パターンがないので、いつまで経っても、要件定義は難しいと言われているのだろう。

DOAは所詮、受託開発のモデリング技法としてしか、細々と使われているにすぎないのだろう。

【品質管理(Quality Management)】

ソフトウェアの品質管理は、製造業が発端で、日本のお家芸とも言える。
QC7つ道具、プロセス改善など、製造業のノウハウを生かして、ソフトウェアの品質管理に適用してノウハウが貯められてきた。
品質管理の一番の花形は、信頼度成長曲線（SRGM）、別名はバグ収束曲線。

時系列にバグの累積数をプロットして、歩溜まりに達したならば、バグがほぼ摘み取られて、品質が安定したと判断できる。
信頼度成長曲線を使えば、リリースしてよいかどうか判断できるのが最大の利点。

その他にも、プロセス改善がある。
日本人はプロセス改善が大好きだ。
現場で問題を発見して、現場の人たちが自主的に解決していく。
そのノウハウが品質管理につながり、日本の製品は品質がよいという神話につながった。

しかし、最近は品質管理の技法をあまり聞かないように思う。
CMMIやITILに押されているのが実情ではなかろうか？

製造業ならば品質保証部門は普通に存在するのに、SIerで品質保証部門やテスト部隊を抱えている所は少ないのではなかろうか？
つまり、SIerは受託開発専門が多いため、開発部隊が多く、テスト部隊は存在しないか軽視されてきた。

日本で行われてきたプロセス改善は、現場からのボトムアップのため、部分最適の罠に陥りやすい。
全体最適で行わなければ解決できない問題がソフトウェア開発には多いのではないか？

CMMIが一世を風靡し、大手SIの品質保証部門がCMMIをそのまま取り入れて、CMMIの推進部門になってしまったのは、日本のプロセス改善が理論的な体系になっておらず、全体最適の観点が漏れていたのではなかろうか？
日本の品質保証部門は、CMMIでプロセスを評価する部門に過ぎず、その役割が官僚化しているような気がする。
実際、開発部隊とテスト部隊はお互いに牽制しあっていて、信頼関係がないのが普通だろう。

あるいは、運用保守のプロセスを日本のSIがフレームワーク化できていないため、ITILのような海外の運用保守のフレームワークに乗っ取られたのでないか？
奈良さんの「ソフトウェア品質保証入門―高品質を実現する考え方とマネジメントの要点」は確かに内容は優れているし、現場で鍛えられたノウハウが入っていると思うが、正直整理されていないような印象を持っている。
ITILの観点を入れれば、運用保守のプロセスはもっと整理されて分かりやすくなるのではなかろうか？

でも、TestLinkでテスト管理してみて、日本の品質管理やテスト管理の技法やノウハウは生かせると感じている。
個人的には、TestLinkに日本の品質管理やテスト管理のノウハウを機能として実装してほしいと思う。

DOAや品質管理は、正直、今の日本人技術者は忘れている。
JavaやC#、クラウドやiPhoneなどに押されて、その技術が生かされていないように思う。
けれども、その技術はもう一度見直されてもいいと思う。