トピック

概要 ページの先頭へ

ソフトウェア開発プロセスは下記の要因の影響を受けます。

  • 領域的な要因: アプリケーション領域、サポートするビジネス プロセス、ユーザー部門、競争相手から提供されるものなど
  • ライフサイクル的な要因: 発売時期、ソフトウェアの予想寿命と計画中の将来のリリースなど
  • 技術的な要因: プログラミング言語、開発ツール、データベース、コンポーネント フレームワーク、既存のソフトウェア システムなど
  • 組織的な要因

これらの要因の重要性には差があります。以降に主要な要素をいくつか説明します。これらは、開発ケースの全般的な形態に影響を与える可能性のある主要な要因および開発組織においてプロセスとツールを実装する方法です。

ビジネスの状況 ページの先頭へ

プロセスの構成方法に影響を与えるビジネス状況には何種類かのタイプがあります。ビジネス状況の例を下に示します。

  • 契約ベースの作業: 開発者は顧客から与えられた仕様に基づいて、その顧客のためだけに、ソフトウェアを開発します。
  • 見越し開発または商業的な開発: 開発者は自己の資金で市場に投入するソフトウェア生産します。
  • 内部プロジェクト: 顧客と開発者は同じ組織に属します。

中間的な状況がたくさんあります。その例として、ソフトウェア開発の一部だけが外注に出されること、地理的な分散が追加的な要因となることなどが挙げられます。明白な利害関係者の数はよい指標となります。

ビジネス状況は「儀式のレベル」、公式性のレベル、およびプロセスの硬直性に影響します。参加する利害関係者 (購買担当者、顧客、外注業者、規制団体など) の数が多ければ多いほど、主要なプロジェクト マイルストーンにおいて、プロジェクトで公式の証拠 (文書、報告書、プロトタイプなど) を作成する必要が高くなります。

ソフトウェア開発作業の規模 ページの先頭へ

ソフトウェア開発作業の規模はいろいろな尺度で表されます。その例として、プログラムのステップ数 (SLOC)、プログラム内の命令数、ファンクション ポイント、人月数、コストが挙げ られます。

プロジェクトの規模は「儀式のレベル」、公式さのレベル、およびプロセスの硬直性に影響します。プロジェクトの規模が大きければ大きいほど、開発チームが大きくなります。また、ビジネス状況が何であるかにかかわらず、種々のチームおよびマネジメントは要求、インターフェイス、および進捗状況について、高い公式性および可視性を必要とします。大規模なプロジェクトのコミュニケーションの問題はチームが地理的に分散することにより悪化します。

新規性の度合い ページの先頭へ

新規性の度合いは、該当のソフトウェア開発作業がどの程度「先例のあるもの」であるかであり、開発組織に相対的なものであり、特に開発が 2 番目以降のサイクルにあるかどうかということです。これには組織の成熟度とそのプロセス、資産、現在のスキル セット、およびチームの編成とトレーニング、ツールの確保、その他のリソースなどの問題が含まれます。

プロジェクトの新規性の度合いの影響は、状況によって非常に異なります。新しいプロジェクト (その類の中で最初のもの) は、動的な構成に大きく影響します。このために、方向付けフェーズおよび推敲フェーズが長期に及び、反復が数回にわたって行われる場合もあります。しかし、要求を聞き出して把握すること、ユース ケース モデリング、アーキテクチャ、およびリスクの緩和にも高い重点が置かれます。前のシステムの発展サイクルにあるプロジェクトでは、変更管理の方がさらに重要になります。そして、旧来のコードを組み込むことが技術的な難題となりま す。

新規性は開発中のシステムだけに関係するものではなく、既にシステムを稼働させている組織の成熟度にも関係します。新しい技術やツールを導入することによって、プロセスが影響を受けます。特に、RUP (Rational Unified Process) そのものを組織に導入する際は、注意深くステップを踏んで段階的に行う必要があります。組織にはなんらかの慣性が付いているので、新しいプロセスの導入に抵抗があります。開発に際しては、既存の慣行から新しいやり方へ円滑な移行を図るように検討する必要があります。

