統合型プリプレス工程管理システムの開発
The Development of a Total Prepress Management System柳町則之＊Yanagimachi, Noriyuki

We have developed a total prepress management system that provides the production management essential to high productivity in a digital prepress workflow. This total prepress management system, consisting ofclient and server software, uses computer network and database technologies to deliver real-time information
on process activities and to control business workflow. Further, the system directly manages human operators,
file servers, and digital data.
In this paper, we report on a unique approach to the integration of management functions with a focus on
two newly developed technologies: "Action" and "Process Ticket", the former being a data access control
object and the latter a process control object.
これまで提案されてきた工程管理システムの多くは、

１ はじめに横軸系の管理を対象としており、縦軸すなわちDTP工程プリプレス工程では、DTP（Desk Top Publishing）をにおける個別処理を管理する機能を有していない（例：

中心にデジタル化が進展しており、現在、国内におけるDTP 化率は８割を超えている。DTP 化によって、制作を含めた印刷前工程の生産性は大幅に向上し、システムや機器のオープン化、低価格化といったユーザメリットも生まれた。しかし、Fig. １に示すように、DTP 化は、作業の属人性を高めるとともに、 管理対象の変化（実物からデータへ）を引き起こし、 デジタルプリプレス工程のブラックボックス化を招いた。 一方、管理・間接部門では、多くの印刷・製版会社において、今なお、現場のデジタル化に対応した管理手法を確立するには至っておらず、情報の共有性、リアルタイム性、再利用性が著しく低い。
我々の調査では、プリプレスに占める管理部門の人員割合は 25％にものぼっている。 短納期化、小ロット化によって、管理・間接業務の絶対・相対コストがともに増Fig.1 Today's production management circumstances of prepess

加傾向にあるなか、当該部門の生産性の改善が急務となっている。
Fig. ２にプリプレス工程の業務フロー例を示す。 横軸
はプリプレス工程の流れであり、受注した仕事は「入稿チェック」の後、「画像入力」を経て「DTP」工程へと移行する。縦軸はデジタル処理の流れであり、「DTP」工程において「色修正」「DTP 編集」「出力」の各処理が行われる。出力までの作業が終了すると、次の工程である「校正検査」に移行する。すなわち、横軸は業務伝票の流れでありアナログ工程、 デジタル工程が混在しており、いわば工程（プロセス）管理の軸である。 縦軸は、デジタルデータの実処理の流れであり、ソフトウェア処理とヒューマン処理とが混在しており、デジタル作業管理およびデータ管理の軸である。
Fig.2 A sample of prepress business workflow＊ MG カンパニー

MG 開発センター

GI システムグループ

KONICA TECHNICAL REPORT VOL.16（2003）

147

アスコン Progress Manager など）。横軸系管理においる当該ジョブの DTP 処理が可能になる（⑤）
。ても、製版・印刷会社毎にシステムが対応的に構築されこのように、本システムは、データベースの情報をもており、モデリングの柔軟性・汎用性が低い。また、JDFとに、クライアントとサーバが動作・機能する「データ（Job Definition Format）１） 等のジョブチケット技術をベース駆動型クライアント／サーバシステム」である。

ベースとする出力系ワークフローシステムは、デジタル作業管理システムに分類することが可能である。しかしソフトウェア群におけるパイプライン的用途を目的としているため、工程管理やヒューマン処理はカバーできていない。さらに、データ管理システムは、欧米のソフトベンダーを中心にアセットマネージメントシステムとして製品化されているが（例：米Xinet社 WebNativeなど）、これらはデジタルアーカイブの管理を目的に設計されたものであり、業務流動性の低いデータを対象としている。このため、入稿から出校・下版まで頻繁にデータがアクセスされる業務流動性の高い日常プリプレス業務には適していない。
本システムは新たに開発したアクションおよびプロセスチケット機構によって汎用的な管理モデルを構築する

Fig.3 System configuration

とともに、業務工程、デジタル作業およびデジタルデータを統合的に管理可能とした。 以下、各管理機能の統合化設計手法、汎用化設計手法およびフィージビリティースタディについて説明する。

２．２

