布団が俺を呼んでいる

丘山大一のぶろぐ

続・初めてコミケ用同人誌を作った話

前回の続きです。

文章の完成度を高める

完成度を高める=推敲の作業です。
いくつかのアプローチがあります。

その1:著者による推敲
最も基本的なものです。
最初から最後まで通して行われます。

その2:著者同士による推敲
余裕ができれば、著者同士による推敲も行います。
ただし著者同士の推敲は(お互いに遠慮するのもあって)さほど大きな変更をもたらしません。

その3:編集によるチェック
「一冊の本」としてまとめる都合上、用語を統一したり、権利上問題がある表現や素材を使用していないか確認します。
編集は文章それ自体よりも、枝葉を気にしたものをチェックします。

その4:読者によるチェック
最重要。
「そこそこ完成した文章」を「読んで」「見て」もらいます。
ここでいう「そこそこ完成した文章」とは、内容が最初から最後まで完結しているものを指します。
書きかけが無い、状態ということです(加筆する分にはよい)。
不思議なものなのですが、どんなにヒドイものでも、ヒドイ状態からちょっとずつ成長している姿を見ていると、最終的にボロボロであっても「最初に比べればだいぶよくなったよね」という結論に至りやすいです。
スパゲティコードをリファクタリングしていると、途中で多少クソコードが残ってしまっても「最初に比べればよくなったよね」という結論になりがちなのを想像していただければと思います。次にそのソースを見る人にとっては、やはりクソはクソなんですけどね。

あとは、読者に「同じ印刷物」を渡して読んでもらうことです。
(重要なのは「同じものを見てもらう」ことです。ちなみに、この方針はでがらし会では非常に強い反発を受けました。)
同じものを渡す理由は、同じものを見たときの感想、指摘事項を集めるためです。
違うものを渡しても違う感想が出てきてしまうのは当たり前なので、意味がないからです。
違うものを読んでいる場合は、(編集の中では)意図して「別物を読んだ」感想として取り扱うようにします。

また、一定周期で印刷しできる限り参加してもらい、なるべく複数回チェックしてもらうように……するつもりでしたが、スケジュール上無理でした。orz
編集の大敗北。

読者によるチェックでは、誤字・脱字等の枝葉より、「面白かった」「つまらない」「色がない」「読みづらい」「読みやすい」「ここの意味が分からない」「興味ない」等の感想が欲しいところです。また、できれば赤ペンなどで紙に書き込んでもらいましょう。
さらに期待されるのは、赤ペンによる読者同士の論争があればなおよしです。
論争がある=色々な読み方がある、色々な意見がある ということだからです。
そして、読者同士の論争をもたらすということは、それは
人に考えさせるよい文章か、
結論を出せていないダメな文章か、
どちらかになっている可能性があります。
それが著者に伝わればベストです。


何を読むか

著者、編集は書きかけのテキストでもなんでもOKです。
ただし、読者側が、そういった中間成果物を読むのはなるべく避けます。
最終的に、紙媒体としての同人誌になるならば、同サイズの紙に印刷したものを読みます。
最終的に、PDFとして出力するならば、PDFで読みます。

大切なのは、「最後にどうやって公開するか」に則ったものを読むことです。
時折、「最後は紙だけど、推敲中は画面で見るからいい」という人もいますが、それは大いなる間違いです。
開発現場の世界に例えるなら、受け入れテストするのに、デバッグで使っていたexeでテストしているようなものだからです。
同じものは作れなくても、「最終成果物と極力近いもの」をでテストすることが重要です。

Q:そうはいっても、画面に出ているものを印刷するのだから同じでは?
A:ぶっぶー

画面で出ているものと紙とでは、大きく異なります。
  • 文字サイズが、画面では拡大できるが紙ではできない = 読みやすさが異なる
  • 画数の多い文字が、印刷したらつぶれてしまって読めない = 印刷の精度の問題
  • 紙では常に見開きだが、画面ではそうとは限らない = 一度に目に入る情報量が違う
  • 紙では片面に画像、もう片面に文字という構成がとれるが、画面ではそうとは限らない = 一度に目に入る情報量が違う
  • 片面に画像、もう片面に文字となるはずが、印刷したら頁の都合上、めくった次の頁に分割されてしまった = 構成の問題
