『仕事ではじめる機械学習 第2版』を編集しました

編集を担当した書籍『 仕事ではじめる機械学習 第2版 』が絶賛発売中。電子書籍もあります。見どころについては 著者の有賀さんがまとめていらっしゃる記事 があるので、そちらをご一読いただくのがお勧め。

最初の版を制作したのが2017年から2018年にかけてのこと。そこから既に3年が経過して、いまだに機械学習への注目は高い状態が続いている。お陰さまで本書については刊行後も読者の支持を得続けることができ増刷を重ね、さらには改訂の運びとなった次第。

本書の制作

編集担当としては、内容に関してバリバリ議論＆相互ツッコミをする著者陣を見守りつつ、周辺の環境を整備したり、印刷日程の調整をしたり、オビの惹句を考えたりしていた。

今回はトップスタジオさんご協力の下、制作の全行程をSphinxとTeXを組み合わせたツールセットで制作している。Sphinxが出力したTeXのソースから、印刷に適した形にしていただく所をトップスタジオさんにお願いし、僕はSphinx側の環境を整えて、TeXでの処理に必要なアノテーションを挿入したり、Sphinx標準の機能では出力できない文書構造を書き換えたり、TeX用の索引タグを挿入するSphinx拡張を書いていた。

単純な例ではSphinxのRoleを定義して、 texindex:`るいせきぶんぷかんすう@累積分布関数` のようなマークアップでTeX形式の索引を挿入したりした。この辺は『 Inside Sphinx 』を読むと書けるようになるはず。

これらの拡張の一部は、本書の前に編集した『 ウェブ最適化ではじめる機械学習 』の時に実装したものが元になっている。

「学び続ける」ための書籍

この2冊は他にも関連があって、両者の原稿のレビューを互いにお願いしてご覧いただいていたり、また書籍の方向性としてはずいぶん異なるのだけれど、担当編集の立場からすると同じ問題意識の下に企画/制作されている。

機械学習の技術解説書は、特定のツールやライブラリを利用して、既存のデータセットを用いて学習や予測を行うというような物が多い。『 仕事ではじめる機械学習 第2版 』にも書かれているように、こういった内容は機械学習を使ったシステム構築という全体像からすると基礎の部分ではあるものの、それだけでシステムを作るのは難しい。

本書は、この機械学習という技術を自らの物にするために、必要な知識の全体像を身につける基礎となる（つまり「仕事ではじめる」）知識を得るための書籍と考えている。機械学習という分野について「学び続けるための基礎」を得るための書籍とも言えるだろう。

一方で『 ウェブ最適化ではじめる機械学習 』の方も、ツールやライブラリがどのような動作原理の下に動いているのか、という背景を学ぶ上で役立つ知識を得られる書籍だと思っている。こちらもまた「今後も学び続けるための基礎」という意味では同じ性格を持った書籍だろう。

たとえるなら、前者は地図、後者はコンパスのような役割の書籍だと考えている。どちらも、いわゆる「機械学習」の技術のコアの部分を、なるべく手間をかけずに知るという機械学習を学ぶ定番のコースからはちょっと外れた部分のあるけれど、そこに両者の価値がある（と考えている）。

「マスターピース」を得るために

ここで話の流れが突然飛ぶのだけど『 古書修復の愉しみ 』という書籍がある。数年前に読んで僕にとってはとても得るところの大きかった1冊なのだけど、これはタイトルの通り古書修復士として訓練を積んだ筆者の回想録で、この中で著者は古書修復について学びながら、自分の仕事に必要な道具を自らの手でひとつひとつ制作する。

一通りの工程の理解と道具の制作方法を学び、職人としての技能を身につけた証として制作するのが本来の意味での「マスターピース」なのだそうだ。さらに職人としての精進はこれで終わりではなく、その後もさまざまな方法で技術を磨き続ける事になる。書籍の中では過去の職人（故人となった自分の師匠）の過去の仕事を観察して、そこから仕事の内容を類推するというエピソードが紹介されている。

僕は、ソフトウェアの分野（更には他の多くの分野における技能の習得）も、これと全く同じことではないかと思っている。基礎と原理、全体像を学び、更に自分で学び続ける方法を身に付ける。そのために資する本を作れたらいいなと思うし、今回の2冊の書籍（そしてそれ以外の書籍の多く）が、読者にとってそういうものであればいいなと考えている。

『Real World HTTP』が約三年ぶりに改訂されました

Real World HTTP 第2版――歴史とコードに学ぶインターネットとウェブ技術

2017年に渋川さんにご執筆いただいた本書を改訂しました。絶賛、発売準備中です。電子書籍は発売日にリリース予定、もちろんEPUBもPDFもあります。

改訂というのはそれなりに売れていないとできないことなので、初版を買っていただいた皆さんには感謝しかありません。ボリュームが100ページ以上増えていますが、お値段は200円アップで抑えています。お買い得ですよ奥さま。

内容についてはここに引用している「まえがき」に書かれている通り、初版の出版以降で変化した内容をアップデートして、さらに新しい章を追加しています。1つはウェブアプリケーションについて、もう1つはクラウド環境についてなのですが、いずれも「HTTPについて体系的に学ぶ」という観点で見たときに必要となる周辺知識なので、ぜひこの辺も注目してお読みいただけると嬉しいです。個人的にはクラウドの章に思い入れが強く、ウェブのコンテンツを配信するためには名前解決や各種のキャッシュやロードバランシングなど、古典的なクライアント/サーバーとは異なる複雑さをもっている訳ですが、そこで使われている技術について知ることができたのはとても勉強になりました。

