give IT a try

プログラミング、リモートワーク、田舎暮らし、音楽、etc.

1人アドベントカレンダーとRuby 2.5の新機能紹介記事・第2弾を書きました

はじめに

以前もお伝えしたとおり、12月1日から25日まで、毎日「プロを目指す人のためのRuby入門」の未収録原稿を使ってアドベントカレンダーを記事を書いていました。

未収録原稿を利用するとはいえ、1人で毎日25日も毎日書けるかな?とちょっと不安でしたが、なんとか無事に書き終えることができました!
基本スタンスは「未収録原稿を使う」なのですが、日によってはほとんど新しく書き下ろした記事もあります。

というわけで、このエントリでは孤軍奮闘しながら執筆したアドベントカレンダーの記事一覧と、それとは別に書いたRuby 2.5の新機能紹介記事を紹介します。

「プロを目指す人のためのRuby入門・別館」アドベントカレンダーの記事一覧

アドベントカレンダーの記事一覧(全25本)は以下のとおりです。
「プロを目指す人のためのRuby入門」でRubyの勉強をしている方は、こちらもチェックすればさらにRuby力がアップするはずです!

  1. 変数名やブロック引数をアンダースコア1文字にするイディオム
  2. メソッドの引数をアスタリスク1文字にするイディオム
  3. 代入なしでローカル変数を宣言するトリビア
  4. 自分が書いたRubyプログラムをirb上で読み込む方法
  5. Minitestで特定のテストをスキップする方法
  6. テストメソッドの粒度について
  7. 配列を使ったキューとスタック
  8. 配列の便利メソッドあれこれ
  9. *と変数の代入の関係
  10. 範囲式を使ったフリップフロップ
  11. ハッシュの便利メソッドあれこれ
  12. 配列リテラルで最後の要素をハッシュにする場合のTips
  13. 文字列をfreezeさせるいくつかの方法
  14. 正規表現関連の便利メソッド
  15. privateメソッドとインデントのスタイル
  16. メソッド定義と同時に公開レベルを設定するトリビア
  17. privateメソッドをレシーバ付きで呼び出せるケース
  18. self.classの形でクラスメソッドを呼び出すときの注意点
  19. Structクラスで単純なクラスを手軽に定義する
  20. 特異メソッドが定義されているクラスはどこ?
  21. 正規表現チェッカープログラムのテストを自動化する
  22. Hash#to_proc と Method#to_proc
  23. Procのカリー化と部分適用
  24. 【初心者向け・動画付き】Railsチュートリアルのサンプルコードを文法解析してみる
  25. Ruby 2.5で発生する「プロを目指す人のためのRuby入門」との差異について
動画やGitHubリポジトリと連動している記事もあります

24日目の「【初心者向け・動画付き】Railsチュートリアルのサンプルコードを文法解析してみる」については解説動画や全体的なdiffを確認するためのGitHubリポジトリも用意しています。
RailsチュートリアルでRubyやRailsの勉強をしている人にとってもいい教材になっていると思うので、こちらもぜひチェックしてみてください。

Ruby 2.5の新機能紹介記事も書きました

それから、Ruby 2.5の紹介記事も以前書いた記事の続編としてPart 2を書きました。
preview-1から思った以上に新機能が追加されていて、既存の記事に追記じゃボリュームが大きくなりすぎるな、と思ったのがその理由です。

Part 1、およびPart 2のリンクはそれぞれ以下のとおりです。

たくさんの新機能があるので、Rubyプログラマの方はぜひチェックしてください!

まとめ

いやあ、我ながらいっぱい書きましたねえ。

記事を書くときは「みなさんのお役に立つように」という思いが一番にあるのですが、それ以外にも「自分の勉強にもなる」という側面もあります。
下手なことは書けないので「あれ、そういえばこれはどうなってるんだろう?」とか思って調べたりすると、自分の知らない知識が身に付いたりします。

まあ、それはさておき、「プロを目指す人のためのRuby入門」と今回紹介した記事を合わせたら、冬休みのお勉強ネタには十分なボリュームかと思います。
「しっかりRubyプログラミングを勉強したい」と思っている方は「プロを目指す人のためのRuby入門」と今回紹介した記事をセットにして学習を進めてみてください!

