目次

１．はじめに

２．プロジェクト計画の不備がトラブルの原因

２－１．性能保証・品質保証の役割

２－２．性能保証・品質保証のポイント

２－３．マイルストンと線表の階層化

３．リスク顕在化時の影響の大きさと具体事例

３－１．実績のない製品・製品組み合わせの保証遅延リスク

３－１－１．【事例１：実績のない製品】品質保証不足が招いた非機能要件・異常系試験のバリエーション不足によるトラブル事例

３－１－２．【事例２：性能問題】官公庁系共通プラットフォームにおける動作条件不整合

３－２．【事例３：実績のある製品】ログイン負荷性能問題と計画不備によるボトルネック発生

４．おわりに

１.はじめに

第1回（大規模システム開発の特徴とマネジメントの難しさ）では、長期間にわたる大規模システム開発プロジェクトにおいて、多くの関係者との連携や外的・内的な変化に対応するため、計画の精緻化、進捗管理、リスク管理、情報共有、合意形成など高度なマネジメントが不可欠であることを紹介しました。第2回となる今回は、プロジェクト計画に潜むリスクとその顕在化による影響について、実際の事例を交えて紹介します。特に、性能保証・品質保証に関する検討不足は、リリース直前での重大なエラーや、サービス品質の劣化を招く要因となるため、計画段階でどう組み込むべきか、進捗管理の工夫によってどのようにトラブルを未然に防いでいくかを紹介します。

２.プロジェクト計画の不備がトラブルの原因

２－１．性能保証・品質保証の役割

皆さんは、プロジェクト計画の不備によるトラブルと聞いて、どのようなことを思い浮かべますか？ 中でも大規模開発では、性能保証・品質保証は計画段階から明確にしておくべき重要な検討事項です。これらが曖昧なまま進行すると、後工程での手戻りや故障発生につながり、プロジェクト全体の信頼性を損なう結果となります。大規模開発では、後工程でのトラブル発覚が試験中断や進捗遅延、コスト超過を招くため、各工程において段階的な保証を確実に行う必要があります。

●なぜ性能保証・品質保証が重要なのか

例えば、ある公共・行政系のシステムでは、多くの利用者が同時にアクセスするため、性能要件（レスポンス時間、同時接続数、処理能力など）を厳密に整理する必要があります。プロジェクト計画で性能保証のための具体的な検証計画や負荷試験のスケジュールが十分に考慮されていないと、実運用で性能不足が発覚し、サービス停止や応答遅延が発生するリスクが高まります。

性能保証に関する検討が不十分、かつ負荷試験の甘さと相まって、リリース直後に応答遅延が頻発するような場合、当初想定していた問い合わせ対応人数では対応しきれず、緊急対応が必要になり運用コストなどが膨れ上がることになります。更には、性能改善のための改修対応が発生し、インフラの再構成や再試験の実施など多くの対応が必要になり、プロジェクト計画は大幅な変更を余儀なくされます。仮に、性能検証不足が招く影響として、ピーク時に同時アクセス数が3,000件を超えることが予測されるシステムのケースを考えます。

※この計算例は、ピーク時に3,000件を超える同時アクセスが予測されるシステムで性能検証が不十分だった場合を想定しています。負荷条件が厳しいほど、インフラ再構成やアプリ調整、再試験といった追加対応が必要になります。以下は極端な例ですが、約300人日の追加工数が発生する可能性があります。計算式は、その追加工数をどの体制でどれくらいの期間で対応できるかを示すものであり、性能保証を計画段階で軽視すると、こうした対応が現実化するリスクが高まることを理解いただくための参考値です。

■例：リリースから1か月以内で性能に関する対応が必要

総工数

プロジェクト人数（性能チーム）

営業日数（月単位）

プロジェクト期間

再構築対応の工数内訳（※あくまで例です）

1.性能チーム8名で対応
　追加工数 ÷ チーム人数 ÷ 月の営業日数 ＝ 対応期間（月）
　300人日 ÷ 8名 ÷ 20日 ＝ 約1.9ヶ月（約2ヶ月掛かる）

2.1ヶ月で対応する計算
　追加工数 ÷（対応月数 × 月の営業日数） ＝ 必要なチーム人数
　300人日 ÷ (1か月 × 20日) = 約15人（1ヶ月で完了するには約15人規模の体制が必要）

