情報担当がいない会社こそ覚えておきたい「発注側のプロジェクト管理」

1. はじめに

初級編では、システム構築における要件定義、スコープ、RFI、RFP、RFQ、三社見積もりの基本を整理しました。

中級編では、もう一歩踏み込みます。

テーマは、「業者に丸投げしないための発注側プロジェクト管理」です。

中小企業では、専任の情報システム担当者がいないことも珍しくありません。

そのため、システム構築やWebシステム導入の場面で、次のような問題が起きやすくなります。

• 要件が曖昧なまま発注する
• 見積の前提条件を確認しない
• 追加費用の発生条件を決めていない
• 途中で社内要望が増え続ける
• 完成の判断基準がない
• 納品後の保守範囲が分からない
• データの所有権や解約時の扱いを確認していない

この状態でシステム構築を進めると、失敗します。

システム構築の失敗は、技術だけの問題ではありません。

多くの場合、発注側の整理不足、判断不足、記録不足、合意不足によって起きます。

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

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

1. 要件には優先順位をつける
2. スコープ変更にはルールを作る
3. WBSで作業を分解する
4. リスクは事前に書き出す
5. 検収条件を契約前に決める

特に重要なのは、「あとで考えます」を減らすことです。

システム構築では、あとで考えることが多いほど、あとで揉めます。

3. PMBOK的に見るシステム構築

PMBOK的に考えると、システム構築は単なる制作作業ではありません。

次の要素を管理するプロジェクトです。

つまり、発注側がやるべきことは、
業者の作業を細かく監視することではなく、判断すべきことを判断し、記録すべきことを記録すること
です。

4. 要件定義 中級編

「欲しい機能」を並べるだけでは足りない

要件定義でよくある失敗は、欲しい機能を全部並べてしまうことです。

例：

• 顧客管理したい
• 予約管理したい
• メール通知したい
• LINE通知したい
• 請求書も出したい
• 売上集計もしたい
• スマホ対応したい
• 管理者権限も分けたい
• データ移行もしたい
• 将来的にアプリ化したい

これ自体は悪くありません。

しかし、問題は、
すべてを同じ重要度で扱ってしまうこと
です。

すべてが重要だと言うと、業者側から見ると、何が本当に重要なのか分かりません。

その結果、見積が高くなる、納期が伸びる、提案がぼやける、優先順位の低い機能に時間を使ってしまう、ということが起きます。

5. MoSCoWで要件に優先順位をつける

要件の優先順位を決めるときは、MoSCoWという考え方が使えます。

例：予約管理システムの場合

このように整理すると、発注側も業者側も判断しやすくなります。

6. 中級者が見るべき要件の4分類

要件は、単に「機能」と「非機能」に分けるだけでは不十分です。

中級編では、次の4分類で考えます。

特に中小企業で抜けやすいのは、運用要件です。

システムは作って終わりではありません。

実際には、次のような運用が必ず発生します。

• 新入社員のアカウント追加
• 退職者アカウントの停止
• パスワード再発行
• 権限変更
• データの修正
• 操作ミスの復旧
• 障害時の連絡
• バックアップ確認
• 契約更新
• 解約時のデータ取得

この運用を決めていないシステムは、導入後に現場が困ります。

7. 要件トレーサビリティとは

中級編で覚えておきたい考え方が、
要件トレーサビリティ
です。

難しく聞こえますが、意味はシンプルです。

要件が、設計・開発・テスト・検収まで、きちんとつながっているか確認すること

たとえば、RFPに「管理者はユーザーを追加できる」と書いたとします。

その要件が、

• 画面設計に反映されているか
• 開発対象に入っているか
• テスト項目に入っているか
• 検収時に確認されるか

ここまで追跡します。

8. 要件トレーサビリティ表の例

これを作るだけで、
言った・言わない問題
がかなり減ります。

9. スコープ管理 中級編

作業範囲は「成果物」で管理する

スコープ管理で重要なのは、
作業内容ではなく成果物で管理すること
です。

悪い例：

顧客管理システムを作る

良い例：

以下を成果物とする。
・管理画面
・顧客登録画面
・顧客検索画面
・CSV出力機能
・管理者マニュアル
・テスト結果表
・バックアップ手順書

システム構築では、成果物が曖昧だと危険です。

特に次の成果物は、契約前に確認すべきです。

• 要件定義書
• 基本設計書
• 画面一覧
• 画面設計書
• 機能一覧
• テスト仕様書
• テスト結果
• 管理者マニュアル
• 利用者マニュアル
• 保守手順書
• アカウント一覧
• サーバー情報
• ドメイン情報
• バックアップ手順
• ソースコードの扱い
• データベースの扱い

