ソフトウェア開発をしているとデバッグは必須の作業です。とはいうもののデバッグ作業に苦しみたくはないはずです。
テスト駆動開発をしていないプロジェクトで、しかも単体テストを重視していないプロジェクトの場合、モグラたたき開発になっている可能性があります。
モグラたたき開発は、きちんとした自動化した単体テストを積み重ねていくのではなく、そのつど、気になった不具合を、気になった順番に解決しようとするアプローチです。
プロジェクト・マネジャーが知るべき97のこと モグラたたき開発を避けよう
モグラたたき開発の特徴
ソフトウェアの世代が変わったときに、一度は枯れたバグが復活している
バグを再発させない仕組みをソフトウェア開発の中に入れていないので、一度は枯れたはずのバグが次のバージョンのソフトウェアで復活してしまっている。実装の仕様がふらふらしている
何をどう実装すべきか、じゅうぶん明確化できていないので、仕様が明確に定まらない。そのため、その関数に期待していいことが、いつまでたっても明確にならない。そのため、それを使う側でもどう使っていいのか分からなくなってしまう。ある現象Aに対する対策と別の現象Bとの対策で、共通に解決する対策を見出せずに、対策が頻繁に入れ替わるので、実装の仕様がふらふらしている。そしてそのつど性能がどうなっているのか、よく分からないまま開発を進めることになってしまう。単体テストを自動化しない
単体テストを自動化していないので、手作業で目視確認をする必要があります。その作業が手間なので、ソースコードを改変したたびに行うことはできません。不具合Aを解決したと手作業で確認します。次に不具合Bが発覚したときに、その対策を対策を行います。そして不具合Bが解消したことを手作業で目視で確認します。そのときに過去に生じた不具合Aが再発していないかどうかを確認しません。そうすると、またいつの間にか不具合Aが再発していたりします。
ありがちな発言：
「単体テストを自動化できればいいんだけれどね、自動化できるの少なそうだから、自動化なんて考えないほうがいいと思う」
間違っていると思う理由：
どんなささいなことでも自動化できれば、バグの入り込む余地をほんの少しでも減らせます。最初から全てを自動化できることはないし、全てを自動化テストしようとは思わずに、出来る部分ではじめることです。発生するかもしれない要因に対して予め準備するのではなく、発生してから考える。
モグラたたき開発では、不幸なことに予め発生するかもしれない要因について考えることなく、結合試験をしてしまうものだから、悲しいほどにトラブルを招き寄せてしまう。開発作業への取り組みを上層部にアピールすることが最優先
このスタイルの開発の特徴は、今発覚している不具合に対してどう取り組んでいるかのアピールこそが、全ての開発作業の中で優先順位をもつことになります。そのため、自動化した単体テストを積み重ねていくことも、ソースコードのリファクタリングをすることも、後回しになります。人によっては、今のバグをつぶさないうちは、いかなる形の単体テストの追加というコードの追加も禁止されるという状況に陥ることがあります。「全ての改変の前にレビューができる」と信じている
「全ての改変の前にレビューができる」と信じているらしく、トラブルを生じたときに、「事前にレビューをしてください。」としか言わない。
また、テストの自動化ができていない状況で「全ての改変のコミットの前に動作テストができる」と信じているらしく、トラブルを生じたときに、「全ての改変のコミットの前に、動作確認をしてからコミットしてください」としか言わない。コードの品質をどのようにして確保するのかについてリーダーに関心がない。（もしくは後回し）
テスト駆動開発をしていって、自動化した単体テストを追加していきながら、それぞれのバグをつぶしていけば、一度つぶしたはずのバグの再発に苦しむことはなくなるはずです。
モグラたたき開発をあなたの職場からなくしていきましょう。モグラたたきにしないためのドキュメント作成を軽視している。
どのような手順をふめば、不具合を発生させずにシステムとしての組み立て・インストール・立ち上げ手順・実際の使用・メンテナンスがすむのか
それの手順を明確化する作業を、開発の全体に対して作成し、組織で共有することを軽視している場合、いくらでも問題は再発する。ある作業を実施できる人、対応できる人を1人のままにしている
何かの問題が発生したときに、問題の特定や対応をできる人が、1人だけという状況を放置してしまって、その1人に過度に負荷がかかる状況にしてしまう。問題が解決したときに、ドキュメントに反映しない
問題を解決した後に一連のドキュメントへの反映を反映をしないまま、解決したからいいだろうとしてしまう。
適切な手順書は、成果物となる文書であることを管理者が理解していないことが、この結果をもたらす。
システムが複合的な要素からなっている場合には、ソフトウェアだけの記述では、不具合を再発させない手順書にならない。バージョン管理・差分表示が楽にならないデータ形式で、ドキュメントを作成している
いつから、仕様が変更になったのかわかりにくい。第0.5版と第0.6版では、何が変更になったのか違いを表示できないデータ形式を利用して、ドキュメントを作成している。メールの転送を重ねていると、同じファイル名なのに、ファイルの中身が変化していることがある。
対策：ドキュメントの作成・更新が楽になるファイル形式を利用する。成果物とならないドキュメントを数多く作らせる
内部の議論のドキュメントでPowerPointなどで作成を要請されるが、どれらのドキュメントは、成果物にならないドキュメントであることが多い。そのことが開発者を疲れさせる要因になっている。成果物としてメンテナンスされ続けるドキュメントが明確になっていない
対策：成果物としてメンテナンスされ続けるドキュメントを明確にする。そのドキュメントの数は多くしないこと。そのドキュメントを書くためのコストも抑えること。ドキュメントは、WindowsやLinuxのどちらでも簡単に読み書きできるようにする。手順にかかわる情報の連絡をメールだけにしている
メールでは、新たに加わったメンバーが必要な情報にたどり着けません。メールの中から必要な情報を探しだすのは困難です。最新版の有効なドキュメントがどれかを、メールの中から見つけるのは現実的ではありません。
対策：Redmineなどのシステムでチケットを管理することです。そして、その内容をメールで必要な人に知らせることです。台数が違うと対応できるやり方に違いを生じることを理解していない
そのシステムが1台のときと10台のときと、100台のときでは、対応できるやり方に違いを生じる。1台のときにうまくいったやり方のままでは100台ではうまく運用することができないことが多い。1台のときは、その１台に特化すればよいので、ロットによる特性のばらつきなどは考慮しなくてよいが、１０台のときではロットによる特性のばらつきを考えにいれなくてはならない。
1台のときには、手直ししているうちに「よくわかんないけど、うまくいくようになった」からいいとしようというのが通用する場合もあるかもしれない。でも、１０台の場合には、そう都合よく「うまくいくように」はなってくれない。何がうまくいかなくしている要因なのかを考えて、「うまくいくようにする」しかない。
1台のときは、手順書を書かなくても、「うまくいったからそれでいいとしよう」とできるかもしれない。しかし、10台のときは、手順書を作って、その手順をふんで作業を進めないと、10台の全てに対してうまくいく状況を作り出すことができない。
10台のときは、「分かっている人がその作業を繰り返す」でなんとかなるかもしれない。しかし、100台のときには、その分かっている人の貴重な時間を、その一連の作業に割りあてることができない。その作業を自動化することや、専任のオペレータを雇ってその作業をしてもらう必要がある。そのどちらの場合でも、その作業を適切な順序で、適切な品質で実現できるようにする準備作業が無視できないものとしてあります。楽をするためには、それだけの準備が必要なのです。
マスター（＝物事の基準）となるドキュメントが機能していない。もしくは存在していない。
チームとして開発している場合には、何をどう開発するのか基準になるものがなくてはなりません。
しかもそれが適切に維持されていなければなりません。それに書いてあることを実現すれば、目標が達成できるように書かれていなければなりません。
モグラたたき開発の場合には、えてしてそのようなドキュメントが適切な管理がされていません。あるべき開発のストーリを開発チームのリーダーがもっていない。
何に問題があって、それらをどのように解決していくかのストーリをもっていない。そのため、必要な対策がなされないまま、本筋ではないところに労力をかけてしまう。
ここに示したチェック項目に１つでも該当するものがあったら、対策をとっていってください。対策をとらない限り、モグラたたき開発になってしまって、開発の成功が遠ざかってしまいます。
不幸にして該当するものが複数ある場合にもめげないで、「改良の余地はたくさんある。」、「対策をした分だけ、必ず結果が改善するはず。」と信じて、開発チームの取り組みを改善していきましょう。
付記：
特に大きい要素としてこの2つが、開発に失敗している事例には共通に生じているように思える。
- 要件定義に問題がある。
- 品質管理に問題がある。