コードの共同所有 - ITエンジニアのひとりごと

XPのプラクティスにコードの共同所有がある。誰が開発したソースでも、ソースは修正してよい、と言うルールだ。たとえば、自分が開発したソースに不具合があり、それを直すと他に影響が出る場合など、自分が開発したもの以外も直してよいのだ。

昨日、受入れテストで障害があがった自分のモジュールを見てみると、自分の作ったロジックは跡形も無く壊され、SQL文からJSPまですべてが新規に作成されなおしており、愕然とした。

思い出してみると、例のスキルのある若手が、その画面の先を造ることになっていて、「修正してよいですか？」と聞かれていたので、「どうぞ。」と答えていた。修正はあるだろうが、すべてが再作成されているほどの修正をしていたとは思わなかった。

問題と思う箇所は以下のような箇所だ。

自分なりに考え抜いた構造だった。
バグも出にくく、実際、内部テストでは品質が良かったと思っている。しかし、今回のイテレーションで作り直されたおかげで新たにバグが生まれてしまった。
新しいソースは私の目から見るとSQLの発行箇所が多岐にわたっていたり、JSPにループ文など、メンテしにくくなってしまっている。
テスト済みモジュールに対し、修正をしたことで、バグが発生している。(Web層のテスト自動化は諸事情によりプロジェクトでは採用していない。ビジネスロジックのテストコードはある。)

たぶん、私の作成したコードが標準化の理想に則っていなかったのが気に入らなかったのだろう。当プロジェクトでは、以下のような標準化がある。これは良い、悪いの判断ではなく、顧客からの要望である。

DBアクセスは複雑なSQLは書かない。基本はテーブル単位でDAOを作成し、テーブル結合などはJavaロジック上で行う。
JSP以外からHTML出力はしない。文字列の編集などはJSP上で行う。

ただ、いずれの標準化も強制ではなく、望ましい、という表現がとられている。で、私が作成したロジックは以下のように作成されていたが、標準化上、望ましくはないがNGでもない。

SQLは結合している。1回のSQLで必要情報すべてを取得している。(極端に複雑ではない。)
JavaでHTML文字列を編集するクラスを作成し、JSPから呼び出している。(ループはJava内に隠蔽)

しかし、これを「望ましい」ほうにその若手は変えたかったのだと思う。確かに、「修正してよいですか？」ときかれてから、なぜかかなり時間がかかって修正している、というのは朝会でも聞いていた。「結構、複雑なので、時間かかっています。」と言っていた。確かに、私が作った構造なら、単純で明快で一部不思議な仕様もあったのだが、(縦横の順番が微妙におかしい表)それも私のロジックでは割合簡単に対応できていた。

今回、そこをJSPにループを書いて、一生懸命作り直していたので、「そりゃ、そういうやり方じゃ、大変だよ。」というのが良く見えるソースになっている。で、私としては、以下のような点が気に入らない。

わざわざ標準化にあわせようとして、複雑化させてしまった。
SQL発行も数多くいろいろな箇所で行っているため、パフォーマンスも悪い。
しかも、新たなバグが生まれてしまった。

要するに、わざわざ複雑化させ、正しく動いていたものを壊してしまった、というのが、悲しい。そしてメンテナンス性も高く実装していたのに、それを無視し、すべてを壊して作り直されてしまったのがとても悲しい。ということだ。悲しい、というよりは腹立たしい、というのが正直な気持ちだ。さらに、この若手からは少々悪意も感じる。

ヘボなロジック組んでるんじゃねぇよ。
標準化わかっているのか？
オレ様がキチンとしたロジック組んでやるから、おとなしく見てろ！

こういう感情を感じるのだ。ちょっと大げさだが、あるだろう。しかし、ココで私がムキになり相手と対峙したらどうなるのだろう。たぶん、お互いにメリデメの主張があり、なかなか先へ進めないだろう。また、もし私の主張が通ったら、その若手はどういう気持ちになるだろう。

人間がチームを組んでシステムを作るのだ。

今回の問題で、システム稼動にどのような影響があるだろう。また、将来にどのような影響があるだろう。おそらく以下のような影響や問題があるだろう。

その若手は、これからも同じような対応をする。そのときに問題になるだろう。
今回、およそ修正に3日、バグ対応に1日かかるだろう。余計な作業だ。
メンテナンス性が低くなってしまった。

ただ、上記のような問題はシステム稼動に対しどの程度の影響があるだろうか。たいした影響ではない、と思う。それよりは、この若手も含め、高いモチベーションで、プロジェクトに参加している意識を持ち、日々充実した作業を行ってもらうほうがはるかに価値が高いだろう。ならば、今回の修正も多めに見る必要があるのだと思う。

正直、腹立たしかったし、1年前なら「考えて作業しろよ！」などと言っていただろう。今回のような事件はプロジェクトを進めていけば必ず出る問題だろう。修正をする際にもっとコミュニケーションをとっていればよかった、と言う意見もあるだろうが、おそらくこの若手とは、標準化やユーザインタフェイス層などの考え方がかなり違うので、分かり合えることはないだろう。ならば、プロジェクトメンバが充実して作業できることを考え、どちらかが引くことも大事だろう。実際、その若手は他の部分では品質も高く、進捗率も良い。そのような部分がこれからも維持できる(もしくはそれ以上に伸びる)のであれば、十分に私の意見を引くことができる。

そして、いつかどこかで分かり合える日が来るように、これからもコミュニケーションを緩やかにとっていきたいものだ。