PR

 チーム開発支援機能を備えた最近の開発ツールやテスト・ツール,変更管理ツールなどを利用すると,さまざまなことを実現できる。例えば,テストを経ていないコードはチェック・イン(プロジェクトのソース・コードを格納するレポジトリに登録すること)できないように設定すれば,プログラマに単体テストの実施を義務付けられる。同様に,会社独自の開発プロセスやコーディング規約などの決まりごとに強制的に従わせることだって可能だ。

 Visual Studio 2005 Team Systemと,2006年6月に出荷が始まるTeam Foundation Serverとを組み合わせれば,プロジェクトに関する各種統計情報をレポジトリから自動的に取得してレポートを出力できるようになる。この機能は,マネージャがプロジェクトの進ちょく状況を把握したり,今後の予想(リリース予定日までにバグがつぶせるかなど)をしたりするためのものだが,プログラマにとってもメリットがある。レポジトリなどから情報を直接取得するため,プログラマが開発作業の合間をぬって報告書を書かなくても済むようになるからだ。

 しかし,使い方によってはプロジェクトではなく,プログラマを管理するツールとしても使えそうな点に少し不安を感じる。先のVisual Studio 2005 Team Systemでは,カスタマイズすれば,個々のプログラマが週に何行書いたかを棒グラフで一覧表示することも可能。だからといって,細かいところまで上から押さえつけるような形でプログラマを管理すれば,モチベーションが下がるなどして結局うまく機能しないのではないかと思うのである。

 特にテストの場合,テストの実施を強制しても,プログラマがテスト・ケースの作成で手を抜くようでは効果が期待できない。テストがどの程度有効かは,テスト・ケースの作り方に大きく依存する,というよりもむしろテスト・ケースの作り方がほとんどすべてといってよいからだ。プログラマが通すためだけのテスト・ケースを作るようになってしまったら何の意味もない。

 アジャイル開発に詳しい,チェンジビジョン代表取締役の平鍋 健児氏は,記者が以前別件で取材したときに,「プログラマに『テストするのが気持ちいい』という感覚にさせることが重要」と説いていた。実際,XP(エクストリーム・プログラミング)のテスト・ファーストでは,「テスト中毒」といってもよいくらいテストが好きになる人がいる。XPを導入しないまでも,テスト実施を習慣にすることで,「テストしないと何となく気持ちが悪い」という感覚にさせることはできるだろう。スペル・チェッカを常用している人が,スペル・チェッカを通さずに英文のドキュメントを提出するのを気持ち悪いと感じるのと同じである。もっと言えば,「夜寝る前に歯を磨かないと気持ち悪い」というのと同じく,“習慣”の問題と言えるかもしれない。

 ちなみにクライアント管理の分野では,すでにセキュリティ上の理由から,ツールによって社員を中央集権的に管理するのが一般的になりつつある。ただ,何をどのように監視・禁止するかはクライアント管理ツールによって違いがある。例えば業務と関係ないアプリケーションのインストールを防止するにしても,あるツールは無条件に禁止するのに対し,別のツールは「監視しています」と通知することで社員に「気付き」をうながすといった具合だ。さらに,導入したツールをどのように使うかは企業のポリシーや社員のセキュリティに対する意識の高さに依存する。ソフト開発の場合も,何をどのように管理すべきかは,開発チームごとに異なるだろう。

 記者の意見を言えば,チェック・イン前の単体テストについては,ツールで強制した方がよいと考えている。確実さが保障されるだけでなく,若い開発者への「習慣」付けができるメリットがあるからだ。ただ,その際にプログラマが,「強制されている」「押し付けられている」のではなく,うっかり何かをするのを忘れたときに「ツールが教えてくれるので便利だ」と感じられるようにすることが大切だろう。

 それには,個々のプログラマの意識の持ち方だけではなく,強制するルール自体や警告メッセージなどに十分配慮する必要がある。結局のところ,開発ツールはまず開発者のためのものであってほしい,というのが記者の願いである。