2009年12月29日火曜日

2009年最終日レビュー大会を終えて

2009年最終日となった今日というか昨日(12月28日)は、当初から総まとめとしてのレビューをしよう、なんてことになってまして、
開発関係、制作関係それぞれで2時間程度をとって行いました。

開発では、今動いている案件の話とか、今やっているものの話を順次していきました。
開発2課によるコンバート関係は、引き続き写研データの調整や、入稿されるAccessデータを解析してEdianに流すとか、ワード2007のXMLを解析して数式を抜くとか、そういったものと、
あと、新しい試みでInDesignで作った商品カタログのデータから、CouchDBという究極?のKey、Value型DBへの取り込みという、ずっと山本さんが言っている、今で言うNoSQLですか、そういう試みの途中経過の発表でした。


※↑はInDesignからcouchDBにぶっこむスクリプトを実行するところ


※↑はCouchDBにとりあえずぶっこんだところ。


商品カタログ系DTPとコンテンツをどうするかの将来像、可能性が見えた気がします。
もうここまでくれば、既製品がほんとに必要なくなりますよね。これから、どんどんオープンソース系の技術がこの業界にも浸透してきて欲しいです。

続いては、PAGE2010でサンプル出展する絵本を作るAIRアプリの途中経過。
AIR2.0への取り組みは、AdobeAIRDayへの参考出展などで取り組みをしているわけですが、FlashCS5からは、TLF(Text Layout Framework)が、InDesignと同じエンジンになるそうで、なんだかAdobeという枠の中でどんどんやりたいことが出来ていく感が、急速に進行していてとても面白くなってきています。


↑Flex4の上で縦組み表現しています。


その他、データ差分をとるためのプラグインとか、バリデーションチェックのモジュールとか、日々必要なものがざくざく出来ていっている感じでした。

制作では、大量ページものが多いわけですが、それをどういう手順でやるか、その手順が正しいのか、といったところを検証しつつ行われました。



これからもっとも心がけていくべき「テクニカルDTP」という分野をしっかりと認知させていくには、いつも同じでやり方が変わらないものについては、しっかりと手順書を作り、ただ作るだけじゃなく、それをやってみて、さらに問題・課題がないか追求し、誰でも出来る状態、誰がやっても同じ結果が得られるように、漏れ、ミスのないようなフローを構築しなければいけません。2009年は試行錯誤の中、粗が目立つときがありましたが、2010年は、その点をしっかりと抑えていくんだ、と結んだのでした。

その後は、忘年会!



紆余曲折、なんだかんだありながら、なんとか年越しできました。
いつも応援していただいている方々に心から感謝いたします。

2009年12月27日日曜日

SGGAE/J勉強会に参加しました

SGGAE/Jは、Scala、Grails/Groovy、GAE/Jを組み合わせたもので、
「すっげーじぇ」と読むんだそうです。

2009年12月26日ニューキャストセミナールームで開催されました。
名古屋Scala勉強会とJGGUG名古屋支部の合同勉強会になります。

1.Google App Engine for Java入門/tantack@名古屋Scala勉強会
Google App Engineとはどういうものか、といった基本的なところのお話でした。
GAEの制限事項とかとても勉強になりました。

2.Lift on GAE/J/RKTM@名古屋Scala勉強会
ScalaのWebフレームワーク「Lift」をGoogle App Engine for Javaで動かすということで、あまりにも簡単にできてしまって驚きました。mavenとか使ったことなかったですが、だいたい追いついて出来ました。当日の資料どっかにあがるのかな?聞いてみます。

3.GroovyなGAE/J:Gaelykでかんたんbot工作/kskyさん@日本Grails/Groovyユーザーグループ
横浜から参戦のkskyさんによるGaelykの紹介と、Gaelykを使ったTwitter botの作成ということで、まずはGaelykで作ったものをGAE/Jに載せるハンズオン。その後、Twitter botの作成では、パイプラインの話、つぶやくウサギ(nabaztag)が登場したりととても面白かったです。名古屋のお天気情報をつぶやく@nagoyaweatherは、このセッションで完了したのでした。