歴史に学ぶ

さて、本書のサブタイトルには「歴史とコードに学ぶインターネットとウェブ技術」とあります。特に前半の「歴史」のほう、これは本書の方針でもあるのですが「HTTPとその周辺技術を、進化してきた過程と共に学ぶことで（体系的にみるとアンバランスな点を含め）、なぜそうなっているかを理解しやすくする」という意味があると理解しています。

僕のような50近いオッサンはもちろん著者の渋川さんもですが、まだ若いころにワールド・ワイド・ウェブが誕生して、その進化の過程をリアルタイムで体験してきた世代です。なので上記のような過程についてある程度の概要は知っています。そういう目線からすると、本書の記述は冗長であったり、トリビアルな内容の集積に見えるかもしれません。実際、上記に掲載した「まえがき」でも、渋川さんが書かれてらっしゃる通り「初版では『これはウェブに関するうんちく集ではないか』という感想が寄せられたり…」という事が起きています。

でも、初版、第2版と本書の編集を担当して痛感したことですが、この3年ほどでもウェブは驚くほど多くの、さまざまな点で変化しており、その細かな内容を網羅することは容易なことではありません。そのような時に、本書のような書籍がお役に立てると考えています。

脳内に「知識の地図」をつくる

情報技術に限らず何かを学ぶ際には、以下の2つの操作を繰り返し行き来する必要があります。

• 全体を俯瞰する
• 細部について理解する

例えばオムレツとはどのような食べ物か（俯瞰）、材料は何でできているのか（細部）、作り方の手順は（細部）、フライパンはどのように扱うのか（細部）という具合です。

僕らは意識的であるか否かにかかわらず、このように問題のスコープを大小させながら知識や技術を習得しています。たとえ完全に記憶していなかったとしても、全体の構造や特定のトピックについての用語や概念が存在することを知っていれば、そこから目の前の問題について推測したり、必要な情報にアクセスする手段を得られるでしょう。それは世界を探検する際に必要な地図を作るのに似ています。

ウェブの場合、対象とする領域はあまりに広く、恐らく全体をくまなく網羅した書籍を作成するとしたら、現在の数倍、あるいは数十倍のボリュームになるでしょう。本書の索引には本文中で紹介されているRFCをまとめているのですが、その数はおよそ100に達します。本書で扱っているのはRFCだけでなく、W3CやWHATWGなどの標準化団体が策定する仕様も含みます。何の予備知識もなく、それら膨大な資料の中に放り出されたとき、それらを読み込んで取捨選択し、必要な知識を一つの体系として構成するのは容易な作業ではありません。

ある種の書籍には、そのような時の道しるべとしての機能があります。膨大な情報のエッセンスを抽出し、ある原理に基づいて体系付けて整理して読者に提示します。読者は著者のたどった知識の道筋を同じようにたどって、陥りやすい勘違いや見落としがちなポイントを避けつつ、書籍として期待する知識を得られるよう意図されています。

本書がウェブ技術のすべてを網羅しているとは言いませんが、ある程度のーー少なくとも基本的な知識を得て、それを元に個々の技術について深く掘り下げられるようなーー知識を得られるものになっていると信じています。必要になった時には、RFCや参考書籍など必要な一次資料を参照できるようなポインタも、できる限り掲載しています。

本書をお読みいただいて、頭の中にウェブ技術に関する地図（インデックスと言い換えてもいいでしょう）を作成し、何かしら問題に直面した際に、解決の糸口を発見する助けとしていただければ、編集担当者としては嬉しい限りです。

そしてその際にはぜひ「これ『Real World HTTP』でみたやつだ！」とご唱和いただけるなら、この上ない喜びです。

追記：渋川さんが「フューチャー開発者ブログ」に本書の読みどころなどを解説された記事を執筆しておられます。こちらもぜひご覧ください。

キャンプの話

この記事はpyspaアドベントカレンダーへ向けて書かれています。昨日は @rokujohitoma の記事でした。

若かりし頃のキャンプ

さてキャンプです。もうこの何年も「キャンプブーム」であると言われています。一昨年にアニメ「ゆるキャン△」が放映されてからはさらに熱を帯びてソロキャンプに出かける若人も多くいるようです。良いことです。

僕も10代から20代の大学生だったころによくキャンプ旅行をしていたのですが、よくよく思い返してみると、その頃からずっとほぼソロキャンプしかした事がありません。そしてちょうど2年前くらいから、再びキャンプに行くようになりました。

20歳前後の頃、長い休みが来るたびに寝袋とテントを担いで旅行をしていました。紀伊半島、北海道、四国、能登半島…などなど。電車で現地へ行って、そこからテクテクと歩きます。短いときには4、5日間。最長で20日間くらい。時々、親切な人が「乗せていこうか」と声をかけてくれることがあり、そういう時にはありがたく車に乗せていただきます。

想像に難くないと思いますが、主に自分の脚力を使って移動し続けるのは結構大変です。北海道などでは食料や水を確保するのが大変なので、予備を合わせると30㎏くらいの荷物を持って移動していました。当時の写真を引っ張り出してきましたが、だいたいこんな感じです。足が痛くて泣きそうな気持ちになることもあります。で、日が暮れたらその辺にテントを張って野宿をします。

