Archive for June, 2011

リファクタリングの必要性を数値で訴えるには

コーディングを進める上で、以下のような指標を考える。

  • コードを書き足す時、ぎりぎりの時間で実装すると増えるが、充分に時間が与えられれば増えない。
  • 仕様の変更があると増える。
  • 仕様が確定しない状態で開発を進めると増える。
  • リファクタリングの工数をとると減る。
  • 開発を始める段階ではゼロで、ゼロより小さくはならない。

直接的なイメージとしては、「削減可能なコード量」である。便宜的に、「冗長量」と呼ぶ事にする。

ビジネス的観点から見た冗長量の意味は以下のようになる。

  • 機能を追加する際のコストは、冗長量に比例する。
  • プロダクトの納品時に、冗長量を低く抑える事は必ずしも求められない。
  • 冗長量が多いと、バグの発生率が高まる場合がある。

開発担当者が冗長量を日々の報告に付け加える事で、ビジネス担当者は仕様変更や緊急開発のリスク、リファクタリング工数のベネフィットを定量的に考える事が出来る。

緊急開発と呼んだのは、たとえばこんなシーンだ。

上司「ねえ君、大至急この機能Aを実装してくれないか」
開発「とりあえず動くだけなら1日で出来ますが、ちゃんと作ろうと思ったら3日は欲しいですね」

こう答えれば、上司は間違い無く、「動けばいいよ、今日中でよろしく!」と言うだろう。(あなたの上司がここで「じゃあ3日で」と言うのであれば、このコラムを読む必要は無い)

冗長量を考慮して、このように答えたらどうだろう。

開発「動くだけのものは1日で作れますが、冗長量は200上がります。冗長量を100下げるのには1日のリファクタリング時間が必要です」

まあ、こう言っても、上司は「1日で」というかもしれない。
開発担当者は、冗長量が200上がった事を報告書にあげておく。

後日、別の緊急依頼が来た。

上司「ねえ君、この前保留にした機能Bね、必要になったから、よろしく頼むよ。」
開発「3日かかります」
上司「以前、2日で作れると言ったじゃないか」
開発「先日冗長量が上がったので。早めのリファクタリングをしないと非効率ですよ?」
上司「ぐぬぬ。。」

数値は必ずしも客観的である必要はなく、開発担当者の主観で適当な値を報告してもらえば良いだろう。
(ただし、減らすのに必要なリファクタリング時間に比例した量であった方が分かりやすいと思う)

もちろん、冗長量に関するデータは給料の査定に響くようにすべきだ。
どのように評価すべきかは、別途議論の余地があるテーマだが。