10. スコープ外を書く重要性

発注書やRFPには、必ず対象外を書きます。

対象外を書かないと、後から次のような話になります。

「これも当然入っていると思っていました」
「普通はここまでやってくれると思っていました」
「前の業者はやってくれました」
「見積に含まれていると思っていました」

このトラブルを防ぐために、対象外を明記します。

対象外の例

• 既存Excelのデータ整備
• 紙資料の電子化
• 過去データの手入力
• LINE公式アカウントの開設
• 会計ソフトとの連携
• 外部システムAPI連携
• 業務マニュアルの全面作成
• 社内研修の実施
• 端末購入
• ネットワーク工事
• セキュリティ診断
• 公開後の機能追加
• 法務確認
• 規程作成

対象外を書くことは、冷たいことではありません。
むしろ、発注側と受注側の認識を合わせるために必要です。

11. WBSとは何か

WBSとは、Work Breakdown Structureの略です。

簡単に言うと、
作業を細かく分解した表
です。

システム構築では、ざっくり「開発一式」と書かれている見積は危険です。

なぜなら、何にどれだけの作業が含まれているか分からないからです。

12. WBSの例

WBSがあると、プロジェクト全体が見えるようになります。

13. ガントチャートの考え方

システム構築では、スケジュール表も重要です。

ただし、細かすぎるスケジュールよりも、まずは大きな流れを押さえます。

例：3か月プロジェクト

ここで重要なのは、
発注側の確認期間もスケジュールに入れること
です。

業者だけが作業するわけではありません。

発注側にも、確認、判断、承認、テストの作業があります。

14. ステークホルダー管理

誰が決めるのかを先に決める

システム構築で揉める原因の一つが、
誰が決定権を持っているか分からないこと
です。

現場担当者は「この機能が欲しい」と言う。
経営者は「費用を抑えたい」と言う。
管理者は「運用が大変になる」と言う。
業者は「仕様を決めてほしい」と言う。

この状態で進めると、話がまとまりません。

15. RACIで役割を整理する

役割整理にはRACIが使えます。

例

これを決めておくと、
誰のOKで次に進めるのか
が明確になります。

16. 変更管理

途中変更は悪ではないが、無管理は危険

システム構築中に変更要望が出るのは普通です。

実際に画面を見てから、
「やっぱりこうしたい」
「この項目も必要だった」
「この帳票も出したい」
という話は必ず出ます。

変更そのものは悪くありません。

問題は、
変更を記録せず、費用や納期への影響も確認せず、なんとなく進めること
です。

17. 変更管理表の例

このように記録すると、無制限な追加要求を防げます。

18. リスク管理 中級編

「起きたら困ること」を先に書く

リスク管理とは、難しいものではありません。

起きたら困ることを、先に書き出しておくことです。

中小企業のシステム構築でよくあるリスクは、次のようなものです。

• 社内の確認が遅れる
• 決裁者が途中で変わる
• 現場から追加要望が増える
• 既存データが汚い
• 業者の説明が不十分
• 見積範囲が曖昧
• 保守費用が後から分かる
• セキュリティ要件が抜ける
• 本番公開日にトラブルが起きる
• 操作研修が足りない
• 退職者アカウントが残る
• バックアップが確認されていない

19. リスク管理表の例

リスクは、ゼロにはできません。

しかし、事前に見える化することで、被害を小さくできます。

20. 三社見積もり 中級編

金額ではなく「前提条件」を比較する

三社見積もりで一番やってはいけないことは、合計金額だけで比較すること
です。

安い見積には、安い理由があります。

もちろん、安くて良い会社もあります。
しかし、次のような理由で安く見えている場合があります。

• 要件定義が含まれていない
• データ移行が別料金
• 保守が別契約
• テストが簡易的
• マニュアル作成が含まれていない
• セキュリティ対策が弱い
• サーバー費用が別
• 障害対応が平日のみ
• ソースコードの引き渡しがない
• 解約時のデータ出力が有料

見積比較では、何が含まれていて、何が含まれていないかを確認します。

21. 見積比較で確認すべき項目

この表を作ると、単純な金額比較では見えない差が分かります。

22. ベンダー評価 中級編

業者選定では、金額以外に次の点を確認します。

1. 要件理解力

こちらの課題を正しく理解しているか。

見るべきポイント：

• 質問が具体的か
• 業務内容を理解しようとしているか
• こちらの言葉をただ繰り返していないか
• 要件の抜け漏れを指摘してくれるか

