CPubについて書いてみた

現在、開発中のWikiからepub,idmlを書き出すWebシステムの紹介をする。
このエントリーをそのまま紹介のショットにしてしまおうと企んでいることは、内緒にして「CPub」について書く。っていうか前置きいいから早く書けと。

CPubとは

文章を最近よく目にするようになってきたマークダウン記法で書く機能と、その文章を各種データにコンバートする機能を提供するWebアプリケーション。JavaベースのWebアプリケーション構築プラットフォーム（オープンソースのフレームワーク）であるGrailsを使用して開発したもの。

↑この画像は、2010年11月27日開催された

「DTPの勉強部屋　第19回」のLTで紹介したもの。

Wikiの（簡単な）解説

• その前に、「Wikiってナニ？」「マークダウンってウマいの？」という人のために簡単に解説する。Wikiは極めて広義なので、詳細は控える。Wikiの説明には、Wikipedia先生による解説があるが、読んでいると難しいので、Wiki自体が難しいと思われると嫌なので、ちょっとだけ解説したい。
• ものを書く人にとっては、書式に慣れさえすれば、ワ●ドよりも、●太郎よりも、種々あるブログなどのCMSの標準エディタよりも愛おしくなる（はず）。
• 例えば、ページを作りたいときには、ページ追加という機能もあるが、下記のように、ページタイトルを「[]※カギ括弧」を付けてリンクとして書くことで、準備が整う。

↑新しいページのリンクを書いたところ。（[CPubについて]）

↑更新すると、CPubについて（add）となる。

このリンクをクリックすれば下記のように、新しいページが作られる。

• このように作られたページは、先ほどのページを親とした「子ページ」として追加される。これは後からでも移動が可能で、文書を構造化しながら体系的に作成していくことができる。
• 代表的な記法では、行頭に「*」や、「#」を付ける（直後は半角スペース）と、リスト（箇条書き）にできたり、CPubでは「h1.」と行頭に付けると、HTMLでいうH1扱いになるという記法を採用している。HTMLの場合、<h1>〜</h1>で囲う必要があるが、マークダウンでは、行頭に付けるだけでその書式が適用されるというように、スタイルを簡略化して書くことができる。
• どんな記法があるかどうかは、システムにより異なるので、実際に試して確認した方が早い。と、この辺で逃げてみる。。。

CPubからの出力

• CPubは、これらの記法で書かれた文書を、現在ではとりあえず3種類のデータに出力する。※HTMLは当然のことなので省略。

1. bookreader
2. IDML
3. EPUB

• 現状でも出力出来る状態。あとは記法をどこまで実装するか、変換をどこまでするかだけ。

↑それぞれをクリックすると、そのページ以下の文書を各フォーマットに

変換してダウンロードすることができる。

bookreaderへの変換

• bookreader形式は、bookreader.jsとしてGoogleCodeでソース公開されている。ライセンスはAPL2のJavaScript。
• 文章をブラウザで読むときに、縦スクロールではなく、画面サイズに合わせた横スクロール型にするもの。縦が横になっただけの話なのだが、PCのブラウザで読む時には、この形式はかなり読みやすさを提供してくれる。
• iPadでもブラウザを通して見ることができるので、CPubでは、iOSのジェスチャーに対応するように改造したものを落とせるようにした。
• 書き手にとっても、擬似的なページ概念があるだけでも表現力として見たときに、素のHTMLよりはいいだろうと思う。
• ダウンロードしたzipファイルを解凍すると、下記のようなファイルが展開される。

↑index.htmlをPCのブラウザで開いたところ。

↑同じファイルをiPadのSafari（GoodReader経由）で開くとこんな感じ。

IDMLへの変換

• IDMLは、DTPアプリケーションのAdobeInDesignで開くことのできるデータ。DTPとはDeskTopPublishingの略で、その昔写植と呼ばれていた「版」を作る作業のこと。現在ではPC上でほぼ完結する。InDesignは、「印刷のための版」を出力ターゲットにしているDTP業界ではスタンダードなレイアウトアプリケーションだ。
• InDesignの現在のバージョンはCS5で、下記にも登場するEPUB出力なども機能として持っており、ドキュメントに動きを付けたインタラクティブPDF（Adobe仕様）への出力や、Flashへの持ち込みも可能となってきており、前述のように「紙のため」だけではなくなってきているのも事実である。
• CPubは、このIDML形式データ（InDesignでレイアウトをするにあたって必要なデータ一式）をダウンロードすることができる。

↑ダウンロードしたzipを展開したところ。

↑図１　book.idmlを開くと、InDesignが立ち上がる。（画面はCS5）

• 上の図１は、InDesignで開いた直後。ただ流れているように見えるが、マークダウン記法でかかれた「h1」や「h2」といったスタイルを、段落スタイルとして読み込んでいる。
• 画像も一緒にダウンロードされてくるので、インラインとして配置、リンクされている。
• InDesignのワード取り込みと比較した場合に考えなければいけないのは、ワードは機能の豊富さから、自由すぎて、いろんなことができてしまうので、複雑になりがち。その複雑さはかえってInDesignでは邪魔になる。それよりも、マークダウンで書かれてスタイルとして出てきた方が後の取り回しが楽である。

↑図２　簡単にそれらしく調整してみた。

• 図１の状態から、段落スタイルの調整と、テキストフレーム設定で2段組みにしたりと、それぐらいしかしてないが、体裁を整えていけば出版物のクオリティに持って行ける。
• ここまで行けば、InDesignを使える人ならもう説明はいらないと思う。工夫次第でなんとでもなる、という感覚を持ってもらったことだろう。
• 今までは、制作側の作業は、原稿データを加工するところから始まっていたが、こういうフローが確立すれば、効率化が図れるはずであるし、執筆者にも早い段階で、仕上がりイメージを出せることは良いことであるはず。なんなら執筆者がInDesignと、読み込み用のテンプレートを持っていれば、そのテンプレートにあるマスタページやスタイルを読み込んでしまえば完成、というのもありだろう。そしたら、うちいらんがな、、、ま、いいか。

EPUBへの変換

