いものやま。

雑多な知識の寄せ集め

TeXで同人誌を作ってみた。(フォント周り)

f:id:yamaimo0625:20190918075457j:plain

昨日に引き続き、同人誌制作に \TeXを使って学んだことについて。

今日はフォント周りについて。

なお、現時点での理解を書いていて正確性には欠けるので注意。
あと \TeX \LaTeXを区別せずに扱ってる。

参考にしたのは以下とか:

[改訂第7版]LaTeX2ε美文書作成入門

[改訂第7版]LaTeX2ε美文書作成入門

LaTeX2ε辞典 増補改訂版 (DESKTOP REFERENCE)

LaTeX2ε辞典 増補改訂版 (DESKTOP REFERENCE)

 \TeXでのフォントの仕組み

まず \TeXはフォントのメトリック情報だけを使って組版を行う

メトリック情報というのは文字を箱として扱ったときの高さとか幅とかのことで、つまり \TeXは文字の細かい形(グリフという)なんかまったく見てなくて、大きさのバラバラな箱を「いい感じ」になるように並べているだけだったりする。

f:id:yamaimo0625:20190919131528p:plain

このメトリック情報が書かれたファイルがtfmファイル(TeX Font Metricファイル)。

欧文の場合、フォントによってメトリックは変わってくるので、指定されたフォントから対応するtfmファイルを \TeXが見つけられる必要がある。
そこで使われるのがfdファイル(Font Definitionファイル)。

 \TeXではフォントを5つの要素で識別している:

  • エンコーディング(数値と文字との対応づけ、OT1とかT1とかがある)
  • ファミリー(書体(≒フォント名))
  • シリーズ(太さ、ボールドとか)
  • シェイプ(形、イタリックとか斜体とか)
  • サイズ(大きさ、10ptとか)

この5つの要素とfdファイルを参照して使われるtfmファイルが決まる。

 \TeXはDVIファイル(Device Independentファイル)を出力するけど、そこには使われたtfmファイル名しか書かれていない。
なので、DVIを表示(あるいは変換)するソフトはtfmファイル名と実際に使うべきフォントとの対応関係を知る必要がある。
そこで使われるのがmapファイル。

これでtfmファイル名から実際のフォントが分かり、実フォントを使って表示(や変換)が行われることになる。

図にまとめるとこんな感じ:

f:id:yamaimo0625:20190919135611p:plain

フォントの指定は\usefont{<encoding>}{<family>}{<series>}{<shape>}という制御綴などを使うっぽい。

論理フォント

この論理フォントという言い方は自分の言い方で、一般にそう言われているわけではないので注意。

上記のフォント指定とは別に、論理的なフォントの指定があるように思う。
\textrm{...}とか\textit{...}とか。
前者はローマン体のフォントを使うことを指定していて、後者はイタリック体のフォントを使うことを指定している。

この論理的な指定で実際にどのフォントが使われるかは、\rmdefaultなどを再定義すると変わるみたい。

欧文に関して

 \TeXの欧文で定番のフォントといえばComputer Modernだったけど、使われているエンコーディングが古いなどで、あまり好ましくないみたい。
同じデザインのフォントを使いたいなら、Latin Modernを使うといいとのこと。

Latin Modernを使うには次のようにする:

\usepackage{lmodern}
\usepackage[T1]{fontenc}

和文に関して

 \TeXでのフォントの仕組みを上で書いたけど、これが和文になるとちょっと話が変わってくる。

和文だとどのフォントでもメトリックが変わらない
どれも正方形の箱の中に文字を入れている。

そこで、明朝体なら「Ryumin-Light(リュウミンL)」、ゴシック体なら「GothicBBB-Medium(中ゴシックBBB)」というフォントが常に使われる。
(もう少し正確に書くと、fdファイルによって明朝体はjis.tfm、ゴシック体はjisg.tfmというtfmファイルを使うことが決まり、これらは仮想フォントというものになっていて、そこにrml.tfm(リュウミンL)やgbm.tfm(中ゴシックBBB)を使うことが指定されているらしい)

じゃあ、リュウミンLや中ゴシックBBBってどんなフォントなのかというと基本的にはシステムには入ってない
なのでPDFにしたときに実フォントは埋め込まれず、表示した時に使える明朝体/ゴシック体の適当なフォントが使われる。

それじゃ困るのでmapファイルで埋め込むフォントを指定することになるんだけど、つまり、DVIファイルで出力された時点でフォントは2種類(明朝体/ゴシック体)しかないので、埋め込めるフォントも2種類しかない。

マジでゴミ仕様

・・・とはいえ仕方ないので、それで頑張るしかない。。。

rmlやgbmというtfmファイル名に対して実フォントを対応させるためにmapファイルを更新するのだけど、それにはupdmapというツールを利用する。
これはDVIウェアごとにmapファイルが必要だけどそれを一つずつ変更していたら大変なので一気に変更するためのもの。
和文の場合はkanji-config-updmapを使うことになる。

updmapにはシステム全体の設定を変えるupdmap-sysと個人の設定を変えるupdmap-userがある。
和文についても同様で、kanji-config-updmap-sysとkanji-config-updmap-userがある。

具体的な指定方法はヒラギノフォントを使う設定のところで。

OTFパッケージ

和文のフォントメトリックは正方形であるべきなんだけど、歴史的な経緯で実際にはちょっと違っていたらしい。
これを直すにはOTFパッケージを使うとのこと。
(このパッケージ自体は名前の通りOpenTypeフォントを使うためのもの)

また、オプションでjis2004を指定すると、JIS2004字形になる。
いくつかのフォントの字形が新しく定められたものになる。

あと、オプションでdeluxeを指定すると、使えるシリーズ(太さ)が増えたり丸ゴシック(mg)が使えたりするとのこと。
このオプションを指定しなかった場合、太字は全部ゴシック体にされてしまうのだけど、これをしていすることで太字の明朝体が使えるようになる。

なので、和文では基本的には以下のようにしておいた方がよさそう:

\usepackage[deluxe,jis2004]{otf}

ヒラギノフォントを使う設定

macOSの場合ヒラギノフォントがバンドルされているので、せっかくだからこれを使いたいところ。
なお、PDFに埋め込んで再配布してもライセンス的には問題ないっぽい。
(単体で再配布するのはダメ。あと埋め込まれたものを取り出して単体で使うのもおそらくダメ)

以下を参考にして使えるようにしてみた:

まずはTLContribから必要なパッケージをインストール:
(TLContribというのはTeX Liveとは別管理されているリポジトリらしい)

$ sudo tlmgr repository add http://contrib.texlive.info/current tlcontrib
$ sudo tlmgr pinning add tlcontrib '*'
$ sudo tlmgr install japanese-otf-nonfree japanese-otf-uptex-nonfree ptex-fontmaps-macos cjk-gs-integrate-macos

そしてリンクを作成する:

$ sudo cjk-gs-integrate --link-texmf --cleanup
$ sudo cjk-gs-integrate-macos --link-texmf
$ sudo mktexlsr

なお、リンクというのはフォントのシンボリックリンクのことだと思う。
おそらくTeX関連のファイルが入っているtexmf以下にフォントのシンボリックリンクを作ってるのだと思われる。
あとmktexlsrはファイル一覧のキャッシュの更新。

最後にヒラギノフォントを使うようにmapファイルを更新する。

$ sudo kanji-config-updmap-sys --jis2004 hiragino-highsierra-pron

ちなみに、更新前の状態は以下:

$ sudo kanji-config-updmap-sys status
CURRENT family for ja: ipaex
Standby family : hiragino-highsierra
Standby family : hiragino-highsierra-pron
Standby family : ipa
Standby family : toppanbunkyu-highsierra