アクションによるデジタル作業管理とデータ管理の統合

従来のデータ管理システムでは、作業対象のデータをファイルサーバからローカルディスクにダウンロードし２ システム概要て作業を行い、作業完了後、データをファイルサーバに２．１れていた。しかし、この方式では、ファイルサーバとアップロードするというデータアクセス制御方式がとらシステム構成本システムはサーバシステムとクライアントシステムローカルディスク間での大量かつ大容量のコピー処理がから成る。サーバシステムは、ファイルサーバを管理・発生し、時に数 G B に及ぶ D T P データでは十分なパ制御するデータサービスサーバ D S S （D a t a S e r v i c e

フォーマンスが期待できないばかりか、ファイルサーバServer）、データベースサーバ DBMS（DataBase Man-とローカルディスクにおいてデータが二重に管理され、agement System）
およびアプリケーションサーバの３ユ

日常の繁忙業務においては同期の管理が非常に難しい。

ニットで構成する。クライアントシステムは、各オペ

また、これまでのファイルサーバシステムで行われていレータの DTP 端末（Macintosh, Windows PC）にクライるグループ作業に対応できない。そこで、本システムでアントソフトウェアユニット DBC（DataBase Client）をはアクション機構を新規開発し、ジョブフォルダに対す組み込む。

るダイレクトマウントを動的に制御することにより、こ各ユニットの機能を Fig. ３に示す。ユーザがクライアント端末において「ジョブ」を処理する場合、 開始要求うした課題に対応するとともに、データと作業との統合的な管理を可能とした。

が要求元クライアント端末のDBCからDSSに対して発行先ず、本システムにおけるデジタルデータの管理手法される（①）。「ジョブ」はデジタル作業におけるデータについて Fig. ４をもとに説明する。 ２．１で述べたようの管理・作業単位であり、ファイルサーバ上に、実際のに、本システムは、実際の DTP データをデジタル作業にデータの格納場所であるジョブフォルダを有している。

おけるデータの管理・作業単位である「ジョブ」に格納す

DSS はアプリケーションサーバを経由して（②）データる。
「ジョブ」は「品目」に対して、「品目」は「顧客」にベースサーバに要求認証を行い、ユーザに当該ジョブの対して、それぞれ複数作成することが可能であり（顧客：処理権限があるか否かチェックする（③）
。認証処理をパ

品目、品目：ジョブの関係性はともに１：N）、「顧客」はスした場合、DSS はファイルサーバに格納されている当取引先、「品目」は受注品目に対応している。

該ジョブのフォルダをクライアント端末からマウント「アクション」はジョブ毎に設定され（ジョブ：アクショ（接続）できるよう、ファイルサーバの制御を行う（④）
。

ンの関係性は１：N）、作業担当者、作業種別、作業モー

この後、DBC によって当該ジョブフォルダがクライアンドといったデジタル作業に必要な各種の情報を包括したト端末にマウント（接続）され、クライアント端末におけ作業管理用のオブジェクトであると同時に、ジョブフォ

148

KONICA TECHNICAL REPORT VOL.16（2003）

ルダのアクセスを制御するデータ管理用オブジェクトで「誰が何のためにジョブフォルダにアクセスしているもある。Fig. ５にデータアクセス制御の原理を示す。

か（したか）」といった進行・実績情報を管理することができる。ユーザ毎に各アクションの作業パフォーマンスを計測、解析することも可能となる。
f アクションはジョブの処理ワークフローを管理・制御する。例えば、ジョブに「色修正」「DTP編集」「出力」の各アクションを設定すると、「色修正」のアクションが完了するまでは、次の「DTP編集」アクションに着手できないようにアクション操作の排他制御が行なわれる。特定アクションが未了のまま、次フローに移行することを防止できる。
g アクションによりデータアクセスが自動化されるため、直しなど他人の仕事を引き継ぐ際に、データの格納先を検索する必要がない。 また、ジョブ毎に誰がどこまで処理したかが記録されるため、引き継

Fig.4 Relationship diagram between jop-related objects

