紀伊國屋から注文していた Diomidis Spinellis『Effective Debugging』が届いた。
明日届く洋書、1冊で薄い本だからネコポス扱いで待たなくてよさそう（同人誌ではない）
— Xaro(-ε-δ)Cydeykn (@CardinalXaro) 2016年7月16日
とりあえず「Chapter1. High-Level Strategies」序文と「Item1: Handle All Problems through an Issue-Tracking System」を訳した。 前回の反省を踏まえ、翻訳文を公開できないので自分のための翻訳である。
項目名の通り、課題管理システムを使いましょう、という話である。以前、上長に「課題管理表をExcelで作れ」と言われた。 「Excelですか」と10回ぐらい聞き返したがExcelで作れという指示であった。 結局、プロジェクトの流れと結びついていない課題管理表など使われることもなく上長も恐らくその存在を忘れていることであろう。
筆者はGitHubなどのコードレポジトリに含まれるもの、プロプライエタリなものとしてJIRA、オープンソースとしてBugzilla や Launchpad 、OTRS 、 Redmine 、Trac を紹介しているがどのシステムを使うかは重要ではなくすべての課題を管理することが重要だと説く。 僕の経験に照らせば、Excelだろうがそれを全面に使うべきであったか。使ううちに限界を迎えて上記のどれかに落ち着くであろうが。 ちなみに、筆者は「課題管理システムにない課題への対処依頼は拒否しろ」とまで主張している。 以前、『カンバン仕事術』を読んだときにJIRAに登録されていない課題があってカンバンで可視化できた、みたいなストーリーがあった気がしたが、それとぶつかりそうな主張である（『カンバン仕事術』に課題管理システムとカンバンの両立方法について書いてあった気がする）。
課題には正確なタイトル、問題の再現方法、優先度と重要度、ステークホルダー、環境、そしてコメントなどで進捗状況をドキュメント化することが重要であると述べている。 理由は本文に書いてある通りであるが、ステークホルダーの説明で「Acmeからの提供、25万ドル規模の顧客」のようなタグをつける話があって生々しいと感じた。
前回はMarkdownで翻訳文を書いてPandocでreStructuredTextに変換してSphinxでHTMLに変換する、というreStructuredTextを新たに覚えたくないが故の七面倒な手順を踏んでいた（さすがにすぐにバッチファイルを書いた）が、今回はCommonMarkParserを使ってMarkdownを直接SphinxでHTMLに変換した。幾分手順がすっきりできて気分がよい。
