情報担当がいない会社でも押さえるべき「統制・契約・品質・リスク管理」

1. はじめに

初級編では、要件定義、スコープ、RFI、RFP、RFQ、三社見積もりの基本を整理しました。

中級編では、要件の優先順位、WBS、変更管理、リスク管理、受入テスト、ベンダー評価まで整理しました。

上級編では、さらに踏み込みます。

テーマは、

システム構築を「業者選定」ではなく「経営リスク管理」として扱うこと

です。

中小企業では、専任の情報システム担当者がいないことも多く、システム導入やWebシステム構築を外部業者に任せる場面が多くあります。

しかし、外部業者に任せることと、丸投げすることは違います。

システム構築では、次のような問題が起きます。

• 予算が膨らむ
• 納期が遅れる
• 要件が変わり続ける
• 業者の説明が分かりにくい
• 社内の決裁が遅れる
• セキュリティ要件が抜ける
• 保守範囲が曖昧なまま公開される
• データの取り出し条件が決まっていない
• 解約したくても乗り換えられない
• 担当者が退職すると運用できなくなる

これらは、単なる技術トラブルではありません。

多くは、
プロジェクト統制、契約、品質管理、リスク管理、運用設計の不足
によって発生します。

上級編では、情報担当がいない会社でも最低限知っておくべき、発注側の上級管理ポイントを整理します。

2. 上級編で覚えるべき結論

上級編で覚えるべきことは、次の7つです。

1. システム構築は経営リスクとして管理する
2. プロジェクトの意思決定ルールを決める
3. 契約書・SOW・SLAを分けて考える
4. 品質は完成後ではなく、工程ごとに確認する
5. セキュリティと個人情報保護は要件に入れる
6. ベンダーロックインと出口戦略を最初に考える
7. 本番公開後の運用引継ぎまでをプロジェクトに含める

上級編の合言葉は、

作る前に、揉めるところを潰す。

です。

3. PMBOK的に見た上級管理領域

PMBOK的に考えると、システム構築は次の領域を統合的に管理するプロジェクトです。

上級編では、
作る機能そのものよりも、プロジェクトを壊さない仕組みを重視します。

4. ガバナンスとは何か

ガバナンスとは、簡単に言えば、

誰が、何を、どの基準で判断するかを決めることです。

システム構築でガバナンスがないと、次のようになります。

• 現場担当者が勝手に要望を追加する
• 経営者が途中で方針を変える
• 業者が誰の指示を聞けばよいか分からない
• 追加費用の承認者が不明
• 納期遅延の責任が曖昧
• 最終的に誰も判断しない

つまり、ガバナンス不足とは、決める人が決まっていない状態です。

5. プロジェクト体制図を作る

情報担当がいない会社でも、最低限の体制図は必要です。

最低限の体制

重要なのは、業者との窓口を一本化することです。

複数人がバラバラに指示を出すと、プロジェクトは崩れます。

6. 意思決定ルールを決める

システム構築では、最初に意思決定ルールを決めます。

決めるべきこと

これを決めていないと、業者は困ります。

業者が困るだけではありません。

発注側も、誰がOKしたのか分からないまま進むことになります。

7. ステージゲート方式

上級編では、プロジェクトを一気に進めるのではなく、工程ごとに承認します。

これをステージゲートと考えると分かりやすいです。

これを入れることで、なんとなく開発が始まることを防げます。

8. 契約書・SOW・SLAの違い

上級編では、契約を分けて考えます。

システム構築では、契約書だけでは足りません。

最低限、次の3つを分けて理解します。

契約書

契約書では、主に次のような事項を扱います。

• 契約金額
• 支払条件
• 契約期間
• 秘密保持
• 損害賠償
• 知的財産権
• 再委託
• 解約条件
• 反社会的勢力排除
• 管轄裁判所

契約書は、法務的な土台です。

ただし、契約書だけでは、具体的に何を作るのかまでは不十分な場合があります。