地元の中学校で働く楽しさと田舎の魅力とリモートワークについて講演してきました

はじめに

ちょっと前の話になりますが、さる2017年11月24日に地元の西脇市立 黒田庄中学校で中学生向けに講演をしてきました。
対象者は校内の全3年生、66名です。

このエントリではその講演の内容や講演をすることになったきっかけについて紹介します。

f:id:JunichiIto:20171221065035j:plain
こちらが黒田庄中学校です。

講演のタイトルとテーマ

講演のタイトルは「好きな場所に暮らし、好きな仕事に打ち込む働き方」で、以下のような内容をお話ししました。

  • プログラマってどんな仕事?
  • 働くのって楽しいよ
  • 都会もいいけど、西脇もいいよ
  • 西脇を出ていかなくても働けるよ

使用したスライドと講演中に見せたデモ

発表で使ったスライドはこちらです。

冒頭の「プログラマってどんな仕事?」では、僕が作った(本当は同僚のakihitofujiwaraがほとんど作った)「ニシワキロゴメーカー」というスマホで使えるWebアプリをその場で動かして紹介しました(アプリについては以下の動画を参照)。

また、その場でソースコードを編集して、アプリの動きを変えたりするデモも見せました。

最後の「西脇を出ていかなくても働けるよ」では、実際のリモートワークのイメージをつかんでもらうためにRemottyを使って日本各地にいる弊社ソニックガーデンのメンバーとリアルタイムでチャットしたり、Zoomを使って東京にいるメンバーとビデオ通話したりしてみました。

チャットやビデオ通話で遠く離れた人とリアルタイムにやりとりする様子は中学生のみなさんにとってすごく新鮮に映ったらしく、教室がかなり盛り上がりました。

f:id:JunichiIto:20171221065634j:plain
RemottyやZoomを使ったデモは大盛り上がり!(写真はイメージです)

僕から中学生のみなさんに伝えたかったこと

簡単に言えば、この講演ではこんなことを中学生のみなさんに伝えたいなーと思っていました。

  • 働くのって大変そう、つらそうって思ってない?(僕はそう思ってた)でも実際やってみると意外と面白いよ!
  • なんとなく「田舎はダメ、都会がいい」って思ってない?でも都会(大阪)からやってきた僕は西脇の方が気に入ってるよ!
  • 西脇に住もうと思っても仕事がないから結局大阪や東京に行かなきゃならない、って思ってない?でもリモートワークっていう選択肢もあるよ!

さらに最後のまとめとしてこういうお話をしています。

  • 別に僕と同じことをみんなもやれ、と言ってるわけではないよ。
  • でも「仕事はつらい」「都会の方がいい」「都会でしか働けない」としか考えていないとしたら、そうじゃない考え方やそれ以外の選択肢があることも知っておこう。
  • 好きな仕事をしながら、好きな場所に暮らす生き方を模索しよう。
  • 幸せな働き方や幸せな暮らしは、ぼーっと過ごしていてもやってこない。可能性と選択肢を増やすために、今からたくさん努力しよう。

こんな内容を40分ほど話したあと、最後に生徒のみなさんからの質問に答えて全部の講演を終えました。

f:id:JunichiIto:20171221065248j:plain
当日は視聴覚室みたいな教室でお話ししました。

「ちょっと待って、なんでそんな講演をやることになったの?」

そもそもなんで僕が中学生向けに講演をやっているのか不思議に思っている人も多いと思います。
今回の講演は僕の方から西脇市に「やりたいです!」と手を上げて、企画してもらいました。

この背景には僕が西脇市のシティプロモーション会議(いわゆる町おこし会議)に参加していたことがあります。
この会議では「西脇市の人口減少や人口流出を防ぐためには、そもそも市民が地元に愛着と誇り(シビックプライドというそうです)を持ってもらう必要がある」という話が重要な課題として挙がりました。

それであれば、これからの未来を担う中学生や高校生にこそ、地元の良さやリモートワークのような新しい働き方を伝える必要があると僕は考えました。

また、僕は大阪の出身ですし、東京にも一時期住んでいたことがあります。
なので、都会にも田舎(=西脇市)にもいいところと悪いところが両方あるよ、という話を自分の経験を交えて話すことができます。