上記は、計画段階での性能検証の不足が、いかに急ぎの対応と追加負荷を招くかを示す例ですが、プロジェクト全体でコストの増大やスケジュールの遅延を招くリスクが高まるか、お分かりいただけるかと思います。計画漏れを防ぐためには、まず性能要件を定量的に定義し、レスポンス時間や同時接続数、ピーク時処理能力などを明文化し、関係者間で合意形成を行うことが重要です。次に、負荷試験や性能検証のスケジュールを初期計画に組み込み、ピーク時を想定したシナリオ試験や一定期間内に処理できる取引件数やデータ量の確認を必須タスクとして設定します。さらに、第三者レビューをはじめ、品質保証部門による計画段階のチェック体制を整え、性能・品質観点での抜け漏れを防ぐ仕組みを導入することが効果的です。

２－２．性能保証・品質保証のポイント

●性能保証

・各工程で性能試験に関する保証内容を明確化し、確実に実施することで大きな手戻りを防止する。

・保証内容を段階的に詳細化し、具体的なプロセス・作業に落とし込む。

・WBS（Work Breakdown Structure）や線表作成時に性能検証タスクを明示し、必要体制を確保する。

●品質保証

・実績のない製品の機能確認、連携確認、性能確認を設計初期段階で早期に実施し、実現性を確認する。

・アプリケーションと外部製品（ミドルウェア（以下、MW）やプラットフォームなど）との連携を単体試験から計画に組み込み、結合試験でのトラブルを防止する。

・上記をWBSや線表作成時に考慮し、必要体制を検討・確保する。

２－３．マイルストンと線表の階層化

性能保証・品質保証でのマイルストンは、プロジェクトの重要な節目を示す指標であり、例えば「性能試験完了」「ユーザ受入試験開始」などの主要成果物の完了や工程移行の判断基準です。線表の階層化とは、WBSに基づき、WBSで分解した作業を基に、スケジュール（線表）を複数レベルに分けて管理することです。次のように、複数レベルに分けて管理することで、単純にタスクだけでなく、性能や品質に関わる検証項目も、より細かい単位で進捗を把握できるようになり、検証漏れや遅延の兆候を早期に発見することが可能です。

マイルストンや線表が粗いレベルでしか管理されていない場合、性能試験や品質検証などの重要タスクが見える化されないことにより、進捗遅延や検証漏れが発生することが考えられます。また、上位タスクだけを見ていると、下位タスクの遅れが全体に影響する兆候を早期に把握できません。この課題を防ぐためには、まずWBSを性能や品質観点で細分化することが重要です。例えば、性能試験を「計画作成」「試験準備」「試験実施」「結果確認」「結果分析」に分けることで、進捗を細かく管理し、漏れを防ぐことができます。次に、線表を階層化し、上位・中位・下位工程の関連を明確化することで、遅延の影響範囲を見える化し、早期対応が可能になります。さらに、マイルストンに品質ゲートを設定することも有効です。「性能試験完了」「受入試験開始」など、品質確認を通過しないと次工程に進めない仕組みを導入することで、品質リスクを抑制できます。

■各階層の内容と例（作業粒度）

上位階層

内容

例

■上記「各階層の内容と例（作業粒度）」をさらに細分化して管理した例

２－４．体制構築のポイント

２－１～２－３では、性能保証・品質保証の役割やマイルストンと線表の階層化について紹介しましたが、性能保証・品質保証を確実に実施するためには、計画段階から専属の推進体制（性能保証・品質保証を担う専門チーム）を構築することが不可欠です。それぞれのチームは、以下を行います。

1.保証計画の策定

性能保証・品質保証に関する計画を明確化し、各工程での保証内容を段階的に詳細化（上流工程では保証観点や主要な性能・品質要件を定義するレベル、下流工程では具体的な試験項目や手順レベルまで詳細化）

2.共通化による品質均一化

各プロセスや成果物の標準化を行い、作業品質のバラつきを防止

3.進捗状況の把握とマイルストン管理

保証タスクの進捗を定期的に確認し、遅延やリスクを早期に検知

特に性能保証では、工程ごとに保証すべき観点や条件を明確にし、計画時点で保証レベルを定義しておくことが重要です。これらをWBSや線表に反映し、必要体制を確保することで後工程での手戻りを防ぎます。

工程

保証内容の観点

主な確認項目

３.リスク顕在化時の影響の大きさと具体事例

３－１．実績のない製品・製品組み合わせに伴う保証遅延および性能問題のリスク