IPAexフォントが埋め込まれる設定になっていたっぽい。

更新後の状態は以下:

$ sudo kanji-config-updmap-sys status
CURRENT family for ja: hiragino-highsierra-pron
Standby family : hiragino-highsierra
Standby family : ipa
Standby family : ipaex
Standby family : toppanbunkyu-highsierra

ヒラギノフォントが指定されていることが分かる。

設定したこと

自分がした設定をまとめると以下:

  • Latin Modernを使うようにした
  • OTFパッケージを使うようにした
  • ヒラギノフォントをPDFに埋め込むようにした

上2つについては、以下のようにソースに書いた:

% フォント関連
% Computer ModernのかわりにLatin Modernを使う
\usepackage[T1]{fontenc}
\usepackage{lmodern}
% OTFパッケージを使う
\usepackage[deluxe,jis2004]{otf}

また、一番下については前述の通りの設定を行なった。


宣伝です。
気になった人はチェックをお願いします!

今日はここまで!

TeXで同人誌を作ってみた。(ビルド環境構築)

f:id:yamaimo0625:20190918075457j:plain

今日からは \TeXを使って学んだことをまとめていく。

なぜ \TeXを使ったか

文章が主体の同人誌を作る場合、組版に使えるソフトはいくつか候補がある。

特に有力なのがRe:VIEW
実績が多く、また同一ソースから複数のファイル形式に出力できる魅力がある。

ただ、以下のようなことからRe:VIEWではなく \TeX\LaTeX)を使うことにした:

1.  \TeXの勉強がしたい

そう、何だかんだでこれが大きい。
勉強で作っている部分もあったので、いろいろ試したかった。

『哲学散歩道』も \TeXで作ったんだけど、デザイン周りは全然触れてなくて、ほぼ素の出力になっている。
なので、 \TeXで本のデザインってどうやったらいいんだろうという疑問がずっと残ってた。
例えば、以下のようなもの:

  • どうやって目次をデザインするのか
  • どうやって見出しをデザインするのか
  • どうやってページレイアウトをデザインするのか
  • トンボや隠しノンブルはどうやって入れればいいのか
  • 断ち切りまで伸ばすのはどうすればいいのか

これらの疑問を解消したくて、 \TeXでの組版にチャレンジしてみた。
実際、いろいろ学べて、今日からの記事はそこで学んだことを忘れないようにするためのもの。

2.  \TeXにメリットがあった

理系だったので、卒論、修論、あるいはレポートで、何だかんだで \TeXは使ってきた。
こうやってブログを書くときにも数式は \TeX記法を使って書いてるし。
なので、これまでにも \TeXにはけっこう触れていて、慣れている部分が多い。
そういう意味で、まったく知らないRe:VIEWを使うよりも心理的障壁は低かったりする。

また、数学の同人誌なので、数式がそれなりに出てくる。
もちろんRe:VIEWでも数式は書けるけど、数式を書くことが分かっているなら、最初から \TeXを使った方が素直と言える。

3. Re:VIEWに不安があった

これもけっこう大きかった。

Re:VIEWはPDFへの出力のバックエンドとして \TeXを使っているので、何か問題があったときには中間出力された \TeXのソースや、あるいはそのソースを出力したRubyのソースと戦うことになる。
何も問題がなければ杞憂ですむのだけど、何かあったときにはその対処コストがちょっと無視できないレベルで大きいのがかなり気になった。

そして、もし問題が起きて結局 \TeXの勉強をしないといけないのなら、最初から素直に \TeXの勉強をした方がいいよね、と。
 \TeXの勉強をしないといけないかもしれないという不安を抱えながら進めるより、 \TeXの勉強をすることを最初からスケジュールに入れておいた方が心理的に安心できる。

実際、Re:VIEWまわりで謎の挙動をして困ったという話はチラホラ見かけた・・・

まぁ、リスクに対してメリットが遥かに大きいから、普通はRe:VIEWを使った方がいいとは思うけど。

 \TeXのインストール

これはRe:VIEWを使う場合も必要。
TeX Wikiを参考にMac TeX 2019(TeX Live 2019にmacOS用のソフトがバンドルされてる)をインストール。

ビルド環境の構築

以下のような感じでビルド環境を作った:

  • \TeXにはupLaTeXを使用
  • 索引作成にはupmendexを使用
  • PDF出力にはdvipdfmxを使用
  • ビルドツールにMakeとlatexmkを使用
  • ドキュメントクラスにBXjsclsパッケージのbxjsbookを使用

upLaTeXは \TeXに日本語用の拡張が入ったpTeX(Publishing TeX)がUnicode対応したupTeXにさらにe-TeX拡張(レジスタ増加など)の入ったe-upTeXでLaTeXフォーマットを読み込むようにしたもの。
何を言ってるのか分からないと思うけど、自分もそう思う。
 \TeXの違法建築っぷりはヤバい。

upmendexは同様にmendexという索引作成ツールがマルチバイト文字に対応したもの。

参考文献の管理にはBibTeXというツールがあり、それをマルチバイト文字に対応させたupBibTeXというものがあるのだけど、今回は使ってない。
BibTeXを使っても使わなくてもあまり手間が変わらなかったのと、ちょっと凝ったことをしたかったのが理由。

latexmk

 \TeX \LaTeX)では相互参照や目次作成のために複数回コマンドを実行しないといけないのだけど、何度もコマンドを打つのは面倒なので簡易的なビルドツールが使われることが多い。
今まではptex2pdfというツールを使ってたのだけど、調べるとlatexmkというツールを使った方がいいようだった。

上記の記事などを参考に以下の.latexmkrcを用意した:

#!/usr/bin/env perl

# Settings for latexmk.
# See https://konn-san.com/prog/why-not-latexmk.html

$latex          = 'uplatex -halt-on-error';
$bibtex         = 'upbibtex';
$dvipdf         = 'dvipdfmx %O -o %D %S';
$makeindex      = 'upmendex %O -g -s index.ist -o %D %S';
$max_repeat     = 5;
$pdf_mode        = 3; # generates pdf via dvipdfmx

最終的にはupBibTeXは使わなかったのだけど、そのまま残してある。
あと、upmendexのオプションで指定している-s index.istはスタイルファイル(これは \TeXのスタイルファイルとは別物)の指定で、索引の出し方を設定するスタイルファイルとしてindex.istを使うということ指示している。
index.istの内容については後日)

latexmkの使い方は、以下:

$ latexmk <対象のTeXソース>

生成物の削除なども行える:

# 生成物をすべて削除
$ latexmk -C

# 中間生成物をすべて削除
$ latexmk -c

Make

latexmkを直接叩いてもよかったんだけど、コマンドを覚えるのもなんだったのでMakeを使った。
Makeを使えばコマンドを覚えてなくてもいいし、あとでコマンド変更の差分を見たりすることが出来る。

Ω<つまりMakeはいにしえのDevOps, Infrastructure as Codeだったんだよ!
ΩΩΩ<な、なんだってー!?

というわけで、以下のようなMakefileを用意した:

.PHONY: all build book ebook clean clean-mid open eopen

BOOK = book.pdf
EBOOK = ebook.pdf
PDF = $(BOOK) $(EBOOK)

COMMON_SOURCE = <includeされるTeXソース> ...

all: build

build: $(PDF)

book: $(BOOK)

ebook: $(EBOOK)

%.pdf: %.tex
  latexmk $<

$(PDF): $(COMMON_SOURCE)

clean:
  latexmk -C

clean-mid:
  latexmk -c

open: book
  open $(BOOK)

eopen: ebook
  open $(EBOOK)

book.texは印刷用の \TeXソース、ebook.texは電書用の \TeXソース。
入り口を2つ用意することで、同一ソースから印刷用と電書用のPDFを両方とも生成できるようにしている。
(各ファイルから共通ソースをincludeしてる)