• EPUBは、iBooksなどの電子書籍リーダーアプリに取り込めたりするファイルフォーマット。詳しくはWikipedia先生に聞いてみよう。
• EPUBの利点は、PDFやHTMLの場合、文字の大きさなどの見た目は、執筆者側、制作者側が決める。読み手はその範囲内で文書を読む。それに対して、EPUBは、読み手側が自分が読みやすいようにレイアウトを変えることができ、制作側が決めた1行の文字数や1ページの行数などは関係なくなる。まあざっくり言えばそういうこと。
• iBooksなんかでは、ページに「しおり」を付ける機能や用語をマーキングするように「ハイライト」してストックさせる機能などがある。そのコンテンツをどう読むか、どう使うかは、ユーザ次第なのだ、というところがええところやないかと思う。
• CPubからダウンロードしてきた.epubファイルを、iBooksなら、iTunesの「ブック」にドラッグすれば終わり。
• CPubはネットワーク上でしかみれないが、EPUBならiPadに入れて、ネットワークがないところでも見ることが出来る。
• 今のところ体裁とかはあんまり考えずにダウンロードさせているが、なんかいいCSSのテンプレートとかあったらどしどしお寄せください。

↑ダウンロードしたのは、book.epub。

それを展開して中身を見てみたのがbookフォルダ。

↑iPad（iBooks）に入れてみたところ。

出演：@kanemu

CPubを使った出版物（紙もWebも電子書籍もなんでも）の執筆、制作ワークフロー

• 従来の一般的な出版フローは、

1. 執筆者がワードなどで原稿を書く。
2. 編集者が内容の精査としての朱入れも含み、編集作業を行った後、何かしらのデータとして制作側に渡す。
3. 制作側がレイアウトして、初稿を出す。
4. 編集者を経て執筆者が確認する。

• と、こんな感じのフローが繰り返されて、出版されるわけだが、いろんな人の手、作業を経ているこの状況は、昔から変わっていない。
• しかも、電子書籍などが一般化しようとする中、DTPデータが出来上がってから、そこから四苦八苦しながらデータを電子化するという非効率なことが一般的に行われる。
• それはそれで、悪いことじゃないかもしれないが、非効率はミスを生むし、時間をかけて結果を出したところで変更があるわけで、ただただお金にならない忙しさが増すだけである。
• CPubを使った出版フローでは、下記のようなことが考えられる。

1. よーし、書くぞ！と、執筆者がCPubで原稿を書く。
2. ここ、こんな風がええんちゃいます？と編集者が朱入れをCPub上でする。
3. あ、そうかも…執筆者はその内容を確認する。
4. そろそろ、レイアウトしてみっか、となったところで、IDMLをダウンロードして、体裁を整えて見てみる。
5. おー、こんな感じでええんちゃう、となったら、さらにCPub上で内容について精査する。これは、形が見えたときに、さらにやりたくなる傾向があるから。
6. まー、時間もないし、そろそろ本格的に体裁整えましょうー、となったらもう一度IDMLを落として、スタイルを読み込んだりなんだりして完成させる。
7. このとき、いかに自動化してレイアウトを再現できるか、いかにDTPオペの手をかけないかが勝負。ダメではないが、制作側としてはそれを目指さないといかんと思う。
8. どうしてもDTPで手直ししちゃったら、CPubをメンテ。ま、やろうと思えば、InDesignからバックもできると思うけど。そこに価値を感じてくれないならやらない。
9. んで、EPUB出しますか、ハイ、どうぞと。

• 美しいですよねえ。素晴らしい。これやりたいんだな、、、なので社内では始めています。
• 数式とかどうすんの？とかあると思いますが、まずはやってみようという姿勢がないとなんともならんし、やろうと思えば出来る話ばっかりだけど、始められるところから始めつつ、本当にそこに必要なものは何かを、執筆者や編集者、データ制作者で議論しながら進めないと、こういうのは成功しない。よーわかっとると思いますが。
• ちなみにDRM（デジタル著作権管理）とかは、僕らが考えることではないので、そちらでがんばってください。
• ついでにいうと、このコンテンツに対する著作権が議論されることはよくあるが、そのデータに対する著作権は議論されないのはどういうこと？

何をしたいか

• これは売り物のシステムとして考えていない。やろうと思えば誰だって、いつだってできるし、価格を付けた途端によくわからない未来への責任を負うことになるのが嫌。
• だれも見えてないこの先に価格という価値観だけで進むのは両者にとって良いことはない、というのがうちの主張。
• それよりも、こういうものをみんなでシェアして使いながら、制作を変えて行こうよ、というメッセージの方が強い。
• 今まで通りの制作なら、印刷というパイが確実に減る中、減退の一途。デジタルデータを作る我々が変えて行かなければ、だれも変えない。
• むしろ著者の方がこういう取り組みに積極的じゃないかと思う。そこにニーズはあるわけで、ほっとけば、いつのまにか完全な孤立もしくは融通の利かない業界になる。
• こういう気持ちに賛同してくれる人たちなら、一緒になってもっと改善していきたいと思っている。なので、そもそもCPubはオープンソースをベースに作られているので、それにならってオープンソースで公開していく。ダウロードについても、bookreader.js自体がオープンソースだからもちろん無料。IDMLとかEPUBはわがまま出そうなので、どうしようか考え中。
• とりあえずやりたい人募集中
• あ、PAGE2011でもやりますよ、この辺。

ということで、校正してないけど、時間なくなっちゃったので先にアップしてしまうのだ。

次は、自動組版系のdotSuriを書く。

InDesignを「連続で開く」「何かする」「上書き保存して閉じる」スクリプト覚え書き

連発で何かしたいことがよくあるので、メモ。

制作現場でさくりと使いたいので、下記の例では、例外処理とか何もしてません。

とりあえず開くファイル名は、CSVで与えるとする。
フォルダを選んでその中にあるファイルとかありますが、
ゆくゆくファイル名以外の情報も与えて与えてそこだけ何かするとかにも使いたいので、
こんなプランにしてます。
※例えば、ファイル名,50-53とかでページ数を与えて、そこだけプリントするとかね。

CSVの取り込みは、配列にさくっとしてくれる「CSVData.js」を使用。

下記サンプルは、
・CSVで与えたファイルを開いて、
・「す」という文字を探して、
・文字スタイルを変更して、
・上書き保存
するだけ。。。

#include 'CSVData.js';

var csvFile = new File('data.csv');

if(csvFile.open('r')){
  var csv=csvFile.read();
}

var fileList = CSVData.parse(csv);