影響を受けた他の方の講演

加えて、僕が勤めているソニックガーデンの社長である倉貫さん(@kuranuki)が宮古島の中学校で「中学生でもわかるシステム開発と新しい働き方」という講話をしてきた、という話にも影響を受けています。

kuranuki.sonicgarden.jp

あと、iOSプログラマとして有名な堤修一さん(@shu223)も学生向けに「プログラマとして食べていく」というお話をされています。

d.hatena.ne.jp

プログラマの講演というと同業者向けに話すことが大半だと思いますが、こんなふうに「大人から若者に自分の働き方を伝える」というのもすごくいいなあ、と考えていました。

こういう背景があって、僕も地元の中学生や高校生に何か将来の参考になるような話をしたいなと思い、講演の企画を自ら持ちかけたのでした。

この講演の正確な主旨

この講演はもう少し正確にいうと、西脇市が少子化対策のために取り組んでいる「3世代パパ育て事業」の中の「次世代パパ・ママ講座」という講座の一環、ということになっています。
「次世代パパ・ママ講座」は中高生を対象にした、将来の子育てや夫婦の役割分担について考えてもらうための講座です。

ちょうど僕が話そうとしていた「西脇で住んで、西脇で働いて、西脇で子育てをする」というテーマと、「次世代パパ・ママ講座」の狙いがマッチしたので、西脇市の方からもぜひ、という運びになりました。

講演後のアンケート結果

講演が終わった後に西脇市のスタッフの方がアンケートを取ってくれました。
アンケート結果を見る限り、今回の講演はすごく好評だったようです!

Q. 内容はわかりやすかったですか?

なんと、全部の回答で「はい」が選択されていました!

  • はい = 60
  • いいえ = 0
  • どちらとも言えない = 0

f:id:JunichiIto:20171221051531p:plain

Q. 考え方が変わったところがありますか?

「西脇市にもいいところがあるんだよ」「リモートワークという働き方もあるんだよ」という講演テーマがうまく伝わったようです。

  • はい = 54
  • いいえ = 3
  • どちらとも言えない = 3

f:id:JunichiIto:20171221070424p:plain

Q. 西脇で子育てするのもいいと思いましたか?

講演の中では長男の誕生がきっかけで西脇に移住することを決めたことや、田舎で子育てするメリットについてもお話ししていました。

  • はい = 50
  • いいえ = 1
  • どちらとも言えない = 9

f:id:JunichiIto:20171221070435p:plain

生徒のみなさんの感想

アンケートには生徒のみなさんがたくさん感想を書いてくれました。
その中からいくつかピックアップして載せてみます。

ここに載せた感想はごく一部ですが、「面白かった」「考え方が変わった」といった好意的なコメントがほとんどでした😊

私は「絶対に都会に出る!!」と思っていたので、今日の話はすごく心を動かされました。「ずっと西脇にいたい」とも思わないけど、他の場所から来た人からしたら西脇っていいんだなーと思いました。いつも長く感じる50分間も今日はあっという間でした。今は勉強がんばろっ!って思いました。

この講演を聞くまで、僕は京都や大阪で過ごすことを夢見ていましたが、今日で世界が180度変わったような気がします。きっといつか西脇に帰ってくると思うし、リモートワークというのもとても魅力的に感じました。今日はありがとうございました。

今までは会社で働いて、という考え方だったけど、家で働いて子どもの世話もできるようになってきているので、いい風に変わってきたので良かったです。とても楽しい講座でした。いろいろな可能性を持つために努力を積み重ねていきたいです。

とてもわかりやすかったです。僕はプログラミングはしたことはありませんが、ゲームを作ることはしたことがあります。とても参考になりました。僕も時間があればプログラミングの勉強やプログラミングをしてみたいです。今日はとても楽しかったです。

いろいろな働き方があるんだなと思いました。自分のやりたい方法で能力を伸ばすことをできるのがすごくいいなと思いました。何がしたいのか、どんな風に将来なりたいのか、もう一度しっかり考えていきたいです。都会に行かないと何もできないと思っていたけど、あらためて西脇市の魅力を知ることができました。

