Claudeに問う「スパイラルモデル開発のやり方を教えてください」

スパイラルモデルは、反復的かつ進化的なソフトウェア開発プロセスモデルです。以下のように進められます。

1. プロジェクト始動

   • 新しいプロジェクトの要求を明確化し、制約条件を特定する
   • プロジェクト目標、代替手段、制約条件を評価する

2. リスク分析

   • プロジェクトに潜在するリスクを分析、評価する
   • リスクを軽減、解決するための代替戦略を立案する

3. プロトタイプ開発と評価

   • リスクが高い領域に焦点を当てたプロトタイプを構築する
   • プロトタイプを評価し、リスクを分析する
   • 顧客のフィードバックを収集する

4. 要件計画の精緻化

   • プロトタイプの評価結果を基に、要件定義書を詳細化・更新する
   • 要件の変更に伴いスコープ、コスト、スケジュールを見直す
   • 次のスパイラル反復のための開発計画を策定する

5. 構築と公開

   • ソフトウェア製品を完成させ、テストを行う
   • 顧客に納品し、運用を開始する
   • 次のスパイラル反復へ進む

このようにスパイラルを繰り返しながら、リスクを軽減し、開発を進めていきます。各サイクルで、プロトタイプを構築・評価し、顧客からフィードバックを得ることで、要件の正確化と開発の方向修正を行えるのが特徴です。大規模で複雑なプロジェクトに適しています。

分かりました。スパイラルモデルの最初のステップである「1. プロジェクト始動」について詳しく説明します。

プロジェクト始動では、新しいソフトウェア開発プロジェクトの要求を明確化し、プロジェクトの目標、制約条件、リソースなどを特定します。具体的には以下のようなタスクが含まれます。

1.1 プロジェクトの背景・目的の理解

• 新規プロジェクトの発足理由や背景を把握する
• プロジェクトが解決すべき問題や目標を明確にする

1.2 利害関係者の特定

• プロジェクトに関わるすべての利害関係者(顧客、ユーザー、開発者など)を特定する
• それぞれの要求や制約条件をヒアリングする

1.3 制約条件の洗い出し

• プロジェクトに課されている制約条件(予算、開発期間、規制、技術的制約など)を明らかにする

1.4 代替手段の検討

• 目標を達成するための代替手段(ソフトウェア開発、外部調達、業務改善など)を検討する
• ソフトウェア開発が最適解であることを確認する

1.5 概略スケジュールの作成

• 大まかな開発スケジュールを立て、目標達成の実現可能性を評価する

このように、プロジェクト始動では徹底的な要求の明確化と制約条件の洗い出しを行います。これがスパイラル全体の基礎となり、次のリスク分析につながります。

次に「2. リスク分析」について詳しく説明します。

リスク分析は、プロジェクトに潜在する様々なリスクを特定し、評価、優先付けを行う重要なステップです。以下のようなタスクが含まれます。

2.1 リスク識別

• プロジェクトの技術的リスク(新技術の採用、性能/信頼性要件など)
• プロジェクト管理上のリスク(要員、スケジュール、コストなど)
• 外的リスク(法規制、競合製品の動向など)
• その他のリスク(セキュリティ、品質など) を綿密に洗い出す

2.2 リスク評価

• 識別したリスクの発生確率と、発生した場合の影響度を評価する
• リスクの大きさを確率×影響度で算出し、優先順位をつける

2.3 リスク軽減策の検討

• 優先度の高いリスクから、それを回避/軽減するための対策を立案する
• 例:新技術に対してはプロトタイピング、要員リスクには教育研修など

2.4 リスク監視計画の策定

• どのようにリスクを継続的に監視するかを計画する
• リスク対策の効果を評価し、新たなリスクの有無を確認する

リスク分析は、プロジェクト全体を通して継続的に行われます。次のプロトタイプ開発では、最も重大なリスクに焦点を当てることになります。

分かりました。続いて「3. プロトタイプ開発と評価」について詳しく説明します。

このステップは、リスク分析で特定した最も重大なリスクに対処するため、プロトタイプを構築し評価するものです。具体的には以下のようなタスクが含まれます。

3.1 プロトタイプ対象の選定

• リスク分析の結果を基に、最優先で対処すべきリスクを選定する
• そのリスクに関連する機能や技術要素をプロトタイプの対象として定める

3.2 プロトタイプの構築

