ソフトウェア工学シリーズの第5回目だよ。

ソフトウェアプロジェクトの成功率がすごく低い理由は、プロジェクト管理の能力が弱いからかもしれない。ソフトウェアならではの特殊性や複雑さを考慮して、プロジェクト管理の考え方をソフトウェア工学の分野に取り入れたのが「ソフトウェアプロジェクト管理」なんだ。

ソフトウェアプロジェクト管理の範囲

効果的なソフトウェアプロジェクト管理は、4つの「P」に集中するよ。つまり、人員 (Person)、製品 (Product)、プロセス (Procedure)、そしてプロジェクト (Project) だね。

ソフトウェアプロジェクトの見積もり

ソフトウェアプロジェクトの見積もりには、人、技術、環境などいろんな要素が絡んでくる。だから、見積もりをサポートするための方法や技術が必要なんだ。よく使われる見積もり方法は次の3つだよ。

1. すでに完了した類似プロジェクトをもとに見積もる
2. 分解技術を使って見積もる
3. 経験則に基づいた見積もりモデルを使う。代表的なものには IBM モデル、CoCoMo モデル、Putnam モデルがあるよ

これらの方法は、見積もりの精度を上げるために組み合わせて使うこともあるんだ。

COCOMO 見積もりモデル

COCOMO モデルは、正確で使いやすいコスト見積もりモデルだよ。詳細度によって、基本 COCOMO モデル、中間 COCOMO モデル、詳細 COCOMO モデルの3つに分けられるんだ。

基本 COCOMO モデル

基本 COCOMO モデルは、システム全体をひとまとめに見積もる静的な単一変数モデルだよ。

式はこんな感じ：

ここで、E は工数（人月）、D は開発期間（月）、L はソースコードの行数（千行単位、コメントやドキュメントは含まない）、a、b、c、d は定数だよ。

基本モデルでは、コード行数 L を見積もることで、開発工数と期間を計算できるんだ。

中間 COCOMO モデル

中間 COCOMO モデルは静的な多変数モデルで、ソフトウェアシステムをシステムとコンポーネントの2つの階層に分けるんだ。ソフトウェア開発に必要な人員（コスト）を、プログラムの規模と一連の「コスト駆動属性」の関数として捉えるよ。

中間モデルは基本モデルをベースに、15種類の工数に影響する要因を考慮しているんだ。工数調整係数 (EAF) を使って見積もりを修正することで、より合理的な数値を出せるようになっているよ。

式はこれ：

L は目的のコード行数（千行単位）、a と b は定数だよ。

詳細 COCOMO モデル

これはシステム、サブシステム、モジュールの3階層に分けるモデルだよ。中間モデルの要因に加えて、要件分析やソフトウェア設計といった各工程におけるコスト駆動属性の影響も考慮するんだ。

COCOMOII モデル

最初の COCOMO モデルは業界で広く使われてきたけど、今はもっと包括的な「COCOMOII」へと進化しているよ。これも階層構造になっていて、3つの段階別モデルがあるんだ。

1. アプリケーション合成モデル：プロジェクトの初期段階で使う。UIのプロトタイプ開発や、システム間のやり取り、性能評価、技術の成熟度が重要な時期だね。
2. 初期設計段階モデル：要件が固まって、基本的なアーキテクチャができた段階で使うよ。
3. アーキテクチャ段階モデル：実際にソフトウェアを構築している最中に使うんだ。

他のモデルと同じく、COCOMOII も規模の見積もりが必要だけど、オブジェクト点、機能点、コード行数の3つの選択肢があるよ。アプリケーション合成モデルではオブジェクト点、初期設計では機能点（コード行数に変換可能）を使うのが一般的だね。

進捗管理

進捗管理の目的は、ソフトウェアプロジェクトを決められた期限内に終わらせることだよ。

進捗管理の基本原則

1. 分割
2. 相互依存性
3. 時間配分
4. 工数の確認
5. 責任の確定
6. 出力結果の明確化
7. マイルストーンの設定

スケジュール作成

スケジュールを立てる時によく使われる図には、ガントチャート (Gantt Chart) と PERT 図 (Program Evaluation & Review Technique) があるよ。

ガントチャート

ガントチャートはシンプルな水平の棒グラフで、カレンダーを基準にタスクを表示するんだ。横軸が時間（日、週、月など）で、縦軸にタスク名が並ぶよ。棒の長さがタスクの期間を表していて、同じ時間帯に複数の棒があれば、それは並行して作業していることを意味するんだ。

ガントチャートは、いつ始まっていつ終わるか、進み具合はどうか、並行作業があるかどうかがひと目で分かるのがメリット。ただ、タスク同士の依存関係が見えにくかったり、クリティカルパス（プロジェクト全体の鍵となる部分）が分かりにくかったりするのが弱点かな。

PERT 図

PERT 図は有向グラフで、矢印がタスクを表すよ。矢印にはタスク完了に必要な時間を書き込むことができるんだ。結節点（ノード）はタスクの終了や開始を表す「イベント」と呼ばれるよ。そのノードに入るすべてのタスクが終わらないと、次のタスクは始められないんだ。イベント自体は時間もリソースも消費しない、単なる「時点」を指すよ。