講演を聞く前は都会に住みたいと思っていたけど、西脇で暮らしたいなと思いました。将来子育てをするなら西脇やなと思いました。仕事と家事も両立して素敵な家庭を築きたいです。最後の質問タイムでも夫婦の仲の良さを知ることができてすごく楽しかったです(※)。最高の1時間でした。ありがとうございました。

※この講演には妻も同席していて、最後の質問タイムで「奥さんのどこが好きですか?」みたいな質問を出されて2人で夫婦漫才みたいなやりとりをしてました(笑)。

まとめ

というわけで、このエントリでは地元の中学生に向けて講演した話を紹介しました。

中学生向けの講演は今回が初めてでうまく話せるか心配でしたが、黒田庄中学校の生徒のみなさんは熱心に僕の話を聞いてくれてとても嬉しかったです。
どうもありがとうございました!

あわせて読みたい

「好きな場所に暮らし、好きな仕事に打ち込む働き方」という講演タイトルは昔僕が受けたインタビュー記事のタイトルから借用させてもらいました(了承済み)。

mydeskteam.com

西脇市のシティプロモーション活動に関する記事も書いています。

blog.jnito.com

都会と田舎の比較はこちらの記事でもあれこれ書いています。

blog.jnito.com

技術書を書きたいITエンジニア必見!?「プロを目指す人のためのRuby入門」の舞台裏をお見せします

前回のブログでも書いたとおり、僕は2017年12月6日から10日まで東京に滞在していました。
そこで出会ったRubyプログラマのみなさんからよく聞かれたのは「あの本(=プロを目指す人のためのRuby入門)って、書くのにどれくらいかかったんですか?」という質問です。

たしかに、Rubyのコードを書く人は多くても、本を書く人はあまりいないと思います。
そこで、このエントリでは執筆の様子がある程度わかるように、「プロを目指す人のためのRuby入門」(チェリー本)の執筆裏話を書いていこうと思います。

ちょっと長いので先に目次を載せておきますね。

それでは以下が本編です。

執筆&制作期間

ざっくり言うと、2016年の8月に書き始めて2017年の11月に発売されたので、執筆&制作期間は全部で1年と3ヶ月ぐらいですね。
以下でもう少し詳しく時系列を追ってみます。

おことわり

ここに載せている進め方やスケジュールはあくまで「プロを目指す人のためのRuby入門」の実績です。
書籍の内容や編集者さんによって進め方は大きく変わってくるので、すべての技術書でこのように進行するわけではありません。

2016年6月:執筆の声がかかる
  • Software Design編集部の吉岡さんから「Rubyプログラマ向けの書籍の執筆に興味はありませんか?」という話をいただく。
    • それまでにSoftware Design誌で数回記事を書いていたので、「次は書籍でも」という流れはそこまで不自然ではないかも。
    • ただし、それより前の「Software Design誌に記事を書きませんか?」という話は数年前に突然連絡が来てビックリした記憶がある(参考)。
2016年8月:とりあえず執筆開始
  • 吉岡さんと話し合って書籍のだいたいの方向性を決める。
  • 企画書のインプットとするために、僕からは目次案を出したりした。

f:id:JunichiIto:20171214194537p:plain
一番初期の目次案です。

  • 「現時点ではまだ企画は通っていないのでポシャる可能性があります」と言われていたが、見切り発車で執筆開始。
    • ポシャったらQiitaで公開すればいいや、と思って書き始めた。
2016年11月:企画が通る
  • 企画が無事に通る。
    • この時点で書籍名は「プロを目指す人のためのRuby入門」、発行時期は2017年11月になっていた。
    • このときは「1年もかかるんですか!?急いだら来年の4月ぐらいに出せるんじゃないですか?」とか言っていた。このときは・・・。
2017年2月:いったん執筆完了、しかし…
  • 結構ハイペースで執筆したので、いったん全部の原稿を書き終える。
    • ここまでは「なんだ、書籍執筆も余裕じゃん」という印象。ここまでは・・・。
  • 吉岡さんから「原稿からページ数の見積もりをしたところ、予定していたページ数を大幅にオーバーしているので100ページぐらい削減してほしい」と言われる(しまった、書きすぎた!)。
