実践バグ管理読了！ - @ikikko のはてなブログ

読了エントリを書くペース上がってきたかも。やっぱ興味がある分野だと、読むペースも早くなりますね。まぁ、興味あるから本を買うんでしょうが…ｗ

そういえばこの本、帯のキャッチフレーズがいいですよね♪

根性だけでバグはなくならない
デスマーチが始まる前に
絶望を希望に変える管理術

全体的な感想は、（どなたかも書いてたかもしれませんが）ちょっと前書きに当たる章が長い気がします。「第2章：バグ管理の流れ」はもっと思いっきり削ってもよかったのかも。中核となる第3章・第4章に行くまでに、ちょっと読み疲れました。この本は「システム開発に初めて携わるような人」も読むことを念頭に置いているので、この部分を説明せざるを得ないのもしょうがないのかもしれませんが…

あと、所々に小ネタがしこんでありますね。アドホックテストの説明で「自動販売機のテストなら、コインを入れてから蹴りを数発入れてみる」とか。Head Firstソフトウェア開発読了！ - @ikikko のはてなダイアリーでもちらっと述べてるけど、こういうの嫌いじゃないですよｗ

Joel氏のJoel on Software - やさしいバグトラッキングとかも、この本と合わせて読んでおくとGood!

実践バグ管理―プロジェクトを成功に導くための

作者: クジラ飛行机,あかさた
出版社/メーカー: ソシム
発売日: 2009/03
メディア: 単行本
購入: 6人クリック: 148回
この商品を含むブログ (21件) を見る

以下、いつものように気になった箇所を列挙。私が受託＆大規模開発に携わっているので、その観点で見てみました。

COLUMN：ジョエル・テストで開発チームをチェック

変更可能なスケジュール表を持っているか？: スケジュール管理者の負担を減らすために、「チケットドリブン方式を採用してスケジュール管理の一部を各開発者に負担させる」という方法が提案されています。ただ、チケットドリブンで管理するタスクは管理者にとっては粒度が細かすぎるので、その差異を吸収できるような何かが必要と考えています。何？と具体的に問われても思い浮かばないのですが…＞＜

買える範囲で一番よい開発ツールを使っているか？: 文中で「組織として戦略的によりよいツールを検討・導入されているか」ということが本質的ではないかと提言されており、具体例としてツールに関する定期的な勉強会開催やオープンソース・フリーソフトの導入があげられています。

これは、まさに的確なものだと思います。ただ（主に受託系の開発に多いでしょうが）外部から人をかき集めるタイプのプロジェクトでは、残念ながらあまりこういった活動が活発でない（できない）こともあります。

外部の人間を含める方が自社の人間で構成したときよりセキュリティ的なリスクが高まるので、得体の知れない（と思われがちな）フリーソフトの類は意見が通りにくいのです。また、人が入れ替わり立ち替わりになるので、勉強会でノウハウを共有しようという意識も高まりにくいというのもあるのです*1。

3-3 バグレポートの書き方

バグレポートの形式を考える際のヒント: ルールは「追加しやすく削りにくい」とのこと。なので、できるだけ軽量なルールを考えて、必要に応じて追加するようにしましょうと。非常に納得。追加するならば、自動的・形式的に作業できる箇所はまだ何とかなるけど、人がマニュアルで対応せざるを得ないところは、特にそうかな。

再現手順の書き方・洗練の方法: 再現手順が重要なバグとそうでもないバグがあるよな〜と思っていましたが、突き詰めるとリアルタイム処理とバッチ処理の違いなのかな。バッチ処理だと自動的に処理が流れるので再現手順云々はあまり考慮しなくてよい。けれど、リアルタイム処理だと手順によってバグが発生するときとしないときがあるので、手順が重要になってくる。

ま、当然と言えば当然ですが、最近バッチ処理のプログラムばかり携わっていたので忘れかけていました…orz

3-4 困ったバグレポートの傾向と対策*2

問題の修正範囲が大きすぎる場合: 対策として、全体を統括するレポートとその部品となるレポートを複数作って管理する、とあります。TracではMasterTicketsPlugin *3、Redmineでは標準機能で関連Issueを表現することができます。このような状況は頻繁にあり得ると思うので、Redmineのように標準機能でサポートする方がスマートでしょうね。

3-5 バグ管理データベースの分析

バグ管理の情報を、その場限りでなく将来に渡って活用していきましょうという話。いや、実に大事なことだとは思うのですが、ここまで手が回っていません。根性で頑張るのでなくきちんとデータを分析して作業に対しての根拠を示していかないと、それこそ帯のキャッチフレーズの通りにデスマーチにまっしぐら…

4-1 バグ管理のパターン

個人的に、この本の一番の功績だと思っている章。デザインパターンしかり、物事を分類して名前を付けるということは、その後の議論や理解に非常に役に立ちますよね♪

とりあえず、【チーム開発向き】と分類されている（Excelパターン・BTSパターン・チケットドリブン開発）を重点的に読み込みました。

