ソフトウェア開発の現場においても、地獄への道は善意で舗装されているのかもしれないと思った話。
地獄への道は善意で舗装されている
「善意でなされた行為であったとしても、その実行により意図せざる結果が招かれるの」意
エンジニアの手を煩わせたくない！
開発組織のマネージャーやプロジェクトマネージャーなどの方が、「エンジニアの手を煩わせたくない」というセリフを口にすることがあります。
その動機は、
- エンジニアには開発に集中してもらいたい
- そのためにも開発以外の仕事はなるべく自分たちで裁こう
といったものであり、エンジニアのためを思っての言動です。善意に満ち溢れていて、とても素晴らしいことだと思います。
ところが、その善意から来る行動が、
- 自らがビジネスとエンジニアの間に入って仕事をまわす
- 気が散らないようにエンジニアの見えないところでコミュニケーションをする
- 決まったことだけをエンジニアに伝える
というコミュニケーション設計になってしまうことがあります。
コミュニケーションのスパゲティ化
開発チームはとビジネスの間にプロキシーとして入ることで交通整理をする、一見良さそうに見えます。でも実際の現場でこれがうまく機能することは極稀です。
なぜなら開発チームとビジネスが意思疎通をするために、2倍のコミュニケーションコストがかかるからです。さらに、どちらのコミュニケーションにおいても一次情報ではないことから伝達遅延が発生したり、コミュニケーションエラーによって新たな問題が発生する可能性があります。
もちろんプロキシとしての能力が優秀であれば機能することもありますが、誰もができることではありません。仮に機能したとしても、「プロキシ」という仕事をつくりだしてそこに大量の時間を投下していることになります。
一方で、上手だと思うマネージャーは上記のようなコミュニケーション設計をします。
間に自分が入るのではなく、一次情報同士がコミュニケーションする場をつくる。そうすることで、コミュニケーションがシンプルになります。ファシリテーションなどによってコミュニケーションを支援することもできるでしょう。
最初の言葉に戻ると、「エンジニアの手を煩わせる」ことになってしまうかもしれませんが、コミュニケーション設計がシンプルである方が仕事がうまくいく可能性がとても高いです。
地獄への道は善意で舗装されている
繰り返しになりますが、動機は善意からくるものなので悪気はありません。でも善意からくる行動が、必ずしもいい結果になるとは限りません。かえってチームを悪い結果＝地獄へと向かわせることになってしまうことがあります。善意からきているからこそたちが悪いのです。
こういったケースでは、「○○のため」という言葉が、「（自分が想像している）○○のため」になってしまっていることが多いです。これでは善意の押し売りになってしまいます。
今回紹介した例はあくまで一例ですが、「地獄への道は善意で舗装されている」ことになってしまうケースはソフトウェア開発の現場においてたくさん存在します。善意から行動に移すことができるエネルギーは素晴らしいです。でもそのエネルギーは、エンジニアのため、ユーザーのため、プロダクトのため、会社のためという大き過ぎる主語に向けるのではなく、目の前の誰かに向けられるとステキですね。
