システム開発のリスクは何がある？対策と管理のコツ

システム開発にはさまざまなリスクが隠れており、対策を怠るとシステム開発が失敗してしまうこともあります。

この記事ではシステム開発を発注する側の視点でどのようなリスクがあるのか、どのように対策すればいいのかを解説していきます。リスク回避のコツとここだけは押さえておきたい、最低限のチェックリストも用意しました。

この記事を読めばシステム開発のリスクと失敗結果がわかり、深刻な失敗をする前に対処できるようになることを目指して執筆しました。お役に立ちましたら幸いです。

実際の開発費用・期間をまとめた資料を無料で差し上げます。資料請求はこちら>>

リスクを放置するとどうなる？

システム開発のリスクは、一言でいうと「まだ起こっていないが今後起こる可能性がある、プロジェクトの成功を阻害する事象」です。

「まだ起きていないならば、実際に起こってから対処しても問題ないのでは？」とも思いますが、発生後に対処を行うとリカバーに多くの時間と費用を割くことになってしまいます。手遅れになると多大な損害が出たり、システム開発が失敗したりします。

システムが完成しない…
プロジェクトが中断する…
できたシステムが打ち合わせと違う…
できたシステムが現場で使われない…
会社同士の関係がこじれる…
最悪、訴訟問題に発展することも…

上記のような悲劇を起こさないように、システム開発を行う際どのようなリスクがあるのかを把握し、リスク発生を未然に防ぐ対策をする必要があります。

関連記事システム開発が失敗する原因と対策

関連記事：システム開発が失敗する原因と対策

実際の開発費用・期間をまとめた資料を無料で差し上げます。資料請求はこちら>>

どんなリスクがあるのか

リスクは大きく分けると「既知のリスク」と「未知のリスク」の2つがあります。この章では「既知のリスク」をメインに扱います。

既知のリスクは、リスクとして特定できて対策がとれるものを指します。主なシステム開発の既知のリスクは以下の通りです。

認識的リスク
技術的リスク
組織的リスク
金銭的リスク
納期遅延リスク

未知のリスクは、リスクとして特定できない想定外の事象を指します。担当者の突然の病気や退職、発注側の経営判断による開発方針の変更、天変地異や社会的事件などがこれにあたります。

これらのリスクはそれぞれ密接に関わっているという点も押さえておきたいポイントです。例えば、認識的リスクを放置してしまうと、無駄な工数や機能が増えてしまい、金銭的リスクや技術的リスクに繋がりやすくなってしまいます。

認識的リスク

誤認や勘違いによって起こるリスクのことです。

発注側とシステム開発側で作るもののイメージが最初から異なっていると、それ以降の認識も齟齬が生まれやすく、誤った方向に進んでしまう可能性があります。

認識的リスクが発生した結果、以下のような事象が発生します。

できたものが打ち合わせと違う
希望していた機能が備わっていない
誤認によって間違えて完成してしまった場合、それを修正するコストと納期が発生してしまう（納期遅延リスクにつながる）

もっともダメージが大きく、かつ一番起こりやすいため特に注力して防ぎたいリスクです。

技術的リスク

設計の段階では開発可能と判断したものの、いざ開発を進めていくと技術的に実装困難なことが判明するケースがあります。

また、新しい技術を採用した結果、システムが正しく動作しない/思った通りに動かないというケースも技術的リスクに当てはまります。

組織的リスク

システム開発では、システム構築の目的設定から要件定義、システムを運用開始する際の現場への展開まで、リーダーシップをもって組織全体を引っ張っていく力が必要です。

組織全体を引っ張っていく人たちがいないと、開発したシステムが現場で使用されなかったり、システム反対派の社員がシステムや業務を妨害したりするケースがあるため注意が必要です。

金銭的リスク

システム開発では、既存のツールでは賄えない部分をカバーできるようオーダーメイドで構築するため、正確な要件や費用を最初の段階で算出するのが難しいという問題があります。

開発が始まったあとに「やっぱり機能を追加したい」と仕様変更をすると、開発費用や期間がどんどん増えていってしまいます。

結果、最初の見積もりよりも費用がかかってしまった、当初の予算を大幅にオーバーしてしまったなどという事態がたびたび起こります。

納期遅延リスク

開発がスケジュール通りに進まず、納期が遅れてしまうリスクです。原因としては開発チームの欠員、予算削減、仕様変更などが当てはまります。

小さな遅れでも積み重なると量が多くなり、既存のメンバーでカバーしきれず追加人員が必要になることもあります。そうなると、追加人員に目的や要件を正しく認識させることに再び時間がかかってしまいます。時間がかかるからとここを怠って作業を進めてしまうと、誤認が増え修正が多発し、さらに作業が遅れる悪循環が起きることもあります。

実際の開発費用・期間をまとめた資料を無料で差し上げます。資料請求はこちら>>