キタキツネに食料を盗まれそうになったり、近所のやんちゃな若者が近くでけんかを始めたり、はたまた薪を拾おうと思ったら墓地だったなど。そういう旅行なので、常に一人で行動していました。だって極限状態を迎えたらどんなに仲の良い友人同士でもケンカになるだろうことは簡単に想像できます。

そこから幾年…

ということで、20代のはじめごろまではそんな感じの旅行が自分にとってのキャンプでありました。大学を出て仕事を始めてからはなかなか長期の休みをとる余裕もなく、いつしかキャンプ道具も実家の押し入れにしまわれたまま気づけば20数年（！）が経過していたわけです。

数年前から「またキャンプ行きてえな」という気持ちが盛り上がってきました。いろいろ準備や検討をしていたのですが、3年ほど前に、家族と一緒に北海道を旅行して、かつて歩いていた辺りを車で走って、簡単なキャンプをしたのがとても楽しかったのが大きなきっかけです。当初は自転車でのキャンプを検討していたのですが、ロードバイクに大量の荷物を積んで自走するのは、自分の居住地を考えるとあまり現実的ではないという結論に至りました。

そこで行きつけの床屋のマスターでカワサキ乗りのマスヤマさんに相談したところ「格好悪いと思うかもしれないけど…タキザワさんにはカブとかいいんじゃないかな。できるならキャブレターでギアが4速のやつ」というアドバイスをいただき、その言葉の通り4速でキャブレター仕様の中古の原付カブ（リトルカブというホイールが14インチのやつ）を購入し、キャンプを再開したのです。

しまい込まれていたキャンバスのボストンバッグに荷物を詰め込んでカブのリアシートにくくりつけ、乗り切れないものはフロントキャリアやベトナムキャリアに。主には武蔵丘陵や秩父山地のあちこちにあるキャンプ場へ行って、焚火をしながら文庫本を読んで（読むふりをして）、ビールを飲んで肉を焼きます。若いころの僕が見たら苦虫をかみつぶしたような顔で眺めそうなゆるさです。

実家にしまわれていたキャンプ道具は、半分くらいが処分されていたのですが、それでもシュラフと、コッヘルなどの小物は昔のものを持ってきました。今はもっといいものがあるのはわかっているけれど、使える物だし愛着もあるので使えるものはそのまま使っています。

おっさんなので気を付けていること

気を付けていることも幾つかあります。若いころは、今思えば無謀な旅をいくつもしていました。先ほど書いた、数年前に再訪した北海道の道々には「クマ出没」の看板があちこちに立てられていました（当時はそんな制度はなかった）。自然の中に入れば野生動物とエンカウントする可能性は常にあります。実はつい先日も山中で焚火をしていたところ変な音が聞こえて、ハッとしてライトを向けると川向うに大きなイノシシがいて大変焦ったことがありました。

以下がその時に撮った写真ですが、慌てていてヘッドライトとスマホの位置がかぶって何も映っていませんｗ 我ながら焦っていたのがよくわかるので、戒めのため敢えてここに乗せておこうと思います。

また、小金を持ったおっさんになるとどうしても道具道楽になってしまいます。せっかく不自由を楽しみにいっているのに、快適さのために道具を無為に増やしてしまうのは僕の好みではありません。なので、持っていく荷物は最低限。しかも原付のカブで行くのが今のところ楽しい。ただ、安全面を考えると制限速度が低い原付ではちょっと怖さを感じることもあるので、そこはちょっと検討中です。

ということで、今後も肉体的に危険を感じるようになるまではキャンプをしていきたいと思っています。昨年ですが「ここにキャンプに行くよ」と書いたら先回りしたtokibitoが待ち伏せしていて一緒にキャンプしたことがありました。あれも楽しかったので、機会があれば他の人たちとキャンプするのも楽しいだろうなと思っています。

明日は@chezouさんの担当です。

『Go言語による並行処理』が発売されます＆それを支えるSphinxのお話

ということで発売されます。10月26日ごろに店頭に並ぶ予定です。Ebookも絶賛準備中です。

https://www.oreilly.co.jp/books/9784873118468/

今回、いまの職場で初めて紙の翻訳書を担当しました。そもそも書籍の編集を細々と再開したときに自分で決めていたことがあって、その中の1つが「翻訳書は担当しない」という事でした。

理由は主に2つあって、1つは僕のメインの仕事はあくまでデジタルコンテンツだということ。書籍には出すべきタイミングというのがあります。また特に翻訳書の場合、勝手に内容を書き換えるわけには行かないので、コンピューター関連のように日進月歩な分野で制作に時間をかけ過ぎると、内容が陳腐化してしまうことが結構あります。そうなるともう企画が不良債権のようになってしまい、会社に迷惑をかけてしまう。 紙の書籍を作る以外にもいろいろ仕事がある、フルタイムではない状態でそういうものを手掛ける自信がなかったという理由です。

もう1つは今の職場には他に編集者が何人もいて、原書の評価から手掛けているわけで、そこにフルタイムではない自分がのこのこ首を突っ込むのは良策ではないなと思っていたことです。

