Ukaru.資格試験オンライン講座

開発技術とプロジェクトマネジメント・サービスマネジメント

ウォータフォール対アジャイル、ブラックボックス対ホワイトボックス、WBSとクリティカルパス、そしてインシデント管理(迅速復旧)と問題管理(根本原因究明)の対比の正確な区別が本章の得点の分かれ目である。

ソフトウェア開発は、要件定義、システム設計、プログラミング、テスト、ソフトウェア受入れ、運用・保守という一連のプロセスで進められる。IPAの公式シラバス「開発技術」分野および共通フレーム(SLCP-JCF2013、JIS X 0160)では、発注者と受注者の間で用語や作業範囲の認識を合わせるためにこのプロセス体系が定義されている。要件定義では利用者の要求を機能要件・非機能要件として明確化し、システム設計は利用者から見た仕様を決める外部設計(システム方式設計)と、開発者側の内部構造を決める内部設計(ソフトウェア詳細設計)に分けられる。テストは単体テスト、結合テスト、システムテスト、受入れテストの順に範囲を広げながら実施し、受入れテストは発注者(利用者)側が主体となって行う点が繰り返し出題される。運用開始後の機能改善や障害修正はソフトウェア保守に区分され、本試験では各工程の実施主体と順序を問う問題が頻出である。

開発モデルでは、ウォータフォールモデル、プロトタイピングモデル、スパイラルモデル、アジャイル開発が出題の中心である。ウォータフォールモデルは要件定義から順に工程を進め、原則として前工程に後戻りしないことを前提とする手法で、大規模開発の進捗管理がしやすい反面、仕様変更への対応が難しい。プロトタイピングモデルは試作品(プロトタイプ)を早期に作成して利用者の要求とのずれを防ぐ手法、スパイラルモデルはシステムをサブシステムに分割し、設計・開発・評価を繰り返しながら完成度を高める手法である。アジャイル開発は短い反復で動くソフトウェアを継続的に提供する手法の総称であり、代表的フレームワークのスクラムでは、スプリントと呼ばれる1〜4週間程度の固定期間の反復で開発を進める。XP(エクストリームプログラミング)のプラクティスであるペアプログラミング、リファクタリング、テスト駆動開発、および開発と運用が密接に連携するDevOpsもシラバス掲載用語として問われる。

テスト技法では、プログラムの内部構造に着目して命令や分岐の網羅性を確認するホワイトボックステストと、内部構造を考慮せず入力と出力の関係だけに着目するブラックボックステストの対比が最頻出である。ブラックボックステストのテストケース設計には、入力データを有効・無効のグループに分けて代表値を選ぶ同値分割と、グループの境界の値を用いる境界値分析が用いられる。また、プログラムの修正が他の部分に想定外の影響を与えていないことを確認する回帰テスト(リグレッションテスト)も定番論点である。開発規模・工数の見積り技法としては、画面数・帳票数・ファイル数などの機能量からシステム規模を見積もるファンクションポイント(FP)法が繰り返し出題されており、プログラム言語や開発者のスキルに依存せずに見積もれる点が特徴である。このほか、類似システムの過去の実績に基づいて見積もる類推見積り法も押さえておきたい。

プロジェクトマネジメントは、PMBOKガイドを事実上の国際標準の知識体系として、スコープ、スケジュール、コスト、品質、資源、コミュニケーション、リスク、調達、ステークホルダー、統合の各マネジメント領域に体系化されている。プロジェクトとは、定常業務と異なり独自の成果物を有期性のもとで生み出す活動である点がまず問われる。スコープマネジメントでは、成果物と作業を階層的に分解して管理可能な単位にするWBS(Work Breakdown Structure)が最重要用語である。スケジュール管理では、横軸に時間をとり作業の予定と実績を帯状に示すガントチャートと、作業の順序関係を矢線で表すアローダイアグラム(PERT図)が頻出で、所要日数が最長となる経路であるクリティカルパスを求める計算問題も出題される。リスクマネジメントでは、対応策をリスク回避、リスク軽減(低減)、リスク転嫁(移転)、リスク受容の4類型に整理し、保険への加入が転嫁に当たるといった具体例との対応付けが定番である。

