SI開発におけるコードの品質について

自分で開発がしたくて事業会社に転職したのに、最近何故か大手企業からの受託開発でSIっぽいことをやっています。あら不思議。 いわゆるウォーターフォール型の開発で、工程ごとにがっつり何回もレビューをやるやつです。 私の会社は大手企業からの一次受けで、主にPM的な業務を行い、実際の開発は協力会社さんにお願いしてシステム開発を行っています。

レビューによる品質確保

大手案件だけあって、とにかくレビューがたくさんあります。ドキュメントもかなりしっかり設計書をそろえる必要があり、その多量のドキュメントに対してレビューを行います。 ドキュメントの版数管理もきっちりされて、要件定義、外部設計においてはかなり入念なレビューが行われます。テスト件数、バグ率なども開発規模に対して指標があり、当然そのあたりもレビューされます。 面倒な部分はありますが、エンジニアは放っておくとドキュメントを作らなくなりがちなので、これはこれで必要な作業かと思います。 何を作ることに合意したのか、正しい仕様は何なのかというのをしっかりドキュメントとして残しておくことは必要です。

正直言って、今回のプロジェクトにおいて外部設計までのドキュメントは複数回の入念なレビューを経てかなり良い品質で仕上がっていると思います。 一方で、製造工程のレビューに関しては開発会社内でちゃんとやってればいいよというちょっと緩いスタンスになっています。

顧客の求める品質とは

さて、こういったSI開発における品質の良さとは何でしょうか。 それは、要求仕様がすべて満たされており、設計仕様通りに動作し、スケジュール通りに納品され、稼働時点で不具合がないことと考えられます。 またテスト工程において規定のバグ検出がなされていることをもって製造の品質を担保しているように見えます。

品質の落とし穴

さて、そんな開発の中で私は今製造工程において社内レビューを行っています。 協力会社さんから納品される成果物は、外部設計に定めた仕様通り動作しており、不具合もありません。 単体テストのバグ検出率などもまぁまぁ問題ない範囲でしょう。

しかし、コードに関しては控えめに言っても糞コードが出来上がっています。 例をあげると

• 定数を使わずコードに数値リテラルを直書き
• メソッド名と処理内容が合っていない
• 循環的複雑度が50を超えているメソッドがある
• 色んな情報を詰め込んでグローバルに持ち運ばれるオブジェクトがある
• javascriptのフォーマットがイマイチ（セミコロンありなし混在、インデントがおかしい）
• javascriptがちょっと危なっかしい（未宣言変数の使用、グローバル変数多数、ところどころscriptタグの中に直書き、比較が全部"=="）

といった具合です。

自分が保守担当になったら絶対に触りたくないコードです。

いつリファクタリングすべきか

糞コードではありますが、顧客の求める品質は満たしていると言えば満たしています。 仕様通りに動作し、バグがありません。

私がコードレビューでいろいろ指摘して修正することは、顧客の求める品質に対しては工数の無駄かもしれないし、逆に今は存在しない新たなバグを生んでしまうことになるかもしれません。

一方で、こういった大手ユーザーのシステムは、一度本稼働してしまうと修正がとても難しいことも知っています。どんなに糞コードでも、とにかく今問題なく動いているものを不用意に修正することは許されません。リファクタリングは今存在しない新しいバグを生んでしまう原因になるからです。

その結果、保守工程では保守性の悪いコードに微修正を少しずつ加えていく形になり、結果不具合が発生するものの、全面的に作り直す工数ももらえず、延々不具合を生み続けることになるのです。

だから、リファクタリングするなら今やってしまうのが一番良いと思っています。

すべては自分の我儘かもしれない

会社の利益を一番に考えるなら、ここではリファクタリングをしないほうがいいのかもしれません。ここで厳しくコードレビューすることで、今のプロジェクトメンバーには当然負荷をかけ、苦労することになります。正直言って、ここまである程度スケジュール通り順調に進んでいたプロジェクトが、私のコードレビューのせいで確実に炎上プロジェクト行きでしょう。 今のプロジェクトメンバーが地獄を見るか、見たこともない運用保守担当が地獄を見るか、その選択になるかもしれません。

炎上させてまでこれを直す必要はあるのか。仕様通り動いているんだから納品してしまえば一緒じゃないのか。今自分達が頑張る必要はあるのか。お前は誰の味方なんだ。お客様第一の前にプロジェクトメンバーのことを考えろ。PMがコードにまで口を出すのはおかしいんじゃないか。

いろいろ考えましたが、コードレビューはしっかりやることにしました。 プロジェクトメンバーからは文句を言われそうですが、やはりこれを納品することはできません。

この失敗の原因は、もっと作り始めの初期段階でコードレビューをしなかったことだと思います。そう考えると、やはりプロジェクト計画をしっかり立てられなかった私の失敗です。 プロジェクトメンバーのみなさん、申し訳ありません。

教訓

コードレビューは製造を始めた初期段階でやりましょう