続「無くても作れる」意外にこれが最大の敵かも。

以前の私のエントリについて、 dev0000さんからこういったエントリを書いて下さいました。

古いものに固執するのと同じぐらい新しいもの好きっているわけで。

人はそれを機会損失と呼ぶ | 眠る開発屋blog


dev0000様のエントリを読ませて頂く中この一文を見たときに、私のエントリ内容の不足に気付きました。ご指摘に感謝いたしつつ、内容の補足をしたいと思います。


まず、私のエントリより引用。

個人的に、こういう意見に潜む「今まで通りのやり方とは違うやり方=リスク」という考えに、非常に違和感を感じてしまいますが、それもありがちな「個人の価値観の相違」と規定されてしまえば、それ以上強硬に主張するのもなかなか難しいです。

2007-11-23 - 思い悩むblog 改め Buriに片思い日記

ちゃんと深く考えておりませんでしたが、これだと「だから今まで通りのやり方やそれを書いた手順書などゴミ箱に投げ込もう、そして新しい事を始めよう」と言わんばかりでした。
でもこれは、真意ではありませんので、この点についての補足です。

  • 今まで通りのやり方は改善していかなくてはならない。
    • 【今まで通りのやり方=最善の方法ではない】から。
      • しかし、必ずしも【今まで通りのやり方=良くないやり方】ではない。
  • 【今まで通りのやり方とは違うやり方=リスク】ではない。
    • だからといって、全ての課題が解消する訳もない。
    • リスクがない訳でもない。

と箇条書きにしましたが、これがエントリもう1つのエントリで書いたことの要約です。

で、一番私が書きたかったのは「だからと言って、新しいやり方を知らなくて良いという事にはならない」という事でした。


今まで通りのやり方を用いても、新しいやり方を用いても、どちらにもリスクはあります。またそれらを選択したが故に発生するコストもきっと存在します。

結局のところはどちらのリスク、コストを選択するかは現場のチームで検討、判断されるものだと思いますが、どちらの効果がより優先されるかを判断する為にどちらのやり方もきちんと把握した上で、比較をしないとなりません。これを怠った上で「今まで通りのやり方が一番良い」と判断するのが、私が伝えたかった「思考停止の罠」にかかった瞬間であります。


だから、新しいやり方だからという理由で新しいやり方を導入するのは、それはそれで良くないんですよ。ただし、何故導入しなかったのかという根拠はあるべきだと思います。つまり根拠とは、

今まで通りのやり方で悪い部分が何であり、新しいやり方ではこれを補える。しかし、今まで通りのやり方で安定していた部分が新しいやり方では犠牲になる危険が高い為、新しいやり方は用いない。

という説明によったアウトプットが恐らくは最適でしょう。自分以外のメンバーに、やり方を変える、または変えないことの理由を説明できるかどうか、きっと結果はすぐに出ます。そしてこういった根拠が無いものは、それが賛成でも反対でもあまり重要視すべき発言とは言えないなと思います。


dev0000さんのエントリより、より実務的、現場的な視野の狭い話になってしまいましたが、私なりに補正をしてみるとだいたいこんな感じになります。うまく補足できていれば良いんですが。。。