4.Grails、Gaelykでハンズオン/tyamaさん@日本Grails/Groovyユーザーグループ名古屋支部
GrailsをGAE/Jで動かし方についての紹介(ハンズオン)
お持ち帰り資料を準備してあるあたりが、tyamaさん、さすがだね。



うちのセミナールームも、皆さんのように技術に詳しくない、勉強ばっかりさせてもらっている私の営業の成果?もあって、徐々に認知されてきたのではと勝手に盛り上がっておりますが、今日ご参加いただいた方からも「駅(JR千種、地下鉄東山線千種)が近くてとてもいいねぇ」「IT系の勉強会には必須アイテムの無線LAN、電源、ホワイトボード、プロジェクタと全部揃ってるし」と言っていただいたので、勉強会を開きたい、場所を探しているコミュニティの方々には無料開放してるのですが、こう言っていただけるだけで、採算合わずとも家賃を払う価値あり、と自分に言い聞かせるのでした。

根がイベント屋なのかな、こういうのをお手伝いするのがとても楽しいのです。
やろうと思えば、場所があれば、どこでも出来そうなので、そうなっても、
「ニューキャストさんとこのセミナールームでやりたいな」と、思っていただけるように、設備じゃない何か、お金じゃない何かをこの場所で築きたいと思います。

快適な勉強会ライフを提供できるように、もっと頑張ります。

2009年12月26日土曜日

Amazon EC2ユーザ会 クリスマス・オフ会に参加しましてきました

Amazon EC2ユーザ会 クリスマス・オフ会に参加しましてきました。

12月25日クリスマスまっただ中、しかも金曜日、渋谷のアマゾン ジャパン株式会社で開催されました。

看板を見て「あ、オレ、ユーザじゃない」と少し尻込みしながら、学びingの社長さんが受付されている中、会場に入っていったのでした。学びing?あー、PAGE2009で聞いた気がすると思いつつ。。。

会場には、なんかそれっぽい人たちばっかりで、山本がいれば、もっと濃い話になったんだろうけど、僕は、アカウント作ってちょっと試してみた口で、よく分かってない部類の人間なので、隅っこで会場を眺めておりました。山本氏は、本日は、明日12/26に開催されるScala勉強会との合同勉強会でGAE/Jの資料に集中したいということで泣く泣くキャンセルしたのでした。

まずは、「AWS新着任日本人スタッフ」小島さんによるAmazon本体の話、AWSの紹介と、スタッフ募集の話。

上のスライドは、Amazonのビジネスモデルの図と小島さん
(レストランでナプキンに書かれた伝説の図?)

初っぱな、データセンターの場所についての話でしたが、現在はUS2拠点、EU1拠点、2010年前半でシンガポールが準備段階、そしてアジア2拠点目はどこか!という話で結構盛り上がったのでした。アジアでは日本しかスタッフ、体制の準備がされていない、ということは「東京?」。書くなっていわれたからこれぐらいで。

ここからはAWSのサービス内容についての紹介で、中でもいちおししてたのは、AmazonVPCの話でした。VPNでプライベート利用できるもので1時間1セントらしい。社内リソースを拡張したいときは是非ということでした。これは特別に難しい設定が必要というわけではなく、通常のVPNと同じだと考えていい、ということでした。

リリース済みのようですが、「EC2 spot instance オークション型で利用価格を入札」や、「CloudFrontStreaming 静的なファイルしかできなかったが、AdobeFlashメディアサーバがビルトインされる。これは完全従量制で提供。オンデマンドストリーミングのみ対応。ライブは未対応」という話がありました。
MicrosoftでなくAdobeと提携したところが、僕らにとっては好都合。
小島さんは、前職AdobeJapanだそうで、PDFソリューションや、Flexユーザコミュニティの立ち上げをされたそうで、そういう意味では僕らに近い存在なんだと思うと、勝手に身近に感じたのでした。