for (i=0;i<fileList.length;i++){
  fileObj = new File(fileList[i]);
  app.open(File(fileObj));
  app.findTextPreferences = NothingEnum.nothing;
  app.changeTextPreferences = NothingEnum.nothing;
  app.findTextPreferences.findWhat = "す";
  var myFoundItems = app.documents.item(0).findText();
  myFoundItems[0].select();
  myFoundItems[0].appliedCharacterStyle= "あか文字"

  app.activeDocument.close(2036691744,fileObj,"",true);
}

上書きしますからね。テストとかするんだったら気をつけてくださいね。
怖かったら、

app.activeDocument.close();

としときましょう。確認ダイアログが出ます。

もうちょっとはしょってみると

#include 'CSVData.js';

var csvFile = new File('data.csv');

if(csvFile.open('r')){
  var csv=csvFile.read();
}

var fileList = CSVData.parse(csv);

for (i=0;i<fileList.length;i++){
  fileObj = new File(fileList[i]);
  app.open(File(fileObj));

  //やりたいことを書く

  app.activeDocument.close(2036691744,fileObj,"",true);
  // or app.activeDocument.close();
}

※ちなみにこれCS3でやったものです。

デジパブ2010行ってきた

2010年7月10日（土）デジタルパブリッシングフェアというか、ブックフェア、教育ITの併設展示会に行ってきました。

とりあえず参加希望を全員に声をかけて、増えたり減ったりしながら、最終的に8人。東名をPAGEのとき同様、レンタカーで日帰り爆走。。。と言ってもまだ若い大事なお命を預かる大切な運転手の仕事、往復約11時間安全運転で完遂したのでした。

まだまだやれるはずの37歳、二日目腰をやられました。

それはさておき…

教育ITもとっても面白かったのですが、とりあえずデジパブメインで報告します。

今年は年初から電子書籍が盛り上がってますので、予想通りというか、iPadやiPhoneが各ブースに並んでましたね。
１．iPhone/iPad向け電子書籍アプリ作成しまっせ、もしくはそういうサービスやってまっせ
２．あなたの電子書籍を配信しませんか、もしくはそういうサービスやってますよ
３．電子書籍のデータを作りますよ
４．電子書籍リーダーありますよ
と、こんなところで、はい終わりと言いたいところですが、epubというまだ漠然とした中から、
具体的な線で「電子書籍にするなら、特別なリーダーとか作らんでもブラウザでええやん」というように、HTML5とかにも確実に行ってるんだなあという方向性も見えました。
逆にFlashでというのが無かったですねえ。寂しい寂しい。昨年はまだ多かった「ぺらぺらめくるWebカタログ」が見事に消えた感じですね。（ちょっとあったけど）

ただ、まだ流行的なものが多くて、「これからは電子ですから！」みたいな業界先行型が、
地デジ対応テレビ（ちなみにうちはまだアナログ）を売りつける業界みたいでいやだなと、
しまいには３Dみたくよく分からない付加価値を押し付けるしかなくなるような始末におえない状態はいやだなと思うのでした。

しかし、電子書籍が「当たり前の存在」になりつつあるのは間違いなく、読み手の選択肢として登場する割合は非常に高い。
紙で欲しい時、端末で読みたいときというのを、どちらか、あるいはどちらも選べる、というのはユーザにとって、利便性は高い。

利便性の高さでいけば、その名の通り、Portable Document Format（PDF）ならば、リーダーさえあればどんなPCでも見ることができる。印刷物の転用であればそれで充分だという意見もある。しかし、PDFは基本的には固められたデータなので、データの更新や修正などを考えると、取り回しの効くHTMLの方がよいというのもある。今後はそれぞれの良さをユーザがどう捉えるかで柔軟に対応していく必要があって、あまりにも一方に傾くのは良くないと思う。

色んなニーズに対応するには、コンテンツの作り方、管理の仕方から見直す必要があり、なぜ海外の方がそうした動きが早いのかという点について、洋書のバーゲンセールに並んだ本を見て思うところがあった。

洋書は驚くほどシンプルであり、コンテンツそのものに時間をかけて、レイアウトや装飾の作り込みというのはそれほど時間をかけているように思えない。コンテンツという素材が前面に押し出されているという印象を受ける。それに比べて日本の出版物は、その素材を覆い隠すような施しがされているようで、無駄が多いんじゃないか、勝負するところがコンテンツ以外になっているのではないかという印象を受けた。その無駄（労力的にという意味）な部分は本のクオリティを上げているかもしれないが、その分、次へ繋がる道が狭くなっている気がするのです。今後は、力の出しどころを変えていかないとなかなかビジネスとしては難しい世界に突入するのではと思うのです。著者とユーザがネットワーク社会の力を借りてより近くなれる環境にあるわけですから、そういうことも総合してコンテンツそのものに重点を置いたビジネスが成功していくだろうと思います。

展示会というのは、そこにいかないと体験できない空気があります。業界がどう動いていくか、ユーザの視点はどこにあるのか、そういったものが見えるよい機会だと思います。そういう中で、ふと自分たちの方向性を確認するよい機会でもあります。

個人的には誌面にある画像をなぞると音（鳥の声とか）が出る図鑑とか良かったです。
確実にターゲットを絞ってそこにベストマッチさせるというのが、採算が合うベースで展開されることを期待したいです。良い物なのに大量に売れないから、採算が合わないからできないって、とっても悲しい。それを欲している人がいるんだし。ということで、介護事業部に1個置きたいなと。

「第2回テクニカルDTP勉強会」開催されました！

記念すべき第1回から３ヶ月（？）…2010年6月26日「第2回テクニカルDTP勉強会」が開催されましたとさ。

この記事は、今回の内容についてというより、主催者的立場で今回の開催を振り返った内容です。技術情報については期待しないように。あしからず。

何をやるのか、タイトルさえも決めてない勉強会は珍しいかもしれないですが、決まってないからこそ、自分が勉強会に持ち込んだ期待は、実は自分への期待だということに終わった後に気付かされる。
それが、後味が良いという感触の理由かもしれない。
これは参加してみないと分からないもの。

…と、ずぼらな主催者は思うわけです。

設立当初、集まって10人ぐらいでしょう、コソコソやりましょう、という軽いノリで始まったのですが、1回目に引き続き2回目も20名を軽くオーバー！

いいですねえ、だんだん訳が分からなくなる。
先日「DTPの勉強部屋」が名古屋で開催されましたが、なんと隣の会議室では「Flex勉強会＠名古屋」が開催されておったのです。紙とWebの境目がどんどん低くなっていく気がしてなりません。そして、ここに集まった参加者は、その真ん中に位置する人たち。
面白すぎて仕方ないですね。

