「いちばんやさしいExcelピボットテーブルの教本」執筆の裏話

2019年8月12日

2019年8月23日（金）に、私が書いた本《いちばんやさしいExcelピボットテーブルの教本》が発売されます。

今回は、この本がどうやって作られていったのか、著者である私の視点で書いていこうと思います。

あくまで、著者目線での話ですので、私から見えている範囲の話しか書いていませんし、記憶で書いていますので細部は違っているかもしれません。

あらかじめ、ご容赦いただければと思います。

（著者から見た）全体像

打診を頂いたのが2019/1/8。発売日が2019/8/23なので、打診を頂いてから約7ヶ月半で本が出版されることになります。

いわゆる執筆期間（最初の原稿である「第一稿」の作成）だけだと約3ヶ月かかっています。

時期	内容
2019/1/8	出版の打診を受ける
2019/1/16	仮目次案作成・出版社打ち合わせ
2019/2下旬	企画が通った旨、連絡を頂く
2019/3/1	目次案修正。外部編集者との打ち合わせ
2019/3/5～2019/5/25	第一稿執筆
2019/5/10	写真撮影
2019/5/26～2019/7/4	原稿修正（第二稿、第三稿）
2019/7/5～2019/7/31	デザイン稿の校正（第一校～第三校）
2019/8/3、2019/8/7	早期購入特典 校正作業

執筆のきっかけ

2019年1月8日にインプレスの担当者さんから、メールにて打診を受けました。

そして1月16日に初めての打ち合わせ。

そのとき、先方からは、次のように言われたように記憶しています。

• ピボットテーブル本の著者を探している
• 私（＝羽毛田）が開催しているピボットテーブルセミナーの案内を見て依頼しようと思った
• 以前、自社（＝インプレス）で本を出版していることもあり、企画は通しやすいと考えている

てっきり、以前インプレスから本を出版していたから、著者候補に上がったのかと思っていたのですが。

実際の順序としては著者候補に選んでみたら、たまたま自社で本を出したことがある人だったという流れだったようです。

初回打ち合わせで、こちらからお願いしたこと

私がピボットテーブルの本を書くなら「こだわりたい」と感じているポイントが2つありました。

ピボットテーブル本にしては、かなり大胆な提案だと思うので、最初に言っておかないとトラブルになると思い、初回打ち合わせでお伝えしました。

ピボットテーブルのことを、本全体の半分も書かないかもしれないが、それで良いのか？

ピボットテーブルを使いこなすためには、ピボットテーブル以外の部分の知識（いわゆる「元データの下準備」）が非常に大切です。

ただ、その下準備の話をしようと思うと、ピボットテーブルの本であるにもかかわらず、ピボットテーブルそのものの説明をするスペースはかなり小さくなることが予想されました。

そこで、ピボットテーブルの本なのに、ピボットテーブルの話が少なくなっても良いのかを真っ先に聞いてみました。

本の最後は「SUMIFS関数の話」で締めてもいいのか？

ピボットテーブルとSUMIFS関数は、代替的な関係にあり、多くの場合、どちらを使っても集計ができます。

そして、それぞれにメリット・デメリットがあるので、実務では、この両者を場面ごとに使い分ける必要が出てきます。

実際、私は、次のような流れで使い分けることをおすすめしています。

• 最初はピボットテーブルで集計
• ピボットテーブルに不便さを感じたらピボットテーブルをSUMIFS関数に置き換え

この話は、実務用途向けにピボットテーブルの説明をする以上は、避けては通れない話だと思っています。

そこで、本の締めで「SUMIFS関数を使おう」という話を書いても良いかも聞いてみました。

ダメといわれたら、（状況次第で）お話をお断りすることも考えようと思っていたのですが、どちらも即座にOKが出ました。

この打ち合わせで、今回の本の方向性が決まりました。

企画が通るまでに（著者として）行った作業

著者として企画が通るまでに行った作業は、「目次を作った」だけです。

