割れた窓を見過ごせるか？

多人数開発をほとんどした事のない自分が言うのもあれだが、少なくともコレまでのチーム開発において、他者に任せっぱなしで安心だ、と思える時はほとんど無かった。
と、いうのも他者の書いたコードが私視点ではヒビだらけに見えるためだ。
学校の課題でしかチーム開発は行った事はないが、他者に頼むと、

テストが無い
ライブラリに存在する機能を自作している
変更に対応できない
メソッドが長すぎる(リファクタリングのにおいがプンプンする)
十分な型が作られていない(例えば、Cの行列を全てint**型で処理する、など)

と言ったコードしか出来上がってこないことが普通だ。

「学校の課題だから」この様なコードしか出来ないのだろうか？
「まだ学生だから」この様なコードしか出来ないのだろうか？
それとも、仕事をし始めてもこの様なことは普通のことなのだろうか？

今はまだ、全てのコードに目が届く。
どんな課題でも、高々10000行程度のソースコードだからだ。
目が届いてしまうからなのかも知れない。そこに割れた窓を見つけてしまうのは。
割れた窓を直さなければ、そこから腐敗が広がることを知っている。
だから、直したい症候群に駆られてしまう。
そして、たいていの場合において、書かれたソースを直すよりは自分1人で書いた方が、本当に残念なことに、早く終わるのだ。
他者に任せる気が起きないのは、そう言った理由がある。

これは、十分に危険な兆候だと思う。その自覚はある。

この問題はどうすれば解決するか。
自分なりの答えとしては、やはりチームの全員がまずいコードを書くことは「いけないこと」だと、自覚を持つ事だと思う。
残念なことに、これは1人で出来る事ではない。1人でこれを解決できるのであれば、どんなに嬉しい事か。
そして、自分1人では解決できないからこそ、解決のための知識を磨く。

よいソースコードとは何か。
よいテストとは何か。
そして、よいチームとは何か。
そのチームを作るためには、どうすれば良いか。

到達点は遠い。ただ、まだ歩ける。
転んでもいい、道を踏み外しても、また戻って、そこにたどり着きたい。
信用できるチームの一員となれることを夢見て。