DTP屋あかつき@おばなの稼業録。
  スポンサーサイト  --.--.--.-- / --:-- 
上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。
No. / スポンサー広告 /  コメント(-) /  トラックバック(-) /  PAGE TOP△
伽藍でもバザールでも関係ねえから運用に必要な情報は伝えていこうぜ、ていう話(M.C.P.C)

はてなブックマーク
「情報をやり取りするにしても、現象が複雑すぎて無理かも。アプリケーションに振り回されてる業界の象徴的現象じゃないかなー」
とコメントしたんですが、これでは説明不足なので、コッチでつらつら書いてみます。
※CLさんのエントリの元ネタはこちら(「枯れて候」名もないテクノ手)

OS9までの時代は、制作環境が長期にわたって固定されていたため膨大な量のノウハウが蓄積されており、データの不具合の対処も「作業的には」解決していましたが、InDesign化・OSX化によってそれらのノウハウはほぼ通用しなくなってしまいました。
アプリケーションの高機能化・ハードウェアのパワーを生かせるようになった反面、過去に積み上げてきた情報という資産を失うことにもなったワケです。
(参考:せうぞー、さんのホームページ「Show Time +one」内「DTP2.0のキャズム」)

最近、CS2・3で作られた他人のデータを見ると「どう作ってるの?」と思わされる場面に多々遭遇します。
「こういう方法があるんだ!」と思うこともありますが、「なんでこんな面倒な方法を採ってるの?」とか「こんなヤリ方じゃ出力できないよ!」と思うことがしばしばです。
これは、機能が多くなった反面、機能を的確に使用することが難しくなっているからだと考えられます。
たとえば、InDesignで文字をツメる場合いろいろな方法がありますが、「どれが一番適しているか」なんて答えられないですが、複数使用すればとんでもないことになりますよね?
(参考:InDesignの勉強部屋「InDesignの様々な詰め機能」

結果、見た目では問題がないように見えても実は重大な問題を抱えたデータが出来ることになったのではないかと。
しかもデータの内容が複雑で、受け手側(製版工程側)がデータの構造を理解(解析)するには相当な時間が必要になります。また、出力できない原因が複数の要因に拠る場合、問題点を探し出すにも相当な時間がかかってしまいますし、情報として蓄積しづらい状況になってると思われます。

さらに、このような状況でがんばって運用情報を蓄積しても、アプリケーションのバージョンアップサイクルが速くなっているため、情報の鮮度が落ちるのも速くなっているし、新しいバージョンへの対応にもリソースを割かれることにもなっています。

このように特定の環境だけにリソースを注力できない状況のため、アプリケーションの習熟度が浅くなり、結果、アプリケーションの高機能に振り回され混乱を来しているのではないかと思いました。

本来であれば、印刷側(製版側)が「正しい」データの作り方のモデルケースを提示し、制作側はそれに則ってデータを制作するのが、一つの解決策だと考えています。
しかし、アプリケーションに対する習熟度が不足しているため製版側が制作側に提示できなくなっているのではないでしょうか?
また、提示できたとしても今度は制作側の習熟度不足でそれを理解できないという悲しい状況もあり得ます。

アプリケーションのバージョン・種類を問わず、データが出力に適したように作られていれば問題が起きることはほとんどありません。巷でさんざんにいわれている(らしい)Illustrator9ですが自分は大好きでしたし、問題が起きたことはありませんでした。

というわけで、どんなデータの作り方が出力(=印刷)に適しているのか、どうすれば効率的な制作が行えるのか、といった実例を共有しアプリケーションの機能を有効に活用していく方法を模索していくべきではないかと思いました。
アプリケーションが高機能化したんだから、そのチカラを有効に使おうよ、と。

不具合情報を共有するのではなく、効率的な使い方を「情報」として共有する。スマートなデータは制作時の工数(手数・手間)を低減させるし、後工程でもスムーズに出力できます。問題が起きても問題点の洗い出しも簡単できます。

逆説的ですが、アプリケーションはあくまで道具。印刷に至る工程の中での使い方までは変わらないんだから、本質部分は情報として「蓄積」できる、ハズではないかと。


最後に「超」個人的意見。

デザインを行う人間としては、データの作り方云々よりいかにより良いデザインを提案できるかに目がいきがちです。
でも、F1とかのレーシングカーを設計する人ってデザイナーって言うんだよね。マシンの機械的構造も含めて、より速いマシンを「デザイン」する人。
そして、勝つマシンほど実はシンプルに作られている。複雑な構造のマシンが勝ったことは、ない。

データを「作る」立場にあるなら考え方も同じ、だと思います。
No.187 / 業務日記 /  comments(0)  /  trackbacks(0) /  PAGE TOP△
COMMENT TO THIS ENTRY

  非公開コメント
TRACKBACK URL OF THIS ENTRY

TRACKBACK TO THIS ENTRY

■特設

INDD 2016(2016年10月14日、お茶の水ソラシティで開催)



■Profile

尾花 暁(あかつき)

  • Author:尾花 暁(あかつき)
  • 性別:オス

    自称、DTPなんでも屋。
    [すきなもの]作業効率化のマネゴト・技術ネタ
    [苦手なもの]小さい画像のキリヌキ・責了時の修正

    ※公開後にエントリーの文章を修正することがあります。内容を大幅に変更・修正した場合は履歴を明記しますが、誤字脱字の修正など細かい変更に関しては明記しません。

    ご意見・ご要望はページ下部のメールフォームからお願いします。

■訪問者数累計

■お役立ち度

この日記のはてなブックマーク数

■お問い合わせ

名前:
メール:
件名:
本文:

CopyRight 2006 あかつき@おばなのDTP稼業録 All rights reserved.
上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。