終わってすぐ名刺交換させてもらって、「今日も仮想化の話をお客さんとしてきたんですが、印刷・出版業界って大量のコンテンツがあって、画像があって、変換が必要で、そして使う時期使わない時期がある、大量の処理をいっきにかける時がある、とかだと、こういうサービスを使うのってありだと思うんですが、どうなんでしょう?」と質問したら、「十分ありです。向いていると思います。」みたいなお返事をいただいたので、これはセールストークにいただきだなと。印刷・出版業界は、ついつい「印刷」もしくは「印刷機」に頭がいっちゃって、あんまり関係ないと思ってるかもしれないけれど、ビジネスインフラとしてのAmazon利用に真剣に取り組む必要があるんだ、という思いに背中を押してもらった気がしました。

ユーザ事例としては、「ウェブポ※年賀状作るサイト」「アンケート集計」がありました。UIの部分はFlexを使ったRIA開発されていて、バックエンドの処理でAmazonを使っている、アンケートについては、ある時期にある処理をまとめて行わなければならない、ということで使っているということでした。これによって次年度のハードウェア予算はほとんど削られ、その分開発の方へ回して、さらに良いものにしていく、ということができるようになったらしいです。

その後、質問タイムから上記になかった話をいくつか紹介。

クレジットカードがないとできない、というのは企業利用に壁ができてしまうのでは?という質問がありました。
これについては、カードを使うことですぐ使える、という利点に重きを置いていてそうしていると。カードがあれば、予審しなくてもいい、というところもコストを抑えられるポイントだと。
毎月100万円を超えるものについては請求書発行という流れもやっているが、マニュアルオペレーションなので、いつかはコストを圧迫することになるので整理が必要だということでした。
また、学生向けにもプリペイドカードのようなもので出来るように準備を開始しているらしいです。

それから、やっぱり安心できる事例が欲しい、というのがあって、その辺はどうなんでしょうか?という質問には、言えませんが進行中案件があることは確かだと、いうことでした。
それから、最近不況もあって、コストを抑えなければいけないということで、お客さん側が機能を削るなどの妥協する事も少しずつ現実的に出てきていて、そのようなコストプレッシャーの中、クラウドを提案するための「風穴」が出てきつつある、クラウドが話の土俵にあがることが出てきている、ということでした。

Amazonは、安く提供するために、とにかくマニュアルオペレーションを抑えた「ローコストオペレーション」を徹底的にやるという方針とのことで、ユーザとしてはそれが長く続いてくれるように応援したいものです。

あとは、「ホワイトボードじゃなくてホントに壁に書くんだ」ということで、壁にペンで書いてました。
上手くとれてませんが、スライドの右側に赤いペンで書かれてます。


うちでもやりたいな。セミナールームならいけそうだけど。ちゃんと消えれば良いんだけどね。

そうそう、ジャンケン大会があって、RightScale社のプレミアム?なシャツをゲットした。

2009年12月17日木曜日

備えあれば

2009年12月16日20時頃、NTTBフレッツとau one netのあたりで回線障害がありました。

当社でSaaS提供しているWEB入稿・自動組版のお客さまがその影響を受けてしまうことになりました。

回線については、なんともしようがないんですが、こういう時のためにも複数の回線が用意してあるので、入り口を変えて接続してもらうという緊急時の対策を施しました。
他にも考えられる障害への対応策は、数年の歳月をかけてかなり施してあります。

お客さまからすると、えっそんなのプロなんだからすぐ直せるでしょ、と考えると思います。
実際、簡単に終わることもあります。しかし、いろいろな可能性を探りながら慎重にやらないと二次三次の障害を起こす原因にもなってしまいます。そうなっては右往左往しながら余計な時間を要してしまうことにもなりかねません。
そういったことを全部含めて、最速で復旧できるように心がけています。

