システムの品質を向上させるためには，実装工程における品質管理が欠かせない。これをきちんと実施するためには，ソースコードの書き方に関する決まりごとである「コーディング規約」が必須となる。電通国際情報サービスが2003年2月に策定した「Javaコーディング規約2003」を例に，その重要性と内容を解説する。
読者の皆さんは，「システムの品質とは何か」と問われたら何と答えるだろう。おそらく最も多い答えは，納品後の「バグの少なさ」ではないだろうか。
しかし，言うまでもなくシステム開発で考慮しなければならない品質は「バグの少なさ」だけではない。プログラムを変更しやすい「保守性」，リソースを効率的に使用する「効率性」，プラットフォームを変更しやすい「移植性」，障害が発生しにくい「信頼性」，使い勝手が良い「使用性」，ユーザーの要求を満たす「機能性」といった品質特性を，総合的に考慮しなければならない。
中でも重要なのが，システム稼働後の変更・保守費用に直接影響する「保守性」である。事実，TCO（Total Cost of Ownership）削減のために保守性の向上を目的として既存システムを再構築するユーザーは最近非常に増えているし，新規開発の場合でも，ビジネス上の変化の速さに対応するために，システムに機能拡張のしやすさ，つまり保守性の高さを求めるユーザーは多い。プログラミングの世界では，周知のとおり「リファクタリング」（プログラムの設計改善）という言葉もあるほどだ。
システムの保守性を高めるためには，実装工程（開発工程）で保守性の高い「良いコード」を作成しなければならない。具体的に言えば(1)可読性に優れており読みやすい，(2)インタフェースが直感的である，(3)変数などのネーミングが適切である，(4)ロジックがシンプルである，(5)コードの重複（コードクローン）が無い，(6)APIが適切に使用されている，といった条件を満たすソースコードである。
こうした条件を満たす良いコードを作成するためには，なんらかの「品質基準」に従ってプログラミングし，それを同じ品質基準に従ってレビュー（インスペクション）する必要がある。このソースコードの品質基準が「コーディング規約」だ。
本特集では，システム開発におけるコーディング規約の重要性を説明するとともに，電通国際情報サービスが独自に作成したコーディング規約である「Javaコーディング規約2003」の内容を紹介したい。実装工程における品質向上に役立てていただければ幸いだ。なお本記事では，主にSEやプロジェクト・マネジャーを対象に規約の内容を紹介するが，リーダークラスのプログラマにも十分に参考になるはずである。
テスト工程にしわ寄せが来る
コーディング規約とは，簡単に言えば「ソースコードの書き方に関する約束事」のことである。先に述べたように，コーディング規約は，実装工程での品質管理を行う際の「品質基準」となる。
とはいえ，実際には実装工程におけるソースコードの品質管理をきちんと行っているSEやプロジェクト・マネジャーは多くない。読者の中にも，「プログラマには，詳細設計書の説明を十分に行っている。このため実装工程でソースコードの品質をチェックする必要はない。品質はテスト工程で確かめればいい」と考え，プログラマに具体的な品質の基準を示していないエンジニアは多いのではないだろうか（図1[拡大表示]）。
多くのSEやプロジェクト・マネジャーが実装工程で品質管理をきちんと行わない原因の1つは，「SEの基本的な仕事は設計書を作ることであり，ソースコードを作るのはプログラマの仕事」と考えているからだろう。「実装工程での品質管理はSEの仕事ではない」というわけだ。
さらに，プログラムのソースコードが読めないために，どうしても「実装工程のことはプログラマに任せがちになる」というSEもいるのではないか。確かにシステム設計やプロジェクトマネジメント，開発プロセスの管理など，SEが行うべき仕事の範囲は幅広い。その上で，様々なプログラムの書き方まで指導・管理するのはかなり難しい。まして自分がプログラム言語を知らない場合，「設計したら後はプログラマにお任せ」と考えたくなる気持ちは理解できる。
しかし，ソースコードの品質チェックを「テスト工程」だけに頼り，実装はプログラマに任せたままでは，保守性の高い良いコードは出来上がらない。プログラマが，スケジュール通りに開発することだけを優先してしまい，保守性を二の次にしてしまう可能性が高いからだ。
非常に優秀なプログラマが1人でコーディングする場合は，それでも良いコードは作成できるかもしれない。しかし，最近の短納期・低予算のシステム開発では，会社もスキル・レベルも異なる複数のプログラマが集まってコーディングを進めることの方が多い。こうした状況で実装をプログラマに任せてしまえばどうなるか。極端なことを言えば，Javaに不慣れなプログラマがインターネットで見つけたサンプルコードを意味も分からずにそのままコピー・ペーストしてしまうこともあり得る。
その結果，結合テストの工程では様々な問題が発生することになる。例えば，障害原因になるコードが至る所にペーストされているために，それらすべてに修正を施さなければならなくなったり，Javaに不慣れなプログラマが書いたコードの可読性が悪いために修正に極端に時間がかかったりする。ユーザーに納品した後も，「ソースコードが汚く，保守性の点で品質を満たしていない」とクレームを受けかねない。
保守性，生産性が向上
ユーザー企業からシステム開発を請け負ったITベンダーのプロジェクト・マネジャーやSEは，構築するシステムの品質に責任を負っており，最終的にシステムの品質を左右するのはソースコードである。となれば，設計書の品質管理だけでは不十分なことは明らかだろう。やはり，しっかりしたコーディング規約を策定してプログラマにそれを遵守させ，SEや品質管理者がコーディング規約に沿ったインスペクションを実施する--という実装工程での品質管理をきちんと行うべきである。
実装工程でコーディング規約を導入すると，たとえ開発言語に不慣れなプログラマがいたとしても，品質が均質化したソースコードを作成できるようになる（図2[拡大表示]）。また，コーディング規約がソースコードの品質基準となるので，ソースコードの保守性向上にも直結する。
加えて，ソースコードが読めないSEでも，コーディング規約に違反しているかどうかをチェックすることで，ソースコードの品質管理を行えるようになる。コーディング規約を介することで，SEとプログラマ，あるいはプログラマ同士のコミュニケーションが円滑になり，結果的にプログラミングの生産性が向上するメリットもある。
既存のコーディング規約を改良
読者の中には，「コーディング規約なんて昔から使っている」というエンジニアもいると思う。だが，米サン・マイクロシステムズが作成した「Code Conventions for the Java Programming Language」などの既存のコーディング規約は，フォーマットやネーミング，コメントに関する規約が中心だった。主にソースコードの“見た目”を意識した内容となっているのである。これでは，保守性の観点から見て良いコードを書くには不十分な内容だ。
そこで，電通国際情報サービス（ISID）は，2003年2月にソースコードの保守性の向上に主眼を置いた「Javaコーディング規約2003」を新たに作成した。作成に当たっては，前述のCode Conventions for the Java Programming Languageなどの既存のコーディング規約をゼロから見直し，オブジェクト指向の特性に応じた内容に作り直すとともに，既存のコーディング規約にはない2つの項目を追加した（図3[拡大表示]）。
1つは，レベルの高いプログラマが持っている良いコードを作成する心得を分析・抽出した「コーディングの心得5カ条」。もう1つは，制御構造などのプログラミング言語の書き方と文字操作やコレクションなどに関するJava APIの使い方を定めた「プログラミング言語のイディオム規約」である。以下では，Javaコーディング規約2003で定めた規約の内容を説明していこう。
|
高安 厚思（たかやす あつし）／電通国際情報サービス 事業推進本部 開発技術部テクニカルエバンジェリスト 横浜国立大学経営学部卒。銀行系シンクタンクでオブジェクト指向技術の研究に携わった後，電通国際情報サービスに入社。オブジェクト指向やJavaの技術支援／標準化に従事。アーキテクチャ，モデル，プロセスが最近の探求対象 |
|
戸田 和宏（とだ かずひろ）／電通国際情報サービス 事業推進本部 開発技術部ITアーキテクト 筑波大学大学院理工学研究科修了後，電通国際情報サービスに入社。Javaを用いたフレームワーク構築やWebシステム開発を中心とした技術支援，プロジェクト監査を行っている |
