布団が俺を呼んでいる

丘山大一のぶろぐ

技術書典5 参加はしないですけど販売する

技術書典は、多種多様なエンジニアが集う日本唯一の場所なんじゃないですかね。
他のイベントは技術なりブランドなりの方向性がありますが、技術書典にはそれがない。


という話はおいておいて

当日参加はしませんが、「でがらし会」として(いつも通り適当に)書いたものが頒布されます。
今回、私は技術的な話ではなく、「ソフトウェア開発資産とはなんなのか」を論じています。まさかり怖い。
多分データとして(PDF)の販売です。
よろしければご購入ください。

コミックマーケット C92 参加しました

人生初のコミケでした。
疲れた。
一日目だけなのに疲れるのね。

まずはお詫び

Hololensは持っていきましたが、特に「どう使おう」とか考えてなかったので、(ブースにいらした方に使っていただこうという考えを当初持っていなかった)上手いことお見せすることができませんでした。
いらした方ごめんなさい!!
本当はもっと面白いんです!

言い訳

人が多すぎて、Hololens アプリの設置がしにくいのおおおお(+_+)
ホールが広すぎて、空間認識が上手くいかないのおおおおお(+_+)
Hololens の電池は2時間くらいしかが持たないのおおおおお(+_+)



買ってきたものや貰ってきたもの



+「一人月 Tシャツ」も買いました。
この人https://twitter.com/kowillm曰く、
「一人で一人月って数えられるとは、ホワイトな職場ですね!」
そういう考え方もあるネ!
悲しいけど、残業込みでカウントするから、一人で一人月超カウントできるのよね……。
そう考えると白字のTシャツはホワイトの証だったのかしらん。

あれ、見返してみたら、殆ど業界向けのモノだな?


想像したものと異なるコミケ

行く前までは、コミケは「祭り」の類だと思っていたのですが、どちらかといえば「市場」みたいだと思いました。
ちょっと疑問を抱くところもあり、理解できたところもあり。
なんですが、当ブログの趣旨とは外れる感じなので以下略ということで。



コミックマーケット 92 カタログ

新品価格
¥2,500から
(2017/8/13 23:41時点)

コミックマーケット C92 参加します

行くかどうかは知らない。
ここのところ更新がなかったのはだいたいこのイベントのせい。

「東た-14b」らしいです。
コミケ行ったことないから全然想像つかん。



お品書き


値段は未定ですが、
  • DEGARASHI BOOK VOL.1
  • DEGARASHI BOOK VOL.2
  • でがらし BOOK mini
になると思われます。
タイトルあってたっけ? まあ大体あってるでしょ(編集担当のいい加減さよ)
私は3冊全てに名前が出てますが、実質的なデビューは今回の「DEGARASHI BOOK VOL.2」です。
Hololens 開発の超初学者向けの内容を書きました。
なぜ初学者向けかというと私が初学者だからですw
そんな本ですが、よろしければお求めくださいませ。






コミックマーケット 92 カタログ

新品価格
¥2,498から
(2017/8/2 22:33時点)

技術書典2 に参加してきました

初の即売会参加でした。
色々と面白かった。
色々反省もありましたが、それは今後直していきます。

頒布物

冬コミで出した「でがらしBOOK Vol.1」
新刊ポエム本(笑)「でがらしBOOK mini」


当日の様子

並びすぎィ!
10時前についたのですが、その時にはすでに一般参加の方々が並んでいました。
10時前だったので、初めはサークル関係者だと本気で思っていました……。即売会こわい。
始まってからも、「入口と反対側にも列ができてるなー、何のイベントだろう?」と思っていたらまさかの技術書典2の行列……会場をぐるっと一回りするような感じで行列ができていたのですね。


頒布物と買ったもの


興味優先で買ってまいりました。
ちょっとずつ読む予定です。ひとまずUSB充電の歴史を読みましたが、すげえ勉強になりました。

いつ食べようか迷っているお煎餅。
懐かしのフロッピー、といった感じでフィギュア(?)も販売していたのですが、すいません、
本業では、

フロッピーは現役です

※個人にUSBメモリは支給されない職場です。


次がありましたら

次はもっとプログラマー向けの内容で書きたいと思います。
(次があったらですが……基本、編集なのでそっち優先)


コクヨ コピー用紙 PPC用紙 共用紙 FSC認証 64G 500枚 A4 KB-39N

新品価格
¥500から
(2017/4/10 22:32時点)

技術書典2に参加します

日時:2017/04/09 (日)
サークル:でがらし会
で参加いたします。

お品書き

  • C91で頒布した「でがらしBOOK」
  • 今回用のコピー本「でがらしBOOK mini」
の二本立てになる予定です。
ただ今ポチポチと作っております。
値段は未定ですが、
  • でがらしBOOK……300円
  • でがらしBOOK mini……100円
くらいかなあ、と思います。未定は未定。

よろしければお手に取ってくださいませ。



OSK ブラックゴールド麦茶 400g

新品価格
¥294から
(2017/3/27 23:38時点)

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

原稿の管理

原稿自体は、Github上にでがらし会のPrivateリポジトリを作成することで管理することが決まっていました。
Github で管理するのはいいのですが、ここで地味にネックになるのが、マークダウンで原稿が作成される、ということです。
※もちろん、別の形式で原稿を作っても良かったのだが、Github上ならマークダウンが便利だと判断。


