技術書のレビューとは
技術同人誌、商業誌関わらず、出版前の原稿を読んで改善点をフィードバックする仕事がレビューです。
商業誌の場合は出版社の編集も入るため、誤字脱字よりかはエンジニア視点での言葉の伝わりやすさや、間違いがないかなどをフィードバックすることが大きな目的となります。
翻訳の場合は原文の英語の意図と日本語のニュアンスが合っているかみることもありますが、基本的な期待としては日本語の表現に主眼が置かれていることが多いと感じています。
企画から出版までの大まかな流れは以下のnoteがわかりやすかったです。
私の記事では校正フェーズの出版社の校正の手前の技術者のレビューを取り扱います。
私も過去いくつかの技術書のレビューに参加していますが、その中で気付いたことや面白さをお伝えできればと思います。
レビューに参加した技術書
- ドメイン駆動設計 サンプルコード&FAQ
- アジャイルプラクティスガイドブック チームで成果を出すための開発技術の実践知
- エンジニアリングマネージャーのしごと ― チームが必要とするマネージャーになる方法
- スタッフエンジニアの道 ― 優れた技術専門職になるためのガイド
どうやってレビューに参加するのか
これは著者や訳者によってさまざまですが、最近はSNSでレビュワーを募集しているケースが増えてきています。
しかしながら、レビュー自体が書籍のクオリティを上げるために実施するものなので、誰でもいいから見てほしいというものではないという側面もあります。
具体的な流れとしては、募集情報をみつけて応募後、原稿のリポジトリの招待もしくはメールでの通知をもってレビュー参加が決定するという流れが一般的です。応募の際には書籍の内容について自身が経験してきたことなど、レビューに貢献できるケイパビリティがあることをアピールするとよいでしょう。
↑のようにオープンに募集しているケースもあれば、コミュニティ繋がりでもう少しクローズドに募集しているケースもあります。技術同人誌の場合は著者が知り合いに直接レビューを依頼していることもあります。
いずれにせよ、コミュニティでの活動を増やしていくとレビューに参加できる接点、機会も増やすことができます。
レビューの流れ
Dropboxなどのドライブを介して原稿のチェックとコメントを残すやり方や、最近は原稿含めてリポジトリで管理し、CIによって修正版のPDFのArtifactsまで生成されるよう準備されているケースもあります。そのようなケースでは基本的にイシューベースで管理していくので、通常の開発業務と近い感覚で参加できます。
翻訳のケースですが、訳者視点の環境構築に関する資料としては以下がわかりやすいです。
レビューが始まると、期限までに原稿を読んでコメント・Issue作成をしていきます。著者・訳者にもよりますが、5割〜7割くらいを最低でも読んでほしいという方が多いと思います。
全員最初から読むとレビューが最初の章に集中し、後半のレビューが薄くなってしまうため、後半から読むことも実は価値があります。（自分はこの進め方をすることが多い）
レビュワーが意識できるとよさそうなこと
個人的に心がけていることとして、率直な気持ち・目線で読んで感じた第一印象を書き残して、改善に繋がりそうなものを整理してフィードバックすることを心がけています。本を読む時に、読みやすい本と読みにくい本にそれぞれ出会ったことがある方もいるのではないかと思いますが、読みにくい本というのは何かしらその要因があるのではないかと思います。
たとえば、
- 前後の文章の接続が自然ではない繋がりになっている
- 機械的な文章になっている
- 一般的ではない用語が用いられている
などです。最初にひっかかったポイントになぜひっかかったのか？を考えてみるとその原因がわかることもあるので、なるべく第一印象とそう感じた理由をセットにしてフィードバックすることを心がけています。
書籍はいろいろなコンテキストの人が読むものですので、すべての人にわかりやすくすることは難しいと思いますが、著者・訳者にとってはレビュワーの第一印象から、「そういう解釈もあるのか！」→「そこは修正します」or「今回はそのままで行きます」というような判断ができると価値があるのではないかと考えています。
レビューで得られるもの
直接的な謝礼と副次的な貢献感
直接的な謝礼としては、見本誌の送付と巻末の謝辞に名前を記載してもらえる、という形式がほとんどかと思います。
また、副次的なものとしては、コードと違い、物理的に自分の名前が載っているものが世の中に存在しているという感覚は個人的にはとても貢献感の得られるものだと感じます。
また、本業がある中で原稿を読んでフィードバックするという活動はそれなりに大変ではありますが、微力ながらいいものを世の中に送り出そうとしている一体感を得られるのはレビューならではかと思います。
原稿をいち早く読める
まだ世に出る前の原稿を読めることは、世の中のトレンドにいち早く触れることにもなり、自身の情報の感度を高めることにつながると感じています。
また、どんな素晴らしい書籍も元となる原稿があり、そこからたくさんのブラッシュアップを経て素晴らしい内容になっていくという、言葉にすると当たり前ですがその地道なプロセスを知ることができます。
他者のフィードバックを知ることができる
最も価値があるのはこの点かもしれません。開発業務の中でも他者が鋭いコメントをしているのを目の当たりにして「すごい、この視点は自分にはなかった！」と感じたことがあるのではないでしょうか？
レビューでもこのような体験をすることがあります。さまざまな有識者の深い造詣に触れられることはとても刺激的です。そして、このプロセス・やりとりは発売後の書籍からは見えません。
レビューで使用されるリポジトリは一時的なもので、レビュー期間が終了すると見えなくなってしまいますが、このプロセスをみることができる点がレビューで一番面白いところだと感じています。
最後に
私はOSSのコードを書くことはあまりないですが、このようなレビューという取り組みもソフトウェア業界へのコントリビュートの形のひとつだなと思っており、機会があって自分が貢献できそうな内容であれば積極的に応募するようにしています。
書籍に関わるなんて想像できない、と思われる方もいるかもしれませんが、意外とチャレンジ可能な世界だったりするので、今後トライしたいと思っている人の参考になれば幸いです。
株式会社ログラスは「良い景気を作ろう。」をミッションに、企業経営を推進する次世代型経営管理クラウド「Loglass 経営管理」を開発し提供しています。
Discussion