因果関係の理解まで至りたい
OSやM/Wというのは、「極端に間違ったことをしなければ、手を入れなくても一定の機能要件を満たす（動いちゃう）」という性質がある。もっと雑にいうと、「根拠はわからないがパラメーターの変更をランダムに試行錯誤したら、ほしい結果（振る舞い）が得られた！」ということがしばしば起きる。（障害対応にも言える話だけど）
このため、内部構造とかシステムの設計思想とかを考えずに適当に動かして、「動いたからこれでいい」「このシステムはこういうものなんだ」みたいに自分は考えてしまいがちだ。（なんかわかんないけど、パラメーター変えたら直ったのでよし！的な)
そういうときに「欲しい結果が得られたから対応をクローズします」ではなく、「やったこと（action)と得られたこと（システムの振る舞い)に因果関係って本当にあるんだっけ？ どういうメカニズムでこの結果が得られたのか、もう少し考えてみようか？」と粘って理解しようとする、考えることが大事に思う
根拠を書くことで想定している因果関係を表明する
設計において方式や設定値を決める時はこの因果関係を逆順に考える。つまり、結果→原因、ではなく、こういう手段(原因)を採用することで、こういう目的(結果)を得ようとみたいなことを考える
そのときに「何を考えてこうしたのか？」というのをできるだけ残したほうがベターだ。そうしないと、後で引きついた人がその（設計時に設計者が考えたこと）のよしあし」を評価できないから。科学で言うと、反証不可能な仮説が誕生してしまう。
「結果」という観点で見た設計の品質は「要件を満たしているのか？」であるが、「プロセス」で見たときの設計品質＝「設計者の思考や構想の組み立てのプロセス、出来上がったものの整合性・一貫性(coherentであるか？)」である。設計の瑕疵により障害発生したときに前者が槍玉にあがりやすい（なんでこんなつくりになってるんだ！）が、本質的には後者（設計時にこれって想定できていたんでしたっけ？）の方が大事に思う。
最近の考え方で言うと、ADR的な話なのかもしれない。