が、なかなか理解はしてもらえません。
おまえらちゃんとやってんのか!と。
見えないんだから仕方ないですね。
見えないから余計にイライラしてしまいますよね。

実際今回は、まず監視サーバから全員の携帯にメールが送信され、その後5人全員が携帯で招集されました。一人は帰宅中に途中下車して一番近い友人宅に陣取りしたようです。第一報から10〜15分ぐらいだったと思います。

その後は、全員オンラインで状況を確認、情報を収集しながら、これが原因だとしたら、どうする、それをしたらどうなる、他に影響は?などなど、こういう場合、一人の判断、知識では不十分なときがあります。いつもはのんびりしてそうな人たちがそれぞれの力を発揮しながら解決、そして対応まで持ち込みます。チームワークが試される時でもあります。

でも、見えないんです。悲しいことに。
今回の全員のやりとりチャットを公開したいぐらいです。

回線が復旧するかもしれない。それでも回線が大変なことになって復旧しなかった時を想定して職務を全うするために動きます。

。。。今回は、緊急対応が完了したとたんに、NTTの回線が復旧しました。

ネットワーク障害も、ハード障害もいつ起こるとは誰も教えてくれません。
逆にいつでも起こる可能性がある、ということです。
世の中が便利になる反面、気にしなくなった反面、見えないリスクも背負っています。

最後は、機械ではなく、人間がやるしかありません。

NTTの人たちもそうだと思います。そういう裏方さん達が、僕らが何気なく使っている物を必至になって守ろうとしているというのは、こういう障害が起こったときぐらいでいいので思い出して欲しいなと思います。
そうしないと、重要性が軽視されて、やがてそれは品質の低下を招くという結果にもなりかねないとちょっと危惧してしまうのです。

印刷・出版系システムは、印刷入稿日が決まっているので、もしデータが出来なかったら損害額が半端な物ではありません。
ボタン押して、自動組版されて出てくる、それだけのシステムなんですが、それを当たり前のようにできるように、相当なノウハウが詰まっています。

それでも障害は発生します。そういうときは、皆さんが思う以上に相当な緊張に包まれます。
ですが、過度の緊張は失敗に繋がります。ほとんどの復旧失敗は、急ぎ過ぎが原因です。
絶対に焦ってはいけない。これが鉄則だと思います。

とにかく下版できないとか、そういう大事故に発展しなくて良かった。。。

2009年12月16日水曜日

ユーザーに想像させるにはシステムの余白が必要だと思う

昨夜はタイトルを書いて、内容を考えながら寝てしまった。。。

システム構築するときに、まず初めに必要な機能の整理とかを充分にやろうとするのは、あと(納品・検収)で、それが出てきてれば完成だよね、という合理的な考えをする周りの人間に必要なだけであって、それだけのコストを掛けた企業、使うユーザーはそこで満足するわけではなく、パフォーマンスが出なければ受け入れてくれない。

一番大事なのは、ユーザーに受け入れられ、自ら使いこなすようになれることだと思います。
そう考えると、使ってみなければ、動かしてみなければ受け入れられるはずもない。
なのでまず、機能モリモリではなく、簡単なというかシンプルさを優先して芯の部分を先に作って、使ってみる、動かしてみる、想像してみる、という場面をユーザーに提供することから、システム開発はスタートするんじゃないかと思います。

うちで使っている制作作業コストを管理するシステムは、Grailsで数時間で自作したものです。
社内システムなので、こういうの欲しいんだけど、と言うと、まず、
案件があって、その中にタスクがあって、そのタスクに各ユーザーが作業時間を登録する、というのが多分芯になる部分なので、それを作ってもらいました。
ほぼScaffoldで開始して、まず登録してみる。
とりあえず、金額と時間の計算とかはできたので、あとは何が必要か分からないので、たくさん文字が入る備考欄を準備して終わり。

