実践バグ管理―プロジェクトを成功に導くための
	クジラ飛行机 ソシム 2009-03 売り上げランキング : 263133 おすすめ平均 バグ管理手法にフォーカスを当てたプロジェクト管理手法読本 Amazonで詳しく見る by G-Tools

実践バグ管理の中で、ユースケース駆動開発という考え方を知った。
UMLのユースケース図を書いて、そのユースケースに合わせてチケットを発行するということか。チケットを発行する粒度として、ユースケースと成果物を元にしたほうが、自分が考える単位としてはちょうどいいんじゃないかという感触がある。

前は画面単位でやろうとしていたのだが、WebアプリもAJAXによって画面遷移なしで色々と機能を盛り込まれるようになってしまったので、それではなかなか収拾がつかなくなってしまったと感じている。そもそも俺は、AJAXで何でもかんでも1画面に入れてしまうようなやり方は好まないのだが。バグも把握しづらいし、リリースできる状態に持っていくまでに時間がかかる。リファクタリングもしにくい。ユーザにとって使いやすければ、AJAXでゴニョゴニョよりも、シンプルなほうがいいと思う。
（AJAXで一画面で色々やるようなアプリは何度も作ってるんだけどね～）

つまり、画面単位でのチケットだと、粒度がでかすぎて、チケットが終わる前に開発者が疲れる。開発者のモチベーションを保ってリズムに乗ってもらうためにも、ユースケース＆成果物単位にしたほうがええんじゃないかなと。それにチケット駆動開発を絡ませる、と。

チケット駆動開発にした場合、機能追加・バグ修正に関するログの漏れがなくなるので、開発者レベルでは手間が発生するが、どこを修正したか後で調査する手間がなくなる。一番無駄な時間というのは、探し物をする時間であると思う。一度その時間を省くことができれば、全員共通で無駄が省ける（運用方法がよければ）。

実践バグ管理―プロジェクトを成功に導くための
	クジラ飛行机 ソシム 2009-03 売り上げランキング : 172755 おすすめ平均 バグ管理手法にフォーカスを当てたプロジェクト管理手法読本 Amazonで詳しく見る by G-Tools

チームでRedMineによるチケット駆動開発を行えるように、メールで周知しながらバグ管理・チケット駆動開発を浸透させようとしている。現在のチームは色々あって実質、開発者2名とデザイナー1名の体制なのであるが、このメンバーにおいては、俺が伝えたいことに納得してもらって作業できていると思う。ゆえに皆、協力的である。また、課題が明確になるため、お客様にもRedMineの使用に協力してもらえている。

この効果は、昔のエクセルによる機能・バグ管理表とはえらい違いである。
管理表を常に最新の状態を保つことができるので、お客様にも最新の残課題がわかるし、コミュニケーションもチケット側にログとして残るので、言った言わないということも、基本的にはあり得ない。使えるようになった人は、もう以前の体制には戻れないと思う。

次は、この体制のスピードについてこれない人への配慮が課題になる。
スピードについてこれないというよりは、RedMineの使い方がわからないという点である。わからないから、RedMineの良さを享受できず、旧体質にこだわる（しかし旧体質はSE,PGに多大な負担をかけてしまうことが多い！）。しかし、わかってもらおうと使い方を説明しても、使ってくれない人は使ってくれないし、難しいところである。SEは使いこなせているんだけど…。ミニ冊子程度の使い方マニュアルでは動いてくれないのだろうか？

RedMineの習得コストと、エクセルの作成コストを考えると、明らかにRedMineの習得コストのほうが安いのであるが…。

この投稿は全然Tipsでもなんでもない。
気付きがあったので、まとめておく。

Good cakeは、Modelに処理を書き、Bad cakeはControllerに処理がある。
これは、ビジネスロジックがコントローラーにあると、テストしにくいからであるという説明があったのだが、最初はピンと来てなかった。しかし、よく考えたらデータベースに関連する処理はモデル側に定義してしまったほうが、何度も再利用ができるし、何よりテストしやすい。コントローラーはモデル・コンポーネントなど、複合的な要素があるので単体でテストしたとしても、他のクラスの力を借りているわけだからユニットテストといいつつも結合テストに近いのかもしれない。

ひとまず、XAMPP環境でモデルのテストをできるところまでを行った。
モデルのテストをガンガン実装したあとに、コントローラー側を記述していくことができれば、テスト駆動開発をようやく行うことができるかなぁ～と思う。プロジェクトにテストを組み込むというのをManage It!で読んだのだが、実装とほぼ同時にユニットテストを書いておければ、そのコードの信頼性を上げつつプロジェクトを進めることができるので、バグが出にくい開発を行うことができるだろう。

テスト駆動開発をチームで使えるようにしたい。
その前に、自分が使えるようになって、他の人に教えられるレベルになっておかなければ！