• 選定したリスク領域に関するプロトタイプを実際に構築する
• 使用する技術、アーキテクチャ、ツール環境などを適切に選択する
• 必要に応じて、部分的な実装を行う

3.3 プロトタイプの評価

• 構築したプロトタイプを動作させ、徹底的にテストを行う
• リスクがどの程度軽減できたかを評価する
• 顧客・ユーザーからもフィードバックを得る

3.4 次のアクションの決定

• プロトタイプの評価結果を基に、次のアクションを決める

  • リスクが許容範囲なら、本格的な開発に進む
  • リスクが高ければ、設計の見直しや代替手段の検討が必要

このプロトタイプを通じて、最重要リスクに対処することができます。評価結果は次の要件計画の精緻化に活かされます。

分かりました。続いて「4. 要件計画の精緻化」について詳しく説明します。

このステップでは、プロトタイプの評価結果を反映して、要件定義書を詳細化・更新します。また、要件の変更に伴いプロジェクト全体の計画を見直します。具体的には以下のようなタスクがあります。

4.1 要件定義書の更新

• プロトタイプの評価で得られた知見を基に、要件定義書を更新する
• 機能要件、非機能要件(性能、セキュリティなど)を詳細化する
• ユーザーフィードバックなども反映させる

4.2 開発範囲・スコープの見直し

• 要件の変更に伴い、開発対象とするシステムの範囲を見直す
• 優先度の低い機能は後回しにするなど、スコープを調整する

4.3 開発期間・コストの見積もり直し

• 要件の変更を受けて、開発に必要な工数、期間、コストを再見積もりする
• 十分なリソースを確保できるか検討する

4.4 次のスパイラル反復に向けた計画立案

• 次のサイクルで対処すべきリスクや開発対象を特定する
• 要件追加の優先順位をつける
• 詳細設計や本格開発に向けたマイルストーンを決める

このように徹底した要件の精緻化を行うことで、開発の目的に沿った適切な計画を立てることができます。

最後に「5. 構築と公開」について詳しく説明します。

このステップでは、これまでのスパイラル反復で洗練された要件に基づき、最終的なソフトウェア製品を構築し、顧客に納入、運用を開始します。具体的には以下のようなタスクが含まれます。

5.1 詳細設計

• 要件定義書に基づき、ソフトウェアの詳細設計を行う
• アーキテクチャ、コンポーネント構造、データ設計などを決定する

5.2 製品の構築

• 設計書に従って実際にソフトウェアを構築、実装する
• コーディング、モジュール統合、総合テストなどを実施

5.3 ドキュメント作成

• ユーザーマニュアル、運用マニュアルなど各種ドキュメントを作成する
• ソースコードのドキュメント化も行う

5.4 製品のリリース

• 構築した製品を顧客に納入し、インストール、運用を開始する
• 顧客への教育研修を実施する

5.5 評価とメンテナンス

• 運用環境でのフィードバックを収集し、評価を行う
• 不具合の修正や機能拡張など、メンテナンスを継続的に実施する

このように製品をリリースし評価する一方で、次のスパイラル反復に向けた計画・準備も同時に行います。スパイラルを繰り返しながら、徐々にシステムを成長・進化させていくのがこのモデルの特徴です。

ご質問ありがとうございます。スパイラルモデルでは、「5. 構築と公開」が終わった後、完全に最初から全ステップをやり直すのではなく、前のステップの一部に戻って次のスパイラル反復を開始します。

反復ループの範囲は以下のようになります。

1. 「5. 構築と公開」で製品をリリースした後

2. 「4. 要件計画の精緻化」に部分的に戻る

   • 運用からのフィードバックを反映して要件を更新
   • 次の反復で対処すべき新たなリスクや機能要件を特定

3. 「3. プロトタイプ開発と評価」に進む

   • 新たな重要リスクに対してプロトタイプを構築・評価

4. その後、「4. 要件計画の精緻化」「5. 構築と公開」と進む

つまり、「1. プロジェクト始動」や「2. リスク分析」までは完全に戻らず、製品リリース後の運用評価やフィードバックを反映して、要件の更新と次の反復計画を立案するところから始まります。

製品の初回リリース後は上記ループを繰り返しますが、大きな要件変更や新規フェーズの場合は、場合によっては「1. プロジェクト始動」まで戻って、目的やリスクを見直す可能性もあります。