そして、latexmk自体は指定されたソースが依存しているソースのタイムスタンプまで調べてくれるようなのだけど、フロントエンドとしてMakeを使うとそこまで感知できないので、COMMON_SOURCEとして列挙して依存関係を追加するようにしている。
$(PDF): $(COMMON_SOURCE)の行がそれで、Makeはターゲットとソースの対のあとにコマンドが続かない場合、依存関係だけを追加する)

あとはcleanで生成物の削除、clean-midで中間生成物の削除、openで印刷用PDFのオープン、eopenで電書用PDFのオープンが出来るようにしてある。
(latexmkでPDFのオープンとか開いたままの更新とかあるようなのだけど、実際に試してみると使い勝手がめちゃくちゃ悪かった(たしか端末が対話状態のような感じになってCtrl-Cを押さないと制御が戻ってこなくなったりしたはず)ので、ビルドだけで終わるのか、PDFを開くところまでやるのかなどをコントロールできるようにした)

.gitignore

生成物はバージョン管理の対象から外したいので、.gitignoreに無視するファイルを追加:

*.fls
*.fdb_latexmk
*.aux
*.out
*.toc
*.idx
*.ilg
*.ind
*.log
*.dvi
*.pdf

*.fls*.fdb_latexmkはたしかlatexmkで出力されるファイル。
*.aux*.log*.dvi*.pdfあたりは \TeX(とdvipdfmx)で出力される典型的なファイル。
*.tocは目次のための出力。
*.idx*.ilg*.indは索引のための出力。
*.outは電書のためにページ内リンクをつけると出力される。

bxjsbookドキュメントクラス

ドキュメントクラスとしては、BXjsclsパッケージのbxjsbookを使った。
昔はjsclassesを使うのが普通だったけど、最近はupLaTeX以外でも使えるようにしたBXjsclsを使った方がいいみたい。

上記の記事などを参考にして、book.texおよびebook.texは次のようにした:

\documentclass[autodetect-engine,dvipdfmx-if-dvi,ja=standard,a5paper]{bxjsbook}

% 設定など

\begin{document}

% 本文など

\end{document}

これで最低限のビルド環境は整った感じ。


宣伝です。
気になった人はチェックをお願いします!

今日はここまで!

Githubプロジェクトボードで同人誌制作のタスク管理をやってみた。

今日も技術書典7で頒布する『Math Poker Girl』の作成に関する振り返り。

今日はタスク管理をGithubプロジェクトボードでやってみたという話。

Githubプロジェクトボードとは

GithubプロジェクトボードはGithubが提供するタスクボード。
タスクボードアプリとしてはTrelloMicrosoft Planner(Teamsで使える)、あるいはKanbanFlowなどがあるけど、Githubが提供しているタスクボードなので特に設定することなくリポジトリと連携できるのがいい。

タスクボードとは

タスクボードでは作業をタスクとしてボードに貼り付けて、例えば「計画済み」→「実施中」→「完了」みたいにタスクの位置を移動していくことでタスクの状態を把握する。

f:id:yamaimo0625:20190917105311p:plain

Githubプロジェクトボードでは、各リポジトリのissueやプルリクエストをカードとして貼り付けられる他、ノートという形でメモを貼り付けたり出来るようになっている。
また、ノートをissueに変換したり、issueの状態変化に合わせてカードを移動したり出来る。

これにより、以下のようなワークフローでタスクを進められる:

  1. やるべきことをリポジトリのissueに登録
  2. プロジェクトボードを用意
  3. issueをカードとしてプロジェクトボードに追加
  4. カードでタスクの状態を管理(計画済みか、進行中か、終わったのか)
  5. 雑多なタスクはノートで追加(必要ならissueに変換する)
  6. タスクを実施
  7. タスクがコミットで終了するならclose #<issue番号>としてコミット(これでissueがcloseされる)
  8. issueがcloseされるとカードも完了の場所に移動。

やる必要のあるタスクが脳内からボードに移動して見える化されるので、タスクのやり忘れを防げるし、その期間でのタスクの進捗具合も見れる
自分は個人で利用してたけど、チームなら各個人のタスクの進捗具合も見えるようになるのでサポートしたりも可能になると思う。

Githubプロジェクトボードの種類

Githubプロジェクトボードには実は3種類ある:

  1. リポジトリ所有のプロジェクトボード
  2. 個人所有のプロジェクトボード
  3. 組織(Organization)所有のプロジェクトボード

1.は各リポジトリで利用できるプロジェクトボード。
リポジトリの"Projects"タブをクリックすると利用できる。
「1リポジトリ-多ユーザ」の場合はこのプロジェクトボードを利用するといいと思う。

2.と3.は複数リポジトリに渡って計画をできるプロジェクトボードになっていて、2.は個人で使えるプロジェクトボード、3.は組織(Organization)で使えるプロジェクトボードになっている。
「多リポジトリ-1ユーザ」なら2.を使えばいいし、「多リポジトリ-多ユーザ」なら3.を使う感じになる。

自分は複数のリポジトリを使いたくて1人での利用だったので個人所有のプロジェクトボードを利用した。
個人所有のプロジェクトボードはプロフィールページを開いて"Projects"タブをクリックするか、右上のドロップメニューから"Your projects"を選択すれば利用できる。

どう運用したか

リポジトリの準備

まずリポジトリ(全部private)は複数用意していた:

そして、それぞれのリポジトリにタスクをissueで追加。

ちなみに、BlogリポジトリやStudyリポジトリは『Math Poker Girl』とは関係ないけど、同じ期間に並行して実施しているので同じプロジェクトボードから参照できるようにしている。

1スプリント1プロジェクトボード

1つのプロジェクトボードをずっと使い続けてもよかったんだけど、細く区切って使った方がカードの数も抑えられていいかなと思ったので、1スプリントごとにプロジェクトボードを用意して使うことにした。
ちなみに1スプリントは一週間にしていた。
いや、一週間ごとにリリースとかいうわけではないんだけど、固定長のタイムボックスがあった方がメリハリがあっていいと思うので。

そんな感じで1週間ごとに1つのプロジェクトボードを使っていたので、プロジェクトボードの名前は「yyyy-mm-wN」(例えば2019年の9月第3週なら2019-09-w3)としていた。

おそらくだけど、プロジェクトボードは期間の長さを固定にして、期間の長さが可変な締め切りはマイルストーン機能を使って管理するのがいいと思う。
(タスクの進捗テンポを守るためのプロジェクトボードと、プロダクトの期待を守るためのマイルストーンという使い分け)

4つの列

一番シンプルなタスクボードは「To do」「In progress」「Done」という3列を用意するけど、自分は「To do」を2つに分けて次の4列を用意して使っていた:

  1. Plan(今週やる作業)
  2. Today(今日やる作業)
  3. Working(作業中)
  4. Done(完了)

これは毎朝その日の計画を行いたかったから。

運用の流れ

そして、以下のような流れで運用していた:

  1. 週初め
    1. 新しいプロジェクトボードを作成
    2. 作業に関連するリポジトリをプロジェクトボードに連携
    3. 各日付の日付ノート(後述)をPlan列に追加
    4. 予定のノートをPlan列に追加
    5. その週に行うissueをタスクとしてPlan列に追加
  2. 毎朝
    1. その日の日付ノートをToday列に移動
    2. その日の予定のノートをToday列に移動
    3. その日行うタスクをToday列に移動
    4. 日付ノートをWorking列に移動し、各タスクの見積もり時間を記入
  3. 作業開始
    1. タスクをWorking列に移動
  4. 作業完了
    1. タスクをDone列に移動(issueならcloseすれば勝手に移動する)
    2. タスクの実績時間を日付ノートに記入
  5. 毎晩
    1. その日の振り返りを日付ノートに記入
    2. 日付ノートをDone列に移動
  6. 週終わり
    1. Done列を見返してその週の振り返り
    2. 来週以降のアクションや目標、予定を検討
    3. プロジェクトボードをclose

