はじめに

オープンソースプロジェクトには、バグの修正や機能追加のリクエストが来ることがあります。

そのときに、なにをどうすれば変更できるか（変更の難しさ）や、自分には作業のための時間がとれるかとか、自分にはわからないけどあの人ならわかりそうだとか、色々なことを考えます。

しかし、それ以外にも私がどんなことも考えているのか、ということを言語化してみました。

意図しない仕様変更

あなたがリクエストをくれ、そのとおりに修正してあなたの環境では良くなったとします。そのとき、

1. あなたの環境では良くなった
2. それ以外の環境では...
   1. 以前から問題があったが、だれも報告していなかった
   2. 以前から問題がなかった
      1. 修正しても問題が起きない
      2. 修正して新たな問題が起きた

このような分岐が考えられます。「それ以外の環境では以前から問題がなく、修正により新たな問題が起きる」理由には、修正のときにバグを入れてしまうことだけでなく、リクエストによる変更が従来の動作とは相容れなくなることがあります。

リクエストをくれたあなたのほかにもたくさんのユーザがいて、あなたも私も知らない使いかたをしているかもしれません。修正したことで、あなたを含む「良くなった」ユーザと、問題なく使っていたのに「問題が起きるようになった」ユーザのどちらが多いでしょうか¹。

というわけで、リクエストと既存の動きが両立しないことが明らかだったり、変更の影響範囲が読めなくて「これで大丈夫そう」という自信が持てない部分だと、気軽に手を入れられません。副作用によってほかのユーザから寄せられる「壊れた」や「改悪された」というクレームは、リクエストをくれたあなたではなくこちらに来てしまいます。そんな予感がする未来のことはお構いなしに「いいから俺のリクエストどおり直せよ」みたいな猛プッシュをされると、「仕様が変わったことへのクレームの対応」や「両立しない動作をどちらも満足する仕様に落とし込んで修正する」ことまで全部面倒見るつもりで言ってるんでしょうね？という気分になることがあります。

副作用を起こしても「さらに修正すればいい（修正できる見込みがある）」という自信があったり²、「片方は切り捨てて放置してもいい」と思える図太さがあれば、気にせずどんどん修正できるのかもしれません。

確認できないけど修正する

たとえば、環境が同じでも私の手元で問題が再現しないと、状況を確認できないので対策が打ちづらくなります。勘のようなものを働かせて修正してみても「あった」問題が「なくなった」ことを手元で確認することができません。

また、私が持っていない機材をサポートしてほしいというような、正常な動作を確認できる環境がないのに修正する場合も難しく感じます。

このような場合はリクエストをくれたあなたの確認が頼りになります。しかし、追加情報を求めたり、修正してみて確認を求めたところ、返信が来ないこともあります。たしかに、こちらが直したいと思ってはいても必ず直さなければいけない責任を負っているのではないのと同じく、あなたにも必ず返事をする義務があるわけでもないのですけれど。

これだと、修正を元に戻すか、問題がなくなったことを確認できない修正を採用するか、という選択を迫られます。もし、なんらかの副作用が起きてしまったら、手元で確認できないので事態を収拾するのが難しくなることが予想されます。

まとめ

ソフトウェアのメンテナンスとは「プログラムにとってなにがよいか」を考えることで、これには「誰かにとって良くする」と「誰かにとって悪くしない」を両立させることが関係していると思います。

プログラマにもいろいろな考えの人がいます。

• 「どんどん直していこう、多少壊れるのは仕方ない」というタイプ
• 「問題ないので黙って使っている多数のユーザに不便をかけないほうがよい」というタイプ

これは「良くする」ために許容できる「悪くなる」の限度が人によって異なるのだと思います。私は後者のタイプなので、できるだけ「悪くなる³」が少なくなるようにしたい、と考えながら作業しています。