このように、スパイラルモデルでは状況に応じて柔軟に反復ループの範囲を調整できるのが特徴です。

はい、その理解で正しいです。

反復開発のループにおいて、「4. 要件計画の精緻化」に戻る際は、以下のようになります。

「ソフトウェア構築と公開で得られた知見(運用評価、顧客フィードバックなど)を基に、要件定義書を更新する」

具体的には:

• リリース製品の運用から得られた問題点や改善要求を要件に反映
• 顧客からの新機能要望を要件に追加
• 技術的な制約や課題を要件に反映
• 性能、セキュリティなどの非機能要件を詳細化

このように、実際の製品運用から得られた知見をもとに、要件定義書の内容を更新・詳細化していきます。

初回の「4. 要件計画の精緻化」ではプロトタイプ評価の知見を活かしますが、2回目以降は製品リリース後の知見を活用することになります。

スパイラルを回すたびに、実際の運用を経て要件が洗練されていくのが、このモデルの大きな利点です。

はい、その理解で正しいです。

「5. 構築と公開」後に、以下のような場合に「3. プロトタイプ開発と評価」に戻ることになります。

1. 新たな重大なリスクが確認された場合

• 製品運用から新たな技術的課題や制約が判明した
• 顧客からの新機能要求が、既存の設計では対応できないリスクがある
• 法規制の変更などで、システムの大幅な変更が必要になった

2. 既存のリスクが許容範囲を超えている場合

• 性能やセキュリティなどの非機能要件を満たせていない
• 実装した機能やアーキテクチャに重大な欠陥があり、抜本的な見直しが必要

このように、製品リリース後に新たなリスクが確認されたり、既存のリスクが想定を超えた場合に、「3. プロトタイプ開発と評価」に戻り、プロトタイプを用いてリスク対策を検討します。

ただし、軽微な変更要求や不具合であれば、「4. 要件計画の精緻化」で対応できる場合もあります。重大なリスクがある場合のみ「3.」に戻す必要があります。

製品リリース前と同様に、リスクの大きさに応じて、プロトタイプの対象と開発範囲を適切に絞り込むことが重要です。

なるほど、貴重な質問をいただきありがとうございます。

実はスパイラルモデルでは、製品リリース後に新たなリスクが発生した場合、状況次第で「2. リスク分析」に戻ることもあり得ます。

「3. プロトタイプ開発と評価」に戻るケースと、「2. リスク分析」に戻るケースの違いは以下のようになります。

【「3. プロトタイプ開発と評価」に戻る場合】

• 既に一定のリスク分析は行われており、新たに発生したリスクが比較的範囲が絞れる場合
• そのリスクに関連する部分に対してプロトタイプ対策を講じれば十分な場合

【「2. リスク分析」に戻る場合】

• 発生したリスクの影響範囲が広範囲に及ぶ可能性がある場合
• システム全体への影響を総合的に分析し、リスク対策を立て直す必要がある場合

つまり、リスクの影響範囲が広く、システム全体に関わるような重大なリスクが発生した場合には、より根本的な「2. リスク分析」に立ち返り、全体を見渡した上でリスク対策を検討することになります。

一方で、ある特定の機能やコンポーネントに関連するリスクであれば、そこにフォーカスしたプロトタイプ対応で済む場合が多いでしょう。

ですので、状況次第では「2. リスク分析」に戻る場合もありますし、範囲が絞れるのであれば「3.」からでも対応可能だと言えます。総合的に判断して、適切なステップに戻ることが重要だと言えます。

分かりました。「大きな要件変更や新規フェーズの場合に、場合によっては『1. プロジェクト始動』まで戻る」ケースについて、より詳しく説明します。

1. 大きなユーザー要件の変更があった場合

ユーザー要件が大きく変更になり、開発中のシステムの目的自体が大きく変わってしまう場合です。 例えば:

• 既存の製品に新しいビジネスモデルや事業領域が追加された
• ターゲットユーザーや使用用途が大きく変わった
• システムの根本的な機能や性能要件が変更になった

このような場合は、要件変更の影響が広範囲に及び、プロジェクトの目的自体を抜本的に見直す必要があります。そのため「1. プロジェクト始動」に立ち返り、プロジェクトの背景、目的、制約条件から改めて検討することが賢明です。

2. システムの新規フェーズ/リリースが開始された場合