ぎ・段取り作業の負荷を大幅に軽減できる。
h 「バックアップ」「サーバデータ消去」「リストア」もユーザがDBCを利用して、アクションに対して「開始」アクションとして定義可能であるため、一般作業のコマンドを適用すると、アクションによって規定される処理フローにサーバ管理の作業を統一的に組み込むジョブフォルダが当該作業者のクライアント端末にマウことができる。

ント（接続）され、「中断」、「終了」コマンドを適用する

j 「バックアップ」アクションは「各ジョブが、誰にと、マウントが解除（切断）される。このように、本シス

よって、いつ、 どこにバックアップされたか」を記

テムでは、ファイル単位ではなくジョブフォルダ単位で録するため、バックアップメディアおよびアーカイのアクセス制御が、 マウント機構を利用して行われる。

ブの管理も可能となる。

以下にアクション機構の利点・特徴を示す。
a

データはサーバ上に一元的に管理されるため、クライアント／サーバ間でのデータの同期管理が不要

オーナ / オペレータモデルによる作業モデルの汎用化設計

前述したようにアクションは作業担当者と作業種別をであり、グループ作業にも対応できる。
s２．３

規定する。本 システムでは、ア クションの発行者をアプリケーションソフトからは、従来環境（ファイ「オーナ」、作業担当者を「オペレータ」として管理する。

ルサーバを常時マウント）と同様にデータにアクセ

オーナはアクションの発行者であると同時に管理者であスできる。 そのため、既存業務フロー、設備をそのり、アクションのライフサイクルに責任をもつ。アクまま適用でき、アプリケーションも選ばない。

ションに対するコマンドの適用は、オーナとオペレータd

ジョブフォルダに対するマウントが成立すると、アクションは作業種別と作業者を規定し、各作業のみ可能である（オーナ/オペレータモデル）。そのため、者の作業ログを自動的にデータベースに記録する。

管理外の不当なアクセスからジョブデータを保護することができ、事故の際の原因追跡や事故のそのものの発生を防ぐことが可能となる。
また、アクションに付加的に設定される「計画時間（＝作業の持ち時間）」と「予測累計時間（＝ 作業の見積り時間）」とを利用することによって、人的リソースの負荷量算出が可能となり、 日別、ジョブ別など様々な角度から負荷量を集計し、工程リソースの最適配分を実現することができる。
「計画時間」は入稿遅延や作業滞留などの業務状態に応じて、自動的にシステムによって算出・更新されるため、負荷量のリアルタイム計測が可能である。
アクションとオーナ/オペレータモデルによるデータア
クセス制御は、上記のような効果を有する反面、 無制限に誰もが全てのジョブデータにアクセスできる従来環境

Fig.5 Data access control by Actionと比較して、 業務の自由度を低下させる懸念がある。そKONICA TECHNICAL REPORT VOL.16（2003）

149

こで、 本システムでは、個人作業とグループ作業の２つい設計となっている。しかし、 実際の業務では、一つのの作業モードと、個人名とグループ名の２つの作業者指業務伝票によって規定された仕事は、デジタル工程にお定方法を設計し、 これらを組み合わせることにより、業いて実際の作業単位に分解され、それぞれが関連付けら務自由度が従来環境レベルに保たれるよう工夫を施してれて管理されている。特にページものでは、 一つの業務いる。具体的には、次の４つの方法で作業者すなわちオ伝票が、ページ単位をベースとする多数のジョブとデジペレータを規定することができる。

タル作業に分解される。 そのため、デジタル工程の進行

a

管理者は、プロセス内に対しては、 ジョブをベースとし個人作業モード／個人名指定

たリソース管理を行う一方、全プロセスの共通管理単位

特定個人をオペレータに指定sである業務伝票をベースに納期管理や他プロセスとの連個人作業モード／グループ名指定
特定グループにおいて最初の作業開始ユーザをオペ携を行う必要がある。 このように、デジタル工程では複レータに指定眼的な管理が要求され、非常に大きな業務負担となってdいる。

グループ作業モード／個人名指定

そこで、 本システムでは、ジョブの作業管理オブジェ

複数の特定ユーザをオペレータに指定fクトであるアクションとワークチケットのプロセス管理

