IT業界で気づいたことをこっそり書くブログ

何とかする系アプリエンジニアが、日々気づいたことを適当に綴っていきます(受託→ベンチャー→フリー→大企業→ベンチャー→起業?)

ソースコードの引き継ぎ改修案件が難しい理由

ここ3年くらいで何度か体験したことです。

条件としてはこういう状態です。

  • 既に完了しているプロジェクトの追加改修
  • プログラマーはもう居ない
  • 仕様書はほぼ無い
  • 完成したのが2年前とか

よくある話ですね。


こういう「ちょっと変えて欲しい」案件を、別に私は軽く見ていたつもりはなかったのですが、想像以上に上振れることがわかりました。
大体想像の30〜40%増のバッファで見積もるのですが、現実は80%〜300%という感じです。

 

原因は少し複雑です。
前提として大きいのは、引き継いだコードの質が自分のものより下であることです。
それだと「場合に依る」と思えるでしょうけど、意外と(?)十中八九自分より不出来であることが多いです(私が特別優秀というわけではなく)


理由はたぶんこうです

  • きちんとしたコードを書くようなプロジェクトでは、どこの馬の骨とも知らない人に引き継がせないし、最低限プロジェクト内にエンジニアが居ないみたいな状況にならない
  • 2,3年前だと皆レベルが低いみたいな状況がある(黎明期問題)
  • バージョンが上がりすぎていて、非推奨なコードになってしまっている
  • 外注の新規開発したコードって大抵クソですよ(元も子もない)

 

コードの品質やらなんやらがひどい場合。修正箇所を直そうとしている内にバグや潜在バグをポロポロと見つけてしまいます。もちろん直そうとはしないのですが、コードが密結合になってるとどうしてもそこを触らなければならなくなってきます。

そういったコードは、例えば既に顕在化していたり、それなりに重いバグならクライアントに交渉できますが、そうではないケースがあります。潜在していたり、凄く小さいものだったりします。すると交渉する方が大変で、勝手に直すほうが早くなってしまいます。
完全に放置する手もありますが、それを直さないと目的の改修ができないことがありますし、検収時にバグが再現されてしまうと自分の責任を問われます。最低限、説明が求められてしまいます。どっちにしても時間が取られてしまうわけです。

この「ちょっとしたバグ」が、密結合によりどこまでも連鎖していくパターンが結構あります。1個バグを潰したら3つバグが誕生するやつです。
すると今度は、整合性を取るために若干のリファクタが必要になってきます。糞真面目ほど、それは無視できなくなりますし、やはりクライアントにリファクタの説明をするのは非常に高コストです。

 

とやってる内に、1行直せばいいところがいつの間にか30行に、みたいなことがままあります。
厄介なのは

  • やってみないとどれだけ量があるかわからない(連鎖するから)
  • 一件一件が非常に小さいため、説明する手間のほうが大きい

あたりでしょうか。

 

たまたま自分の出会った案件がそうだったのだ、と最初は思ったのですが、最近はこちらの方がデフォルトだと考えるようになりました。それほど高確率で上振れます。

これの対策が見つかりません。
上記で書いたように、説明しようが追加料金を求めようが手間のほうが上回ります。「全力で不具合を無視する」という発想が出てきそうですが、不具合を無視したら修正タスクが終わらない状態になるのです。

回避するにはそもそも時間単位での仕事にしてしまうか、バッファを数倍レベルで盛るくらいでしょうか。
(反面教師じゃないですが、自分で一から作る際は密結合を頑張って回避しますし、資料を何かしら残します)

 

まとめ

ちょっと修正する程度の保守単発案件は死ぬほどおいしくないです。
やるとしても、それなりに大きい案件を選ぶか、時間単位での仕事にするべきだと思います。
その時も、見積もりはかなり盛ったほうがいいと思います。