2

3

100冊越えた記念パーティー
やり損ねた•
いちばんやさしいPython入門教室
改訂第2版

９刷

9月8日発売予定！
最後の章では、Yolov8を使った画像認識までやります！

２版

5

・月刊I/O・インターネットマガジン
・DOS/Vマガジン
・VBマガジン・.NETマガジン・ソフマップワールド

•

今回は、最大公約数的なオーソドックスな話をします（だいたい、どの出版社でも同じ、基礎的な話をします）
今回は、主に「書籍」をテーマにします。
不明点は、最初に編集さんに聞いてね！

•
1. ある技術の解説を書いてもらいたい
2. 現場の実際の話を書いてもらいたい→特定の「ネタ」にフォーカス→クラウド、LLMなど旬のネタ
3. あなたについて書いてもらいたい→有名人などのコラム→今回、このケースは除外

•・ブログ
・Twitter
・講演、イベントでの展示
・技術書典や技書博などで出している同人誌書けそうな人を探して依頼するよ•・代表的な人にお声がけ（講演している人、ブログ書いている人など）
・広報を通じて、企業内でチームを組んで執筆［メリット］
・複数人で書くので、ひとり当たりの負担が少ない
・執筆になれていない人でも、慣れた著者のサポートを受けながらチームとして執筆できる•・文章がおかしいのは、編集部で直せます。少しの調整で読みやすくするノウハウも持っています。
・でも構造がおかしいのを直すのは厳しいです→前後関係がおかしい→途中の説明が抜けている→理論破綻している•・忙しいエンジニアに、推敲・校正までお願いするのは悪いと考えている編集部も多いです→負担が大きいと感じるなら、編集部にお任せOKです・エンジニアから出てくるのは箇条書きだけ、ヒアリングした結果だけ、そこから執筆するなんてこともあります→僕が呼ばれます！！！
・大きくリライトします→リライトしすぎて怒られることもありますが、それも僕の仕事です•
知見を皆に広めるという目的で、負担のない範囲でのご協力をお願いします•・大企業じゃないから？
・技術力が足りないから？
→いいえ。ネタが合わない or 編集部のリサーチ不足が理由です。
違います！
単純なミスマッチです。

•
・PRする
→印税・原稿料は、エンジニアの単価に比べて安価です。ですので、エンジニアとして忙しそうな人に声をかけるのは悪いと思っています→「依頼あれば書きます」とPRしていただければ、お声がけしやすい！

・実際に書いてみる→ブログ→雑誌記事/Web記事→書籍→同人誌で書いてみるのも方法のひとつ→「どんな感じの文章が書けるか」がわかると、お声がけしやすい！
→声がかからないのは技術力不足とかでなくミスマッチが多いです。
→面白企画があれば、「持ち込み企画」として提案できます！
それは最後にお話します•

・書籍であれば、少なくとも128ページ以上→ある程度のボリュームが必要
・雑誌であれば、編集さんに依頼されたページ数以内→ダイジェスト的にコンパクトにまとめる必要

•
目次
はじめに
第1章
1-1 なんとか
■なんとか
■なんとか
1-2 なんとか…
第2章
2-1
第X章
索引
著者略歴章
節
小見出し

執筆とは、こうした決まったスタイルに、内容を落とし込んでいく作業••

概要を示すリード文

•
節見出しと小見出しの間には、必ず文を入れている章によって、節見出しと小見出しとの間に文が入るケースと入らないケースが混在するのは統一感がなくて読みにくいよ•
スタイルは編集部が決めるので意識する必要はないが、統一感をもった書き方をすべき。
・章によってリードがあったりなかったりする。章によって極端に長さが違う・小見出し（■見出し）がひとつしかない節がある
・極端に短い節がある、極端に長い節がある→読みにくさの原因になるので、考慮すべき事項

•
タイトル
ちょっとした文章（リード）
■見出し
■小見出し
■小見出し
雑誌の記事を依頼されたら、その雑誌に掲載され■見出している記事を確認して、■小見出し
そのフォーマットに落とし込もう■小見出し

•・編集部が作るもの
・対象とする読者、書籍の大きさ、ページ数・発売時期、価格
・内容（構成案） ←現実との乖離があれば補正する
・この資料を基に編集部や営業部で企画会議して、発刊するかどうかを決めていく•

この本の目的が書かれている

読者対象を定義している

•

•