１．サーバ自動組版のランニングコスト算出とか
（@mkawax）
自分なので、適当にとおもったら、@iki_osuさんが書いてくれてるではないの！ありがとうございます！
http://kstation2.blog10.fc2.com/blog-entry-424.html

何が言いたかったかよくわからんですが、続く人たちがもっぱら「濃い」と思われ、Web入稿自動組版やりたいっていうけどさ〜みたいなのを柔らかくやって、口火を切ろうと思ったのです。

２．"InDesign CS5 extension + Google翻訳サービス連携デモ" ＋ Flash Builder 4
（@tomoakioshima & @tyama）
Adobe Flexを使って、CS5のエクステンションを作る方法の紹介です。
詳細は下記ブログで。
http://blog.my-notebook.net/indesign_cs5_extension.html

スクリプトをJSで書いて配布というのも別にできるんですが、エクステンションとしてInDesignのパネルに、ここまでさくっと入れられるとこういう配布ができるとベターですね。

３．opub（オレパブ）
（@nbqx69）
http://d.hatena.ne.jp/nbqx69/

解説すると、解説できません。
いや、つまり、制作の環境をひとまとめに"pub(zip)った"もの。
人はそれを「オレパブ」と呼ぶ。
DTPerにスクリプトを使って欲しい、どうやれば使ってもらえるだろう、という
スクリプトを書く人なら誰でも考えるこの壁を無かったことにしてしまうこの作品。
長野からはるばるやってきた彼には他にも色々と見せてもらいました。

紹介は下記から。
http://nbqx.jottit.com/opub

４．カネムー「スクリプト・プログラマー宣言」するの巻
（＠kanemu）
彼自身をなぞった「Adobeスクリプトしか書けなかった自分は、どのようにプログラマとしての成長を試みるべきか」といった内容。
こんな彼に、みなさん是非会うべし。
http://kanemu1117nc.blogspot.com/2010/06/dtp.html


５．FlashCatalystと戯れる
（＠hokori）
AdobeがFlashCatalystを出してきたって事で、AI→FCで作るFlashコンテンツの制作フローがどこまで出来るのか、AI上で画像を配置するときに工夫しないといけなさそうだっだりする話とか、実際使うかどうかとか、試してみた感想を話していただきました。他の参加者からも実際使ってみた感想をいただいたり、「紙」と「Web」の繋ぎが今回の目玉じゃないかと思うCS5ですが、興味を引かれるアプリですよね。Flash慣れてる人は、普通にFlashかもしれないけど。
ちょっと横道にそれますが、InDesignCS5にはインタラクティブ機能がついてて、それをもとにFlashへ持って行ける。しかし、AIにはその機能がついていなくて、書き出してからの作業となる。この辺が、Adobeとして方向性がどっちなんだろうという疑問がある。ただ、パネルなんかがFCはもろFlexで作られてるのでもしかしたら、AIも実はそっち側で統合されていくんじゃないかとか。まあ、想像は膨らむばかりです。

６．Adobe Configurator 2.0って…
（@tyama & @mkawax）
そういやこんなんあったよ、って程度の紹介です。
ツールボックスからオブジェクトを並べてボタン作ったり、スクリプト埋めたりとそうすることで、CS5のエクステンションが作れる。書き出しは、Pluginフォルダを選ぶとそこに展開される。ZXPでのパッケージ化は無理なのか、、、配布を考えるとFlashBuilderを使ってZXPを作った方が良さそうですね。

７．epub談義
（@YUJI_ID）
ちょっと時間あまったので、隣にいたYUJIさんに「EPUBの話してくださいよぉ」とおねだりし、ご本人は「つまんないですよ」と言っておられましたが、すみません、そのまとめっぷり…年の功には勝てません、、、ということで、とっても勉強になりました。
「InDesignの勉強部屋」のYUJIさんですから、やりたいことは下記。
・InDesignでレイアウト・組版する
・InDesignからEPUBを書き出す
・iPad/iPhoneなどのEPUBリーダーで読む
ご自身の著書を使って、フォント埋め込みや書き出し方など、いろいろと試しているところをお話いただきました。

中でも、誌面レイアウトとEPUBレイアウトには違いがあり、印刷物先行である場合は、どうしてもEPUBでは再現できないレイアウトがあり、テキストの流れや図の位置など、ある程度の「レイアウトの型」にはめるしかない。かといって誌面のレイアウトをくずせば、見た目のクオリティが下がる。かといってレイアウトを保持するためにEPUBじゃなくPDFにすれば…とどうどうめぐりになる。

所感では、「その本を一番読ませたい人に合う形（機能）を提供することを優先する」と考えた方が良い気がする。

これは、昨日のtyama昼食談義で、似たような話が…
〜〜〜〜
アプリケーション開発において、色んなシチュエーション、端末、ブラウザなどに合わせることを考えるよりも、一番使われるだろう年代、例えば「40歳女性にウケるアプリ」というようにターゲットを絞って作り、他は合わせられれば合わせる、という方がよい。いろんなものに合わせようとすれば、結果それは担当者の勝手な妄想によって作られたものにしかならない。まずは、ターゲットにばっちりはめて、次第にそこに自ら集まってくるユーザを狙う方がよい。
アプリ開発、システム開発において、すべてのOS、すべてのブラウザ、そしてバージョンに合わせることは、機能が豊富な程、不可能に近い。コスト的な面もそうだが、知らないうちに変わってしまうユーザの使用環境に合わせることは無理である。
〜〜〜〜

例えば、アプリケーションの解説・習得本を例に考えると、
そのアプリを使っている最中にどう使われるかを想定したものであったり、
電車とか移動中に読む場合に適したものを考えたりと、
シーンによって端末は違うと思うので、それを全部無理矢理網羅するものはできないから、順番に合わせて作っていけばよいと思うのです。

逆に言えば、そのシーンをこちらから特定（またはオススメ）することもできるかも。
喫茶店用とか、電車用とか、多分そのロケーションでその人の気分も違う。
そのロケーションだからこそ発揮できる見せ方ってのを考えると楽しくないですか。ただ字の大きさとか縦組みとか横組みとか、その手前にユーザのニーズはあるんじゃないかと、それだけなんですけど。

提供側が全部まとまってる方が制作コストがかからんから、というのは、そもそもこの電子書籍の市場では無理かと。