2017年3月:分量の削減
  • サンプルコードの書き方を変えたり、優先度の低い内容を削除するなどして「これぐらいなら大丈夫そう」というところまで分量を削減した。
  • ちなみに、この頃にカットした原稿を無償で公開しているのが、「プロを目指す人のためのRuby入門・別館 アドベントカレンダー」です。

2017年4月:構成上の大手術
  • ソニックガーデンの同僚に原稿を読んでもらって感想を聞いた。
  • いろんなフィードバックが上がったが、中でも影響が大きかったのは「例題が章の最後に来ると途中で眠くなるし、最初の方の内容も忘れてしまう」という感想だった(しかも1人だけじゃなく複数のメンバーから)。
  • 吉岡さんやソニックガーデンメンバーとの長い議論の末、「例題に必要な知識の説明 → 例題の解説 → 例題で使わなかった知識の説明」の順で書くことに決定。それに伴い、原稿の大幅な書き直しに着手する(ひえ~~~😭)。
2017年5月:原稿の清書完了
  • 書き直しと原稿の清書が完了。短期間で構成を変える必要があったため、かなりハードだった。。
  • 関西Ruby会議2017にて講演の最後に「11月に本が出ます!!」と発表。本の執筆を公にしたのはこれが初めて。

2017年6月~7月:DTP作業
  • この時期は編集サイドのDTP作業がメインだったので、僕の方はこれといった作業はなし。
2017年8月:1回目の校正
  • 紙とPDFで最初のゲラ(試し刷り)が届く。ここから1回目の校正がスタート。

  • 清書完了から時間があいたのと、原稿が本らしい見栄えにグレードアップされたことにより、原稿を読み直すと「ん?この説明だと、ちょっとわかりにくくない?」という箇所が多数見つかる。
  • 校正の本来の目的は誤字や脱字を修正することだが、僕の場合は推敲や書き直しも多数リクエストしたため、吉岡さんを困らせることになった。

f:id:JunichiIto:20171214190843p:plain
修正依頼はAcrobat Reader DCでPDFにメモを書き込んでいきました

2017年9月:まえがきとか、表紙デザインとか
  • 1回目の校正が終了。
  • まえがきやあとがきの原稿を書いていたのもこの時期。
  • あと、表紙デザイン案についてもこの頃に議論していた。
2017年10月上旬:2回目の校正
  • 2回目の校正を実施。この期に及んで相変わらず推敲や書き直しをリクエストして、吉岡さんを困らせる。
  • 索引に載せるキーワードを抽出していたのもこの時期。
2017年10月下旬:3回目の校正(最終)
  • 3回目の校正を実施。吉岡さんからは「もう推敲の段階ではないため、基本的に修正はなしとお考えください」と釘を刺される(苦笑)。
  • でも何点か、推敲に近い修正リクエストを投げてしまった・・・(で、結局修正してもらいました。吉岡さん、ありがとう~😂)。
  • 10月31日に校正を完了。ここからあとは一切原稿を修正できません!
2017年11月:ついに発売!!
  • 11月2日、印刷所に入稿。
  • 11月17日、見本誌が刷り上がる&都内にて先行発売開始。
  • 11月18日、僕の手元に見本誌が届く。

f:id:JunichiIto:20171119171614j:plain
1年かけてようやく形になりました(やったー)

  • 11月25日、全国の書店で正式に発売開始。電子版も同時に発売される。

・・・と、こんな感じで執筆と制作が進んでおりました。
いやあ、長い道のりでしたねえ。

執筆や制作に関するQ&A

それではここからは、プログラマのみなさんが疑問に思いそうなQ&Aを以下に載せていきます。

原稿は何を使って書いていたの?

僕はMarkdownを使って書いていました(エディタはVimです)。
また、書いた内容をリアルタイムにプレビューしたかったので、Marked 2というシェアウェアを使っていました。

f:id:JunichiIto:20171214191605p:plain
Markdownを編集して(左)、リアルタイムにプレビュー(右)

どうやって変更管理をしていたの?

Markdownで書いている間はGitとBitbucketを使って原稿の変更管理をしていました。
ただし、2017年6月以降はDTPでの編集に切り替わったため、制作期間の後半は僕の方では変更管理をしていません。

校正を繰り返しているとき(2017年8月~10月)は変更点の差分だけをdiffで見たかったりしたのですが、DTPだとそういうわけにもいかず、どこがどう変わったのか確認するのにちょっと神経を使いました。。