じゃあ、なんで今回と言えば、もともと翻訳者である山口さん（@ymotongpoo）から「『Concurrency in Go』がよさそうな本なので翻訳に関われたら」という話をもらって社内の編集者に紹介していたのですが、紆余曲折を経た末に社内で「瀧澤がやればいいんじゃね」という事になり、良い本だなという印象と、山口さんとお仕事ができるという点でもちろん異論もなく、編集を担当することとなりました。はい

本書の内容はGo言語でのプログラミングがある程度分かっている読者に向けて、Goの目玉機能の1つである並行プログラミング関連の機能を一通り紹介する、というもの。僕自身、Goについては『Real World HTTP』を編集した時に少しだけ触って、RFC番号を入力するとタイトルを取得してくれる簡単なプログラムを書きRFC番号のチェックをしたくらいだったので、読者対象としてちょうどよいくらいで、とても勉強になりました。

翻訳の山口さんが調べてくれたり、レビュアーの皆さんにご指摘をいただいたりして、たくさんの訳注を入れています。そういう意味でも大変よい書籍になったと思います。実務に携わる皆さんには4章とか5章の実装パターンの所が役に立つんじゃないかなと思います。個人的には6章の「ゴルーチンとGoランタイム」が、ランタイムがどうやって複数のゴルーチンをスケジューリングしているかについての概要を説明していて面白かったです。

さて、本書の制作ですが、訳者も僕もPythonによく触れているので、Sphinxを使って行われました。これまで担当した書籍でもSphinxで執筆をしてもらっていて、その時は僕の方でRe:VIEW形式に変換してからDTPをして編集という工程を経ていました。

これはこれで便利なのですが、いったんreSTからRe:VIEWに変換してしまうと後戻りができなかったという欠点がありました。実はこの制限はreSTをRe:VIEW形式に変換するビルダ、sphinxcontrib-reviewbuilder ができたことで大きく緩和されているのですが、画像のキャプションの扱いや文書内での参照関係など、両フォーマットのスキーマの違いによって、完全にイコールにはなりません。その部分でデグレ―ションを混入させることは工程管理上よろしくない。

また、著者さんや翻訳者さんはそれほどRe:VIEW形式に通じてるわけじゃないので、校正時にソースを直接直したくても手を出しづらかったり、手慣れたreSTでやりたいというフラストレーションがありました。今回、山口さんからも「できれば最後までreSTでやりたい」というご要望をいただき、これを機会にと一念発起して環境を整えることにしました。

『Sphinxをはじめよう』執筆者のお一人である若山さん（@r_rudi）が作ったSphinxプラグインにsphinxcontrib-indesignbuilderというInDesign向けXML形式（というかRe:VIEWのidgxml形式）を出力するビルダがあります。これはもともと若山さんが雑誌で執筆された時に作成されたもので、サポートされたタグがそのとき必要なものだけだったのですが、これに必要なVisitorメソッドを追加しました。またidgxmlでは脚注のテキストを本文中の脚注マーク位置に置くのですが、Sphinxの出力する文書構造とは異なるのでその部分だけ変更するTransformを追加しています。

これで出力したXMLをInDesignに読み込ませるわけなのですが、その時に別途lxmlを使ったフィルタプログラムを用意して、属性値を追加したり対応するスタイルを指定したりしています。この辺はRe:VIEWのメインメンテナである武藤さん（@kmuto）の電子書籍『Re:VIEW+InDesign制作技法』に書かれているものをPythonで書き直したというような内容です。

上記に比べると以下のような感じのフローになります。1工程減っただけですが、実作業としては山口さんにも元のテキストに手を入れていただくのが簡単になったため、ブランチを分けて作業をするのもやりやすくなったり、慣れないフォーマットについて調べたりすることもなくスムーズに作業していただけたと思います（山口さんに「やりやすかった」というコメントをいただきました）。

本書は電子書籍としてPDFとEPUBも制作しているのですが、僕がSphinxのEPUBビルダにそれほど精通していない事と、社内で使っているRe:VIEWを使ったビルドツールがあるので、書籍の校了後にこれまでは前段階で使用していたsphinxcontrib-reviewbuilderを使ってRe:VIEW形式にして、そこからEPUBを作成しました。つまりこんな形になります。

一見、非合理に見えると思いますが、reSTからRe:VIEWへの変換はほぼビルダにお任せなので、大した手間ではありません。また、いったんreSTで校了したテキストを変換しているので、バージョン管理も複雑なものにはなりません（reSTをメインのツリーとみなして、そこから派生するという考え方）。先ほどもお話ししたようにスキーマが違う箇所がいくつかあるので、その辺は手直ししていますけど、1日もかけてないので大したことはありません。

ただし、いくつか制約もあります。今回はGoのプログラミング書で、組版も割とシンプルなものだったのですが、数式が多用されているものだったりすると、現在僕が用意しているツールだけでは対応できそうにありません。また、Sphinxの脚注マークアップはauto-footnote形式（注のナンバリングをツールに任せる記法）にしか対応していません。これは実装の問題なので今後改善される可能性があります。

Sphinxプラグインの方は若山さんのリポジトリにマージしていただいているので、誰でも利用することができます（リポジトリを参照）。フィルタの方は、書籍ごとに細かく手を入れる必要があるのと、InDesignのスタイルに強く結びついているのでプラグインには含まれていません。上記でご紹介した武藤さんの書籍を読みながらご自分でフィルタを書いてみるのがいいと思います。とはいえ、僕が数式が多用される書籍をこのフローで作ることになったら、たぶん武藤さん（の所属されるトップスタジオさん）にお仕事としてご相談するだろうと思います（笑）。