マークダウンは印刷のための形式ではない

当たり前ですが、マークダウンはHTMLを簡易に書くことに重点がおかれています。
出てくるものは解釈されたHTMLであって、その解釈はブラウザやライブラリに依存します。特にTableなんかは顕著です。
また、Github上に置くだけでは連結することも、(当たり前ですが)頁番号を振ることもできません。
よって、「印刷用の何がしかの形式にするためのライブラリが必要」ですが、「成果物はそのライブラリに依存する」します。
でもって、書く人ごとに使っているライブラリ・環境は異なるわけです。
合同誌なのに、書いているのはマークダウン(=テキスト)なのに、人によって結果が異なる。ツライ。


ライブラリの選定ーGitbook

あれこれ悩みましたが、最終的にGitbookを使用することにしました。
※正確にはWindows+Git for Windows+Gitbook+calibre
決め手は、
  • PDFへの変換ができる
  • PDF化した時の結果が、マークダウン+Github(ブラウザ) で表示した結果に近い(個人ごとの差が小さいことを期待)
  • PDF化の結果が印刷に向いている(特に改ページ)
  • 現在のリポジトリの構造でそのまま動く
という点です。ブラウザによる差異は取り除けないので、ここは諦めたところです。
他にも幾つか候補がありましたが、単純な使い勝手でGitbookを上回るものがありませんでした。
しかし、この選定に時間がかかりすぎてしまいました。
ライブラリの選定に時間がかかる=出力結果が不定なまま=ページ数も未定 ということです。
そのうえ、ライブラリと格闘している間に――編集としてあるまじきことに――皆の原稿進行具合の監視が半端になっていました。
結果、当初40頁くらいの予定が、出力してみたら120頁にふくれあがるという事態にw
いくらなんでも120頁は多すぎ! ということで、皆に協力を仰ぎ、最終的に80頁にしました。
いやあ、完全に編集担当の不手際でした(汗)
みんなありがとう!


製本について
色々悩んだのですG、STARBOOKSさんにお願いしました。
ポイントは、
  • 実績がある
  • PDF受付が明示されていた
  • 一部の頁のみカラー に対応していた
  • 比較的安い
  • 会場に搬入してくれる
という点でした。
担当のお姉さんの声が可愛かったのが最大のポイントだったなんていえない。ちなみに会場にいらしていたそうですが、その人も可愛かったそうな。お会いできていないぞチクショウ。
特に、上記事情によりPDFで入稿しなければならなかったため、PDF受付ができることが確定で分かっていたのが非常に大きかったです。

また、仮入稿もできましたので、一度製作途中のものを入稿し、印刷に問題がないかどうか軽くチェックしてもらうことができました。
印刷所に依頼するのは初めてでしたので、コレができたのは安心感の意味で非常に大きいかったです。

いやはや、お世話になりました。


さて、3回にわたって長々と書きました。

正直、理想通りにはいかなかったところが多いですが、処女作&初編集にしては「そこそこ」できたかなあ、という感想です。
通してのご注意ですが、今回はあくまで「初めて」「合同誌の編集という立場で」「丘山としての考え」を書いたものです。
何かの参考になれば幸いですが、「正解」を提示したわけではありません。特に、「文章の完成度を高める」の件は、どちらかといえば小説等で有効な手法です。技術書を書くのであれば、あるいはそうでなくても、異論が出るところだと考えています。
そしてこの「異論が出る」ところがキモだと思います。
一人でやってても異論なんて出ませんからね。折角の合同誌ですから、黙々とやるよりも、意見をぶつけあってワイワイガヤガヤやりたいです。

諸々反省点もあります。数多の失敗もありますw
2回目以降の機会があれば、また違ったやり方をしたり、今回のやり方を洗練する形にでやっていきます。
しかし編集面倒くせえ編集は編集で面白いよ!



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

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

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

前回の続きです。

文章の完成度を高める

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

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

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

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

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

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

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

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


何を読むか

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

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

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

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


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

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


お金の話をなるべくする

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

次回に続く!


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

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

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

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

経緯

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

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

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


編集担当

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

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


計画

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


中間〆切の意義

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


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

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

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


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

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


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

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

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

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

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


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

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

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

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


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

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

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


次回

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




職業としての「編集者」

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

コミケ

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

詳細

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

さらなる詳細

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


で、本については?

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


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



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

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

FAManagementStudio なるものを作ってもらっています

お手軽に使える Firebird Embedded 用のGUIツールがなかったため、「欲すいよー」と言っていたら作ってくれました。

色々

FlameRobin なんか使いにくくね?
インストーラー不要で、配置するだけで使えるのがEmbedded の強みなのに、GUIツールが要インストールって不便じゃね?
と駄々を捏ねていたら開発が始まったというシロモノです。

詳細はwiki or メイン開発メンバが色々書いています。

ちなみに

動作確認や、仕様の検討、ドキュメント整備なんかはやっているのですが、ソースはほとんどいじっていません。
あと、宣伝しようしようと思っていてすっかり忘れていたのは秘密。
一応、ブログのサイドメニューにリンクを貼って置いたからこれで許してもらおうという計画。


GitHub実践入門 ~Pull Requestによる開発の変革 (WEB DB PRESS plus)

新品価格
¥2,786から
(2016/8/16 22:01時点)