本文に出てくる図やイラストはどうやって作ったの?

図やイラストは僕が紙に手書きで書いて、iPhoneで写真に撮って、それを共有してDTP編集時に清書してもらいました。
僕の適当な手書きの図がちゃんとそれっぽい図になって出てきたときはちょっと感動しました。

たとえば、こんないいかげんな図が・・・、

f:id:JunichiIto:20171214093008j:plain

編集を経て、こうなるわけですね(すごーい)。

f:id:JunichiIto:20171214093020p:plain

編集者の人とはどうやってやりとりしていたの?

Bitbucketのissue(課題)を掲示板代わりに使ってやりとりしていました。

f:id:JunichiIto:20171214192014p:plain
掲示板代わりに使っていたBitbucketのissue
「1回ぐらいは顔を合わせておきましょう」ということで、2017年3月に東京でお会いしましたが、それ以外はすべてオンラインでのやりとりで完結しています。

執筆時間はどうやって捻出していたの?

僕は業務時間外で執筆していたので、執筆時間の捻出は空いた時間や土日祝日の有効活用!もうこれだけですねー。残念ながら銀の弾丸はありません(苦笑)。
あとは日々のタスクをしっかり管理して、優先順位を付けていくことでしょうか。
執筆期間中は優先度的に「ブログの執筆 < 原稿の執筆」になっていたので、この1年ぐらいは普段よりもブログの更新頻度が落ちていたかもしれません。

ただ、僕の場合はリモートワーカーなので通勤時間がないのと、子どもたちがある程度自分で時間をつぶせる年齢になっていたので、他の人よりも少し時間が作りやすかったと思います。
でも、パソコンに向かう時間は確実に多くなっていたので、妻や子どもたちにはちょっと迷惑をかけていたかもしれません(ごめんね)😣

執筆や制作にまつわる所感いろいろ

最後に、執筆や制作を通じて感じたことをあれこれ書いてみます。

紙の本の制作はコテコテのウォーターフォールだった

紙の本の制作は完全にウォーターフォールですね。

  • 企画や目次案を考えて(要件定義)
  • ページ数や販売価格を検討し(見積もり)
  • スケジュールを立てて(計画)
  • 執筆して(コーディング)
  • 校正して(検証)
  • 期日までに印刷所に入稿(納品)

・・・というように、キレイなウォーターフォールを描いております(苦笑)。

前職まではウォーターフォール型のシステム開発もやっていましたが、ソニックガーデンに入ってからはずっとアジャイル型なので、「おお、久々のウォーターフォール開発じゃん、これ!(ちょっとイヤ😫)」と思いながら執筆しておりました。

Everyday Railsのような自費出版&電子書籍では執筆途中でも本を公開(販売)して、読者のフィードバックをもらいながら書き進めていくというアジャイルな執筆スタイルを取ることもできますが(Leanpubではこれをリーンパブリッシングと呼んでいます)、紙の本ではいろいろ難しいんだろうなあ、という印象でした。

校正作業がアナログすぎて大変だった&バグゼロを達成できなかった

校正は紙のゲラ(もしくはPDF)を人間の目でチェックしていく、超アナログな作業です。
しかも、最初にもらったゲラの時点で思った以上の誤字や脱字が含まれており、「本当に全部見つけられるかな・・・」と心配になりました。

f:id:JunichiIto:20171214192745p:plain
こんなふうに思いがけないところに誤字が隠れています(エイアリスって何やねん・・・)

校正は全部で3回やりましたが、「叩けばいくらでも出てくる布団のホコリ」のように、最後の最後まで「あっ、ここにも!」と誤字脱字を発見したりしていました。

マヌケな誤字や脱字が残ったまま出版したくなかったので、目を皿のようにしてチェックしましたし、編集の吉岡さんも僕が見落とした誤字をたくさん修正してくれましたが、残念ながらバグゼロは達成できませんでした・・・。

技術評論社さんのサポートページを見てもらうとわかると思いますが、すでにいくつかの記述ミスが報告されています(涙)。

サポートページ:プロを目指す人のためのRuby入門 言語仕様からテスト駆動開発・デバッグ技法まで:|技術評論社

