ソフトウェア要件の優先度

ソフトウェア開発を進めていく中で、お客さまの要件には必ず"優先度"が存在していることはご存知かと思います。エンジニアから見た場合、普通に上流・超上流の工程を進めるにあたって、すべてを同じ『ニーズ』『要求事項』と言う扱いにしてしまって、おそらくは優先度をあまり意識しないことが多いのではないでしょうか。

特に、

　・スケジュールに影響が出そう
　・予算が都合つかない

といった問題でも出ない限り、まず優先度を見ません。

なぜか。

それは、スケジュールや予算の枠に収まってしまうからです。「どーせやるのは一緒なんだから、別に優先度とかつけなくていいじゃん」と思ってしまうのです。

しかし、元来は何か問題が起きてから検討していたのでは間に合いません。問題と言うのは、限られた期限内に解決しないと、大抵の場合は爆発します。にも拘らず、そこから検討を始めていたのでは遅いのです。

"要件の対応優先度"と言うのは、予算・期間・技術などの理由によって、要件を不対応とする際の指標として、要件を定義する際にはあらかじめ決めておくべきものです。

多くの場合、各要件にはそれぞれお客さまの中で推進者が決まっています。

優先度は、その推進者の職位や声の大きさによって定められることが一般的です。そのため、要件定義においては、優先度を上げた要件が経営的な観点からも重要であるかのように見せかけられるかが、定義した者の将来を左右すると言っても過言ではないでしょう。

システムやサービスの導入では、予算や期間あるいは技術的な理由などによって、やむを得ず要件を落とさざるを得ないことがあります。

そのような時のため、プロジェクトマネジメントでは、機能要件、非機能要件を決める際に、それらが必須のものであるか、できればあった方が良い程度のものかを検討し、実現の優先順位をつけておくことが必要になります。

重要度と緊急度で区分けするマトリクスはちまたでもよく見かけることがあると思います。何かしらの決断を強いられた時、重要なのはパッとこのイメージが頭の中で思い浮かべられるかどうかによって決まります。

これ以外の評価軸を持っている人…たとえば、「あの人に嫌われるかもしれない」とか「周りの人がなんて言うか心配」なんて他人の顔色をうかがってばかりの人なんかが、一般的に決断力が無く優柔不断なのはそのためです。

マトリクスの粒度が粗いようであれば、こうした細分化を進めていけば、難なく決断することが可能になるでしょう。

そして、優先順位のつけ方には次のような鉄則があります。

鉄則１　導入の目的・方針に照らして決める

要件の優先度は、当然のことながら利用者にとっての『システムやサービス導入の目的』に照らして決めていくのが基本です。これを前提に話が進められないようであれば、そもそも要件定義ができるレベルのエンジニアではないと言えます。一つひとつ挙がる要件が、

　・目的に対して必須であるか
　・なくても実現できるか
　・代替手段があるか

などを考慮して、必須か否かを判断していくわけです。

たとえば、物品購入システムの場合、もしも導入の目的が「お客さまのニーズを満たす」というだけでなく

　「お客さまの期待を超える快適で豊かな生活の実現を支援する」

ために提案を行うものであるとするならば、

　関連する他商品を紹介する機能

が必須となることでしょう。

あるいは、

　「従来、Webでの買い物をしてこなかったシニア世代にも
　　ネット通販の楽しさを実感してもらう」

と言う目的であれば、さして楽しくもないWeb決済機能は必須とせず、銀行振込と言う代替手段を取ってもらってもいいと言うことになるわけです。また、シニア世代の中にはクレジットカードを持っていない人だっているかもしれません。そういった世代に利用してもらう…と言うだけでも、カード決済以外の方法を活用することは、重要なポイントとなります。

重要なことは、常に『目的』に沿っているかどうかという観点です。これを無視して決定して良い懸案や課題というものは一切存在しません。

鉄則２　経営的な視点を忘れない

要件の優先度を決めるときに考慮する事項には、導入の目的との関連以外に、下記のような経営的な視点にたった事項があります。

　・その要件を満たさないと、法令や規程その他各種の約束事を守れないか
　・その要件を満たさないと、ユーザーの対外的な信用、信頼を損なうか
　・その要件を満たさないと、ユーザー企業や組織内の規則類を守れないか
　・その要件は、システムやサービス導入の方針に沿ったものか
　・その要件を導入するメリット・デメリットはどの程度存在するか

いずれも、単にシステムやサービス導入のメリット・デメリットに関わるだけでなく、場合によってユーザー企業の業績や地位を左右するものになりますので、必ず考慮することが必要な項目です。

こうした分析や優先度付けを行わないまま、見積り、業務フローなどを作って要求事項を抽出するだけの作業は、本来であればプロジェクトマネージャーやソフトウェアアーキテクトのする仕事ではありません。

これでは、単にエンジニアとして、「何を作りたいのか」聞いて、「どう作るのか」考えているだけの、ただの製造作業と変わりません。クリエイティブにお客さまが本当に求めている『システム』を構築したいのであれば、

　作る

ことよりも

　実現する

ことに重きを置いて進めていくと良いでしょう。あまり「作る」ことにばかりこだわり続けていると、お客さまの言葉は耳に入らなくなってしまうものです。

お客さまに「何を作ってほしいのか」なんて聞いても、ＩＴリテラシーが乏しい場合、明確な回答は返ってきません。それは、エンジニアとして上から目線すぎるのです。そうでないお客さまにとっては、最も付き合いにくい相手と言えるでしょう。

超上流工程から参画する責任と自負があるのであれば、お客さま側の要件の推進者の１人となったつもりで、

　システムやサービスの是非

を考える視点を持ちましょう。