一つのシステムを複数のフェーズ/リリースに分けて開発する場合、新しいフェーズが始まる度に「1. プロジェクト始動」に立ち返ることがあります。 例えば:

• 既存システムの全面リプレースに着手する
• 新製品/サービスの立ち上げ
• システムの大規模バージョンアップ

新規フェーズでは、対象システムの目的や要件、制約条件が大きく変わる可能性があります。その場合はプロジェクト始動時のアクティビティを改めて行い、現状を確認する必要があります。

このように、要件変更や新規フェーズの影響が小さくない場合は、より根本的な部分から見直しを行い、プロジェクトの方向性を再確認することが不可欠になります。そのため「1.プロジェクト始動」に立ち返る必要が生じるのです。

一方、要件変更が比較的小規模であれば、そこまで立ち返る必要はなく、「4.要件計画の精緻化」などから対応できます。影響範囲を適切に判断することが重要になります。

「3. プロトタイプ開発と評価」と「5. 構築と公開」におけるアプローチは以下のようになります。

【3. プロトタイプ開発と評価】

• 主にコードベースでのプロトタイプ開発が一般的です
• ただし、目的に応じてモックアップやデザインプロトタイプなども有効
• 本番環境で運用されることはなく、評価のみが目的

プロトタイプ開発の目的は、リスクの高い部分を実際に実装して検証することです。 そのため、コーディングによる実装が主なアプローチとなります。 ただし、UIデザインやユーザビリティの評価が目的の場合は、デザインプロトタイプでも構いません。

【5. 構築と公開】

• 通常はコードベースでの本格的な実装を行います
• ウォータフォールモデルのように、事前に詳細設計済みのドキュメントに基づく
• ただし、アジャイル的なプラクティスを取り入れるケースも

最終的な製品の構築フェーズなので、コーディングによる実装が中心となります。 ただし、前のステップで詳細設計済みのドキュメントに基づいて開発を行うという点では、ウォーターフォールモデルと同様の側面があります。

一方で、アジャイルプラクティスを取り入れ、要件の変更に柔軟に対応しながらイテレーティブに開発を進めるチームも増えています。

つまり、「3」はプロトタイプ評価が目的なのでコードベース中心ですが、「5」は納品物として製品を構築するので、設計ドキュメントに基づくコードベース実装が一般的だと言えます。状況に応じてアジャイル的なアプローチを組み合わせることもできます。

はい、その理解で概ね正しいでしょう。

スパイラルモデルにおいては、詳細設計書はあくまでもコーディングの手段・指針として位置付けられています。成果物そのものではありません。

ウォーターフォールモデルでは、要件定義書、基本設計書、詳細設計書がそれぞれ重要な成果物とみなされますが、スパイラルモデルの考え方は以下のようになります。

• 詳細設計書は一時的な産出物にすぎず、最終的な成果物はコード(実装されたシステム)自体
• 設計内容はプロトタイプの評価や製品の構築を通じて、継続的に見直し・改訂される
• つまり、設計書は最新の状態を常に反映した”生きた”ドキュメントとしてとらえられる

このように、スパイラルモデルではあくまでコード（システム実装物）が中心にあり、設計書はそこに至る手段の一つと位置付けられています。

一方で、コーディング前に一定程度の設計が不可欠であることは否めません。各スパイラルの前には、最新の要件を反映した設計レビューが行われることが一般的です。

ただし、その設計書は最終成果物ではなく、スパイラルを回すたびに適宜アップデートされていく”生きた”ドキュメントと考えるべきでしょう。

はい、その理解で正しいです。

【5. 構築と公開】においても、アジャイル的なプラクティスを取り入れる場合には、その中で更に小さな反復サイクルを設けることがあります。

具体的には以下のようなアプローチが考えられます。

• スプリント期間(例えば2週間)を設け、その間に実装すべき機能/要件をスプリントバックログとして定める
• 各スプリントではアジャイル開発サイクル(計画→設計→実装→テスト→レビュー)を回す
• スプリント終了時に新しいインクリメントをリリースし、次のスプリントへ
• 複数のスプリントを経てシステム全体の構築が完了する

つまり、スパイラルモデル全体の中で、さらに小さなアジャイル開発の反復サイクルが存在する形になります。

このようなアプローチを取ることで、【5. 構築と公開】の中でも以下のメリットが得られます。