主にこれらが問題となります。
逆に、最終的に電子化するならば、なるだけ画面で見るべきです。


修正の要否の最終判断は「作家に任せる」

商業ではないので、編集の権限はそこまで強くありません。
ここまで、推敲の話をしてきましたが、修正するかどうかは各著者にお任せします。


お金の話をなるべくする

ここらでちょっと毛色の違った話をば。
何をやるにしてもそうなのですが、合同で実施する場合、お金は確実に揉めます。
同人誌についても、「利益を出すのが目標」「トントンになればいいや」「同人誌は赤字で当たり前」は人によって意見が分かれます。
同人誌で利益が出ると色々面倒なのですが、それでも「売る、ということは利益を出すこと」と考える人もいるわけです。
この辺りの意見は、各人バラバラでもいいのですが、「合同でやる時の方針」は早めに固めておく必要があります。
よって、折を見て費用、利益、各人の負担額を提示し、意思の統一を図っておきます。

次回に続く!


伊勢藤 同人誌ケース ブラック

新品価格
¥700から
(2017/1/14 21:16時点)

Windows Phone (Windows Mobile) Windows Update 後の再起動ににかかる時間(10.0.14393.693)

Updateのことを完全に忘れていたので同人誌の話はまた今度。

今回はこんな感じ

アップデートファイルのダウンロードや更新自体は済。再起動にかかる時間だけです。
合計15分で更新が完了しました(歯車云々の時間は省略)。
またいつもの時間です。
コレ、いつも15分で終わるように設計されているわけじゃない……ですよね?

状況によって時間は大きく前後すると予想されますので、目安の一つとして。


バージョン

端末はNuAns Neoです。
本日時点の各バージョンは、
バージョン:1607
OSビルド:10.0.14393.693
ファームウェアリビジョン番号:1028.020.001.92
ハードウェアリビジョン番号:1.0
無線ハードウェアバージョン:1.0
チップSOCバージョン:8952

更新情報

一応掲載。

最近、Windows Mobile の動きがないけど大丈夫かしら。


20170113 追記

いきなり再起動がかかりました。
調べてませんが、なんだったろう?
バージョンなんかは変わってないみたいです。

初めてコミケ用同人誌を作った話

昨年のC91用に、「でがらし会」として作成しました。
今回は編集としてのお話や考えを書いていきます。

経緯

「でがらし会」の代表が「技術書の同人誌作りたい」と突然言い始めたことが発端です。
私は文章を(好き勝手に)書くのが好きです。大学時代もちょいちょい仲間と冊子を作っていました。
なので、話を聞いたときも、いいんじゃないかな、と(書き手として)思っていました。
しかし技術書って書いたことないなー、何を書けばいいんだろうなー、とボンヤリ考えていた時、でがらし会代表である凡人のお言葉がありました。

代表:「編集をやって」
私:「え、やだ」

それ絶対面倒やんけ、と思い速攻で断った記憶がありますが、他に立候補者がでなかったので編集とあいなりました。


編集担当

さて、編集の最初の仕事は、「そもそも編集って何やるのさ」という自己定義です。
私の経験の中では、合同で本を作る際は
  • 代表者(発起人。この人の名前で出す。最終決定権保持者)
  • 会計(お金をとりしきる)
  • 編集長(本の設計、監督)
  • 編集担当(ページ調整や挿絵管理)
  • 印刷担当(印刷管理、コピーを大量にとる場合は力仕事もあり)
  • 読者(本の作成には直接参加しないが、文章を読んで意見を言う人)
等の役割・仕事があります。
ホンマモンの出版社ではないので、実際にはこれらを兼任しながら進めますが、注意点として、原稿を書く人は原稿を書くことのみに注力し、上記の役割・仕事には原稿が完成するまではなるべく関わらない/関わらせないようにします。
理由は幾つかありますが、重要なのは「作業を手伝っていたら原稿が完成しなかった」という事態を避けるためです。
わりとシャレにならないので。