こういうツールを使ったり手を入れたりすることが、書籍の質に直結するわけではないという意見もあります。僕自身もその意見には賛成です。ただし、書き手の側がそれを望んでいて、制作する側がそれに合わせることによって書き手の負担が大きく減らせる、もしくは効率が良くなるというのは事実です。この辺は書籍と雑誌、また出版社ごとの状況にもよるので唯一の解はないでしょう。それぞれの状況に応じて自分で考えるという、当たり前のことをするしかないかなと思っています。

偉そうなことを言っていますが、実のところ、ここに書いたことは森田さんや鹿野さんたちが10年近く前に実現されていたことを2周遅れくらいで追いかけているだけなんです。そういう前を走ってくれる人たちがいるからこそ、こうやって努力の方向性が定まるのだし、それで楽になった分をより本質的な部分の充実に振り向けられたらなというようなことを考えています。

ということで、Sphinxで商業出版したい場合にはぜひご連絡ください。皆さまの玉稿をお待ちしております。

pyspa books（概念）についてのまとめ 2017年版

これはpyspaアドベントカレンダー2017、16日目の記事です。

こんにちは。turkyです。皆さんお元気ですか？僕は風邪を引いて、金曜にあった職場の忘年会をドタキャンしました。皆さんも気をつけてくださいね！

さて、「pyspa books」と僕が呼んでいる一連の書籍群があります。「pyspaは概念」という言葉がありますが、これに従うならpyspa booksも概念と言えるでしょう。実際にそのような名前のシリーズやら書籍があるわけではありません。

pyspaに集まった人たちの中から生まれて来た書籍、その何割かは僕が関わったものなのですが、それを心の中で「pyspa books（概念）」と呼んでいます。

はじまり

ことのおこりは@ymotongpooが2012年にpyfesで行ったプレゼンが参考になります。これの19枚目に出てくる「某外資系出版社のT氏」が私です。ガラ悪そうですね。

Sphinxで翻訳してたら本が出てた話 from Yoshifumi Yamaguchi

ということで@ymotongpooに翻訳してもらったのがこちら。確かこれがpyspaがきっかけで誕生した最初の書籍になると思います。もう5年前になるんですね。

『Java開発者のための関数プログラミング』（2012/6）

続いて書き下ろしの電子書籍として執筆してもらい、PyCon JP当日にリリースしたのがこちら。正確にはsphinx-users.jpの皆さんなのですが、メンバーの過半数がpyspa参加者でもあるのでpyspa関連書籍に含めてしまっても良いでしょう。

『Sphinxをはじめよう』（2013/9）

あまり知られておりませんが、@shiumachiが監訳している書籍もあります。これは内容の検証がとても大変で、お願いして監訳してもらったもの。

『Apache sqoopクックブック』（2014/3）

この辺までは、僕自身もまだ試行錯誤しているような部分があり、書き下ろしも『Sphinxをはじめよう』1冊だけです。

pyspaらしさの表出

この辺から書籍のキャラクターにもpyspaらしさが出てきているように思います。まさにpyspaチャットでの雑談から生まれたのがこちらの書籍。

『word2vecによる自然言語処理』（2014/5）

@nishoがword2vecのお話をしてて、「なにか食わせるデータがないかな？」という話になり、「書籍を書いていただけるならデータをご提供できます」ということで形になったという経緯があります。

@shibu_jpにご執筆いただいたMithril本です。この本は世界最速で書かれた（そしておそらく世界唯一の）最速JSフレームワークの書籍となりました。

『Mithril』（2015/8）

この本を出したとき、@shibu_jpから「紙の本もあったらいいですよね」という言葉をいただき、これまで出した電子書籍をプリント・オン・デマンドにする試みを始めます。

電子から紙へ

そして今年になり、印刷された書籍として1年の執筆期間を経て登場したのがこちら。こちらについては別途エントリがありますので、そちらをご覧ください。おとうさんはえらい。

『Real World HTTP』（2017/6）

そして2013年にリリースした『Sphinxをはじめよう』を改訂、同時にPODも制作して絶賛発売中です。今回は前回よりもsphinx-uses.jp度が高まっているので、このリストに挙げるのはまあギリギリ範囲内という感じだと思っています。

『Sphinxをはじめよう 第2版』（2017/10）

さらに、技術書典2で@chezou、@tokoroten、@hagino3000が同人誌として発売した書籍が生まれ変わって登場したのがこちらです。

『仕事ではじめる機械学習』（2017/10）

ちなみにこの書籍は2018年1月に紙の書籍として再リリースされます。2度（生まれなかった1回を含めると3度）転生した書籍という、技術書としてはかなり珍しい事例だと思います。

僕が関わった以外のpyspa books（概念）

以上が僕の関わったpyspa関連書籍、pyspa books（概念）なのですが、僕が関わっていないものもあります。@golden_luckyこと鹿野さんの手になる書籍です。以下ご紹介しましょう。

