コンカレントとは同時とか並行といった意味です。「コンカレントエンジニアリング」と言いますと、設計から生産まで、複雑な設計情報を共有しつつ、開発の時間短縮や効率化を図ることです。しかも分散的で非同期、かつ協調的なプロセスを目指すところがポイントです。何というか、センター指向ではありません。
情報共有やコミュニケーションのシステムですから、協同作業（コラボレーション）と非常に近い概念ですが、設計開発上の概念が、（いわば）文系部門の文書管理やワークフローの改善に応用されたということだと解釈しています。後程説明しますが、CALSやITのキーコンセプト、あるいは源流のように思われます。名詞ならコンカレンシです。
筆者が取組んできた経緯や意図は、基本的にWeb「日本の考古学リソースのデジタル化」で示している通りですが、換言すれば、埋蔵文化財や考古学の世界に、コンカレントなやり方を持込みたいというのが、究極の目標になります。
筆者の興味の発端はハイパーテキストでした。電子化によって多くの文書やデータを連繋的に取扱うことが憧憬でした。それには、自在なリンク／アクセスのソフト的なプラットフォームに加え、オンライン化が必要だったわけです（ディスプレイの高画質化・大画面化、マシンの高性能化も関係あります）。ハイパーテキストは、少なくとも典型的なデータベースとは異なる概念です。
ハイパーテキストの歴史を簡単に振り返りますと、1945年Vaneever BushのMemex、1965年Ted Nelsonのハイパーテキスト、1968年Doug EngelbertのNLS（オンラインシステム）、1987年Bill Atkinson（Apple）のハイパーカード、そして1991年Tim Berners-Lee（CERN）のワールドワイドウェブ（その文書フォーマットがHTML）ということになります。（この流れだと、1968年Alan Kayのダイナブックも挙げておいた方がいいでしょう）
電子出版（電子書籍）の歴史は、Expanded Book（日本ではエキスパンドブック）に始まるといっていいでしょう。Expanded Bookのプロジェクト（1990年〜）はパワーブックの登場（1991年）によって急速に実現に向ったそうです。最初のExpanded Bookはハイパーカードのアプリケーションでした。こうしてみると、1991年は画期だったようです。
但し、ハイパーテキストの観点からしますと、電子書籍はハイパーテキストの連鎖にわざわざ囲いを設けるようなところがあります。電子書籍は、コンカレントの要求とは、今でも緊張関係にあるようです。電子書籍は、コンカレントなフローと整合的であれば、何とかなるかもしれません。
HTMLは、ハイパーテキストとオンラインを統合的に扱う、実にシンプルで強力な考案でした。HTMLとブラウザの普及は、1995年頃が境になるでしょう。HTML2.0の制定が1995年です。Windows95は独自ネットワークMSNを構想していたのですが、直ぐにWebに軌道修正します。
電子書籍は徐々に事業化されつつありますが、最近はExpanded Bookの発展形であるT-Timeやドットブック、またザウルスなど様々な勢力によってPDA対応も進みつつあるようです（2002年はPDA版電子書籍の普及元年になるかもしれません）。これらは、デバイス指向という感じもあるのですが、やはりHTMLこそ文書の電子化を普及させた立役者です。HTMLは極めて標準指向です。電子書籍のデバイス指向でも、HTMLベースのフォーマットが世界的には主流かもしれません。
HTMLの隆盛は、その母体であるSGMLの改良を促し、SGMLの改良版であるXMLを産み出しました。今度はXML文書を母体として、閲覧環境に合わせてHTML化したり、PDF化するという方向性も出てきました。HTML自体もXML化されつつあります（XHTML）。
報告書の電子化は、結局1997年のAcrobat日本語版登場を待って、はじめて実現に踏み切りました。もちろん、HTML系もできる限り取組むようにしてきました。
ハイパーテキストの夢は、HTMLやPDFによって現実のものとなったと締め括ることができます。でも、これは道のりの一つにすぎませんでした。CD化は最高レベルのデータ保存性も意図していたのですが、ナローバンド時代のやむをえない選択でもありました。
ご存知のように2001年は日本でのブロードバンド元年になりました。高速であると同時に、常時接続であることが、状況を大きく変えます。今はブロードバンドの第一世代ですが（かなり幅がありますが、実効速度１Mbps前後のオーダー）、将来は桁が上がり、ローカルディスクと同等速度の、いわばブロードバンド第二世代、さらにローカルメモリと同等のブロードバンド第三世代も予測されます。
コンカレンシは情報交換を目指しますから、一番プリミティブな要素はテキストです。テキストといえば文字コードです。どの文字（字形＝グリフ）を選び、どういうコード体系（エンコーディング）で、どのコードポイントに割りふるかの問題です。但し字形はフォントによって異なるので、厳密にいうとコードの対象は文字の概念ということになっています。規格表に字形が示してあるのは、その文字の字形の例を示していることになります。JISの漢字コードの正式名称は「情報交換用漢字符合」です。最初から「交換用」と入っています。表示や印刷ではないのです。
JIS漢字コードの第一水準・第二水準・記号（非漢字）は、JIS X0208に定められていますが、合計7479字に限られています（ちょっと説明を端折りますが、78JIS、83JIS、87JIS、90JISと改訂を重ねており、後二者が0208です）。これでは数が足らんと、よくいわれるわけですが、不足問題の解決は一筋縄ではいきません。独自拡張だけだと、機種依存文字になってしまいます。実は1990年に補助漢字という規格（JIS X 0212…非漢字含めて6067字）も制定されたのですが、これは失敗したとされています（Windows98以降ではフォントは実装されています）。0208と0212を合わせれば、漢字だけで12156字です。
そこで新しく2000年に制定されたのがJIS X 0213、いわゆる2000JISです。第三水準・第四水準となっています。これが非漢字も含めて合計4344字あります。0213は0208（第一水準・第二水準）も含んだ規格ですが、0212（補助漢字）と同時に使うことはできません（補助漢字と重複が多いが、3144字は除外された）。0213は合理的に作られており、成功を期待されている規格ですが、既存の機種依存文字とバッティングするために、普及が足踏みしている状態です。結局ユニコード化することで、普及するだろうと言われています。0208と0213を合わせて、漢字だけで10040字です。
一方、ユニコードないしISO10646という規格も出現しています（両者は起源的には同一ではありませんが、ユニコードが10646に採用された経緯があります）。ご存知のことと思いますが、CJK統合漢字として20902字が制定されています（ユニコード2.0）。この中には第一水準・第二水準と例の補助漢字が含まれています。その後ユニコード3.0で拡張漢字-Aが6582字追加され、ユニコード3.1では拡張漢字-Bで42711字が追加されたそうです。全て合わせると、70195字になります。なおユニコードにはUTF-8、UTF-16、UTF-32の別があり、今後の主流はUTF-8と言われています（OS内部での処理は異なります）。
OS内部的には既にユニコードが使われており、Windowsでは例の補助漢字のフォントも用意されていますので、第一水準・第二水準と合わせて利用可能になっています。しかし、コードはともかく、補助漢字は全てのOSで標準装備ではなかったので、現状では機種依存も同然の状態です。
Mac はOS XでOpenTypeで2000JIS（JIS X 0213）が実装されました（ということは補助漢字の多くも含まれている）。OpenTypeのヒラギノ・フォントは（非漢字含み）約２万字用意されており、内部的なアクセスはユニコードです。OS Xネイティブでユニコードにアクセス出来るアプリケーションは現状では限られており、InDesignとEGWordだけのようです。
情報交換を考えると、文字コードを何とかしないといけないのですが、上述のように非常にやっかいな問題です。レガシーといいますか、下位互換性が非常に重視されるのが文字コードの世界です。しかも漢字の世界は、決して文字コードだけでは解決しません。異体字と包摂の問題です。これはユニコードでも解決しません。
ちょっと奥の手ですが、フォントを切替えて第一水準・第二水準のJISコードを使い回しする方式でコードの制約を逃れると、収録文字数は無制限になります。現在12万字を収録した今昔文字鏡と、現在67527字を収録したGT書体があります。これらは便利な存在ですが、フォント依存なので、専用のフォントでしか使えません。コンカレンシの観点からは問題があります。デザインも明朝のような、そうでもないようなデザインになっており、通常のフォントと混在すると違和感があります。そう、これらはまさに字形（グリフ）にコードをふった体系なのです。文字鏡はグリフのコード（文字鏡番号）であって、文字コードではないというわけです。
印刷や見た目だけを考えれば、文字の画像を貼りこめばいいし（外字でも同じこと）、文字を画像の一種だと考えれば何でもないのですが、情報のデジタルフローは、そこで一旦止まってしまいます。印刷物を読んで、ユニコードにも無い字を再現（入力）しようとしたら、また外字作成か、今昔文字鏡／GT書体を使うしかありません。
HTMLなどの書式付きテキストならば、フォント指定可能なので、何とでもなるともいえます。ただ、今昔文字鏡／GT書体は、ローカルマシンにフォントをインストールしている必要があります（無償配布）。常時接続環境であれば、URL指定で文字画像をサーバからとってくることもできます。
埋蔵文化財調査や考古学の世界を俯瞰して、下記のようなダイアグラムを考えてみます。この全てをリサーチフローとします。
(1) 現場→ (2) 整理→ (3) 報告書→ (4) 研究→ (5) 発表
もちろんフィードバックの矢印など、もっと細かく適切な分析も可能かもしれません。デジタル化とは、このフローのコンカレント化を目指すということです。それには環境、ツール、データフォーマット、制度など、多様な取組みと改革が必要になるでしょう。
(1)〜(3) には調査機関という場があり、 (5) には研究会／学会という場があります。グループやチームには、グループウェアが適用できるはずです。
報告書電子化は、このフローの中では重要な結節点ですが、全体構想の一部にすぎません。従来は全て紙ベースでしたし、必要とあれば情報の存在する場所まで交通費をかけて出掛けていく必要があります。これは、やはり一種の貴族主義です。第一、報告書は最も重要で欠くべからざるものであるにも関わらず、部数は限られ、しかも書庫は溢れかえっています。つまり、報告書は稀少性と余剰性の二面性を帯びています（この難問を電子化で解決しようというわけです）。
古い話に戻りますが、取組みの当初は、個々のプロセスのデジタル化から始まりました。ワープロ導入も大きいかもしれませんが、トータルステーション導入は現場電子化の端緒でした。これで遺物のプロット作業がデジタル化され、測点のデータを作図に結び付けることが次の目標になりました。このあたりはCADの範疇です。出版といえばDTPですが、DTPのフォーマットといえばポストスクリプトなので、図をポストスクリプト化することが次の目標になりました。データは何でもDTP化しやすいように用意する方向にあります。
DTP化が基調となってきたのですが、印刷を終点とする思想は、データ（ファイル）の整理、保管、再利用に少々無頓着なところがありました。やはり、汎用的で系統的なデータ保全が課題になると思います。
例えば（印刷業界では常識の）CMYKの写真データには汎用性がありません。あれは良好なポジをスキャンして印刷データとするだけの存在です。やはりRGBで、シャープネスをかけていないデータがベースになります。従来型の写真はPhotoCDにしておくしかありませんが、これからはデジタルカメラ（当然、データはRGBベースです）が主流になるでしょう。2002年現在入手可能な機材で、それは可能になっていると思います。自分としては、フィルムに戻るつもりはありません（もはや暗室にも戻りませんが）。
研究プロセス (4) には、データ収集や論文作成支援の意味があります。データ収集といえば、データベースへの憧憬です（メタデータを自動収集することで解決したいのです…詳しく論じたいのですが次の機会に）。論文作成支援には、文献閲覧と引用文献リスト作成の自動化などがあります。文献閲覧は、電子図書館の範疇になるかもしれません。
ちなみに電子図書館は設備のことではなく、機能を指しています。個人からすれば電子本棚です。将来のマイ電子本棚は、Web上に存在することになると考えます。そうした時代のローカルな統合環境を、仮にArchaeological Desktopと名付けています。もちろん、その大部分は未だ姿を現わしていません。
発表プロセス (5) には、コミュニケーションの場と媒体（雑誌とセッション／シンポジウム）の意味があります。 セッションのデジタル化には、ビデオのストリーミングが効くでしょう。第１回の技術研究会は、オンデマンドのストリーミングを公開しました（要旨集購入者の特典という方式になっています）。
コンカレンシを目指して埋文の電子化が進む前に、電子政府・電子自治体の流れが現実化しつつあります。電子政府というとSF的ですが、要するに行政の電子化です。一番熱心だったのが、CALSの概念を守り通した旧建設省の建設CALS/ECです。CALS/ECは「公共事業支援統合情報システム」の略称だそうですが、勿論ほんとは違います。
CALSは不思議な言葉で、元来は米国防省の電子購買システムのことなのですが、その後様々に概念や適用範囲が拡張され、頭文字はそのままに中味が書き換えられています。
1985 Computer Aided Logistic Support
1988 Computer-aided Acquisition and Logistic Support
1993 Continuous Acquisition and Life-cycle Support
1994 Commerce At Light Speed
当初は文書の電子化に端を発するようです（兵器のマニュアルの頁数が膨大になり、物理的な重量が深刻な問題になったとされています）。CALS自体は資材調達に関わる文書の電子化プロジェクトだったようですが、底流にあるのはコンカレント・エンジニアリングの思想ではないでしょうか。CALSでは、設計・開発・生産・流通・サポートまで一貫した情報共有システムを目指しています。その後CALSは、コンピュータ活用のバックボーンとして、キーワードと化していきました（だからこそ頭文字は変わらなかった）。購買が軸になっていたせいか、Electronic Commerce（電子商取引）とも結びつきました。今日のアメリカの競争力の根源はCALSにあるとも言われています。ITも実際の意味はCALSと殆ど同じです。
CALSは、情報共有の都合上、データフォーマットの標準化を促しました。SGML／XMLもそれゆえに注目されていたわけです。
建設CALSの動きはe-Japan構想ともリンクしていますが、電子納品は2001年度から徐々に開始しています。最初は国の直轄事業からですが、当然地方自治体にも展開が予定されています。電子納品の主な要素は、以下のようなものです。
図書類は、報告書（REPORT）の他、施工計画（PLAN）や打合せ簿（MEET）、写真、図面、その他で構成されています（厳密な表現ではありません）。文書フォーマットはXMLを目指しているけれども、実際の運用はPDFになっているようです。但しPDFと同時にそのオリジナルデータも収録することになっています。現状でXMLが成功しているのは写真だけと思われます
※参考文献は基本的に省略しますが、キーワードをGoogleで検索していただければよいかと思います。