不確実性の時代に、アジャイル開発で向き合っていこう

第2回:ウォーターフォールに対するアンチテーゼとしての反復型開発とアジャイル

岡本修治 (KPMGコンサルティング)

2023-02-01 07:34

梗概

 現代社会は多くのものがソフトウェアで成り立っており、絶えず変化するニーズに応じられる柔軟でスピーディーな開発が求められています。その一方、何が正解(ゴール)なのかが分からない、という不確実性の時代でもあります。不確実性に対処するには「アジャイル開発」が最も有望ですが、その成功裏の実践には、従来の常識の解体と再構築が必要です。エンタープライズにおけるアジャイル開発の実践が待ったなしの状況の中、理論、課題、近年の動向も踏まえ、実例を交えながら幅広く解説します。

ウォーターフォール開発 - 誕生の背景と狙い

 アジャイル開発は21世紀の幕開けとともに本格的に普及し始めましたが、その本質を理解する最良の方法は、アジャイルがアンチテーゼとする、それまでの30年の長きにわたりシステム開発の主流であったウォーターフォール開発手法の狙いと特性を押さえることです。

 ウォーターフォール開発手法が誕生した1970年頃の状況を振り返ってみましょう。1960年代はまだソフトウェア開発の方法が確立されておらず、一部の優れたエンジニアの職人芸に頼る状況でした。ソフトウェアを作るために必要な期間や工数に加え、品質が要求水準を満たすのか、つまり、「Q(品質)C(コスト)D(納期)」が分からないことが最大の問題であり、これらを可視化し、制御できるようにすることが喫緊の課題でした。

 そのような状況を改善する方法として、工業製品の製造過程のように開発活動を幾つかの工程(局面)に分け、各工程の「活動内容」「作成物」「完了基準」を定義し、工程完了時にはステークホルダーの合意事項を文書で残し、次の工程に進める方式が提唱されました。これにより、進捗(しんちょく)を可視化して管理することができるようになるとともに、開発の早い段階から品質を作り込むことが目論まれました。

 この工程を分割する、いわば「局面化開発方式」ともいうべき方法を「ウォーターフォールモデル」と呼ぶことになったきっかけは、米国のWinston W. Royce氏が1970年に発表した論文「Managing the Development of Large Software Systems(大規模なソフトウェアシステム開発の管理)」(注1)で提唱された開発プロセス(図1)であるといわれています。

図1 Winston W. Royce氏の論文で提唱された開発プロセス 
(出所:「Managing the Development of Large Software Systems(大規模なソフトウェアシステム開発の管理)」を基にKPMG作成)
図1 Winston W. Royce氏の論文で提唱された開発プロセス
(出所:「Managing the Development of Large Software Systems(大規模なソフトウェアシステム開発の管理)」を基にKPMG作成)

(注1)Winston W. Royce[1970]“Managing the Development of Large Software Systems,” In ICSE '87 Proceedings of the 9th international conference on Software Engineering, pp.328-338(https://blog.jbrains.ca/assets/articles/royce1970.pdfなどから入手可能)

 Royce氏による前述の論文では、分割された各工程が階段状の滝(ウォーターフォール)の形式で表現されていますが、Royce氏自身は論文中において「ウォーターフォール」という言葉を使用していません。実際は、「隣り合う前後の工程間における反復を通じ、各工程の作業や成果物は精緻化されていく」と述べるにとどまり、また、「この仕組みの美徳は、変更管理プロセスを現実的に対処可能なボリュームまで引き下げてくれることである」としています。つまり、各工程は一度しか実施しない、文字通りの意味での「ウォーターフォール」とは本質的に異なるものです。

図2 願わくば、各フェーズ間の反復的な相互作用が連続したステップに限定されることを望む 
(出所:Winston W. Royce, [1970])
図2 願わくば、各フェーズ間の反復的な相互作用が連続したステップに限定されることを望む
(出所:Winston W. Royce, [1970])

 Royce氏は論文の中で、「私はこのコンセプトを信じてはいるが、この方式による実装はリスクが高く、失敗を招く。特に大規模ではうまくいかない」とし、さらに、作成物の動作検証を行う工程がリリース(運用開始)の直前に位置していることについては、「開発サイクルの最後に行われるテスト段階において、それまでの机上における分析・設計の結果が正しかったかどうかがようやく明らかになるわけだが、結果として想定通りには動かない可能性がある。場合によっては、その影響は設計のやり直し、さらには要件の見直しが必要なほど破壊的なものかもしれない」と述べており、実際の適用に当たっては強く注意喚起をしています。

図3 残念ながら、このプロセスにおいては、設計の反復が連続したステップに限定されることはない 
(出所:Winston W. Royce, [1970])
図3 残念ながら、このプロセスにおいては、設計の反復が連続したステップに限定されることはない
(出所:Winston W. Royce, [1970])

ZDNET Japan 記事を毎朝メールでまとめ読み(登録無料)

ホワイトペーパー

新着

ランキング

  1. セキュリティ

    ISMSとPマークは何が違うのか--第三者認証取得を目指す企業が最初に理解すべきこと

  2. セキュリティ

    情報セキュリティに対する懸念を解消、「ISMS認証」取得の検討から審査当日までのTo Doリスト

  3. 運用管理

    IT管理者ほど見落としがちな「Chrome」設定--ニーズに沿った更新制御も可能に

  4. セキュリティ

    シャドーITも見逃さない!複雑化する企業資産をさまざまな脅威から守る新たなアプローチ「EASM」とは

  5. セキュリティ

    従来型のセキュリティでは太刀打ちできない「生成AIによるサイバー攻撃」撃退法のススメ

ZDNET Japan クイックポール

所属する組織のデータ活用状況はどの段階にありますか?

NEWSLETTERS

エンタープライズコンピューティングの最前線を配信

ZDNET Japanは、CIOとITマネージャーを対象に、ビジネス課題の解決とITを活用した新たな価値創造を支援します。
ITビジネス全般については、CNET Japanをご覧ください。

このサイトでは、利用状況の把握や広告配信などのために、Cookieなどを使用してアクセスデータを取得・利用しています。 これ以降ページを遷移した場合、Cookieなどの設定や使用に同意したことになります。
Cookieなどの設定や使用の詳細、オプトアウトについては詳細をご覧ください。
[ 閉じる ]