やはり、どのように周囲を巻き込むかがBTSパターン・チケットドリブン開発の肝ですね。ある程度のポジションの人ならばトップダウン的に導入しやすいでしょうが、下っ端からだと中々難しい。政治的に交渉している時間も余裕もないし、たとえできたとしても、導入するころには既にプロジェクトの終盤。ワークフローも固まってきた頃にBTSなど出しても、結局使いづらいという声があがるだけ。

妙案が欲しいなぁ…

4-3 リリース管理について

小規模製品の場合: 要するに、ブランチを切らない（切る必要がない）プロジェクトの場合。余談ですが、私が関わっているSAPのプロジェクトではこれになりがちです。というのは、SAP内蔵のバージョン管理システムにブランチ・マージ機能が無いからです。だから、新機能リリースとバグ対応が混在して、リリース管理が大変なことになったり…orz

複数のバージョンを保守する場合
複数のリリースを保守する場合: バージョンは時系列、リリースはターゲット（機器・環境・顧客）単位と理解しました。それぞれ単一バージョン・リリースと複数バージョン・リリースのパターンがあるので、2×2の4パターン。一番複雑なのはもちろん、複数バージョン・複数リリースでしょうね。

ちなみに、受託開発なら単一バージョン・単一リリースが基本かなと思います。というのは、ターゲットが一つに固定されているから、バージョン・リリースが分かれようがない。パッケージ製品だと、こうはいかないでしょうね。

4-4 様々な開発プロジェクト

複数のチームからなるプロジェクトやオフショア開発プロジェクト: 「仕様書の読み合わせ*4」なるものがあるんですね。時間の無駄と批判されることが多いらしいですが、まさにそう思います。そんなことより、本書で提案されているようにチーム間の交流を深めるべきでしょう。契約とか政治とか色々ややこしい問題があるのでしょうが…＞＜

ちなみに、この節に関連して「大規模チームのプロジェクトにマッチする管理手法」としてBTSパターンやチケットドリブン開発は推奨されているけど、Excelパターンは挙げられていないですね。著者も無意識に避けているのかなｗ

4-5 番外編：実際の開発プロジェクトのバグ管理

日本語プログラミング言語「なでしこ」の開発について: バグ管理も（Pukiwikiプラグイン⇒Trac⇒スレッド型の自作掲示板）と紆余曲折を経て、今の形「なでしこ」バグ＆要望掲示板になっているみたいです。その中で触れられている↓の言葉は、実体験の分だけ重みがありますね。

Tracは開発者にとってみれば、非常に使いやすいのですが、一般ユーザーには敷居が高く感じるようです。

5-2 デスマーチの立て直し

プロジェクト管理的な要因: 一因として、官僚主義的なプロジェクトが挙げられています。例としては、画面キャプチャについて。テストのエビデンスが品質を下げてる実態 - 山本大＠クロノスの日記とかも合わせて読むと、色々考えさせられます。

画面キャプチャ（エビデンス）自体が全部悪いとは言いませんが、プロジェクトの初期段階からテスト方針を決めておかないと悲しい事態になると思います。（IF文条件分岐などの）コーディングレベルも全てエビデンスを作成しろと言われても、作ったところでそれこそ誰も見ないでしょうね。自分が考えている方針は、こんな感じ。

【基本設計レベル】：確認してもらう必要があるので、ユーザにも分かるようなエビデンスを作成

【詳細設計・コーディングレベル】：エビデンスは不要、その代わり条件網羅を意識した単体テストを実施

新規プログラム作成時は、基本設計レベルのエビデンスを作成する前に単体テストをしっかり行う。でないと、いきなり基本設計レベルのテストを行っても、どこに問題があるかが判明しづらくなる。

既存プログラム修正時は、修正前と修正後の差異を意識してテストを行う。既に動くものがあるなら、コーディングレベルのテストを飛び越して基本設計レベルのテストを行う方が、分かりやすい場合もある。

政治的な要因: 一因としての「出羽の守」。けれど、これ実は自分もよくやってしまうのですよね…orz

例えば、現プロジェクトにOOPやらxUnitを啓蒙する活動をしていたのですが、そのときによく「別の言語では〜」「別のプロジェクトでは〜」という言葉が口に出ていました。「自分一人の思いつきでなくて、既にそういう実績があるものですよ」という意図があったのですが、周りから見れば出羽の守になっていたのかも…。

ならば、他の事例は出さずにOOPなりxUnit自身の説明だけでいいじゃない？というのも最もな意見です。が、それだとあまりにも根本的なところから説明を始めないといけなくて、本質的なことまでたどり着かないんですよね、これが。OOP *5なら「クラスとは？」「インスタンスとは？」ぐらいから始める必要が。で、続けていく内に説明を受ける方のキャパを超えて、「面倒だから今のままでいいよ」となりがち…。

解決策としては、私が要点を掴んだ押し付けがましくない説明ができるようになることですね。周りがある程度までは自分で学んでくれると非常に助かりはしますがｗ