ソフトウェアエンジニアに働く慣性の法則

なんでもいいのだけれども、例えばだけどバージョン管理システムつかって開発してないです、みたいな人がいた時に、傍から見たらすごく良くないことをやっているように見えるけど、当人からすれば今までこれで開発してきたし、別にバージョン管理システムなんか使わなくてもいいよ、みたいなふうな反応をされる。また、こういう反応はその当人だけじゃなくてその人の周りの人も同じ様な反応をする。

もうすこし卑近な例で言うと、コードの質なんかに関しても、汚いコードで書くのが普通で今まで数多くの案件をこなしてきました、みたいな場合だと、綺麗なコードなんて犬に食わせろ的な態度を取って逆に綺麗にコードを書く人をすこし敬遠した態度を取るような人も見られる。そしてそういう人の周りには似たような態度を取る人が多い。そういう考え方みたいなものは、長い間過ごす同じ開発チームのなかで浸透していくからだと思う。

基本的に綺麗なコードを書くよりも、汚いコードを書くほうが作業スピードは早い。スケジュールを切るプロマネ級のひとは、基本的に実績ベースでスケジュールを切る。 例えば、「このエンジニアは以前これぐらいの期間であれを開発したから、今度のスケジュールもこれくらいだろう」という感じに。綺麗なコードを書くとスケジュールに間に合わなくなる、みたいなことが起こりえるような環境ができる。自動テスト書きましょう、みたいな話もこれと同様で、テスト書かないのが当たり前になると、プロマネもそれに依存して自動テスト書く分のスケジュールを切らないのが当たり前になってしまう。

エンジニアリングの現状を変えることで、プロマネのひとにとっても影響がでるようになると、なかなか変えづらくなってくる。完全にエンジニアリングのみに関することならそのエンジニアだけを説得すればいいけど、スケジュールなんかも関わってくると結局プロマネの人やその周りのステークホルダーも説得しないといけなくなる。

何かを変えようとして議論するときに、現状に対する完璧な解を提示しないと、なんやかんや理屈をつけられてそれだとこういうエッジケースで・・・とか結構瑣末な話になってきて議論が長引き最終的にはなにか有耶無耶になって結局説得できない場合が多い。議論する相手が頭いいと実際そんな感じになる。議論や説得をして何か変えようとしてもあんまりうまくいかない気がする。

バージョン管理システム使おうとかコード綺麗に書きましょうとかそういうわかりやすい例の話は、ほぼ自明の理で従わない奴は馬鹿のように思うけど、これが自動テスト書きましょうとかCI導入しましょうこのままだと破綻するからこういうアーキテクチャ導入しましょうとか設計綺麗にしましょうとかリファクタリングしましょうとかこれこれ自動化しましょうとかまあなんでもいいけど色々題目を変えると、現場によって慣性の法則が働いて、いやそれはちょっと・・・みたいなことになる。

最終的にはどうなるかというと、開発が破綻したり問題が出てくるようになってきて初めてこりゃいかんよね、みたいなことを言い始める人が出てきて、いやだからそれを前から言ってたやんけ、という話になったりする場合もある。でも問題が出始めるようなったり開発が破綻し始めてから問題に対処するよりかは、最初からちゃんとやって質のいいソフトウェアを開発するほうがいい。

あるプラクティスがエンジニアにとって当たり前になると、他のエンジニアにもそれが浸透する。エンジニア何人かに浸透すると、それに対してプロマネがそれに依存するようになる。プロマネにも浸透するとそれはステークホルダにも浸透する。だから悪いプラクティスがエンジニア間で浸透するとそれを変化させるのに苦労する、という風なことを最近おもった。

大学生の頃読んだこのコラムを読みなおそうと思った、まる。