マネジメント系 攻略ガイド

基本の仕組み

Aが2日、Aの後にBが3日とCが5日、両方の完了後にDが1日なら、全体は2＋5＋1＝8日です。Bを1日短縮しても全体の8日は変わりません。

WBSで成果物を作業へ分解し、依存関係を結んだ最長経路をクリティカルパスとして見ます。並行できる作業を単純に全部足さないのがポイントです。

期間短縮は品質や費用に影響することがあります。担当を増やせばいつでも比例して早く終わるわけではなく、分担や調整の時間も生まれます。

プロジェクトのリスクは、発生確率と起きた場合の影響を見て優先順位を付けます。事前に避ける、影響を減らす、保険等で移転する、対応費用との比較で受容するなどの判断をします。追加機能を無審査で受け入れると、当初の費用や納期の前提が崩れるため、変更の影響を合意します。

計画・依存関係・リスク

WBSは成果物や作業を実行可能な単位へ階層的に分解したものです。ガントチャートは作業を時間軸の横棒で示し、アローダイアグラム（PERT図）は作業の順序と依存関係を示します。クリティカルパス上の作業には余裕時間がないため、遅れるとそのまま全体の完了が遅れます。クリティカルパス以外の作業は、余裕時間の範囲内なら遅れても全体の期間は変わりません。

リスクは発生確率と影響度で優先順位を付け、対応の担当者と実施条件を決めます。変更要求は、影響する費用・期限・品質を評価して承認し、計画に反映します。

基本の仕組み

予備機へ切り替えてサービスを復旧するのがインシデント管理の例です。繰り返す停止の根本原因を調べ、恒久対策を行う活動は問題管理として考えます。

SLAはサービス提供者と利用者の間で合意する品質条件です。目標復旧時間などを定め、実績を測ることで、期待と実際のずれを把握します。

復旧と原因解決は同じではありません。暫定対応で動いていても再発のおそれは残るため、変更を管理しながら恒久対策を進めます。

事業継続計画では、止められない業務を選び、許容する停止時間や失ってよいデータ量から復旧を設計します。RTOは復旧までの目標時間、RPOはどの時点のデータまで戻せるようにするかの目標です。前日夜のバックアップだけなら、当日昼の障害で午前中の更新を失う場合があります。

運用管理と事業継続

インシデント管理は障害の影響を抑えてサービスを早く復旧し、問題管理は繰り返す障害の根本原因を調べて再発を防ぎます。変更管理は修正を評価・承認し、承認された変更はリリース管理で本番環境へ展開します。構成管理は、サーバやソフトウェアなどの構成要素とその関係を正確に記録します。

利用者からの問合せや障害の連絡を一元的に受け付ける窓口をサービスデスクといいます。窓口を一つにすること（SPOC：Single Point of Contact）で、記録と一次対応を漏れなく行い、解決できない案件は専門部署へ引き継ぎ（エスカレーション）ます。

BCPでは優先業務、代替手段、連絡・復旧手順を決めます。RTOはいつまでに復旧するかという目標時間、RPOはどの時点のデータまで戻せるかという目標時点です。短いRPOにはより頻繁なバックアップ等が必要です。

ファシリティマネジメントは、建物・電源・空調などの設備を最適に保つ活動です。停電に備えるUPS（無停電電源装置）や自家発電装置、落雷による過電圧を防ぐサージ防護、入退室管理などが含まれます。

基本の仕組み

入力者と承認者を分け、変更履歴を残せば、誤入力を発見したり後から経緯を確認したりできます。監査人は、その仕組みが設計どおり動いているか証拠を集めます。

システム監査では、監査対象から独立した立場で評価し、改善につながる指摘を行います。実際の改善を決め実施する責任は、対象の経営者や管理者にあります。

監査人が対象業務を自ら運用し、その成果を自分で監査すると独立性が損なわれます。監査があるだけで全ての不正を防げるとも限りません。

統制と監査の分担

内部統制は、組織自身が業務の有効性及び効率性、報告の信頼性、法令等の遵守、資産の保全の四つの目的を達成するための仕組みです。金融庁の基準では、統制環境、リスクの評価と対応、統制活動、情報と伝達、モニタリング、ITへの対応の六つを基本的要素とします。アクセス権の分離、承認、操作ログの保全などが具体例です。

システム監査は、統制の整備・運用を独立した立場から評価します。監査計画を立て、予備調査・本調査で監査証拠を集め、監査報告書を依頼者（通常は経営者）へ提出し、指摘事項の改善状況をフォローアップで確認します。経営者がIT活用の方針を示し監視する仕組みはITガバナンスと呼ばれます。

発注と支払の承認を同一人に集中させず、職務を分離します。監査人が改善案を示しても、実施する責任は被監査部門側にあります。監査証拠は記録・面談・現場確認などから集め、意見を裏付けます。

基本の仕組み

『空き枠を選んで予約できる』は機能要件です。『同時100人の利用時にも一覧を3秒以内に表示する』は非機能要件の例で、速度だけでなく測定条件も必要です。

要件定義で必要なことを明らかにし、設計で実現方法を決め、実装してテストします。単体テストは部品、結合テストは部品間の連携、システムテストは全体、受入テストは利用者側の要求を満たすかを確認します。

ウォーターフォールは工程を順に進め、アジャイルは短い反復で成果を確認しながら変化へ対応します。アジャイルでも計画や品質確認は必要です。

プロトタイピングでは、まず試作品を利用者に触ってもらい、「この入力順では使いにくい」「必要な表示がない」といった認識の差を早く見つけます。確認した結果を要件や設計へ戻す点が重要です。試作品が動いたことだけで、性能・安全性・保守性まで完成したとは判断しません。

開発工程とテストの対応

機能要件は「何をするか」、非機能要件は性能・可用性・安全性・使いやすさなど「どう動くか」を定めます。ウォーターフォールは工程を順に進め、アジャイルは短い反復で価値を確認・調整します。プロトタイプは画面や操作の認識合わせに役立ちます。

アジャイルの代表的な手法には、スプリントと呼ぶ短い期間で開発を繰り返すスクラムや、ペアプログラミング・テスト駆動開発などを実践するXP（エクストリームプログラミング）があります。開発と運用の担当が連携して、迅速かつ安定したリリースを目指す考え方をDevOpsといいます。

単体テストは個々の部品、結合テストは部品間、システムテストは全体の要件、受入テストは利用者の業務上の受入条件を確認します。テストの目的を取り違えず、対応する設計書や要件からテストケースを作ります。

テスト技法には、内部構造を見ずに入力と出力が仕様どおりかを確かめるブラックボックステスト（同値分割・限界値分析など）と、命令や分岐の網羅など内部構造に着目するホワイトボックステストがあります。修正後に、変更していない既存の機能へ悪影響がないかを確かめるのが回帰テスト（リグレッションテスト）です。