シェア
ツイート
ブックマーク私たちの身の回りには多くのソフトウェアやアプリケーションが存在し、それらのシステムの不具合がニュースになることもあります。
一体なぜ、大きく取り上げられるような不具合が起こるのでしょうか。
原因としては、単なるヒューマンエラーやシステム開発時の人為的ミスのような場合もあります。しかし、実は根本の原因として、システム開発のスタート時点で前提に誤りがあり、そのまま開発が進められているケースも多くあるのです。
今回はシステム不具合の原因となる「要求定義」の失敗と、それが引き起こすトラブルについてご紹介します。また、同じ失敗を起こさないためのポイントについても解説していきます。
システム不具合を防ぐ要求定義の重要性を確認していきましょう。
- もくじ
1．システム不具合の多くは「要求定義の失敗」が原因
システムの不具合の原因として「要求定義の失敗」が多く挙げられます。では、そもそも要求定義とはどのようなものなのでしょうか。
この章では、要求定義とは何か、要求定義がシステム開発にどのような影響を与えるのかについて解説していきます。
要求定義とは？
そもそも「要求定義」とはシステム開発の最初の段階で、利用者がそのシステムに何を求めているのかを明確にしていく作業のことを言います。
要求定義では、ソフトウェアやシステムの開発を行なう開発者が、クライアント（システムの発注元）の要望を基に、開発するシステムの概要を具体化していきます。
つまり、クライアントは自分たちの作りたいシステムのイメージを伝え、システム開発者はそのイメージを形づくるために必要な機能や性能を具体的に定義していく必要があるのです。
要求定義の失敗がシステム不具合につながる理由
システム開発は、以下のような流れで作業手順が進んでいきます。
- 要求定義 ... クライアントの要望をシステムに求める仕様を定義する
- 基本設計 ... 要求定義を基にシステムの基本を設計する
- 詳細設計 ... 基本設計を基に詳細までシステムを設計する
- 実装 ... 詳細設計を基に実際にシステムを開発する
- テスト ... 開発したシステムが実際に仕様通りに稼働するかをテストする
- 稼働開始 ... テストが無事完了した段階で本番運用の稼働を開始する
要求定義はシステム開発の流れの一番源流に位置する作業です。
そのため、この段階で失敗するということは、後の工程で挽回することがほぼ不可能になると言えます。
建物に例えるならば、土台の構築段階で失敗したまま、建物を建てているのと同じことです。
要求定義の段階での失敗が、後々まで尾を引き、さまざまな不具合を誘発するケースは少なくありません。
要求定義で失敗すると、システム開発はその段階ですでに失敗していると言えるのです。
2．要求定義に失敗すると起こるリスク
要求定義の段階で失敗すると、一体何が起こるのでしょうか。
さまざまなケースが考えられますが、中でも恐ろしいのが「セキュリティ面の失敗」です。
セキュリティの部分で失敗すると、外部からの不正アクセスを許してしまい、機密情報や顧客情報の漏洩などの実害が発生します。
最悪の場合、システムの基幹部分への侵入を許し、システム内にバックドア（情報の抜け穴）を作られて、そこから常に情報が抜かれ続けてしまうという事態も起こりかねません。
システムそのものを破壊されるという事例も多数発生しています。
また、開発しているシステムのセキュリティに問題がなかったとしても、分かりにくい仕様は内部情報を漏洩させてしまうなどのセキュリティ事故を発生させてしまうこともあります。
これは例えるなら、滑りやすい床で滑って転んでしまうようなものです。そのような場合、そもそも転んだ人が不注意だと言い切れるでしょうか。
常識的に考えれば滑りやすい床にしたことも原因のひとつなのです。
3．クライアントとシステム開発者は運命共同体
システムには必ずユーザーが存在し、要求定義を失敗してしまうと、ユーザーに多大な損害を与えてしまうケースもあります。
例えば、ネットバンキングのようなシステムの場合、セキュリティに脆弱性があればユーザーである顧客の情報が抜き取られたり、場合によっては預金データが改ざんされ、ユーザーの財産が失われたりもします。
そのような重大な事故が起こってしまった場合、クライアントである企業は社会的な信用を失ってしまいます。
また、このようなケースでは批判の矛先はクライアントばかりではなく、その要求通りにシステムを開発したシステム開発者にも向けられます。
つまり、クライアントとシステム開発者は運命共同体と言えます。
4．要求定義で失敗しないためのポイント
ここからは、要求定義の失敗を起こさないためのポイントについて解説します。
機能の必要・不要を整理する
クライアントの要求を何とか形としてまとめるのが、システム開発者の仕事です。
そのため、まずは本当に必要な機能とそうでない機能の整理から始めなくてはなりません。
システムの根本にかかわる"本当に必要な機能"と"単なる思いつきの機能"の区別をしておくことが重要です。
また、整理した結果、思いつきの機能と、重要な機能の間に矛盾が生じることもあります。
そうした場合、当然のことながら後者を優先しなくてはならず、システム開発者はその点に関してクライアントの理解を得る必要があります。
クライアントに必要な機能を提案する
クライアントからの要求を整理するだけでなく、要求の中にない必要な機能を提案することも重要になります。
システム開発には「常識」というものが存在します。
例えば、電子決済のような高度なセキュリティを要求させるシステムを開発する際、現在は二段階認証などの厳重なセキュリティ対策を施すことは常識といえます。
システム開発者は、仮にクライアントの要求の中にそのような機能がなかったとしても、必要であれば提案することが大切です。
時にはクライアントの要求を退けることも必要
要求定義の失敗は、作業を行なうシステムエンジニアの力量不足という可能性もありますが、クライアントの認識不足によって起こるケースも多いです。
近年は社会全体にICTリテラシーが浸透してきましたが、十分ではありません。
システム開発をしようとするクライアント側の要求が、あまりにも「ざっくり」としすぎているケースは大いに存在します。
システムにおける意識が不足しているクライアントの場合、「ああいうことがしたい」「こういう風にしてほしい」と、さまざまな要求をシステム開発者に要求します。
しかし、完成したシステムに関するイメージがないので、ときに矛盾した要求をする場合があります。
クライアントの要求に矛盾を感じた場合は、要求を退けることも必要です。
要求を退けたとしても「こちらがお金を出すのだから、その通りに作ってくれ」と言うクライアントもなかには存在するでしょう。
しかし、クライアントが要求したからといって鵜呑みにし、そのまま実装することはとても危険なのです。
まとめ
要求定義とは一方的に要求を聞くことではありません。真に信頼できるシステムを構築するためには、そのことをクライアントに理解してもらう必要があります。
そしてそれは要求定義に入ってからでは遅く、実際の要求定義に入る前に、大前提としておくことが重要です。
システム開発者とクライアントの関係は建築会社と施主の関係にも似ています。ただし、いくら顧客が金を出すといっても、違法建築を要求する相手の注文を受けることはできません。
要求定義に気を付けることでシステムの信頼度を高めることができ、「本来なら起こさなくてもいい事故」を起こさなくて済みます。
結果的に完成するシステムの質は高くなり、信頼度の高いシステムを作ることが可能となって、クライアント企業の顧客満足度を高めることにも繋がるのです。
