ASEが考えるアジャイル開発
アジャイル開発においては、ウォータフォールの開発手法に比べて品質管理が曖昧になる傾向があります。
そのため、以下のような考えかたに沿って品質を確保しています。
アジャイル開発の特徴
アジャイル開発における品質管理は、アジャイル開発の特徴の上に成り立っています。
アジャイル開発の特徴は以下の通りです。
- 「動くモノ」を段階的に確認できる ウォーターフォール開発では、ユーザーが動くシステムを確認できるのは納品後となります。 アジャイル開発では、『アジャイルソフトウェア開発宣言』における「包括的なドキュメントより動くソフトウェア」の通り、アジャイル開発では「動くモノを順次リリース」することにより、お客様は自身の要求が実現されているか随時確認でき、認識の相違等があればフィードバックとして伝えます。 従ってお客様が本当に求めているシステムを構築することができます。
- 要求の変化への対応 長い開発期間においては企業を取り巻く環境や競合他社の動向により要求に変化が生じる場合があります。 ウォーターフォールにおいては要件定義で決めたことは原則変更できませんが、アジャイル開発では『アジャイルソフトウェア開発宣言』における「計画に従うことよりも変化への対応を」の通り、要求の変化に柔軟に対応することでお客様にとって有用なシステムを構築します。
アジャイル開発のおける品質管理方針
アジャイル開発のおける品質管理方針は以下の4つです。
- 全体最適化 要件定義:システム化の目的・達成目標を明確にし、目的を実現する要求の開発を優先 総合テスト:業務運用を意識したシナリオテストや非機能要件の確認により本番運用に問題がないことを確認
- 発見より予防 コードレビュー:上級技術者によるレビューにより不具合の発生を防止し品質を均一化 テストコード:テストコードの記述によりテストの網羅性を確保しデグレードを防止
- ドキュメント作成 ドキュメント:必要なドキュメントは作成、無駄なドキュメントは作成しない 作成タイミング:動くモノを基にドキュメントを作成することで正確なドキュメントを提供 (プログラムから自動生成)
- 保守品質 不具合対応時間:発生した不具合については迅速な対応が目標 保守性:コードレビューやリファクタリングにより保守性の高い開発を実施
全体最適化
アジャイル開発では開発期間を一定の「期間(スプリント)」に分割し「設計・開発・テスト」を繰り返すことで「動くモノ」を順次リリースします。この「期間」の前後に以下の工程を設けることでシステムの全体最適化を図ります。
- 要件定義 アジャイル開発においてユーザーストーリーと呼ばれる要求に対応するだけでは部分最適化は図れるかもしれませんが、システムの全体像が見えにくくなります。アジャイル開発ではプロジェクトの最初に「要件定義」を行い、システム化の目的・達成目標を明確化することで、システム化の目的を実現する要求を優先的に開発します。 また、システム化の範囲を明確にすることでシステムの完成イメージを共有します。 ※システム化の範囲については要求の変化により開発過程において変更になる場合があります。
- 総合テスト アジャイル開発ではスプリント内でのテストだけでなくプロジェクトの最終段階で総合テストを実施します。 総合テストでは業務運用を意識したシナリオテスト及びセキュリティや性能等の非機能要件の確認も行います。 総合テストの実施により本番運用において問題がないことを確認しシステム全体の最適化を図ります。 ※総合テスト項目については網羅性確保のため実施前にお客様にレビューをして頂きます。
発見より予防
ウォーターフォール開発の品質管理においては「不具合をいかに発見するか」が重要なポイントとなっています。
アジャイル開発では不具合を発見することより「不具合を発生させない」ことを重視しています。
- コードレビュー(予防) 開発者とは別の上級技術者がソースコードをレビューすることにより不具合の発生を防止します。プロジェクトによっては複数の上級技術者が多段階レビューを実施します。 このコードレビューは不具合の防止だけでなく、プログラム品質の均一化にも効果があります。プログラムは開発基準等を作成していても開発者によりコードの相違が発生します。レビューの実施により個人差を無くし保守性の向上も図ります。
- テストコード(派遣) アジャイル開発の開発ではソースコードとともにテストコードも記述します。テストコードの記述によりテスト項目の網羅性を確保しデグレードの発生を防止します。 テストコードによる自動テストは人的テストにおけるテスト者への依存性を無くし、テスト品質の向上とテストの効率化を図ります。 ※アジャイル開発では自動テストと別に前述の「総合テスト」も実施します。
ドキュメントの作成
ウォーターフォール開発ではシステムそのものと同レベルでドキュメントも重要視されています。
アジャイル開発においては『アジャイルソフトウェア開発宣言』における「包括的なドキュメントより動くソフトウェア」の影響かドキュメントを軽視する傾向があります。
- ドキュメント作成 無駄なドキュメントは作成しません。使われないドキュメントを作成するくらいなら一つでも多くの要求を開発したり、テストを実施するほうが重要と考えています。 従って、ドキュメントの作成においても手書きよりツールを重視し、効率性や正確性を確保しています。
- 作成タイミング ウォーターフォール開発においてはドキュメントがレビュー対象で次工程へ進むための重要な要素となっているため開発に先駆けてドキュメントを作成します。 しかし、実際には仕様変更などで開発過程においてドキュメントの変更が発生したり、最悪の場合には開発したソフトウェアとドキュメントが不一致のケースもあります。 アジャイル開発においては動くモノがレビュー対象でありドキュメントはお客様のための納品物です。従って、プロジェクトの最終段階で動くソフトウェアから自動的にドキュメントを作成することで正確なドキュメントを提供します。 なお、開発中においても相互に認識合わせを行うために必要となるドキュメントは、随時作成します。
保守品質
システムは開発がゴールではありません。本番運用における満足度、有用性、可用性の高いシステムこそお客様に価値を提供できます。
アジャイル開発では本番運用における保守品質も重視しています。
- 不具合対応時間 システムにおいて不具合が発生した場合、対応に時間が掛かるほどお客様の業務運用やサービスに大きな影響を与えます。 アジャイル開発では不具合が発生した場合の「迅速な対応」を心掛けています。 ※不具合内容により迅速な対応が困難な場合もあります。また仕様変更についてはこの限りではありません。
- 保守性 不具合の対応時間の短縮化のためには、特定開発者への依存することなく「原因の特定」「改修作業」が迅速に実施できることが必要となります。 アジャイル開発では前述の「コードレビュー」により品質の均一化を行うとともに、リファクタリングの実施によりコードの可読性を向上し共通化を推進することで保守性の高い開発を実施します。