「システムはリリースしたら終わり」——エンジニアとして経験を積むほど、この考え方が通用しないことは実感として分かってくるはずです。しかし、リリース後の運用をどう安定させるか、そしてその運用が正しく行われているかを客観的に証明する「システム監査」や、組織全体を統制する「内部統制」「ITガバナンス」となると、急に自分ごととして捉えにくくなるのではないでしょうか。
この記事では、プロジェクト計画の基礎に軽く触れたうえで、リリース後の運用・監査・ガバナンスという、エンジニアが見落としがちな領域を一気に解説します。
- プロジェクトの「3つの制約」と、計画フェーズの基礎（姉妹記事との使い分け）
- リリース後の価値を支える「ITサービスマネジメント」（ITIL・SLA・インシデント管理）
- 物理環境と緊急時を守る「ファシリティマネジメント」と「BCP」
- システム監査の目的と、監査人に求められる「独立性」
- 内部統制とITガバナンスが、現場のエンジニアとどう関係するのか
<この記事もおすすめ！>
\株式会社PRUMのメディア/
プロジェクトマネジメントの基礎知識を押さえておく
3つの制約（スコープ・タイム・コスト）と品質
プロジェクトとは、特定の目的を達成するために期限を定めて行う活動であり、明確な開始と終了があります。このプロジェクトには、スコープ（作業範囲）、タイム（納期）、コスト（予算）という3つの要素が互いに影響し合っており、例えば開発の途中で「新機能を追加したい」となれば、納期を延ばすか予算を増やすかの判断が必要になります。このバランスを制御し、最終的な「品質」を確保することが、プロジェクトマネジメントの本質です。
計画フェーズを支えるPMBOK・WBS・スケジュール管理という知識
こうしたプロジェクトの計画段階については、世界標準のフレームワークである「PMBOK」や、作業を最小単位に分解する「WBS」、ガントチャートやクリティカルパスを使ったスケジュール管理など、押さえておくべき知識がまだたくさんあります。これらの計画フェーズの基礎については、こちらの「プロジェクトと運用の違いとは？初心者が最初に押さえるべきPMの基本ルール」で詳しく解説していますので、あわせて読んでみてください。ここから先は、計画を終えて実際にリリースした後の話——「運用」「監査」「ガバナンス」に絞って解説していきます。
リリース後の価値を支える「ITサービスマネジメント」
システムはリリースして終わりではありません。ユーザーが継続して価値を感じられるよう、運用し、改善し続けることが重要です。
運用のベストプラクティス「ITIL」
ITIL（アイティル）は、ITサービス運用における成功事例を集めた世界的なガイドラインです。運用のルールを標準化することで、担当者によって対応にばらつきが出ることを防ぎます。「なんとなく経験と勘で運用している」状態から抜け出すための共通言語だと考えると分かりやすいでしょう。
SLA（サービスレベル合意書）とSLM
SLAとは、「システム稼働率99.9%以上」「重大な不具合は4時間以内に復旧」といったサービス品質の目標を、ユーザーと書面で約束するものです。そして、この約束した品質を守り、さらに向上させていく活動をSLM（サービスレベルマネジメント）と呼びます。SLMには、目標を立て、実行し、結果を確認し、改善するというPDCAサイクルが欠かせません。
インシデント管理と問題管理の使い分け
運用の現場では、「インシデント管理」と「問題管理」という2つの考え方を使い分ける必要があります。インシデント管理は、「今、システムが使えない」という状況に対して、根本原因の特定よりも先に、ワークアラウンド（応急処置）を適用してサービスを復旧させることを最優先します。一方、問題管理は、サービスが復旧した後に、根本原因を特定し、再発防止策を講じることに集中する活動です。「まず止血、そのあと原因究明」という順番を意識しておくと、現場での判断に迷わなくなります。
物理環境と緊急時を守る「ファシリティマネジメント」と「BCP」
ITシステムは、コードやソフトウェアだけで成り立っているわけではありません。物理的な基盤の上にはじめて成り立っています。
サーバー室・電源など、物理的基盤を守る仕事
サーバー室の温度管理や耐震対策、入退室管理、そしてUPS（無停電電源装置）や自家発電機の整備といった、物理的な環境を維持する仕事をファシリティマネジメントと呼びます。普段は意識されにくい領域ですが、これが崩れるとどれだけ優れたコードを書いても意味がなくなってしまいます。
BCP（事業継続計画）とBCM
巨大地震やサイバー攻撃といった予期せぬ事態が起きたときに、重要な業務を継続させる、あるいは早期に復旧させるための計画をBCP（事業継続計画）と呼びます。そして、このBCPを実際に維持し、訓練し続ける活動をBCM（事業継続管理）と呼びます。計画を作って終わりではなく、定期的に訓練して実効性を保つことが重要です。
システム監査：客観的な視点で「正しさ」を証明する
「監査」と聞くと、自分には関係のない、どこか怖いものだというイメージを持つ人も多いかもしれません。しかしシステム監査とは、組織のIT活用が法律や社内ルール、安全基準に則って行われているかを、第三者の立場から検証する活動です。
監査人に求められる「独立性」
システム監査で特に重要なのが、監査人が監査対象の部署から独立した立場であることです。自分が関わったシステムを自分で監査するのでは、客観性が保てません。実際に利害関係がないことだけでなく、「外から見て独立しているように見えるか」という外観上の独立性も重視されます。
監査の流れ（計画→実施→報告→フォローアップ）
システム監査は、大きく4つのステップで進みます。まず監査の計画を立て、次にヒアリングや証拠収集などの監査を実施し、その結果を報告書としてまとめて改善勧告を行い、最後に改善が実際に行われたかを確認するフォローアップを行います。この一連の流れを理解しておくと、自分の部署が監査を受ける立場になったときにも、落ち着いて対応できるようになります。
内部統制とITガバナンス：組織の「良心」と「戦略」
内部統制とコンプライアンス
内部統制とは、不祥事を防ぎ、経営目標を達成するために、経営者が組織の中に組み込むチェック機能のことです。そしてコンプライアンスとは、単に法令を守るだけでなく、社会的な倫理や企業の行動規範を守ることも含んだ、より広い概念です。「ルールで縛る」というより、「組織が健全であり続けるための仕組み」だと捉えると理解しやすいでしょう。
ITガバナンス（経営戦略としてのIT活用）
ITガバナンスとは、ITを単なる道具としてではなく、経営戦略の一部として捉え、組織全体の価値を高めるためにIT活用をコントロールする、経営陣の責任のもとで行われる活動です。現場のエンジニアが書く1行のコードも、突き詰めればこのITガバナンスという大きな枠組みの中に位置づけられています。自分の仕事が組織の戦略とどうつながっているかを意識できると、視座がひとつ上がります。
まとめ：管理と監査の知識が「信頼」という資産を作る
ここまで見てきたプロジェクトマネジメントやシステム監査の知識は、単なる事務手続きではありません。技術力を社会の中で確実に機能させるための「OS」のようなものです。このOSをインストールすることで、「ただコードが書ける人」から、「ビジネス目的を達成し、社会的責任を果たせるプロフェッショナル」へと進化していくことができます。プロジェクトの計画段階について、より詳しく知りたい方は、姉妹記事「プロジェクトと運用の違いとは？初心者が最初に押さえるべきPMの基本ルール」もあわせてご覧ください。
