技術書のレビューの経験則

出版される前の本の内容は、通常は著者や編集者に代表される「制作サイド」の人間にしか読まれない。 専門性の高い本であれば査読とか監修といったプロセスを有識者にお願いすることはあるけど、そうしたお願いをするときには有償だったりカバーや袖に名前を出したりすることが多いので、これも「制作サイド」の一部とみなしていいだろう。 一方、基本的に無償で、完成した書籍の献本と謝辞への掲載くらいを前提に、あくまでもベストエフォートで発行前の本の内容を見てくださいというお願いを第三者にすることもある。 この場合の第三者というのは、制作中の書籍の想定読者だったり、出版後の書籍を対象読者へ紹介してくれそうな立場の人だったりする。 このようなプロセスを制作に取り入れる習慣は、とくにここ数年のIT系の出版社ではめずらしくなくて、界隈では「レビュー」などと呼ばれている。 というわけで、技術書の制作における「レビュー」につ

[kmizushima]

技術書のレビューをする側に回ることは多いのだけど、ついミクロなところに目がいってしまいがちな自覚があるので、気を付けたい。

[sh19910711]

"レビューで何を見るべきかを要約するのは難しいけど、がんばって見てはいけない / 何に気付くかは「何に気付こうと思って読んでいるか」に多分に影響 / レビューの主眼は、あくまでも第三者の目を取り入れること" / 2018

[pho]

重箱の隅ではなくマクロな指摘というのは確かにそうだな。

[mas-higa]

"本の表現に対して調整を要求する場ではない" チームから文書を出すときにも思い当たる。だったらオマエが書けよと。書き手が独裁者になれない立場だとつらい。

[note103]

この辺の話をする際の基準になりそうなすごい内容でさすがです。

[turu_crane]

技術書に限らずミクロな視点に陥りやすいの気をつけたい

[chezou]

社内のドキュメントやblogなんかだったり、OSSのデザインドキュメントとかだとGoogle Docs使うことが多いかな。任意の範囲で指摘をして議論ができるので

[ryuzee]

どっちの立場も機会が多いので参考にしよっと

[braitom]

技術書のレビューだけでなく調査レポートとかそういう技術系のドキュメントのレビューの時にも使えそうな内容だ。

[yujiorama]

こんなにちゃんと考えたことなかった。校正ボランティア、じゃなくてマクロな指摘をする

[efcl]

技術書のレビューについて。これは完成品ドラフトの査読っぽい

[JunichiIto]

今度レビューが必要になったときに参考にさせてもらいます！

[seiunsky]

Dropboxにそういう機能があるのかー

[golden-lucky]

書きました