1. GitHubで
雑誌・書籍を作る
稲尾尚徳
WEB+DB PRESS編集部（技術評論社）
2014/06/01 GitHub Kaigi

2. どんな雑誌・書籍を
作っているか

3. WEB+DB PRESS
• 初公開！ 6月24日発売
• 明日入稿だけどたぶん
この表紙で確定
• @naoyaさんのGitHubの記事
もあります

4. WEB+DB PRESS plus
• 現在40冊
• @hirocasterさんのGitHubの本もあります

5. どんな人と
作っているか

6. 執筆陣は一流のエンジニア
@naoyaさん ：雑誌、書籍（ 3冊！）、ムック
@hirocasterさん：雑誌、書籍、ムック
@amatsudaさん ：雑誌、ムック
@miyagawaさん ：雑誌（ Vol.2から！）、ムック
@kenchanさん ：雑誌、ムック
@yandodさん ：雑誌、書籍（ 2冊！）
!
※本日の登壇者・運営チームより（登場順。漏れがあったらすみません）
※会場にはもっとたくさん！

7. どのように
作っているか

8. 使っているツール
• GitHubで原稿管理とやりとり
• md2inaoで原稿テキストの変換
• Adobe InDesignで紙面レイアウト

9. md2inaoとは何か
• Markdownで書かれたテキストを、
WEB+DB PRESS/WEB+DB PRESS plus用の
InDesignテキストに変換するツール
• ソースコードの文字数チェック機能なども備えて
いる

10. md2inaoの
簡単な歴史
詳細はこちら
https://gist.github.com/inao/baea09bc6fc53551886b

11. md2inao以前（∼2010年）
プログラミング雑誌の原稿中でもぜったいに登場しない
全角を駆使した編集記号での執筆をお願いしていた。
• ■大見出し
• ◆b/◆太字◆/b◆
• ◆i/◆イタリック◆/i◆
• ◆ルビ/◆技評◆ぎひょう◆/ルビ◆
この編集記号からInDesignテキストに変換するプログラム
を、別途編集部で持っていた。
https://github.com/inao/idtagreplacer

12. markdown2inao.plの誕生
（2010年）
「そんなわけのわからない記法で書けるか！」
ってことで、@typesterさんが自身の執筆用に
Markdownから編集記号に変換するスクリプトを
作り、Gistでも公開してくださった。

13. markdown2inao.plの成長
（2010∼2012年）
その後、@hsbtさん、@hokacchaさん、
@suzukiさん、@syohexさんといった方が、
Gist上で少しずつ、そして時には大きく改善してく
ださった。

14. markdown2inao.plから
md2inaoへ（2013年）
昨年春、@naoyaさんが連載スタートを機に
GistからGitHubに移行し、名前もmd2inaoにあら
ため、マニュアル、テスト、Travis CI、Web版な
どもそろえてくださった。
md2inao.plができるまで - Togetterまとめ
http://togetter.com/li/465621

15. もはやinaoではない
現在のmd2inaoは、InDesignテキストに変換する
機能も備えたため、編集もMarkdownで行い、
MarkdownからInDesignテキストに直接変換して
います。
ですので実態としては、もはやmd2inaoではなく
md2indesignです。

16. md2inaoの近況
2013年春の@naoyaさんの怒涛の更新ラッシュが
去ったあと、しばらく沈黙が続いていましたが、
ここ最近、@gfxさんの特集の執筆を機に、@gfx
さんによるCPAN化、@naoyaさんによるHeroku
への自動デプロイ機能など、再び進化しました。

17. md2inaoの今後、あるいは
おんぶにだっこな開発の未来
@gfxさんの記事も明日印刷所に入稿しちゃうの
で、再びの沈黙も予想されています。
なお、現在Issueは14個ほど挙がっています。
https://github.com/naoya/md2inao/issues?state=open

18. InDesignテキストとは
何か

19. 正確には
InDesignタグ付きテキスト
• 文字周りのスタイルをひと通り設定できる
• 画像周りは取り扱えない
• Re:VIEWなどが対応しているInDesignのXML
だと、画像なども扱える
• ただXML版でも、2段組のWEB+DB PRESS
のレイアウトまでを行うのは難しそうとのこと

20. md2inaoで変換したこんな感じの
テキストをInDesignに取り込むと
<ParaStyle:大見出し>GitHub
<ParaStyle:本文> GitHubはもはやお馴染みですね。GitHub
はGitのリモートリポジトリとして利用できるWebサービスで、
ほかのユーザに向けてソースコードを共有・公開できます。ほ
かの開発者とのコミュニケーションにもよく利用されることか
ら、「プログラマのためのソーシャルネットワーク」と呼ばれ
ることもあります（<CharStyle:太字>図1<CharStyle:>）。
── 伊藤直也著「Emerging Web Technology研究室」第8回「GitHubを使った
Pull Requestベース開発プロセス」『WEB+DB PRESS Vol.81』、技術評論社、
2014年、p.144

