ある意味どうでもいいことや、役立つかどうかもわからないような中身を、日々脳内から適当に垂れ流しまくりつつ、今日をなんとか生き存えることを思案してます。
2018/03/21
DTPソフトで効率よく作業するためには、最近はよく「スクリプトを導入しよう」「キーボード用のカスタマイズツールを入れて作業効率を上げよう」みたいなことを推奨しているような話題を時折見かけます。
しかしそれはそれで、業務利用として考えた場合には、必ずしも手放しで喜べるものではないよ、問題もあるよ、というおはなし。
しかし、そこには必ずしもいいことだけがあるわけではなく、いくつかの問題点がクリアできるかどうか、というところが大きくかかわってくるわけで。
思いつくままにつらつらとピックアップ。
これは組織系ではある意味当たり前。
有料ソフト（パッケージ・ダウンロード・シェアウェア何でも同じ）はもちろん、それがフリーソフトだろうがオープンソースだろうが、環境として「自由に導入できる状態かどうか」は最大の壁になるわけで。
個人的には、「現場の自由度は一定程度は必要」くらいは思ってはいるものの、組織利用じゃ個人利用と同等に扱うわけにはいかないのもまた事実。
ともあれ、ここが突破できるかどうかは、それぞれによってまるで変わってくるのは当たり前ですが、たぶん推奨している側はここの部分が基本的に入っていないんじゃないかって思ったりします。
さてそれなりに自由に導入できたとした場合、の話。なので最初の部分は突破できているとか無関係とかの前提ありきですが。
これも組織とかグループとかそういう範囲で、一人じゃないってところが前提にはなってきます、が、「自分だけが使える状態」というのは、共同作業においてはやはり影響度が限りなく高い部分だったりします。
それぞれが導入できるのか、そもそも環境として入れられるのか、ってところも、ハードルとしてはけして低いところではないわけで。
特に特定処理に依存するようなものを自分が一番真っ先に導入したうえで、その処理がなければ他の人は何もできなくなる、というものは、個人的には完全にダメなケースだと思ってます。
DTPとかだと「特定プラグインを入れて作業したデータは、そのプラグインを入れないともう作業ができなくなる」という、過去にはよくトラブルにトラブルに繋がるようなケースになりうる話の部分だったところでもあったりします。
もちろん全部が全部そういうものじゃないのはわかっています、けど、事実上の環境依存にしてしまうことで、結果としてトラブルになりうる可能性は十分に踏まえないといけない部分です。
効率化によって作業時間の短縮につながるのはいいことです。
しかしその場合は「標準作業時間はいったいどれくらいなのか」がわからなくなってきます。
そうなると問題になってくるのは時間ベースで算出が必要な、標準コストが不明瞭になってしまうという問題に繋がってしまうわけです。
これは組織であれば勿論出てきて当たり前の問題ではあるんですが、個人であってもこれは同様になってきます。
要は「時間基準で費用請求する場合に、短縮された時間で費用請求となった場合には損をする」ということにも繋がりかねないという問題に繋がってくるんです。
グロス請求などもあるのでここは一概には言えないですし、逆にきちんと算出すればその分だけ余分に稼ぎ出すことができるかどうかの算出もできる、というメリットにつながる可能性もあるんですが、やはり重要な要素になってくるであろう、と。
ちなみにここだけでいっば、カスタマイズ関係なく、組織ベースで複数人数で対応する場合は「平均作業時間」という話にもなってきます。そうなると新人とベテランでも対応時間が違うのはある意味当たり前なわけなので、どちらを基準にすることもできないはず。
ただ普通、ベテランは時短できる分だけ本来は時間当たりの費用請求は高くてもいいとは思うんですけど……そうもいかないのが世の中の状況ともいえるので、まあ難しいおはなし。
ここは大きな問題。
そのカスタマイズ用のツール、使えなくなった時の事って果たして考えているのかどうか、という点。
元のプラットフォーム（OSやアプリケーション）のバージョンアップ等で動作しなくなることもあるでしょうし、そもそも元開発者が随時アップデートしてくれるとは限らない訳で。
利用できなくなったら、当然ですが作業効率はがっつり落ちる。というか下手したら作業自体ができなくなる可能性もゼロではないわけで。
そうなってくると仕事も何もあったもんじゃありません……なにもかも、おじゃん。
まあ仕事自体は続けられるということになったとしても、作業効率がそれまでと大幅に落ちて（というか元に戻って）、時間がかかりまくるようになってしまう可能性は十分にあるわけで。
その場合には「あることを前提にして仕事入れてたら、全部の仕事を捌けなくなった」とか、ある意味本末転倒な結果にならざるを得なくなるという。
前項にも関わってきますけど、短い時間前提として仕事を詰め込んでた場合にものすごく問題になってしまうんじゃないか敵なのがコレです……というか仕事が間に合わなくて信用問題になりかねないとかそういうところにも繋がってくるので。
（まあ最悪、徹夜でも人海戦術でもなんでもやって信用だけは落とさないようにするとかもあるんですが、体力勝負とか費用面とか考えれば本末転倒な結果になりかねない）
これも前項がらみというか、そこに通じる話ながらも、ちょっと別枠として考えておくとしての話。
もちろんメンテナンスできない場合に代替方法があればいいとは思います、が、それもちゃんと最初から複数（最低2つ、あれば他にも選択肢があるのが良い）の選択肢をちゃんと選んでおけるかどうか、というのもあるわけで……実はまったくそんなものを見越してなかったっていうのがものすごく厳しいし、選択肢があっても完全に同じことができるケースなんてまず稀なので、そういうこともちゃんと織り込んでおかないといけない。
まああまりにも「入れられない」「入れない」に固執すると、今度は何も考えない状況に陥ってしまうので、それはそれでいいことではないんですが、カスタマイズについてもメリットだらけではないことっていうのは大きく踏まえないといけないところなので、様々なことを考えつつ、カスタマイズ系の選択肢は伝家の宝刀的に「こういうこともあろうかと」的なものにしておくべきだなあ、と思う次第なわけです、はい。
まあスクリプトあたりで、自分で書ける人とか、そこそこ自分で対応できちゃう人はいいんじゃないかとは思いますです。
他人が作ったものである限りは、メンテナンスがきちんと行われるかはどうしてもトレードオフの一環になってしまう。
ソフトなんて10年20年使えるわけではなく、最低3年、長期的に引っ張って引っ張ってを見越しまくったとしてもせいぜい使えて6-7年くらいじゃないかと思うので、そうなると環境を定期的に見直ししなきゃならなくなるのは必然なわけです。
その見直しを行った際に、今までのツールが使えなくなった、ということがあるのは前項どおり。
じゃあ使えるようにしてもらえるかどうか……というと、やはりこれは賭けに近いところになってくるわけです。
もちろん、ある程度の期間使えれば全然モトは取れるとかそういう話にもなるでしょうし、それで十分な場合もありうるんですが、ケースによっては長期対応が必須の業務とかもありうるわけで。
フリーウェア・シェアウェア系はもちろんのこと、これは個別に開発してもらったアプリケーションでも同じで、元メーカー等がちゃんとメンテナンスしてくれるかはまったく別の話……まあ後者の場合はメンテナンス系の契約できてるかどうかってのが一番大きいですが。主にお金の都合がメインとして。
多くの場合はそこまで考えられてはいないんだろうなー……という。
まあ、どこまで長期的に考えるかってのはあるんですが、まあ2-3年ベースであれば十分視野に入れる範囲であって、その範囲内で問題ないかどうかっていうのは大きな要素だと思ってますです。
ということで……最後のはちょっと差し置いていたとしても、1～4については常日頃から絶対に考えておかないといけないわけで。
あとはプラットフォーム的な依存をするものをどうするかですわな……そこだけは誰でもリスクを持つことになるので。
そういう意味では誰もが関わってくる部分じゃないかとは思ったりはする。
そもそも「もともとのDTPソフト自体がなくなったらどうすんじゃい」とかもありますけど。まあそこも本来は選択肢を複数持つような体制にしたい……けれども、ことDTP業界に限っては、ある意味自分たちでその選択肢を潰していったしなあ……現状選べる僅かな選択肢をどう考えるか、くらいか。
コメント