全13086文字
PR

 本特集ではこれまで基礎編と実践編を通し、一貫して「アジャイル開発らしさにとらわれず、ウオーターフォール型開発の経験も生かすべきだ」と主張してきた。だが、アジャイル開発にはウオーターフォール型開発の「常識」が当てはまらない部分があるのも事実である。実践編の最終回として、特に注意すべき6つの違いを説明する。

違い1:成果物は「正常に動く機能」そのもの

 最初の違いは、開発したプログラムを本番環境に展開するデプロイ作業の考え方だ。

 一般的な請負契約のウオーターフォール型開発では、ソースコードや実行可能なプログラムそのものが契約対象の成果物となる。そのため、ソースコードに不具合がないことは当然として、ソースコードそのものがコーディング規約に沿った「完成品」であることが求められる。

 通常、テスト環境で開発ベンダーが動作に不具合がないことを確認したプログラムは、発注者側に納品され、発注者側の最終確認を経て本番環境にデプロイされる。多くのプロジェクトでは、デプロイ時点でソースコードの記述そのものをチェックすることはないものの、コーディング規約に沿った完成品であることが開発側と発注側の共通の前提となっている。

 しかし、アジャイル開発にはこの考え方を適用すべきではない。根本的な考え方の違いがあるためだ。

 アジャイル開発では、ソースコードやプログラムではなく、「正常に動く機能」そのものを成果物と考える。そのため、極端に言えば、たとえソースコードがコーディング規約に沿っていなかったとしても、また、別途追加開発中の書きかけのソースコードが含まれていたとしても、対象機能を実行するうえで影響を与えないと確約できていれば、その時点での納品物としては問題がなく、本番環境にデプロイ可能と考える。

図 アジャイル開発でデプロイされるプログラム
図 アジャイル開発でデプロイされるプログラム
成果物は「プログラム」ではなく「正常に動く機能」(出所:シグマクシス)
[画像のクリックで拡大表示]

 アジャイル開発の開発現場では「CI/CD(継続的インテグレーション/継続的デリバリー)」という開発プロセスが一般に広まっている。CIはプログラムが登録されたり変更されたりすると自動的・定期的にテストやビルドまで実行できるようにする手法である。CDはCIに加えデプロイも自動化する手法だ。

 CI/CDを導入することで、シナリオテストまで完了したプログラムだけをリリースに合わせてビルドしていくのではなく、単体テストが完了したプログラムもタイムリーにテスト環境にある既存のプログラムに統合されていく。デプロイは単体のプログラムのみを対象とするのではなく、依存関係があるプログラムも対象となるため、デプロイ対象となるプログラム群の中には、シナリオテストが完了したプログラムとシナリオテストの途中にあるプログラムが混在する。

 ときには、将来的にリファクタリング(保守性や拡張性の向上を目的として、複雑化したプログラムの内部構造を整理する作業)の対象になるであろう、コーディング規約に沿わないソースコードや可読性の低いソースコードも混在する状態となる。

 そもそもアジャイル開発は、ただ1つのリリース日を目指してプロジェクトを進めるのではなく、五月雨のリリースをよしとしている。そのため、デプロイ対象のプログラムが全て完全済みではない状態はむしろ当たり前といえる。

 もちろん、プログラムのバージョンを厳密に管理して、デプロイ前にその対象からテスト途中のプログラムを除いたり、ソースコードのレビューを徹底させたりすることで、アジャイル開発においてもウオーターフォール型開発と同等にソースコードやプログラムの(直接機能に関わらない見た目上の)完成度を担保することはできる。しかし、こうした管理はデプロイに関する作業を煩雑にし、アジャイル開発のメリットである俊敏性を損なわせかねない。