はじめに
ビタワンさんの楽しいマンガ、いきのこれ！社畜ちゃんで先日デバッグの話が出てたので、デバッグの楽しみ方をまとめました。
後輩ちゃんかわいいよ後輩ちゃん！
デバッグのやり方自体については、こちらの記事を良ければどうぞ
僕の名前はデバガーコナン、探偵さ！
元ネタはビタワンさんの社畜ちゃんツイートより
デバッグのコツを教える先輩プログラマの話（再掲）
探偵の例えはわかりやすいですよね。探偵気分でバグという謎を解いてみてはいかがでしょうか？
一狩り行こうぜ！
バグをドラゴンと呼ぶ運用を始めて1ヶ月くらいたった - Konifar's WIPより
確かに、バグをドラゴンと読んだ場合「Sクラスのドラゴンが出ました！」「Aクラスのドラゴンを相手にしてる最中だってのに！」って会話になるし、ドラゴンは結局人の手で生み出されたものってところが中二ファンタジーっぽくて良い
— 尾野（しっぽ） (@tail_y) March 18, 2015
天才の所業です。お、ドラゴンが出たか！一狩り行こうぜ！
ギルドのようにチケットを扱っても面白そうですね。悠々とバグチケットをかっさらっていく姿はさながらギルドの賞金稼ぎ！
普段はバグ狩りをしないベテランが、眠りから覚めたSクラスドラゴンに対して満を持して立ち上がり、熟練の観察眼からドラゴンを攻略していく姿は圧巻！
チームでハマる言い方にバグを置き換えるってのは楽しそうですね
アヒル隊長と行く電子の旅
ラバーダック・デバッグ とは、ソフトウエア工学におけるコードのデバッグ手法である。ラバーダック・デバッグは、The Pragmatic Programmer[1]という本で紹介された、プログラマーがラバーダックを持ち歩きアヒルちゃんに向かってコードを1行ずつ説明することによりデバッグを行うという話が由来である。
精神的なものだけではなく、ラバ―ダック・デバッキングは本当に効果あります。自分を客観視するのに効果的なので、デバックだけでなく設計やプレゼンなんかでも使えます！
相手はラバーダックでもいいし、推しキャラでもいいし、同僚でもOKです。脳内で誰かと話すのも楽しくていいですね。(私はたまに料理の土井善晴先生に励ましてもらいます)
あ、同僚相手にやる時は顔色を窺いましょうね！
いきのこれ！社畜ちゃんでもラバーダックを取り上げた回があったので、どうぞ！
社畜ちゃん漫画の122話、123話です！٩( 'ω' )و
今回はIT業界のあるあるネタ（？）回です！
皆さんは「他人に問題を他人に説明していたら自力で解決策が浮かんだ」みたいな経験はありますか？
その他のエンジョイ方法
- プロジェクタでデバッグ作業のライブ配信
- デバッグが速ければ悦に浸れるぞ！
- デバッガを使いこなしてどやる
- ツールをうまく使えるとゲーム感覚で楽しいですよね
- ホワイトボードを前に座談会
- みんなでワイワイお絵かきしながら解析しよう！
- テストコードを育ててバグ検出ゲームとして楽しむ
- このテストはわしが育てた
- バグつぶしフェチになる
- １つずつバグが潰れていってテストがグリーンに変わっていくのがたまらない！って人いるらしいですね
- 自分をハッカーだと思い込む
- フード被ってterminalを開きまくれば気分はハッカー
その他、エンジョイ方法を随時募集中！
最後に
バグが出るのは当たり前のこと。とはいえバグを潰していくのは心が折れる作業です。
そんな作業をちょっとでも楽しく過ごせれば、効率も上がっていくに違いありません！
ちなみに私はラバーダックデバッグとホワイトボードをこよなく愛しています！
参考
良マンガ
いきのこれ！社畜ちゃん 著ビタワンさん
社畜ちゃんと同じ観点の記事
デバッグを楽しむ方法
ドラゴン
バグをドラゴンと呼ぶ運用を始めて1ヶ月くらいたった - Konifar's WIP
ラバ―ダック
ラバーダック・デバッグ｣とはプログラマーが使う問題解決手法である
ラバーダック・デバッグの再考とイチオシツールの紹介
イラスト: いらすとや
おまけ バグを扱う前の心構え
よく見るバグにまつわる誤解を乗せときます。
バグを出してしまうことは失敗なの？
バグと対面する前に、持っておきたい心構え。それはバグのないソフトウェアなんてないことです。
特に若い人は、バグ=失敗と捉えて、バグが出ることを嫌ったりします。「理論上はうまく行くはず！と思っていたのに実際は思ったように動かない！なんてダメなんだ！」と
理論上はうまく動くかもしれません。ただこれは「*ただし摩擦や空気抵抗はないものとする」状態のようなもので、実際のものづくりには摩擦も抵抗も想定外の出来事もあるんです。
だからこそ想定外の動作であっても安定してソフトウェアを動かすためにテストをし、バグを見つけるんです。
また、バグがない場合でも、品質がいいわけではなくテストが足りないケースもあります。テストの範囲や観点が足りなければ、見つけるべきバグが見つけられないという怖いケースも考えられるわけです。
なので**バグが見つかることは失敗ではない、正しいプロセスを踏めている証拠で、これでまた一つ品質向上につながる！**と考え、ポジティブにバグに取り組んでいきましょう！
バグを沢山出す人は品質が悪いの？
たまに聞くことがあります。バグ数を沢山出す人を品質が悪いと責める。確かにバグを出したのは事実でしょうが、バグ数が多い=品質が悪いとなるとは限らないです。
例えば同じくらいの規模の機能をAさんは1000個、Bさんは10個作りました。出したバグの数はAさんが50個、Bさんは5個です。
おいおいバグ数が10倍もあるじゃねえか！Aさんの品質どうなってるんだよ！…とはならないですよね？
野球で守備範囲の広く守備機会の多い選手はエラー数が増えるのと同じです。
皆さまのチームの小坂誠を正しく評価してあげてください！
参考
バグを扱う前の心構えに関して、ソフトウェアテストに関するリンクをいくつか貼っておきます
テスト担当者なら絶対に覚えておきたい『ソフトウェアテストの7原則』
ソフトウェアテストは、「バグを見つけるため」に行うものではない。もうこれ以上「バグが見つけられない」ことを証明するために行うもの。
IPA 定量品質管理の実践方法