Zenn
🎃

【論文】「ソフトウェアの開発モデルおよびソフトウェア開発プロジェクト失敗の分析」を読んでみた

に公開
システム開発
開発手法
開発プロセス
失敗
idea

はじめに

書籍「ドメイン駆動設計をはじめよう」の冒頭で登場した論文を読んでみました。

Software Process Models and Analysis on Failure of Software Development Projects
（ソフトウェアの開発モデルおよびソフトウェア開発プロジェクト失敗の分析）
Rupinder Kaur, Dr. Jyotsna Sengupta, 2011

「ドメイン駆動設計をはじめよう」ではこの論文をもとに、ソフトウェアプロジェクトの7割は失敗しており、その原因の1つはコミュニケーションであると紹介されていました。

今回の要約では、なるべく情報量を落とさず、わかりにくい部分は意識して補足を加えています。また、私はプログラマーであり、普段は論文を読む機会は少ないです。そのような読者向けに、意図的に内容の構造を変更しています。

早速読んでみましょう！

論文

要約

  • ソフトウェアプロセスモデル
    • ソフトウェアシステムの設計、開発、保守のために行われる一連の活動を指す
    • さまざまなソフトウェアプロセスモデルが考案させれており、ソフトウェア開発プロセスの構造化、記述、規定を目的としている
    • ソフトウェア開発において非常に重要な役割を果たし、ソフトウェア製品の中核を形成する
  • ソフトウェアプロジェクトの失敗
    • 多くの場合、組織にとって壊滅的な打撃となる
    • ソフトウェアプロジェクトの失敗とは、具体的にはスケジュールの遅れ、バグのあるリリース、不足している機能などを指す
  • 本稿が目指すところ
    • 現在のソフトウェアプロセスモデルについて論じる
    • ソフトウェア開発の失敗の分析を行う
    • 新たな研究の必要性を示す

1 序論

  • ソフトウェア開発モデル
    • ソフトウェアがどのような状態を経て成長していくかを示すもの
    • ライフサイクルは、製品が構築され、ソフトウェアが運用を開始し、最終的に廃止されるまでの各状態を定義する
    • 具体的には、ウォーターフォールモデル、V字モデル、アジャイル開発など
  • ソフトウェアプロセスモデル
    • ソフトウェアプロセスのアーキテクチャ、設計、または定義を抽象的に表現したもの
    • 目的は、コスト、時間、品質、顧客の要求変化など、さまざまな懸念事項を管理すること
  • 現状の課題感
    • ソフトウェア開発モデルの多くは、ソフトウェア工学の文献で体系的にまとめられている
    • ソフトウェアプロセスモデルのうち、大規模開発における開発プロセス中の絶え間ない要求変更は、依然としてプロセスモデルで十分に管理されていない
      • その結果、機能性、コスト、納期の面で期待に沿わないソフトウェアプロジェクトが発生している
  • 代表的なプロジェクトの失敗要因
    • 最も一般的な失敗理由
      • プロジェクトマネジメントプロセス自体
      • 組織文化とITの整合性
    • プロジェクト失敗の主要因
      • 見積もりの誤り
      • プロジェクト目標や目的の不明確さ
      • プロジェクト遂行中の要求変更
  • 本論文の残りの構成
    • 第2章：既存のモデルと手法について論じる
    • 第3章：ソフトウェア開発失敗の分析し、この分野における新たな研究の必要性を示す
    • 第4章：結論を述べる