グループ作業モード／グループ名指定
特定グループの全メンバーをオペレータに指定オブジェクトであるプロセスチケットとを関係付けるこ

また、アクションの発行者をメンバーに含む管理者とにより、ジョブ系の管理と伝票（ワークチケット）系グループをオーナとして設定することが可能である。の管理の独立性を保ちつつ工程管理とデジタル作業管理

この場合、アクションの発行者に加えて、オーナグルーを統合化した。各オブジェクトの関係性を Fig. ６に示す。

プの各メンバーに対しても共通にオーナ権限が与えられる。 そのため、アクションの発行は各管理者が個別に行い、管理はグループで行うことができる。日勤・夜勤などのシフト間においてオーナグループを構成し、業務の連続性を確保するといった運用が可能である。
２．４

プロセスチケットおよびアクションによる工程管理とデジタル作業管理の統合

製版・印刷会社の業務フローを分析すると、デジタル作業工程における仕事の単位と業務伝票が管理する仕事の単位が異なっていることがわかる。前者は初校から下版まで連続性をもって管理されているのに対し、後者は顧客からの入稿状況に応じて適宜変わり、初校から下版までの連続性がない。 従来の工程管理システムでは、アFig.6 Relationship diagram between key objects

ナログ工程、デジタル工程ともに業務伝票単位で管理されていたため、デジタル工程における管理が表層的となっていた。

２．４．２

状態連携

本システムではアクションをプロセスチケットに関連こうした問題に対応するため、本システムでは「ワーク付けることにより、アクション−プロセスチケット間でチケット」と「ジョブ」という２つの異なるオブジェクトの状態連携を行う。プロセスチケットの配信により関連を導入した。前述したようにジョブはデジタル作業工程するアクションがアクティブになり、アクションの状態におけるデータの管理単位であり、その配下にアクショの総和によりプロセスチケットの状態が決定・管理されンを有するオブジェクトである。これに対し、ワークチる。 例えば、プロセスチケットに関連付けられたアクケットは業務伝票を置き換え、全体工程を管理する。

ションが一つでも［作業中］の状態である場合、当該プワークチケットは、また、その配下に個々の工程（プロロセスチケットの状態も［作業中］となる。

セス）を管理する「プロセスチケット」を有している。
２．４．１

各オブジェクトの関係性

また、アクションはジョブに関連づけられ、 さらに作
業種別や作業担当者を規定しているため、 アクションをワークチケットとジョブは、ともに「品目」の下に対等経由することで、プロセスチケットとジョブ、作業種別、に作成される（品目：ワークチケット、品目：ジョブの関作業担当者とを関連づけて管理することが可能になる。

係性はともに 1：N）
。これは、ワークチケットとジョブとFig.５に各種作業情報をキーとしたプロセスチケットの再は、 直接的な関係性がないことを意味しており、初校か構成の例を示す。 例では、DTP プロセスチケット（P1）

ら下版まで連続性の有無の違いを吸収できる自由度の高はアクション１からアクション５と関連付けられている。

150

KONICA TECHNICAL REPORT VOL.16（2003）ジョブ、作業種別、担当オペレータのいずれのキーも、者負担が少ないため、管理業務そのものが全体のボトルアクションをベースとした状態管理がなされているため、ネックにならない。なお、本システムでは、作業担当者各キーの状態をアクション情報をもとにリアルタイムにがコンピュータ端末の操作を行えない環境にある場合を算出し、プロセスチケットの進行管理に利用すること可考慮し、プロセス管理者は作業担当者の操作を代行でき能である。

る設計となっている。

以上のように、デジタル工程の進行管理者は、アク２．５．２

サブプロセスによるアナログ作業管理ションをベースに実務管理を行うとともに、プロセスチ

また、アナログ工程では、プロセス内の作業別進捗状ケットを様々な作業情報をキーに再構成し、複眼的に進況を管理するため「サブプロセス」を設けた。プロセス管

行管理を行うことが可能である。