つまり「週初めに計画→週終わりに振り返り」という大きな枠があって、その中で毎日「朝に計画→夜に振り返り」を繰り返すようにして、その中でタスクをTodayからWorkingさらにはDoneへと進めていく感じにしていた。

実際のプロジェクトボードの様子はこんな感じ:

f:id:yamaimo0625:20190917121932p:plain

ちなみに、同人誌制作に限らずに一般のタスク管理に使えると思う。
それこそ普通の開発にも。
(その場合、リポジトリ所有のプロジェクトボードか組織所有のプロジェクトボードをチームで使い、加えて個人の雑多なタスクを個人所有のプロジェクトボードで管理する感じになるはず)

工夫したこと

実際に運用する中で、振り返りで気づいたことなどから以下のような工夫を行なってみた。

予定をノートで入れた

予定はカレンダーアプリで管理してるけど、プロジェクトボードにも追加するようにした。
これにより、

  • 週初めに今週の予定を確認する習慣がつく
  • 予定を考慮した計画を立てられる
  • いちいちカレンダーアプリを開かなくても今日の予定が分かる

というメリットが。

ノートにはURLなどもメモっておけるので、勉強会の場合はURLを貼っておけばプロジェクトボードから直接勉強会の詳細を確認しに行けて便利。

あと、途中からプールに泳ぎに行く予定もノートで追加しておくようにした。
するとToday列を見て「プール」とあるので「泳ぎに行かなきゃ」となるし、終わってDone列に移動すると一仕事終えた気分になるのでとてもいい。
ジムに行くとかそういう「やらなきゃいけないけどやらなくてもいい」系のものは、明示的なタスクにしてしまった方が続けられると思う。

週終わりの振り返り開始時間を書いた

週終わりの振り返りはノートにして計画していたのだけど、最初は「週終わり作業」とだけしていたので、ついつい気づいたら寝る時間になってて振り返りが出来ず、週の初めに起きてからやることが多かった。
そこで、「週終わり作業 21:00〜」と明示的にやる時間を決めて書いておくようにした。

これで21:00になったら「振り返りやらなきゃ」となって振り返りし忘れることがなくなった。

ノートにしたけどやり忘れるということが多い場合、この開始時間を決めて書いておくというのはいいと思った。

休息日を用意した

時間を好きに使えるので、ついつい頑張りすぎることが多かった。
療養中なので、体調の管理がけっこう重要なのに・・・
そこで意図的に休むように休息日を用意するようにした。

フリーランスとかだとこういった休みの管理も重要っぽい。
働きづくめでもパフォーマンス落ちるからね・・・
(とはいえ焦るんだよなぁ・・・)

以前、このブログでも紹介したHaLakeさんで作業を行なっていたのだけど、HaLakeさんは水曜日が定休日なので水曜日と日曜日は休息日として休むようにした。

とはいえやはり焦るので、水曜日は完全な休みではなく部屋の片付けをしたり本を読んで勉強したりするインプット日という扱いにしてみた。

まぁ、入稿直前は結局あまり休めなかったけど・・・

日付ノートを用意した

上記と関連して、日付を書いたノートを用意するようにした。
例えば「9/9 作業」とか「9/11 インプット」とか「9/15 休息」とか。

このノートの役割は3つ:

  1. その日が作業日なのかインプット日なのか休息日なのかを明示する
  2. 各タスクの見積もり時間と実績時間を記録する
  3. その日の振り返りを記録する

1.については前述した通り。

2.については、振り返りをするときにタスクを実施するのにどれくらい時間かかったのが分かった方がいいと思ったので途中から行うようにした。
昨日の記事の実績時間はこの記録がベースになっている。

プロジェクトボードの嬉しいことで、列を移動したりした時間はプロジェクトボードの"Menu"から"Activity"で確認できる。
なので、作業開始時にWorking列に移動しておけば、何時から始めたのかが分かるので記録は比較的簡単に出来る。
(あとで一気にやろうとすると大変なので、記録自体はその都度やっておいた方がいい)

3.については週終わりの振り返りをやろうとしたときにけっこう忘れてることが多かったので、その日のうちに軽く振り返りをしておいた方がいいと思って始めた。
週終わりの振り返りで日付ノートを見返すと「あーそういえば」となってよかった。

あと、副次的な効果で、日付ノートをDone列に移すことで「今日はこれでおしまい!」と区切りをつけれるようになったのがよかった。
それがないとダラダラと作業が続いてしまう感じがあったので。
それと、日付ノートの間に挟まったcloseになったタスクを見ることで、その日に終わらせたタスクの量が感覚的に分かるのもいい感じ。

これも出来たかも

他に、これも出来たかもという点に関して。

マイルストーンの活用

昨日も少し書いたけど、マイルストーンをもう少し使えればよかったかも。
初めてだったので締め切りがいつ頃だといいのか分からず、ちょっと使えなかった。

ラベルの活用

issueにはラベルをつけることが出来るのだけど、今回はちょっと使えなかった。

考えたいのが、大きすぎるタスクをどうするか。
issueに親子関係をつけたり出来れば分解したタスクを子タスクにすればいいんだけど、そういうことは出来ないはず・・・

今回は「タスク分解する」みたいなタスクを追加しておいて、分解した各issueを追加したらそのタスクはcloseするとしてたけど、ちょっと微妙な感じ。

Issueと一口に言っても実際にはいろんなレベルに分かれるので、ラベルを使うことでそういったレベルを分けられればよかったかなと思う。
まだうまくまとまってないし試せてもいないけど。

おそらく、ユーザ目線での価値単位であるFeatureやBugfixと開発者の作業単位であるTaskにラベルを使って分けて、前者はリリースと結びついたマイルストーンで管理し、後者はスプリントと結びついたプロジェクトボードで管理。
そして、それらの結びつけは一方のissueから他方のissueに言及しておこなう感じなのかな。
その作業コストがどんなもんかを確認してみないとだけど。


宣伝です。
気になった人はチェックをお願いします!

今日はここまで!

同人誌制作のスケジュールの振り返り。

f:id:yamaimo0625:20190916141434j:plain

昨日に引き続き、技術書典7で頒布する『Math Poker Girl』の作成に関する振り返り。

今日はスケジュールがどうだったのかについて。

概要

まず概要は以下:

日付・期間 内容 補足
7/10 当落通知
7/12 リポジトリ作成 Githubのプライベートリポジトリ
7/15 執筆開始
7/15〜7/23 はじめに、プロローグ 9P、構想や執筆環境の用意も実施
7/24〜8/1 第1章 40P、ポーカーのルール
8/2〜8/8 第2章 32P、オッズ計算
8/9〜8/11 奥付、各種デザイン  \TeXとの格闘
8/12〜8/24 研究(第3章)、表紙、エピローグ プログラム書いたり計算したり
8/25〜9/2 第3章 46P、ハンドレンジとポジション
9/3〜9/4 おわりに、トンボ、隠しノンブル 印刷用/電書用のMakeも用意
9/4 初稿完成
9/5〜9/6 赤入れ 見出し構造の修正、索引付けも
9/7〜9/9 赤入れの反映 背表紙の作成も
9/9 最終チェック
9/10 入稿 締切は9/11だった
9/10 電書版にリンクを追加 PDF内でジャンプ可能に
9/13 ダウンロードカード作成、入稿 締切は9/17だった