「経験上、これだけのページ数(472ページ)だと誤字脱字をゼロにするのは正直難しいと思います」と吉岡さんからは言われていたものの、バグゼロを達成できなかったのはソフトウェア開発者としてはちょっと悔しいです!!(いや、むしろ開発者だからこそバグゼロの難しさを理解しているはず、というべきか・・・)

索引の作成は自動的にキーワード抽出・・・ではなかった!!

技術書の巻末にはたいてい索引が付いています。
実際に自分で本を書くまでは「専用のツールかなんかで、いい感じに自動抽出してくれるんだろう」とか思っていましたが、実は違いました!!

索引の作成は著者が本文を1ページずつ確認しながら、「このページのこの用語を索引に載せてください」と1件ずつ指定していきます。
自動作成じゃなかった!ビックリ!!

f:id:JunichiIto:20171215083239j:plain
僕は今回ゲラ上の索引キーワードに蛍光マーカーで印を付けていきました

本文の執筆はブログやQiita記事の延長で書けたものの、索引の作成は初めてだったので結構戸惑いました。
(もちろん吉岡さんからアドバイスはもらっていましたが)

というわけで、どのページにあるどのキーワードを索引に載せるべきか(もしくはスルーすべきか)、という判断は全部僕が1件ずつやっています。
チェリー本を持っている方は一度索引を開いて「これ、伊藤さんが1件ずつ選んでいったのか・・・」と思いをはせてやってください(笑)。

f:id:JunichiIto:20171216054935p:plain
索引のキーワードは僕が1つずつ選びました(大変)。

プログラマ脳だといろいろ自動化できそうな気もするけど・・・

僕の所感をここまで読んだプログラマの方は「そのへんの作業って、やろうと思えば全部自動化してイテレーティブ(反復的)にやれるのでは?」と思うかもしれません。
実際、僕もそんな気がしていました。

ただ、できあがったゲラを見たり、吉岡さんの話を聞いたりしていると、DTPの編集作業は人間の目と手による職人的な微調整があちこちに入っているようでした。
また、もし仮に一部の工程を自動化できたとしても、別の工程とのつなぎこみでややこしい問題が起きたりするのでは?と思ったりしました。

このあたりは編集者や出版社の裏事情やワークフローをしっかり理解している人でないと、安易に「全部自動化すればいいじゃん」とは言えないんじゃないかなー、というのが僕の印象です。
(たとえば、商業出版用のフォントはめちゃくちゃ高価で、あっちこっちのマシンにおいそれとインストールできない、みたいな話もあって、読者が知らないいろんな事情が絡んできそう。)

もちろん、自動化できるところはどんどん自動化してほしいんですけどねえ。

2017.12.18 追記:自動化するやり方もあるそうです

実際に自動化してイテレーティブに制作する手法も(10年前ぐらいから)あるそうです。
詳しくはこちらのブログ記事をご覧ください(当ブログの引用ありがとうございました!)。

golden-lucky.hatenablog.com

編集者の人がいてくれるのはありがたい

商業出版であれば通常、出版社が編集者を付けてくれます。
もちろん「プロを目指す人のためのRuby入門」でも、吉岡さんという編集者の方が付いてくれました。

編集者がいるのは以下のような点で非常にありがたかったです。

  • 原稿ができあがったらすぐに感想をもらえる。
    • ブログであれ、本の原稿であれ、自分が書いたものに対するフィードバックは何かしらほしいので、毎回確実に反応があるというのは物を書く人間にとって非常にありがたかった。
  • 説明のしかたや文章の構成で悩んだときも相談すればアドバイスがもらえる。
    • 自分のブログだと1人で悩むしかないが、本の執筆だと「うーん、わからん!相談しよう」と「困ったときの吉岡さん頼み」が使えた(笑)。
  • 「こんな本にしたい」「こういうことをやってみたい」という提案やリクエストを気軽に投げられる。
    • ものによっては「ビジネス上の観点からちょっと難しい」と断られたケースもあったが、多くの相談事は前向きに検討してもらえた。
  • 普通のプログラマは絶対に持っていない「技術書の機能性」に関する専門知識を持っている。
    • 今回「開いたままにしやすい紙」を選んでもらったのは、その最たる例。
    • 紙面や表紙のデザインに関しても、単純な「見た目のカッコよさ」だけでなく、「技術書としての機能性を損ねていないか」といった観点で意見をもらうことができた。
  • 校正作業でも僕が気づいていないミスを多数見つけてもらった。

