エンジニアの正義とは第一に正しさに誠実であることです。 第二により高みに上り詰めることです。

丁寧に解説されていようとも技術的に誤った文章は、躍起になって否定されるものです。

たとえ口が悪く礼儀知らずだとしても、技術的に正しく、そしてそこに容易には得難い水準の知見が詰まっているならば、 その文章は賞賛されえますし、肯定的な意味で引用され語り継がれるものです。

その知見が正しいかどうか。それがエンジニアにとって最重要な事項です。 誤った知見に基づいていては何も作り上げることは出来ないのですから。 エンジニアは正しさに対して誠実でなければなりません。 誤った情報を発しないように。発してしまったら訂正するように。

失敗することは悪ではありません。 エンジニアリングというのは多数の失敗を越えて行くことです。 失敗からいかにうまく知見を得るか。 取り返しのつかない失敗をしないようにコントロールしながら、 失敗を重ねて見識を深めていくのです。

過ちて改めざる是を過ちという。

技術的な失敗も、誤った発言も、より正しいものに近づき改めるための過程となって エンジニアを育むものです。正しさに誠実であるには過ちは改める必要があります。

エンジニアの議論の仕方

議論とは勝ち負けではありません。 どちらかが否定されどちらかに与するようなものではないのです。

議論では論点に対するより正しい知見を築くことが大事なのです。

どうも、議論というと ディベート のようなものを想像する人がいるように見受けられます。

ディベートはある命題に対して、肯定派と否定派にわかれて討論し、 それを聞く第三者の投票によって採否を定めます。 また、肯定派、否定派という役割分担は本人の意思とは別に定められるものです。 ですから、自分の主義主張とは関係なく、立場に応じた弁護をしなければならない。

ディベートではより多くの同意を得ることで勝利となります。ディベートには勝敗がある。 しかし、ディベートはその討論から真実を得ることを目的とはしていない。

エンジニアの議論において、誰が正しかった、なんてのは瑣末な問題です。 ある人の意見が100%正しく、そこに加筆も修正もないようなものは議論ではない。 そうした結果となるならば、それは授業とか講義と呼ばれるものでしょう。

エンジニアの正義は正しさに誠実であることと言いました。 二人の人がいて、意見の一致を見なかったとすれば、そこはほつれなのです。

ほつれを正すときに以下のような選択肢で考えてはいけません。

• 自分が正しく、相手も正しい
• 自分が正しく、相手が間違っている
• 自分が間違っており、相手が正しい
• 自分も相手も間違っている

正誤を勝敗と捉えて議論に挑むと陥る誤りです。これらの選択肢に足りないのは 正誤の中間です。一部は正しく、一部は間違っているという事例を考えていない。

ほつれをみつけたら、自分および相手の言説のうち、正しいものを拾い集めなくてはなりません。 あるいは、その整合性を取るために、新しい理論を必要とするかもしれません。

そうした過程で作られた、「より正しいもの」を双方が享受する、それが議論なのです。

議論の過程では論理的な思考が必要とされます。議論のアンチパターンとしては 話し合いをダメにする論証パタン１３個（有意義な論争のための議論ハック） が参考になるでしょう。

正しいとは何か

正しさというのは何をもって正しいとするのか、というのは非常に哲学的な、難しい話題です。

しかし、エンジニアらしく実用性で考えるのであれば、「無矛盾であること」とすれば事足ります。 ゲーデルの不完全性定理なんてのもありますが、実用上は無視できます。 無矛盾であることは正しいことの必要条件。矛盾がある以上は正しいとは言えない。

かといって矛盾が１つでもあればそれは全くの役立たずかというと違う。 現代科学も、ある特定の条件において矛盾が出てしまいますが、それ以外では矛盾しない。

一部に矛盾というパーツを孕んでいることが、ただちに全体を無価値化するものではない。 完璧な理論というものがない以上、より無矛盾な理論が選ばれているだけのことです。