ちょっと話はズレましたが、今回は「会計」「編集長」「編集担当」「印刷担当」を受け持とう、と決めました。
残った代表者は「凡人」。
読者は、「同人誌作成に直接参加していない勉強会のメンバ」を半強制的に巻き込むことにしました。
ただし、会計、つまりお金は揉め事の原因となります。特に一人でコレをやってしまうと透明性に欠け、後々に禍根を残しかねません。
よって、費用としてあつかうものについては、代表を確実に通すことにしました(権限の一部を放棄)。
どちらかといえば、
  • 「決定権が強い代表が暴走するのを防ぐために、お金についての決定権は会計が持つ」
  • 「会計は主と副の両方を置く。二人置いて監視できるようにする」
  • 「主は通帳を持ち、副が判子を持つ。コレにより、多額のお金の使い込みを防ぐ」
方が組織としてはよいのですが、今回はコレの逆をした、ということになります。
口座も作ってなかったしw


計画

まず大ざっぱなスケジュールを組みました。
  • 11月上旬:原稿中間〆切。方向性を固める。
  • 12月上旬:原稿〆切
  • 12月中旬:(そこそこ安く仕上げるための)印刷所〆切
  • 12月29日:C91当日
12月の予定は、C91及び印刷所の〆切からおおよそ逆算で決められます。
極端な話、スケジュールといっても、実は12月中の予定さえ組めればあとはどうにでもなります。
が、それは「印刷担当」の話。
「編集長」が決めなければならないのは、実は中間〆切だと私は考えています。


中間〆切の意義

関係者が少なく、またその組織内での本づくりのノウハウが溜まっている場合はいいのですが、今回のように関係者が多く、ノウハウが無い、しかも文章を書くのに慣れていない人が多い場合は、原稿の中間〆切をやや早めに設定しておく必要があります。


理由1:原稿未完成を防ぐ

原稿を完成させる。これには想像以上の労力と時間がいります。
が、これが大抵の場合、驚くほど小さく見積もられます。普段「こんなスケジュールと工数見積もりで上手くいくわけないだろ、PMはバカか」というような人でも、なぜか自分の書く原稿は「いけるいける」と勘違いします(経験者談)。

小説でも解説でもそうなのですが、大抵の場合は
  • 書く内容を決める
  • 全体の構成を決める
  • 書いていく
の順番に進みます。


……………………
………………
…………

すいません、ウソつきました。
こんな風には進みません。


大抵の場合は
  • 書く内容を決める
  • 全体の構成を決める
  • 完成系を妄想する
  • 妄想で満足して書かない
の順番に進み、見事に停滞します。
厄介なのが、「全体の構成を決める」というところ。
コレができてしまうと「後は埋めるだけや!」という気分になります(経験者談)。
実際にはその「埋める」作業が一番つらいはずなのですが。なぜだ。

そんなこんなで、企画開始直後に一気に構成まで練り上げた後、〆切一週間前になるまで停滞することが多いです。
そして〆切一週間前に書き始めた後、

「なんか書きたかった内容と違う風になっているな?」
「ん? 軽く読み直してみたら、構成に矛盾があるぞ?」
「あれ、3時間使って書いたのに全然進んでない……」

となります(経験者談)。
場合によっては原稿を書くが億劫になってきて、「気分転換にゲーム」、「旅に出ます」とか言い出す人もいます。
それでも大抵は書き上げてくれるのですが、まれにそのまま原稿を落とす人がいます。

かくして、慌てて書かれ、中間〆切直前に提出された原稿は、妙に浮ついた、誤字脱字が多いものとなります。
これを補正する時間が、中間〆切~最終〆切の期間です。


理由2:本の方向性を早めに見極める

これは作者側ではなく、編集側の問題です。
今回の本は、わりと自由なテーマであり、どのような原稿が出てくるか予想がつきませんでした。
また、どのくらいの頁数になるかも分かりませんでした(※次回以降後述しますが、今回、ここで失敗しました)。

そもそも外部に出せないような内容を提出する人もいるかもしれませんし、
頁数が予定よりも少ない場合は、コピー本の方がよいかもしれません。
頁数が多い場合は分冊、あるいは話し合いや投票によって載せる原稿を早めに決めたいところです。

どの問題であっても、編集のノウハウと、ある程度の共通認識が編集-作家間でできあがっていればクリアできます。
が、両方ともなかったのでチキンな〆切としました。


理由3:読者の意見を原稿に反映させるための時間を作る

これは完成度に関する話です。
アプリケーションのバグは、テスターが多ければ多いほど潰せます。
また、改善提案もテスターが多いほど集められます。
本も一緒で、読者が多ければ多いほど誤字、脱字、誤りが見つかりますし、
感想、意見も集められます。

