プロセスで品質を確保するパターンと課題

アジャイルのスクラム（以降アジャイルと記す）では、タイムボックスという考え方があります。これはあらかじめ決めた期間は実行時に起きる様々な事柄を起因として期限の延長をしたりない、というものです。ウォーターフォールでのシステム開発で公共系に多い、工程は一度決めたらベンダー都合で変えられないというのと同じといえば似ているかもしれません。

局面で品質を確保するのはアジャイルだけか
そのタイムボックスの期限がきたらソフトウェアをリリースしなければなりませんから、ソフトウェアの品質はタイムボックスの中で確保することが必要になります。アジャイルのタイムボックは早期リリーすることでビジネスへの貢献に寄与することが価値としているので、タイムボックスを短くするのが一般的です。短いタイムボックスのリソースを有効に活用するためには、人手がかかり繰り返す作業は自動化をすることで、開発に当てるリソースを確保するようになります。その例がテストの自動化やデプロイの自動化になるわけです。

一方、ウォーターフォールでのシステム開発では、設計、開発の長い期間を経たプロジェクトの最後の局面でテストを行うために要件や仕様が「要件と違う」など、リスクの不確実性をアジャイルでの開発のプレゼンなどでは飽きが来るほど繰り返し持ち出されています。

局面で品質をコントロールできるウォーターフォール
ところが、プロジェクトによっては、システム開発のひとつ一つの局面ごとに品質をプロセスとして組み込み、工程ごとに品質評価を行うという、まさに品質をコントロールしているケースもあります。

アジャイルと違うのは、アジャイルはタイムボックスでリリースするアウトプットがサービスとして利用できるということであり、ウォーターフォールはその局面のアウトプットに過ぎず、最終的なサービスとしての品質については対象となっていないということです。

ただ、これもプロジェクト計画の組み立て方としてアウトプットをインクリメンタルに開発してリリースする手法をとるならば、ほぼアジャイルのシステム開発と同等の価値が得られます。

プロセスで品質を確保することを織り込む
システム開発のパターンを見出すとするならば、アジャイルでもウォーターフォールでもタイムボックスという概念のスプリントや局面に対し、品質を確保するプロセスを織り込むことが必要です。

このプロセスに品質を織り込むパターンに対するアンチパターンは、「全部作ってから要件が充足していることを確認する検証を行う」です。簡便に言えば、タイムボックスの最後にテストを行うのはウォーターフォールのテスト工程で要件を確認するのと同じということです。ウォーターフォールであっても、工程の最後の週に外部レビューを詰め込むのはプロセスに品質を織り込むパターンではありません。

実現例
アジャイルであれば、日々の自動テストの実行がプロセスに品質を織り込むパターンであり、ウォーターフォールでは、工程の期初からアウトプットの構成要素となるコンテンツを外部レビューに掛け、要件の充足を確保するやり方になります。

つまり、どちらのシステム開発手法を取っても、プロセスに品質を織り込むパターンは実現されており、未知の世界ではないということです。

プロセスで品質を確保するパターンを適用する際の課題
アジャイルであればテストコードが要件を満たすコードとして日常的に維持されるためのリソースを確保することが挙げられます。ウォーターフォールでは、局面の期初から外部レビューの位置付けとしてセッションを設けるなどプロジェクトの開発標準プロセスに品質管理プロセスを組み込み、それがWBSとして計画し、実行されていることのモニタリングと品質状況も同じサイクルでモニタリングすることが挙げられます。

結局、わたしたちシステム開発に従事するシステムエンジニアがしなければならないのは次のことです。

All you need is the plan, the road map, and the courage to press on to your destination.
Earl Nightingale
All you need is the plan, the road map, and the courage to press on to your destination. - Earl Nightingale - BrainyQuote