はじめに
Google work
心理的安全性がチームの「対人関係」にフォーカスしているのに対して、今回の記事ではシステムの「修正に対する心理的安全性」について考察してみたいと思います。
心理的安全性とは
心理的安全性が高いチームでは、個人がチームや上司に対して、たとえ否定的な意見でも言い合えるようなチームを指します。
心理的安全性が低いチームでは、意見した人間に対して、直接的な否定をしたり、不機嫌になる、提案した人間に業務を丸投げするなど、意見した人間にマイナス要素が発生するチームを指します。
こうした心理的安全性の低いチームでは良いアイディアや意見にストップがかかってしまう、デメリットがありました。
修正に対する心理的安全性
今回の記事で言及している「修正に対する心理的安全性」が高い環境は、エンジニアがシステムに良い修正を加える際に、エンジニアにとってマイナス要素がない状況を指します。
「修正に対する心理的安全性」を左右する要素として以下が挙げられます。
・修正しなくてもシステムが動作する場合(リファクタリング)
・修正に対するテスト工数が多い場合
・修正を配布するコストが高い場合
修正しなくてもシステムが動作する場合(リファクタリング)
リファクタリング自体はメンテナンス性を向上し、将来的な機能の追加、修正のコストを下げ、プログラムの寿命を延ばすことにも繋がる有益な作業ですが、やらなくても「今は動く」という状況は、それ自体が修正に対する心理的安全性を低くしています。
リファクタリングに対して、修正に対する心理的安全性を高めるためにプロジェクトができることはボーイスカウトルールを取り入れることかと思います。
ボーイスカウトには大切なルールがあります。それは、「来た時よりも美しく」です。
プログラマが知るべき97のこと
たとえ自分が来た時にキャンプ場が汚くなっていたとしても、そしてたとえ汚したのが自分でなかったとしても、綺麗にしてからその場を去る、というルールです。そうやって、次にキャンプに来る人達が気持ちよく過ごせるようにするのです(このルールは元々、ボーイスカウトの父と呼ばれるロバート・スティーブンソン・スミス・ベーデン=パウエルの「自分が最初に見た時よりも、世界をいい場所にすべく努力しよう」という言葉から来ています)。
ルール化することで、チームとしてリファクタリングを良いことと認識しあい、リファクタリングを促進させます。
修正に対するテスト工数が多い場合
修正の影響範囲が広範囲に修正が及び、さらにはそのテストが手動による長時間に渡り拘束される作業で、かつバグの責任を負うとなると、誰もその対応をやりたいとは思わないはずです。
これに対して心理的安全性を高めるには、修正者とテスト者を分けること、テストコードを書くこと、テストを自動化しておくこと、などが挙げられます。
修正を配布するコストが高い場合
システムの更新作業で、システムを止めなければいけないなど、修正を配布するコストが高い場合、たとえ良い修正でも、重大なバグなどではない限り修正をすることは許可されることは少ないでしょう。
これに対して心理的安全性を高めるには、無停止デプロイ環境の構築・自動化、停止時間の最小化、定期メンテナンス導入などが挙げられます。
おわりに
エンジニアの良い修正を、案で終わらせないための、即座に実行に移せる環境を「修正に対する心理的安全性の高い環境」と定義します。