本の編集者は読者からすると完全に裏方ですが、著者とは最初から最後まで二人三脚で本を作ってきたので、編集者は著者にとってはなくてはならない存在だなあと思いました。

自費出版や同人誌と比べてどう?という話はなんとも言えない

最近はてなブックマークでこんな記事が話題になっていました。

まあ、比較するポイントによっては商業出版よりも自費出版や同人誌の方がメリットが大きいという点もあるかと思います。
とはいえ、観点はいろいろあって、商業出版、自費出版・同人誌ともに一長一短があるので、一概にどっちがいいとは断言できないし、本のジャンルや著者の好みによって判断が分かれるだろう、というのが僕の感想です。

まとまらない話をつらつらと書くなら、

  • たしかに1冊当たりの印税は、Everyday Rails(書籍価格16ドル、約1,600円)の方が、チェリー本(書籍価格3,218円)よりも上。
  • ただし、1冊当たりの印税が低くても、数がたくさん売れたらチェリー本の方が儲かる、ということもありうる。
  • 商業出版の方が著者に箔が付きやすい。
  • 自費出版や同人誌だと編集者が付かない(もしくはフリーの編集者を自腹で雇う?)。
  • 商業出版は印税の率が低い代わりに、大コケしてしまったり、在庫を大量に抱えてしまったりしたときのリスクは出版社が持ってくれる。
  • 商業出版だと自分の本が全国の書店に並ぶ。自分の書いた本が本屋さんに並んでいるのは単純に嬉しい。
  • 商業出版だとネットだけでなく、僕のことを全く知らない読者さんが町の書店で自分の本と出会うこともある。
  • 商業出版の方が周りの人(親戚や友人)も一緒に喜んでくれやすい。

とか、そんな感じですかねー。

いろいろ観点がある、とは言ってみたものの、一番大きいのはやはり印税面でしょうか。
大雑把にまとめるなら、

  • 自費出版や同人誌は売上げの大半が自分の懐に入る
  • 商業出版は印税は確かに少ない。しかしそれ以外のメリットが大きい

という感じです。

自費出版並みの印税率で商業出版ができたら最高なんですが、世の中そんなに甘くありません。
2つの選択肢を天秤にかけて、自分にとって「こっちが良い」と思った方を選択するしかないわけです。

まあ、僕自身、自費出版の電子書籍を1冊翻訳したのと、商業出版で紙の本を1冊出した経験だけなので、偉そうにあれこれ語るのもまだ早いかもしれませんが😅

f:id:JunichiIto:20171214193515j:plain
本屋さんに自分の本が並んでいるのは嬉しいもんです♪

まとめ

というわけで、このエントリでは「プロを目指す人のためのRuby入門」の舞台裏をいろいろと紹介してみました。
技術書を執筆する流れや大変さが、なんとなく伝わったでしょうか?
こうやって振り返ってみると、なかなかのビッグプロジェクトでしたねえ(しみじみ)。

なので、できるだけたくさんの人に読んでもらいたいし、「よかったよ!」という感想もたくさん聞きたいなーと思っています。
まだ読んでいない方はぜひ、「プロを目指す人のためのRuby入門」を書店で手に取ってみてください!
もう読まれた方も、よかったら周りにいるプログラマのみなさんにオススメしてもらえるとありがたいです。

今後とも「プロを目指す人のためのRuby入門」をよろしくお願いします😄

f:id:JunichiIto:20171125053616j:plain

「プロを目指す人のためのRuby入門」について

「プロを目指す人のためのRuby入門」は「他の言語での開発経験があり、これからRubyを始めたい人」や「Rubyプログラミングの経験はある程度あるものの、まだまだ自信がない人」に向けて、Rubyの言語仕様や開発の現場で役立つ知識を詳しく、ていねいに解説した技術書です。

詳しくはこちらのエントリをご覧ください。

Rubyのプログラミングスキルを上げたい方はぜひ、お近くの書店、もしくはAmazon等のネットショップでお買い求めください。