発声練習

■[研究] トラブル発生時の原因切り分け手順

「あの、〜が＊＊＊で困っているんですけど」という助力要請が学生からくるんだけど、余裕がないときにはこういう助力要請はきつい。ある程度、原因を切り分けて、自分が対処できないことが判明してから助力を請うて欲しい（なお、切り分け自体に助力を請うのはOK。なぜならば、二回目は以降は切り分けてから助力を請うてくることが予想できるから）。

最低限3つに分類して欲しい。

• ハードウェア的環境に起因するトラブル
  • 実験なら、実験機器自体が壊れているかいないか？実験機器同士が適切に接続されているかどうか？
  • 計算機なら、そもそも電源が入っているか？ケーブル類ははずれかけていないか？
• ソフトウェア的環境に起因するトラブル
  • 実験なら、実験環境（温度、湿度、明度など）が実験計画どおりか？
  • 計算機なら、使用しているOSやコンパイラー、各種ソフトウェアのバージョンは適切かどうか？設定が適切かどうか？
• 自分が行なった行為に起因するトラブル

この分類自体をやらされるのは結構しんどい。それが5月とか6月とかだと別に気にしないのだけど、12月、1月、2月に分類まで求められると「お前、今まで何やってきたんだよ！？」と思ってしまう。

トラブルが自分が行なった行為に起因すると思われる場合は、以下の手順で原因を探る。

1. 正解（自分が得たいと思っていたこと、自分が行ないたいと思っていたこと、予想される結果）を書き出す
2. 正解を得るための手順を丁寧に列挙する（作業手順、実験手順、実験方法、試薬・入力データの列挙）
3. 2で列挙した手順を眺め、ミスが起こりうる部分をすべて列挙する
4. 3で列挙したミスが起こりうる部分に関して、一つ一つミスしていなかったかどうかをチェックする

プログラムのデバッグなどでもそうだけど、思い込みがミスの見逃しの原因になりやすい。なので、急ぐ気持ちを一度抑えて、自分が行なった行為全体を見回してみるのが無難。ちなみに、上記の手順を実験／コーディング前に行なうのがテスト駆動開発（TDD）の基本コンセプトであると私は理解している。

あと、正しさや妥当性に関して誰も保証していない事柄に関しては、上の手順でしか自分がやったことが正しい、あるいは妥当であることを他人に説明することができない。「こうやっておけば、いいんでしょ？」ということが成り立っていないので、「こうやったら適切かと思うのですが、あなたはどうお考えですか？」というスタイルで話を進めないといけない。

Permalink | コメント(0) | トラックバック(0)