デバッグに関する原則__2_.pdf

Transcript

1. デバッグに関する原則
2. 本スライドについて - デバッグルール: 9つの原則、54のヒント　という書籍をベースにまとめてます。 - この書籍はもう売ってないです - 細かいツールの話や言語固有の話は入っていません。それらが知りたい場合は別 途調査ください
3. デバッグのための行動
4. 1. システムを理解する
5. システムにわからない部分がある場合、問題 はそこにあるように思える
6. 理解するために - マニュアルを読む - ライブラリーであれば公式ドキュメント、モジュールであれば仕様書 - バグが起きているので書いてあることを信じ切ることは危険だが、 理解の最初としては必要 - 料理が思った通りできない場合にレシピを見直すのと同様に、マニュアル通りにしてないことが問 題の可能性がある - 全部徹底的に読む - 自分が重要であると思うところだけでなく、 徹底的に読み込む - 問題の原因を突き止める鍵はまだ読んでないところにある
7. 何が正しいかを知る - 何が正常かを理解する必要がある - チェーンソーの音を一度も聞いたことない人はブンブン音がなるのが問題であると勘違いするかも しれない - 何が問題かに気付くために担当している分野に対する基礎知識が必要 - 多くの人が家庭用コンピュータの不具合を解決できないないのは基礎知識がないから - 例
8. 現状を知る - 問題を切り分けるためには、どの機能がどこにあるかを知る必要がある - オーブントースターでトーストを焦がしたら、調整つまみで焼き時間を調整することを理解している 必要がある - 通過するAPIやモジュールなどを全て知っておくべき - トーストが焦げた例 - 調整つまみで時間を短くしてもトーストが焦げた場合は、トースターの時間を調整する機能が 壊れていると理解できるので、新しい物を買うか修理に挑戦すればよい
9. ツールを知る - デバッグツールは目となり耳となります - 正しく使用し、結果を正しく解釈する必要がある - 体温計の反対側を口に入れても意味がない - 多くのツールは使い込んだ人だけが知っている強力な機能がある - ツールを使い込めば使い込むほどシステムで何が起きているか理解できるように なる - 時間を割くべきツールでできることは全て習得しよう
10. 2. わざと失敗してみる
11. もう一度やってみる - 自分が何をしたか調べて、もう一度再現してみる - 作業を進めながら手順を一つ一つ書き留める - 書き留めた手順に従ってやると、本当にエラーが起きるかを確認する - バグは環境の状況に依存する可能性があるので、手順の最初には環境の状況を 書き留めておくこと - 寒い日に車の窓がくっつことを整備士に調べてもらいたいなら、あなたが毎朝洗車していることを伝 える必要がある
12. 失敗を促す - 失敗の手順に多くの手間がかかる場合は、テストなどを書き自動化することが有益 - 飲酒運転の疑いをもう一度ハイウェイを走らせて確かめるようなことはしない。あなたをまっすぐに 歩かせたりして簡易的に確かめるものだ - ただし、メカニズムを変更してはならない - 「新しい問題を生み出す」のではなく「促す」 - 何かを変更するときも頻度にだけ影響与えるような高いレベルで行う必要がある - 窓の水漏れをテストするために消防用ホースを使い、窓ガラスを粉々にして、「原因は窓ガラスであ る」と言ってはならない - 普通のホースで水をかければよい
13. 制御されていない条件を見つけ出す - どの条件がシステムに影響するかわかった時点でいろんな組み合わせを試してみ ればよい - 起こした結果を書き出す - 条件を調整すると問題が起きないこともある - 問題が起きる条件を特定したのだ - その条件を書き出してときの、その条件を色々変えてみて観察する
14. 統計データに騙されるな - わざと失敗させる理由のもう一つとしては「原因のいとぐちをつかむこと」 - 問題がいつ起こるかわからない場合、例えばボタンを右手でクリックする場合と左 手でクリックする場合など意味のない比較を膨大にすることになる - 十分な情報が集まれば、問題に常に関係あることと、いっさい関係ないこととの区 別がつく - 問題が解決したのか、たまたま運がよかっただけなのか - テストのサンプルは多いほど良いが、必ず発生する一連の流れを探す方が圧倒的に有効である
15. 「そんなはずはない」ことが起こることもある - 開発者が「そんなはずはない」と起こったりすることがある - テスト実施者のミスで実際に起きてないかもしれないし - 起こったかもしれない - まずやるべきことは、憶測を取払い開発者の前で再現してみること - 「そんなこと」を発見するには再現してみてデータをとって状況を確認するしかない - 家族と一緒にある味のアイスクリームを買うとエンジンがかからなくなる - バニラかチョコレートの時は大丈夫で、他の時は帰りのエンジンがかからなくなる
16. 3. 考えるのをやめて観測する
17. 資料もないのに、理論的な説明をつけようとするのは大きな間違いだよ。
 人は事実に合う論理的な説明を求めず、理論的な説明に合うように、
 事実のほうを知らずしらず曲げがちになる。
 （シャーロック・ホームズ）
