要求定義と要件定義は重要だけど実は呼び方はどうでもいい！理由

今回は、ソフトウェア開発において「一般的には」重要とされる2つのキーワードについて考えてみます。それが「要件定義」と「要求定義」。とてもよく似た四文字熟語なのと、これらのフェーズ（段階）の間には明確な境界がないため、この2つの概念はよく混同されたり、誤解されがちです。しかしそれは本当に誤解なんでしょうか？ここにも、ローコード・ノーコード開発プラットフォームが関係しているので、一般的な常識とされている考え方に、敢えて反論を交えて解説してみます。

どっちがどっち！？要件定義と要求定義の違いとは？

まずはさらりと、一般的にいわれる、要件定義と要求定義の基本的な意味から確認してみましょう。密接に関係してはいるものの『両者は別物であり、違いを意識することが必要である！』とされています。

要求定義：どんなことを望んでいるか？

要求定義は、まさに、ユーザーが何を「要求」しているのかを定義することです。ユーザーからのニーズや要求を集めて理解するプロセスを指します。そのためには、ユーザーとの密なコミュニケーションが不可欠です。

• ユーザーが何を「要求」しているのかの定義
• ソフトウェアが実現すべき状態や、達成すべき目標を理解する

要件定義：実現するにはどんな機能が必要か？

一方で、要件定義は、ソフトウェアがどのように動作すべきか、具体的に何を実現するべきかを明確に定義する工程です。要求定義で得た情報を基に、具体的な機能や性能、システムが満たすべき「要件」を定義します。

• 機能や性能、システムが満たすべき「要件」の定義
• 目標を達成するために、具体的に何をすべきか機能や操作を明示する

要求定義・要件定義の「定義」なんて、実はもうどうでもいい！？

そんな前述の説明ですが、伏線回収の間も置かず即反論してみます。リープリーパーでは、要求定義・要件定義を敢えて分けたり、呼び分けに過度に注意を払う必要はないと考えます。

誤解のないように明記しておきますが、顧客ニーズを明確にして、それを実現するために具体的にソフトウェアをどう開発するかが重要なことは変わりありません。しかし、そこで重要なのが、要求定義・要件定義とキッチリ呼びわけて考えるかどうかではないのです。結局、人は、自分にとって必要なソフトウェアが何なのかは、実際に動かして使ってみなければわかりません。丁寧なヒアリングを繰り返し、定義や仕様を細かく作り込んだとしても、『やっぱり違った！』『何だかコレじゃないかも…』というのは十分あり得ます。ちなみに、理解を助けるヒントとして英語の表記をチェックしてみると、DefinitionやAnalysis、Specificationという言い回しの違いはあっても、RDD : Requirements Definition Documentでほぼ認知されています。

欧米の企業に比べてシステムの内製化率が低い日本の企業では、外部のSIer（システムインテグレーター）にソフトウェア開発を依頼することが一般的です。この場合、要求定義と要件定義のプロセスもしばしばSIerに委託され、発注者側の企業は単にその結果を確認する役割を担うことも珍しくありません。そのため、一部のSIerさんには反発されるでしょうが、要求と要件でハッキリと定義を分けたがる背景には、自分たちの存在意義を確保したい人たちという存在もあります。また、より上流工程の仕事を得るための、単なる言葉遊び的な使われ方をしているからに過ぎないともいえます。要求定義・要件定義と自身の存在価値を高いままにしておきたい開発現場では、厳しいやり取りが飛び交うこともあるようですが、その様子は、怪しげなビジネスマナーの流布によって、マナー講師のことを「失礼クリエーター」と揶揄する風潮を思い起こさせます。

Excelを使うときに、いちいち要求定義・要件定義する人なんていない！

社要求定義・要件定義にこだわりすぎる滑稽さは、例えるなら、Excelを使って仕事で必要なスプレッドシートを作るときに、いちいち要求・要件の定義をキッチリ決める人はいないのと同じだともいえます。Excelの例えつながりでいえば、『Excel並にできるようになるソフトウェア開発』がローコード・ノーコード開発だともいえるので、これをセットで考えてみましょう。