＜追伸＞
ワールドカップ残念でした…マジ泣きしました。
こんな自分の、明日の自分はとっても恥ずかしいと思われます。

以上
遅くなりましたが、報告でした。

みなさん次回またお会いしましょう！！

ADOBE® CREATIVE SUITE® 5 デザインセミナーツアー in 名古屋で「テクニカルDTP」を紹介

2010年5月18日名古屋ミッドランドホールにて「ADOBE® CREATIVE SUITE® 5 デザインセミナーツアー in 名古屋」が開催されました。

地元企業として20分のセッション枠が用意されたので、「テクニカルDTP」を紹介させてもらいました。
CS5の発表のために集まった300名近い人たちを前にしたとき、なんてぇ安請け合いをしたもんだと反省。

CS5の話を聞きに来たのに、、、と思ってる人もいたんだろうな。。。まあしょうがないね！

当日話しきれなかった、伝えきれなかった内容を、ここに書いておこうと思います。
※当日の資料はこちら。
テクニカルDTPというと、スクリプト使ってとか、自動組版とかの話でしょ、とか言われると困るのです。
それはあくまで、そういうこともできるよね、というだけのことであって、
もっと制作という部分にスポットライトをあてるべきだ、というところなのです。
またまた長い戯言。お付き合いいただけそうな人は、付き合ってください。

テクニカルDTPについて、20分で語れるものではないですが、せっかくAdobeさんのセミナーなので、

１．どんなにソフトウェアが良くなろうとも、使う側がその価値を理解して、その価値を対価に変えないといけないよね、
２．僕ら制作側（ソフトウェアを使う側）の人たちは、その価値を理解する必要があるし、
３．対価によって得た価値を、今度は自分たちの対価に変えていかないといけないよね、
と、いうことが言いたかったんです。

そうしないと、制作は環境も良くならないし、給料も良くならない。
ソフトウェアを出すメーカーさんも買う人がいなくなれば、オープンソースにでもしない限り続けられない。
作る側、使う側が共存できる関係になければ継続はない。
素晴らしいソフトウェアを開発する人たちも、それを使ってクリエイトする人たちも、みんないなくなる。
であれば、今、この時代はなんなんだと。僕らがやっていることはなんなんだ、ただただ衰退に向かうだけのことなのか。

どれだけ「お求めやすく」なったからって、金はかかる。
Adobeさんからして、開発してバージョンアップするにも金はかかるから、その価値の対価を求めているわけで、
僕らは制作という中で、価値を高めてその対価を要求すべきである、と思う。
そういった努力をせずして、現状に甘んじるのは負け犬だなと、自分に照らして思うわけです。

印刷費の中に制作費がコミコミなる時代に慣れすぎている僕も含めた制作側の人たちは、
作ることに自己満足しすぎて、そしてやりすぎている（時間をかけすぎている）部分もある。
クリエイティブでありたいならば、価値を対価に変えるべき。変えていくべき。主張すべき。
何も間違っていないと思うのだけど、どうなんでしょう。

勘違いしてもらうと困るのは、金を出せ、といっているのではない。
限りあるお財布と、でも今後こうしていきたい、というようなやりたいことがあるのなら、
順番にやっていきましょうよと。
今は、ただ作るだけ、その場しのぎの積み重ねが、今の状態を作り出していると気付かないといけない。

制作の仕事は、直接その版元となる会社から請けることもありますが、まだまだ印刷会社からお仕事をもらうことが多いのが実情。
印刷会社に比べれば、営業の人数は圧倒的に少ない。うちなんて一人もいない。
でもそういう会社だからこそ、「制作＝物作り」を真剣に考えて生きている。
情報を伝える手段として、紙が減っていく中、ユーザー自身がその情報を得るデバイスを選択する時代に、
それを主に考えている人たちのビジネスにぶら下がって、コスト削減要求に応じる必要なんてあるのでしょうか。


営業が「ああ、そんなら他でやってもらうからいいや」「お客さんがここまでしか出せない」と言うならば、
それが、全うであると諦めるしかないのであるなら、そこに未来はないでしょう。
彼らは、その価値を対価に変えようとは何も思ってないということです。
ただただ価格競争に勝つために値下げを受け入れる。
お金を出す側、請ける側、作る側というところの変な上下関係が続くのであれば、この先、紙の世界なんて存在しないでしょう。
それは、「紙」を必要としないから、というわけではない気がします。

別に営業さんだけが悪いわけでもない。その価値を伝えられない、対価に変えられない体制、それを作り出している業界自体が悪いということになります。

オペレーターも、営業さんも、経営者も、お客さんもみんな悩んでるのに、
ポイントがずれている。
自らそうさせている、というところに全体で取り組まないといけない。

その不合理さ、矛盾を一番押しつけられるのは、誰ですか。結局、末端の制作です。
システム開発でいえば、プログラマです。

物が出来た後で、何か言おうとしても遅い。
出来てしまえば、彼らはというか自分も含めて、その苦労、こうした方がいいんじゃないか、ということは
きれいさっぱり忘れてしまいます。

作っているとき、その工程の最中（原稿作りから、DTP、校正、プログラミングなどなど）にこそ、
今の課題をクリアするためのヒント、次の時代へのヒントがいっぱいあるわけです。
だから、制作という工程を大事にしないといけない、ということなのです。

だって、確実に紙は減っていくんです。
ならば、制作の人たち、クリエイトすることが好きな人たちは、情報を提供する側のひとたち（出版社であったり、著者であったり、編集の人たちであったり）ともっとどうすべきかを一緒に考え、違う方、別の未来へ向いていってもいいと思う。
もっともっと、ものを言っていいと思う。

さてさて、みなさんどうお考えになりますか？

「テクニカルDTP」第1回勉強会 無事終了

2010年3月20日ニューキャストのセミナールームで、テクニカルDTP勉強会の記念すべき第1回が開催されました。

お題を一切決めてませんので、適当に開始されたわけですが、
参加メンバーからして特に心配することもないなと思いつつも、
どうなるかしら、という一抹の不安も抱えつつ開催したのでした。