数ヶ月運用して、リストの出し方がこうなってると集計しやすいんだよね、とJIRAに入れて、時間のある人が修正→確認→クローズと。

ゆくゆくは月集計とか個人集計とかやりたいなと思ってましたが、しばらくして、
「あ、備考欄に必要なキーを文字で入れといてそれで文字で検索すればリストでるじゃん」と。数ヶ月でかなり会社のコアなシステムになりました。それが今まで見えなかった部分の可視化にも繋がって、当初考えていた使い方よりも変わってきています。

これは一例でしかないですが、検索キーって、何になるか分からないし、キーの種類、タイプなんかも、先に決めようと思ったら、そこから大幅に話しが膨らんだり、横道に逸れたりして、それがプロジェクトを遅延、クラッシュさせる原因になる。そうすると、本来やりたかったことが小さくなって、他のことの方が重大に思えてくる。

だったら、ユーザーに想像させるシステムの余白(開発者の視点からも作り込みすぎない)を作っておいて、自らがその想像を実現させようとして使いこなすようになる。自らが使いこなせるようになれば、あとは、プログラムの世界へようこそ、ということで、自分たちでもコーディングしてもらうという、まあ最後は本人のやる気によりますが、システム開発ってそういうステップを踏む分野もあっていいんじゃないかなと思います。

2009年12月15日火曜日

InDesignとEdianWingとMC-B2を比較〜流し込み編

ずっと続きを書いてないので、どこまで書いたか忘れてしまいましたが、
InDesign、EdianWing、MC-B2というところにとりあえず絞って考えると、向いている案件、向いてない案件てあるよね、というところまでだったですね、多分、、、

制作現場では、あまりアプリに固執してしまうと、そればっかりになって、アプリが持つ機能として、できるできないという議論になる可能性が高く、違うアプローチから開発されたアプリではさっくり解決できてしまったりすることもある。
なので、導入はしないにしても、広く検証なりしておかないと、全体として良くならない。

今回は、流し込みの視点で、どうなの?を見てみます。
それぞれ持ち味が違うので、組版機能で出来る、出来ないというのはありますが、
流し込み自体は全部対応していて、EdianWingはトリガー、MC-B2はB2タグ、InDesignもタグテキストと、いうことで、それぞれで流し込みができます。

これまたそれぞれですが、流し込みを補助するようなツールもあったりします。
流し込みを選択する時点で、大量ページものでないと、設計にかかる時間がとれないので、意味がないですが、スタイルの機能を持つ(当たり前なんですが)、InDesign、MC-B2の方が、まとまりがつきます。

そして、これからは流し込みだけじゃなくて、取り出しというのも考えていかないといけませんので、さらにスタイルの概念が重要になってきます。

もうひとつは、手をいれやすいデータにできるかどうか。
この辺りは、長い組版専用機の流れを組むEdianやMC-B2の方がよさそうです。
しかし、InDesignは、スクリプトという強力な魔法が存在するので、そういうのもカバーできるかもしれません。

MC-B2の表機能は、セル内の泣き別れができるのは素晴らしい。
でもInDesignのエクセル連携する表もこれまた素晴らしい。
両方とも、表もスタイルという位置づけになっていて、扱いやすい。

組版アプリは、組版作業を、いかに短い時間でやるか、というチャレンジに対して、失望させない将来性を持っている必要があります。

組版作業では、繰り返し作業を自動化するというのは、無くてはならない手法です。
そしてまたその部分を、組版仕様として、例えばスタイル、スクリプト、マクロなどで、ドキュメント内に管理できる、というのはかなり強力な支援機能だと思います。
そう考えると、総合的にみて、それができるのは、MC-B2かInDesignだろうなと。

Edianにスタイル機能がついてくればちょっと機能として魅力ですが、価格がなぁ、、、
安定性と歴史でしばらく前まではいちおしでしたが、ここまで周りが整備されてくると、決定打に欠けてしまいますね。頑張れEdian。

