システム開発のリスクは技術的要因だけでない!システム構築に潜む3つのリスクとは何か?

パソコンの前で頭を抱える女性

更新日:2017年09月26日 | 公開日:2016年08月14日

システム構築のリスクというと真っ先に思い浮かべるのが、システムが動かなかった…、システムが止まった…などの「技術的リスク」かもしれません。
しかし、よほどの大きな設計ミスがない限りは、そうした不具合はバグのひとつとして、システム納品時までにはなくなっているか、万一納品後に発覚しても開発会社が責任をもってすぐに直してくれます。
むしろシステム構築で最も注意しなければいけないリスクは他にあります。

プロジェクトが途中崩壊するようなリスクとはどんなリスクなのか把握しよう

オフィス内でパソコンを操作する女性

プロジェクトが途中崩壊するようなリスクというと、何か恐ろしい巨大なリスクを想像してしまいますが、その実態は「確認漏れリスク」「責任の所在リスク」に集約されます。
まず、それぞれどんなリスクなのか見てみましょう。

確認漏れリスク

まず「確認漏れリスク」ですが、これはエンジニアの技術的範疇である場合には、それほど傷は大きくなりません。
その多くはプログラマのコーディングレベルで多少のトラブルはあるにせよ、システム開発につきもののバグの処理として、すぐに解消されていきます。

恐ろしい「確認漏れリスク」の典型的例は、むしろ発注側に生じます。
最初の要求仕様の打ち合わせから最終確定するときに、本当にこのシステムで通常の業務が改善できるのか、何か機能的な漏れはないのかというところを徹底して確認するのが基本中の基本ですが、諸般の事情によって見切り発車的にプロジェクトがスタートせざるをえない時などにプロジェクトが空中分解する程の危険性を伴った「確認漏れリスク」が生じます。

最初に試作品を作ってプロジェクト開発をすすめる「プロトタイプモデル開発」において、充分に試作品を確認することを怠ったり、途中でテストをはさみながら結果を次の工程にフィードバックしていく「アジャイル型開発」でいい加減に確認作業をしてしまうと、あとから取り返しの付かない状況が起こります。

責任の所在リスク

システム開発のプロジェクトは、発注者が開発者に仕事を丸投げしておしまい、というわけにはいきません。
それぞれのフェースで発注者、開発者が負うべき責任を最初に明確化しておく必要があります。

【責任分担例】

(1)発注側開発側共同作業の例:要件定義作業、テスト
(2)開発企業作業の例:開発対象機能の設計、開発対象機能の開発、進捗管理
(3)発注者の作業の例:必要情報の提供、ベンダーの求めに応じた意思決定、プロジェクト実施場所の設置及び管理、納品成果物の検査

上記の例ですと、(1)要件定義作業、テストは一緒に責任を持つ共同作業ですし、(2)にあるように進捗管理は開発側の責任ですから、納期の遅れなどは基本的に開発者に責任があります。
また、(3)必要情報の提供、ベンダーの求めに応じた意思決定はクライアント側の責任ですので、必要な情報提供が不十分でプロジェクトが進まない場合の責任は発注側にあります。

こうした分担体制が曖昧のままプロジェクトを進めると「責任の所在リスク」がある時点で一気に表面化します
「納期が遅れたのは、そっちの責任でしょ?」「いや、最初に十分な資料がなかったからこうなったんです」という水掛け論で済んでいる場合はまだ解決の方法があるにしても、泥沼の訴訟問題に発展してしまうケース(例:「日本IBMはなぜスルガ銀行に負けたのか」)もありますので、しっかりと「責任の所在リスク」を認識して詳細を詰める必要があります。

どうすれば「確認漏れリスク」「責任の所在リスク」に対処できるか知っておこう

ノートパソコンと筆記用具

「確認漏れリスク」への対処方法

「確認漏れリスク」については、基本的なことではありますが些細な事であっても必ず確認をして文書に残しておくことが鉄則です。
システム構築の初期においては、「目的を確認する」「要件を確認する」「要求事項を確認する」などが必須ポイントとなりますし、プロジェクトがスタートしてからは「伝えるべき相手を確認する」「進捗状況を確認する」「問題の本質を確認する」などが必須となります。

プロジェクト日誌を必ず用意して上記のポイントを記録し、何か危ない兆候があったらすぐに関係者に連絡を取るようにしましょう。


「責任の所在リスク」への対処方法

責任の所在のリスクを最小限にするには、まず何といっても最初にきちんとした分担表を作って、それを契約書に反映させることです。

責任の所在を明確化するためには、「作業範囲」「責任分担」「納品成果物」「検査方法」「保証」「訴訟時の解決の方法」などを取り決めた「基本契約書」をきちんと締結し、さらに個別の作業内容を具体的に記した「個別契約書」を交わすことが大切です。

先ほど例に上げた裁判の例では、スルガ銀行が日本IBMに発注した銀行システムの開発が途中で頓挫してしまいました。
双方の言い分は下記になります。

● 発注側・スルガ銀行側の言い分
ベンダーであるIBMが果たすべき義務、つまり高度な専門的知識と経験に基づいて開発作業をマネジメントしなければならない「プロジェクトマネジメント義務」の違反が原因と主張。

● 開発側・日本IBM側の言い分
システム開発はあくまでもベンダーとユーザーの共同作業であり、ユーザーもまた開発に必要な協力をすべきという「協力義務」の違反が原因と主張。

最高裁判所は2015年7月8日、両社の上告を棄却する決定を下して、日本IBMに約42億円の賠償を命じた東京高等裁判所の判決が確定しています。

これなどは典型的な「責任の所在リスク」の顕在化です。
こうした教訓を踏まえて、個別契約書できちんとした詳細な分担表を作ることをぜひ行ってください。

なお「基本契約書」と「個別契約書」の作り方などについては「システム開発の契約書締結で外せないポイントはココだ!「基本契約」と「個別契約」の違いとは何か」を参考にしてみてください。

【まとめ】リスクは整理すれば怖くない!

いかがでしたでしょうか。
システム構築におけるリスクは多く分けて「技術的リスク」「確認漏れリスク」「責任の所在リスク」とありますが、最初に目が行きがちな「技術的リスク」はバグの処理として開発側がなんとかできるレベルのものがほとんどです。

むしろプロジェクトそのものが空中分解したり、最悪のケースでは巨額の訴訟問題に発展したりするケースもある「確認漏れリスク」「責任の所在リスク」などについてその危険性の認識を深め、これらのリスクの顕在化を防ぐ対処を早め早めに打っておくことが大切です。

日本最大級の発注業者比較サイト「アイミツ」ではシステム構築に関する専門知識を持ったコンシェルジュが、信頼のおける業者を完全無料で紹介することができます。

システム開発には大きな時間とコストを要するものです。
納得のできるパートナーを選ぶことで、それぞれのリスクを防いでシステム開発をスムーズに進行できるようにしていきましょう。

いま知りたいこと
コンシェルジュが解決します!

コンシェルジュサービスは
3万社以上が利用している無料の相談サービスです。

コンシェルジュ