スピードを優先し、品質が犠牲になっているタイプに意識して欲しいこと

エンジニアに限らずどんな職種でも次のどちらかに偏り過ぎてしまう人はいるものです。
当たり前ですが、どちらが良い悪いではなく、ただのバランスの問題です。
タイプA：スピードを優先し、品質が犠牲になっている
タイプB：品質を優先し、スピードが犠牲になっている

今回はタイプA：スピードを優先し、品質が犠牲になっている傾向が多い方に意識していただきたいのは「考え方」を学ぶです。
ビジネスにおいてスピードは重要ですが、スピードを意識し過ぎると単に「早く終わらせる」ことが目的になってしまいます。
ここでは例として「障害対応」を考えてみたいと思います。

考え方を学んでいないエンジニアは、今ある情報だけでいきなり解決策らしきもの探しに出かけます。
偶然、解決策に出くわすこともありますが、考え方を学んでいないので次に似たような別の障害が発生してもそれが別の原因であるとは思わないので問題も解決せず、スキルも身に付きません。

一方、考え方を学んでいるエンジニアは、まずは事態の把握（障害範囲や障害影響など）と必要な情報収集を行い、次に1つ1つ問題の切り分けを行っていきます。
次に似たような別の障害が発生しても問題の切り分けを行っていく中で前回の障害時とは何が違うのかを理解できます。
結果、問題解決できることが多くなり、その経験がまたスキルとして蓄積されていくのです。

ネイティブアメリカンの諺に次のような言葉があります。

問いを持った部族は生き残ったが、答えを持った部族は滅びた

私自身、現在でも障害対応に携わることも多いのですが、必要なのは知識よりも考え方が重要だと痛感しています。
スピードを優先し、品質が犠牲になっているタイプの方は、一足飛びに解決策に向かうのではなく、事態の把握と必要な情報収集を心掛けていただきたいと思います。
別の人が問題解決をした場合は、問題の原因などの背景や解決に至ったプロセスを確認し、次回は自分でも同じプロセスを辿れるように振り返っていただければと思います。