18. まず「観察する」 - エンジニアは「思想家」 - 考える方が楽しいし、楽。肉体労働よりも楽 - エンジニアにとって「観察する」より「思想する」方が楽 - ただし、問題がおきたいきさつは想像力を超えることがある - 「観察する」のは難しい - ソフトウェアで「観察する」ということは、ブレークポイントを設定し、デバッグ文を追加し、値を監視す る - 非常に複雑である - へたな推測に根拠がなかったとしても、バグの追跡はし続けなければならない - 時間がただ消費しただけで何も前進していない - なので、まず「観察する」という意識が大事なのである
19. 問題を直接見る - バグを見つけた時、私たちが見ているのは問題ではなく問題の「結果」である - 電気がつかないという結果には見つけるべき問題がある - 実際に何が起きているかを一部始終を観察しない限り問題は誤解されやすい - これが問題だと見当つけて修正しても、実際には別のところで問題が起きているこ とがある - 逆に問題が隠れたり、さらに別の問題を生む可能性もある - サーバが夜中に再起動する問題があった - 毎晩ほぼ同じ時刻に起こるので、ログなど証跡はなかったバッチ処理だと決めつけた - 自動的に動くプロセスを監視してみることにしたが何ヶ月も問題は発見できなかった - 夜中に残ってマシンの様子を眺めていたら掃除のおばちゃんが電源を抜いていた - 通常は近道するより実際に見た方が数倍早い
20. 詳しく見る - 前例のようにほんのちょっと見たら原因を見つけられることは稀である - 一般的には問題を確かめるために、調査すればしただけ、何が原因なのかがよく 見えてくる - より多くの情報を得るにはどこを探ればよいか判断できるようになる - では、どこまで観察を続けれよいのか？ - 「システムを理解する」と同じようにここでも経験が役にたつ - 見当違いの推測をして、それを追いかけているうちに、どのような場合にどこまで観察すればよい かわかってくるだろう - そして、デバッグの名手の基準が「どれだけ早く推測できるか」でも「どれだけ素晴 らしい推測が」できるでもなく、「下手な推測に基づいて行動を起こす場合がどれだ け少ないか」にあることを理解するだろう
21. ハイゼンベルグの不確定性原理に気をつける - ハハイゼンベルグは本当に軽くて、本当に小さな量子物理学を研究しているとき に、粒子の位置または運動量のどちらか一方を測定することは可能だが、一方の 測定がもう一方の測定を阻害することにきづいた - テスト用のツールがテストするシステムに影響することは可能なかぎり減らすべき である - ツールを追加したら失敗を再現してみて、ハイゼンベルグの呪いにかかっていないか確かめてみよ う
22. あくまで検索を絞り込むために推測をする - 「考えをやめて観察する」とは推測を全くしないということではない - 問題の検索を絞り込むため推察する - 推察が全くの的外れになることがある。 - 調査によりその推察に根拠がない場合は最初からやりなおそう - ただし、例外がある - ある種の問題は他の問題より発生しやすくかつ修正しやすいので、まずそれをチェックしてみること である - その場合は調査をせずにまず修正してみてもよい
23. 4. 分割して攻略する
24. 「今まで何度も言ったじゃないか。不可能なものを一つ一つ消していくんだ。
 残ったものがどれほどあり得ないとしても、それが真実に違いないって」
 （シャーロック・ホームズ）