テクニカルDTPとは、tyamaさんによる命名ですが、その意味を私なりの解釈で解説すると、DTPというもの自体に写植や製版などいろんな意味が込められ、まして今はワードもDTPとして存在するわけで、そんな中、従来の情報処理的な組版というものがその中で陰を潜めている感があります。しかし、これから時代はまさにこの部分が脚光を浴びなければいけません。それこそ、テクニカルDTPという発想は、Webさえも包み込むものだと考えています。Publishのためのデータは、印刷、WEB関係なく、データ作りという点において、テクニカルな手法が必要だということを広めていきたいと思っておる次第です。（多分概ねそういうことだと）

当日は、15名＋αのメンバーが集まり、14:00〜18:00のタイムスケジュールで開催されました。


まずは、自己紹介から。
それぞれ自分が今やっていることなどしていただきまして、
だいたいどういうメンバーか把握できたところで、山本氏からスタート。

セッションテーマ１　IDML
山本氏「TwitterアカウントからIDMLでInDesignで名刺を作ってみる」
ブログはこちら

PAGE2010の頃に、ちゃちゃっと作ったやつですが、IDMLのこういう使い方もあるんだというのをデモしてもらいました。Web入稿されたデータからどうやってIDMLに落とし込むかというところで、議論がなされたのでした。

セッションテーマ２　電子書籍
YUJIさん「自分の本を電子書籍にしてみる。そしてiPhoneとかも」
まだ、実験段階ということでしたが、最近いろいろと挑戦している電子書籍（EPUB形式）とか、iPhoneアプリなどなど、現状と今後についてお話していただきました。
テクニカルDTPという分野が、一般的に言われているDTPと、WEBとを融合させるためには、絶対に必要な気がしてきたのでした。

セッションテーマ３　Script
カネムー「IllustratorのScript作成Tips〜ExtendScriptを自分はどう使って書いているか」
実際、どうやって書いてるかをとつとつと説明してくれました。スゴイ結果も、地道な作業で組み立てたコードで実現しているんですよというところがカネムーらしいお話でございました。
ブログ

セッションテーマ４　XML　GoogleAPI　翻訳
大島さん「XML＋GoogleAPIを使ったなんちゃって翻訳」
いまいろいろ一緒に動いてもらっている大島さんです。翻訳にGoogleAPIを使って、XMLを翻訳してしまいましょうという遊びネタです。遊びといっても、こういうやり方もあるんだよねと。そして、いつかそうなっていく、というのを今まで体感してきたわけですので、今はちゃんと出来なくても、これからの技術の基本になるかもしれませんね。

セッションテーマ５　InDesign　XML　多言語展開
大島さん「InDesign + XML による即効多言語展開」
多言語というと、FrameMakerがまず浮かぶわけですが、ここはひとつInDesignでということで挑戦したデモでした。次のセッションにも関わってきますが、データに自動的にタグ付けを行うという発想。そこまで出来ればFMと同等になれるわけなので、そこにInDesignを使うことで自由度が増す（んじゃないかと）。FMも人口が減ってきてそうなので、今なら、InDesignでも代用できるんじゃないの？ということでした。

セッションテーマ６　InDesign　データ解析　データベース
大島さん「DTPデータを解析しながらデータベースを作る」
このセッションは、ニューキャストネタですが、うちのカネムーとともに大島さんにもいろいろ手伝っていただいて形にすることができました。何より説明がへたくそな我々なので、お任せした次第です。
かなりの反響でその後もしばらく話題の核になりましたが、InDesignのデータを解析しながら、データベースを作っていこうというもので、既存のプロジェクトで苦戦している方々には、目から鱗的な手法です。
この辺をオープンにする太っ腹さを感じていただければ幸いです。
こういう風にでもしないと、業界の技術の底上げなんぞできません。
これが一番だとは思いませんが、いろんな技術がどしどし世に出てくることを期待しています。

第2回も4月後半か、5月にはやりたいなと思ってます。
正直ここまで反響があるとは思わなかったのですが、
下記Googleグループでも開催情報など流していく予定です。
Googleグループ「テクニカルDTP勉強会」
※ユーザになるには申請が必要です。

ということで、テクニカルDTPをどんどん広めていきましょう！

InDesignをiPhoneのStanzaで読める電子書籍にしてみる

ざっくりですが、、、、

InDesignCS4で、「Degital Editions用に書き出し」というメニューからePub形式に持って行けますが、iPhoneの電子ブックリーダーのStanzaにそのまま持ってこれるかなと思いきや、エラーで持って来れず。。。

なので、とりあえずうまくいった方法を。
１．InDesignCS4→「Degital Editions用に書き出し」でとりあえずePub保存する
２．ePub形式のデータを作ってくれる「Sigil」で、１のデータを開き、Save asで保存しなおし。
３．先に「Stanza Desktop版」をインストールしておいて、それで２のデータを開く。
４．iPhoneでStanzaを開き「ライブラリ」→「共有ブック」とタップすると、「Books on 某」と出てくるので、そうすると、３で開いているデータが出てくるので、それをダウンロードする。
※InDesignから書き出したデータだとここでエラー。
５．取り込み完了すれば自分のiPhoneで見れる。

ということで、なんとなくInDesignからiPhoneで読める電子書籍にできると。

今後例えばですが、AdobeからInDesignで書き出したデータを「うまいこと」持って来れるような繋ぎのツールが出てきたりすると、すごく加速しそうだなと。リーダーとかもですが。

それとInDesignで作ったデータを電子書籍にする場合、というかePubにする場合、作るときに想定した作り、例えば、タイトル、見出し、箇条書きなど、表現しやすい、持って行きやすい作り方にしておくのは重要と感じましたね。
※ちなみに、合成フォントはブブーとなったり現時点ではしています。

「鉄腕アトム」がそうであるように、「システム」は人である

手塚先生って素晴らしいなと書き終えて思った次第。。。
システム導入の検討にあたってどういうスタンスで考えるべきなのか、みたいな内容です。
長いな、相変わらず。

最初はたいした知識もなく、思わぬミスもするかもしれない
座って、見ているだけ、聞いているだけかもしれない

周りが悪者一味なら、悪いことを覚えてしまうかもしれない

しかし、一番の取り柄は、忘れろといわない限り「忘れない」こと
そして、他の人がめんどくさくてやりたくないと言う
単純で連続する作業を「文句を言わず」に、そして「間違わず」にやってくれる
100万馬力はないけれど、CPUをガンガン回して自らの極限を知らずして頑張る

時間がたつにつれ、いろんなことを知るようになり、出来るようになる
今まで数人で時間をかけてやっていたことを、一人で瞬時にやってしまう

そしていつのまにか想像を超えたパフォーマンスを出せるようになる

