こんにちは、たけです！今回は、基本情報技術者試験の中のマネジメント分野を、超わかりやすく、具体例も用いて、徹底解説します！
この記事を読めば、初学者でも「なるほど！」「イメージ湧いた！」となること間違いなしだと思います。
プロジェクトとは何か？
ここでは、「そもそもプロジェクトって何なの？」という基本から始めて、プロジェクトを立ち上げる前に絶対にやっておきたい重要な調査「フィージビリティスタディ」についても解説していきます。
プロジェクトの定義
プロジェクトとは、「明確な目的があり、期限が設定された一時的な活動」のことです。
- 通常の業務（ルーチンワーク）とは異なり、始まりと終わりが明確にある
- 成果物が定義されており、達成すべき目標が存在する
例：
- 新しいECサイトを3ヶ月で開発する
- 店舗のPOSシステムを1ヶ月で刷新する
- 文化祭の準備を1ヶ月で終わらせる
フィージビリティスタディ（実現可能性調査）
プロジェクトを立ち上げる前に、「そもそもこの計画は実現できるのか？」を検討するプロセスです。
主な観点：
- 技術的実現性：必要な技術や人材が社内・社外にあるか？
- 経済的実現性：コストに見合うリターンがあるか？予算は足りるか？
- 法的実現性：法律や規制に違反していないか？
この段階で「これは現実的に難しい」と判断されれば、プロジェクトそのものをやめる、または計画を修正する必要があります。
プロジェクトマネジメントとは？
続いて、プロジェクトをどうやって計画的に成功へ導くのか、つまり「プロジェクトマネジメント」について見ていきましょう。プロジェクトを成し遂げるための枠組みと考えてOKです。
プロジェクトマネジメントの定義
プロジェクトマネジメントとは、「プロジェクトを計画し、実行し、完了させるまでを効率的かつ確実に進めるための管理手法」です。
- 目標達成のためのスケジュール、コスト、品質、リスク、人材、コミュニケーションなどを総合的にマネジメントする
- チーム全体が同じゴールに向かってスムーズに進めるように調整する役割も含まれる
PMBOKとは？
PMBOK（Project Management Body of Knowledge）は、プロジェクトマネジメントの国際的なガイドラインであり、米国PMI（Project Management Institute）が発行しています。
PMBOKの5つのプロセス（プロジェクトの流れ）
プロジェクトは次の流れで進んでいきます：
立ち上げ → 計画 → 実行 → 監視・コントロール → 終結
- 「立ち上げ」でプロジェクトの目的と関係者を定め、
- 「計画」で詳細なスケジュールや予算を設計し、
- 「実行」で実際の作業に取りかかり、
- 「監視・コントロール」で進捗や課題をチェックして修正し、
- 最後に「終結」でプロジェクトを正式に終了させます。
PMBOKの10の知識エリア
それぞれのプロセスを支える管理分野がこちらです。
- 統合管理：全体の整合性をとる
- スコープ管理：やること／やらないことの明確化
- スケジュール管理：期限を守るための工程管理
- コスト管理：予算の範囲で実行
- 品質管理：成果物の品質を保証
- 資源管理：人材や設備の最適配置
- コミュニケーション管理：情報共有と報連相の徹底
- リスク管理：起こりうる問題の事前対処
- 調達管理：外部委託や発注の管理
- ステークホルダー管理：関係者の期待値調整と満足度の向上
プロジェクト計画に必要な各種管理スキル
ここからは、PMBOKに登場する10の知識エリアの中から、特に重要なものをピックアップして詳しく見ていきます。それぞれが具体的にどんな役割を果たしているのか、順を追って説明していきますね。
スコープ管理
スコープとは「プロジェクトでやるべきこと」のこと。スコープ管理はその範囲を明確にするプロセスです。このスコープを明確にするために使われる代表的な手法がWBS（Work Breakdown Structure）です。WBSは、スコープを細かい作業単位に分解して「見える化」し、作業漏れや範囲のズレを防ぐのに役立ちます。
⇨スコープを曖昧にすると、後から「あれもこれも追加して」となり、工期やコストが爆増。逆に、必要なものが漏れていると顧客が満足しない
例：
- 「注文ページ作って」→ 決済？会員登録？SNS連携？ → やる・やらないを最初に明確化！
WBS（Work Breakdown Structure）
大きな作業を小さく分解することで、抜け漏れを防ぎ、スケジュールや工数を見積もりやすくします。
例：ECサイト構築
- トップページ作成
- 商品一覧ページ作成
- カート・決済機能
- テスト・デバッグ
スケジュール管理
スケジュール管理では、プロジェクトを期限までに完了させるために「いつ、何を、誰が行うか」を計画し、調整していきます。
この目的を達成するために、主に次の2つの手法が使われます。
ガントチャート
- タスクを棒グラフで表した表。左から右に時系列で進捗が見える。
- 誰がいつ何をするのかが一目でわかる。
アローダイアグラム
- 作業の流れや順序、依存関係を矢印で表現。
- 重要経路（クリティカルパス）や、どこに余裕（フロート）があるかがわかる。
コスト管理
コスト管理では、「プロジェクトにかかる費用を正確に見積もり、計画し、管理する」ことが求められます。コストが計画通りに収まっているかを常に意識しながら、予算超過を防ぐ必要があります。
この目的を果たすために、主に以下の手法が使われます。
開発工数（人月）
「作業量」を数値化する方法で、現場では通常「人月（にんげつ）」という単位で考えます。
例：3人 × 1ヶ月 = 3人月
1人月はおおよそ20営業日とされ、これに人件費を掛け合わせることでコストを算出します。
ファンクションポイント法（FP法）
システムの規模を「機能の数」で数値化して、その合計値をもとに見積もる手法です。
例：
- 入力機能 × 4点
- 出力機能 × 5点
- 照会機能 × 3点
など、機能ごとに重みづけをして開発の難易度やボリュームを算出します。
品質管理
- 品質が悪いと、納品後に手戻りや不具合で信用ダウン＆コストアップ
- テスト、レビュー、不具合管理を計画的に実施
- PDCA（Plan→Do→Check→Act）サイクルで継続的改善
資源管理
- 人的資源：誰が何をいつまでにやるかを管理
- 物的資源：会議室、サーバー、ツールなど必要なものを用意し、計画通りに使えるよう調整
この管理が不十分だと、「人がいない」「道具が足りない」というトラブルに直結します。
コミュニケーション管理
情報の伝達ミスや共有不足は、プロジェクト失敗の原因になります。「いつ・誰に・何を・どの方法で伝えるか」を計画しておくことで、関係者間の理解ズレを防ぎます。例としては、「毎朝10時に進捗ミーティング」「Slackで全体連絡」など。
リスク管理
プロジェクトに影響を与える可能性のある事象（例：納期遅延、サーバーダウン）を事前に洗い出して対策を立てる
例：
- サーバーが落ちたら？ → バックアップを別サーバーに用意しておく
- 主要メンバーが退職したら？ → 引き継ぎ体制の構築
調達管理
外注先に仕事を依頼する場合や、必要なソフト・ハードを購入する場合は、契約・納期・品質・価格などをしっかり管理する必要があります。トラブル回避のため、契約内容を明確にすることが重要です。
ステークホルダー管理
- プロジェクトに関わる人々（顧客、上司、チームメンバーなど）との信頼関係を築く
- 期待値の調整と、継続的なコミュニケーションが重要
第4章：ITサービスマネジメントとITIL
ここでは、システムの「開発」ではなく「運用」をテーマに扱います。開発が終わってからも、システムは日々安定して使われなければ意味がありません。そのための考え方と仕組みが「ITサービスマネジメント」と「ITIL」です。
ITサービスマネジメントとは
企業が提供するITサービス（業務システム、クラウドサービスなど）を、安定的かつ継続的に運用し、ユーザーに満足してもらうための管理方法です。
ITILとは
ITIL（Information Technology Infrastructure Library）は、ITサービスマネジメントにおけるベストプラクティス（成功事例）を集めたフレームワークです。
サービス運用の方法
サービスデスクの種類
- 中央型：本社に一極集中して問い合わせ対応
- ローカル型：各拠点にそれぞれの窓口を設ける
- バーチャル型：物理的に分かれていても、ネット上で一体運用
サービス運用プロセス
- インシデント管理：障害やトラブルに素早く対応して復旧
- 問題管理：根本原因を追求し、恒久的対策を講じる
- 変更管理：システム変更の影響を最小限に抑えるよう計画・実行
- 構成管理：サーバーやソフトなど、構成要素の情報を一元管理
- リリース管理：新機能やパッチなどをスムーズに提供
中長期的運用のための管理
- サービスレベル管理（SLA：Service Level Agreement）
- サービス提供者と利用者の間で「どのレベルのサービスを提供するか」を取り決めた契約書
- 例：「システムの稼働率は月99.9%以上を保証」など
- 可用性管理：
- システムやサービスが「必要なときに利用可能」であるように維持管理する
- ダウンタイムの短縮がカギ
- キャパシティ管理：
- 利用者数やトラフィックの増加に耐えられるよう、サーバーやネットワークのリソースを見積もって準備する
システム監査と企業統治
最後にプロジェクトやシステムの運用がうまくいっているかをチェックする「監査」や、「会社として正しく運営されているか」を守る「ガバナンス・内部統制」について解説していきます。ミスや不正を未然に防ぐために、とても大切な視点です。
システム監査とは
ITシステムが適切に設計・運用され、情報の正確性・安全性・効率性が保たれているかを、第三者がチェックするプロセスです。
役割分担
- 監査依頼人：監査を依頼する人（例：経営者）
- 監査対象部門：実際に監査を受ける部門（例：情報システム部）
- システム監査人：中立的な立場で評価・指摘を行う専門家
監査の原則
- 外観上の独立性：見た目に第三者として中立であること
- 精神上の独立性：忖度せず、公正に判断できる心構えを持つこと
監査の流れ
- 監査計画の作成：目的・対象・方法を決定
- 監査実施：ヒアリング・資料分析・現場確認など
- 監査報告：問題点と改善提案をまとめて報告書を提出
- フォローアップ：改善状況を確認し、再評価を行う
コーポレートガバナンスと内部統制の違い
- コーポレートガバナンス：企業経営が正しく行われているか、取締役会などが監視・指導する仕組み（経営層が対象）
- 内部統制：業務レベルでの不正・ミスを防ぐための仕組み（現場が対象）
おわりに
ここまで読んでくれてありがとうございます！
この内容をマスターすれば、基本情報のマネジメント分野はかなり手応えありだと思います。
わかりにくい用語やもっと詳しく知りたいところがあれば、コメントで教えてください！
ちなみに私が基本情報の勉強で使用している教材はこちらです。
図や表を用いた解説が多く、とてもわかりやすいです！
他の基本情報の記事はこちらです！
AI関連の記事も書いてるのでこちらもぜひ！
