(レビュー用非公開プロジェクトからのコピペ。2017-05-18)

悩んでいるのでScrapboxのベストプラクティスに従ってまずは箇条書きで書き出してみました。

今の書籍レビュー

プロセス

西尾が原稿を『読める形』にする

レビュワーがそれを読んでメールなどの方法でレビューを返す

西尾がレビューコメントを踏まえて原稿をブラッシュアップする

レビュワーにとって「本を読んで感想を言う」という活動になるのでやりやすい

西尾にとってレビュワーの意見が独立であると仮定できる

「複数人が近いことを言う」や「2人が逆のことを言う」などの情報が得られる。

わかりやすい本を書くという評判と実績のある結城浩さんの方法論を真似している

Scrapboxを活用する案

プロセス

西尾が『読める形』になる前の断片をScrapboxに入れる

西尾＋レビュワーが、直接いじる(発散プロセス)

西尾が適当なタイミングで文章化(収束プロセス)を走らせ、書籍として『読める形』にする。

その後上記のレビュープロセス

発散プロセスは無限に時間を吸う危険性がある(収拾つかなくなる、というやつ)

レビュワーは「僕の本の構成を考えること」にはさほど興味が無いのでは？

そもそも書籍の企画を通す段階で目次案は構造化済み

自分の案の中からも色々泣く泣く切り捨てた部分がある

今から再度発散フェーズが走っても大部分は枠に収まらないのでは。

でも、別冊を別途出しても良いし、オンラインで読めるようにしても良い

コラムとして追加する案も

レビュワーには多人数・リモート・時間非同期での情報断片の構造化をする、という作業が求められる

これ1人でやってても大変

KJ法に不慣れな人に僕はいきなり多人数でのKJ法をやらないように指導している

他人の書いた断片は理解が困難で、その苦しみが派生してそのプロジェクト自体やKJ法自体を嫌いになる

Scrapboxを活用している人の使用例を見ていると、わからなかったらわからないってその場でコメントしてる風

何か面白いことが起こるかもしれない

セレンディピティは事前に予測できない

断片を入れていく作業が単純に西尾の負担増になる

3週間で1章書くペースはレビュー対応コストを計算に入れずに決めてしまったので…。

負担の総量が読めない

「最初からたくさんやろうとしない」が大事かも

例えば「そもそも著者が考える知的生産とは？」との質問を受けて手元で書いた文章とか、まとまってないのでレビュワーにシェアしてなかったけど、そういうもの。

読者に"キチンと系統立った知識というよりいろいろな情報の寄せ集め"とか言われてしまうリスクがある

書籍にする上では情報を「整理」する必要がある

仮に共同編集するとしたらどうやる？

レビュワーにアイコンを作ってもらう: nishioみたいに自分のIDのページを作る

箇条書きをツリー掲示板のように使う

文章にCtrl-iでアイコンをつけることで地の文と自分の意見を区別する

こんな風に

「第X章～」のページは共同編集しない

1人の著者が書いている「普通の原稿」として読んでレビューしたい人のために

その他のページは自由に編集できる

特にツリー掲示板のようにコメントや質問を書くなど

レビュワーは作りたければ新しいページを作っても良い

タイトルに質問文を書いて本文が空でもよい