システムを理解する
- マニュアルを読む
- 全部徹底的に読む
- 何が正しいか知る
- 現状を知る
- ツールを知る
- 調査する
分割して攻略する
- 調査範囲を絞り込む
- 妥当な範囲を知る
- どちら側にいるのかを知る
- 目立つテストパターンを使用する
- 問題のある方から始める
- わかっているバグをまず修正する
- ノイズは先に修正する
一度に一つずつ変える
- 散弾銃ではなくライフル銃を使用する
- 両手で真鍮の取っ手をつかむ
- 一度に一つずつテストする
- 正常なものと比較する
- 最後に動いていたときから何を変更したか考える
履歴をつける
- 何をどの順序で行い、何が起きたのかを記録する
- 悪魔は細部に宿る
- 関連付ける
- 設計のための履歴はテストにも役立つ
- どんなに短い鉛筆でも、どんなに良い記憶力に勝る
電源を確認する
- 自分の憶測を疑う
- ３マス目から始めない
- ツールをテストする
新しい視点でものを見る
- 新しい見識を吹き込む
- 専門家に教えを請う
- 経験者の意見を聞く
- 助けはどこからでも得られる
- プライドを捨てる
- 持論ではなく症状を報告する
- 確信する必要はない
あなたがしなければ問題は解決しない
- 本当に解決したか確認する
- 本当に自分が解決したか確認する
- 自然になくなることはあり得ない
- 原因を修正する
- プロセスを修正する
ヘルプデスクから眺めるとユーザーは曇って見えない
- デバッグルールに従う
- 処置と結果を検証する
- 自動ツールを使用する
- 推測はどれだけ単純なものであっても確認する
- 入手可能なトラブルシューティングガイドを利用する
- トラブルシューティングガイドに貢献する
システムを理解する
- マニュアルを読む
- 草刈機のトリマー線が溶けてくっつかないようにトリマーヘッドに潤滑油を差すことは、マニュアルに書いてある。
- 全部徹底的に読む
- マイクロコンピュータへの割り込みに関する説明は、37ページに埋もれている。
- 何が正しいか知る
- チェーンソーは本来大きな音を出すものである。
- 現状を知る
- エンジンの速度とタイヤの回転数は異なる可能性があり、その違いの原因はトランスミッションにある。
- ツールを知る
- 体温計のどちらの端がどうなのかを知ること。Glitch-O-Maticロジックアナライザの強力な機能の使い方を知ること。
- 調査する
- アインシュタインでさえ詳細を調べた。それなのに、Kneejerkは自分の記憶力に頼った。
わざと失敗してみる
- もう一度やってみる
- 問題を見て、その原因の糸口をつかみ、問題が解決したかどうか確認するために、もう一度やってみる。
- 最初から始める
- 整備士は窓が凍りつく前に車を洗車に出したことを知らねばならない。
- 失敗を促す
- 水漏れする窓にホースで水をかけてみる。
- だが、失敗をシミュレートしてはならない
- 別の「よく似た」窓ではなく、水漏れする窓にホースで水をかけること。
- 制御されていない条件を見つけ出し、とにかく問題を発生させる
- いろいろな方法を変えて、できることはすべてやる。大声を上げるまで、揺らしたり、ガタガタ鳴らしたり、回転させたり、ねじったりしてみる。
- すべてを記録して、たまにしか起きないバグの痕跡を見つけ出す。
- 私たちのボンディングシステムは、通話の順序がごちゃ混ぜになると、必ず、そしてその状況でのみ失敗した。
- 統計データにだまされるな
- ボンディングの問題は時間帯に関連しているように見えたが、実際には電話回線を独り占めしていた地元の若者たちが原因だった。
- 「そんなはずはない」ことが起こる可能性もある
- アイスクリームの種類さえも問題となる可能性がある。
- デバッグツールは絶対に捨てない
- ロボットのラケットがいつか役に立つかもしれない。
考えるのをやめて観察する
- 問題を見る
- シニアエンジニアは、問題をその目で見て、原因を突き止めることができた。若手エンジニアは、問題が何かを知っていると思い込み、壊れていないものを直した。
- 詳しく見る
- ポンプの音を聞いただけでやめてはならない。地下室へ降りて、どのポンプか調べよう。
- システムにツールを組み込む
- ソースコードデバッガ、デバッグログ、ステータスメッセージ、点滅ライト、腐った卵の臭いを使用する。
- ツールをあとから組み込む
- アナライザ、オシロスコープ、計測器、金属探知機、心電図記録装置、石鹸の泡を使用する。
- おそれずに飛び込む
- それはリリースされたソフトウェアである。壊れているのだから、開けて修理しなければならない。
- ハイゼンベルグの不確定性原理に気を付ける
- ツールがシステムに悪影響を及ぼさないようにする。
- あくまでも検索を絞り込むために推測する
- メモリーのタイミングがずれていると推測してもかまわないが、タイミングを変えるものを組み込む前に、それを調べること。
分割して攻略する
- 調査範囲を絞り込む
- 1から100の間の数字は逐次近似法で７回で言い当てられる。
- 妥当な範囲を知る
- 数字が135なのに、範囲が1〜100であると思い込んでいると、範囲を広げなければならなくなる。
- どちら側にいるのかを知る
- 汚れた排水があるなら、排水管は上流にある。なければ、排水管は下流にある。
- 目立つテストパターンを使用する
- きれいな水の中では、汚泥が川に流れ込むとすぐにわかる。
- 問題のある方から始める
- 正常な部分が多すぎて検証しきれない。問題のある部分から始めて、原因をたどっていく。
- わかっているバグをまず修正する
- バグは互いをかくまう。見つけたらすぐに排除しよう。
- ノイズは先に修正する
- わかっているものをそのままにしておくと、システムのほかの部分を壊しやすい。ただし、ささいな問題や感覚的な問題に夢中になってはならない。
一度に一つずつ変える
新しい視点でものを見る
- 新しい見識を吹き込む
- マネキンでさえ、問題を解決するのに役立つ可能性がある。
- 専門家に教えを請う
- フェーズパラメータが正しくないことが確認できたのは、VGAキャプチャのベンダーだけだった。
- 経験者の意見を聞く
- 車内灯のワイヤが挟まっていることがすぐにわかる。
- 助けはどこからでも得られる
- 同僚、ベンダー、Web、書店はあなたがやって来るのを待っている。
- プライドを捨てる
- バグは必ず発生する。自分でバグを修正することではなく、バグを修正すること自体に誇りを持とう。
- 持論ではなく症状を報告する
- 相手を自分のやり方に引きずり込んではならない。
- 確信する必要はない
- シャツが格子縞だったことを話そう。
あなたがしなければ問題は解決しない
- 本当に解決したか確認する
- 配線が問題であると思い込み、燃料フィルタが汚れたまま道路に出てはいけない。
- 本当に自分が解決したか確認する
- 「Wubba!」に効き目があったのではないかもしれない。
- 自然になくなることはあり得ない
- 「わざと失敗させる」手法を使って元に戻してみる。それを出荷しなければならない場合は、現場で問題が起きたときにそれを記録するためのトラップを仕込む。
- 原因を修正する
- 別の変圧器を故障させる前に、役に立たない８トラックのデッキを取り出そう。
- プロセスを修正する
- オイルをきれいにふき取るだけで満足してはならない。機械の設計プロセスを修正しよう。
ヘルプデスクから眺めるとユーザーは曇って見えない
- デバッグルールに従う
- 無知なユーザーに惑わされずに、デバッグルールを適用する方法を見つけなければならない。
- 処置と結果を検証する
- ユーザーはあなたが言ったことを誤解し、ミスを犯す。ユーザーがしたことと言ったことを一つ一つ検証して、問題を早期に発見しよう。
- 自動ツールを使用する
- システムが生成するログやリモート監視／制御ツールを使って、ユーザーを介入させない。
- 推測はどれだけ単純なものであっても確認する
- ワープロを作動させるには電力が必要であることに気付かない人もいる。
- 入手可能なトラブルシューティングガイドを利用する
- その設計が正常であることはすでに判明しているかもしれない。履歴を無視してはならない。
- トラブルシューティングガイドに貢献する
- 既知のシステムで新しい問題を発見したら、すべてを文書にまとめて次のサポートスタッフを支援しよう。
システムを理解する
- マニュアルを読む
- 全部徹底的に読む
- 何が正しいか知る
- 現状を知る
- ツールを知る
- 調査する
分割して攻略する
- 調査範囲を絞り込む
- 妥当な範囲を知る
- どちら側にいるのかを知る
- 目立つテストパターンを使用する
- 問題のある方から始める
- わかっているバグをまず修正する
- ノイズは先に修正する
一度に一つずつ変える
- 散弾銃ではなくライフル銃を使用する
- 両手で真鍮の取っ手をつかむ
- 一度に一つずつテストする
- 正常なものと比較する
- 最後に動いていたときから何を変更したか考える
履歴をつける
- 何をどの順序で行い、何が起きたのかを記録する
- 悪魔は細部に宿る
- 関連付ける
- 設計のための履歴はテストにも役立つ
- どんなに短い鉛筆でも、どんなに良い記憶力に勝る
電源を確認する
- 自分の憶測を疑う
- ３マス目から始めない
- ツールをテストする
新しい視点でものを見る
- 新しい見識を吹き込む
- 専門家に教えを請う
- 経験者の意見を聞く
- 助けはどこからでも得られる
- プライドを捨てる
- 持論ではなく症状を報告する
- 確信する必要はない
あなたがしなければ問題は解決しない
- 本当に解決したか確認する
- 本当に自分が解決したか確認する
- 自然になくなることはあり得ない
- 原因を修正する
- プロセスを修正する
ヘルプデスクから眺めるとユーザーは曇って見えない
- デバッグルールに従う
- 処置と結果を検証する
- 自動ツールを使用する
- 推測はどれだけ単純なものであっても確認する
- 入手可能なトラブルシューティングガイドを利用する
- トラブルシューティングガイドに貢献する
システムを理解する
- マニュアルを読む
- 草刈機のトリマー線が溶けてくっつかないようにトリマーヘッドに潤滑油を差すことは、マニュアルに書いてある。
- 全部徹底的に読む
- マイクロコンピュータへの割り込みに関する説明は、37ページに埋もれている。
- 何が正しいか知る
- チェーンソーは本来大きな音を出すものである。
- 現状を知る
- エンジンの速度とタイヤの回転数は異なる可能性があり、その違いの原因はトランスミッションにある。
- ツールを知る
- 体温計のどちらの端がどうなのかを知ること。Glitch-O-Maticロジックアナライザの強力な機能の使い方を知ること。
- 調査する
- アインシュタインでさえ詳細を調べた。それなのに、Kneejerkは自分の記憶力に頼った。
わざと失敗してみる
- もう一度やってみる
- 問題を見て、その原因の糸口をつかみ、問題が解決したかどうか確認するために、もう一度やってみる。
- 最初から始める
- 整備士は窓が凍りつく前に車を洗車に出したことを知らねばならない。
- 失敗を促す
- 水漏れする窓にホースで水をかけてみる。
- だが、失敗をシミュレートしてはならない
- 別の「よく似た」窓ではなく、水漏れする窓にホースで水をかけること。
- 制御されていない条件を見つけ出し、とにかく問題を発生させる
- いろいろな方法を変えて、できることはすべてやる。大声を上げるまで、揺らしたり、ガタガタ鳴らしたり、回転させたり、ねじったりしてみる。
- すべてを記録して、たまにしか起きないバグの痕跡を見つけ出す。
- 私たちのボンディングシステムは、通話の順序がごちゃ混ぜになると、必ず、そしてその状況でのみ失敗した。
- 統計データにだまされるな
- ボンディングの問題は時間帯に関連しているように見えたが、実際には電話回線を独り占めしていた地元の若者たちが原因だった。
- 「そんなはずはない」ことが起こる可能性もある
- アイスクリームの種類さえも問題となる可能性がある。
- デバッグツールは絶対に捨てない
- ロボットのラケットがいつか役に立つかもしれない。
考えるのをやめて観察する
- 問題を見る
- シニアエンジニアは、問題をその目で見て、原因を突き止めることができた。若手エンジニアは、問題が何かを知っていると思い込み、壊れていないものを直した。
- 詳しく見る
- ポンプの音を聞いただけでやめてはならない。地下室へ降りて、どのポンプか調べよう。
- システムにツールを組み込む
- ソースコードデバッガ、デバッグログ、ステータスメッセージ、点滅ライト、腐った卵の臭いを使用する。
- ツールをあとから組み込む
- アナライザ、オシロスコープ、計測器、金属探知機、心電図記録装置、石鹸の泡を使用する。
- おそれずに飛び込む
- それはリリースされたソフトウェアである。壊れているのだから、開けて修理しなければならない。
- ハイゼンベルグの不確定性原理に気を付ける
- ツールがシステムに悪影響を及ぼさないようにする。
- あくまでも検索を絞り込むために推測する
- メモリーのタイミングがずれていると推測してもかまわないが、タイミングを変えるものを組み込む前に、それを調べること。
分割して攻略する
- 調査範囲を絞り込む
- 1から100の間の数字は逐次近似法で７回で言い当てられる。
- 妥当な範囲を知る
- 数字が135なのに、範囲が1〜100であると思い込んでいると、範囲を広げなければならなくなる。
- どちら側にいるのかを知る
- 汚れた排水があるなら、排水管は上流にある。なければ、排水管は下流にある。
- 目立つテストパターンを使用する
- きれいな水の中では、汚泥が川に流れ込むとすぐにわかる。
- 問題のある方から始める
- 正常な部分が多すぎて検証しきれない。問題のある部分から始めて、原因をたどっていく。
- わかっているバグをまず修正する
- バグは互いをかくまう。見つけたらすぐに排除しよう。
- ノイズは先に修正する
- わかっているものをそのままにしておくと、システムのほかの部分を壊しやすい。ただし、ささいな問題や感覚的な問題に夢中になってはならない。
一度に一つずつ変える
新しい視点でものを見る
- 新しい見識を吹き込む
- マネキンでさえ、問題を解決するのに役立つ可能性がある。
- 専門家に教えを請う
- フェーズパラメータが正しくないことが確認できたのは、VGAキャプチャのベンダーだけだった。
- 経験者の意見を聞く
- 車内灯のワイヤが挟まっていることがすぐにわかる。
- 助けはどこからでも得られる
- 同僚、ベンダー、Web、書店はあなたがやって来るのを待っている。
- プライドを捨てる
- バグは必ず発生する。自分でバグを修正することではなく、バグを修正すること自体に誇りを持とう。
- 持論ではなく症状を報告する
- 相手を自分のやり方に引きずり込んではならない。
- 確信する必要はない
- シャツが格子縞だったことを話そう。
あなたがしなければ問題は解決しない
- 本当に解決したか確認する
- 配線が問題であると思い込み、燃料フィルタが汚れたまま道路に出てはいけない。
- 本当に自分が解決したか確認する
- 「Wubba!」に効き目があったのではないかもしれない。
- 自然になくなることはあり得ない
- 「わざと失敗させる」手法を使って元に戻してみる。それを出荷しなければならない場合は、現場で問題が起きたときにそれを記録するためのトラップを仕込む。
- 原因を修正する
- 別の変圧器を故障させる前に、役に立たない８トラックのデッキを取り出そう。
- プロセスを修正する
- オイルをきれいにふき取るだけで満足してはならない。機械の設計プロセスを修正しよう。
ヘルプデスクから眺めるとユーザーは曇って見えない
- デバッグルールに従う
- 無知なユーザーに惑わされずに、デバッグルールを適用する方法を見つけなければならない。
- 処置と結果を検証する
- ユーザーはあなたが言ったことを誤解し、ミスを犯す。ユーザーがしたことと言ったことを一つ一つ検証して、問題を早期に発見しよう。
- 自動ツールを使用する
- システムが生成するログやリモート監視／制御ツールを使って、ユーザーを介入させない。
- 推測はどれだけ単純なものであっても確認する
- ワープロを作動させるには電力が必要であることに気付かない人もいる。
- 入手可能なトラブルシューティングガイドを利用する
- その設計が正常であることはすでに判明しているかもしれない。履歴を無視してはならない。
- トラブルシューティングガイドに貢献する
- 既知のシステムで新しい問題を発見したら、すべてを文書にまとめて次のサポートスタッフを支援しよう。
システムを理解する
- マニュアルを読む
- 全部徹底的に読む
- 何が正しいか知る
- 現状を知る
- ツールを知る
- 調査する
分割して攻略する
- 調査範囲を絞り込む
- 妥当な範囲を知る
- どちら側にいるのかを知る
- 目立つテストパターンを使用する
- 問題のある方から始める
- わかっているバグをまず修正する
- ノイズは先に修正する
一度に一つずつ変える
- 散弾銃ではなくライフル銃を使用する
- 両手で真鍮の取っ手をつかむ
- 一度に一つずつテストする
- 正常なものと比較する
- 最後に動いていたときから何を変更したか考える
履歴をつける
- 何をどの順序で行い、何が起きたのかを記録する
- 悪魔は細部に宿る
- 関連付ける
- 設計のための履歴はテストにも役立つ
- どんなに短い鉛筆でも、どんなに良い記憶力に勝る
電源を確認する
- 自分の憶測を疑う
- ３マス目から始めない
- ツールをテストする
新しい視点でものを見る
- 新しい見識を吹き込む
- 専門家に教えを請う
- 経験者の意見を聞く
- 助けはどこからでも得られる
- プライドを捨てる
- 持論ではなく症状を報告する
- 確信する必要はない
あなたがしなければ問題は解決しない
- 本当に解決したか確認する
- 本当に自分が解決したか確認する
- 自然になくなることはあり得ない
- 原因を修正する
- プロセスを修正する
ヘルプデスクから眺めるとユーザーは曇って見えない
- デバッグルールに従う
- 処置と結果を検証する
- 自動ツールを使用する
- 推測はどれだけ単純なものであっても確認する
- 入手可能なトラブルシューティングガイドを利用する
- トラブルシューティングガイドに貢献する
システムを理解する
- マニュアルを読む
- 草刈機のトリマー線が溶けてくっつかないようにトリマーヘッドに潤滑油を差すことは、マニュアルに書いてある。
- 全部徹底的に読む
- マイクロコンピュータへの割り込みに関する説明は、37ページに埋もれている。
- 何が正しいか知る
- チェーンソーは本来大きな音を出すものである。
- 現状を知る
- エンジンの速度とタイヤの回転数は異なる可能性があり、その違いの原因はトランスミッションにある。
- ツールを知る
- 体温計のどちらの端がどうなのかを知ること。Glitch-O-Maticロジックアナライザの強力な機能の使い方を知ること。
- 調査する
- アインシュタインでさえ詳細を調べた。それなのに、Kneejerkは自分の記憶力に頼った。
わざと失敗してみる
- もう一度やってみる
- 問題を見て、その原因の糸口をつかみ、問題が解決したかどうか確認するために、もう一度やってみる。
- 最初から始める
- 整備士は窓が凍りつく前に車を洗車に出したことを知らねばならない。
- 失敗を促す
- 水漏れする窓にホースで水をかけてみる。
- だが、失敗をシミュレートしてはならない
- 別の「よく似た」窓ではなく、水漏れする窓にホースで水をかけること。
- 制御されていない条件を見つけ出し、とにかく問題を発生させる
- いろいろな方法を変えて、できることはすべてやる。大声を上げるまで、揺らしたり、ガタガタ鳴らしたり、回転させたり、ねじったりしてみる。
- すべてを記録して、たまにしか起きないバグの痕跡を見つけ出す。
- 私たちのボンディングシステムは、通話の順序がごちゃ混ぜになると、必ず、そしてその状況でのみ失敗した。
- 統計データにだまされるな
- ボンディングの問題は時間帯に関連しているように見えたが、実際には電話回線を独り占めしていた地元の若者たちが原因だった。
- 「そんなはずはない」ことが起こる可能性もある
- アイスクリームの種類さえも問題となる可能性がある。
- デバッグツールは絶対に捨てない
- ロボットのラケットがいつか役に立つかもしれない。
考えるのをやめて観察する
- 問題を見る
- シニアエンジニアは、問題をその目で見て、原因を突き止めることができた。若手エンジニアは、問題が何かを知っていると思い込み、壊れていないものを直した。
- 詳しく見る
- ポンプの音を聞いただけでやめてはならない。地下室へ降りて、どのポンプか調べよう。
- システムにツールを組み込む
- ソースコードデバッガ、デバッグログ、ステータスメッセージ、点滅ライト、腐った卵の臭いを使用する。
- ツールをあとから組み込む
- アナライザ、オシロスコープ、計測器、金属探知機、心電図記録装置、石鹸の泡を使用する。
- おそれずに飛び込む
- それはリリースされたソフトウェアである。壊れているのだから、開けて修理しなければならない。
- ハイゼンベルグの不確定性原理に気を付ける
- ツールがシステムに悪影響を及ぼさないようにする。
- あくまでも検索を絞り込むために推測する
- メモリーのタイミングがずれていると推測してもかまわないが、タイミングを変えるものを組み込む前に、それを調べること。
分割して攻略する
- 調査範囲を絞り込む
- 1から100の間の数字は逐次近似法で７回で言い当てられる。
- 妥当な範囲を知る
- 数字が135なのに、範囲が1〜100であると思い込んでいると、範囲を広げなければならなくなる。
- どちら側にいるのかを知る
- 汚れた排水があるなら、排水管は上流にある。なければ、排水管は下流にある。
- 目立つテストパターンを使用する
- きれいな水の中では、汚泥が川に流れ込むとすぐにわかる。
- 問題のある方から始める
- 正常な部分が多すぎて検証しきれない。問題のある部分から始めて、原因をたどっていく。
- わかっているバグをまず修正する
- バグは互いをかくまう。見つけたらすぐに排除しよう。
- ノイズは先に修正する
- わかっているものをそのままにしておくと、システムのほかの部分を壊しやすい。ただし、ささいな問題や感覚的な問題に夢中になってはならない。
一度に一つずつ変える
新しい視点でものを見る
- 新しい見識を吹き込む
- マネキンでさえ、問題を解決するのに役立つ可能性がある。
- 専門家に教えを請う
- フェーズパラメータが正しくないことが確認できたのは、VGAキャプチャのベンダーだけだった。
- 経験者の意見を聞く
- 車内灯のワイヤが挟まっていることがすぐにわかる。
- 助けはどこからでも得られる
- 同僚、ベンダー、Web、書店はあなたがやって来るのを待っている。
- プライドを捨てる
- バグは必ず発生する。自分でバグを修正することではなく、バグを修正すること自体に誇りを持とう。
- 持論ではなく症状を報告する
- 相手を自分のやり方に引きずり込んではならない。
- 確信する必要はない
- シャツが格子縞だったことを話そう。
あなたがしなければ問題は解決しない
- 本当に解決したか確認する
- 配線が問題であると思い込み、燃料フィルタが汚れたまま道路に出てはいけない。
- 本当に自分が解決したか確認する
- 「Wubba!」に効き目があったのではないかもしれない。
- 自然になくなることはあり得ない
- 「わざと失敗させる」手法を使って元に戻してみる。それを出荷しなければならない場合は、現場で問題が起きたときにそれを記録するためのトラップを仕込む。
- 原因を修正する
- 別の変圧器を故障させる前に、役に立たない８トラックのデッキを取り出そう。
- プロセスを修正する
- オイルをきれいにふき取るだけで満足してはならない。機械の設計プロセスを修正しよう。
ヘルプデスクから眺めるとユーザーは曇って見えない
- デバッグルールに従う
- 無知なユーザーに惑わされずに、デバッグルールを適用する方法を見つけなければならない。
- 処置と結果を検証する
- ユーザーはあなたが言ったことを誤解し、ミスを犯す。ユーザーがしたことと言ったことを一つ一つ検証して、問題を早期に発見しよう。
- 自動ツールを使用する
- システムが生成するログやリモート監視／制御ツールを使って、ユーザーを介入させない。
- 推測はどれだけ単純なものであっても確認する
- ワープロを作動させるには電力が必要であることに気付かない人もいる。
- 入手可能なトラブルシューティングガイドを利用する
- その設計が正常であることはすでに判明しているかもしれない。履歴を無視してはならない。
- トラブルシューティングガイドに貢献する
- 既知のシステムで新しい問題を発見したら、すべてを文書にまとめて次のサポートスタッフを支援しよう。