こちらはpyfesの会場で原書を手にお話ししていたのを覚えています。訳者の@ransuiにはゲラを見せてもらいながら意見を求められたりもした思い出が。「明日のすーぱーはかーを育てる本」というテーマは@ransuiとは10年以上前から話し合っていて、それがこういう形で実現しているのは嬉しくもあり、ちょっと悔しい気持ちもあり、その位いい本です！

『たのしいプログラミング Pythonではじめよう』（2014/2）

こちらは@ymotongpooが訳していたWebのドキュメントが英語圏で書籍化され、翻訳も再編集されて書籍になったもの。つい先日、担当編集であった@golden_luckyにお聞きしたら、元々は『すごいHakellたのしく学ぼう』の訳者さん経由でのお話しであったということですが、入れちゃってOKということなのリストに入れちゃいます。

『すごいErlangゆかいに学ぼう!』（2014/7）

（追記）

公開直後に@golden_luckyからご指摘いただきました、@cocoatomoが翻訳するこちらもリストアップすべき1冊です（すみませんでした）。僕みたいな文系学部を出てる人間にとっては数学と聞くと「数学コワイ」と条件反射してしまいがちなのですが...いえ、もちろん購入済みですよ（積読中）。

『グッド・マス』

こちらは『Real World HTTP』の執筆と並行して進んでいたascii.jpでの連載を再編集して書籍化したものです。執筆時期が同じという意味で勝手に双子の兄弟のような書籍だと思っています。本書は技術書典3で先行発売されたのですが、たまたま出展ブースが隣だったので、開場と同時に購入しました。

『Goならわかるシステムプログラミング』（2017/10）

なぜpyspaで本をつくるのか

特に今年に入ってからのものは、製作中のレビューにもpyspaメンバーにお手伝いいただくことが増えました。皆さんジャンルの異なるスペシャリストなので、違う方向から球が飛んで来てとても勉強になります。

しかも普段から笑いながらマサカリを投げあうコミュニケーションをし合っている人達なので、馴れ合っている中でも容赦はありません（下記参照）。

はー、 @chezou さんにマサカリ投げるの楽しかった…内容が濃いだけに投げがいがあった…

— 分散深層学習er (๑•̀ㅂ•́)و✧ (@kuenishi) 2017年9月25日

ただし、投げてもらったマサカリをどうするかについては、チャットルーム外で著者さんと僕の間で相談して最終決定をしていました。この辺の線引きをきちんとしたのは良かったと思います。

僕は企画編集をメインの仕事としていないので、外へ出て著者さんを探し、書籍を作ることはあまりしていません。ですが、普段チャットルームや宴会で行われている小学生レベルの会話の合間にキラリと光る知性を見せられると「これ本にしたいなー」と思ってしまうんですよね。で、それを遠慮なく口にするというところから多くの話ははじまります。上記のリストの書き下ろしの書籍はほぼ100％このパターンです。

おわりに

ということでpyspa books（概念）の現在について簡単にまとめてみました。クレジットされていないけれど、中身をざっとみてもらったりした本は他にもあります。周辺という意味では『Python文法詳解』を含めてもいいのかと思いますが、あの書籍の成立にはまた別の物語があります。これについては気が向いたらいつか書くかもしれません（書かないかも）。

今回ご紹介したpyspa books（概念）ですが、今後もすでに発行される予定が複数あります。僕も企画していますし@golden_luckyも何かを画策されているようです。

いつ登場するかは分かりませんが、楽しみにお待ちいただけたら嬉しいです。

編集者も本を売りに行こう

お前誰よ？

このエントリは「編集とライティングにまつわるアレコレ Advent Calendar 2017」6日目の記事です。

こんにちは瀧澤です。モーリさんにお声をかけていただいて参加しました。

初めての方向けに説明しますと、とある人文系特殊版元から某IT系版元で12年弱編集に携わり、現在はこれまた別のIT系の版元で電子書籍関連の仕事などをしています。モーリさんは二つ目の会社の先輩でした。

最近の主な興味は分割型キーボードの自作です。自分でもErgodox_ezという分割型のキーボードを使っていて大変気に入っています。分割型キーボードの効能についてはこの辺に書いてあるのですが、僕も今のキーボードを使うようになってから肩こりが劇的に改善しました。

いまはこの分割型キーボードを自作するネットワーク上のコミュニティができていて、そこを覗きつつirisのPCBを注文して届くのを待っています。その間にLet's Splitにも興味が出てきて、着実に沼にはまりつつあるのを感じている日々です。

「フルスタック編集者の話」ではなく

さて、当初はフルスタック編集者について書こうと思っていたのですが、このアドベントカレンダーに登録されている方には真のフルスタック編集者（自分で出版社をやってらっしゃる）がいらっしゃるので、その辺の話は他の方にお任せして、僕は他の方の書かないようなことを書いてみようと思います。

僕は現在は編集者ではなく、主に電子書籍サイトの運営と（ファイルフォーマットの管理という意味での）コンテンツ制作、たまに実際に電子書籍を企画編集するコンテンツ制作を行なっています。2008年からやっているのでもう9年になるのですが、当初はできることがとても限られていたので、それ以外のこともいろいろやっています。その中にはユーザーコミュニティや各企業が主催するイベントに出向いて書籍の販売を行うなんていう業務も含まれています。

「あー、学会なんかで売るアレね」とお思いの方もいらっしゃるかもしれませんが、現在の勤務先はその辺ちょっと変わっていて、というか僕を今の会社に誘ってくれた元上司が常に手を抜かない人だったため、どんなイベントでも周りが引く位の書籍を持ち込んで販売を行っています。