アプリケーションのタイプ ページの先頭へ

アプリケーションには種々のタイプがあります。たとえば、組み込みのリアルタイム システム、分散情報システム、テレコミュニケーション システム、CASE ツールなどです。アプリケーションのタイプはプロセスに影響します。特に、ドメインにおいて開発に課される特殊な制約に、それが顕著に現れます。その例として、安全性、性能、国際化、メモリの制約などが挙げられます。

アプリケーションのタイプによってプロセスが特に影響を受ける例として、航空機の飛行管制システムのような重大な使命を担うものがあります。そのようなシステムには一般に高いレベルの儀式が必要とされます。それは、要求を把握することと製品の品質を保証することの両方のためです。そのようなアプリケーションでは、テストにも多大のリソースを割く必要があります。

開発のタイプまたは目標とするドメインによって、プロセスに下記のような課題が持ち込まれます。

  • 特定の作業をサポートするための技法およびツール。たとえば、有限状態マシンのための自動的なコード生成が挙げられます。
  • 証明手続き。たとえば、医療機器に関して。
  • 標準への準拠。たとえば、会計または財政に関して、あるいはテレコミュニケーション機器に関して。

開発のタイプ ページの先頭へ

開発には、下記のようにさまざまなタイプのものがあります。

  • 契約ベースの作業: 特定の顧客のために製品を開発します。この場合、管理および交渉の対象となる利害関係者が多いのが普通です。公式性の高い外部的な成果物 の必要性もあります。顧客 (または代表者) は進捗を監視し状況を知らされていたいと願うからです。顧客にレビューされる成果物は理解しやすいものを作成します。ときには、マイルストーンを確立する必要があります。そうすれば、後続のプロジェクトのコストを固定できます。その場合、新しいマイルストーンを追加したり、既存のマイルストーンを調整したりする必要があるでしょう。場合によっては、顧客が使用しているライフサイクル モデルをほかのマイルストーンまたはフェーズで調整する必要があります。
  • 大衆市場向け製品開発での見越し開発。その場合、その組織内のマーケティング マネージャ (プロダクト マネージャと呼ばれることもあります) が顧客の役割を演じます。見越し開発の場合は発売までにかかる時間の方が機能よりも重要なことが多く、公式なレビューの必要性は少なくなります。
  • 内部開発: 社内の別の部門に納入する製品を開発します。RUP を使用していない別のプロジェクトに製品を納入する場合は、RUP 以外のライフサイクル モデルへの適応が必要になります。成果物を記述する際には、技術的な傾向が強くても受け入れられるでしょう。なぜならば、その成果物をレビューするのは同じ社員であるからです。
  • 予備調査: 予備調査では、製品を開発することは、通常はありません。予備調査の目的は、製品を開発することが可能であるかどうかを判定することです。この場合、通常のプロジェクトと同様のマイルストーンは必要ありません。

現在の開発プロセス ページの先頭へ

ほとんどの場合、組織内で現在実践されている、ソフトウェア開発プロセスを置き換えることはありません。その理由は、多くの場合、緊急性または重要性の高い領域に最初に焦点を当てて、新しい開発プロセスを段階的に導入していくからです。ほとんどの場合、現在のソフトウェア開発プロセスの一部は当分の間、残ります。あるいは永久に残るかもしれません。

問題と根本的な原因 ページの先頭へ

