理工書の出版社に勤務しており、書籍を企画編集しています。

出版物もソフトウェアの一種であり、理想に近づけるための方法として、読み直しをはじめとする「テスト」が存在します。今回は、本のテストに対する私と周囲の取り組みを報告します。

コンピュータソフトウェアと同様に、本もソフトウェアの一種です。

コンピュータソフトウェア開発の技術には、本づくりに応用できるものがあります。ですがテストはそのまま応用できない場合がままあります。

本作りにおけるテストは、人の目で読み直すことが中心になります。

ですが、人間はコンピュータのように速く読めません。またコンピュータのような単純な正確さや再現性を求めるのは無茶です。読んでくれる人の人数を増やすと、とりまとめが大変です。

そこでこういった工夫をしました。テスト自体を機械に肩代わりしてもらうのは難しいので、主にテストをしやすくするための工夫です。

最終的な仕上がりに近いものを読めば、より実際に即した改善案が浮かびます。

内容に詳しい人に目を通してもらえば、より良い改善案をもらえます。

たくさんの目で、または時間をおいて読むことは、視点の固定や思い込みを減らします。

多人数からフィードバックをもらう際のとりまとめは、メーリングリストやトラッカーやバージョン管理ツールを使えば、効率化できます。

校正支援ツールは、本来は誤記を見つけるための道具ですが、内容上の問題点もまま見つかります。

（※注意：ツールはあくまで人間を支援する手段で、何をどう使うかはケースバイケースです。）

効果は測定していませんが実感しています。発行後に見つかる不具合は明らかに減りました。効率についても、例えば数十時間かかっていた校正作業が、数時間でかつ高い精度でできるようになっています。著者や訳者からも、読者からも、おおむね良い評価をいただいています。

ただし、読むのが大変なことに変わりはありません。また支援ツールもすべてが自動化できているわけではなく、忙しいと適用が滞りがちです。

今後の課題は、うまくいった工夫の実行コストを下げることと、効果がありそうな方法を試していくことかと考えています。

なおTDDの可能性は今のところ不明です。