一年のうちで一番大きな出展イベントになると、販売用に持ち込む書籍が2,000冊を超えたりします。コンピュータ関連書なので判型もそれなりに大きく（ほとんどがB5変形とA5で、半々くらい）、その他の機材やノベルティとして提供するグッズなども合わせると、2トンのトラックではちょっと積みきれないくらいの物量になります。

積載量4トンのトラックに積み込みを完了すると、だいたいこんな感じになります。

ちょうど今年のイベントの設営中の写真がありましたので貼っておくとこんな感じです。

昨年のものですが、ブースが完成するとこんな感じになります。

このクラスのイベントになると、やってくるお客さんの数も半端ではありません。別のイベントの話ですが、イベント後に決済アプリ（squareを使っています）のログを確認したら、一番混雑している時間帯で、1時間あたり60取引が記録されていました。レジ2台で回しているので、1つのレジあたり2分で1取引ということになります。

1. お客さんが商品をレジに持ってくる

2. バーコードをスキャンして代金を告げる

3. 現金をいただいてお釣りを返す、またはカード決済をする

4. 購入金額に応じてノベルティを提供するので、複数から選んでもらう

5. 商品とグッズを袋詰めしてお渡し

を2分に1回です。一日中この状態が続くわけではありませんが、結構大変です。

イベント販売の現場から

ここまでお読みになって「どこが編集と関係してるんだ」とお思いになられるかもしれません。でもちゃんと関係しています。

上記でご説明したものは極端としても、ある程度の物量をさばいていると、普段見えないことが見えてきます。というのも、そこに来たお客さんがとる行動は、多くの場合、日々普通の書店さんで起きているであろう状況にずいぶんと近づいていると思われるからです。

書籍を売るためには陳列するのですが、どういう順番で何を並べると良いのかから既に戦いは始まっています。書籍同士の関係性になるべく破綻がないように並べるところから始まるのですが、複数日のイベントでは初日ほとんど売れなかったのに、置き場所を変えると途端に動き出したりします。

イベントによってはよりお客さんの注目を引くために、その場で手書きのPOPを書いたりもします。声がけなんかもします。何を書けば、どんな言葉をかければお客さんの目に止まるのか、振り向いてもらえるのか。目の前でリアルにお客さんの反応が見られるので、途中でPOPを作り直したり、本の置き場を変えたりして、お客さんの反応どう変わるかを確かめる。そこから学べることがたくさんあります。

また、中には書籍の内容についてご質問を受けたり、内容に関する感想をいただいたりします。個人的な話ですが、プログラマの友人が結構いるので、イベントによっては書籍を買いにきた彼らと雑談をしながら、なぜその本を選んだのかを聞いたりすると、思っても見なかった書籍同士の関連性がわかったりもします。

いわゆるPDCAサイクルというやつが、イベント中にぐるぐる回ってるのがわかります。電子書籍販売サイトを運営する上で、このイベント販売の経験から学べることがたくさんありました。また、オビやサイトの惹句を考えたりするときにも、イベントで見かけた光景を想像しながら言葉を選んだりします。

電子書籍の販売を始めた当初には、「イベント会場で電子書籍を手売りする」ということもやってみました。完全に冗談からはじまった話なのですが、実際に電子書籍を買いたいという方の生の声を聞けた（そしていろいろなご不満をいただいたりもした）ので、（良い意味で）その後の方針やら決定やらに大きく影響したと思っています。

誰でも、そしてどんな版元でもこういう環境が得られるかは別としても、お客さんが平台に積んだ本を手にとって、中をパラパラと眺めて購入する、または元に戻す。という行動を観察して、それを自分の本作りに活かすということなら、割と簡単に始められると思います。そして自分が関わった本が目の前で売れていく様を見るのは大変気持ちの良い光景です。

まとめ

• お客さんに直接書籍を販売に行くといろいろ学べます

• いろいろ試行錯誤をして、ハマった瞬間は楽しい

• あまりに規模が大きくなると、それはそれでしんどい

• 分割型キーボードで肩こりが激減するよ

明日はmktredwellさんのエントリです。お楽しみに！

『Real World HTTP』という書籍を（9年ぶりに）編集しました

発売されています。EbookはPDF、EPUB完備です。

Real World HTTP - 歴史とコードに学ぶインターネットとウェブ技術

どんな本なのか？

内容は、書誌情報のページに書いてある通りですが、いまのHTTPの仕様とその周辺にある技術を、その成立過程を紐解きつつ紹介するという書籍です。

HTTPってメソッド送ってレスポンスが返ってきて、ヘッダーとボディがあって、ステータスコードが...というのは何となく知っているという人もそれなりにいらっしゃると思います（僕もその位の知識でした）。

ですが、ふと「ダウンロードの中断と再開ってどうなってるんだっけ」とか「SSLが安全ってどういうこと」とか「ブラウザでビデオ見られるやつってどうなってんの」とか考え出すと色々わからない。

そういった疑問について、おおよその概要を紹介しつつ、元の仕様や情報へのポインタがまとめられております。こんな本が読みたかった。

制作過程について

内容については渋川さんご自身が書かれたblogをご覧いただくのが良いと思います。ここでは本書の制作についてまとめます。