ソフトウェア開発組織を理解するための重要な様相の 1 つは、既存のソフトウェア開発プロセスにおける問題点を理解することです。このことは、プロセスの導入を開始するに当たって、プロセスのどの分野に集中するかということに影響します。確立された作業方法が組織内にない場合、問題を検出しても無意味だということを理解する必要があります。詳細は、「../workflow/environm/co_iproj.htm -- このハイパーリンクは、生成されたこの Web サイト内に存在しません概念: プロジェクトでのプロセスの実装」を参照してください。代わりに、問題の根本原因を認識する必要があります。問題を排除するには、そのプロセスを改善し、プロセスを自動化するツールを導入し、メンバーにトレーニングを受けさせることによって根本原因を追跡します。

典型的な問題の例

一般的な問題をいくつか、下に示します。

  • 範囲を適切に管理できない - 組織は最終的に自分達ができる以上のことを行おうと試みることがよくあります。
  • 要求を的確に把握できない - 要求を仕様としてまとめることが的確にできません。
  • 変更依頼を的確に管理できない
  • 要求を的確に管理できない - 要求が最終製品に反映されないことがあります。
  • 予測を的確にできない - スケジュールどおりに納品できると楽観しすぎることがよくあります。
  • 設計に欠陥がある - 要求にはよく応えていても、システム設計の点では劣っていることがあります。設計に関してどのような問題がありますか。システムの保守と拡張が困難ですか。性能、使用性、容量などの面で問題がありますか。
  • 品質の高い製品を産出できない - 製品に多くの障害がありすぎます。その原因はテストが不十分なことかもしれません。しかし、通常は、要求を的確に把握して管理する能力が不足していることや、設計に欠陥があることも、関係しています。
  • 許容範囲外のソフトウェアの性能
  • 低いユーザビリティ
  • 開発者間の衝突 - 所有権および構成管理に対しては管理が不十分なため、開発者どうしの間で同じものを変更してしまう可能性があり、その場合は作業が無駄になります。
  • 問題検出の遅れ
  • ユース ケースから設計への移行時のトラブル
根本原因の例

問題は、何かが間違っているという症状で現れることがよくあります。問題の根本原因を認識する必要があります。一般的な根本原因をいくつか、下に示します。

  • 要求管理が不十分
  • あいまいで不正確なコミュニケーション
  • 弱いアーキテクチャ
  • 複雑すぎる
  • 要求、設計、実装間における未検出の不整合
  • テストが不十分
  • プロジェクト ステータス評価書が主観的
  • ウォーターフォール式開発によるリスク低減の遅れ
  • 変更の伝達が制御されていない
  • 自動化が不十分
  • ユーザー インターフェイスを構築する体系的な方法がない
  • ユース ケースから設計に進む方法がない

組織的な要因 ページの先頭へ

組織内でプロセスを実装する方法は、組織的な要因に左右されます。そのような要因の例として、組織構造、プロジェクト組織およびマネージャの気風、利用可能な能力とスキル、以前の経験、態度が挙げられます。

プロセスを構成する方法も組織的な要因の影響を受けます。たとえば、組織内の人が以前にソフトウェア開発プロセス記述書を使用したことがあれば、RUP を使い始めることは容易です。逆に、以前にソフトウェア開発プロセス記述書を使用したことがなければ、プロセス記述書の範囲を限定するようにした方がよいでしょう。また、開発ケースを理解も使用もしやすくするために余分の労力をかけて、非常に価値のある RUP の部分と対応させることもできます。

多くの人にとって新しい分野がいくつかあるならば、作業しやすいように、可能な限り優れたガイドラインを用意します。たとえば、多くの人にとってプログラミング言語が新しいものであるならば、学習用に非常に優れたプログラミング ガイドラインと設計ガイドラインを用意するとよいでしょう。

態度 ページの先頭へ

新しい技術、新しいプロセス、および新しいツールに切り替えることに対する組織内の人々の否定的な態度は、おそらくそれらのプロセスやツールの導入に成功するためには、最大の障害となります。新しいプロセスに対する熱狂的すぎる期待も問題です。そのプロセスに人を注目させすぎてしまうからです。