SOW

SOWは、Statement of Workの略です。

日本語では、作業範囲記述書、業務範囲記述書のように考えると分かりやすいです。

SOWには、次の内容を書きます。

• プロジェクトの目的
• 対象業務
• 対象システム
• 作業範囲
• 対象外
• 成果物
• 前提条件
• 発注側の責任
• ベンダー側の責任
• スケジュール
• 検収条件
• 変更管理ルール

中小企業のシステム構築では、このSOWが非常に重要です。

契約書があっても、SOWが曖昧だと揉めます。

SLA

SLAは、Service Level Agreementの略です。

保守・運用時のサービス水準を決めるものです。

たとえば、次のような内容です。

• 問い合わせ受付時間
• 障害対応時間
• 初動連絡までの時間
• 復旧目標時間
• バックアップ頻度
• 監視の有無
• 月次報告の有無
• セキュリティアップデートの範囲

SLAがないと、障害時にこうなります。

すぐ対応してくれると思っていた。
月額保守に含まれると思っていた。
土日も対応してくれると思っていた。
バックアップから戻せると思っていた。

こういう「思っていた」をなくすために、SLAを決めます。

9. SOWに必ず入れるべき項目

SOWには、最低限以下を入れます。

1. 目的

このプロジェクトで何を達成したいのか。

例：

予約管理業務を一元化し、電話・Excel・紙で分散している予約情報を統合する。二重予約を防止し、受付業務の負担を軽減する。

2. スコープ

今回やること。

例：

• 予約登録
• 予約変更
• 予約キャンセル
• 顧客情報管理
• 管理者ログイン
• 権限管理
• CSV出力
• メール通知
• 管理者マニュアル作成

3. スコープ外

今回やらないこと。

例：

• LINE通知
• 会計ソフト連携
• スマホアプリ開発
• 紙資料のデータ入力代行
• 既存Excelの整備
• 社内規程の作成
• 端末購入
• ネットワーク工事

4. 成果物

納品されるもの。

例：

• 本番システム
• 要件定義書
• 画面設計書
• テスト結果表
• 管理者マニュアル
• 利用者マニュアル
• 保守引継ぎ資料
• アカウント一覧
• バックアップ手順書

5. 前提条件

見積や納期の前提。

例：

• 発注者は確認依頼に3営業日以内に回答する
• 既存データは発注者が指定フォーマットで提供する
• 追加機能は変更管理の対象とする
• 外部サービス利用料は別途発注者負担とする
• 本番公開日は双方協議のうえ決定する

6. 検収条件

完成と判断する条件。

例：

• Must要件が正常に動作すること
• 受入テストで重大な不具合がないこと
• 管理者マニュアルが提出されていること
• 本番環境で主要業務が確認できること
• 保守連絡先と障害時対応手順が共有されていること

10. 契約形態を理解する

システム構築では、契約形態によってリスクの持ち方が変わります。

代表的には、次のように考えます。

ここで大事なのは、
安易に契約形態を選ばないこと
です。

仕様が固まっていないのに請負で安く発注すると、後で変更費用が増えます。

逆に、成果物が明確なのに準委任で進めると、いつ完成するのか曖昧になることがあります。

契約形態は、プロジェクトの性質に合わせて考える必要があります。

11. 要件定義の上級管理

上級編では、要件定義をさらに厳密に扱います。

要件は、次の階層で整理します。

上級編で特に重要なのは、
非機能要件・運用要件・移行要件・保守要件
です。

多くの失敗は、機能要件ではなく、ここで起きます。

12. 非機能要件を軽視しない

非機能要件とは、機能そのものではなく、品質や安全性に関する条件です。

たとえば、次のようなものです。

非機能要件を決めないまま発注すると、こうなります。

動くけど遅い。
動くけどバックアップがない。
動くけど誰が操作したか分からない。
動くけど退職者アカウントが残る。
動くけど障害時に戻せない。
動くけど解約時にデータを取り出せない。