25. 調査範囲を絞り込む - ターゲットを効率よく調査するためには、逐次近似法という手法が一般的に用いら れる - 予想範囲内で何かを見つけるためには、範囲の両端の中間点でターゲットが通り過ぎたかどうかを 確認して、通り過ぎたら、その先半分のまた中間地点を通り過ぎてないかを逐次的に調べていく方 法 - 友人に1から100の間の整数を1つ想像してもらい、あてていく作業をイメージすると 良い - 逐次近似法には非常に重要な前提が二つある - 調査の範囲を知っていなければならない - あるポイントを調べるためには自分が問題のどちら側にいるかを知らなければならない - 友人が嘘をついたり、135を選んだりしたら永遠に調査は完了しない
26. 妥当な範囲を知る - 近くの川が悪臭をしている場合、海まで遡るのか近くの川までに限定するのか経験 と手間に従って妥当な範囲を特定する必要がある
27. どちら側にいるのかを知る - 近くの川が悪臭をしている場合、汚水が流入しているのが上流なのか下流なのか 知る必要がある - 各ポイントを調べ、問題が上流なのか下流になるのかを特定していく必要がある - 調べた結果ポイントを移動させる
28. 目立つテストパターンを使用する - 綺麗だった水が赤みがかって悪臭を出していれば簡単にわかるが、バグの影響が 捉えにくい場合や、データをそもそもバラついていて派手に壊れていてもわからな い場合は簡単に見分けられる入力やテストパターンを用いる - 川の例の場合、濁った川の流れより透き通った川の流れの方が流入ポイントは見つけやすい
29. 問題のある方から始める - 多くのシステムでは、本流に流れ込む支流のように、さまざなな流れが1つに合流 する - 上流から検索を始めると見当はずれの支流を調べ時間を無駄にする可能性がある - 悪臭を放つ赤い排水がある悪い方から手をつけて、上流へ向かって作業を進める こと - 加熱炉が作動しないとしよう。 - 燃料切れはよくあるので、まずそれが原因ではないかとしれないと疑って、タンクがいっぱいかどう かを確認する。次に燃料の注入に問題がないかを確認する。注入が問題がない場合（以下略 - 最終的にスプレーヘッドからオイルが噴出していることに気づくまでには時間がかかる - 問題のある加熱炉から 調査を始めよう
30. 分かっているバグをまず修正する - システムは複数のバグが紛れ込んでいるものだ - 発生している問題の1つを見つけたら、ほかのものを探す前にまず修正しよう - 修正が他の問題へ影響する可能性はある - 影響する場合、修正した後に再度テストしよう - ある問題が解決すると別の問題が解決される可能性がある - 修正によってどちらにせよ他へ影響出る場合は、発見が早いことに越したことはな い
31. ノイズは先に修正する - 前のルールから「ある種のバグは、ほかのバグの原因になりやすいので、まずそれ らを探して修正すべきである」 - ノイズ信号はなかなか見つけられない断続的な問題全ての原因となりうる - まず他の問題を解決する前にノイズの問題を解決する必要がある - 他の問題は予測するのが難しくても、ノイズを除去する解決することもある - ただし、そればかりに没頭してはならない - ノイズの問題を修正することの難しさと、それが実際に何か影響している可能性を比較しよう - 完璧主義になりがち - それらが実際に問題の原因になってないなら、通常はそのままにしておく方がよい だろう
32. 5. 一度に1つづつ変える
33. エンジンがかからない時の話 - ある朝、妻の車で仕事に出かけようとした時、エンジンがかからなかった - ギアをパーキングからニュートラルにすればエンジンがかかるだろうと思い、ニュー トラルにした - それでもエンジンがかからなかった - 妻に尋ねると車のキーの調子が悪いらしい - いろんなやり方でキーを回してみたが、エンジンはかからなかった - キーを色んな方法で回してみる前にギアをパーキングに戻していれば、エンジンは おそらくかかっていただろう
34. 散弾銃ではなくライフル銃を使う - 変更は一つづつ行おう - 散弾銃のように一度にたくさんやっつける方法は、今すぐ忘れること - 良いライフル銃を手に入れて、一つずつやってけよう - 問題を実際に目撃した場合は、それだけを修正すれば良い - ターゲットを撃つのに散弾銃が必要と考えた場合、ターゲットがはっきり見えてない可能性がある - 本当に必要なのは良い照明と良いメガネである - 小学校でよく行っている植物観察では、全く同じ土と全く同じ種で、全く同じタイミン グで水をやり、植物にあたる日光の量だけ調整する - こうすると成長のばらつきは日光の照射時間によるものとなる - あるいは日光の照射時間を同じにし、水の量をかえると成長にばらつきがでる - 成長が悪いのが修正したいバグだとすると、鉢の色と水の量と照射時間全て同時 に変えると鉢の色が関係ないことがわからなくなる
35. 両手で真鍮の取っ手をつかむ - システムのさまざまな部分に変更を加えて、それが問題に影響するかどうか調べた くなることがよくある。 - これは通常、ツールを使って何が起きているかを調べることではなく、推測していることなので注意 が必要 - これでは問題が起きている状況を探すのではなく、変更してしまってい。この変更によって、最初の 問題が見えなくなるどころか、問題をますます増えてしまうこともある - 原子力潜水艦のは発電装置の制御パネルには真鍮の取っ手が付いている。警報 装置が鳴り出したら、エンジニアはその取っ手を両手で掴、システムで何が起きて いるか正確に理解するまで話さないように訓練を受けていた
36. 正常なものと比較する - 問題が起きた時と正常なもので、デバッグログやトレースなど取得できるあらゆる 出力を比較するだけで問題の多くが解決したりする - ただ、前後でコードを大きく変更すると比較が難しくなる - 2つのトレースの要因はバグだけに絞り、他の要因は全て排除しよう - 二つのテストのログは同じマシン上で続けて実行しよう - 異なるマシン、異なるパラメーター、異なるユーザ入力、異なる環境は避けよう
37. 最後に動いていた時から何を変更したか考える - バージョン管理してるなら、問題が起きてないバージョンまで遡り問題が起き始めた ところの直近の変更をみることで問題の焦点がはっきり絞られる - ただ、状況がそこまで単純じゃないケースもある - 例えば、問題はかなり前からあって、タイミングやデータベースのサイズなどの変更によって表面化 することがある - バージョン5.0で問題が起きたように見えても、バージョン 3.2の問題が表面化したに過ぎないことも ある - 重要なのは落とし穴への道を塞ぐことではなく、落とし穴自体を防ぐことである
38. 6. 履歴をつける
39. バグの話（ビデオ圧縮チップの話） - ビデオデータを小さなサイズに圧縮して送信する必要がある - テレビ会議システム - ある日、これといった理由もなしに圧縮の速度がかわることがあった - 再起動すると直る - チップを緩めたり冷やしたりしても改善しなかった - イライラ - ある時、椅子から立ち上がると突然速度が落ちた（ように見えた） - もしかして寂しがり屋？
40. バグの話（ビデオ圧縮チップの話） - 椅子から立ち上がると着ているシャツがカメラに広く映り込むことがわかった - 格子柄のシャツを着ていた - もう何回か立ったり座ったりして原因を調べて、わかった - 格子柄は対象のプロセッサが極めて圧縮を不得意とするパターンだった - この話のポイントは「最も取るに足らないように見えることが、実際にはバグを引き 起こす犯人である」ということ
41. 何をどの順番で行い、何が起きたかを記録する - 記録をつけよう - 問題を調査する際には、自分が何をどの順番で行ったのか、そして結果として何が起きたかを記録 しよう。これは毎回行うこと - ハードウェアでもソフトウェアでも同じ - 食物アレルギーの症状が現れると、アレルギー専門医はアレルギー反応とその時 の食べたものを結びつけることで、アレルギーの原となった食べ物を特定しようとす る - 関連がはっきりせず、より詳しい情報が必要な場合は、食べたもの全てと時間、その時の反応を全 て日記に書くように指示されるだろう - これが「履歴」 - いちごを食べた時に蕁麻疹が出てることの因果関係がわかったとします - そうする医者は対処法を提示することができるので、この「履歴」は大切 - 処方はいちごを食べないこと
42. バグの話（フロッピーディスク） - カスタマーサポートに、ある顧客から立ち続けに電話があった - 購入したフロッピーディスクが一度だけ正常に動いたが、その後動かなくなってしまった - カスタマーサポートは何度も新しいフロッピーディスクを送ったが、同じように一度は 正常に動き、その後動かなくなった - とうとうスタッフはその顧客に電話をかけ、手順を一つ一つ教えてもらった - フロッピーディスクは 1回使った後にファイルキャビネットに 磁石で留められていた
43. 悪魔は細部に宿る - 多くの場合、履歴が大事だと理解されるが、残念なことに本当に必要な詳細な記録 が必ずしもあるわけではない - 単なる「問題がある」「動かない」など - グラフィックが完全に歪んでいるとも、赤い部分が全て緑で表示されているとも、３番目の数字が間 違っているとも書かれない - ログがあるが、いつ問題が起きたが分からないレポートが出てくる時がある - アレルギーの場合、食べたものだけ書かれていていつ症状が出たか書かれていない履歴に何の 意味もない - ログには記録されない状況や症状をデバッグトレースやログに注釈として書き込ん でおくこと
44. 悪魔は細部に宿る - 状況を説明する時には、具体的に、矛盾がないようにする - ビデオ通信では大体システムAとBがあり、それが相互に通信する。そして、「リモー トビデオなし」とバグレポートを受け取ったとしよう - これでは問題はAなのかBなのかわからないし、リモートビデオとはリモート側で表示されるビデオ のことなのか、リモート側から送られてきたビデオのことなのか - 基本的な症状を理解しないことには問題の解明に着手できない - もう一つ注意しないといけないのは「何が起きた」だけでなく、「どれくらい続いたか」 である - 「ほとんど聞こえないほどのブンブンいう音が 0.5秒続いた」なら問題ないが、「キーンという音が 6秒 続いた」とかなら詳しく調査する必要があるだろう
45. 関連づける - ある症状を他の症状やデバッグ情報と関連付けるのは非常に有益 - 「とても大きな音がした」より「 14時5分23秒から4秒間、非常に大きな音がした」が良い - 食物アレルギーと日記に話に戻ると、一枚の紙にいつ何を食べたかを下記、もう一 枚野上に蕁麻疹が出たことをかいたとしても、じんましんがいつ出たか書かないと 意味がない - 複数のシステムの連携をみる場合、同期の取れているタイムスタンプを使おう
46. どんなに短い鉛筆でも、どんなに良い記憶力に勝る - 細かな点は記憶にたよってはならない。記録しよう - 自分にとって重要でないものが、別の問題を扱う他の人にとって重要なこともある - デバッグログやトレースを保存しておき、ログにでない事象や状況は注釈として残し ておこう - 全てを記録しよう
47. 7. 電源を確認する
48. 自分の憶測を疑う - 自分の憶測を絶対に信じてはいけない - 特に説明のつかない問題に遭遇したとき - 「プラグは差し込まれているか」と自問しよう - 凝ったデジタルチップがなぜ正常に動作しないかを疑問に思い、それでいながら実 際に電源が流れているかどうかは確認しない - 実行していると思っているコードは本当に実行しているだろう - 実際には古いコードを読み込みロードしている可能性はないだろうか - トラブルの原因が土台にあることはよくある - この世のものと思えないような問題にぶつかったら、そこで立ち止まり足元を見よう
49. ３マス目からはじめない - エンジンがかからない場合、もう一つ検討すべきなのは、エンジンをかける時の状 況が正しいかどうかである - プラグが差し込まれているだろうか、スタートボタンを押しただろうか - 必ず最初からはじめよう - プログラムを実装する前にメモリーが初期化されることを前提としていても、それを明示的に行わな ければ、状況は悪化するだけである
50. ツールをテストする - ツールも開発者が作ったものだ。ツール自体にバグがある可能性がある - ツールにはバグがないというのは幻想だ - デバッグツールについても思い違いがあるかもしれない。バッテリーの切れた断線 チェッカーを使って何らかの接続のテストしたら、正しい配線でもピープ音が鳴ら ず、接続不良だと勘違いするだろう - 間に配線がない状態でチェッカー自体のテストが必要である - デバッグログなどを入れた場合、まずコードを直す前にログが出力されることを確 認しよう
51. バグの話 - 築90年の家で突然ボイラーが止まってしまった - 石油で動いていたので給油が間に合ってないと思い、給油の目盛をみたが問題な かった - そこでボイラーの修理屋を呼んだ - 修理屋も真っ先に目盛を見に行った。 - それは確認したと話したあったのだが、彼が懐中電灯ので目盛をドンっと叩くと、メモリが 0に急降 下した - 修理屋は補充用の石油を給油して、私を都会ズレしたまぬけなやつだと冷たい目 で見て帰っていった
52. 8. 新しい視点でものをみる
53. 「事件の状況をはっきりさせるには、他人に話して聞かせるのが一番さ」
 （シャーロック・ホームズ）