新しい技術やプロセス、ツールに対する人の態度を測るには、次のような質問をします。

  • 新しい技術からどのような利益があると思いますか。新しい技術によって現在の問題を解決できますか。新しい技術に関して問題があるとすればそれは何ですか。
  • 新しいプロセスからどのような利益を得ることができますか。新しいプロセスによって現在の問題を解決できますか。新しいプロセスに関して問題があるとすればそれは何ですか。
  • 新しいツールからどのような利益があると思いますか。新しいツールによって現在の問題を解決できますか。新しいツールに関して問題があるとすればそれは何ですか。

人の動機付けを測るには、次のような質問をします。

  • 組織内のすべての人が変更を必要としているのはなぜですか。
  • 競合他社が何をしているか、またそれが自社のビジネスにどのような影響を与えるかをすべての人が知っていますか。
  • 業界における技術変革と、それが自社のビジネスにどのような影響を与えるかをすべての人が知っていますか。

否定的な態度のサインは、次のような答えに見ることができます。

  • 「そのプロセスは役に立つどころか、かえって邪魔だ。」
  • 「そのプロセスは文書をたくさん作成することを意味する。」
  • 「そのプロセスは仰々しい。」

否定的な態度に対処する方法を下に示します。

  • 今日の問題を指摘することによって、人々を動機づけします。
  • プロセスは人のすることを規制するものではないことを説明します。プロセスは主として、ガイドラインや定義などを参照できる「ヘルプ システム」としてみなされるようにすべきです。
  • プロセスのごく一部だけを使用することを説明します。誰もプロセス全体をマスターすることはできませんし、それは目的でもありません。プロセスを本の詰まった本棚にたとえます。つまり、必要なときに利用するものであることを示します。
  • パイロット プロジェクトを実施して成功させ、新しいツールおよびプロセスが役に立つことを示します。懐疑的な人を 1 ~ 2 人、パイロット プロジェクトに含めます。

熱狂的すぎる期待の兆候を下に示します。

  • 人はプロセスに完全に頼って、すべての問題が解決されると考えること
  • プロセスは特効薬つまり魔法の公式であって、それに従えば成功が保証されると受け取ること
  • プロジェクト チームが、解決する必要のあるプロセスに関連する問題を最初に評価しようとせずに、プロセスをカスタマイズすることに多大の時間と労力を注ぎ込もうとすること

熱狂的すぎる期待に対処する方法を下に示します。

  • 期待を設定します。プロセスは役に立つが、プロセスが問題を解決するのではなく、人が問題を解決することを示します。
  • プロセスをカスタマイズすることに多大の労力を注ぎ込まないように、人を説得しま す。
  • ソフトウェア製品を開発することに人を集中させます。

技術面および管理面の複雑さ ページの先頭へ

システムの技術的な複雑さおよび管理的な複雑さの観点から、種々のシステムとそのプロジェクトを分類できます。下のダイアグラムは種々のシステムを分類する方法の大まかな考えを示します。たとえば、通常の小規模なビジネス スプレッドシートのアプリケーションは一般に、技術的な複雑性が低く管理もしやすいと言えます。これとは対照的なのが、典型的な兵器システムのプロジェクトで、これは多くの場合、技術的にも管理的にも複雑です。

一般に、システムのサイズ、プロジェクトの期間、またはビジネス状況を増大すると、管理的な複雑性も増大します。問題領域または解決空間のどちらかの新規性が増大すると、技術的な複雑性が増大します。管理的な複雑性と技術的な複雑性の間に相関関係があります。大規模なプロジェクトの多くは技術的にも複雑です。結果的に、以下のことが言えます。

  • 管理的な複雑性が増大すると、儀式、公式なレビュー、マイルストーン、および成果物の増大につながります。
  • 技術的な複雑性が増大すると、特定の技術、役割、ツール、および作業の増大につながります。

技術的な複雑性および管理的な複雑性の観点からシステムを分類できます。



Rational Unified Process   2003.06.15