つまり、動くことと、業務で安全に使えることは別物です。

13. セキュリティ要件の上級チェック

システム構築で最低限確認すべきセキュリティ要件は次のとおりです。

認証

• 管理者ログインはあるか
• 二要素認証は必要か
• パスワードポリシーはあるか
• 退職者アカウントを停止できるか
• 共有アカウントを使わない設計か

権限管理

• 管理者と一般ユーザーを分けられるか
• 閲覧だけの権限を作れるか
• 拠点別・部署別に制限できるか
• 権限変更の手順があるか

ログ

• ログイン履歴が残るか
• データ変更履歴が残るか
• 管理者操作ログが残るか
• ログの保存期間は決まっているか

通信・保管

• 通信はSSL/TLSで暗号化されるか
• 個人情報は適切に保護されるか
• バックアップデータも保護されるか
• 外部サービスとの連携先は明確か

脆弱性対応

• 使用しているCMSやプラグインは更新されるか
• セキュリティアップデートは誰が行うか
• 脆弱性が見つかった場合の連絡ルールはあるか
• 緊急対応の費用は決まっているか

14. 個人情報を扱う場合の確認

顧客情報、社員情報、予約情報、成績情報、受験者情報、医療・美容・教育系の情報などを扱う場合、個人情報の取り扱いは非常に重要です。

確認すべきことは次のとおりです。

• どの個人情報を扱うのか
• 利用目的は明確か
• 誰が閲覧できるのか
• 外部業者が閲覧できるのか
• 再委託はあるのか
• データは国内に保存されるのか
• バックアップ先はどこか
• 削除依頼に対応できるか
• 解約時にデータを削除できるか
• 漏洩時の連絡手順はあるか

ここを曖昧にすると、単なるシステムトラブルでは済まなくなります。

15. 品質管理 上級編

品質管理とは、完成後に一度だけ確認することではありません。

上級編では、品質を工程ごとに確認します。

品質は、最後にまとめて確認するものではありません。

各工程で止める勇気が必要
です。

16. 品質ゲートの例

このように、工程ごとに合格条件を作ることが重要です。

17. テストの種類を理解する

発注側も、最低限テストの種類を知っておくべきです。

特に重要なのは、
受入テストは発注側の責任
という点です。

業者の「テスト済み」は、業者目線の動作確認です。

発注側は、実際の業務の流れで確認する必要があります。

18. 受入テストは業務シナリオで行う

受入テストでは、画面を適当に触るだけでは不十分です。

実際の業務シナリオで確認します。

例：予約管理システム

上級編では、正常に動くかだけでなく、間違った操作をしたときに安全かを見ます。

19. RAIDログを使う

上級編では、RAIDログを使うと管理しやすくなります。

RAIDとは、次の4つです。

RAIDログの例

RAIDログを使うと、問題、対応、決定が流れずに残るようになります。

20. 変更管理の上級ルール

変更管理では、次のルールを決めます。

変更の分類

変更時に確認すること

• なぜ変更するのか
• どの要件に関係するのか
• 費用は変わるのか
• 納期は変わるのか
• セキュリティに影響するか
• テスト項目は増えるか
• マニュアル修正が必要か
• 誰が承認するのか

変更を悪者にしてはいけません。

ただし、
変更は必ず記録し、承認してから進める
ことが重要です。

21. ベンダーロックインとは何か

ベンダーロックインとは、特定の業者に依存しすぎて、他社へ乗り換えられなくなる状態です。

よくある例

• サーバー情報を発注者が知らない
• ドメイン管理者が業者名義
• ソースコードが渡されない
• データベースの仕様が分からない
• 解約時にデータを取り出せない
• 独自仕様が多すぎて他社が触れない
• 管理画面の権限が業者に集中している
• 保守資料が存在しない

これは非常に危険です。

料金が高くなっても、対応が悪くなっても、乗り換えにくくなります。