リスクの対策方法は？

システム開発で起こりうるリスクを紹介しました。これらのリスクは対策をとることで発生確率をグッと減らすことができます。

リスクの対策方法は以下の通りです。

繰り返しになりますが、リスクはそれぞれ密接に関わっています。「認識的リスクにはこの対策」とピンポイントで対策するのではなく、リスクをまんべんなく回避できる対策を行い、全てのリスク発生確率が減らせるように対策することが大切です。

見える化をする

あらゆるものを明文化し、見える化を行いましょう。何が正しい情報なのか、どの情報が最新か、プロジェクトのメンバーが一目で理解できるようにしておきましょう。

見える化しておくとよいもの

ルール
役割分担
トラブル時の責任の所在
仕様書
リスク管理表
経営戦略
業務モデル……など

システムを作る目的、ゴールを見失わないようにすることもポイントです。戦略マップや業務モデルなどを地図代わりに、メンバー全員がこれまで通過したポイントが合っているか、正しい方向を向いているか都度確認しましょう。

綿密にコミュニケーションをとる

見積もり段階から双方の認識をすり合わせることで、見積もり金額やスケジュールの認識ずれを減らすことができます。定期的にコミュニケーションをとることで、誤認も起こりにくくなります。もしも誤認が発覚した際も、なぜそうなったのか原因を考える機会を設けて、問題の本質をあぶり出すようにしましょう。

アクシアでは、チーム内で気づいた時に声を上げるようにする習慣づくりと、エンジニアもお客様とのミーティングに参加してコミュニケーションをとり、リスクの軽減をはかっています。

システム検証を行う

開発段階で局面ごとに受注側がシステム検証（テスト）を行い、バグや問題点を洗い出します。

運用前のテストでは、発注側にも積極的にシステム検証を行っていただきます。仕様通りに出来上がっているかのチェックはもちろん、スムーズに運用をまわすための予行練習も兼ねています。また、運用前に不具合を発見して修正できるように、思いつく限りの業務の全ケースをテストしましょう。

また、要件定義前にも1つ1つの要件について実現可能かシステム検証を行い、早い段階で実現可能かを確認しておくことが重要です。この段階で、できないものはなぜできないのか（費用、時間、技術）原因を明確にしておくことで、リスクを軽減することができます。

最小限で開発を始める

せっかくシステム開発をするならば、欲しい機能を全部実装してもらいたいと思うかもしれません。

しかし、初期開発では「実装する必要のあるもの」に限定して、最小限で開発するように推奨しています。

成功のコツは「実装する必要のあるもの（無いと業務が行えない）」と「実装した方が良いもの（あったら便利だが無くても業務は行える）」は分けて考えることです。実装した方が良いものまでターゲットにしてしまうと、延々とやりたいことが出てきていつまで経ってもシステムを運用開始できないということが頻繁に起きます。

こうなると予算と時間だけ延々と消費してしまうことになるので、システムで何をやるのか（目的）を明確にすることはリスクを最小にするためにも重要です。

開発会社任せにしない

システム開発の進行は開発側に丸投げするのではなく、発注側も組織全体でシステムを受け入れる体制になっていることが重要です。発注側も積極的にシステム開発に関わるように努めていただくとスムーズに開発が進みます。

希望を積極的に伝えたり、データを整理してからシステム開発会社に渡したりなど、とても助かります。

社内には現行業務をかたくなに変えたがらない人もいるので、新システムの操作に対応できるよう説明会や研修の時間を設けておくとよいかと思います。

余裕を持ったスケジュールと予算を組む

「未知のリスク」対策として有効です。開発メンバーの欠員やシステムの不具合、遅延や仕様変更など、見積もり段階では想定できなかった事象が起きることもあります。

トラブルを想定して、余裕のある計画を立てることが大切です。

開発会社選びも重要なポイント

リスクを減らすために、信頼できる会社を探すことも重要です。

責任を持って対応してくれそうか
予算内で解決したい課題が解決できるか
プロジェクト進行は、自社の状況に合った形で満足できる内容で進行してもらえるか

また、いくつか会社をピックアップして相見積もりを取ることもポイントです。

会社選びのポイントは、以下の記事で詳しく解説しています。

実際の開発費用・期間をまとめた資料を無料で差し上げます。資料請求はこちら>>

リスク回避するためのポイント

リスク対策の一つとして、見える化を行うとよい、というお話をしました。リスクを洗い出し、管理表やチェックリストを作成すると誤認や抜け漏れが減るのでおすすめです。リスク全体を客観的に把握でき、対策することができます。

ここでは、リスクを洗い出して見える化したあと、どのようにすればよいのかをPMBOK※のリスクマネジメントに沿って解説していきます。