2 背景研究

  • ソフトウェア開発モデルの開発
    • ソフトウェアシステムの開発および保守には、高度に相互連関したさまざまな活動が含まれる
    • これらの構造化された活動群を管理するために、多様なモデルが開発されてきたが、その成功度はさまざまである
      • ウォーターフォールモデル、イテレーティブ開発、プロトタイピング、スパイラルモデル、RAD（Rapid Application Development）など
  • プロジェクトの多様さと開発モデルの適合性
    • 各製品は、プロジェクトごとの特定の状況に応じて異なる状態を経るため、開発モデルは多様である
    • たとえば、問題が十分に定義・理解されており、ユーザーの要求がほとんど変化しない場合
      • 短いウォーターフォール型ライフサイクルで十分なことが多い
    • たとえば、問題が不十分に定義・理解され、ユーザーの要求が非常に変動しやすい場合
      • スパイラルモデルのような、より長く複雑なライフサイクルを選択せざるを得ない
  • ソフトウェア開発モデルの紹介
    • スパイラルモデル
      • 各サイクルでは、さらに詳細なレベルでソフトウェア製品の開発が扱われる
      • Win–WinスパイラルモデルやWin–Winステークホルダーアプローチがある
    • プロトタイピングモデル
      • 不確かな要求を理解するのに役立つ
      • 誤った期待を生み、システム設計が不十分になる可能性がある
    • RAD（Rapid Application Development）
      • プロトタイピングモデルのバリエーションの一つ
      • 各開発フェーズに厳格な時間制限を設け、迅速な開発を可能にするツールに大きく依存する
    • 探索的モデル（Exploratory model）
      • 要求収集技法としてプロトタイピングを利用し、構築は非常にシンプル
      • 高水準言語による高速開発に限界がある
      • システムや製品の詳細な要件が事前にほとんど知られていない状況で最もうまく機能し、大半が経験則に基づいている
      • コスト効率が高いとは言えず、最適とは言い難いシステムを生むこともある
      • 他に実行可能な代替手段がない場合にのみ使用すべき
    • アジャイルプロセスモデル
      • 分析や設計への比重が低く、実装はかなり早い段階から始まる
      • 時間枠を固定することが求められる
    • Extreme Programming（XP）
      • 複数の短い開発サイクルを採用することで変更コストを削減しようとする
      • 12人以下のチームでしか効果を発揮しない
    • Industrial Extreme Programming（IXP）
      • XPの進化版として導入された
      • 大規模かつ分散したチームでの開発を可能にし、柔軟な価値観をサポートすることが目的
      • その実用性を証明する十分なデータはまだない
    • コンポーネントベース開発（CBD）モデル
      • スパイラルモデルの多くの特徴を取り入れた進化的モデル
      • ソフトウェア作成に反復的アプローチを要求する
    • 統一ソフトウェア開発プロセス（Unified Process）
      • CBDモデルを代表する開発プロセス
      • 反復的かつ漸進的な開発を組み合わせ、シナリオベースのアプローチでシステムの機能を定義する
      • オブジェクト指向開発に重点を置いている
  • ソフトウェア開発プロセスモデルの進化
    • 顧客ニーズの変化を反映してきた
      • 顧客がより迅速な成果や開発プロセスへの関与、リスク・有効性を測定する手法の導入を求めてきた
    • 要件を確定する前にドメインを理解しなければならない
      • Dines Bjørnerによれば、ドメインを理解せずにソフトウェアを開発することは不可能
    • システム開発環境が急速かつ多岐にわたって変化した結果、以下が同時に進んだ
      • より実践的な新しいプロセスモデルの登場
      • もはや有用ではない古いモデルの淘汰

3 ソフトウェア開発における失敗の分析

  • ソフトウェアプロジェクトの失敗
    • 成功の基準を満たさないときに失敗する
    • 多くのITプロジェクトは、予算オーバーになるか途中で打ち切られ、完了したとしてもユーザーの期待やビジネスパフォーマンス目標を大きく下回ることが少なくない

ソフトウェア製品の失敗に関するレポート

ここでは、Dan Galorath が取り上げたソフトウェア製品失敗に関する各種レポートを概観する。

Standish "Chaos" レポート

年 成功 失敗 問題あり
1994年 16% 31% 53%
1996年 27% 40% 33%
1998年 26% 28% 46%
2000年 28% 23% 49%
2002年 34% 15% 51%
2004年 29% 18% 53%
2009年 32% 24% 44%

TCS（Tata Consultancy Services）調査（2007年）

  • スケジュールを守れなかった組織：62%
  • 予算超過を経験した組織：49%
  • 想定以上の保守コストが発生した組織：47%
  • 期待されたビジネス価値やROIを提供できなかった組織：41%
  • 期待性能を発揮できなかった組織：33%

Avanadeリサーチレポート（2007年）

  • 66%がシステム仕様の問題による失敗
  • 51%が要件理解不足による失敗
  • 49%が技術選定の問題による失敗

ESSU（European Service Strategy Unit）調査（2007年）

  • 57%の契約でコスト超過を経験
  • 33%の契約で大幅な遅延発生
  • 30%の契約が途中で打ち切り
  • 戦略的サービス提供パートナーシップの12.5%が失敗

KPMGサーベイ（2008年）

  • 平均すると、IT関連プロジェクトの約70%が目的を達成できていない

Bob Lawhornプレゼンテーション（2010年3月）より

  • 業務とIT間のミスコミュニケーションによる要件定義不足が、プロジェクト失敗率66%を招き、米国企業に毎年少なくとも300億ドルの損失をもたらしている（Forrester Research）
  • 60%～80%の失敗は要件定義、分析、管理の不備が直接の原因（Meta Group）
  • 50%が本番リリース後にロールバック（Gartner）
  • 40%の問題はエンドユーザーによって発見（Gartner）
  • プロジェクト総費用の25%～40%が手戻り工数によって無駄に（カーネギーメロン大学）
  • 予算の最大80%が自ら招いた問題の修正に消費（Dynamic Markets Limited 2007年調査）

「成功」するプロジェクトはごくわずかである。

  • プロジェクト成功の三大要因
    • 「納期どおりに納品」
    • 「予算内（または予算以下）で実施」
    • 「システムが要件どおりに動作」

