HOME会社概況業務内容開発分野開発事例CANモジュールソフテックだよりお問い合わせ
HOME > 開発システム事例 > Notesシステム開発「ISO文書管理システム」

開発システム事例

Notesシステム開発「ISO文書管理システム」

1. はじめに

ISOにおいてはISO文書すなわち品質記録の管理が重要となります。
2007年3月6日にISO9001を認証取得いたしましたが、その際にISO文書管理システムをどのように構築するかが大きな課題でした。
ISO文書を管理する上での課題はISO9001の要求、および実際の運用を考慮すると以下のようなことがあります。

  1. 複数の人員がISO文書を支障なく作成し、維持できること
  2. 作成したISO文書は読みやすく容易に識別可能であること
  3. 検索可能であること
  4. 保管期間および廃棄について管理できること
  5. 保護されること
  6. 個々のISO文書について審査・承認が可能なこと
  7. 文書量が膨大となっても識別・検索・保管・保護について支障がないこと
  8. 権限の管理が容易に出来ること

これらを満足するISO文書管理システムを構築することはなかなか大変です。
当社ではNotes I を用いてシステムを実現しましたが、どのように考えてシステムを開発したのか、その特徴と共に以下に紹介します。

2.保護されること

前項で掲げた課題の内の5については本ISO文書管理システムを開発する以前に当社のNotesシステムレベルで解決しています。
Notesには複製 II という機能がありますが、これを利用して良好に保護できるシステムを実現しています。
具体的にはNotesシステムを4組立ち上げ、4組を互いに複製するように構築しています。
同じNotesシステムが4組存在するわけです。
その内の2組は東京都に、もう2組は青森県に立ち上げました、その上で、インターネット経由で常時複製しています。
相互にバックアップとなっていて、自然災害による建物の倒壊や火災があったとしても4組全てが利用不能・復旧不能となる可能性は限りなくゼロに近いと言えます。

3.文書量が膨大となっても識別・検索・保管・保護について支障がないこと

Notesシステムを選択したことで課題の1、4、6、8は自動的に解決の見通しが立ちました。
その結果、5を除外すると残った課題は以下の3つになります。

  • 作成したISO文書は読みやすく容易に識別可能であること
  • 検索可能であること
  • 文書量が膨大となっても識別・検索・保管・保護について支障がないこと

その中で、初めに検討しておくべき課題は「文書量が膨大となっても識別・検索・保管・保護について支障がないこと」という点です。
単一のNotesデータベース(以降ではNotesDBと略します)でISO文書管理システムを構築するのはソフテックの事業規模から考えて無理があります。単一のNotesDBに収まるような文書量ではないからです。必然的に複数のNotesDBで構築することになります。

次に複数のNotesDBで構築する場合もいくつかのやり方が考えられます。ここでは2つ掲げます。1つは、SO文書の種類毎にNotesDBを分ける方法。例えば、顧客要求仕様書のNotesDB、開発計画書のNotesDB、レビュー記録のNotesDBというようにそれぞれ専用のNotesDBを作る方法です。
もう1つは、仕事のプロジェクト単位あるいは仕事のシリーズ単位などで分けてNotesDBを作る方法です。

前者は依然として容量不足で破綻する危険性を排除できません。また、「読みやすく容易に識別できなければならないこと」を考慮するとプロジェクト管理者や担当者の立場に立てば後者のほうが理想的です。
基本的な考え方として当社では後者の仕事のプロジェクト単位あるいは仕事のシリーズ単位などで分けてNotesDBを作る方法を選択することにしました。

さて、ISO9001における管理責任者の立場に立ったらどうでしょうか、管理する立場ですから全プロジェクトのISO文書の作成状況が一覧で見ることが出来ればベストです。しかし、複数のNotesDBに分散していてはそれもままなりません。立場の異なる視点から見ても良好なシステムを構築するのはなかなか容易ではありません。

NotesDBにはドメイン検索という機能があり、複数のNotesDBを横断的に検索できます。この機能を使えば「検索可能であること」が解決できます。しかし、検索する上での利便性は単一のNotesDBで適切にカテゴリ分けされたビューに加えてデータベース内の検索を利用できる環境に比べると遠くおよびません。
その意味で検討の余地があります。

4.インデックスDB

図1.ISO文書管理システムの構造と動作概要
図1.ISO文書管理システムの構造と動作概要

さて、この問題を解決するために考えた方法がインデックスDBという概念です。
仕事のプロジェクト単位あるいは仕事のシリーズ単位で作るNotesDBをISO文書管理DBと呼ぶことにした場合、複数のISO文書管理DBの各々に多数のISO文書が登録されることになります。

それらの全てのISO文書を作成し、保存したときに自動的に基本データのみを別の単一のNotesDBに転記するようにしておけば、全てのISO文書の情報が網羅できます。この単一のNotesDBをインデックスDBと名付けました。

具体的には図1に示すような構造になります。
こうすることで管理責任者が苦労することなく全プロジェクトにおけるISO文書の作成状況を把握できる環境が構築可能になります。
ここで容量を抑えるために転記する基本データは極力少なくすることがポイントとなります。
その意味で、明細データや添付ファイルは転記しません。

図2.ISO文書管理システムの動作詳細
図2.ISO文書管理システムの動作詳細

5.文書番号取得