目次案を出して、しばらく待っていたら、2月下旬に企画が通ったとの連絡を頂きました。

1冊目のときには、企画が通るまでに何往復かやり取りを行いました。それに比べれば、（著者目線では）ほぼ何もせずに企画が通ったという印象です。

外部編集者との打ち合わせ

今回の本は、インプレスから出版されますが、株式会社リブロワークスの担当者さんが「編集」の立場で関与されています。

具体的な作業の進め方としては、主に、私（＝著者）と、リブロワークス（の担当者）との間でやりとりを行い、インプレス（の担当者）はその様子を随時チェックするイメージです。

このような体制で作業をするため、リブロワークスの担当者さんにも一度お会いしておいたほうがいいだろうということで、2019/3/1に、リブロワークスさんにお邪魔して、打ち合わせ（兼 顔合わせ）をすることになりました。

このタイミングで、次のような内容の打ち合わせをしています。

• 本の最終的な方向性を確認（目次案の再検討）
• 役割分担（※特に、画面キャプチャを誰が撮影するか）
• 原稿作成、受渡方法の確認

本の中で、Power Queryを扱うことが決まったのも、この時期です。

この打ち合わせ後、正式に原稿の執筆を始めました。

原稿の執筆

目次案も固まり、関係者の顔合わせも終わったので、 一巡目の原稿（第一稿）の執筆を始めました。

前回の本でも第1章を書くのは難航したこともあり、最初に第2章～最終章まで原稿を書き、最後に第1章を書くという順番で原稿を書いていきました。

執筆にかけた時間などは、次のような感じです（正確に測定していないので、あくまで感覚的な数値です）。

• 第一稿の執筆にかけた期間は約3ヶ月弱
• 執筆にかけた時間は500時間～600時間くらい
• 文字数は11万字～13万字くらい（※編集後のMarkdown原稿のサイズ28万bytesから推測）

また、今回の原稿は、次のような環境で作成しています。

項目		使用ソフト
記述スタイル		Markdown
使用ソフト	原稿作成	Visual Studio Code
	画面キャプチャー（仮想環境）	VMWare Workstation
	原稿プレビュー	Atom
原稿のやり取り		GitHub

Markdown（を拡張したもの）で原稿作成

今回の原稿は、すべてMarkdownに、リブロワークスさんが独自タグを付加したもので作成しています。

Markdownで作成した原稿はAtom（≒高機能なメモ帳）で見ると、本のレイアウトに近い状態でプレビューができるようになっています。

（参考）
MarkdownプレビューツールをAtomパッケージ化しました

私自身はAtomをあまり使ったことがなかったので、結局、次のようなスタイルで原稿を作成することにしました。

• Visual Studio Code（≒高機能なメモ帳。Atomと機能的には似ているらしい）で原稿作成
• Atomでプレビュー表示

Visual Studio Codeでファイルを修正すると、即座にAtomのプレビューも変わり、ストレスなくプレビューを確認できます。

この仕組みのおかげで執筆自体は、かなり快適でした。

画面キャプチャの取得環境

今回の本では、私のほうで画面キャプチャを撮るという前提で作業が進められました。

ということで、私が、いったん全キャプチャを取得しています（もっとも、最終的には、レイアウトの都合その他の要因で、編集者さんのほうで、かなりの部分のキャプチャを撮り直して頂くことになったようですが）。

画面キャプチャは、VMWare Workstationで「Windowsの仮想環境」を作成し、その中で画面キャプチャを撮っています。

普段使っている環境で画面キャプチャを撮ってしまうと、設定が初期状態と違う・不要なものが写り込むなど、トラブルが起きがちなので、それを避けるために仮想環境を構築しています。

画面キャプチャを撮るときには、まず、下記のツールを使って、クリップボードにデータを格納します。

• スクリーンショット（Ctrl+Shift+＋）
• Snipping Tool

