連載
NAgileで始める実践アジャイル開発

第6回 ソフトウェア開発の秘伝 "Development Baseline 2007"

自動化については、以前にも説明したので大丈夫だな？

はい。ビルド・エンジンはすでに使っています。

ここでいっている自動化は、ビルドの自動化だけでなく、常時結合も含まれるものだ。常時結合についても以前に説明したので、今日は自動化の重要な考え方を伝えることとしよう。それは、「CRISPなビルド」と呼ばれるものだ。

CRISPなビルド？！ そういうドーナツ屋さんが亜米利加（あめりか）にありましたね。日本での1号店が新宿にオープンしたとか。

それは、クリスピー・クリーム・ドーナツだ。スペルが違うだろ。

　CRISPなビルドとは、“Complete, Repeatable, Informative, Schedulable, Portable”のそれぞれの頭文字を取ったものだ。つまり、途中で手動の操作を必要としない完全な状態であり、繰り返し実行可能な、ビルドの成功／失敗などの詳細情報を出力できる、特定の手順に依存することなく好きな時間にスケジュール実行することができ、異なるマシンでも実行することができるビルドであることが重要ということだ。これは、『達人プログラマー』という書籍で紹介されている考え方だ。自動化にとって非常に重要な考え方である。

なるほど。確かにドーナツとは関係ないですね。

関係あるか！ 引っ張りすぎだ。では、次は標準化だ。

複数の開発者で作業を行う以上、最低限のルールは必要だ。それをまとめたのがこの標準化だな。

標準化というとガチガチなイメージがしますね。

そうだな。だが、Development Baselineではあくまで必要最低限なものを決めるという考え方があるのでガチガチではない。ここでは、コードの標準化と品質の標準化について説明しよう。

はい。

コードの標準化は、だいたい想像がつくと思うが、コーディング規約に従ってプログラミングを行うことが第一だ。偉大な先人によってまとめられたVisual BasicとC#のコーディング規約（のドキュメント）を次のURLから参照することができる。

• VB.NET／C#コーディング規約（オブジェクト倶楽部）

　これらは、.NET Framework 1.0の時代に作成されたものだが、現在最新の.NET Framework 2.0による開発でも十分に使える内容のものだ。

こうやって情報を公開してくれる偉大な先人がいるとありがたいですね。

そうだな。感謝の気持ちは常に忘れないように。

　それと、コードがコーディング規約に従っているかどうか検証を行う“FxCop”という無償のツールもある。これは、Visual Studio Team Systemの各エディションに標準で搭載されている機能でもある。下記URLよりダウンロードすれば、通常のVisual Studioから単体で使うことも可能だ。

• FxCop

　また、FxCopは常時結合のツールである“CruiseControl.NET”とも連携することが可能だ。CruiseControl.NETのFxCopレポートの画面は次のようになる。

CruiseControl.NETのFxCopレポート

FxCopによりコーディング規約に従っているか検証された結果が、CruiseControl.NETのWebユーザー・インターフェイスから確認することができる。

なるほど、いっぱい警告メッセージが出力されてますね。

ただし、FxCopの使用は必須ではない。

えっ？！ なぜFxCopは必須ではないのですか？

FxCopが標準で使用するコーディング規約は.NET Frameworkのクラス・ライブラリの標準に従ったものであり、かなり厳密だ。先ほどの画面を見て分かるように、普通にコードを書いただけでもかなりの警告メッセージが表示される。なので、プロジェクトに応じてこのルールは使う／使わないという設定を行う必要がある。

　しかしながら、FxCopのコーディング規約をカスタマイズするには、専用のアセンブリを開発する必要があり、かなりの工数を要する。もし、社内で使用する共通の開発標準のコーディング規約の検証ツールとしてFxCopを利用し、カスタマイズのための予算を積んでいるのならともかく、1つの開発プロジェクトでFxCopのコーディング規約のカスタマイズを行うことは現実的ではない。だから必須ではないのだ。

なるほど、コーディング規約を検証するために、工数を取られすぎても本末転倒ですものね。

そういうことだ。また、コーディング規約を守るだけで、標準化の本来の目的であるソフトウェアの品質を一定のレベルに保つことを達成できるわけではない。品質の標準化も同時に取り組むことが重要だ。