22. 出口戦略を最初に決める

上級編では、システム導入時に出口戦略を決めます。

出口戦略とは、
解約・移行・乗り換えの条件を最初に決めること
です。

確認すべきこと

システムは、作るときより、やめるときに揉めることがあります。

だからこそ、始める前に終わり方を決める必要があります。

23. 調達管理 上級編

調達管理とは、単に見積を取ることではありません。

次の流れ全体を管理することです。

1. 課題整理
2. RFI
3. RFP
4. ベンダー説明会
5. 質問回答
6. 提案受領
7. 評価
8. 契約交渉
9. SOW確定
10. 発注
11. 構築管理
12. 検収
13. 保守契約
14. 更新・解約判断

上級編では、契約前の準備が、契約後のトラブルを減らすと考えます。

24. RFPにプロジェクト管理要件を入れる

RFPでは、機能要件だけでなく、プロジェクト管理要件も入れるべきです。

入れるべき項目

• プロジェクト体制
• 担当者の役割
• 定例会の頻度
• 議事録の作成方法
• 課題管理方法
• 変更管理方法
• テスト方針
• 検収条件
• セキュリティ対応
• 保守体制
• 障害時対応
• 解約時対応

機能要件だけをRFPに書くと、
作るものは比較できても、進め方を比較できません。

良いRFPは、何を作るかだけでなく、どう進めるかも問うものです。

25. ベンダー評価の上級基準

上級編では、ベンダーを次の観点で評価します。

上級編で重要なのは、「できます」と言う業者より、「ここはリスクです」と言える業者を評価することです。

26. 見積の上級チェック

見積では、合計金額ではなく構造を見ます。

見るべき項目

見積に「一式」が多い場合は注意が必要です。

一式が悪いわけではありません。

しかし、説明できない一式は危険です。

27. 価格交渉より範囲調整

システム構築で、単純な値引き交渉ばかりすると危険です。

無理に値引きすると、次のどこかが削られます。

• 要件定義
• 設計
• テスト
• ドキュメント
• セキュリティ
• 保守
• 担当者の稼働時間

価格が高いと感じたら、まずやるべきことは値引きではありません。

スコープを調整すること
です。

例

• LINE通知は次期対応にする
• 売上分析はCSV出力で代替する
• アプリ化は見送る
• 初期公開は管理者機能に絞る
• データ移行は直近2年分にする
• 帳票は最低限にする

価格交渉ではなく、
優先順位に基づいて段階導入する
ことが重要です。

28. 段階導入という考え方

上級編では、一度に全部作らない判断も重要です。

フェーズ分けの例

いきなり完璧なシステムを目指すと、費用もリスクも大きくなります。

まずは、
業務が回る最小構成
で始めることも有効です。

29. 本番公開判定

本番公開は、気合いで行うものではありません。

公開前には、公開判定を行います。

公開前チェック

公開前に特に重要なのは、
切戻し手順
です。

本番公開後に問題が起きたとき、前の状態に戻せるかを確認します。

30. 運用引継ぎ

システム構築は、公開して終わりではありません。

公開後に運用できる状態にするところまでがプロジェクトです。

運用引継ぎで確認すること

• 管理者は誰か
• パスワード再発行は誰が行うか
• アカウント追加は誰が行うか
• 退職者アカウント停止手順はあるか
• バックアップは誰が確認するか
• 障害時の連絡先はどこか
• 軽微修正はどこまで月額内か
• 月次確認は必要か
• ログ確認は誰が行うか
• 契約更新日はいつか

運用引継ぎがないシステムは、
担当者が変わった瞬間に止まるシステム
になります。

31. 保守契約の上級チェック

保守契約では、次の内容を確認します。

月額保守は、
何でも無料でやってくれる契約ではありません。

範囲を明確にすることが重要です。

32. 経営者が見るべきダッシュボード

上級編では、経営者や責任者が見るべき指標を決めます。

プロジェクト中

運用開始後