そして、そのクリップボードのイメージを、Visual Studio Codeの「Paste Imageプラグイン」でpngファイル化しました。

「Paste Image」プラグインを使うことで、一つ一つ手作業でファイル保存するのに比べ、かなり作業が楽になりました。

表紙＋イラスト用の写真撮影

「いちばんやさしい」シリーズでは、著者のイラストが、表紙など本のいたるところに差し込まれます。

そのイラストは、実際に写真撮影をしたものからイラストを起こしています。

ということで、第一稿を書いている途中の5/10に写真撮影が行われました。

時間にして2時間くらい。貴重な体験ができました。

ただ、このあとの校正作業で自分の写真が入った原稿をチェックするのは、精神的にかなりキツかったです（苦笑）。

原稿修正・編集・校正作業

第一稿を書き終えたら、データをアップロード。その後、編集・校正作業に入ります。

編集・校正作業は、編集者さんが（文章を含め）修正・編集を加えた後、私が内容確認＋必要に応じて修正する、という作業を2巡繰り返しました。

その後、デザイナーさんが作成した原稿（いわゆる初校）が上がってきて、さらに、そこから2巡～3巡、編集・修正を繰り返しました。

結局、最初の原稿から4巡～5巡程度、編集・修正作業を繰り返したことになります。

原稿のやり取りはGitHubベース

原稿のやり取りはGitHub経由で行いました。

複数人でGitを使う処理に慣れていないので、若干不安がありましたが、実際には、私はmasterブランチに原稿をPushしていればいいだけだったので、1人でGitを使っているのと、ほとんど変わらない感覚で作業ができました。

編集者さんからの修正は、別ブランチで行われ、私が確認したうえでmasterブランチにマージするという流れで進みました。マージするときに若干ドキドキしましたが、ほぼトラブルは出なかったように思います。

私が、Gitの機能をフルに使いこなせているわけではないので、便利さを完全に享受できているわけではありませんが、データのアップロード・ダウンロードをGit操作だけで完結できるだけでも、とても楽でした。

校正作業はPDFベース

デザイナーさんがレイアウトをした後の「校正作業」に入ると、作業はすべてPDFファイルベースで行われました。

基本的には、修正をお願いしたい点をPDFの「校正」の機能を使って、修正依頼を作成しGitHubでアップロード。また、全員で共有したほうがいい事項などはIssueを立てて管理をする、というような運用でした。

PDFファイルのやり取りをGithub経由で行っている以外は、基本的には、前回の本の製作過程と同じでした。

PDFファイルベースでの修正は、Markdownベースでの修正に比べると面倒に感じましたが、これは仕方がないところなのでしょうね。

一部原稿のカット＋付録PDFファイル化

実は、校正の最終段階で、一部の原稿（約10ページ分）がカットされることになりました。

私が、そのことを知ったのは7/29（原稿を最終確定させるのが7/31の予定だったので、その2日前）でした。

そのページでは、（私としては）重要なことを解説していたことに加え、最終段階（デザイン稿の2回目のチェック時＝二校の段階）で、いまさら他の部分の原稿を差し替えるわけにもいかないため、単にカットされるのでは、なかなかツラいものがあります。

そこで、何らかの形で配布できないか打診してみたところ、早期購入特典として配布できることになりました。

もっとも、私からリクエストしたのはいいものの、校正作業に入ってみると、編集者さんから「わかりにくいから書き直せないか？」というコメントが多く付き、修正にかなりの手間がかかってしまいました。

後で聞いたら、カットした理由は「出版社内で原稿を読んだ結果、誰も意味が理解できなかった」からだったそうです。なので、手間がかかったのは、ある意味自業自得ではあります。

まとめ

こんな作業過程を経て、本ができあがりました。

今回も、1冊目の本と同様に、編集者さんその他の方のおかげで、私の当初のアイデアを、より良いものに仕上げて頂けたと思います。

この場を借りて、お礼を申し上げます。