品質の標準化ですか？

そうだ。コーディング規約に従っただけのプログラムは、あくまで書き方のお作法が正しいだけで、それが美しいコードになるわけでも、十分なパフォーマンスが得られるわけでもない。当然ながら、不適切なアーキテクチャの基で作成したコードは満足なパフォーマンスが得られないだろうし、システムの中の1つのモジュールの品質が悪いだけでシステム全体として満足なパフォーマンスが得られないということだってある。つまり、品質の標準化は1人の努力や規約だけでは駄目で、チーム全員の協力と努力が必要ということだな。

なるほど。では、どうすれば品質の標準化を行うことができるのですか？

1つの答えとしては、コード・レビューとリファクタリングだな。作成したコードを1日1回でもよいので、ほかの人にレビューしてもらうこと、そして汚いコードはリファクタリングし、奇麗なコードに書き換えること。

　また、可能であればペア・プログラミング（＝2人組でコーディングを行うアジャイルの手法。以下ペア・プロ）を行うことで、常に第3者の目を意識しながらプログラミングを行うことができ、独りよがりのコードの記述ができなくなる。知識の共有という意味でもペア・プロは有効だ。

でも、ペア・プロというと、なかなか上司の理解が得られないものですよね。

気にすることではない。広い意味でいうと、実際の現場では普通にやっていることだ。

え？ ペア・プロをですか？

そうだ。滝も分からないことがあれば、そのことについて詳しい人に教えを請うだろう？ また、自分のプログラミングに問題があればほかの人に見てもらいながら開発するだろう？

確かに、それならよくやってます。

ペア・プロというと「1日中、2人でがっつりプログラミング！！」と思いがちだが、そうでなくてもよいのだ。分からないことがあれば周りに質問し、問題を抱えて悩んでいる人がいればちょっとの時間でも一緒に考えてあげる。大切なのはチーム内のコミュニケーション、決して時間の長さではない。チーム内のコミュニケーションを活発にすることで、品質を一定のレベルに保つことができる。さらに定期的に勉強会などを開催することで技術の底上げを行うことができる。それら複数の要素が組み合わさって初めて、品質を向上させることができるのだ。ペア・プロと聞いて肩ひじを張る必要はないので、まずは自分にできることからやってみるとよい。

それなら私にもできそうです。ちょっと勇気がわいてきました。

それと、メトリクス・ツール（＝品質を測定するツール）についても紹介しておこう。“NDepend”というツールで、無償ではないが、トライアル版も提供されているので試してみるとよいだろう。商用利用のプロジェクトでも2週間は無料で試せるので、試してみて損はないツールだ。

• NDepend

　また、NDependもCruiseControl.NETと連動させることができる。分析結果のレポートは次のようになる。

おおお！！ なんかいろんなレポートが見れますね。面白〜い。

NDependは確かに面白い。が、メトリクス・ツールを導入するだけで品質を確保できるわけではないということを忘れるでないぞ。

というと？

メトリクスはあくまで品質を計測するための指標にすぎん。つまりは中学や高校での期末試験のようなものだ。

期末試験？

そうだ。品質を向上させる取り組みを常に行っていなくては、メトリクス・ツールを導入する意味がないということだ。ここでいう品質を向上させる取り組みとは、コード・レビューやパフォーマンス測定などを行い、コードの問題点をリファクタリングし、コードの品質を改善するということだ。それらの取り組みを行ったうえでメトリクス・ツールを使えば、継続的に品質を向上させることができるのだ。品質を向上させる取り組みを行っていなければ、日ごろ勉強をしていないのに期末試験だけ何度も受けているようなものだ。試験を受けるだけで学力が向上するわけがなかろう。大切なのは日々の積み重ねだ。

そういわれると確かにそうですね。

われわれ開発者はツールに目を奪われがちだが、目的は常に忘れないようにしなければならん。標準化はソフトウェアの品質を一定のレベルに保つために行うのだ。そのためにも日常的に品質向上に取り組むことが大切だ。そのことをゆめゆめ忘れるでないぞ。

はい！ 心しておきます！！

よろしい。では、次にテスト駆動開発を説明しよう。