新規製品や初めて組み合わせるMWは、特にOSSを含む構成の場合、商用製品と異なりベンダーによる動作保証が限定的です。バージョンや設定によって挙動が変わることもあるため「この構成で安定動作する」という確証が得にくいのが実情です。さらに、故障発生時にベンダーサポートが受けられないケースもあるため、性能・品質保証の検証項目を自社で定義し、十分な事前検証を行う必要があるなど、保証の難易度が上がります。その難しさをイメージしていただくため、3件のトラブル事例を紹介します。

３－１－１．【事例1：実績のない製品】品質保証不足が招いた非機能要件・異常系試験のバリエーション不足によるトラブル事例

●トラブル内容
電子申請システムで、新製品で使用実績の無い通信MWを採用した際、非機能要件や異常系試験のバリエーションが十分に検討できておらず、特に通信制御の品質保証が不十分だったことが、後に重大なトラブルを引き起こしました。

●問題点
電子申請情報を他機関へ送信した際に届かないという事象が発生し、通信エラーがトラブルの原因でした。通信制御では、処理の種類や処理の優先度に応じて複数のキューを用意するのが一般的な構造ですが、制御パケット、再送要求パケット、再接続要求などの通信処理で使うキューが単一構造で設計されていたため、トラブル発生時に以下のような状況が発生しました。

　・双方の通信で受信確認（ACK）が正常に処理されず、再送要求が滞留

　・再接続要求と再送パケットが同一キューで競合し、処理順序が崩壊

　・双方が待ち状態に入り、デッドロック状態が発生

現場では、「通信が止まった」「システムが応答しない」という報告が相次ぎ、再起動を試みても復旧に時間が掛かる状況となりました。

●どうすれば防げるか

①非機能要件の明確化

通信制御の耐障害性、再送処理の優先度の制御、並列処理の要件を整理・明記し、設計レビューで漏れが無いかの確認を実施

②キュー設計の改善

構造の見直し（単一キュー構造を廃止など）、制御パケット、再送要求パケット・再接続要求を分離した複数キュー設計

③異常系試験の網羅性確保

通信断、再送による競合、再接続要求の同時発生など、発生しうるシナリオを洗出し、異常系試験として試験ケースに追加。また、実績の無い製品を採用する場合、想定外の問題が発生することも考えられるため、通常の異常系試験よりも試験範囲やシナリオを多く設定し、試験を実施

④非機能試験の早期実施

実績の無い製品の場合、把握しきれていない仕様や想定外のケースも発生する可能性があるため、SQLや処理性能確認を行う。また、レスポンスやスループットを確認するとともに、試験環境が整っていれば、本番想定に近しい状態で負荷試験を実施し、性能要件を満たすかの負荷試験を実施し、要件を満たすか検証

●強化策

①事前リスク評価の実施

スケジュールに余裕があれば、どのような問題が発生しそうかを事前に把握するため必要に応じてPoCを実施。PoCで発生した問題の傾向を分析し、試験内容の検討を実施

②設計段階での非機能要件の詳細化とレビュー強化

通信制御に関わる非機能要件（耐障害性、優先度制御、並列処理など）を詳細に定義し、詳細レビューで競合やデッドロックを防止する設計になっているかなどをチェック

③シナリオの拡充

新製品であり、実績がない場合は通信トラブルや競合状態を想定した異常系試験ケースを網羅的に作成し実施。試験範囲を広げた多様なシナリオ検討

３－１－２．【事例2：性能問題】官公庁系共通プラットフォームにおける動作条件不整合

●トラブル内容
官公庁系共通プラットフォームの構築において、複数の製品が関係しており、動作条件の不整合が発生しました。具体的には、OSのバージョンやMWの組み合わせに起因し、一部の機能が要求仕様を満たさず、正常に動作しない事象が発生。一部サービスで通信エラーや処理遅延が頻発し、業務に支障をきたしました。

●問題点
①動作条件に関する情報不足

製品の動作条件の不整合により、全体の整合性を把握できていない

②検証計画の不十分さ

複数製品が関係することによる相互影響を考慮した検証計画が不十分で、リスクの早期発見が困難

③リスク残の対応遅れ

リスク残を検知した後も、検証開始が遅延

●どうすれば防げるか

①動作条件の明示化と対応範囲などの一覧化