理者は、プロセスチケットに対しサブプロセスを選択的に付与することが可能である。また、サブプロセスには作業担当者を複数割り当てることができる。
Fig.８にプロセス管理に関わる各オブジェクトの関係性を、Table １および Table ２に、各オブジェクトに対する全体管理者、プロセス管理者、作業担当者の操作権限を、それぞれ示す。

Fig.7 Reconfiguration of Process Ticket

２．５

プロセスチケットによるプロセス管理モデルの汎用化設計

２．５．１

多層的管理者モデル

本システムでは、業務の流れに沿って段階的にプロセ

Fig.8 Relationship diagram between process control objects

スチケットの処理主体が変化する「多層的管理者モデル」を設計、採用している。
まず、ワークチケットの作成者は、「全体管理者」としTable1 Permission matrix, Create / Defineて当該ワークチケットに対しプロセスチケットを設定する。全体管理者は、各プロセスチケットの設定の際、「プロセス管理者」をプロセスチケット毎に設定する。本システムにおける「プロセス管理者」は各プロセスの進行管理者である。全体管理者がワークチケットをアクティブにすると、プロセスチケットが各プロセス管理者に配信される。デジタル工程においては、この後、前述したように、アクションと連携した進行管理が行われる。一方、アナログ工程では、プロセス管理者は受理したプロ

Table2 Permission matrix, Status update

セスチケットに対して「作業担当者」を設定し、作業担当者は、自身に割り振られたプロセスチケットの作業ステータスを入力する。作業担当者は複数割り当てることが可能であり（プロセスチケット：作業担当者の関係性は 1：N）、プロセスチケットの状態は作業担当者の状態の総和によって決定・管理される。このように、「全体管理者 ⇒ プロセス管理者 ⇒ 作業担当者（またはアクション担当者）」の順に段階的にプロセスチケットの処理主体が変化し、 管理レベルのブレークダウンが行われる。スキルおよび情報レベルに応じた裁量を各処理主体に与えることで、業務の硬直化と管理負荷の特定担当者

プロセスチケットがサブプロセスを有する場合には、への集中を回避している。 業務自由度が高く、かつ管理作業担当者の状態の総和によってサブプロセスの状態が、

KONICA TECHNICAL REPORT VOL.16（2003）151

サブプロセスの状態の総和によってプロセスチケットの状態が、それぞれ決定・管理される。このように、多機能作業のアナログ工程では、プロセスチケットがサブプロセスによって作業レベルに分解され、デジタル工程と同様に（注：デジタル工程ではプロセスチケットはアクションによって作業レベルに分解される）プロセス内の進捗状況を作業レベルで管理することが可能となる。

３ フィージビリティースタディによる妥当性検証
本システムの妥当性・有効性を検証するため、コニカの顧客である印刷会社数社にてフィージビリティースタ
ディを実施した。
システム導入にともなう現場負荷（運用負荷、操作負荷など）は、３時間の導入研修後、すぐにシステム運用を開始できるなど、 非常に軽微であることを確認した。全デジタル工程において、全業務を例外なくシステム配下で管理することができ、本システム環境と従来環境との複線的な業務運用や、 既存設備の流用などと合わせ、システムの基本性能の妥当性、業務適用性の高さを実証することができた。 現在、業務フローおよび業務体制の最適化に着手し、システムの導入にともなう経営的効果を計数的に確認中である。

４ まとめと今後の課題
以上、新規開発技術であるアクションおよびプロセスチケット機構を中心に、工程管理、デジタル作業管理、データ管理の統合化手法、各管理機能における汎用化設計手法、およびそのフィージビリティースタディについて述べた。
今後、アナログ工程におけるフィージビリティースタディを実施し、プリプレス工程全域に対するシステムの妥当性を検証するとともに、 汎用性、機能性をより一層高め、リアルタイムの PL 管理、工数管理を可能とし、効率経営のソリューションとしていく。
●参考文献
１）JDF Specification Release 1.1, CIP4 Organization

執筆者注：
本研究報告は、印刷学会「第 108 回春期研究発表会 予稿集」に掲載された論文を、 印刷学会の許可を受けて、転載したものです。 ただし、趣旨を変えない範囲での加筆と図表の補強を施しています。

152

KONICA TECHNICAL REPORT VOL.16（2003）