•
・全体の流れがわかる→「流れ」を作る→説明の過不足、前後関係がおかしくないか（前提とする説明を先にきちんとしているか）がわかる
・総量がわかるので、尻つぼみになりにくい
例えば200ページの書籍を5章構成で作るなら、1章は、所詮40ページくらい。1章が4節なら、1節8ページ。つまり、分割することで、「できそう」な範囲になる・進捗状況を掴みやすい•・読者はその分野について何も知らない→いきなり本質から語っても理解できない。まずは、それが何なのか、どういうメリットがあるのか、デメリットがあるのか、などを語ってから、操作なり仕組みなりに入る→使うとよいメリット、習得するとよいメリット、何ができるのかを伝えないと、習得意欲がわかない・ゴールを明示する→いきなりやってみましょう、じゃくて、最初に、「何を作るのか（目指すのか）」を示す。なんのために操作しているのかわからないまま読み進めるのはつらい•「Sikulixとは」からではなくて「RPAとは」から始めることで、RPA分野におけるSikulixの位置づけを明確にする。
RPAをはじめようという人が対象ということは、読者はRPAを知らない。だから、そこから書く！

•・対象読者は誰か
・本書を読んだあと、読者はどんな得をするか→「○○がわかる」「○○の操作ができるようになる」
・流れを作る→説明していないことを説明なしに語らない（どうしてもそうなってしまうなら、○○で説明と補足すること）

•
・テキスト
・WORD
・Markdownなど、基本的に何でも可。使いやすいソフトで。
編集さんと事前調整
テキストに変換され、DTPで組版されるよ•「見出し」「本文」「プログラムリスト」などをどのように記述するかを編集さんと調整する→テキストであれば「■は大見出し」「●は小見出し」などの規則→Markdownであれば「#が大見出し」「##は小見出し」など→Wordであれば、見出しのスタイルを適用するなど※基本、テキストにするので、WORDで書く場合、「テキストボックス」とかは使わないのが望ましいです（テキストとして保存したとき失われるため）。
執筆しやすい、見やすくフォントなどを調整するのはよいですが、誌面に、そのまま反映されないです（新たにDTPさんがテキストから組版するため）•・テキストの装飾→赤字とか太字とか……
→指示方法を編集さんと調整→できないこともある→プログラムリストで予約語を太くとか→編集さんと相談→できない/やり方によって反映できないこともある
事前に調整しないと、せっかくの作業が反映されないこともあります！

•・オリジナル（説明用の引出線とか文字とかを重ねない）をPNG形式などで用意する（トリミングをしないものも用意するのが望ましい。レイアウトの都合で、「余白が空いてしまって、トリミング前の画像が欲しいということがある）
・引出線や文字などは、別の方法で指示する→たとえばPowerPointに貼り付けて、そこに引出線や解説を入れる（そしてオリジナルの画像とともに提出する）→印刷したものに、手書きで引出線でもOK•・ラフでよい（デザイナさんが清書する）→手書き、PowerPointなど→ラフの場合、テキストだけ、別にファイルとして用意して提出すると「スペルミス」を防げます
・自分で作りたいよという人は、Illustratorで読める形式で→draw.ioとか使えます
デザイナさんの清書なしでそのまま掲載したいときは要確認！

編集部によって工程が違うので、確認してね！

•・文章が多少おかしいのは編集部で直せます→おかしいまま出版されるのは、編集部の怠惰か著者に気を遣ったかです。気遣いで直されないケースもあるので、もし、直してほしいなら「直してください」と告げてください→原稿は著者のものです。編集は著者の意見を尊重します。
・本文の量が多いときは、適当に「見出し」を入れると読みやすくになります→見出しを入れると視覚的にわかりやすくなります・だらだら書かずに、箇条書きにするとわかりやすいです→手順などは、箇条書きのフォーマットにするとよいです•
EC2インスタンスを作るには、AWSマネジメントコントールを開き、［EC2］メニューを開きます。
そして［インスタンス］の部分から、［新規］をクリックします。新規の画面が表示されたら、まず、「インスタンス名」を入力します。ここでは「○○」とします。
次に、AMIを選択します。AMIを選択するには・・・・・・・・

•EC2インスタンスを作るには、次のようにします。
【手順】EC2インスタンスを作る［1］［EC2］メニューを開く
AWSマネジメントコンソールを開き、［EC2］メニューを開きます。
［2］インスタンスを新規作成する［インスタンス］の［新規作成］をクリックします。
［3］名前を入力する「インスタンス名」を入力します。ここでは「○○」とします。
［4］AMIを選択する
次に、AMIを選択します。AMIを選択するには・・・・・・・・