54. バグの話 - 車の調子がおかしくなった。車をバックさせるとブレーキライトのヒューズが飛ぶ - すでにヒューズをいくつかダメにしていたので、車に詳しい同僚に聞いてみた - 同僚は「車内灯が車のフレームにぶつかって配線を締め付けているんだ。車内灯 をあけて、それを取り出してしまい、まわりに丈夫なビニールテープで巻いておけば 大丈夫さ」 - 結果、直った - そんなことはよくあるらしい
55. 助けを求める - 問題をそっくり誰かに押し付けてしまいたいという願望は別として、助けを求める理 由は3つある - 新しいものの味方 - 専門技術 - 経験
56. 新しい見解を吹き込む - 固定観念にとらわれていると全体像を眺めることは難しい - 全てに対して誰もが先入観を持っている - 先入観があると、実際に何が起きているかが見えなくなる - 偏見のない視点で問題を見つめる人がすばらしい見識をもたらし、新しいアプロー チのきっかけを与えてくれるのはよくあることだ - 問題を他人に説明すると、自分の中に新しいものの見方が生まれ、問題が解決す ることがある
57. 専門家や経験者に聞く - 車内灯がショートした話のように同じような状況を目撃したことがあり、何が問題な のかをすぐに説明できる人がいる - 特定分野の経験を積んでいる人はなかなか見つけられないもので、したがって高く つく。ただし、投資する価値があるかもしれない
58. バグのはなし - 引退するまで長年にわたって大きな工場で機械を管理している男がいた - 彼が引退してからしばらくの間、工場は問題なく稼働していた。しかしある日機械が 止まってしまい、新人の整備士のあらゆる努力もむなしく2度と動かなくなった - 工場主は引退した男に電話をかけ、状況を説明し助けてくれるように頼んだ - すると男は修理に１万ドルはかかるだろうと答えた。法外な要求だったが、工場側は切羽詰まって いたので、その要求を飲んだ - 男は道具箱を下げて工場にやってくると、機会が設定してあるところに向かった - そして、ハンマーを取り出すと、機械の側面を一回だけ強く叩いた。すると機械が動き出した - 工場主が「ハンマーを一回叩いただけで一万ドルとだと？」と激怒すると「それは違 う。ハンマーで叩くのは10ドル、どこを叩けば良いかを知っていることに9,990ドル だ」と、誤りを正した
59. 助けはどこからでも得られる - 新しい見識が必要なのか、専門知識が必要なのか、経験が必要なのか、それとも これらの組み合わせが必要なのか。 - 会社の同僚もその一人 - サードパーティーの装置やソフトウェアなら、そのベンダーに聞ける - 問い合わせベンダーがいない場合やいても連絡が取れない場合のアドバイス「もう 一度マニュアルを読む」だ - 1のルールにしたがっていれば、マニュアルをもう読んでいるはずだから、問題への新たな視点でマ ニュアルをもう一度読んでみよう - あるいは理解できなかったものが理解できるようになっているかもしれない - ツール、プログラミング言語、設計作法、デバッグに関しても、多くの情報源がある - 近所の書店やオンライン書店、関連のある雑誌やニュースレターやリリース、全てが情報源。専門 家は周りに溢れている
60. プライドを捨てる - 助けを求めることは、無能の証ではない - バグを何とか修正したいという願望の表れである - 新しい見解や専門知識や経験を取り入れ、より素早くバグを改修できる - 援助を選んだあなたの 賢明さを表す - 逆もまたしかりで、自分はおろかで、専門家が神であるうなどとは考えないこと - 専門家もミスを犯す。それが自分のミスであると思い込むと泥沼にはまる
61. バグの話 - B-treeと呼ばれる大きなデータベースのインデックス構造を利用するプログラムを 書いていたときのことである - コンピュータサイエンスに非常に詳しい同僚とコードを書いていた - ある時、自宅でソースコードを見直していると、彼のプログラムに理解できない部分 があると気づいた - ある条件が揃うと、ソフトウェアがツリー構造を作り直すときにデータブロックをそっくり破壊している ようなのだ - 自分の考えがどこか間違えているかを突き止めようとして何時間も奮闘した - しかたなく出社して同僚に、なぜここが正しく動作するのかわからないと聞いて - 同僚は「これはバグだね」と言った
62. 持論ではなく症状を報告する - 新しい見解を持つ誰かに聞くのは自分の理論では結論が出せないからだ - それなのに持論を展開するとせっかくの正しい考えが自分の持論に引きずりこんで しまう - それだけなく先入観は重要な事実を隠してしまうかもしれない - 断固たる態度で望むこと - 助けを求める時は下記を説明すること - 何が起きたのか - 何を見たか - 状況を - 腹痛のために訪れた病院で医者が聞きたがっているのは、あなたがインターネット で調べて骨髄癌であると確認していることではなく、どのような痛みかである - ゼネラルモーター社が欲しいのは月曜日に組み立て、二日酔いの組み立て工がフィニアピンをきつ く締めすぎた話ではない。寒い朝にエンジンがかからないことである
63. 確信する必要はない - 物事にはあいまいなグレーゾーンがある - なぜそうなのかよくわからない、こういう情報も提示する価値がある - あなたが理解していない、もしくは期待していないものが発見されたのだ - 物おじせず情報として提示しよう
64. 9. あなたがしなければ 問題は解決しない
65. バグの話 - ある人が中古車を購入した - 中古車でロサンゼルスを通って北米大陸を横断した。北の丘陵に通じる長く険しい 丘にに来た時、アクセルを目一杯踏んでスピードを維持していたが、丘の頂上にた どり着く前にエンジンが突然止まった - もう一度エンジンをかけてみた、キーを回すとエンジンはすぐにかかった - 次に丘の頂上に着く時は同じ問題はおきなかった - また別の地域を丘を登っているとまたエンジンが止まってしまった - エンジンをかけなおすとまたかかった - その冬、まったく平坦な道を制限速度で走っている時に、またエンジンが止まってし まった。 - 時速70-80kmを超えると、しばらくして車がエンストすることに気づいた
66. バグの話 - 修理店や持っていった - 彼らがいうには「電気系統の問題」だそうで、ケーブルを何本か交換してもらい、 75ドルもし払わさ れたからといって、彼らがデバッグの方法を知っているとは限らないことを私は思い知らされた - 一連の出来事は - アクセルを目一杯踏んだ時に起こったことだった - エンジンはキャブレターから送り込まれた燃料を燃やすことは知っている - もしかしたらキャブレター内部の燃料が切れた時にエンストしているのでは？ - 「8: 新しい視点で物を見る」と言うルールを適用し、職場でコーヒーメーカーの周り にたむろしている人々に「ガソリンタンクからキャブレターへの燃料供給を妨げるも のがあるとすれば何かな？」 - 「燃料フィルタの汚れさ」 - 私は50セントの燃料フィルタを書い、自分で交換し、問題を解決した - 修理店の問題はほんとうに解決されたかどうかの判断はつかなかったはずだ
67. 本当に解決したかを確認する - 「2: わざと失敗する」で失敗する手順と状況は確認済みなので、その手順と状況に 従い再テストする - 修正が上手くいったと決めつけてはならない
68. 本当に自分が解決したかを確認する - 修正した部分を元に戻して問題が再発するか確認しよう - 修正すべき部分だけを修正し、修正された部分を失敗する状態に戻し、さらに再び 失敗された状態に戻す - こうしてはじめて問題が修正されたことが証明される - 理由としてデバッグの最中に、テストの手順やソフトウェアまたはハードウェアの一 部など正式な「修正」の一部でないものまで変更してしまうことがよくあるから - 変更による影響がなければ良いが、それによって偶然問題が解決される場合や、見えなくなる場合 がある - 変更による影響を受けていない顧客に修正を配布してお、顧客上のシステムでは 相変わらず問題が起きる
69. バグの話（セサミストリートの話） - スーパーグローバーとベティールーがコンピューターの電源を入れようと奮闘して いた - スーパーグローバーが「飛び跳ねて、Wubba!っていうと電源が入るんじゃないか な」と言って「Wubba!Wubba!Wubba!」と言って大声をあげている間にベティールー が電源ボタンを見つけた - ベティールーが電源ボタンを押すとコンピュータの電源が入った - グローバーはベティールーが何をしたかも聞かずに、電源が入ったのを見て、自分がコンピュータ の電源を入れる重要な手段を見つけたと確信した
70. 自然になくなることはあり得ない - あなたが修正しない限り、問題は解決しない - バグがなくなったと信じたいのは誰しもが同じだ - ただ、また失敗する - それまで失敗していたシステムが、状況が何か変わったため失敗しなくなった（ある いは頻度が減った）としよう - この場合「その2: わざと失敗してみる」に戻って、たましか起きない失敗をもっと頻繁に再現させる 方法を読み返そう - 色々修正してしまっているなら元の状態に戻して、対象のシナリオでテストしよう - 新しいソフトウェアで再現できないとしたら、問題は解決されたのかもしれない、両者の違いを調べ て原因を突き止めよう - 時間がない時もある - その場合は顧客の手元の対象の問題が起きた場合に備えて、情報が記録されるようにしよう - こうすれば、もう一つの利点としてその情報で問題を解決できないとしても、少なくとも顧客には、あ なたが真剣に問題を解決しようとしてるのがわかる
71. プロセスを修正する - 品質管理プロセスは本章では基本踏み込まないが、システムを修正することと、シ ステムを誤動作させたプロセスを修正することの境界線を見極めることはむずかし - そして、その境界線を超えた方が良い場合もある - 工場の床にオイルがこぼれたいたとする - オイルを拭けば良いが根本の問題は解決されていない - 金具の隙間から漏れ出しているから、締めたが止まらない - 振動が激しい機械は 4本ボルトで締めた方が良いところを 2本で締めている - これが主原因 - これも違う。このままでは新しい機械を設置した場合にも同じ問題が発生する - 要件、設計、テスト段階において機械の振動を計算に入れるように、「設計プロセ ス」を修正しなければならない