サービスマネジメントは、ITサービスを安定的・継続的に提供するための管理活動であり、ベストプラクティス集であるITILと、サービスマネジメントシステムの要求事項を定めたJIS Q 20000(ISO/IEC 20000)がシラバス上の根拠である。サービス提供者と利用者が稼働率や障害復旧時間などのサービス品質の水準を数値で合意する文書がSLA(サービスレベル合意書)であり、SLAの達成状況を継続的に監視・報告・改善する活動がSLM(サービスレベル管理)である。プロセスの区別では、中断したサービスを可能な限り迅速に復旧させることを目的とするインシデント管理と、障害の根本原因を究明して恒久的対策を講じる問題管理の違いが最頻出のひっかけである。さらに、変更を評価・承認する変更管理、承認された変更を本番環境へ確実に展開するリリース及び展開管理、利用者からの問合せを一元的に受け付ける単一窓口(SPOC)であるサービスデスクの役割を整理しておく必要がある。

ファシリティマネジメントは、建物・電源・空調などの設備を維持・管理し最適化する活動であり、停電時に一定時間電力を供給してシステムを安全に停止させるUPS(無停電電源装置)、自家発電装置、サージ防護、免震・耐震設備などが問われる。システム監査は、経済産業省「システム監査基準」に基づき、情報システムのリスクに対するコントロールが適切に整備・運用されているかを、監査対象から独立した立場のシステム監査人が点検・評価・検証する活動である。監査人には外観上および精神上の独立性が求められ、監査計画の立案、監査の実施、依頼者への監査報告、改善のフォローアップまでが一連の流れとなる。関連論点として、業務の有効性・効率性、財務報告の信頼性、法令遵守などの達成のために組織内に組み込まれ全員によって遂行される内部統制、その中核概念である職務分掌、そして経営陣がITの利活用を方向付け統制・監督するITガバナンスも本章の頻出テーマである。

この章の問題から3問

ウォータフォールモデルでは、要件定義からテストまでの工程を順番に進め、原則として前の工程に後戻りしないことを前提とする。

正解 ○(正しい)

正しい。IPA公式シラバス「開発プロセス・手法」の定義どおり、ウォータフォールモデルは各工程を完了させてから次工程へ進み、原則後戻りしない。進捗管理がしやすい反面、後工程での仕様変更に弱い点とセットで押さえる。「柔軟に工程を行き来する」と書き換えたひっかけが定番。

ブラックボックステストでは、プログラムの内部構造に着目し、命令や分岐がどれだけ実行されたかという網羅性を基準にテストケースを設計する。

正解 ×(誤り)

誤り。内部構造・網羅性に着目するのはホワイトボックステストである。ブラックボックステストは内部構造を考慮せず、入力と出力の関係(仕様)だけに着目し、同値分割や境界値分析でテストケースを設計する(IPA公式シラバス「開発プロセス・手法」)。両者の定義の入替えが本試験の典型的ひっかけ。

SLA(サービスレベル合意書)は、サービス提供者と利用者の間で、稼働率や障害復旧時間などのサービス品質の水準を合意して文書化したものである。

正解 ○(正しい)

正しい。ITILおよびJIS Q 20000(ISO/IEC 20000)に基づく定義であり、SLAは提供者と利用者が達成すべきサービスレベルを数値目標を含めて事前合意する文書である。その達成状況を継続的に監視・改善する活動がSLM(サービスレベル管理)で、SLAとSLMの役割の混同を狙う出題が多い。

この章の残り12問を解く

登録不要 ・ 採点と解説はその場 ・ 進捗は端末に保存

ITパスポートの他の章

本ページの講義ノートと問題は、各試験の出題範囲に基づきAIが作成し、法令・基準に照らして別のAIレンズで敵対的に検証したものです(検証プロセス)。法改正等で誤りが見つかった場合は随時修正します。合格を保証するものではありません。