しかし、本当に成功の鍵はこの三つだけで測れるのだろうか？
失敗には単一の要因ではなく複数の要因が絡み合っている。以下に、失敗の最も重要な原因を示す。

3.1 要件の抽出

  • 要件の抽出
    • 望ましいソフトウェア製品の要件を抽出することは、それを開発する上での最初のタスク
    • プロジェクトの初期段階で要件収集が不十分だと、プロジェクトの目的が部分的にしか明確にならないことがある
  • よくある失敗
    • 上位レベルであいまいかつ実用性に乏しい要件しか提示されない
    • その結果、開発者は自分たちが必要だと考えるものを作ってしまう
      • 開発者がユーザーからの具体的なインプットを得られない状態
      • 開発者が開発対象のビジネス内容を十分に理解していない状態
    • そして、システムを納品した時点でユーザーから「必要としていた機能が実現されていない」と評価されることが常である
  • ステークホルダー自身の要求の不明確性
    • プロジェクトスポンサー自身が、何を本当に求めているのか説明する経験を持たないために、目標や目的が不明瞭になることもある
    • ユーザー自身はITの専門家でないため、自分たちがプロジェクトに何を求めているかを理解し、それをはっきりと仕様化できることは少ない
  • 開発者の要件の抽出の役割
    • 開発者はソフトウェア工学の知識や経験を駆使して、ユーザーの要件を引き出さなければならない

3.2 ユーザー関与の欠如

  • ITプロジェクトを管理する上での主な困難
    • 経営層の支援不足
    • ユーザー関与の欠如
  • ユーザー関与の必要性
    • ユーザー関与の欠如が、多くのプロジェクトにとって致命的であることが明らかになっている
    • ユーザーが関与しない場合、社内の誰もシステムに対してコミットメントを持てない
      • むしろ社内の人間がシステムに対して敵対的になることさえある
    • ソフトウェアプロジェクトの成功基準の一つは、プロジェクト開始時から開発を通じて継続的にユーザーが関与しているかどうかにかかっている
  • ユーザーの協力
    • ユーザー関与はユーザー側の負担が大きく、しばしば行われない
      • 時間と労力を要する
      • 彼らにとって新規プロジェクトに割く時間は優先度が低い
    • 開発者はユーザーを積極的に巻き込まなければならない
      • ユーザーはプロジェクトを継続的に支援する必要がある

3.3 チームサイズ

  • チームサイズの重要性
    • ソフトウェア開発プロジェクトにおいて、適切なチームサイズは不可欠
  • 3つのチームサイズ
    • 小規模プロジェクト：10人以下の小規模チーム
    • 中規模プロジェクト：11～25人の中規模チーム
    • 大規模プロジェクト：26人以上の大規模チーム
  • 小規模チーム
    • コミュニケーションが円滑になりやすく、非常に柔軟に対応できる傾向がある

3.4 時間軸（Time Dimension）

  • スケジュールの重要性
    • ソフトウェア開発においては、定められたスケジュール通りにプロジェクトを納品することが有益
  • タスクの時間
    • タスクの「作業時間」：割り込みを受けずに、完了するまでに要する時間
    • タスクの「所要時間」：割り込みを含めた、実際に完了するまでにかかる時間
  • よくある誤り
    • プロジェクトマネージャーがスケジュールを見積もる際に「作業時間」を用いること
  • プロジェクトの時間的スパン
    • 短くすることを推奨
    • プロジェクトの期間が長すぎると、プロジェクトは失敗し、組織から要求されなくなる

3.5 固定コントローラ（Fixed Controller）

  • 変化する要件
    • システム構築中に、環境制約やクライアントの要求は常に変化を続ける
    • 制御されていない変更は、開発中のシステムに大きな混乱をもたらし、多くのプロジェクトの失敗を招いてきた
  • コンポーネント駆動型アプローチ
    • システム全体を独立性の高い「コンポーネント（部品）」に分割し、それぞれを個別に設計・実装・テスト・再利用していく開発手法
    • 新しい要件や変更は、これらのコンポーネントが現在の開発プロセスに適合するまで、個別に対応で
    • 新しい要件の変更から目の前の開発対象を独立させるため、開発者はコンポーネント駆動型アプローチに従う必要がある

3.6 テスト

  • テストの主な目的
    • ソフトウェアの障害を検出し、欠陥を発見して修正できるようにすること
  • 受け入れテスト
    • 最終的にはユーザーが受け入れテストを実行し、システムがビジネス要件を満たしているかどうかを確認する必要がある
    • しばしば、受け入れテストで十分な障害を検出できないことがある
    • それには、以下の原因が考えられる
      • 計画外のテスト
      • テストの目的を理解していないユーザーのトレーニング不足
      • プロジェクトの遅延によるテスト実施時間の不足