2009年12月13日日曜日

NGK2009に参加してきました

名古屋で活動しているコミュニティが集まって、LT(ライトニングトーク)するという企画。
なんで参加することになったんだっけ、と思い起こせば、ここ1年ぐらい勢力的にそういう人たちとコンタクトとろうとやってきた中で、自然な流れでそうなってました。

ここ見ると、いろんなコミュニティが参加しているのが分かります。
山本が積極的に動いてはいますが、関東方面がメインなので地元のことは、実はよく知らなかったりしたわけですが、今では、名古屋のコミュニティにも参加したりできるようになってきました。まだまだこれからも発掘していこうと思います。

本日は50人ぐらいでしょうか、名古屋市立大学の会議室が一杯になる感じで、そんな中、私と山本もLTしてきました。

といっても、僕の場合は、勉強会会場を探している人たち向けに、うちのセミナールーム、無料なんで是非使ってください、という宣伝をしてきました。
「探している人いますか?」という問いかけに対して、10名以上の方が手を挙げていたので、やっぱり需要はあるよなと。

休憩時間に遠く遠く離れた喫煙所(要は敷地外)でたまたまいた人に話しかけてみたら、使いたいと言ってくれたので、来て良かったなと思いました。
「無料でいいんですか?」って言われたので、「まあ実は動きたくないんで、来てくれた方が楽だし」という半分本気の冗談をかましながら、「勉強会って結局コミュニケーションなので、根っからそういうのが好きだし、技術者の人たち、技術者を志す人たちがコミュニケーションをとりたいのに、そういう場を探すのに苦労してしまっているなら、場所を提供することしかできないけど、役に立てるならやり続けたい」というような主旨で返答した気がする。

山本は、いっつも濃いお話をじっくりするのが好きで、大量のプレゼンシートを作る人ですが、なんとなんと、すっきりしっかりきっかり5分でまとめきって、エンターテイナーだけあって、ウケもよく上々の仕上がりでした。
Java is Groovy,Groovy is Javaのくだりでは、結構みんなが見入ってました。
Grails/Groovyへの関心が増えるといいなと思いました。

懇親会では、入社1年目の子とか、大学生とかが来ていて、ああ、こういう意欲がある若い人たちをもっと巻き込んで、もっと増やさなければと思ったのでした。
会場はなぜか錦三で、大安ということもあり結婚式の二次会がそこら中であるようで、入ったところもそんな感じのスペース。
プロジェクタとモニタがあって、LTの続きをしたりしました。
こういう飲み屋作りたいと思ってたのですが、是非今度音楽付きで、長野のGroovy?なVJを名古屋に呼びたいなと思うのでした。

いろんなコミュニティ、いろんな人と触れ合うことが出来て、とても良かったです。
さあ次は来週のScala勉強会と合同でGAE/J勉強会!

2009年12月12日土曜日

某専門学校で企業説明してきた

組合関係の活動ですが、うちは今回で2回目。
大学、専門学校とかに、インターンシップ受け入れまっせという企業が出張して、学生に企業説明をするというプチイベント。本番は、夢プロジェクトというイベントです。

とりあえず前回の企業説明で第一志望で逆指名した2名は3月中旬からインターンシップとして受け入れが決まっています。
2週間なので、特に何かすごい力になるようなことが教えられたり、吸収出来たりするわけではないですが、就活や面接、採用されて就職する前に、実際の職場を体験できるのは、学生にとっては良いことだろうと思います。

企業にとっては、というか、組合企業は中小ですから、そうそう10人も20人も採用できるわけはなく、1,2名というところも多いんじゃないかと思いますが、中小企業にとっての「人」の重要度からすると、今のうちから、次世代を担う人たちとのコミュニケーションは必要だと思って僕は取り組んでます。