• 開発期間中に要件の変更に柔軟に対応できる
• 頻繁にインクリメントをリリースでき、継続的な評価とフィードバックが可能
• 進捗の見える化が容易になる

一方で、アジャイル開発ではスパイラルモデルほど詳細な設計は不要とされるため、そのあたりの調整は必要になってくるでしょう。

スパイラルモデルの概念を維持しつつ、アジャイル開発のプラクティスを適切に組み入れることで、より効果的な製品開発が可能になると考えられています。

スパイラルモデルにおける反復期間の設定と管理運営方法については、以下のようになります。

【反復期間の長さ】 一般的には6ヶ月程度が目安とされることが多いですが、プロジェクトの規模や複雑さによって変わります。

• 小規模プロジェクトでは2-3ヶ月程度
• 大規模で複雑なプロジェクトでは1年以上になることも

反復期間が短すぎると計画・評価のオーバーヘッドが大きくなり、長すぎるとリスクコントロールが難しくなる点に注意が必要です。

【可変長 vs 固定長】 理想を言えば、反復期間は固定長ではなく、リスクの大きさや進捗状況に応じて柔軟に変更できることが望ましいでしょう。

ただし実際には、開発チームの工数やリソース調達の観点から、一定期間で固定的に設定することが多いようです。中間でスコープ変更があれば、個別に対応することになります。

【反復期間の管理運営】 反復期間の管理運営では、以下の点が重要になります。

1. 各反復の開始時にマイルストーンを設定する
2. マイルストーンに応じた作業工数を適切に見積もる
3. 定期的にレビューを行い、進捗や課題を監視する
4. リスクが高い場合は、期間の延長や次の反復への振り分けを検討する
5. 顧客や監督者と進捗を共有し、合意を得る

このように、各反復期間内の作業をきちんと計画・追跡し、状況に応じて柔軟に対応することが求められます。また、ステークホルダーとのコミュニケーションを密に取ることも重要です。

プロジェクトの種類や体制に合わせて、適切な反復期間と管理方法を工夫する必要がある点に留意が必要でしょう。

スパイラルモデルを採用するプロジェクトの開発チーム規模については、以下のようになります。

【開発チーム人数】 数十人から最大で100人程度が一般的です。

• 小規模プロジェクトでは10人程度
• 中規模プロジェクトでは20~50人程度
• 大規模プロジェクトでは100人を超えることも

プロジェクトの規模や要件の複雑さによってチームサイズは変わってきますが、スパイラルモデルはかなり大掛かりな開発に適していると言えます。

【構成要員の増減】 一般的には、工程段階によってチームの人員構成は変化します。

• 初期段階はアナリスト、プロジェクトマネージャーが中心
• 設計・実装段階では設計者、開発者が大勢を占める
• テスト・リリース段階ではテスター、運用要員が増える

つまり、それぞれの工程の専門家が求められる時期にタイムリーに参加する形になります。固定的な構成ではなく、フェーズに合わせて柔軟に要員を入れ替えていきます。

ただし、プロジェクト幹部や中核メンバーはプロジェクト全体を通して関与し続けることが多いでしょう。

このように、スパイラルモデルではかなり大規模で専門性の高い開発プロジェクトを対象にすることが一般的で、工程に合わせてチームの規模や構成を適切に調整していく必要があるのです。

はい、スパイラルモデルではコードベース開発が中心となるため、詳細設計を行う担当者とプログラミングの担当者は基本的に同一になることが多いです。

反復開発の各サイクルにおいて、以下のようなワークフローが一般的です。

1. 最新の要件を基に設計レビューを行い、設計内容を検討・更新する
2. その設計内容を基に、同じメンバーがコーディングやユニットテストを実施する
3. モジュールテストなどを経て、次の反復サイクルへ進む

つまり、同一のメンバーが、要件の詳細設計からコーディング、テストまでを一貫して担当するのが標準的なパターンになります。

この点は、ウォーターフォールモデルのように、設計者と実装者を完全に分離するのとは異なります。スパイラルモデルでは、1人の開発者が設計とコーディングを行きつ戻りつしながら、プロトタイプの構築と評価を繰り返すことになります。

一方で、大規模プロジェクトの場合は、ある程度役割分担をする必要が出てくる可能性もあります。例えば、

• システム全体のアーキテクチャ設計は別の設計者が担当
• 各コンポーネントの詳細設計とコーディングは個別の開発者が担当