各イベントには番号があり、そのイベントの「最早時刻」と「最遅時刻」が設定されるんだ。最早時刻より前には次のタスクは始められないし、最遅時刻までに始めないとプロジェクト全体が遅れちゃう。また、各タスクには「バッファ時間（スラックタイム）」があって、工期に影響を与えずにどれくらい遅らせられるかが分かるようになっているよ。

PERT 図は、タスク間の関係やクリティカルパスを見つけるのに役立つけど、並行関係を直感的に把握するのはちょっと苦手なんだ。

ソフトウェア構成管理

ソフトウェア構成管理（SCM）の主な目標は、変更の識別、変更制御、バージョン管理、変更が正しく実装されたかの確認、そして変更の報告だよ。

内容としては、バージョン管理、構成サポート、変更サポート、プロセスサポート、チームサポート、変更報告、監査サポートなんかが含まれる。

また、構成データベースは次の3つに分類されるよ：

1. 開発ライブラリ：開発者が使う用。頻繁に変更されるし、管理もゆるめ。
2. 受控ライブラリ（管理ライブラリ）：ある段階が終わった時にリリースされる成果物を入れる場所。これがいわゆる「ソフトウェア構成ライブラリ」で、しっかり管理されるよ。
3. 製品ライブラリ：テストが終わって、最終製品としてユーザーに渡す準備ができたものを入れる場所。

リスク管理

ソフトウェアのリスクには「不確実性」と「損失」という2つの特徴があると考えられているよ。不確実性は起こるかどうかわからないこと、損失はもし起こったらひどい結果になること。リスク分析では、この不確実さと損失の度合いを数値化することが大事なんだ。

プロジェクトリスクは、プロジェクト計画を脅かすもの。予算、スケジュール、人員、リソース、要件などの潜在的な問題だね。

技術リスクは、ソフトウェアの品質や納期を脅かすもの。設計、実装、インターフェース、保守などの問題だよ。技術が難しすぎたり、新しすぎたりする場合に起こりやすいんだ。

ビジネスリスクは、ソフトウェアの生存能力を脅かすもの。主に次の5つがあるよ：

1. 市場リスク：誰も欲しがらない良いものを作っちゃう。
2. 戦略リスク：会社の戦略に合わなくなる。
3. 販売リスク：営業が売り方を知らない。
4. 管理リスク：上層部のサポートが得られなくなる。
5. 予算リスク：お金や人が確保できなくなる。

(一) リスク識別

リスク識別は、計画に対する脅威をシステム的に見つけ出す作業だよ。既知のリスクや予測可能なリスクを見つけたら、まずは回避し、無理ならコントロールすることを考えるんだ。

一つの方法は「リスク項目チェックリスト」を作ること。次のような項目を確認するよ。

• 製品規模
• ビジネスへの影響
• 顧客の特性
• プロセスの定義度
• 開発環境
• 開発技術
• 人員の能力と経験

リスクの要因としては、性能、コスト、サポート、スケジュールなどが挙げられるね。

(二) リスク予測

リスク予測（見積もり）では、「発生する確率」と「発生した時の影響」の2点から評価するよ。

(1) 予測のステップ

1. 発生確率の尺度を決める
2. 起こる結果を記述する
3. プロジェクトや製品への影響を見積もる
4. 誤解がないように、予測の精度を明記する

簡単な方法として「リスク表」を作るのがいいよ。リスクの種類、確率、影響度（1：破滅的 〜 4：無視できる）を並べるんだ。

(2) 影響の評価

影響を決めるのは、リスクの本質、範囲、時間だよ。 全体の「リスク露出度 (Risk Exposure, RE)」は、次の式で計算できるんだ。

P は確率、C はコスト（影響）だね。

(三) リスク評価

リスク評価では、(Ri, li, xi) という三元組を作るよ（リスク、確率、影響）。 大事なのは「リスク参照水準」を決めること。コストオーバー、スケジュールの遅れ、性能低下のどれかが一定のラインを超えたら「プロジェクト中止」となるような基準を持つことだね。

(四) リスクコントロール

リスクコントロールは、リスクに対処する戦略を立てること。

(1) リスク回避

一番いいのは、起こる前に原因を分析して対策することだよ。 例えば「激しい人員流動」というリスクがあるなら、労働条件を改善したり、誰かが辞めても仕事が止まらないように情報を共有したり、バックアップの担当を決めたりする戦略が考えられるね。

(2) リスク監視

リスクが高まっていないか、常にチェックすること。チームの雰囲気や、メンバー同士の関係、報酬への不満などを見ておくんだ。

(3) RMMM 計画

これらをまとめたのが「リスク緩和・監視・管理計画 (RMMM 計画)」だよ。 プロジェクトが始まったら、この計画に沿ってリスクを追いかける。リスクが実際に起きたか確認し、対策が正しく行われているかをチェックして、将来のためにデータを集めるんだ。

何か問題が起きた時、複数のリスクが絡んでいることも多いから、「どのリスクが原因でこの問題が起きたのか」を突き止めるのも大事な仕事だよ。