システムは、導入しただけでは価値になりません。

使われて、業務が良くなって、初めて価値になります。

33. 情報担当がいない会社が上級編で作るべき資料

専門部署がなくても、最低限この資料は作れます。

1. プロジェクト憲章

• 目的
• 背景
• 予算
• 期限
• 責任者
• 成功条件

2. SOW

• 作業範囲
• 対象外
• 成果物
• 前提条件
• 検収条件

3. 要件トレーサビリティ表

• 要件
• 設計
• テスト
• 検収
• 状態

4. RAIDログ

• リスク
• 対応事項
• 課題
• 決定事項

5. 変更管理表

• 変更内容
• 理由
• 費用影響
• 納期影響
• 承認

6. 受入テスト表

• 業務シナリオ
• 確認結果
• 不具合
• 再確認

7. 運用引継ぎ表

• 管理者
• 手順
• 連絡先
• 保守範囲
• 更新日

この7つがあると、情報担当がいない会社でも、かなり強くなります。

34. 上級編チェックリスト

契約前

• 目的は明確か
• 決裁者は決まっているか
• SOWはあるか
• 対象外は書かれているか
• 成果物は明確か
• 検収条件はあるか
• 保守範囲は明確か
• 解約時のデータ取得条件はあるか
• ドメイン・サーバーの名義は確認したか
• 追加費用の条件は明確か

構築中

• 定例会はあるか
• 議事録は残っているか
• RAIDログは更新されているか
• 変更管理表はあるか
• 要件とテストがつながっているか
• 発注側の確認遅れはないか
• 追加費用の承認は記録されているか

公開前

• 重大不具合は残っていないか
• 権限設定は確認したか
• バックアップは確認したか
• 切戻し手順はあるか
• 管理者マニュアルはあるか
• 利用者への案内は済んでいるか
• 保守連絡先は共有されているか

公開後

• 問い合わせ先は機能しているか
• 障害時対応は明確か
• 月額保守の範囲は守られているか
• アカウント管理はできているか
• 退職者アカウントは停止されているか
• バックアップ確認はしているか
• 契約更新日を把握しているか

35. 上級編のまとめ

システム構築は、単なる制作物の発注ではありません。

会社の業務、顧客情報、社員情報、売上、信用に関わるプロジェクトです。

上級編で覚えるべきことは、次の7つです。

1. ガバナンスを作る
   誰が決めるのかを明確にする。
2. SOWを作る
   作業範囲、対象外、成果物、前提条件を明確にする。
3. SLAを確認する
   公開後の保守・障害対応・バックアップを明確にする。
4. 品質ゲートを作る
   工程ごとに合格条件を決める。
5. セキュリティ要件を入れる
   認証、権限、ログ、バックアップ、脆弱性対応を確認する。
6. 出口戦略を作る
   解約、データ取得、乗り換え条件を最初に確認する。
7. 運用引継ぎまでを範囲に入れる
   公開して終わりではなく、使い続けられる状態にする。

36. 講義の締めメッセージ

情報担当がいない会社ほど、システム構築は業者任せになりがちです。

しかし、本当に重要なのは、技術を全部理解することではありません。

発注側が、

• 目的を決める
• 範囲を決める
• 責任者を決める
• 契約条件を確認する
• 変更を記録する
• 品質を確認する
• 運用まで考える

この基本を押さえることです。

システム構築で怖いのは、専門用語が分からないことではありません。

決めるべきことを決めないまま進めることです。

PMBOKの考え方を使うと、システム構築は整理できます。

情報担当がいない会社でも、
プロジェクト憲章、SOW、要件一覧、RAIDログ、変更管理表、受入テスト表、運用引継ぎ表を用意すれば、発注側として十分に戦えます。

上級編の結論は、これです。

システム構築は、作る前の統制で勝負が決まる。

業者に任せる部分と、発注側が決める部分を分ける。

これが、システム構築で損をしないための上級実務です。