システム開発プロジェクトにおいて、まず最初に行う工程が要件定義である。要件を定義するわけであるが、ざっくり言うと、「何を開発するのか」を決めること、である。対照的に、設計工程では「どうやって実現するのか」を決めることも合わせて覚えておきたい。
要件定義は、作るものを決める工程であるが、それはお客さんからの要求を元に作る。だからこそ、システム開発の中では最も重要な工程だと言われている。だって、「作るもの」を間違えたら、どうやって作ろうがどれだけ美しく作ろうが全く価値のないものになるからだ。
例えば、テレビが欲しい人に対して、カメラを売ったって何の価値もない。それがいかに精密に作られていたとしても、だ。これから開発プロジェクトを進めるチームメンバ・ステークホルダーの仕事を無駄にしないためにも要件定義は確実に抑えたい。
ただ、一方で要件定義というのは非常に難易度の高い仕事でもある。難しい所以の一つが、お客さん自体が何がほしいのかを把握していない、ということである。これはシステム開発に限らずだけれど、いかに潜在的なニーズや課題意識を引き出せるのかがポイントだと言われる。
先ほどの例で言えば、テレビが欲しい人に対してテレビを提供しても満足してもらえない場合があるのだ。なぜなら、お客さんは、「何かを達成するための手段としてのテレビ」が欲しいのであって、本当に欲しいものはその「何か」であるからだ。その「何か」を提供するために必ずしもテレビが最適だとは限らない。むしろそうではないことの方が多いかもしれない。
もっとも厄介なのは、特に受注型であるSIの場合は、要件定義がミスっていても開発プロジェクトとしては成功、と判断されてしまうところだ。お客さんがすごく満足したわけでもなく、売上増加に貢献できたわけでもないが、お客さんからお金をもらってシステムを納品できればプロジェクトとしては御の字になってしまうという構造的な問題がある。
すると、ホンモノの要件定義を理解することもなく、「要件定義とはこういうものだ」みたいな誤った認識がまかり通ることになる。
話を戻すけれど、要件定義の難しさはお客さんとのコミュニケーション・ヒアリングによって答えを導き出していくことにあるのでは？と考えた人もいるかもしれないけど、実は企画型案件の場合でも同じ、もしくはそれ以上の難しさがあったりする。
企画型案件とは、ある課題に対してこういうことをしたい、そしてそれを実現するためのシステム開発のことである。お客さんの要求を元にシステムを作るのではなく、自分たちの理想を元にシステムを作る。だから、内部だけで進めることができるので一見すると簡単そうに見える。
しかし、「自分たちがやりたいことは何なのか？」を本当の意味で突き詰めて考えていくことに難しさがある。
一つは、理想を明文化・言語化するプロセスは難しいということ。お客さんが自分たちの欲しいものがわかっていないように、私たちも自分たちが欲しいものが実ははっきりとわかっているわけではない、ということだ。
特に、それが組織としての理想である場合、各々が考える理想像は微妙に食い違っていたりしてそれらの方向を合わせるのも一苦労である。また、変に理想を追い求めすぎたりして、青い鳥症候群のような、あるはずのない構想だけを描き、結果絵に書いた餅になる可能性も孕んでいる。
二つ目は、先ほどの話と少し逆で、地に足のついた発想をしてしまいがちであるということだ。どういうことかというと、つまり設計や実装のことをわかっているが故に、技術的な制約から理想を逆算して考えてしまうのである。まず、「やりたいこと」を考えてから「できるのかできないのか」を判断・検討すべきなのだが、頭の中で「できない」と判断してしまうと、そもそも「やりたいこと」として挙げられない。
目的から考えるべきなのに、まずツールや製品ありきで、あるいにニーズから考えるべきところをシーズありきで考えてしまう、というのはよくある話なのだろう。今の私たちもそんな感じで割と要件定義にハマってしまっている気がする。これらの点にはぜひご注意いただきたい。
