ウォーターフォールの開発業務と社内ルールを
CI導入のための準備を整えていくのは難しいかもしれませんが、
いくつかのコツを押さえれば無理なく行うことが出来ました。

1.最初だけ家で勉強して検証する

CIをする上では、例えばJavaのプロジェクトであればJenkinsの他に
JUnit4、selenium2、Maven、DBUnit、Mockito、PowerMock等の
知識と動作検証が必要になってきます。
業務が大変で業務中に学習や検証が難しかったので
一旦は家で学習、検証しました。
最初だけ個人的な時間を使えば、
後でCIによる効率化で時間が返ってきますから
じきに業務を行いながらCIを進めていくことができるようになりました。

2.まずデプロイから自動化する

開発工程においてテスト環境へのデプロイ作業は
テスト以上に繰り返し行われることが多いでしょう。
テストより先にまずデプロイだけでも自動化してしまえば
この後のテスト作成時間を稼ぎやすくなりますので
デプロイ作業を真っ先にJenkinsに実装しました。
普段どのようなデプロイ作業をしているかにもよりますが、
環境によって設定ファイルを置き換えていたりするとき
手作業だと設定ファイルを間違って違う設定ファイルで上書きしてしまったりして
テスト開始までに余計な時間がかかるといったようなことがありましたが
自動化することで回避できました。

3.最初から完全なテストをコーディングしようとしない

例えばDAOのテストはテストデータを定義して
データベースにテストデータを投入しなければ常に同じ結果は返ってきませんが、
そんなテストでもないよりマシだったりします。
普段コーディングしながら動作確認するときも
正式なテストとして実施するとき以外は
データベースのレコードにしっかりしたテストデータを投入することは
あまりしないと思います。
特にウォーターフォールのルールのもとでは
必ず人力によるテストはすることになりますから、
それよりも普段何度も行うちょっとした動作確認を
自動化するように考えてテストをコーディングしていきました。
これでまた時間が稼げます。

4.webアプリケーションの場合seleniumでUIテストプロジェクトを別に作成する

こちらも、まずDBの更新が伴う部分は無視して、
リンクや表示の確認だけ作ってしまうのが良かったです。
動作確認対象のブラウザが複数ある場合、
特に自動化による恩恵が受けやすいです。
サーバーサイドのコードが新規でなく、テストし辛いスパゲティコードや
大きなメソッドばかりの場合、サーバーサイドのコードの単体テストよりも
UIのテストから作っていった方が開発効率が上げやすいこともあります。
スクリーンショットも撮ってテスト結果のhtmlドキュメントを生成して
それにスクリーンショットのサムネイルを貼り付け、
開発中の処理実行待ち時間などにちらちらと見ることで
画面の異常を素早く検知できました。

5.自分の周りの人の作業をJenkinsで手伝う

この時点で既に周りの人よりもかなり作業効率が上がっていました。
自分の作業に余裕が出てきたら周りの人の作業をJenkinsを使って手伝いました。
周りの人を手伝うためのJenkinsのプロジェクトを作ったら
自分の端末のJenkinsを周りの人の端末からでもアクセスできるようにして
自分以外の人からも実行できるようにしました。
こうしていくことでCIの便利さを徐々に組織に浸透させていくことができました。