このような進め方は、ウォーターフォール方式とは大きく異なる点です。ウォーターフォール方式の場合、単体テスト、結合テスト、総合テストといったように、段階的にプログラムの結合度合いを高めて検証を進めていきます。このため、検証の初期の方は、結合していないプログラムが多く、結合していない部分は設計内容を基にした想定によって検証することになります。
ご存じの通り、開発は複数名が携わって進行していきますので、その想定が開発メンバー全員で同じ認識であれば問題にはなりませんが、往々にして設計内容に曖昧さが残っていて、メンバー間での認識が異なる場合があります。このため、開発期間の終盤になって初めてプログラムを結合した際に、認識が異なっていた事項が原因で動かない箇所が複数発生し、修正に追われるといった事態を多く見かけることになるのです（図2における、「統合テストの開始」のタイミング）。
（図２）アジャイルプロセスとウォーターフォールプロセスにおける不具合（リスク）発見と解消のタイミングの違い
これは、第2回「ウォーターフォールに対するアンチテーゼとしての反復型開発とアジャイル」で紹介したWinston W. Royce氏による論文でも「開発サイクルの最後に行われるテスト段階において検知した不具合によっては、その影響は設計のやり直し、さらには要件の見直しが必要なほど破壊的なものかもしれない」と案じていた通りのことが、実際の現場で起きているのです（第2回の図3参照）。検証は不具合を見つけるためにあるものなので、検証中の不具合の検知をここで問題視することはありませんが、問題はその不具合が見つかるタイミングです。
開発期間の終盤に不具合が見つかると、本番稼働時期に近いこともあり、短い期間での修正を余儀なくされます。その期間に収まらないような不具合の量や難易度がある場合は、本番稼働時期の見直しにまで影響することもあります。システム開発を発注した企業側からすると、半年から数年の長い期間をかけて準備を進めて、「なぜもっと早く見つけられないのか」といった思いを強く抱くのは当然であり、実際によく耳にもします。一方で、アジャイル開発の場合は、数週間単位のサイクルの中で、常に動作するように、複数のプログラムの結合などの検証も含めながら進めるため、開発期間の終盤に不具合の検知が集中するような事態は必然的に避けられるのです。
質の高い状況管理
アジャイル開発では、課題などの状況の管理面においても、早期に共有される仕組みが備わっています。例えば、第4回「アジャイルに対する誤解（1）」で触れたアジャイルの代表的なフレームワークである「スクラム」では、日次ミーティングとして、1日の作業の始めにチームメンバー間で15分程度の状況を報告し合う機会を設け、メンバーが1人ずつ、前日の実施内容、当日の実施内容、課題を共有します。特に課題については、毎日共有することで、メンバー全員が認識し、必要に応じてすぐに対応できる状態を醸成することにつながります。課題は数日でも放置されると、全体への影響が大きく対応が難しくなる傾向があります。課題が品質に関わる内容である場合には、早期に共有されることによって、品質への悪影響も最小限にとどめながら進めることができるのです。
これまでの慣例では、週次定例会議などで1週間分の状況をまとめて報告することが多くあります。仮に、報告の直後に、一部のメンバーが課題を検知した場合、（本来はすぐにでも上長などに共有すべきですが）メンバーの意識によっては1週間共有されず放置される危険性もあります。ウォーターフォール方式では、開発期間は長期に及ぶことが多く、課題への対応も1週間程度のタイムラグであれば許容の範囲と思われるかもしれません。しかし、ウォーターフォール方式でも、1つ1つのタスクは数日刻みで実行され、かつ複数名が並行してタスクを進めているため、1週間分のタスク量は相当数になります。仮に、該当の課題が1週間で対応したタスクの全てに影響するとなった場合には、それらのタスクを全て見直す必要があり、影響は甚大となります。
このように、課題を早期に共有し、メンバー全員の課題意識が醸成されることは、品質を向上していく上で不可欠な要素です。また、ウォーターフォール方式を採用している場合であっても、組織によっては朝会のような形で日々課題を共有し合うような機会を設けて、その効力を実感している方も多いかと思います。実践されたことがない方でも、日次ミーティングは、汎用性の高い手法のため、開発方式にかかわらず一度試してみることをお勧めします。そして、日次ミーティングの効果を実感できたのであれば、アジャイル開発で実践される頻度の高い検証による効力も想像に難くないでしょう。
- 岡本 修治（おかもと・しゅうじ）
- KPMGコンサルティング Technology Strategy & Architecture シニアマネジャー
- 外資系総合ITベンダーにおいて大規模SI開発をはじめ、ソフトウェア開発プロセス／ツール展開のグローバルチーム、コンサルティング部門などを経て現職。金融、製造、情報通信など業界を問わずITソリューション選定、開発プロセスのアセスメント（評価）と改善、BPR支援などさまざまな経験を有し、中でも不確実性の時代と親和性が高いアジャイルトランスフォーメーションを通じた意識改革、開発組織の能力向上支援をライフワークとし注力している。
- 新田 明広（にった・あきひろ）
- KPMGコンサルティング Technology Strategy & Architecture マネジャー
- SEからキャリアを始め、金融、公共、小売りなど幅広く業界を担当し、主に基幹系システムの刷新に携わる。新規事業のプロダクト開発では、ビジネス環境の急速な変化に対応するため、アジャイル開発とデザイン思考を活用し実践。これらの経験を基に、企業のアジリティを高める顧客起点の価値提供を志向したシステム開発手法の推進に取り組んでいる。