まずあらかじめ断っておくと、実は6月末に退職していて(退職エントリをちょっと書こうとしてやめた)、7月からは体調を整えつつ転職(or 独立?)のために療養&勉強中。
整体に行ったり泳ぎに行ったり、あるいはSleepTownの紹介記事を書いたりというのは、体調を直して回復するため。
あと技術書を書いてるのも勉強の一貫(タスクマネジメントとかマーケティングとか)。

なので、普通はフルタイムで働いて趣味の時間で執筆だと思うんだけど、自分の場合はフルタイム(といっても10時〜17時くらい)で執筆して夜は泳ぎに行ったり週2で休息したりという感じで進めていた。
(そうでもしないと普通はこのページ数書けないと思う・・・)
そういう意味で、普通とはちょっと違うかも。

あとちょっと特殊なこととして8/12〜8/24に研究をしてるんだけど、これはもう普通に数学の研究。
既存研究があるわけでもないので調査のためのフレームワーク(トイゲーム)を考えて実際に触れてみたりRubyでプログラム書いて調査したり数式をこねくり回したりして、意味ある結果が出るかどうか調べてた。
その結果をまとめたのが第3章になってて、技術書を書いてたというより論文を書いてた感じになってる。
(残った課題が確認問題になってるけど、先行研究として強化学習とこの本についてまとめてそれを調べれば学位論文くらいにはなるはず)

執筆のペース

こういうのは実績の把握が重要なので、wc -l -mでカウントして日数と比較すると、次のようになっていた:

内容 ページ数 行数 文字数 日数 ページ/日 行/日 文字数/日
第1章 40 1814 46,367 9 4.4 202 5,152
第2章 32 1360 34,237 7 4.6 194 4,891
第3章 46 2187 73,045 9 5.1 243 8,116

第3章のペースがいい感じに見えるけど、これは慣れてきたというより、表が多かったのが原因に思う。
なので、1日あたり4.5ページ、200行、5,000字くらいが今の自分の執筆速度っぽい。

うーん、でも実際にコミットしてたときの差分文字数はもう少しあったような・・・
もう少しちゃんとやるなら各コミットの差分を追わないとダメかもしれない。
あと、実際の作業時間の集計をとるとか。
(一応、大雑把な作業時間はとってある)

ただ、作業分量の見積もりに必要なのは最終的な数字で、今の数字だけでも、例えば100ページの本を作ろうと思うなら自分の場合は22日くらい、つまり3週間ちょっと必要そうだと分かる。

推敲・校正にかかった時間

今回めちゃくちゃ反省したのがコレ。
推敲・校正がめちゃくちゃツラかった

もうこんな推敲・校正は絶対したくない・・・

今回、印刷はねこのしっぽさんにお願いしたのだけど、116Pを超える場合は締め切りが約1週間早くなって9/11に。
そして、初稿が出来たのが9/4だったので、もう必死に赤入れとその反映、校正を行った。
これがツラいのなんのって・・・

間違い探しをするわけだから、もうひたすら集中し続けないとダメで、頭痛と肩こりがホントに酷いことになった。
療養とはなんだったのかとなるレベル。
まぁ、その分いい本に出来た自信はあるけど。

実績ベースの話をすると、9/5, 6の2日間で赤入れをやって、約150ページを約15時間かけている。
また、その赤入れの反映は9/7〜9の3日間でやっていて、約21時間かけている。
赤入れのペースは約10ページ/時、反映のペースは約7ページ/時。

まず、推敲・校正はめちゃくちゃ集中力・精神力・体力を削られるので、1日2〜3時間くらいまでにしておくべきだと思った。
今回は無茶し続けたので頭痛で死にそうになった。
ホントに無理。

そして実績ベースで考えるとチェックは10ページ/時、反映は7ページ/時なので、1日に出来るのはチェックで20〜30ページ/日、反映で14〜21ページ/日となる。
仮に100ページの本なら、チェックだけで3〜5日、反映で5〜7日くらいは見積もっておかないと死ねる。
執筆ペースを考えると100ページの本で22日くらいだったので、執筆:推敲で3:1〜2:1くらいの比率になるようにスケジュールを組んだ方がいいっぽい。

加えて今回失敗したのは、時間がなかったのでいろんな目的の推敲・校正をいっぺんにやったこと。
昨日の記事に書いた、

  • 読点の削除
  • 段落の改善
  • 不要な語句の削除
  • 索引付け

に加え、

  • 節を小節に分割して構造を修正
  • 誤字の修正
  • 数式のチェック

あたりも一緒に進めていたので、かなり大変だった。

このへんは時間がなくて一緒にやらざるを得なかった感じなので、余裕を持って何回かに分割してやった方がいい
(『数学文章作法』でいう「ローラー作戦」ではなく「フェーズ作戦」を使う)

締め切りからの逆算

ということで、約100ページの本を作る場合、締め切りから逆算して次のようなスケジュールにした方がよさそうだった:

内容 備考 相対日数
イベント当日 -0
入稿締め切り 1週間〜2週間前 -14
推敲・校正 約2週間(稼働率25%〜40%) -28 〜 -14
初稿締め切り -28
執筆 約4週間(稼働率100%) -56 〜 -28
執筆開始 -56

(執筆は少し余裕を追加して3週間ではなく4習慣としている)

執筆、推敲・校正の期間については、約50ページなら半分、約150ページなら1.5倍、約200ページなら2倍といった感じ。
次回以降の参考にしたい。

(こういう実績ベースの見積もり、重要だよね・・・ちなみに、次に参加するつもりの第29回文学フリマ東京は11/24なので約10週後でもう動き始めないとw)

レビュー

そういえばレビューを依頼しなかった。
これは原稿が出来上がるのがギリギリになるだろうと予想してたからと、適切なレビューアが思い浮かばなかったから・・・

もし今後依頼するなら、さらに余裕あるスケジュールを組まないとダメそう。
(みんなよくフルタイムで働いて原稿書いてさらにはレビューとかまでお願いする時間を確保できるよなぁと感心する)

マイルストーン

今回、リポジトリGithubにプライベートリポジトリを作り、Github Projectsでのタスク管理を試してみたのだけど、マイルストーン機能は使わなかった。
ただ、今回の実績で初稿の締め切りをいつぐらいにすべきかは分かったので、次はマイルストーン機能を使ってみてもいいかなと思っている。


宣伝です。
気になった人はチェックをお願いします!

今日はここまで!

同人誌の執筆(文章作成・推敲)で気づいたこと。

f:id:yamaimo0625:20190430184014j:plain

昨日に引き続き、技術書典7で頒布する『Math Poker Girl』の作成に関する振り返り。

今日は執筆する中で気づいたことについて。

  • 読点の打ち方
  • 段落の分け方
  • 不要な語句の削除
  • 索引の入れ方

うわっ・・・私の読点、多すぎ・・・?

自覚なかったんだけど、自分、めちゃくちゃ読点を打つ癖があった。

意味をおかしくしないという意味では読点は打った方がいいし、実際に声に出して読むと読点がそれなりに入ってた方が息苦しくならなくていいんだけど、ちょっと入れすぎかなということに気づいた。

読点って思った以上に入れなくても読むときは不自然に感じない。

むしろ入れすぎると文が区切れすぎて読むのがつっかえつっかえな感じになる。
読点をなくすと文章が流れるようになって、読者はその方が気持ちよく読めると思う。
(もちろん、つっかえさせるためにあえて読点を入れるテクニックはある)

例えば、推敲前の文章がこれ:

「確か、お互いに手札が何枚か配られて、お金を賭け合うんだっけ。 手札が弱くても、相手を降ろせば勝ちなんでしょ?  あとは、手札を交換していたかも。 そして、お互いに降りなければ手札を公開して、強い方の勝ち」

問題はないし、切れるべきところで切れているようにも見える。
けど、ここから読点を大量虐殺した結果がこれ:

「確かお互いに手札が何枚か配られてお金を賭け合うんだっけ。 手札が弱くても相手を降ろせば勝ちなんでしょ?  あとは手札を交換していたかも。 そして、お互いに降りなければ手札を公開して強い方の勝ち」

すっごく滑らかに読める!
そして、別に意味がおかしくなってたりはしない。
むしろ、後者を読んでから前者を読むと、すごくつっかえつっかえに感じる・・・

ちょっと悩ましいのは、接続詞の後の読点を入れるかどうか。
書くときってどうしても接続詞を書いたあとに一呼吸入れるので、そこで読点を打ってしまうんだけど(「そして、」とか「むしろ、」とか)、実際には入れなくても読める場合が多い。

例えば、(←とこの読点もそうなんだけど)推敲前だと

「もちろん、J、Q、K、Aも使える。 例えば、以下のようなのもストレートだ」

だったけど、読点を削った結果は

「もちろんJ、Q、K、Aも使える。 例えばこんなのもストレートだ」

と読点がなくても全然問題ないし、むしろスッキリして読んでて気持ちいい。

もう癖になってて直すのがかなり難しくも感じてるんだけど、基本的には読点は打たず、読んでみて意味がおかしくなるところにだけ打つようにした方がよさそう。

あと、区切りの助詞の代わりに読点を入れているケースがけっこうあったので、そういう場合は助詞を使うことで読点を削除できる。
これは好みの問題もあるので難しいところだけど。

(before)

「その場合、その全員が勝者だ。ポットは山分けすることになる」

(after)

「その場合はその全員が勝者だ。ポットは山分けすることになる」

他、文が長くなりすぎている場合があるので、そういうときは読点を削除して文を分けた方がいいし、なんなら語順を入れ替えるというのも有効と言える。

↑ この文自体「他にも文が長くなりすぎている場合がある。そういうときは読点を削除して文を分けた方がいい。語順を入れ替えるのも有効と言える」と3つに区切った方がいいとかね。

段落の分け方

段落の分け方なんて普段あまり悩まないんだけど、今回は小説だったのでかなり悩んだ。
というのも、小説って思った以上に段落が分かれてる

もちろん、長い地の文ならあまり困らない。
それは普通の文章とあまり変わらないから、普段と同じように分ければいい。

困るのは、会話文が続く間に挟まる短い地の文の集まり。
文としては2つか3つなんだけど、これを段落に分けるべきか否か。
数が少ないので段落を分ける意味があまりないといえばその通りなんだけど、段落を分けた方が自然だと感じることも少なくなかった。

その中で気づいたのが、地の文も種類がいくつかに分けられるということ。
具体的には、以下の3種類:

  1. 三人称視点での場面の描画。(そこに何があるのかとか、誰が何をやったとか)
  2. 一人称視点での場面の描画。(その場面での一人称の人物から何が見えたのかや、その人が何をやったのか)
  3. 一人称視点での心情の描画。(その場面での一人称の人物が何を思ったのか)

そして、地の文の種類が変わったら段落を変えるというのを目安にするとよさそうだと思った。
あと、種類が同じでも主語が変わったときはときは段落を変える方がよさそう。
完全にそうとは言いきれないんだけど・・・

例えば、推敲前だと

 次の休日、ボクが駅前でフィネスを待っていると、彼女はほどなくやってきた。
 今日は彼女にポーカーのルールを教えてもらうことになっていたのだ。
「やぁ、おはよう、ヒロアキ
「おはよう、師匠」
 ボクは言われた通り、彼女のことを師匠と呼んだ。途端に上機嫌になるフィネス。
「うんうん、いいねぇ、我が弟子!」

推敲後は

 次の休日、ボクが駅前でフィネスを待っていると彼女はほどなくやってきた。 今日は彼女にポーカーのルールを教えてもらうことになっているのだ。
「やぁ、おはよう、ヒロアキ
「おはよう、師匠」
 ボクは言われた通り彼女のことを師匠と呼んだ。
 途端に上機嫌になるフィネス。
「うんうん、いいねぇ、我が弟子!」

で、推敲後の方がよくなってるはず。
はず・・・(感覚的なので難しい)

コメントを追加すると以下のような感じ:

 次の休日、ボクが駅前でフィネスを待っていると彼女はほどなくやってきた。 今日は彼女にポーカーのルールを教えてもらうことになっているのだ。三人称での場面・事実の記述
「やぁ、おはよう、ヒロアキ
「おはよう、師匠」
 ボクは言われた通り彼女のことを師匠と呼んだ。一人称での行動の記述;動作の主語はボク
 途端に上機嫌になるフィネス。一人称からみた場面の記述;動作の主語はフィネス
「うんうん、いいねぇ、我が弟子!」

いや、微妙で難しいんだけどね。

不要な語句を使ってしまうということが多いということ

・・・というふうに(これは極端だけど)「という」とか「こと」をついつい入れてしまうことが多かった。
読んでみてもあまり違和感は感じないんだけど、こういうのはバッサリと切ってしまった方がいい。

(Bad) 不要な語句を使ってしまうということが多いということ
 ↓
(Good) 不要な語句を使ってしまうことが多い

上記の「読んでみても・・・」の文も、読み返すと「〜してみる」とか「〜なんだ」はなくていい。

(Bad) 読んでみてもあまり違和感は感じないんだけど、こういうのはバッサリと切ってしまった方がいい。
 ↓
(Good) 読んでもあまり違和感は感じないけど、こういうのはバッサリ切った方がいい。

なお、書いてるときはどうしてもこういうクッションを入れてしまうので、入れないように注意しながら書いていくのはなかなか大変・・・
それで書くペースが落ちてもよくないし。

なので、書くときに意識するというよりかは、推敲時のレビュー観点の一つとして不要語句の削除を意識する方が効率的だと思う。

この単語、索引に追加すべきかどうか・・・

索引が必要な文章を初めて作ったので、どの単語を索引から辿れるようにすべきかでかなり悩んだ。

ちょっとややこしいんだけど、ここで悩んだというのは「索引に載せる単語」をどれにすべきかではなく(それは簡単に分かる)、「索引に載せるべき単語」から参照される単語をどれにすべきかということ。

例えば、「スモールブラインド」という単語(専門用語)を索引に載せるべきというのはすぐに分かるんだけど、じゃあスモールブラインドという単語が出てくるページをすべて索引から辿れるようにすべきかというとそうではなくて、辿れるようにすべきものとそうでないものがある。

「そして最初にアクションするプレイヤーをスモールブラインド(Small blind)と呼び、次にアクションするプレイヤーをビッグブラインド(Big blind)と呼ぶ」

は索引から辿れた方がいいけど、

「スモールブラインドから順に残っている誰もがベットしないでチェックし続け、ボタンまで周ればそのフェーズは終了だ」

は索引から辿れた方がいいかというとちょっと違う。

これに関しては、単語が「説明される対象」なのか「説明に使われているだけ」なのかを考えるといいと思った。
そして前者の場合だけ索引に追加する。

なぜかというと、読者が索引を見るのは「あれ? この単語の意味、なんだっけ?」というときだから。
そのときに見たいのは単語の説明が書かれている前者であって、その単語がどう使われているのかという後者ではない。

プログラムでの関数定義と呼び出しをイメージすると分かりやすいかも。
ユーザが索引を見るのは、関数呼び出しを見て「この関数の定義ってどんなだっけ?」というとき。
なので、索引から辿れるべきは関数呼び出しをしている箇所ではなく、関数定義をしている箇所。

さっきのスモールブラインドの例だとまさにそうなっていて、前者はスモールブラインドという単語の説明をしているので索引から辿れるべきだけど、後者はフェーズの終了条件の説明で、スモールブラインドという単語はそのために使われているだけだから索引から辿れるべきではない。