21. こんな簡易PDFができます
※前述した@naoyaさんの
原稿をサンプル用に切り
貼りしたため、文章はつ
ながっていません

22. GitHubをどのように
使っているのか
詳細はこちら
http://d.hatena.ne.jp/naoya/20140127/1390815492

23. ブランチモデル
• 作業者が、WIP（Work In Progress）な
Pull Requestを送る
• 執筆時は、著者さんがWIP Pull Requestを出す
• 編集時は、編集者がWIP Pull Requestを出す
• これを繰り返していくことで完成させる
• 複数人での執筆、複数章に分かれた執筆、同時進
行の作業などの場合は、Pull Requestからさらな
るPull Requestを派生させることもある

24. たとえばこんなPull Request

25. コミット
• コミット数は、特集でだいたい500くらい
• 基本的な校正時には見出し単位でコミット
• <見出し名>を校正した
• 意図を伝えたい変更は、ピンポイントでコミット
• ○○と重複しているので削除した
• 話題が変わったので段落分けを行った
• SourceTreeだと、hunkより細かい行単位で選択
したコミットがやりやすい
• revertする／される可能性がある変更も、その変更のみ
でコミット

26. フィードバック方法
• Pull Requestの確認時に気がついたものは、
GitHub上でコメント
• テキスト上での校正時に気がついたものは、
テキスト中に直接書き込み
• ★○○などの★ライブラリがあります。
• ★なぜ、☓☓なのかがちょっとわかりませんで
した★
• これらのコメントは簡易PDFでは赤字になる

27. これくらいの活用状況

28. プライベートリポジトリなので
みなさんから見るとこんな感じ

29. GitHubで何が変わったか
• 進 状況が見える化された
• 従来はアウトライン、草稿、完成原稿の3回くらい
• Issue/Pull Requestによりメールを使わなくなった
• 特集だと100を超えるメールをやりとりしていた
• コミットメッセージで変更意図を伝えやすくなった
• メールあるいは原稿テキスト中に書く必要があっ
たので、従来は大きなものしか伝えなかった
• 思い切った変更の提案が行いやすくなった
• Pull Requestの破棄やrevertがあるので

30. どれくらいGit/GitHub
を使いこなしているか

31. ごく基本的なことしか
できません
• そのときどきで、著者さんに教えていただきなが
ら習得していっています
• 著者さんの寛容さに助けられています
• 使い方が適当でも許してくださる
• 使い方がわからないときは教えてくださる

32. Git/GitHubの習得
• Gitの学習（2009年）
• GitメンテナのJunio C Hamanoさんに
「はじめてのGit」を書いていただいて
（「開発ツール徹底攻略」にアップデート版を収録）
• Gitの実戦投入（2009年）
• @tyanoさん、@yoshioriさんの特集原稿で
• GitHubの実戦投入（2013年）
• @amatsudaさん、@idesakuさんの特集原稿、
@naoyaさんの連載原稿で
• Joined on Nov 19, 2008でした

33. プライベートリポジトリをforkしてPull Request
がきたけど、fork先のプライベートリポジトリ
にはアクセス権がないのでcheckoutできない

34. 急にmasterが
pullできなくなった

35. まとめとして
背景にある経験・考え

36. 雑誌・書籍作りは、ソフトウェア
開発に近づけたほうがうまくいく
• 著者さんの普段のワークフローに近いから？
• 雑誌や書籍もソフトウェアだから？

37. おんぶにだっこされながらも
できるだけ取り入れたい
• GitHubによる常時共有、バージョン／課題管理
• Markdownという書き慣れた記法による執筆
• HTMLや簡易PDFの作成による常時結合
• 簡易PDFは常時ではないですけど><
• レビューによるフィードバック

38. 編集者はゼロを1にはできないけど、1を2にする
お手伝いはできるかもなので（とゆうかそれがお
仕事なので）、著者さんが一人で苦闘しないよう、
こまめな成果物やフィードバックを。

39. ご注意事項

40. GitHubのプライベートリポジトリ
はご用意いただく必要があります
• 現時点で当社でご用意できるのは、試験運用中
のGitLabのみ（バックアップなし）
• 1媒体1リポジトリとすると、当社全体だと年間
約400のプライベートリポジトリが必要
• 増刷や改定もあるので、1年だけ維持すれば良
いわけではない
• 実際には雑誌は1記事1リポジトリほしいので、
僕一人でも年間50リポジトリ程度必要

41. ご参考：Vol.81での勢力図

42. あくまで私の場合のお話です
• 今回の発表内容はあくまで僕の場合のお話です
• WEB+DB PRESS編集部の人は
だいたい同じようなやり方でいけます

43. 最後に

44. ハブでありたい
GitHubさんにはとうてい及びませんが、
WEB+DB PRESSはエンジニアの方々の
ハブの一つでありたいと願っています。
読者の方同士、著者さん同士、読者の方と著者さん、
さまざまなプログラミング言語や技術、
誌面を通して、これらをつなぐハブになりたいです。
そのためには、、、

45. 書いてください
or
読んでください

46. ご静聴ありがとう
ございました