今日ジョブエンジンのdipの営業君が言ってましたが、「つぶしちゃうつもりなら人材をとる必要はないですが、やるんだったら継続的にやらないと穴空きますよね」と。こいつ、いい営業だな、はっきり言うやつは好きです。

今日は100人ぐらいだったと思いますが、だいたい同じような時代を通過してきた人たちの塊なわけで、塊としてみると、それがひとつの時代にも見えてきます。

自分たちの世代と比べて考えてしまうと、なんだかいつもギャップを感じてしまうのですが、そうではなく、この世代の人たちの考え方みたいな中心にもやっとあるものを基準に置いた方がギャップを小さくできるんだろうなと思えるようになってきました。

リクルート系の人(ってあのリクルートではなく)が、就活についていろいろ学生に語ってましたが、履歴書とかそういえば書いたことないなというところから、今の彼ら学生の時代に数分間だけタイムスリップしてしまいました。

よくよく思い出してみると、高校の授業が終わって、適当な大学に合格して、入学までのバイトで、今の会社に入ったというか手伝いで行ったのですが、昔でいう写植が楽しくって、どっかで「これは天職だな」と思った瞬間があります。前社長に褒められて、確か昔使ってた事務所のエレベータだったと思うけど、「天職だと思います」って言いきった記憶があります。「そうか、頑張れ」と、とても喜んでくれたことを思い出しました。
僕は社員にこんな風に言われたことはない。でもそう言われるようになりたいなと改めて思いました。それがその時の勢いであっても、頑張って輝こうとする人たちを潰しちゃいけないと。

1時間ぐらいのオリエンがあって、その後、ブースに分かれて説明会。前回は山本氏が頑張ってくれたのですが、20人ぐらいを5ターン。1ターンが17分で、しゃべり倒しました。
内容は次のようなものです。対象は、新2〜3年生が多かったです。
・DTPで印刷物とWEBアプリを作ってる会社です。
  Flash系の技術が紙とWEBを繋ぐことになるんじゃないかという話をちらり。CG系もいたので。でもAIRとかは知ってる人がいなかったな。
・IT希望が多いので、ITでも常駐派遣タイプの企業とか社内開発スタイルの企業とかいろいろあるよ、営業はこういう人がむいてそうだよ、設計は、PGは…みたいな話。
・Grailsを使って、5分以内でWEBアプリケーションを作る
 Javaをちょうどやりはじめたぐらいなのですが、こういう技術もあるんだよと。
・勉強会とかに学生のうちから参加してみると、仕事や職場のもっと深いところまで聞けるかもよ。そこで拾ったキーワードを探っていくと興味の持てるものが出てくるかもしれないよ。

前半は向き合って話しをする形で、
後半は、学生君側の席に座って、隣から、後ろから僕のMacをみてもらって、実際作って動かしてみました。身を乗り出して聞くやつもいるし、つかれちゃったやつもいるし、寝てそうだったので、ゴルァの意味を込めて「大丈夫?」と言ってやったが、ノーリアクション。まあ仕方ない。一人でも多く、自分たちがやっていることを覚えてくれればそれでいいんだ、と涙をこらえながら5回の説明を乗り切りました。

最後に片付けしてたら、同組合員の社長さんが、僕が学生に混じって説明する姿を見て「町のにいちゃんが一生懸命後輩たちに教えてる感じがして良かったよ」と話しかけてくださいました。ちょうど黒板が後ろにあったので、それを勝手に使ったりもしてたので、もしかしたら、おめぇ目立ちすぎだというボディブローだったのかな。だったらごめんなさい。根が素直なので、褒められたと今でも思ってます。でも仕事の話とか、今度うちに遊びにいくよ、みたいなことも仰ってたのでいいのかな。気にしないでおこう。

あと、何人かインターンシップで来てみたいという学生もいるらしい、という情報を耳にしたので、とりあえず頑張った甲斐があったかなと。
こういうのは続けてこそ、積み上げてこそ成果が出る物なので、地道にいきます。