•
・原稿の通りに進めると、原稿に書いていない選択肢を選ばないと、その通りにならないケースがある→ライブラリのインポートの手順ヌケとか→設定のヌケとか・そこで、その選択肢を選ぶ理由を教えてほしい→［○○を選択します］と、いくつの選択肢のなかから選ぶ
場合、理由がないとモヤモヤします•・著者が決めた名称なの？
・それでないといけない名称なの？
・それが慣例なの？
「決まり」か「決めた」のか「慣例」か。
「決まり」なら、どこで決められているのか（原典）も示してあげると親切です！

•
編集部による。原稿の難易度にもよる→初心者向けのものであれば、検証することが多いです→上級者向けのものでも、編集部がわかる範囲で検証することが多いです→データを用意しないといけないとか、機材が必要とか、検証環境を用意しないといけない場合は、しないこともあります→手順がダイジェスト雰囲気風の原稿は検証しません（できません）

•

書き方テクニックについては、こちらの動画を見てね
https://event.ospn.jp/osc2021-onlinehiroshima/session/431543

•
原稿提出

レイアウト済みのものは、校正紙としてPDFで出てくるよ

編集

レイアウト

初校

再校

修正は初校までが原則。
「はじめに」「著者略歴」とかは、このあたりで書く

初校の修正が反映されたことを確認するのが目的。
→このあと3校、4校と進むが、著者は見ない

•・編集部が重要語句をピックアップしてくれるケースが多い→編集さんはその分野のプロではないので、不適切な用語が混じるケースもあるので、確認することをお勧めします→用語統一の揺れに気づくこともあるので、そういった意味でも確認するのがお勧め
・こだわるなら、自分でPDFにマーカーを付けて、「これでお願い」というのも可能→ページ番号は編集部にお任せでOK•・企画書を作る・編集部に営業する→編集部のホームページ→書籍の「奥付」→技術書の同人イベント、各種イベントの物販コーナー→いきなり企画書を送るのではなくて、こういう書籍を出したいと思うのだが、企画書を送ってもよいか？ と聞くところ
からスタート•・テーマが合う出版社を探すこと
ソフトウェア系、開発系、ゲーム、IoTや電子工作
インフラ、ネットワーク、サーバー初心者向け、上級者向けなど……
合わない出版社に持ち込んでも良い
結果にならないよ•・連絡こない・企画の進捗がわからない
・立ち消えになったかもわからない→遠慮なく、催促してください。

•・手間の割に費用が見合わないかも知れませんが、編集部は負担を減らすよう、最大の努力をしています

・書籍1冊を書き上げるなんて、自分にはできないと思っても、構成案を作って細分化すれば、そこまでできないものでもありません→ふだん設計書などを書いているエンジニアにとって、技術書を書くのは、システムを作るのとあまり変わりません
是非、皆さん、気軽に技術書の世界へ！

•
エンジニアと出版社の橋渡しをします！
報酬は菓子折で！

ぼくは、本高砂屋のエコルセが好きだよ！
あと、パイ系のお菓子も好き！

小笠原種高

大澤文孝

モウフカブール
http://mofukabur.com/

新刊•
当選すれば出ます！

出ます！

2023年11月12日（日）池袋サンシャインシティ

2023年11月25日（土）大田区産業プラザPiO

現在サークル募集中。
当落抽選

現在サークル募集中。
先着順

どちらもサークル募集中！
参加申し込みしよう！

•・先着順なので、申込時の入力不備がなければ、参加確定
・規模が小さいので、初参加でもあたふたしにくい2023年11月25日（土）大田区産業プラザPiO
現在サークル募集中。
先着順•・印刷所に「PDF」として渡せば、印刷できます。ページ数にもよりますが、本文モノクロなら、お小遣いの範囲で作れます
・Re:ViewやVivliostyleなどMarkdownなどから組版できる（PDF出力できる）ソフトもあるが、WORDなどからPDFを作るのでもOK・オンラインの印刷所なら、クレジットカードで決済してPDFをアップロードして終わり！
・あとは内容次第！ 印刷についてわからないことあれば、Twitterで絡んでください！

•・こんなこと知りたい・こういうことがわからない→是非、教えてください！

モウフカブール
http://mofukabur.com/

小笠原種高

大澤文孝