ただし、ちょっと例外があって、普通の用語を専門用語ではこう言うと説明している場合、その普通の用語も索引から辿れるようにした方がいいと思った。

例えば、

「そこでブラインド(Blind)という強制ベットがあるんだよ」

という文の場合、説明対象は「ブラインド」で「強制ベット」は説明に使われている言葉なんだけど、強制ベットも索引から辿れた方がいい。
なぜなら「あれ? あの言葉って専門用語だと何て言うんだっけ?」というケースがあるから。
なのでそう言う場合だけ例外的に索引に追加する。


あと、結城浩先生の『数学文章作法』はやはりおさえておいた方がいいと思った。

読み返してみたけど、不要な語句を削るべきという話や索引についても書かれていて、改めて勉強になった。
オススメ。


宣伝です。
気になった人はチェックをお願いします!

今日はここまで!

同人誌のテーマ選びの話。(書きたいこと vs 読みたいこと)

9/22(日)に技術書典7にサークル参加するので、それに向けて同人誌を作った。
まだ完成品を見てはいないけど、入稿も無事終わって一段落といったところ。

今回、初めてのことや考えたことがいろいろあったので、そういった振り返りを少しやっていきたいと思う。
まずテーマ選びに関して。

その同人誌を読みたい人はいるのか?

さて、同人誌を出したいというからには、何か書きたい/伝えたいことがあるというのは疑いないと思う。
ただ問題となるのはそれを読みたい人/知りたい人はいるのかということ。

例えば、技術書典とは関係ないんだけど、次のようなツイートを見かけた。

つまり「プロは読者の読みたいことを優先して自分の書きたいことは書かない」という意見に対して、「プロは読者の読みたいことを書くのは当然としてなんとか自分の書きたいことも捻り込むものだ」という主張といえる。

この主張は個人的には正しいと思うけど、今の議論ではあまり重要ではなくて、「読者の読みたいこと」と「著者の書きたいこと」の2軸が存在することが重要。

読みたいこと vs 書きたいこと

この2軸を図にするとこうなる:

f:id:yamaimo0625:20190914114106p:plain

分かりやすいのは「読者も読みたいし著者も書きたい」領域と「読者も読みたくないし著者も書きたくない」領域。
前者は書けばいいし、後者は書かなければいい。
問題となるのは「読者は読みたいけど著者は書きたくない(読者優先)」領域と「著者は書きたいけど読者は読みたくない(著者優先)」領域をどう扱うべきか

このギャップ領域がほとんどなければ幸せで何も考えなくていいんだけど、大きい場合はいろいろ考えないといけない。
はてさて、どうすべきなのか?

「読者優先」と言い切れない理由

ここで「それは当然『読者優先』の一択でしょ」となりそうなんだけど、そう言い切れないのが難しいところ。

著者は書きたいことがあるから書いているわけで、書きたいことが書けないなら何のために書いてるのか分からなくなる
このモチベーションの問題は大きい。

一方で、モチベーションに関しては別の問題もあって、せっかく書いたのに売れないと何のために書いたのか分からなくなる

もちろん、リソース(執筆時間&ページ数)がいくらでもあるなら全部書けばいいんだけど、そうでないときはこの2つはジレンマとなって立ちふさがってくる。
そして、前者を優先するなら著者優先になるし、後者を優先するなら読者優先になる。

レーゾンデートル(存在理由)

基本的には読者を優先すべきだと思うけど、この文章を書きながら少し考えが変わってきた。

やっぱり書きたいことは何がなんでも捻じ込まないとダメだ。

なぜかというと、そうしないと「その同人誌が存在する理由」つまりレーゾンデートルが存在しないから。
自分が書きたかったことが書かれてない同人誌なら、それは自分が書く必要は何もない。
他の人が書けばいい。
けど、そうではないわけで。
なので、何がなんでも書きたいことは入れないとダメ。

もちろんその度合いはあって、ここでの主張は「読者:著者=100:0」にするのだけはダメというもの。
また「読者:著者=0:100」にしろという主張でもない。

例えば、読者の読みたい(けど著者は書きたくない)ことが100あって、著者の書きたい(けど読者は読みたくない)ことも100あって、リソース的に50しか書けないとなったとき、「読みたいこと」を50書いて「書きたいこと」を0にするのだけは絶対にダメ。
そして「読みたいこと」を0にして「書きたいこと」を50書けと言っているわけでもない。
読者を優先するなら「読みたいこと」を40「書きたいこと」を10書くとかがいいだろうし、どうしても書きたいんだというなら「書きたいこと」を50書いてもいいと思う(ただしその場合はたくさん売るのは諦める)。

価値を提供する

とはいえ、読者を大切にするのを忘れてはダメで。

何でもいいからちゃんと価値を提供すること。

これ大事。
いろんなところで言われてるから、自分が改めて書くことでもないけど。

なので、以下のようにするのがいいと思う:

  1. 基本的は読者の読みたいことを書く。
  2. けど、自分の書きたいことを何がなんでも捻り込む
    それが出来ないならその本を書く意味はない。

そして、この観点で結城浩先生の『数学ガール』を見返すと、面白いことに気づく。

数学ガール』の内容は主に前半と後半に分けることが出来て、前半は後半で必要になる内容、後半は本のサブタイトルの内容(フェルマーの定理とか乱択アルゴリズムとか)となっている。
これは、前半は基本的な内容を伝えていて多くの人に価値を提供していて、後半はけっこう難しいので全員が読めるわけではないけど、サブタイトルにしてるくらいで結城先生が書きたかったことなんだろうと推測できる。
こんな感じで、多くの人に価値を提供する→書きたいことを書いて刺さる人には刺さる、というのがいいんだと思う。
(まぁ、結城先生にとっては前半の内容は別に書きたくないことではないだろうけど)

そもそも読者は読みたいものを知っているのか

他に考えておきたいのがそもそも読者は読みたいものを知っているのか

当たり前なんだけど存在を知らないものは知りたいと思うことがまず不可能
存在を知って初めて知りたいと思える。

つまり、次の3つのステージがある。

  1. そもそも存在を知らない
  2. 存在は知ってるけど詳しくは知らない
  3. ある程度知っていてより深く知りたい

そして読者が読みたいと思うのは2.か3.になったもの。
2.なら入門書、3.なら応用書を手に取ることになる。
けど、1.の状態ではそもそも読者が手に取らないーーというか取れない。

そして読者のほとんどが1.の状態ならそもそも読者が読みたいものが存在しない
存在しないんだから、読者の読みたいものを書くということ自体が出来ない。
なのでそれが読者の読みたいものなんだと気づかせる必要があるとなってくる。

自分の場合、『哲学散歩道』で書いた身体性の議論とかはかなりそういう面が・・・
今回書いた『Math Poker Girl』でもあとがきで「ソクラテスってこんな気分だったのかな」と書いたのだけど、分かってないことを分かってないと、そもそも分かりたいと思わないというか・・・

