システム開発のリスクを調べると、費用・納期・品質といった分類が並んだ記事がたくさん出てきます。読めば「たしかにそうだ」と思うのですが、では自社は何をすればいいのかというと、手が止まる。そんな方に向けた記事です。
一覧を眺めるだけでは動けない理由は単純で、リスクの分類は「何が起きるか」しか教えてくれないからです。動くために必要なのは、そのリスクが自社の事情で起きるのか、開発会社の側で起きるのかという区別です。この記事では、システム開発のリスクを5つに整理したうえで、どちらの側で起きるかで分けて、先に打てる手を説明します。
この記事のポイント
- リスクは費用・納期・品質・体制・技術の5つに分けると抜けにくい
- 大事なのは分類ではなく、どちらの側の事情で起きるかの区別
- 発注側の落ち度で起きるリスクは、契約前にほぼ潰せる
- 全部に備えようとせず、影響の大きい2つに絞る
目次
システム開発のリスクを5つに分けて把握する
まず全体像です。分類そのものはどの資料でも大きくは変わりません。
費用・納期・品質・体制・技術の5つ
システム開発で起きる問題は、次の5つに分けるとおおむね収まります。
| 種類 | 起きること | 気づくタイミング |
|---|---|---|
| 費用 | 追加費用が積み上がり、予算を超える | 開発の中盤以降 |
| 納期 | 完成が遅れ、稼働予定日に間に合わない | テスト工程に入ってから |
| 品質 | 動くが業務が回らない、不具合が多い | 受入テストか稼働後 |
| 体制 | 決める人がいない、担当者が交代する | 要件定義の途中 |
| 技術 | 選んだ方式で実現できない、性能が出ない | 設計から実装の間 |
この表で注目してほしいのは右の列です。費用と納期と品質は、気づくのが遅いという共通点があります。中盤以降に表に出るので、気づいたときには手を打つ余地が減っています。
逆に体制のリスクは早い段階で表に出ます。要件定義で「その件は持ち帰ります」が続くなら、決める人がいないというサインです。ここは早いうちに直せます。
技術のリスクも比較的早く出ますが、発注側からは見えにくいのが厄介です。設計の段階で「この方式で大丈夫ですか」と聞いても、専門的な回答が返ってきて判断できません。ここは中身を理解しようとするより、「もし想定した性能が出なかった場合、どう対処しますか」と聞くほうが実になります。答えが用意されているかどうかで、検討の深さが分かります。
分類より大事なのは、どちらの側で起きるか
ここがこの記事の主題です。同じ「納期が遅れる」でも、原因が自社にあるのか開発会社にあるのかで、打てる手はまったく違います。
自社の事情で起きるものは、契約前や着手時に自分で潰せます。開発会社の側で起きるものは、こちらでは直接どうにもできないので、選ぶ段階で見抜くか、契約で備えるしかありません。
一覧を眺めて不安になるのは、この2つが混ざったまま並んでいるからです。分けてしまえば、やることは意外と少なくなります。
もうひとつ、どちらとも言えないものがあります。要件の認識違いがその代表で、伝えた側にも受け取った側にも原因があります。この種類は「どちらが悪いか」を決めようとすると進まないので、記録の残し方で防ぐ領域だと割り切ってください。
発注側の事情で起きるリスク
実務で多いのは、こちら側です。私の感覚では、揉めた案件の半分以上は発注側にも原因があります。
- 要件が決まらない… 社内で意見が割れたまま開発会社に渡す。結果として作り直しになる
- 確認が遅い… 設計書のレビューが1週間止まると、その分だけ後ろがずれる
- 決める人が出てこない… 打ち合わせに担当者しか出ず、その場で決まらない
- 現場を巻き込んでいない… 情シスだけで決めた要件が、実際の業務と合わない
- あとから要望が増える… 見せたら現場から追加要望が出て、範囲が膨らむ
これらは全部、開発会社を替えても解決しません。逆に言えば、発注側の準備次第で大部分を防げます。要件定義がうまくいかない典型的なパターンは要件定義が失敗する原因の記事で扱っています。
特に2つ目の「確認が遅い」は軽く見られがちです。設計書のレビューを2週間止めれば、単純に2週間後ろにずれます。それが3回あれば1か月半です。開発会社は待っている間も人を確保しているので、その分の費用が請求されることもあります。
開発会社の側で起きるリスク
もう一方は、こちらで直接コントロールできない領域です。
- 見積もりが甘い… 受注を優先して工数を低く見積もり、途中で足りなくなる
- 要員が交代する… 主要な担当者が抜け、引き継ぎで時間が溶ける
- 技術の選択を誤る… 慣れていない方式を選び、性能や連携でつまずく
- 下請けに丸ごと出す… 実際に作る会社と話ができず、伝言ゲームになる
- 報告が上がってこない… 遅れを抱えたまま「順調です」と言い続ける
これらは、選定の段階で見抜くか、契約と運用で備えるしかありません。ただし全部を疑ってかかる必要はなく、影響の大きいものだけ確認すれば十分です。次でその話をします。
見抜き方として実用的なのは、提案の段階で「今回の案件で、うまくいかないとしたらどこだと思いますか」と聞くことです。良いことしか言わない会社より、懸念を自分から挙げる会社のほうが、進行中も実態を報告してくれます。
システム開発のリスクに発注側が先に打つ手
ここからは、実際に何をするかです。
契約前に潰すものと、進行中に見るもの
打ち手は、いつ実行できるかで2つに分かれます。
| 時期 | やること |
|---|---|
| 契約前 | 決裁者を決める。今回作らないものを名指しする。体制図で実働者を確認する。追加費用の条件を書面にする |
| 着手時 | 確認の期限を決める。議事録の担当を決める。現場の担当者を各業務1〜2名確保する |
| 進行中 | 週次で残作業を見る。悪い報告が出てくるかを見る。テスト期間が削られていないかを見る |
契約前の4つは、その気になれば1日で決められるものばかりです。にもかかわらず、決めないまま進めてしまうことが多い。ここを埋めるだけで、発注側の事情で起きるリスクは大きく減ります。
とりわけ効くのが「今回作らないものを名指しする」です。作るものを列挙するのは誰でもやりますが、作らないものを書いている発注側はほとんどいません。ここが空白だと、あとから出てきた要望が範囲内か範囲外かを判断できず、費用の話が毎回もめます。
契約書に入れておくと効く4項目
開発会社の側で起きるリスクは、こちらでは直接どうにもできません。だからこそ、起きたときにどうするかを先に書面へ書いておく価値があります。ひな形を一から作る必要はなく、届いた契約書に次の4つが書かれているかを見るだけです。
- 追加費用が発生する条件と、その決め方（誰の承認で確定するか）
- 主要な担当者が交代する場合の通知と引き継ぎの取り決め
- 再委託を行う場合の事前通知の要否
- 納品物の一覧（設計書やソースコードを含むか）
どれも「起きたら困ること」を先に決めておくだけの項目です。書かれていなければ追記を依頼してください。断られる性質のものではありません。もし強く渋られるなら、その反応自体が判断材料になります。
なお、条文の細かい解釈が必要な場面では弁護士に相談してください。ここで挙げているのは、法律論に入る前に発注側が目視で確認できる範囲の話です。
兆候は数字より会話に出る
進行中のリスクは、進捗率の数字には出てきません。90%のまま何週間も動かない、という形で表に出るころには手遅れです。
早く気づける材料は、会話のほうにあります。
- 質問への回答が、前より遅くなってきた
- 「調整中です」「確認します」が増えて、結論が出ない
- 打ち合わせに出てくる人が変わった、または減った
- 悪い報告がまったく上がってこない
4つ目が一番の危険信号です。順調な案件でも問題は起きます。問題が報告されないのは、起きていないからではなく、言えない空気になっているからです。定例で「困っていることはありませんか」と毎回聞くだけでも、出てくる情報が変わります。
聞き方にもコツがあります。「順調ですか」と聞くと「順調です」しか返ってきません。「いま一番心配なのはどこですか」と聞くと、具体的な話が出てきます。前者は答えが1つしかない質問で、後者は考えないと答えられない質問だからです。
作業予定表から遅れを読み取る方法はシステム開発のWBSの記事にまとめています。
全部に備えない。影響の大きい2つに絞る
リスク一覧を作ると、つい全部に対策を書きたくなります。ですが、担当者が数人しかいない会社でそれをやると、管理そのものが負担になって続きません。
絞り方は簡単で、次の2軸で並べて上位2つだけ選びます。起きたときの影響が大きいか、そして起きる可能性が高いか。この2つを満たすものだけに手を打ってください。
多くの会社では、「要件が決まらない」と「テスト期間が削られる」の2つが上位に来ます。前者は発注側の事情、後者は開発会社の事情で起きるものです。片方だけ見ていても足りない、というのがこの記事で一番伝えたい点です。要件の抜けを事前に点検したい場合は、要件定義書レビューシートで観点を確認できます。
選んだ2つは、月に一度でいいので状況を見直してください。プロジェクトが進むと上位が入れ替わります。要件定義のうちは「要件が決まらない」が最上位でも、実装が始まれば「テスト期間」に移ります。固定した一覧を作って満足するより、いま何が一番危ないかを毎月言えるようにしておくほうが実務では効きます。
もうひとつ付け加えると、絞った2つ以外は「起きたら考える」で構いません。起きる可能性が低いものに時間をかけるより、確実に起きるものへ人を割いたほうが結果が変わります。備えなかったものが起きたときは、そのとき対応すればよい話です。
システム開発のリスクについてよくある質問
- Q. リスク管理表は作ったほうがいいですか。
- 開発会社が作るものを見せてもらえば足ります。自社で別に作る必要はありません。見るときは、発注側の作業に関わる項目が載っているかを確認してください。載っていなければ追加を依頼します。
- Q. リスクを理由に見積もりが高くなることはありますか。
- あります。要件が固まっていない状態で総額を確定させようとすると、開発会社は不確実な分を上乗せします。安くしたいなら、決められるところを先に決めて範囲を狭めるのが確実です。
- Q. 小さい案件でもリスク管理は必要ですか。
- 規模が小さいほど、絞ってください。決裁者を決めることと、今回作らないものを名指しすること。この2つだけでも、多くのトラブルは避けられます。
- Q. 開発会社が信頼できるか、事前に分かりますか。
- 完全には分かりません。ただ、提案の段階で悪い可能性を自分から説明する会社は、進行中も報告が上がってきます。良いことしか言わない提案のほうが、あとで困ります。
- Q. リスクが現実になったら、まず何をすればいいですか。
- 状況を書面にするところからです。いつ何が起きて、誰がどう判断したのかを時系列で残してください。対応を決めるのも、あとで責任の所在を整理するのも、この記録がないと進みません。感情的なやりとりに入る前に、事実を並べるのが先です。