とはいっても、読者側の都合もあるので、読んでもらえるよう長めの時間をとります。
※できれば1度、全員集めて読み合わせをしたかったところですが、今回は叶いませんでした。


次回

今回はここまで。
ちょっと記事が長くなってしまったので、分割します。
次回もできるだけ早くあげたいと思います。




職業としての「編集者」

新品価格
¥1,944から
(2017/1/11 00:43時点)

昨年の反省、今年の目標

新年始まって10日ほど経ってますけど気にしない気にしない。
遅ればせながら、あけましておめでとうございます。

昨年の反省

  • やっべえCCさくらの放映日間違えてたw 来年じゃんw
  • 前半はともかく、後半はあきらかに学習が失速していた。
  • 本をあまり読めていない。

今年の目標

  • Hololens がくる予定なので、それで遊ぶ。
  • いい加減3Dモデリングを勉強する。
  • 軽い運動(世間的には軽いが、本人にはキツイ)は週一を維持。
  • もう一本くらい、練習がてらUWPアプリを作る。
  • 読書量を増やす。月3冊くらいは読みたい。

※読書履歴には、ラノベや雑誌は含めていないので、それらを含めればもうちょっと増えることは増えます。

実にいい加減な一年になりそうですw


死ぬまでに行きたい! 世界の絶景 2017年 カレンダー 壁掛け CL-413

新品価格
¥1,215から
(2017/1/9 12:53時点)

コミケ

この頃更新が滞りがちだった原因がコイツです。
祭りって怖い。

詳細

サークル「でがらし会」としてC91に参加予定。
これに出すなんちゃて技術書を作りました。
スペースは「木曜日 西地区 "み" ブロック 23a」らしい。
……らしい、というのは、私は編集として参加していますが、当日行かないためですw
CM、CM。

さらなる詳細

でがらし会HPはこちら。
技術書作りは、私は編集担当として参加しています。裏方ですね。
そのため、ちょろっとしか文章を書いていません。


で、本については?

C#を中心に、ラズパイ、Xamarin、Firebird、設計論です。
概ね80頁、300円の予定。
よろしければお手に取ってくださいませ。


色々苦労したけど、そのあたりの話はコミケが終わってからまた書きます!



四日市 萬古焼き 急須 e408 紫泥

新品価格
¥1,890から
(2016/12/27 22:20時点)

Delphi でインターフェース変数が、他のインターフェースを実装しているかを調べる

Delphi で、「インターフェースで受け取った変数が、他のインターフェースを実装しているか」
をどのように調べるのかが分からなくて苦戦したのでメモ。

調べる前 「isでいけるいける」
コードを書いた後 「isだとコンパイル通らないやん……」

というわけで、正解はこんな感じ。


ソースは、ブラック企業から社員を取得し、その人物がプログラマーならなら残業させるというもの。

procedure hoge;
var
  IShain : ISalaryman;
  IShachiku :IProgramer;
begin
  IShain := BlackCompany.Shain;
  if Supports(IShain, IProgramer, IShachiku) then
    IShachiku.Zangyou;
end;

BlackCompany.Shainから返された値を、ISalaryman インターフェースで宣言されたIShainで受けとります。
このIShain変数の実体が、IProgramer インターフェースを実装しているかどうか調べるのがSupports メソッドです。
実装していないならFalse、実装されているならTrue が返り、第三引数(サンプルではIShachiku)にIProgramer にキャストされたものが入ってきます。
これでIShachiku 変数には、IProgramer 型が入ってきます。
後は残業させればよいヨロシ。

詳細は

下記の本に書いてあります(宣伝)



果実酒収穫

以前漬けていたものを収穫しました。

ドン!



コレを手元にある中で、一番高い酒のビンに入れれば、



おお、色もそれっぽい!
コレ騙せるんじゃね?

今年もソコソコいい出来かな。満足満足。


サントリー 果実の酒用ブランデー 紙パック 1800ml

新品価格
¥1,625から
(2016/12/18 20:34時点)

Windows Phone (Windows Mobile) Windows Update 後の再起動ににかかる時間(10.0.14393.448)

いぇあ!

今回はこんな感じ

アップデートファイルのダウンロ��ドや更新自体は完了しているので、再起動にかかる時間だけです。
合計15分で更新が完了しました(歯車云々の時間は省略)。
またいつもの時間にもどったようで。