こうしたインデックスDBの利用だけでは「作成したISO文書は読みやすく容易に識別可能であること」という課題をまだクリアできたとは言えません。
例えばインデックスDBのビューに同じような文書名が出てくることは日常茶飯事であり、常時識別が容易というわけには行きません。
それを解決するために全てのISO文書に対してユニークな文書番号を振ることにしました。文書番号によって個々のISO文書を識別しようと言うことです。

その実現方法については図1、図2に示すようにインデックスDBが単一のNotesDBであることに着目して、ユニークな文書番号を割り振る役目をも担わせることにしました。
全てのISO文書管理DBにおいて全てのISO文書を作成する際にインデックスDBに対して文書番号を要求します。
インデックスDBは要求を受けた全てのISO文書に対して重複しないようにユニークな文書番号を割り当てます。
そのようなアプリケーションをISO文書管理DBとインデックスDB内に作り込むことで実現しました。

6.インデックスDBに登録されないISO文書

実は全てのISO文書がインデックスDBに登録されているわけではありません。ISO文書管理DBの対象となるISO文書は受注した仕事、すなわちプロジェクトを推進する通常の過程で作成されるISO文書です。
例えば以下のようなNotesDBはISO文書管理DBと別に独立して存在しています。

  1. 不適合通知、是正・予防処置報告 管理DB
  2. 借用品 受入検査記録DB
  3. 供給者一覧DB
  4. ISOアンケート集計DB
  5. クレーム報告DB

多くはISO9001認証取得以前に存在したデータベースですが、ISO9001認証取得に伴って改造を施しています。こうしたデータベースに格納されているISO文書を含めて必要な文書にユニークな文書番号が割り振られるようにしました。

7.督促メール送信システムの設置

2007年3月6日にISO9001認証取得をして、はや3年が過ぎようとしています。その過程でいろいろな問題が発生しましたが、その中の1つにISO文書の審査・承認が行われずに放置されてしまうということがありました。
なぜ審査・承認が行われずに放置されているのか確認してみると、いろいろな原因があるのですが、結果的に本人が放置していることを認識していないケースが多々あることが分かりました。

また、自身が審査・承認せずに放置しているISO文書があるかどうか、それぞれのデータベースを時々参照してチェックすれば良いのですが、審査・承認を担当する立場の人たちは繁忙のためにその余裕もありません。
であれば、督促することも有効であろうと考え、督促メールを送信することとしました。
この機能を実現する上において、当初は個々のデータベースに各々専用の督促用ソフトを組み込むことを考えました。

しかし、それぞれのデータベースで管理している審査依頼中・承認依頼中などの状態の種類が豊富であり、個別にソフトを組んでいたのでは開発に掛かる工数が大きなものになる、また、ソフト量も増えてメンテナンス性も悪くなる、などそのまま開発を推進することに戸惑いを生じました。
検討を重ね、最終的に督促を行う専用のデータベースを作るという案にたどり着きました。
具体的には他のデータベースの状態を監視して督促すべき状態を検出したら督促メール送信するシステム(データベース)の開発を行いました。
督促メール送信システムにおいて新たに督促を設定する場合は、概略以下のような内容を設定します。

  1. 督促を行う期間
  2. 最初の督促を行う経過日数
  3. 2回目以降の督促を行う経過日数
  4. 最大督促回数
  5. 対象DB名
  6. 検索に使用するビュー名
  7. 督促を行うべき状態にあるかの判断式(フィールド名 III と式言語 IV で記述)
  8. 経過日数を判定する対象となる日付フィールド名
  9. 督促メールの宛先
  10. 督促メールのCC:
  11. 督促メールの件名
  12. 督促メールの本文

このシステムはISO文書を格納しているデータベースにおける審査・承認を改善するための督促機能として開発しましたが、汎用的に使えるように開発したので以下のような副次的なメリットも発生しました。

  1. ISO関連以外の既存のNotesDBや今後新規作成するNotesDBに督促機能を組み込む場合にも使え、設定を行うだけで実現できるので、開発の手間を減らせる。
  2. 督促機能を追加する上での技術的なハードルが下がって担当者の選定が楽になった。

8.まとめ

NotesによるISO文書管理システムについてご紹介しましたが、現状でも、私たちはこのシステムに日々改良を加えながら利用しています。
その意味でまだ完成したシステムではありません。
しかし、必要欠くべからざるものになっており、本ISO文書管理システムは基幹システムとしてソフテックの品質マネジメントシステムを支えています。

(K.S.)

脚注記号 用語 説明
I Notes Lotus Development社が開発したグループウェアという種類のソフトウエア。文書共有、電子メール、電子掲示板などの機能を持つ。ユーザがカスタマイズして利用できる。Lotus Development社は1995年にIBM社に買収され、ロータス(Lotus)というブランド名として残っている。
II 複製 Notesデータベースを複数の拠点で利用する場合、データベースを複製してそれぞれの拠点に配置することが出来る。どこかの拠点で入力すると他の拠点に反映される。
III フィールド名 Notesの文書の中は例えば宛先、件名、本文というようにいくつかの領域に分かれています。この領域のことをフィールドと呼びます。
IV 式言語 Notesはソフトを組み込むことが出来ます。そして、その際の言語は式言語とロータススクリプトの2種類があります。式言語は変数の評価など簡単なロジックを実行するのに向いています。

関連ページへのリンク

関連するソフテックだより