この先、Lucid本も書きたいと思ってるけど、Lucid本もそうなんだよなぁ・・・
なんでこうもアーリーアダプターのさらに前でばっかり本を書いてるんだろう(^^;
あっ、気づいてる人が他にいなそうだから伝えたいと思うのが原因か。。。

読者は1人だけじゃない

あともう一つ考えておきたいのが、読者は1人だけじゃないということ。
読者にだって多様性がある。
多くの人には刺さらなくったって、刺さる人がいるならその人のために書くというのは全然ありだと思う。

多くは売れないと思うけど、心を強く持って・・・(自分への励まし)

ニッチ本の生存戦略

そういったニッチ本の場合、普通にやってると継続的な活動は出来ないと思う。

  • 売れなくて心が折れる
  • 印刷にかかった費用や諸経費を回収できない

なので、少し特殊な生存戦略を考える必要がありそう。

需要を喚起する

「なぜこれがあなたに必要なのか」を強く訴える必要がある。

読者はそれが自分に必要なものだということにまず気づけていない。
そういった読者に刺さるようなアピールをして少しでも需要を喚起しないとダメ。

例えば、自分の『哲学散歩道』は、構成として最高のものになっていると思っているけど、それは「普通の本」ならの話。
ニッチ本だと構成が美しいだけだと生きていけない。
タイトルから変えて、構成もより多くの人に「これはあなたに必要な本なんだ」と伝わる形にしないとダメ。

あと、煽りの付け方を工夫するとか露出を増やして認知してもらう機会を増やすとかいった努力が不可欠。

価値の提供を忘れない

最低限、一つだけでもいいから、何か読んだ人に価値を提供する。
そうすれば「読んだけど何の役にも立たなかった」というのだけは避けられる。
これは読んでくれた人への礼儀というもの。

値段を少し高くする

刺さる人が少ないなら、値段を高くして回収できる費用を大きくするのも手だと思う。
刺さる人は値段が少し高くても買ってくれると信じて。

売れて欲しいからと値段を下げるのはダメだと思う。

ーーいや、売れないの嫌だから、めっちゃ値段下げたいんだけどね!
今でも値段下げるべきかめっちゃ悩んでるけどね!!

でも、値段下げたら買ってくれるような人は、そもそも読んでもあまり面白いと思ってくれない。
逆に、読んで面白いと思ってくれる人は、値段が少し高くても買ってくれる(はず)。

それなら値段を少し高くしても、本当に欲しいと思ってくれる人にちゃんと届けて、自分も次の活動に向けてちゃんとお金を得る方がいいと思う。

「安さが理由なら買うべきではない」とよく言われるけど、その裏として「安さを理由として売るべきではない」も正しいと思う。
安かったから売れたというのではなく、買ってくれた人にとって価値があったから売れたとなるようにしないと。

『Math Poker Girl』に関して

さて、今回の『Math Poker Girl』に関しては、自分が書きたいことを書いている中で、読者が読みたいだろうことからめちゃくちゃ乖離してることに気づいてめちゃくちゃ悩んだ。

たぶん読者が一番望んでるのは「数学的にこうすればいいよ」という安直な結論。

対して、自分が書いてて至った結論は「世間で一般的にこうすればいいと言われてるけど、数学的に検討するとその主張には根拠がないよ」ということ。
定性的にはある程度正しいことまでは示せたんだけど(これ自体おそらく世界初の仕事)、定量的に正しいことまでは言えなかった(し、おそらく正しくない)。

読者は「安直な結論」を望んでいて、自分は「安直な結論なんかない」ことを書きたいとき、どうする???

どうしたものかと悩んだけど、自分に嘘はつけないということでそのまま書いてる。
いろいろ耐えられずに言い訳じみた節をつけたくらい・・・
(自分の書いたキャラの赦しの言葉に思わず泣きそうになった)

とはいえ、きっと数学の議論の部分が刺さる読者もいると思う。
たぶん。
そういう人に届いてくれればと思う。


というわけで、宣伝。
気になった人はチェックをつけてもらえると自分が喜びますm(_ _)m

今日はここまで!

睡眠リズムアプリ「SleepTown」を使ってみた。

毎日を健康に過ごすには、規則正しい睡眠が必須。
けど、意志の力だけでは誘惑も多く、なかなか上手くいかないもの・・・

そんなときは「仕組みの力」を使うのが一番。
ゲーム感覚で睡眠リズムを作っていけるアプリ「SleepTown」を使ってみた。

SleepTown

SleepTown

  • SEEKRTECH CO., LTD.
  • ヘルスケア/フィットネス
  • ¥240

概要

「SleepTown」は規則正しい睡眠リズムを作ることで街を作り上げていくアプリ。
ゲーム感覚で取り組めるので、楽しみながら睡眠リズムを整えることができる。

f:id:yamaimo0625:20190912143320p:plain
街が作られていく

使い方

ダウンロードして起動したらやるのは「就寝目標」と「起床目標」の設定。
このアプリでは「就寝目標」の2時間前までに寝て「起床目標」の10分後までに起きると街に新しい建物が作られる。

寝る準備が出来たらこのアプリを開き「就寝」ボタンを押す。
すると建設が始まるのでそのまま睡眠へ。

f:id:yamaimo0625:20190913083926p:plain
建設中・・・

そして、起きたら「起床」ボタンを押す。
ちゃんと起床目標の10分後までに起きれれば建物が完成する。

f:id:yamaimo0625:20190913083950p:plain
完成!

毎日コツコツと達成していくと、街が発展していく様子が見れる。

f:id:yamaimo0625:20190912144323p:plain
街と睡眠リズムの様子

あっ、手前で一つ建物が壊れてるけど、これは起きるのに失敗したヤツw
こうなると残念なので、そうならないように頑張るw

建設に失敗するパターン

建設に失敗するパターンは、次の3つ:

  • 就寝目標の時間までに「就寝」ボタンを押せなかった(建設が始まらない)
  • 「就寝」ボタンを押したあとに他のアプリを使ったりこのアプリを終了する(建物が壊れる)
  • 起床目標の10分後までに「起床」ボタンを押せなかった(建物が壊れる)

f:id:yamaimo0625:20190912144546p:plain
悲しい・・・

アラームの設定

起床に関してアラームの設定が可能で、音楽も自分の好きなものを選ぶことが出来る。
もちろんマナーモードにしていてもちゃんと鳴るので安心。

f:id:yamaimo0625:20190912145238p:plain
アラーム設定

デフォルト曲も爽やかな感じでいいんだけど、自分は朝の音楽というとベートヴェンの第6のイメージが強いので第6にしてるw

その他

設定で就寝リマインダーを15分前に入れることも可能。
ミスを減らせる。

あと、設定でシェイクチャレンジというのを有効に出来る。
これは「起床」ボタンを押したあとにスマホをフリフリする設定で、しっかり振らないと起きた認定されなくなる。
「目覚ましだけ止めて起きなかった・・・」というのを予防できるし、腕を振るのが覚醒に繋がっていい感じ。

f:id:yamaimo0625:20190913084023p:plain
シェイク!

他、モチベを維持するためにアチーブメントやサークルがある。

実際に使ってみて

当たり前なんだけど、早く起きるためには早く寝る必要がある。
なので、早く寝るモチベを維持できるアプリを探してて見つけたのがこのアプリ。

実際に使ってみると、就寝目標の時間近くになるとソワソワしてくるwww

まだいろいろやりたいという思いはありつつも、「就寝」ボタンを押しはぐって建設開始できないと「もったいない」感じがするし、せっかく「就寝」ボタンを押しても起きないと建設に失敗してしまうのでやはり「もったいない」気がしてちゃんと起きるw
ボタンを押しはぐったときの悔しさは異常w

こうやって書いてて気づいたけど、寝なきゃいけないのになかなか寝れない理由の一つとして「寝るのがもったいない」という「もったいなさ」があると思うので、そういう貧乏性の人には逆にこのアプリがピッタリなのかもしれない。

そして、ちゃんと早く寝ればちゃんと朝起きられるのは道理。
疲れが溜まって起きるのに失敗したのが数回あったけど、それ以外はちゃんと起きられているのでとてもいいと思う。

というわけで、規則正しい睡眠リズムを作りたい人にはめちゃくちゃオススメ。

今日はここまで!

SleepTown

SleepTown

  • SEEKRTECH CO., LTD.
  • ヘルスケア/フィットネス
  • ¥240