※PMBOK（ピンボック）…PMI（プロジェクトマネジメント協会）が発行しているガイドブック。プロジェクト管理に関する知識を体系的にまとめたもので、プロジェクトマネジメントの世界標準となっている。

リスク特定

リスク（まだ起こっていないが起こる確率が高い事象）を洗い出し、一覧形式で記述します。

リスク分析

リスクの重要度・優先度のランク分けや数値化を行い評価します。定性的、定量的に評価することがポイントです。

定性的リスク分析
……リスクの発生確率や影響度を考え、対処するリスクの優先順位づけを行います。

定量的リスク分析
……リスクが顕在化した時の影響を金額や必要な期間などで数値化します。

実際の開発費用・期間をまとめた資料を無料で差し上げます。資料請求はこちら>>

リスク対応計画

一覧で出したリスクの対応方法をそれぞれ挙げて記述します。

リスクコントロール

特定したリスクが発生していないか、新たなリスクが発生していないか監視し、変化があった場合は対応策を検討します。

リスクのチェックリスト

システム開発のリスク管理については、IPAが発行している「ITプロジェクトのリスク予防への実践的アプローチ」に事細かにリスクとなりうる事象と対策方法が書いてあります。

しかし、全91ページと大ボリュームのため、ここでは特記事項をかいつまんで解説していきます。

主プロセス

要件定義・設計・実装などのメインプロセスのチェックリストです。チェックがつかない項目はリスクがないか注視していきましょう。

□システム化の目的が明確か？具体的に文書化されているか
□目的が複数ある場合、優先度が明確か？具体的に文書化されているか
□仕様が膨らんだ場合、誰がどのような基準で対応判断するか
□発注側/受注側の責任分担、役割分担が明確になっているか
□業務知識のある人がプロジェクトにいるか
□現行システムのドキュメントが存在するか、最新の状態か
□現行システムの要件定義に関わったメンバーがいるか
□現行システムから継承する機能、修正する機能、新たに追加する機能が明確になっているか
□要件定義書に「現行どおり」という記載がないか（あるならば認識相違が起こりやすい箇所のため、該当機能の調査が必要）
□パッケージ適用する際、検討・レビューは十分行ったか
　（必要な機能要件、非機能要件、維持保守要件などは満たしているか、承認者へ承認や合意が取れているか）
□性能の検討は十分か
　（性能見積り根拠はあるか、性能目標は明文化されているか）
□可用性の検討は十分か
　（方針、稼働率の見積もり、計画が明確にできているか、リソース確保できているか）
□運用に向けての制約条件が明確か
　（システム運用の手順書が作成されているか）
　（障害発生時の代替・回復方法の手順書が用意されているか）
□各ステークホルダーの合意形成法が明確か、各ステークホルダーのキーマンや各担当者を把握できているか

支援・管理プロセス

プロジェクトが円滑に進むように気をつけたいチェックリストです。プロジェクトの進行と、システムの品質を左右します。

□ドキュメントの変更管理をしているか
□要件の変更やソース修正を行った場合、ドキュメントにも反映しているか
□仕様変更を一覧化しているか
□仕様変更の承認は確実に記録しているか
□仕様変更の影響範囲や詳細内容は可視化されているか
□要件定義書をもとに現場ユーザーやステークホルダーが参加した業務のウォークスルーを実施することを計画に入れているか
□テスト項目は業務のパターンを網羅しているか
□非機能要求が文書化されているか
□要求に優先順位がついているか、優先順位はユーザーに確認しているか
□現物の画面や帳簿とドキュメントを比較して相違がないか
□エンドユーザーがUIの確認を行っているか
□外部システムとの全ての入出力の仕様が明確か
□適切なレビュアーがいるか

組織的プロセス

プロジェクト単体ではなく、組織全体として気をつけたいチェックリストです。組織的リスクの具体的な回避策が網羅されています。

□経営層によるプロジェクト運営の関与が十分か
□経営層の承認を得ているか、経営層の考え方（位置付け）が文書化されているか
□要件の変更時に影響に応じて責任者の承認を得るルールが存在するか
□パッケージを導入する場合、採用方針、カスタマイズに関する制約条件を公的文書に記載しているか
□力のある人による不合理な決定がされていないか、不合理な決定を止める仕組みはあるか
□プロジェクトの意思決定機関が設置されているか、意思決定機関が決定権限をもっているか
□議事録は作成しているか
□効果的なコミュニケーションができるツールやルールを構築しているか
□直接対話する機会を用意しているか
□長期間放置されている課題がないか
□システム用語など、意味が通じない言葉はお互いにないか
□DB項目定義書は作成されているか
□現行業務の分析を十分に行ったか、業務フローは明確か
□関連業務、新業務の利用イメージは明確か
□新業務のスコープや機能定義を把握しているか

実際の開発費用・期間をまとめた資料を無料で差し上げます。資料請求はこちら>>