エンジニアのセンスとスピード感を磨く方法

大切なのはセンスとスピード感、若手エンジニアに役立つチップス

スペックにあるから必要なのか、それとも必要だからスペックにあるのか

スペック違反

スペックに書かれていたことを見逃していた事が後々判明した時、

ある人は、スペックに書いてあるんだから、とにかくやらなくてはいけないと、無条件に従おうとします。実際には必要で無いどうでも良い事項であっても。

別の人は、スペックになぜこんな事が書かれているのだろうか、本当に必要なのだろうかと背景をまず考えて、やらないと不具合が出るのか考えます。

 

スペックにあるから必要なのか、それとも必要だからスペックにあるのか。

これは「ニワトリが先か卵が先か」の言い回しではない。どちらが先か明確である。

 

スペックにあるから必要とは限らない。なぜならスペックは結構間違っている。

必要だからスペックに必ず書いてあるかと言えば、必ずしも書いてない。なぜならあまりにも常識過ぎることまで書ききれないし、そうでなくても書き落としている。

 

スペックを理解する前に、物を理解していないと、スペックを正しく理解できないし、スペックの間違いに気がつかない。自分が理解できていないことを、人に要求してはいけないの。原理原則が根底。

 

 

トラブルが起きたら

技術的なトラブルが起こったケース、原因がなかなか判明しない事は結構あります。

どのような現象が起きているのか直接的に見たり測定できないので、何が起因で何が結果なのか、何が主要因で何が助長しているのか、、因果関係が分からない、、、

 

原因が解明できないから、だれの責任か断定できない。自分は悪くない、相手が悪いと責任回避が解決をますます遅くする。

 

真実はあるのですが、そこにたどり着くために責任はまず忘れてとして真実を探さないと解決ができないのですが、そうは言ってもビジネスなので責任となると損害賠償になるので担当者レベルでは責任は認めようとはしません。

 

トラブル原因究明は、先ずは責任は問わないとしてまず皆で進めよう働きかけで責任回避の守りの心境を皆から取り払わせます。

しかし世の中言っていることとやっていることは違うので、最終的に原因が究明された時には、原因を作った所が責任を追及されてしまうことになります。

原因究明のためにいくら協力的に尽力しても、責任は逃れられません。残酷です。

 

自分が限りなく犯人だと感じたら、責任分担を少しでも軽くするにはどうしたらよいでしょうか。

原因を一つでなく複合された結果とするしかないでしょう。

「ニワトリが先か卵が先か」や「どっちもどっち」に終わらせるために、やれる対策を一度に全部施してしまうのです。その結果問題が解決できれば、何が主要因だったのか断定が出来なくなります。対策を一つ一つ試行錯誤して試して行ったら原因が断定されてしまう可能性が高まります。

自分の責任が大きいと危機感を感じたら、他の理由も探して複合要因に持っていき、対策全部同時に打って解決を一発と決める。

トラブルが起こってしまったら、逃げたくなりますが逃げられませんので前向きに対応することが一番大切です。一番怖いのはトラブル対応でお金がかかってしまうことでなく、責任逃げの態度が嫌われて信頼を失い将来の仕事のチャンスを失う事なんですね。