状況によって時間は大きく前後すると予想されますので、目安の一つとして。


バージョン

端末はNuAns Neoです。
本日時点の各バージョンは、
バージョン:1607
OSビルド:10.0.14393.576
ファームウェアリビジョン番号:1028.020.001.92
ハードウェアリビジョン番号:1.0
無線ハードウェアバージョン:1.0
チップSOCバージョン:8952

更新情報

日本語版の更新はいつものようにちょっと遅れている模様。
英語版の方は出てる。

情報が出ているのはいいんですけど、Mobileについての表記が無くて不安になる。
「Windowsで共通なんだよ!」といえばそれまでですが……。



12月2日といえば

すでに過ぎてしまった12月2日ですが、以前から発表されていた、皆さん待望のものが出ましたね。
そう、


カードキャプターさくら クリアカード編(1) 特装版 (講談社キャラクターズA)

新品価格
¥2,462から
(2016/12/4 20:51時点)


CCさくらクリアカード編!



なかよし本誌でも追いかけていますが、まあそれはそれとして買わないとね!
なお、上にはアマゾンのリンクを張っていますが、私は本屋でフツーに買いました。
レジがおねーさんでも、特装版の少女漫画くらい余裕で持っていくのが私のスタイルです。


というわけで、みなさん、

「封印解除(レリーズ)!」







……ん?



……なんか忘れているような……??






ああ、思い出しました。
12月2日から、Hololens の日本予約販売も開始されました。

お値段は概ね30万強です。


エンジニア的にはこちらも重要でしたね。
ごくごく一般的なエンジニアにとって、

「さくらちゃん >>>>>>> 超えられない壁 >>>>>>>>>Hololens」


だと思いますが、さくらちゃんのついでに宣伝しておきましょう。
誰かさくらちゃんがMRで動くアプリを出してください
直前に円安に移行していたので、どうなるか不安でしたが、影響は受けていない模様。


1月からさくらちゃんが再びTV放送されるらしいですし(テレビ持ってないけど)、Hololens もくる。

来年は初頭からワクワクですね!!





カードキャプターさくら クリアカード編(1) (KCデラックス なかよし)

新品価格
¥463から
(2016/12/4 21:11時点)

UWP Project が作成できない

UWPは、なんでこうもエラーが多いのだ(泣)
以下失敗談。対応方法だけ知りたい方は最後らへんだけどうぞ。

エラー内容

久々にUWPでアプリを組もうとしたところ、下記のエラーが発生。


調べると、どうやらSDKのインストールにコケている場合に出るらしい。

対応

SDKを拾ってきてスタンドアロンインストール
と思ったんですが。


先生、なんかエラーが出ます!

試しにVS2015のインストーラーからWIndows Software Developer Kit を入れなおしてみる。
玉砕。

う~ん、分からん。
と思ってコンパネを覗いてみたらなんかいる。


あれ? 14393を入れようとしているのに、なんで26624がいるんだ?
試しにアンインストールしてみる。
それでから、再度スタンドアロンインストール実行。

しかし無情なるエラー。
折れそうになる心。

でも、コンパネを見直すと14393が入っている。
ものは試しと「変更」→「Repair」を試してみる。
Visual Studio 起動……なんか使う予定がないPythonでエラーが出たぞ(汗)
VS2015のインストーラーをもう一回叩いて入れなおす。
Visual Studio 再起動……。う~ん、Python はエラーでなくなったけどUWPはまだダメ。

ちょっとここで仕切り直し。
コンパネから14393をアンインストール。OS再起動。
そしてスタンドアロンインストール実行……おおインストーラーが動いた!
これはいけた!……と思いきや、プロジェクト作成は失敗する。

再び折れそうになる心。

最終的に

こちらを参考にさせていただきました。
超感謝。
projectのテンプレートの一部をコメントアウトすることで対応。
私の場合、パスは下記。
C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\ProjectTemplates\CSharp\Windows Root\Windows UAP\1041\BlankApplication\BlankApplication.vstemplate

結果

・WIndows Software Developer Kit 10.0.26624 が妨害していたことはしていたと思う
・同じようにプロジェクトが作成できない方がいるということは、何か条件があるはず……ぐぬぬ。


かずきのUWP入門