これからの技術者のドキュメントについて０．総論　「国際化時代・21世紀に向けて」という観点から題記テーマを論じる上での重要な視点として、第１に技術者を取り巻く環境の進歩発展を十分に考察すること、第２に技術者自身の側にも大いなる変革が求められていくこと、という２点をまず指摘したい。前者の環境の進歩発展とは、一言で言えば技術者のあらゆる仕事のコンピュータ化であり、具体的には高度な作業支援システムを含む、各種の業務領域を統合したフルＥＷＳ化として実現されていくものと思われる。また後者の技術者の変革とは、技術環境の推移に対応して、特定分野のエキスパートから総合的なエンジニアリング・プロデューサーへと変化する、技術者自身の業務への要求であり、本論のテーマであるドキュメントはその直接の対象として密接に結びついている。そこでまず、この２つの視点に基づいて、これからの技術者が関係していく業務領域を６種類のフェーズに分けて、それぞれの段階における技術環境および技術者の姿と、その具体的な結果であるドキュメントについて考察し、これに続いて、国際化時代における日本人の科学技術に関する考察を試みることにする。１．企画フェーズ　技術者の仕事をもっとも単純化して言えば、新しい技術に基づく製品・システム・サービス等を、社会一般へ提供することである。ところで、新製品を世に発表する際に、いかにして対象となる人々に受け入れられやすい製品にするか、という「ニーズ」を考慮した企画戦略は非常に重要である。本節の「企画フェーズ」とは、とくにこのニーズ指向の部分に関する企画業務領域を対象としている。技術者がこの領域に関与する必要性は、これからの企画部門がワークステーション上に構築する企画検討用データベース、という一種のドキュメントを想定してみると容易に判明する。つまり、国内や海外から刻々と得られる市場調査データや同業他社・他業種の動向の情報、あるいは消費傾向と関係する経済・文化・社会状況の分析データ、そして現在の事業展開情報や現行機種の資料などがＥＷＳ上に蓄積され、企画部門の業務は、このデータベースを対象とした詳細な分析・検討へと推移して、従来の新聞やカタログのコピー作業などは激減する。さらに、このデータベースをもとに新製品企画のアイデア候補を多種にわたって自動抽出するようなシステムの出現によって、同じコンセプトから複数のターゲットの製品ラインナップを同時に発表することが可能になるが、これは価値観の多様化時代に適した有効な戦略である。このような状況になると、従来の専門分野の枠内に留まった姿勢ではニーズや企画情報が生かされないために、技術者自身の業務に対する発想の転換が必要となる。たとえば、システム設計の途中でＬＡＮを介して企画データベースにアクセスし、必要な市場ニーズ情報を自分のＥＷＳに取り込んで仕様書に反映させながらシステム設計を行なうとか、現行機種の仕様に関するドキュメントをアクセスして、ソフト体系の上位互換性を確認しながら周辺機器との接続仕様を検討する、といった作業が自然に行なわれなければならない。そして場合によっては、企画データベース内の生データを自分の想定した分析手法によって検討し、新たなニーズ企画を創造・提案していくような柔軟な参加も求められるようになる。以上のような意味で、技術者が企画フェーズに関係することは、技術者自身の位置づけの向上とともにより重要になっていくものと思われる。２．研究フェーズ　前節の企画フェーズがニーズ指向の立場からの企画業務であったのに対して、この「研究フェーズ」とは、技術先導型のシーズ指向による企画分野として、技術者がより密接に関係する領域である。その対象は技術領域のあらゆる情報であり、従来ならば独立した研究部門の技術者が専門に担当した分野であるが、これからの技術者はこの研究フェーズもまた、業務の一端として関与していく必要がある。いくつかの例を示すと、たとえば現有する工業所有権や他社の特許状況に関する調査・分析データは、将来の特許紛争の際の資料というよりも、製品企画・仕様検討のために個々の技術者が参照するドキュメントとして、ＥＷＳ上にデータベース化される。あるいは、関連する技術分野の最新状況や、海外文献の自動翻訳による概説抄録、各種の学会論文や研究機関の研究報告などについても、ＬＡＮと接続されたファイル装置から必要な情報が検索できる環境となる。また、各種の国際規格や規制・規則等の状況調査などは、試験・検証・保守といった業務に欠かせない技術情報であり、それぞれの作業環境となるＥＷＳから随時アクセスできることが必要である。さらに、新しいデバイス・装置・システム等に関しては、提供側からのデータシートやマニュアルとともに、サンプルに対する評価試験の結果や、カタログデータに載らない情報・実験から得られた経験則・使用上の注意や特殊なクセ・他の類似システムとの比較、といった、担当技術者ならではの微妙な情報こそが重要である。従来は個々の技術者に頼ったこれらのノウハウが、共通の技術情報データベースに供給されることで、個人では対応しきれない情報過多の時代への解決策ともなる。このように、研究フェーズの結果は、それ以降の各段階への基礎情報として参照され、さらには新しい技術によるシーズ企画の源泉となるものでもあり、「必要な情報の検索や分析がスムーズに行なえるようなデータベースシステム」という巨大なドキュメントの構築が鍵となる。３．設計フェーズ　従来の設計作業というと図面やコーディングを連想するが、本節の「設計フェーズ」とは、ＥＷＳを支援ツールとした基本的なシステム構築作業であり、その中心は、仕様検討・仕様書作成という、まさにドキュメント化の作業である。ここでは、企画部門の人から与えられた仕様に従って設計するだけ、という従来の姿勢の技術者は駆逐されていく運命にある。最近よく指摘される話題に、企画－設計－開発－生産という流れの中でコンセプトが散漫になっていく、という現象があるが、これは各段階で情報が散逸する結果であり、製品の操作性の低下や機能の不備、時には致命的なバグの誘因となる場合すらある。しかしこの問題点は、技術者が検討・作成する開発仕様書がマニュアルの原稿でもある、言い替えればテクニカルライターを兼ねた技術者による仕様検討、という首尾一貫した業務形態が生まれることで克服されていくと思われる。つまり、企画部門からのコンセプトを企画サイドとユーザーの両方の視点から理解した上で、周辺の技術的状況をふまえて全体の機能仕様を客観的に検討し、これを「開発仕様書」というドキュメントの形に表現する、という技術者の業務が登場するのである。もちろんこのためには、ＥＷＳ上で対話的に確認しながら構築を支援する環境や、機能仕様の記述に使用される記述形式や記述言語の標準化が不可欠であり、さらには自然言語による記述から標準化言語の記述への自動変換システムの実現も期待される。この開発仕様書に求められる性格は、機能仕様・システム仕様の概略を技術者の立場から規定した骨格となるべきもので、ハードウェアに関する部分をさらに具体化すると回路図になり、ソフトウェアに関する部分を具体化するとフローチャートになり、動作機能に関する記述を一般ユーザー向けに整理するとマニュアルになり、個々の詳細な仕様条件を数値化すると検査仕様書になる、といったものである。そして、ＥＷＳ上でこれらのドキュメント類を有機的に結びつけることによって、仕様変更・バグ対策・バージョンアップといったドキュメント修正の際に、相互の矛盾や不統一を避けるうえで、きわめて有効な体系を実現することができる。また、製品イメージや操作性を評価するための、プロトタイピングツールとしてのシミュレーターとしてＥＷＳを活用することで、具体的な開発段階に移る前にあらかじめ全体像を把握できるメリットもある。このように、設計フェーズとはこれからの技術者の本領が発揮されるべき、重要なステージとなるものと思われる。４．開発フェーズ　設計フェーズでのシステム構想を受けて、本節の「開発フェーズ」では具体的な開発作業を担当するが、これは現在でも少しずつ実現されてきているために、内容は比較的容易に想像できる。詳細開発という言葉から連想される、回路図描き・プログラミング・デバッグといった従来の作業でなく、これからの技術者の開発とは、ＥＷＳ上の支援ツールに対する操作が中心となる。まず最初には、機能的要求を実現するためのハードウェアとソフトウェアのトレードオフについて、対話的に検討するための支援ツールが起動される。システムのどの部分をＣＰＵのソフト領域とし、どの部分をハードとして実現するか、という検討が、機能モデルの動作予測や開発期間・費用の予測データのもとで行なわれ、ＣＰＵの選択やＡＳＩＣ化を含めた構成の青写真が、技術者の判定によって決定される。次に、ハードの開発の面では、開発仕様書から全体の入出力信号に要求される仕様を抽出して、ここから必要な部分のディジタル回路を搭載したカスタムＬＳＩを自動設計するＣＡＤシステムが起動される。少量多品種製品の場合であれば、ＡＳＩＣでなくＰＡＬやＬＣＡを使った回路として、必要な論理設定プログラムが自動生成される。全ての部品を含めた回路設計と基板の設計も自動化され、設計ツールを操作する技術者の仕事は、ＥＷＳ上に示された自動設計結果に対する評価と指示に比重が移る。ハード関係のドキュメントとしては、ファウンドリとの接点となるＬＳＩの設計データ・テストデータ、基板の回路パターンデータ、製造ラインの自動制御のための回路データなどが出力される。また、ソフトの開発の面では、開発仕様書から機能仕様を抽出して、構造化設計に対応した基本フローチャートを自動生成するツールをまず起動し、対話的に修正しながら完成させる。さらに詳細な部分のソフトについては、高級言語やさらに上位の自然言語のレベルによって記述されたソースプログラムが、そのまま仕様面でのドキュメントとなる。ＣＰＵプログラムの機械語レベルへの変換からＲＯＭ化までは自動変換され、マスクＲＯＭデータはハード部分の部品データへとリンクされる。次に、従来であれば試作機を使ってのデバッグ作業、という時間のかかる段階があったが、ここでは上のハード関係のドキュメントとソフト関係のドキュメントを入力として、ＥＷＳ上で全体の動作をシミュレーションするシステムを使用する。これによって機能的な論理チェックから詳細な動作タイミングチェックまでが検証可能となり、デバッグ作業も相当に簡略化される。また、このような業務に並行して、技術者は「業務日報」に相当するドキュメントもＥＷＳ上に常時作成していく。このドキュメントは全てのフェーズにおいて必須のもので、次のような意味を同時に持つ重要なものである。第１に、のちの検証・仕様変更などの対象として技術ドキュメントを参照する際の基準となる。第２に、特許問題や互換機などの著作権問題に際して、独自の技術状況を説明する証拠となる。第３に、客観的な評価がますます困難になる技術者の勤務評価の有力な材料となる。第４に、フレックス制・在宅勤務の時代に向けての、技術者の客観的な自己管理をサポートする。以上のように、製品開発の中核である開発フェーズの作業は、ＥＷＳ環境の進展とともに大幅にインテリジェントされていくことになる。５．検証フェーズ　開発フェーズで述べたデバッグとは、所定の設計に対するミスやバグを発見して修正する、という従来の意味での作業であり、これは上記のように環境の進歩とともに軽減されていく。本節の「検証フェーズ」とは、仕様と異なる動作や論理的な矛盾を検証するデバッグを含む、信頼性試験・環境試験・機能試験などのテスト作業を意味している。ここでは、まず対象となる試作品や量産サンプルに対して、それぞれ該当する計測器・試験器などが接続されたり、所定のチェックプログラムがロードされる。次に、具体的な試行・計測・記録・判定などが自動的に実行化され、評価データというドキュメントがＥＷＳから視覚的に提示されることになる。一方、たとえばノイズ試験であればデータベース上のノイズ関係の国際規格の基準と比較され、問題があれば警告される。設計フェーズの開発仕様書から作成された機能試験仕様書や、開発フェーズの回路データから作成された電気的試験仕様書などに対するチェックも同時に行なわれる。これらの検証結果というドキュメントは、仕様変更や次期機種への応用、あるいは輸出規格取得のための資料ともなるので、定期的にまとめられてネットワーク内にファイリングされていく。６．統括フェーズ　ここまでの段階によって物理的に完成した製品は、本節の「統括フェーズ」という技術者のドキュメント化作業によって、本当の意味での完成品になる。まず最初の作業は、ユーザーズマニュアルとリファレンスマニュアルの作成である。これは従来は企画屋やテクニカルライターに任せていた分野であるが、これまで述べたような環境では、基本的機能を記述した開発仕様書や、ソフト開発のドキュメントである自然言語のソースプログラム等によって、十分に機能説明の骨格は完備しており、あとは技術者がユーザーの視点を意識してドキュメントの切り貼りを行なえば、容易に作成できる。ここでのＥＷＳ上のシステムとしては、説明文のフォーマットを用意してキーワードの穴埋めを対話的に支援するような、マニュアル作成ツールも実現される。一方、技術的な解説書であるリファレンスマニュアルも、関連するドキュメントから必要な技術条項を検索し、マルチウィンドウ上で再構成するようなＤＴＰツールの支援によって作成される。また、開発プロジェクトの報告としてまとめられるレポートも、同様のツールによって容易に文書化されるが、新規な技術を採用した場合に必要な特許出願というドキュメント化とは相当部分でオーバーラップしており、「特許原稿を兼ねた研究開発レポート」という新しい位置づけが生まれる。さらに、不具合の改訂というよりも機能拡張のために、仕様変更・バージョンアップといった作業が発生した場合、ＥＷＳ上に用意されているフローチャートやソースプログラムが、そのまま仕様変更の対象として検討できるために、従来の環境に比べて、２次災害のリスクはかなり改善される。また、基本的なシステムを踏襲した展開機種を開発したり、次期機種の開発を検討を行なう場合にも、これらの統括フェーズにおいて整理された各種ドキュメントをベースとすることで、信頼性と効率の面で非常に有効に機能することになる。以上のように、これからの技術者とは、それぞれの業務領域において広範な視野をもって総合的な仕事を行なう、いわばエンジニアリング・プロデューサーとなるための自己形成が求められるのである。７．国際化時代における技術者　ここまでに述べた技術者の環境・業務に関する考察においては、ドキュメントの具体的な記述に触れていない。これは、日本のコンピュータ科学の分野に特有の、日本語そのものに由来する問題点のためである。「正しい理解のためには英文マニュアルを読むべし」という金言や、「大抵のコンピュータ言語は英語をベースにしている」ことなど、裏返すと日本語の問題点を語っている事実は非常に多い。そして、歴史的・文化的な日本語論とは別の言語学的な事実として、そもそも日本語は論理的・科学的な記述には適していない、という認識は必要である。少なくとも科学技術分野のドキュメントという対象の記述では、無理やり日本語化したコンピュータ言語や、日本の特許の文章の不自然さを見れば、その非合理性は明白である。そこで、国際化時代というキーワードのもとで、いくつかの対応策を個々に検討してみることにする。　その第１は、日本人が英語をより自分のものにする、という当り前の方策である。英語とは特定の言語でなく国際化時代の標準語である、と考えてみると、少なくとも技術的なドキュメントについては、日本人の側から前向きに取り組むべきなのは当然とも言える。しかしこれは、日本の教育システムに根本的な問題をもつ議論でもあり、当分は技術者自身による努力を期待するしかない。苦労して英語と接することで技術者として成長した本人が、その合理性をなにより理解しているからである。　第２の対応策は、ＥＷＳなどの支援による自動翻訳システムの充実である。文学などの複雑な文章に比べて、科学技術分野の文章は論理的であるために、自動翻訳の対象としてはもっとも手の届くところにあり、対話的に曖昧な部分を修正できるような環境なども実現されつつある。しかし本当に重要なことは、「文章の記述が日本語であるか英語であるか」という表面ではなく、「ある概念を英語のような論理的な構造で表現すること」にある。この点では自動翻訳システムが本質的な解決にならないのも事実だが、今後の現実的な適用としては大きく貢献するものと思われる。　第３の対応策としては、より論理的な新しい日本語を作り出す、という選択も考えられる。現代の日常的な日本語の乱れとか、外来語・和製英語の氾濫とかいった、社会的な問題提起の中ではやや抵抗がある内容とも言えるが、実際には徐々に進行している現象である。つまり、日本語マニュアルの中で英単語をそのままカタカナで使用したり、ソースプログラムの中でラベルや変数に日本語を散在させたりするような、英語と日本語の混在した外観をもつ文書がその好例である。また、技術者のドキュメントといっても、目的や対象によって非常に多種にわたるものであり、取扱説明書の全文が英語では読む側が放棄してしまう場合から、国際会議のレポートとして日本語を使用できない場合まである。このような状況のなかで、目的を把握してバランスを考慮しながら、適材適所の考え方で日本語と英語を使い分けた最適なドキュメント、というのは想定しうるものである。　以上のように、ドキュメントという側面から考えてみると、国際化時代における日本人、とりわけここでは科学分野・技術分野での日本人の特異性、という認識の必要性が浮かび上がってきた。それはドキュメントという具体的な表現においては、日本語と英語（あるいは他の諸言語）という相互変換に努力を伴う２つの文化の間の距離であり、さらには日本人がものごとを考える際の思考構造にまで関係するような、重要な問題提起を含んでいるように思われる。21世紀に向けて国際化が進むにつれて、技術の交流から共同の研究開発へ、さらには国境を意識しない人類共通の文明資産として、技術者の仕事のとらえ方も変化していくであろう。その時、日本人の技術者には次の３つの義務があると思われる。まず第１に、言葉の壁を持たずに共通の舞台に参加できること、第２に、英語文化圏の財産である論理的な思考・自然科学的な哲学を理解できること、そして第３に、ファジイ理論の「あいまいさ」のような、日本特有の文化に由来する新鮮な視点・柔軟な発想を忘れないことである。現在のところ、日本の技術が世界に貢献しているのはごく皮相的な部分にしか過ぎないが、これからの日本の技術者が人類の財産である科学技術に本当に貢献できる可能性は十分にあり、それを上のような努力によって一歩ずつ実現していくのは、他ならぬ我々なのである。