2. リスク説明力

良い業者は、できることだけではなく、リスクも説明します。

見るべきポイント：

• 難しい部分を説明してくれるか
• 追加費用になりそうな点を先に言うか
• セキュリティや運用面の注意点を話すか
• 「何でもできます」と言いすぎないか

3. 保守体制

システムは公開後が本番です。

見るべきポイント：

• 誰が問い合わせを受けるか
• 何時から何時まで対応するか
• 障害時の連絡方法は何か
• 月額保守に何が含まれるか
• 軽微な修正は含まれるか
• 追加作業の単価はいくらか

4. ドキュメント力

ドキュメントが弱い業者は、担当者が変わったときに困ります。

見るべきポイント：

• 要件定義書があるか
• 設計書があるか
• テスト結果があるか
• マニュアルがあるか
• サーバー情報が整理されるか
• 保守引継ぎ資料があるか

23. ベンダー評価表の例

費用は重要です。
しかし、費用だけで選ぶと失敗します。

中級編では、
費用の安さよりも、説明の透明性を重視する
と覚えてください。

24. 契約前に必ず確認すること

契約前には、最低限これを確認します。

費用

• 初期費用
• 月額費用
• 保守費用
• サーバー費用
• ドメイン費用
• SSL費用
• 追加作業単価
• 緊急対応費用

成果物

• システム本体
• 設計書
• テスト結果
• マニュアル
• 保守資料
• アカウント情報
• バックアップ手順
• ソースコードの扱い
• データベースの扱い

権利

• ドメインの契約者
• サーバーの契約者
• ソースコードの所有・利用権
• デザインの権利
• データの所有権
• 解約時のデータ取得方法

保守

• 月額保守に含まれる範囲
• 含まれない作業
• 問い合わせ方法
• 対応時間
• 障害時の対応
• バックアップ
• セキュリティアップデート
• 軽微修正の扱い

25. 検収 中級編

「完成しました」を信用するのではなく確認する

検収とは、
納品されたものが、発注内容を満たしているか確認すること
です。

検収で重要なのは、感覚で判断しないことです。

悪い例：

なんとなく動いているのでOK

良い例：

要件定義書のMust要件がすべて動作し、テスト項目を通過し、管理者マニュアルが納品され、本番環境で確認できたのでOK

26. 受入テストの例

受入テストでは、
発注側が実際の業務目線で確認すること
が重要です。

27. 検収条件の例文

契約や発注書には、次のような検収条件を入れると安全です。

本件の検収は、要件定義書に記載された対象機能のうち、Must要件が正常に動作すること、テスト結果表が提出されること、管理者向け操作説明資料が提出されること、本番環境にて発注者が主要業務の動作確認を行えることを条件とする。
なお、軽微な表示修正や運用上支障のない文言修正については、検収後の保守対応または別途協議により対応する。

このように書いておくと、完成判断がしやすくなります。

28. 情報担当がいない会社の現実的な体制

情報担当がいない会社でも、最低限の役割分担は必要です。

最低限の体制

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

複数人がバラバラに業者へ要望を出すと、プロジェクトは崩れます。

29. 情報担当がいない会社が最低限作るべき5つの資料

専門的な設計書をすべて作る必要はありません。

ただし、最低限この5つは作るべきです。

1. 課題整理表

2. 要件一覧表

3. スコープ表

4. 見積比較表

5. 受入テスト表

この5つがあるだけで、発注側の管理レベルは大きく上がります。

30. 中級編のまとめ

システム構築で重要なのは、業者に詳しい技術用語で勝つことではありません。

発注側がやるべきことは、次の5つです。

1. 目的を明確にする
2. 要件に優先順位をつける
3. スコープと対象外を決める
4. 変更・リスク・検収を記録する
5. 見積を金額ではなく前提条件で比較する

情報担当がいない会社ほど、
完璧なIT知識よりも、発注側の整理力
が重要です。

PMBOKの考え方をすべて覚える必要はありません。

しかし、

• スコープ
• 要件
• リスク
• 調達
• 変更管理
• 検収

この6つを押さえるだけで、システム構築の失敗確率は大きく下がります。

システム構築は、業者選びだけで決まりません。

発注側が、何をしたいのか、何をしないのか、何をもって完成とするのかを決められるか。

そこが一番重要です。

情報担当がいない会社でも、
RFP、要件一覧、スコープ表、見積比較表、受入テスト表を用意できれば、十分に戦えます。

システム構築で失敗しないために必要なのは、
高度なプログラミング知識ではありません。

発注側が、プロジェクトを管理する意識を持つこと。