2009年12月10日木曜日

中間データを意識してWikiで文章を書いてみた

Wiki書式を中間データにして、InDesignとかMC-B2に持ってこう、なんて企画があって、実際お客さんに言ってみたらサンプル的な題材をいただくことができたのでやってみました。
※公開はできないですが。

「文書構造」なんていうと、XMLを思い出してしまいますが、ぱらぱらとその辺の本を見てみれば分かりますが、「ルールは、あるようでない」のが普通。なのでXMLとか考えるのはやめましょう。

今日あるお客さんのところでも、「XMLは機械(システム)同士のやりとりのためにあるだけで、人間がタグ打って作る物じゃない」という話で盛り上がりつつ、数年前は、それしかなかったから進めてた学会系のって、そろそろ変えませんか?的な提案をしないとな。。。

マニュアルとか、書き物自体が一定の構造を持っているもの、持っていた方がいいものは別として、たいがいの読み物は、ルールはなかなか作れないので、それならば「書式」として統一性を持たせる方向で考えた方が素直じゃないかということでWikiなのです。

XMLだと書式、スタイル、レイアウト、文書構造が一緒くたに考えられがちで、混沌とし過ぎて、「結局、何でこうするんだっけ?」みたいな意味不明の作業になってしまいます。

とりあえずWiki書式で書いておいて、複数の著者が好きなように書いたやつを統合するときに、全体のバランスをみて、揺れの調整をばっさり掛けてしまう感じで、一度に難しいことをやろうとせず、徐々に整合性をとっていくようにすれば、深く考えずにいけるかなと。
それよりもまず、DTPにしかなっていないデータをちゃんとその他メディアとも行き来できるコンテンツとして集約していかないと、とにかくもったいない気がしてならないのです。

なので、次のステップは、WikiをB2とInDesignに落とし込みをする予定になってます。

2009年12月9日水曜日

制作フローを分析してみて思ったこと

分析といってもあんまり大袈裟なものでなくて、入稿から納品まで、どのようなフローになっているのかなと、再確認したかったのでやってみました。

久々のオムニグラフ登場で、こいつぁ使えるねえ、とぶつくさ言いながらやってみたわけですが、だいたい出来たものを眺めてみて、

「うーん、分かりにくい…」

確かに、分かりにくい。。。矢印が各方面に出ていたり、分岐が多かったりということで、
気付いたのは、

「分かりにくい=作業が複雑化しすぎている」

複雑化は、無駄を生み、ミスを誘発する可能性があるので、これはなんとかせにゃいかんなと。

メールとかFTPとか、PDFとか便利なシステムや機能がたくさん出てきていいんだけど、乱立してしまったり、それぞれの連携を考えていないと、分散、複雑化するだけで実は時間が余計にかかっていることがある。そもそも時間を短縮するためのものだから。

確かに、これだけ複雑になっていると、迷いが多くなるので、初心者ほど、作業の手をストップさせてしまうとか、作業の流れを見渡せないので、その人しかわからなかくなっちゃう、という、「なんかよく分からないけど時間がかかってる」理由のひとつなんじゃないかと思えてくる。

作業はパターンな訳で、こうきたらこうする、こうきたらこれらの選択肢から一つ選んで次へ進む、というだけ。通常の制作業務で新しいパターンが存在してくることはまず無いと思う。(多分)
出会ったことのない新しいパターンのように思えるのは、それを単品で考えてしまうからで、何かの派生、何かの類似として、パターンにはめれば驚くことはない。たまに、今までやってきたとおりにしかできない人がいますが、そういうパターンを外れた瞬間こそ、いつもどおりやればいいし、今までの経験から何かと何かが繋がって、こうすればいいじゃん!という発想が生まれやすい瞬間でもあると思うのです。

もうちょっと事情を聞くのと、所々でトラップしようと思います。