やってはいけない、設計と実装の並行作業：分散開発のABC（後編）（3/4 ページ）

[三橋和広，株式会社オープントーン]

運用環境構築とテストリリース

運用環境構築とテストリリースのポイント

• 連結テストは1つの開発作業である
• データベース設計を別のところで行っているようなケースではリリースするだけで大きな工数が掛かる

　運用環境の構築は当初4カ月目の後半に予定され、東京の元請けによって構築されることになっていましたが、基幹開発側の進ちょくの遅れなどもあり、5カ月目の中旬にずれ込みました。

　開発側としては特に運用環境構築作業に参加する予定ではなかったので、作業負担として影響を受けることはあまり想定していませんでした。しかしながら、福岡の顧客へのテストリリースが遅れたことによって、時間的な問題から別の問題が発生していました。

開発環境、運用環境の差異

　開発環境の設定手順書を基に運用環境を構築することになっていたのですが、実際には開発環境＝運用環境とはいきませんでした。

　開発側では4カ月目の初旬でデータベース項目の更新を打ち切っていました。これは、いつまでもデータベース設計が流動的な状況での開発を避けるために東京の元請けにも予告していたことです。

　しかし、データベース定義書の更新締め切り以後も、連携相手の基幹側の更新は続き、開発環境用のデータベースと運用環境用（他社システムと連動）のデータベースで差異が生じてしまったのです。

　開発側からすれば、いつまでもデータベースの項目が決まらないことはあまりにも大きなリスクとなりますので、早期にデータベース定義更新の停止を依頼することでリスクの軽減を図りました。しかし、こういった連動システムの場合、データベースの定義変更の禁止が可能かどうかは事実上企業の力関係に支配されます。基幹システム側の、リリースギリギリまでの一方的なデータベース項目の修正により、連動するWebシステム側も多大な工数を投じて、急きょデータベース（DAO）とロジックの修正へ対応することとなってしまいました。

結合リリースに掛かる作業負担

　データベース（DAO）とロジックを修正したことによって、開発環境でそれまで使用していたテストデータも、そのままでは使用できなくなりました。テストデータの作成もそれなりに工数の掛かる作業です。修正前・修正後の相関性を合わせたテストデータを作るといった工数は相当なものでしたが、やむなくデータの再作成も行いました。

　さらに、データベース項目を合わせた後、基幹側が用意したデータでテストを行ってみると、画面が表示されない、プログラム例外が発生して落ちるなどの問題が頻発し、都度原因の追及と修正、リリースが繰り返されました。

　このことは、連動システムにおいて、連結テストが事実上開発として十分な工数が必要になることを意味しています。

　特に分散開発においては、全くコミュニュケーションのない開発者の作成したシステム同士が仕様書に従って連動するわけですから非常にリスクがあり、そこで1つの開発を再び行う必要を意味しています。

図7 要件定義→設計→実装→テスト→連結テスト＋実装！！