ご執筆はSphinxで行われました。執筆〜推敲の過程はそのままSphinx上で行い、ある程度まとまったところで、しろうさん謹製のsphinxcontrib-revierbuilderでRe:VIEW形式に変換しています。

前回、渋川さんにご執筆いただいた時はXMLBuilderでXMLを出力し、クイックハックしたXSLTでRe:VIEW形式に変換しました。以前の方法に比べると、出力した後に手を入れなければいけない箇所（主に空白の扱い）が激減しました。しろうさん素敵です。

そのあとは、Re:VIEWを元に各フォーマットを作成するというプロセスで、これはオライリー・ジャパンのサイトに寄稿していただいた武藤さんの記事が参考になります。本当は制作の工程をトップスタジオさんで行う事も考えていたのですが、オライリー側の事情で実現しなかったのは残念だったことのひとつです。

上記のような経緯で、そこから先の制作について特別なものは特にありません。一番残念だったのは、自分が10年近く書籍の制作から遠ざかっていたために、細かい部分を完全に忘れていて、もう少し機械化できる部分があったことに後から気がついてとても反省しています。最終的に力技でつじつまを合わせてしまった箇所が沢山ありました。そしてちゃんとつじつまが合っているのか今でも不安です。力技ダメ、ゼッタイ。

多様性を確保するための電子書籍

さて今回、紙の書籍で150ページ前後の電子書籍として企画されたものを、後から書籍に変更するという過程を踏みました。プロトコルのアップグレードみたいな感じです。 もちろん、電子書籍のみで出版するのと書籍にするのではかかるお金や影響が大きく異なりますので、改めて企画書を提出して社内の審査を受けています。

多くの技術書は、

執筆→書籍

執筆→雑誌連載→書籍

という過程を経て誕生します。最近では、

執筆→Webの連載→書籍

という過程もありますね。書籍1冊を書き下ろしで書くのは、書き手も出版社の側もリスクと投入コストが大きく。新しいチャレンジを行うのはとても難しい。その点、雑誌記事という場は、新しい題材へチャレンジしたり、執筆や翻訳の経験を積むためにはとても良いステージだと思います。

現在、コンピュータ関連の技術雑誌を定期発行している出版社というと技術評論社さんと日経BPさんの2社が思い浮かびますが、（僕の目から見ると）雑誌を持っている出版社さんからは、新しい書き手がどんどん登場してくる印象があります。

一方で−−僕も雑誌編集部にいたことがあるので分かるのですが−−雑誌を維持するというのはとても大変なことです。単純に企画を立て、取材をし、原稿を寄稿してもらい、誌面を制作して雑誌にまとめるというだけでも多くの労力が必要ですが、それを事業として継続するのはさらに難しい。

また、雑誌やWebの記事を書籍にまとめるという方法については、1回ごとの分量に限りがあるため、ある程度の期間連載を続けてから、内容を再構成するという過程を経ます。連載の最初の頃と最後の方では半年から年単位で期間が開いていて、対象としていたテーマそのものが変化してしまうなんてことが起きたりもします。

僕がここ数年やってきたのは、これとは別の過程で、

執筆→電子書籍→ブックレット（プリント・オン・デマンド）

という流れでした。雑誌記事よりは長く、書籍よりは短い。ある程度まとまった分量の知識を、素早く世に送り出せますし、雑誌を維持する労力よりはローコストに（≒小規模に）新しいことにチャレンジできます。今回、ここからさらに派生して、

執筆→電子書籍→書籍

という流れを作れたのは、僕としては収穫だったと思います。

最近では技術書典に出展された同人誌が商業出版に乗るというコースも登場していて、情報がまとめられて広められる方法の多様性が増しているのは良い事だと思います。

いろいろな出版の仕方ができることによって、新しいチャレンジ、これまでは世に出ることがなかった著者さんの原稿が多くの方に届けられるのではないかと思っています。電子書籍についてはいろいろなご意見がありますが、実務に携わる僕の立場からは、道具としてうまく使おうと思うだけです。

ということで、オライリー・ジャパンで電子書籍の執筆をしてみたいという方はお声がけください。締切等監視委員会はいつも皆さんを見守っております。

おとうさんはえらい

さて皆さん、ご存知の方も多いと思いますが、渋川さんは3人のお子さんを持つお父さんで、日々のお仕事に加えて子育てにも追われる日々を送っていらっしゃいます。にもかかわらず300ページを超える、しかも内容の濃い書籍をお書きになるという生産性には驚嘆させられております。しかも本書と並行してAscii.jpさんで連載しているんですよ。

お子さんたちにも何度かお会いしたことがあるのですが、これがもうとても可愛いらしいお子さんたちで、そんなご家族との時間を削って執筆していただいたことには、感謝の気持ちしかありません。

昨年の10月に、近隣に住むPythonユーザーで公園に集まってバーベキューをする機会があって、その時には「年末くらいにはまとめたいですね」というお話をしていた気がするのですが、HTTPという（いまでは）大きな仕様を相手にするにはもう少し時間が必要だったようです。

作った僕が言うのも何ですが、現在のHTTPの仕様（とその周辺）をまるっと理解して、より詳しい情報なり仕様なりにアクセスするための道しるべとしてよい本になったと思います。僕自身も勉強になりました。HTTPを使ってユーザー以上の何かをするという人は目を通しておいて損はないと思っています。