「鉄腕アトム」を正しく育てる自信と決意があるならば、システム導入すればいい
彼は地球を救ったが、システムは企業を救うかもしれない

現場は、会社からこう言われる
「コストを削減せよ」

それは、
　残業を減らせ
　余分な人員をピックアップしろ
　もっと生産能力を上げろ
という言葉を別に言い換えたもの
僕もトップだから、その気持ち、よく分かる

現場にも、こういう思いがある
「もっと楽したい」
僕も現場的仕事をすることもあるから、よく分かる

労使間のよくある言い分であり、両方とも正しい
利益を考えない企業はダメだし、効率化を考えない現場もダメだ

そこで、両者が同意するのは、
「システムを入れよう」
または
「システム化しよう」

「よし、じゃあそこの君、調べてくれたまえ」

いろいろ調べ、聞き、見積もりをとり、稟議書をまとめる

「やりたいことができそうなんだな、それで費用は？」

「ウン千万円です」

「費用対効果は？」

「楽になりますし、時間も短縮できそうです。」

「いや、費用対効果を聞いているんだ。どのぐらいで回収するんだ？」

ある特定の部分にしか影響を与えないソフトウェアであれば、限られた範囲で算出することはそれほど難しくないだろう

しかし、我々が相談を受けるものでいけば、それは広範囲に影響を与える
単純な自動組版システムでスタートしたものが、いつのまにか基幹システム並の扱いを受けることも少なくない

企業としては、年単位の決算で利益を出さなければいけないから、どれぐらいで償却するか、そこで利益を生み出せるかを試算する必要がある
うちみたいな小さな会社は、もとより資金繰りが命だ

ただ、うちは小さいから、やるべきときは腹をくくる
すべてはトップである僕が責任をとればいいだけだから

しかし、大きな組織は、いろんな人に与える、その責任の影響は大きい
当事者の想像以上に大きい
自分のせいで数百人単位の仲間の人生を変えてしまうかもしれない
それはみんな慎重になる

こうなってしまうと、採用、導入までの道のりは非常に長くなる
何度も何度も色んな人に説明をし、理解を促す

やがて担当者は疲れ果て、
そのうち予算申請の期限は過ぎ、
通常業務が忙しくなり、
来年に持ち越しとなる

大きくなればなるほど、そこに明確な理由付けが求められる
とにかくやっちゃえ、ということはできない世の中だ

本当にこういうことが多い
知識経験ぐらいは残るが、そこにかけられた費用を合算すると、そちらの方が問題じゃないだろうか
また、営業的に言えば「機会損失」を何度も繰り返している事になりかねない

そうなってしまう要因の根本はなんだろうかと考えてみた

それは、システムをソフトウェア、いわゆる「モノ」だと考えてしまうからではないか

「購入」した以上、その「モノ」は、購入前に約束（コミット）したことが実現することが当たり前である、という考えに基づいている

てめぇんとこみたいに小さい企業じゃねえんだよと言われても続ける

新しいシステムは「新人」であり、
　導入検討は「新しい人材獲得のための採用活動」であり、
　設計は「面接」であり、
　開発は「新しい人材を自社に適用させるための教育」であり、
　テストは「試用期間」であり、
　リリースは「正社員化」であり、
　保守は「人のケア」だ
ひっくるめて、そこにかかる費用はすべて「人に対する投資」である

新人にもいろんなタイプがあるだろう
　高卒で若く、将来に目を輝かせているような、磨けば光る人材
　大卒でしっかり勉強してきた、やる気のある人材
　転職してきた、ある程度スキル・実績を持った人材

しっかり面接して、教育しなければ、適合しない
採用したままほっといて、うまく適材適所にはまることなんてない
そしてその人のパフォーマンスがすぐに出せることなんてない

即戦力、完璧だと思った人材、変な癖を持っていて、
後になって問題になったりすることもあるかもしれない

大丈夫かなと思った人材が突然花開き、莫大な利益をもたらすかもしれない

人の採用は、投資
システムの採用も、投資

投資だから、言ってみればギャンブルと同じ
それまで培った知識と経験、勘からできるだけ高確率を狙う

ギャンブルが人任せであるのに対して違うところは、
周りの努力で変えられる可能性が高いということ
人材を上手く使うには、その人を教育し、その人と話しをし、その人を知り、お互いの信頼関係を構築する
それしかないと思う

ずっと椅子に座っていて給料がもらえるなんてことはないし、
そんなやつに給料を払いたくはない

どう使うかは周り次第

合わなければ、切るしかない
そこまでの給与返せとは言わない
面接の時の実績の話は嘘だったかもしれない
でもそれを信じてしまった会社も会社

雇って、教えて、やらせてみてからでないと分からない
雇うときは、「まぁちょっと雇ってみるか」か「よしやってみるか」というような思い切りがあると思う。それと「とにかくやっちゃえ」は同じで、保証はどこにもない。

それは企業がよく知っていること
それと同じなんだと思う

採用を促す上司が、
「こいつ、良いやつです。僕はこいつを一生懸命育てます。だからとりあえず1年間置いてやってください。どうしてもダメだったら僕をクビにしてください。」
と言ってくれたとき、
「この人について行こう」
と思う「こいつ」なら、きっとやってくれるはず

その信頼関係が築ける環境のある企業なら、人もシステムも育つ

てな感じで…

テクニカルDTPの源流

この間、組版業の大先輩にお会いして、お話を聞くことができた。

自ら書く「組版を楽にするためのプログラム」を「日曜大工と同じだから」と言い切る。

全ては「自分が楽をするため」であり、「飯を食うため」

XMLだ、eBookだ、なんていうのは、遠くの方で盛り上がっている祭りで、自分たちは、お祭りの途中でのどが渇いたという人にラムネを売る、お腹が空いたという人に焼きそばを売る、そうやって「自分が飯を食うため」に組版という仕事をしている、と。

VBで書き、UIはボタン1個。

今日来た「おねえちゃん」でもボタンを押せば、30年組版をやっている人と同じ結果が出せるという。

これこそテクニカルDTPだと思う。

DTPにもテストという概念がますます必要なんじゃないかしら

DTPってある意味、システム開発でいう「アジャイル」な方式で出来ていくものだという話をこの前していた。

ここはやっぱりこういう機能が欲しい＝ここはやっぱりこういう文面にしたい