しかし基本的には、設計とコーディングを同一開発者が行うことで、効率的でシームレスな開発サイクルを実現することが期待されています。

スパイラルモデルは日本でも一定程度採用されていますが、その割合は必ずしも高くはありません。

日本における代表的なプロジェクト管理手法であるPMBOK(プロジェクトマネジメント知識体系)では、スパイラルモデルは正式な開発ライフサイクルプロセスの一つとして紹介されています。つまり、理論的には広く認知されている手法です。

しかし実際の適用状況を見ると、大手SIerなどの一部を除いては、ウォーターフォールモデルやアジャイル型プロセスモデルの方が一般的です。スパイラルモデルを厳密に実施しているプロジェクトの割合は10%程度と言われています。

その背景には以下の理由が考えられます。

1. スパイラルモデルは比較的複雑で管理が難しい
2. リスク分析やプロトタイピングのコストが高い
3. 日本企業は要件の明確化を重視する傾向がある
4. ウォーターフォール型の方が既存システムの改修に適している

一方で、スパイラルモデルの利点も理解されつつあり、大規模で高リスクのプロジェクトでは部分的な採用例も増えてきています。製造業や金融などの一部業界では、スパイラル的アプローチを取り入れるケースもあります。

ただし、本格的な全面採用には至っていないのが実情です。今後はより簡便な形でスパイラル的実践を取り入れられないか、モデルのさらなる改良が求められるかもしれません。

米国におけるスパイラルモデルの採用状況は以下のようになっています。

スパイラルモデルは1980年代後半に提唱された比較的新しいモデルですが、当初から一定の支持を得てきました。特に以下の分野で採用事例が見られます。

• 国防総省の武器システム開発
• NASA等の宇宙開発プロジェクト
• 大規模ソフトウェアプロジェクト(金融、製造業など)

しかしながら、近年はアジャイル手法の台頭が著しく、スパイラルモデルの立場は必ずしも有利とは言えない状況にあります。

アジャイル系のスクラム、カンバン、リーンなどが、特に商用ソフトウェア開発で主流になってきているためです。理由として以下が挙げられます。

• アジャイル手法の方が軽量で柔軟性が高い
• スパイラルモデルではリスク分析やプロトタイピングにコストがかかる
• アジャイルがスピード感のある反復開発に適している

一方で、スパイラルとアジャイルを上手く組み合わせるハイブリッド型のアプローチも一部で見られます。特に大規模で複雑なシステム開発では、全体をスパイラルで制御しつつ、個々の反復開発はアジャイルで行うなどの実践があります。

つまり、純粋なスパイラルモデル採用の比率は必ずしも高くはありませんが、スパイラル的な概念や要素を取り入れるケースは一定数あると言えるでしょう。今後もスパイラルとアジャイルの融合が一つの潮流になっていくと予想されます。

スパイラルモデル自体が完全に消えていく可能性は低いと考えられますが、今後広く普及していくかどうかは定かではありません。

【日本】 日本ではこれまであまり広く採用されてこなかったスパイラルモデルですが、今後一定の広がりを見せる可能性はあります。

• アジャイルとの融合で、スパイラル的概念を取り入れるハイブリッド型モデルが増える可能性
• 大規模で複雑なシステム開発において、リスク管理の側面からスパイラル的アプローチのニーズが高まる可能性

ただし、ウォーターフォールが根強い上、近年ではDevOps的ナレッジなど、より軽量なアジャイルプラクティスの方が注目を集めている側面もあります。

【米国】 米国ではスパイラルモデルの発祥の地でもあり、一定の採用実績はあるものの、アジャイル手法の浸透が著しい状況です。

• 商用ソフトウェア開発ではアジャイル手法が主流になりつつある
• 大規模システムでもアジャイルを核とした新しいモデルへの移行が加速する可能性

ただし、国防総省などの特定分野では、リスク管理の観点から引き続きスパイラル的アプローチが重視される公算が高いです。

総じて、スパイラルモデル自体が完全に消え去ることはないと考えられますが、純粋な形でのスパイラルモデル採用は限定的になり、アジャイル手法との融合や新しいハイブリッドモデルへと移行していく可能性が高そうです。リスクマネジメントの考え方自体は生き残るとみられますが、具体的なプラクティスが変容していく可能性は高いでしょう。