製品ベンダーに対して、OSバージョン、MWの組み合わせなどに関する動作条件を明示的に確認し、各製品の対応範囲や制約事項を一覧化。一覧は、単なる仕様書の抜粋ではなく、実際の運用環境に即した構成での整合性を見切るために活用する

②ポイントを絞った検証

挙動差異や、特定条件下での通信安定性など、リスクが顕在化する可能性のあるポイントに絞って重点的に検証を行い、動作条件の整合性を確保し、リリース後のトラブル発生リスクを最小限に抑える

●強化策

①構成情報の一元管理

共通プラットフォームの構成情報を一元管理し、バージョンや設定の変更履歴を追跡可能にする

②早期の実施

本番想定の構成で、複数製品の組み合わせによる負荷試験・異常系試験を早期に実施する

③連携の強化

製品ベンダーとの連携を強化し、サポート範囲を明確化し、トラブル発生時の対応フローを事前に定義

３－２．実績のある製品、製品組み合わせに伴う保証遅延および性能問題のリスク

３－２－１．【事例3：実績のある製品】ログイン負荷性能問題と計画不備によるボトルネック発生

●トラブル内容
実績のある製品を採用していても、計画が不十分である場合、リスクが顕在化します。ある全国規模のシステムでは、サービス開始初日に全国拠点の事務所職員による同時ログインアクセスが集中し、システムが利用できないという大問題が発生しました。本番相当の同時ログイン数による認証サーバやセッション管理サーバへの負荷検証が不十分だったため、同時ログイン時に処理が集中し、認証処理が遅延するボトルネックとなりました。

●問題点
①負荷試験計画の不備

APサーバやDBサーバなどの主要サーバへの負荷検証は、想定内容を事前に整理し試験を実施していたものの、整理観点が不足しており、認証サーバやセッション管理サーバへの負荷を十分に検証しきれていない

②性能保証の観点不足

タイミングとアクセス数など、どれくらいの負荷が掛かるのかという観点の整理が不十分であり、実運用に近しいシナリオが洗い出し切れていない

③試験実施拠点やアクターの偏り

総合試験の前半では、アクターや拠点を絞り一部のユーザからアクセスのみを検証し、後半で初めて全国拠点からの同時アクセスを実施。全国拠点から一斉にログイン要求が集中した際、一部が処理しきれず、負荷が偏り性能の限界を超え、アクセスできなくなる、もしくはアクセスできてもシステム全体の応答が極端に遅くなる、というボトルネックが発生した

●どうすれば防げるか

①事前の負荷整理

各サーバに対して、アクセス集中を整理し、ピーク時がいつでどれくらいなのかを事前に整理する

②認証処理性能の確認

認証処理の応答時間やスループットを測定し、性能要件を満たしているか確認する。特に、同時ログイン要求が増えた場合の処理能力を検証し、ボトルネックとなる可能性のあるモジュールを早期に特定

③全国規模の同時アクセスを再現

事前に環境準備ができる場合は、実運用を想定した全国拠点からの同時アクセスを模擬し、ピーク時の負荷を再現する。認証サーバやLBなどの負荷分散が適切に機能するかを確認し、総合試験段階であらためて、ユーザに全国必要に応じて冗長化やスケールアウト計画を適用する

●強化策

①ピーク時のシナリオの必須化

月末・月初や業務開始が集中する時間、処理が集中する時間など負荷集中が予測されるタイミングや負荷対応が必要となる処理系の洗い出しを事前に整理し、そのタイミングと同等の時間に実施する

②負荷試験の段階的拡張と継続的モニタリング

総合試験前に、段階的に負荷を増加させる試験を複数回実施し、各段階で認証処理やセッション管理の応答性能を確認する。また、試験中にリアルタイムで負荷状況をモニタリングし、ボトルネックの兆候を早期に検知・改善する仕組みを導入することで、実運用に近い安定性を確保する

４.おわりに

今回は、プロジェクト計画の不備が引き起こすトラブルの具体例と、それに伴うリスク顕在化時の影響について紹介しました。性能保証や品質保証の検討不足は、リリース直前や運用開始後といった大事な時期に重大な問題を招くだけでなく、対応に多大な工数とコストを要します。

こうした状況を防ぐために、プロジェクトの計画段階から性能・品質に関するリスクを明確にし、検証計画を具体的かつ実践的に策定することが大切です。

次回の第3回では、進捗管理や多方面での外部インターフェース先との調整方法や工夫、気を付けるべき点について具体例を交えながら紹介します。