これは完成物を見て出てくる意見（欲求※要件、要求ではなく）であって、僕はそのケツを決定するもの、もしくはそれをやるかどうかは、時間（割り当て可能な時間）だと思ってるんですが、この作業の積み重ねで出来ていくものとすれば、同じような感覚が必要だと考えられます。

反して、ウォーターフォールな方式でいけるかというと、DTPは無理。言うなればシステム開発も無理。
DTPにいたっては、「これ追加」「これ変更」は当たり前であって、それがあるからこそ、DTPの仕事があるわけで、それに対応しません、ということであれば、職自体必要ない。だって、それはただコンバートしただけだもんね。

「無いもの（見えないもの）」を作り出すということは、その目指す先の「有」は、だれも見たことがない。だれもそれが完璧だという姿をなんとなく想像はしていても固定的に限定的に指し示すことはできない。なんとなく自分の想像に近いところで、OKを出すしかない。

だから、DTPもシステム開発もクリエイティブな世界なんだと思うのです。

だからこそ、作り手は、お客さんの想像から、創造しなければいけない。
常にプロフェッショナルな立場からそれを作り出すという関係で成り立つものだと思うのです。
だから、色んな便利なツールとか沢山あって、誰にでもできるんかというと、そうではなく、やっぱりそれが成り立つには相当な努力をした人たち、それが好きな人たちだけが生き残っていく世界なんじゃないかと。

話逸れますが、先日美容院の年下の店長が言うとりました。
たまたま美容院関係を目指す人向けのフリーペーパーがあって、その話題の中ですが、
「美容師ってさ、結構目指してる人多いよね？専門学校とかもあって」
「いっぱいいますけど、結局なれるのはホント一部だけで、みんな対外辞めていきますね。」
「ネイルとかはやってるっぽいじゃん」
「誰でもできるようになっちゃって、どんどん値が下がっちゃって、今やっていけなくなってるみたいですよ。僕らは値段は下げないんですよ。そもそも誰でもができるものではないんですから。」

これを聞いて、ああこいつもクリエイティブな世界のプロなんだなと。そして厳しい修行に耐えて今があるんだよなと思ったわけです。

んでんで。。。話戻します。

僕らの世界に戻すと、どちらかというと完成したものにクリエイティブさを求めるのではなく、その作る過程において求められるものとなります。
だって、DTPでいけば完成したものはレイアウトされたページだし、システムでいっても、使う側からすれば、別に中身のソースコードが綺麗かどうかなんてのは関係ない。

ただ問題は、どう作られたかが重要で、ちゃんと出来ていなければいけない。
DTPで言えば、間違いがない（印刷トラブルになるような要素も含む）かどうか、
システムで言えば、ちゃんと動くかどうか、
両方ともお粗末なミスを含んでいるようではプロとは言えない。

それには、作り方が非常に重要ということで、DTPにもその品質を担保する「テスト」という概念への取り組みが必要だと思うのです。

そのテストは、
・最初の要件では、前述通り決められないので、随時変わっていくもの、足されていくものというのが前提
・プログラム的チェックが可能か、目検が必要かを振り分けをする
・テストが通るように作る
・テストして、それが通ってから初校、再校ごとに納品する
というようなことを考えています。

印刷のためのプリフライトチェックとかありますが、それも含まれます。
しかし、その内容まではチェックされません。
データなんですから、今後は、もっと内容まで掘り下がったチェック（文字、文言とか、画像、著作権とかもあるかも）が必要とされると思います。

それから、もう一つ、なんで必要かという理由になるものは、電子書籍やコンテンツの再利用など、今後「データ」としての扱いが重要になってくるということです。

なので、印刷は、その出力方式の一部でしかなく、当然その品質を保つことも重要ですが、今までのように「印刷ありき」という考え方から、徐々にシフトできるところから「データありき」という認識に変わっていくと思われます。

僕らは印刷にするところが得意だというアプローチから、その制作の仕事をいただいているわけですが、ただ出来るというわけでなく、プロフェッショナルに展開できないと意味がない、ということだと思うのです。

2010年 明けましておめでとうございます

ひとまず年末ジャンボもかすっただけで終わりましたので、ちゃんと仕事しないとダメだなと、気持ちを引き締めて今年も頑張ろうと思います。

僕が景況なんぞ語ってもしょうがないので、印刷とか出版に関係するあたり、しかも自分のところに関係するあたりで、考えてみたいと思います。

まず、個人が印税35%の電子書籍を出版できる時代 - Amazon Kindleの衝撃とか、
大晦日特番「誰が電子書籍を読むのか」の閲覧メモにあるように、今までのスタイルを貫くか、見切りをつけて新しい方向へ舵をとるかは、版元さんや著者の方々の考え方によりますが、出版の流れは大きく変わっていくのはもう間違いないことなので、それを見据えて備える年になりそうです。

電子書籍やリーダーなんて必要ない、なんていう時代はとうに過ぎていて、ユーザー（読者）が、欲しい本またはコンテンツを手に入れたい「モノ」「手段」として欠かせないものになる、ということは必至であり、必然的に電子データの重要性が高まる。

コンテンツの様々な用途を目的とした作り方もさることながら、データを「保管する」という点においても、不明瞭な点は今でも多く、それがGoogleさんたちの目論見に一網打尽にされてしまう可能性を持たせてしまっていると思います。

コンテンツデータをいつでも使える状態、使いたいときに使える状態というにしておくことが必要で、そのためには、
・データはどこにあるのか？
・データの持ち主って誰なのか？
・そのデータはどんな（何で作られた）データなのか？
・そのデータはいつからいつの期間で有効なのか？
などなど

…ああ、これ濃くなるので「DTPデータの保管について」という別記事にしよう。

この辺りをちゃんと整理する必要があると思います。

今まで頑張って作っても「印刷」という工程を超えて、何年もたてば行き場を失ってゴミ同然の扱いになってしまっていたDTPデータも、その内容（コンテンツ）とともに、その作り方、保管の仕方に至るまで、それがいかに重要であるか、そういう認識が高まって欲しいものです。

昨日から新しい大河ドラマの龍馬伝が始まりましたが、印刷や出版に大きく影響を与えるGoogle、Amazon、Adobe、Appleなど、押し寄せてくるのは全部海外の企業やサービス。日本の今までの歴史、慣習にも当然良いところはあるのですが、この波は抑えようがないのではないかと真剣に思う年始であります。

では皆さま、今年もよろしくお願いいたします。