ソフトウェア開発における問題を解決するうえで（特に、顧客が非協力的である場合に）役に立つ問題特定テクニックを以下に紹介する。
顧客から情報を引き出すのに苦労したという経験はないだろうか？また、顧客が簡単に提供できるはずの情報であっても、手に入れるために苦労させられたことがあるのではないだろうか？
顧客と筆者の間で以下のような会話が交わされたことがある。
顧客：「壊れている」
筆者：「壊れているって、どういうふうにですか？」
顧客：「ちゃんと動かないんだ」
筆者：「何をしようとするとちゃんと動かないんですか？」
顧客：「ほら、あれだよ。コンパイルはうまくできるんだけど、実行しようとすると動かなくなってしまうんだ」
筆者：「動かなくなるって、どういうふうにですか？」
顧客：「エラーメッセージが出て、停止してしまうんだ」
筆者：「エラーメッセージの内容を教えてもらえますか？」
顧客：「メモしてないんだけど」
もちろんのことながら、筆者のテスト環境では問題を再現できない。このため筆者としては、少なくとも相手のシステムにアクセスさせてもらう必要がある。しかし顧客は深入りされたくないと考えており、ただ問題を解決してほしいと思っているのである。彼らは口にこそ出さないものの、心の中では「このソフトウェア屋ははったりばかりで、テストすらしていないのではないだろうか？会社は高い金を払っているというのに、われわれのユーザーの目の前でおかしくなるなんて。そのうえ、直すのにさらに料金がかかるとは！」と思っていることだろう。彼らは筆者に手を貸したいなどとは露ほども思っていないというわけだ。ところが、彼らのシステムでも問題が再現しない場合があるため、支援するにはどうしても、彼らからの情報提供が必要となってくるのである。
筆者の顧客のほとんどはソフトウェア開発者なのだが、彼らはしばしば大量のコードを筆者の目の前に積み上げ、その中に潜んでいる問題を見つけ出すよう依頼するという行動に出て、筆者を当惑させるのである。彼らに対して優れた問題解決テクニックを教えようとする試みも、しばしば行ってはいるものの（本来、釈迦に説法を説くようなものだ）、反発されることもあるのには驚かされる。まあ、料金請求の対象となる時間が増えるだけなのだが。
以下に、筆者が使用している問題解決テクニックを紹介する。これらの多くはソフトウェアのバグに対してのみならず、さまざまな問題に対して適用できるはずだ。
