変更管理プロセスと技術的負債の返済

ソフトウェア開発はリリースごとに差分を積み上げていくのが一般的なスタイルです。最初に動くものを組んで、リリースしたあとは触らずに放置されるべきものではない。周囲の環境の変化に合わせて要望があるので、ほとんどの場合は動くものをベースにして、新しい機能なりを追加してというのを繰り返します。

既存のコードベースに差分を積み上げる改良開発は、新規開発と比べて、難しいというか厳格なものです。最初はやっぱりワーっと統制のない状態で作られても完成までは何とかたどり着けます。超人的なエンジニアが独力で作り上げたって伝説が残ってたりしますね。完成までたどり着けない場合もありますが、それは今回議論したいことではありません。一方で、そのような新規開発と比べると、追加の開発は既存のものと整合性をとったり、既存のものを壊さないように気をつけたりする必要があるので、それなりに厳格な変更管理のプロセスが必要になります。新規開発と比べると改良開発はどうしても生産性が低いように見えてしまいます。でも、それはそういうものなので仕方のないことです。この事情を経営に説明できない開発組織ってのは良くないと思います。

厳格な変更管理のプロセスが今はなくても、まともな組織なら勝手に厳しくなります。プロセスは増える方向に重力が働いていて、基本的に増える一方です。どこかの変更の品質に問題があれば、その後の変更はプロセスが増えて統制が厳しくなります。これは自然の摂理でそういうものです。そうすると工数ってどんどん増えて行くので、傍目には生産性が低いように見えてしまいます。

ただ、私はプロセス増やして統制をきつくするのは必要だと認めるものの、それがどれほど効果的なのかは疑問に思っています。統制が緩かった過去の時代に積み上げられたものはそこにあるままだからです。それは一般には技術的負債と呼ばれるものですかね。地雷を踏んでしまった事故があったとして、地雷を避けるようなチェックを増やすのは直接的な回避策ですが、その分工数が増える。そしてチェックしきれるかというとしきれない。地雷原の中を歩かせるようなストレスフルな仕事の生産性が高いはずがないし、また地雷踏んでしまったら、さらにプロセスが厳しくなって、どんどん工数が増えてくる。

地雷を踏んだ事故があったら、普通に考えたら地雷をどけるべきでしょう。地雷は悪意あって置かれたもので、踏んだら確実に大きな傷を負うので、どけることに異論はだれもないと思いますが、踏まないようにうまく歩けてしまったり、踏んでもかならずしも爆発しないし、致命傷でもないリカバリ可能な傷で、うまくリカバリしてしまう人もいたりすると、どけようって判断にはなかなかならないのが困ったところです。

例としては、循環的複雑度がとても高い関数が挙げられるでしょうか。こういう複雑で危険なコードベースをいじったときに問題が起きたときに、再発防止策でチェックリストを作りますとか、影響範囲調査とリグレッションテストを強化しますってなるんですが、仮に運用されても効果はあっても工数がかかって開発がどんどん遅くなってくるでしょう。

じゃあ技術的負債は放置しないという方針ものに、循環的複雑度の基準値をつくって、それを超えるような変更は認めないというルールを作ったらうまくいくか。まあ、うまくいかないだろう。ここでうまくいっている状態とは、みながその基準に従って、新しく複雑な関数はつくらず、既存の複雑な関数は簡単にして、変更を重ねるうちに基準を超える複雑な関数がなくなっていく状態です。なぜなら、その統制を守るコストを負担するのが、変更を加える人になってしまうからだ。その差分だけなら気をつけて if 文を加える方が簡単だし、既存のコードが複雑であることに責任はないし、なぜわざわざ時間をかけたいと思うのでしょう。品質基準を押し付けるひとが、コストやスケジュールに責任をもっていないと、喧嘩になるだけだ。

先ほどの地雷原の話に戻ると、道通るのにいちいち地雷除去戦車を個人で用意しろって無理があるじゃない。道を早く行きたいって思いは強い。やっぱり地雷探知機で気をつけながら行こうってみんな思う。ルール無視しちゃう人はそうしちゃうでしょう。やっかいなのはルール無視しても早く着いたほうが褒められてしまうことだ。でもそういう風に統制効かなくなると地雷探知機もすっ飛ばした方が早くて、確率の問題なのでほとんどの場合はそれでうまくいくんだけど、たまに失敗して爆死する人が出る。

じゃあ、コストも出すし、スケジュールもゆるくするからやれってなるかというとそれもならない。プロセスを加えて仕事を増やすときはそんなのちょっとやろってコストが過小に見積もられて増やされるし、仕事が増えた分のアカウンタビリティは結局仕事をする側が持つ。簡単な仕事でもこれだけ手間がかかりますとか言うはかなりかなり手間である。統制を守るのはとてもコストがかかる。早く道を進みたいためにやっていたはずなのに、余計に道を進むのが遅くなる。それは一般に受け入れられない。

誰かがリーダーシップをもって地雷を除けって話になるのだろう。本当の地雷原だって、お前らの問題なのだから自分でやれよって思いますけど、やっぱり外から誰かが除去してあげないと問題は解決しない。差分の変更管理はプロセスで統制できるが、積まれてしまった差分はプロセスの問題じゃないってのが現在の考えです。対人地雷を禁止して地雷を増やさないのは変更管理プロセスのなかで制御できるが、変更管理プロセスはすでに積み上げられて問題は解決しない