まずは、いきなりExcelを開いて、自分が扱いたいデータが何なのかを把握します。金額や日付、商品コード、文字列など、ユーザーは無意識にデータモデルを選択しています。セルを操作して入力し、関数を加え、シートを追加。足りない機能は追加し、余分であれば削除し、旧い内容はアップデートを繰り返す。こうやって、自分が必要なファイルを作り上げていきます。最初から、自分の希望が明確になって、仕様がキッチリ決まっているわけではありません。使っていく過程で自分が求めていることに気付いたり、その時々でニーズが変化していくことは、普通にあり得ます。重要なのは、誰かと定義を確認し合うことよりも、自分の手元で自由かつ迅速にカスタマイズできることです。

スタートからいきなり真のニーズに対峙せざるを得ないローコード開発

従来型のスタイルでソフトウェアを開発しようとすると、開発に入るまでにやらなければならないことが山ほどあります。アーキテクチャーやデータベースの設計、サーバーのセットアップ、インフラ環境の整備など、さまざまなタスクに溢れかえります。大変な作業ではありますが、これで時間稼ぎをしておける面もあります。

一方、優れたローコード・ノーコード開発プラットフォームがあれば、ちょっと乱暴な言い方に聞こえるかもしれませんが、いきなりソフトウェアを作り始めることからスタートできます。準備や環境のセットアップや、アーキテクチャーどうするかというプロセスは不要です。スタートが『どんなことを実現したいのか？』『じゃあ、何を作ればいいんだっけ？』という、要求定義・要件定義が一緒になったような問いから始まります。

もちろん、ソフトウェアを開発する前に、顧客と丁寧に話し合って細部を詰めたり、細かく分析するのが適したプロジェクトもあるでしょう。しかし、短いサイクルで繰り返していくアジャイルな開発スタイルであれば、後から見直すことを前提として作ってもコストは全然変わりません。要求定義・要件定義はそれとして、具体的に動くものを触りながら突き詰めていく方が、より現実的・効率的です。

これもよくあることですが、ローコード・ノーコード開発プラットフォームは、導入できる組織の規模や業種を選ぶというのは誤解です。エンタープライズ向けの大規模なシステムや、金融や医療のようなミッションクリティカルなシステム開発にも、ローコード・ノーコードは次々と導入が拡がっています。組織の規模や業種にかかわらず、要求定義・要件定義そのものに拘るよりも、ビジネスで求められるニーズにフォーカスしながら、トライ&エラーを高速に繰り返していきます。

ただ、ここには、ローコード・ノーコード開発ならではの厳しさがあります。それは、要求・要件に対峙することからスタートせざるを得ず、更新のたびに常に意識することが求められるからです。時間稼ぎをしている暇はなく、ここから逃れることもできない意味において、プログラムコードを書く部分以外でストイックな姿勢が厳しく問われます。

要求定義と要件定義のプロセスがどのように管理され、進行されるかは、企業の開発戦略やリソース、組織の文化に大きく依存します。どのアプローチを選択するにせよ、ユーザーニーズを把握することと、それをソフトウェアで実現する重要性は変わりません。それぞれが適切に管理されることが、プロジェクト成功の鍵となります。

ローコード・ノーコード開発プラットフォームを使ったからといって、要求定義・要件定義が完全に不要になるわけではありません。明確な定義付けよりも、とにかく実際に動くモノを優先させる中で、アップデートを高速に繰り返していくことが求められます。自分自身を含めた、ユーザーニーズに最初から向き合うスピード感も非常に重要です。これはちょうど、ローコード・ノーコードによって不要になるのが、修行のような非効率なコーディング作業であり、プログラムコードそのものが重要なことに変わりはないのにも通じています。

言葉の定義はともかく、いきなり作り始めて、作りながら考えることができる、革新的なローコード・ノーコードツールの動向もチェックしておきましょう。次回は、要件の特性についてお話しします。リープリーパーの各種ソーシャルメディアのフォローも、この機会にぜひ！

リプリパ編集部

編集部員

XFacebookInstagram

リープリーパー（略称：リプリパ）編集部です。新しいミライへと飛躍する人たちのためのメディアを作るために、活動しています。ご意見・ご感想など、お気軽にお寄せください。
リプリパ編集部の記事一覧