【システム開発】要件定義における7つのジレンマと解決策

前回投稿した要件定義書に書いてはいけない危険な表現99にて、「要件定義書にこんな表現がかかれていたらNGです」ということを解説しました。

その解説において、誤ったことは述べていませんが「NG表現を全て正しい表現にするということを実践してしまうと、また別の問題も起こるというジレンマがある」ということで、説明を終えていました。

今回は、要件定義における7つのジレンマについて解説をします。

要件定義を行う上で多くの方が直面する問題だと思います。各ジレンマの解決策も提示しますので、ぜひ最後までご覧ください。

※このコラムの内容は動画で公開しています。Youtube版はこちらをご覧ください。




さて、ジレンマとは？
これは専門用語ではありませんのでご存知だとは思いますが、改めて調べてみますと次の内容となります。

究極の選択というには大げさかもしれませんが、担当者としてはそのような気持ちにさせられるような問題でもあります。

では、どのようなジレンマがあるのか。個別に解説してまいります。

①定量化のジレンマ

要件を定量化することはとても重要です。逆に定量化しなければ、開発者が自分の都合のいいように解釈をしてしまい、発注者が求めるものと相違があるという結果になることが少なくないからです。
　
例えば「ユーザーが直感的に理解できるUI」という定性的な要件も、「初めてシステムを使用するユーザーの80%以上が、5分以内に会員登録を説明なしで完了できること。」のように定義すれば数値化できるということは前回説明しました。

しかしここで、その数値が企画段階で具体的に出ているならまだしも、そうでない場合、妥当な数値を引き出すのが悩ましいところです。
先の例だと「80％以上、5分以内」としたのですが、「70%ならダメ？7分以内でもいいのでは」という考え方もあるわけです。さすがに、10%～20%は直感的に理解したと言えないと判断できるものの、何％が妥当かに対して明確な答えはありません。また、数字を上げれば上げるほど、実現のハードルも同時に上がってしまうのは容易に想像できるでしょう。

数値をどう設定するか、定量化のジレンマがここにあります。
解決策としては、以下のものが考えられます。

②コストのジレンマ

高い目標設定は望ましいのですが、一方でコストも比例して高くなることが多いです。「同時に100人のアクセスがあっても、クリックして1秒以内に画面が表示される」ということや、「24時間365日停止しないシステム」というものは、要件として書くのは易しいものの、それを実現するためには、コストが高額となります。

特に発注者からしてみると、要件定義の時点でどのくらいの目標設定がどれくらいの見積金額に跳ね返ってくるのか想像ができないため、なおさらでしょう。　

目標をどの程度に設定するのか、コストのジレンマがここにあります。
解決策としては、以下のものが考えられます。

③検証のジレンマ

定義した要件は検証が可能でなければなりません。要件を検証する手段や方法が不明確な場合、その要件が実際に達成されているかどうかを判断することができません。先の定量化のジレンマで、「初めてシステムを使用するユーザーの80%以上が、5分以内に会員登録を説明なしで完了できること」と決定した場合、システムの完成後、ユーザーと共にその確認テストを実施する必要があります。80％の判定においては、「10人のユーザーで十分なのか？あるいは100人必要なのか？その検証は同時に行うのか？何回かに分けて行うのか？場所はどうするのか？目の前で？リモートで？」といったように、検証のための具体的な評価基準やテスト方法が必要となるのです。

検証にも時間とコストがかかるという、検証のジレンマがここにあります。
解決策としては、以下のものが考えられます。

ここまでの3つのジレンマは、前回投稿した「要件定義書にこんな表現がかかれていたらNGです」ということに関わるジレンマを解説しました。

この他にも要件定義におけるジレンマがありますので、続けてご紹介します。

④システム化の範囲のジレンマ

とくに新規事業向けシステム開発の要件定義の準備段階では、「範囲にとらわれることなく、自由に要件を出すべき」ということを述べていました。

新規事業向け開発でないとしても、関係者が増え、みんなが真剣に考えれば考えるほど、要件の範囲が広がってきます。要件の範囲が広がるとプロジェクトは複雑になりますし、当然ながら予算・スケジュールへの影響を及ぼすようになります。

一方で範囲を狭めすぎることにより、必要な要件が漏れてしまい、使えないシステムが出来上がってしまうというリスクも秘めています。

広げ過ぎず、狭めすぎない範囲を決めるという、システム化の範囲のジレンマがここにあります。
解決策としては、以下のものが考えられます。

⑤ステークホルダーのジレンマ

あちらを立てればこちらが立たず。声の大きい方に引きずられる。上の人の言うことに逆らえない。簡単に言うと、そう言うことです。

経営層としては、コスト削減を目的としたシステム導入でありながら、現場は使い勝手向上を強く求めてくる。システム改善により、データの管理責任が別部門になる。そうすると、ある部門は省力化されますが、別の部門の仕事が増えるということもあります。

要件定義を行う部門があらゆる権限を持っていることは少ないため、関係者間をいかに調整するのかということが大きな課題となります。

時として、関係者全てが納得できる要件にならないという、ステークホルダーのジレンマがここにあります。
解決策としては、以下のものが考えられます。

⑥技術的判断のジレンマ

とりわけ最新の技術。今ならAIを想像してください。その技術を前提とした要件は、実現の可能性が読み切れない場合があります。

大手企業やスタートアップが実現している技術が簡単に自社の要件に応用できるのかどうかということは、開発を委託するITベンダーの技術に依存することもありますし、そもそも応用ができない技術であるかもしれません。しかし、発注者側に相当な知識がない限りそのような判断は困難ですから、そこに理想と現実のギャップが生じます。

技術的な実現性が判断できないという、技術的判断のジレンマがここにあります。
解決策としては、以下のものが考えられます。

⑦セキュリティと利便性のジレンマ

今や日常業務においてもセキュリティを切り離して考えることはできません。ましてやシステム開発においてセキュリティは重要なテーマのひとつです。

一方で、セキュリティ対策を強固にすればするほど利便性が低くなり、システムを利用する現場の賛同を得ることが困難になります。例えば極端な話し、社内のパソコンをインターネットから切り離してしまうとどれだけ不便になるかは容易に想像できるでしょう。複雑なパスワードポリシーや2段階認証はセキュリティを向上させますが、複雑で使いづらいと感じる人も少なくありません。

利便性を著しく損なうことなくセキュリティ対策をどこまでにするかという、セキュリティと利便性のジレンマがここにあります。
解決策としては、以下のものが考えられます。

まとめ

今回は、要件定義における7つのジレンマについて解説しました。

いずれのジレンマも解決策を提示していますが、それを絶対的なものとするのではなく、自社のシステム開発における背景・予算・期間などと照らし合わせた上で、妥当な落としどころを見つけてください。