| アプリケーションが高機能化したんだから、そのチカラを有効に使おうよ | 2008.06.18.Wed / 20:41 | |||
伽藍でもバザールでも関係ねえから運用に必要な情報は伝えていこうぜ、ていう話（M.C.P.C）
のはてなブックマークに
「情報をやり取りするにしても、現象が複雑すぎて無理かも。アプリケーションに振り回されてる業界の象徴的現象じゃないかなー」
とコメントしたんですが、これでは説明不足なので、コッチでつらつら書いてみます。
※CLさんのエントリの元ネタはこちら（「枯れて候」名もないテクノ手）
OS9までの時代は、制作環境が長期にわたって固定されていたため膨大な量のノウハウが蓄積されており、データの不具合の対処も「作業的には」解決していましたが、InDesign化・OSX化によってそれらのノウハウはほぼ通用しなくなってしまいました。
アプリケーションの高機能化・ハードウェアのパワーを生かせるようになった反面、過去に積み上げてきた情報という資産を失うことにもなったワケです。
（参考：せうぞー、さんのホームページ「Show Time +one」内「DTP2.0のキャズム」）
最近、CS2・3で作られた他人のデータを見ると「どう作ってるの？」と思わされる場面に多々遭遇します。
「こういう方法があるんだ！」と思うこともありますが、「なんでこんな面倒な方法を採ってるの？」とか「こんなヤリ方じゃ出力できないよ！」と思うことがしばしばです。
これは、機能が多くなった反面、機能を的確に使用することが難しくなっているからだと考えられます。
たとえば、InDesignで文字をツメる場合いろいろな方法がありますが、「どれが一番適しているか」なんて答えられないですが、複数使用すればとんでもないことになりますよね？
（参考：InDesignの勉強部屋「InDesignの様々な詰め機能」）
結果、見た目では問題がないように見えても実は重大な問題を抱えたデータが出来ることになったのではないかと。
しかもデータの内容が複雑で、受け手側（製版工程側）がデータの構造を理解（解析）するには相当な時間が必要になります。また、出力できない原因が複数の要因に拠る場合、問題点を探し出すにも相当な時間がかかってしまいますし、情報として蓄積しづらい状況になってると思われます。
さらに、このような状況でがんばって運用情報を蓄積しても、アプリケーションのバージョンアップサイクルが速くなっているため、情報の鮮度が落ちるのも速くなっているし、新しいバージョンへの対応にもリソースを割かれることにもなっています。
このように特定の環境だけにリソースを注力できない状況のため、アプリケーションの習熟度が浅くなり、結果、アプリケーションの高機能に振り回され混乱を来しているのではないかと思いました。
本来であれば、印刷側（製版側）が「正しい」データの作り方のモデルケースを提示し、制作側はそれに則ってデータを制作するのが、一つの解決策だと考えています。
しかし、アプリケーションに対する習熟度が不足しているため製版側が制作側に提示できなくなっているのではないでしょうか？
また、提示できたとしても今度は制作側の習熟度不足でそれを理解できないという悲しい状況もあり得ます。
アプリケーションのバージョン・種類を問わず、データが出力に適したように作られていれば問題が起きることはほとんどありません。巷でさんざんにいわれている（らしい）Illustrator9ですが自分は大好きでしたし、問題が起きたことはありませんでした。
というわけで、どんなデータの作り方が出力（＝印刷）に適しているのか、どうすれば効率的な制作が行えるのか、といった実例を共有しアプリケーションの機能を有効に活用していく方法を模索していくべきではないかと思いました。
アプリケーションが高機能化したんだから、そのチカラを有効に使おうよ、と。
不具合情報を共有するのではなく、効率的な使い方を「情報」として共有する。スマートなデータは制作時の工数（手数・手間）を低減させるし、後工程でもスムーズに出力できます。問題が起きても問題点の洗い出しも簡単できます。
逆説的ですが、アプリケーションはあくまで道具。印刷に至る工程の中での使い方までは変わらないんだから、本質部分は情報として「蓄積」できる、ハズではないかと。
最後に「超」個人的意見。
デザインを行う人間としては、データの作り方云々よりいかにより良いデザインを提案できるかに目がいきがちです。
でも、F1とかのレーシングカーを設計する人ってデザイナーって言うんだよね。マシンの機械的構造も含めて、より速いマシンを「デザイン」する人。
そして、勝つマシンほど実はシンプルに作られている。複雑な構造のマシンが勝ったことは、ない。
データを「作る」立場にあるなら考え方も同じ、だと思います。
のはてなブックマークに
「情報をやり取りするにしても、現象が複雑すぎて無理かも。アプリケーションに振り回されてる業界の象徴的現象じゃないかなー」
とコメントしたんですが、これでは説明不足なので、コッチでつらつら書いてみます。
※CLさんのエントリの元ネタはこちら（「枯れて候」名もないテクノ手）
OS9までの時代は、制作環境が長期にわたって固定されていたため膨大な量のノウハウが蓄積されており、データの不具合の対処も「作業的には」解決していましたが、InDesign化・OSX化によってそれらのノウハウはほぼ通用しなくなってしまいました。
アプリケーションの高機能化・ハードウェアのパワーを生かせるようになった反面、過去に積み上げてきた情報という資産を失うことにもなったワケです。
（参考：せうぞー、さんのホームページ「Show Time +one」内「DTP2.0のキャズム」）
最近、CS2・3で作られた他人のデータを見ると「どう作ってるの？」と思わされる場面に多々遭遇します。
「こういう方法があるんだ！」と思うこともありますが、「なんでこんな面倒な方法を採ってるの？」とか「こんなヤリ方じゃ出力できないよ！」と思うことがしばしばです。
これは、機能が多くなった反面、機能を的確に使用することが難しくなっているからだと考えられます。
たとえば、InDesignで文字をツメる場合いろいろな方法がありますが、「どれが一番適しているか」なんて答えられないですが、複数使用すればとんでもないことになりますよね？
（参考：InDesignの勉強部屋「InDesignの様々な詰め機能」）
結果、見た目では問題がないように見えても実は重大な問題を抱えたデータが出来ることになったのではないかと。
しかもデータの内容が複雑で、受け手側（製版工程側）がデータの構造を理解（解析）するには相当な時間が必要になります。また、出力できない原因が複数の要因に拠る場合、問題点を探し出すにも相当な時間がかかってしまいますし、情報として蓄積しづらい状況になってると思われます。
さらに、このような状況でがんばって運用情報を蓄積しても、アプリケーションのバージョンアップサイクルが速くなっているため、情報の鮮度が落ちるのも速くなっているし、新しいバージョンへの対応にもリソースを割かれることにもなっています。
このように特定の環境だけにリソースを注力できない状況のため、アプリケーションの習熟度が浅くなり、結果、アプリケーションの高機能に振り回され混乱を来しているのではないかと思いました。
本来であれば、印刷側（製版側）が「正しい」データの作り方のモデルケースを提示し、制作側はそれに則ってデータを制作するのが、一つの解決策だと考えています。
しかし、アプリケーションに対する習熟度が不足しているため製版側が制作側に提示できなくなっているのではないでしょうか？
また、提示できたとしても今度は制作側の習熟度不足でそれを理解できないという悲しい状況もあり得ます。
アプリケーションのバージョン・種類を問わず、データが出力に適したように作られていれば問題が起きることはほとんどありません。巷でさんざんにいわれている（らしい）Illustrator9ですが自分は大好きでしたし、問題が起きたことはありませんでした。
というわけで、どんなデータの作り方が出力（＝印刷）に適しているのか、どうすれば効率的な制作が行えるのか、といった実例を共有しアプリケーションの機能を有効に活用していく方法を模索していくべきではないかと思いました。
アプリケーションが高機能化したんだから、そのチカラを有効に使おうよ、と。
不具合情報を共有するのではなく、効率的な使い方を「情報」として共有する。スマートなデータは制作時の工数（手数・手間）を低減させるし、後工程でもスムーズに出力できます。問題が起きても問題点の洗い出しも簡単できます。
逆説的ですが、アプリケーションはあくまで道具。印刷に至る工程の中での使い方までは変わらないんだから、本質部分は情報として「蓄積」できる、ハズではないかと。
最後に「超」個人的意見。
デザインを行う人間としては、データの作り方云々よりいかにより良いデザインを提案できるかに目がいきがちです。
でも、F1とかのレーシングカーを設計する人ってデザイナーって言うんだよね。マシンの機械的構造も含めて、より速いマシンを「デザイン」する人。
そして、勝つマシンほど実はシンプルに作られている。複雑な構造のマシンが勝ったことは、ない。
データを「作る」立場にあるなら考え方も同じ、だと思います。
