[#TiDD]本を書く際の注意点(プロセス編) - 「チケット駆動開発」の経験から -
書籍「チケット駆動開発」の発売から2週間。いただいた色々なご意見から、反省点を基に注意点をまとめておきます。もちろん、多くの方にレビューもしていただきましたし、自信を持って出版しました。しかし完璧だと思っても、振り返るといくつかの反省点はあるものです。ここでは、主にプロセスの観点から注意点をまとめてみました。今後は電子出版が容易になる事から、インディーズ的な出版も増えると思います。本を書く際の注意点はこれだけではありませんが、初めて出版される方に少しでもご参考になればと思っています。
1.読者層の見極め
どの読者層に向けて本を書くか、それによって本の構成や書き方が変わってきます。前作の「Redmineによるタスクマネージメント実践技法」の場合は、初めての方をかなり意識しました。そこで、まず後半を書き出してから前半を書いて、必要な用語の定義ができる様にしました。
今回は著者らにとって2作目という事で、2つの戦略が考えられました。より入門的な内容にするか、より高度な内容にするかです。議論の結果、前作を踏まえて、説明が不十分だったより上位の内容を書く事にしました。そこで、「用語集」を最後につけることで伝えたい概念的な内容を一気に読めるようにしました。
しかし、前作はRedmine、今回は方法論としての捉え方が一般的なようで、前作を読まれていない方も多いようです。初めてチケット駆動開発に触れられる方も多く、そのような方には少し読みにくい本となってしまいました。
2.タイトル
内容を明確に示すタイトルにすべきです。元々は読者層を意識したタイトルを検討していたのですが、どれも座りが悪かったので、シンプルな「チケット駆動開発」としました。このタイトルは分野を表しているだけですので、人によって、「入門」「基礎」「のすべて」など色々な捉え方をされたようです。
そのような期待に応えるには、チケット駆動開発の基本的な技術を個々に並べて説明する必要があると思います。しかし、チケット駆動開発の視点でBTS/ITSを用いて障害管理を実践すれば、基本的な技術は容易にわかるとの判断から、基本的なBTS/ITS技術の網羅はしていません。シンプルすぎるタイトルが招いた混乱の一つだと思います。
(9/9追記:今、誤解を受けないタイトルをつけるなら「チケット駆動開発 アンサーブック」だと、思っています)
3.共著の場合は大きな単位で分ける
著者が変われば文体が違いますし、一章の長さも変わります。文体は相互にチェックする事で、ある程度は修正できますが、一章の長さは調整できません。
プログラムの保守の場合、変数やメソッドの分割などに癖があっても、同じ担当者の者だけを見ていればそれなりに意図が見えてきます。文章の場合もたぶん同じでしょう。もちろん、絵が少ないなどという基本的な問題もありますが、前作の様に前半と後半などシンプルな分ければ、もう少し読み易かったと思います。
(全体をチェックする場合も多かったですが、担当分とそれ以外を分けて読む事も多かったです。その時のイメージが、この問題に気づきにくくしているかもしれません。もし本をお持ちなら、担当者ごとに読まれるとイメージが変わるかもしれません。)
4.構造的な問題はレビュアーには積極的に問いかける
今回の出版に際して多くの方にレビューしていただきました(ありがとうございました)。レビューをしていただく場合、細かなチェックとともにゆっくり読まれる事や、やはり遠慮もある事から、構造的な指摘は出にくいようです。
「チケット駆動開発」の第2部では、似たような内容を別の視点で複数の章に分けて書いています。冗長との指摘はこのあたりかと思います。この点が私自身も少し気になっていたのですが、特に指摘がなかったのでそのままにしてしまいました。しかし、前作同様に著者の方から質問をしていれば、結果が変わったかもしれません。
5.一貫性とバランスを考えた構造を保つには追加よりも削除
「チケット駆動開発」ではレビュー後に追記をしています。大きな修正ではないのですが大事な修正です。このような場合、導入部と全体の一貫性や全体のバランスが崩れてしまいがちです。終盤になるとやはりリファクタリングが億劫になりがちですが、もっと勇気をもって全体のバランスのとれた構造を維持すべきでした。
前作の場合、最後に大胆な削除をしてバランスを保ちました。追加よりも削除の方がバランスを保ち易いと思います。
6.構造的欠陥は指摘され易い
文章の読み易さは、構造によって大きく変わります。特に一気に読まれる方は、構造上の問題や、それに起因する難解さが気になる様です。もちろん文章テクニックによって読み応えのある本にできるかもしれませんが、やはりアーキテクチャは重要です。
たった2冊の経験から、執筆プロセスの注意点を書きました。もちろんこれだけではないですし、読み易くするための基本的な技術も重要です。今回は、滅多にない経験ですので、振り返る意味でまとめておきました。どなたかのご参考になれば幸いです。
次回のRxTstudy(Redmineやタスク管理を考える勉強会@大阪)では、チケット駆動開発をどのように捉え、どのような発展を望んでいるかなど「チケット駆動開発」執筆に至った思いを発表する予定です。ご興味のある方は、ぜひご参加ください。
« TwitterとSNSの違い | トップページ | [#TiDD] チケット管理システムはプロセス構築のUNIX »
「チケット駆動開発」カテゴリの記事
- One fact in one placeとチケット駆動開発 - Software Processes are Software, Too -(2021.12.21)
- マルチスレッド処理と進捗管理・配員・作業分割/割り当て- Software Processes are Software, Too -(2021.12.20)
- カプセル化と組織パターン - Software Processes are Software, Too -(2021.12.20)
- [#TiDD] ポケモンGOにチケット駆動開発のポイントを学ぶ(2018.05.01)
- [#TiDD] プロジェクトを成功させるチケット管理(2017.07.02)
この記事へのコメントは終了しました。
コメント