ゴミ箱の中のメモ帳

まだ見ぬ息子たちへ綴る手記

コーディング規約で出た損失

先に「コーディング規約なんていらない」を書いた。本当はこの記事の内容を書きたかったわけだが、話が逸れに逸れてしまったので別の記事にした。

コーディング規約があることで実際に損失が起きた会社の話。

 

C#ルールブック ?読みやすく効率的なコードの原則

C#ルールブック ?読みやすく効率的なコードの原則

 

 

コーディングを支える技術 ~成り立ちから学ぶプログラミング作法 (WEB+DB PRESS plus)

コーディングを支える技術 ~成り立ちから学ぶプログラミング作法 (WEB+DB PRESS plus)

 

 ====

その会社は厳格なコーディング規約を定めていた。

コーディング規約を掲げているだけでは確認ミスや漏れでコーディング規約に違反していしまう可能性があるので、コミットされるコードがコーディング規約を満たしているかチェック担当の人間とパーサが自動でチェックすると言う構造にしていた。

まずコミットしようとするコードは一時的なブランチに入れられる。そのコードを担当の人間がチェックし、チェックが終わったコードは夜中の自動処理で実際にコミットされるという寸法だ。なので実際のコミットは機械的に行われるのみで人間が直接行うわけではない。

これによってコーディング規約と品質を確保しようとしていたのだろう。


その会社は大きくなったのでいくつかの小さな会社を買収した。買収された会社も親会社であるその会社のコーディングスタイルや規則を守る必要があり、それまでのスタイルを変更する必要がある。

子会社とされるのであれば従来からのコードはそのまま動かし続けることもできたのだが、親会社に完全に吸収される場合には親会社のシステムを使うために規約を完全に守らなければコミットすることができない。

そのシステムは自社内で開発が完結している場合であればうまく行っていたのだが、今回のように外部のコードを買う場合や、外部と連携して開発する場合にはうまく行かないことがわかっていなかったのだ。

 

だがそんな事は言っていられない。吸収した会社のコードを親会社のシステムに入れるには全てのシステムを変更してテストをパスするようにしなければならない。そうしなければ親会社のシステムに組み込むことはできない。

だが吸収したのであるからシステムを統合しなければ幾重にも無駄なコストがかかってしまう。だが修正するにしても大規模な改修が必要になるためにかなりのコストがかかる。

そこで会議が持たれた。コーディング規約を変更するかどうか。親会社のコーディング規約を変更して子会社のスタイルを許容できるように変更するかどうかだ。

だが結局は双方の規約には矛盾が合ったために統合することは出来なかった。規約を統合するのであれば実質的に規約が無いに等しくなる。だがそうすると現在の品質は確保できない。いや、現在までに無駄にコストをかけて守ってきたことが全て水泡に帰すこととなってしまう。

そしてそれに合わせてパーサを変更するのにもコストもかかるというのが理由だ。

それは会社的にも、役員的にも、対外的にも出来ることではなかった。


よってその子会社のコードが現在のシステムに組み込むことが出来るように3ヶ月の時間とコストをかけて変更することになった。そのコストはその小さな会社を買収するのにかけた費用と同等のコストとなった。

そしてその修正により新たなバグが入り込み、安定した運用に入るまでにはさらなる時間がかかった。そしてその間にはそのシステムは機能の追加などはなく、ユーザがドンドンと離れて運用コストに見合わない収益となり廃止された。

その会社を買収したコスト、そのシステムを改修したコスト、運用での赤字、そしてなによりバグによる会社の信頼性の低下という損失を支払うことになった。


そもそものコーディング規約に幅を持たせていればこんなことにならなかったのだが、コーディング規約を絶対視し、それを守らせることが目的になってしまった為に起きてしまったことだろう。

現在もこのようにコーディング規約を絶対としている会社は多くあるかと思う。


コーディング規約は自主的に守る程度にして置かなければこれと同じような損失が起きるだろう。

なんてったってコーディング規約にはこのように会社ごとに大幅に違う、単なるオレオレルールでしか無いのだから。