3.7 品質管理の不備

  • 成果物の品質の維持
    • 品質を保つためには、定期的な品質評価と適切な予防・欠陥除去策が必須である
    • 欠陥除去活動の例としては、要件レビュー、設計レビュー、コードレビュー、各種テストなどがある

4 まとめ

  • 本論文では、さまざまなソフトウェアプロセスモデルを検討し、ソフトウェア開発プロジェクトにおける諸問題を分析する試みを行った
  • 各種レポートを取り上げ、ソフトウェア製品の失敗事例について論じた
    • プロジェクトは予算超過で進行したり、途中で中止されたりすることがあり、完了に至ったものもユーザーの期待やビジネス要件を大きく満たさない場合が少なくない
  • 本研究では、プロジェクト失敗の主因となるいくつかの重要な要素を取り上げて検討した
    • これらの要素だけが成功・失敗を決定づけるわけではないが、上位に挙げられる要因であることは間違いない
  • 本研究は、ソフトウェア開発における主要な課題を解決するための新たなアプローチやモデル、手法の開発の必要性を示した

おわりに

いかがでしょうか。4ページ分でサクッと読めるかなと思いきや、意外と2hほど時間がかかってしまいました。

本論文を「ソフトウェアプロジェクトの失敗の分析」という観点で見ると、以下が主要な内容になるのかなと感じます。

  • 万能な開発モデルはない
    • プロジェクトごとに特性が多様であるため、うまく適合する開発モデルを選定する必要がある
    • 特に大規模開発における開発プロセス中の絶え間ない要求変更は、依然としてプロセスモデルで十分に管理されていない
  • ソフトウェア製品の失敗に関するレポート
    • ソフトウェア開発プロジェクトの3割しか成功しない
    • 残りの7割は失敗している
  • 代表的なプロジェクトの失敗要因
    • 最も一般的な失敗理由
      • プロジェクトマネジメントプロセス自体
      • 組織文化とITの整合性
    • プロジェクト失敗の主要因
      • 見積もりの誤り
      • プロジェクト目標や目的の不明確さ
      • プロジェクト遂行中の要求変更
  • 本論文で挙げた失敗の最も重要な原因
    • 要件の抽出
    • ユーザー関与の欠如
    • チームサイズ
    • 時間軸
    • 固定コントローラ（要求変更からの守護・対応）
    • テスト
    • 品質管理の不備

個人的には、以下を肝に銘じて開発したいなと感じました。

  • ドメインを理解しないと、ソフトウェア開発は不可能
  • ユーザーの要求を理解し、その要求の変化に対応する

ソフトウェア開発プロジェクトの3割しか成功しない

こちらがなかなかに絶望的な数字ですね。なぜ、こんなにもソフトウェア開発のプロジェクトは不安定なのでしょうか？

1つ目は、ソフトウェア開発の歴史の浅さがあると考えています。1940年台に初期のコンピュータが登場してから、まだ1世紀経っていません。ソフトウェアは時代やハードウェアとともに進化を続け、そのスピードは緩まっていないようにも感じます。このような中、単純に業界がまだまだ未成熟 (枯れていない) ということがあるのではないでしょうか。

2つ目は、ソフトウェアの自由度の高さがあると考えています。比較対象として、家の建築を考えてみます。家を建てたい人が建築士と相談し、マイホームを建てるとします。建築では、最初に図面を作成した後は施工するのみであり、再度設計に手戻りすることは少ないと理解しています。マイホーム建築の失敗率が7割もあるとは思えません。一方ソフトウェア開発では、大きなシステムほどウォーターフォールがうまく機能せず、実際にその経験がある方も少なくないと思います。では、ソフトウェア開発と建築では何が異なるのでしょうか？それは「解法の幅」ではないかと考えています。建築では、現実の物理法則に従う必要があります。例えば、吹き抜けにすれば剛性が下がり、柱の位置の自由度が下がります。つまり、あちらを立てればこちらが立たず、選択肢が思いのほか少ないのではないでしょうか。対してソフトウェア開発は、自由度が高いです。アーキテクチャレベルでは、どのようにコンポーネントを分けても、動作させることはできます。コードレベルでは、トランザクションスクリプトで書いても、モデルを活用して書いても、やはり単純に要求を満たすだけならソフトウェアの作成は可能でしょう。この自由度の違いが、ソフトウェア開発では最初に設計しても後から考慮漏れや設計不備が発覚する原因になるのではないか、と考えました。ここまで書いていて、いや単純に「解決する対象の複雑さ」の方があるかなと感じました🤔 家の建築では人が住み、生活できれば良いのですが、ソフトウェア開発では現実世界の多様な問題を対象にするためです。蛇足はここら辺にしておきたいと思います。

最後まで読んでいただき、ありがとうございました！

Discussion