そもそも要件定義とは？

　そもそも「要件定義」とは何か、改めて簡単におさらいしておこう。

　システム開発において「要件」とは、実現すべきことを関係者間で合意した内容を指す。この要件は、事業要件、業務要件、システム要件という3つの階層に分類され、それぞれが異なる視点で定義される。このうちシステム要件は、さらに機能要件と非機能要件に分かれているが、これらの要件を明確にし、合意するプロセスこそが要件定義である。


　要件定義の役割と重要性について、佐藤氏は次のように強調する。

「その究極的な役割とは『何を作るか（What）』を決めることです。この『何を作るか』が明確でなければ、その後の設計段階での『どのように作るか（How）』を進めることは困難になります。このため要件定義とは、システム開発の成功を左右する重要なプロセスであり、適切な要件定義がなされていなければ、プロジェクト全体が迷走してしまうことにもつながりかねないのです」（佐藤氏）

　ここでシステム要件の中の機能要件と非機能要件にも触れておこう。


　まず機能要件とは、システムが提供すべき具体的な機能やサービスを指す。つまりシステムが「何をするか」に関する要件であり、ユーザーやクライアントが期待する具体的な動作や結果を定義する必要がある。一方で、非機能要件はシステム全体の動作や品質に関する要件であり、セキュリティや性能、可用性などが含まれる。

再注目される「要件定義の重要性」

　要件定義の重要性は、IT業界における歴史の中で繰り返し浮上してきたテーマである。佐藤氏はこう振り返る。

「2000年代前半までは、上流工程や設計に関する書籍が多く出版され、Web上でも活発な議論が行われていました。しかしその後、Webサービスなどのヒットが予測できないプロダクトに多くの時間を割いて要件定義や設計を行うのは非効率だということで、まずは動くものを作るという流れに変わっていきました。これに伴い、技術者たちの興味・関心はプログラミングや実装技術へと移行していったように思われます」（佐藤氏）

　プログラミング重視の流れは、アジャイル開発やリーンスタートアップの考え方が広まった時期だ。とにかくまずは迅速にプロダクトを作り、そこから改善していく手法が支持された。しかし、このアプローチには大きなリスクがある。

「結果として、たとえ事業が成功したとしても、設計が不十分だったシステムはレガシー化し、負の資産となってしまいます。システム障害が頻発し、運用や保守において大変な手間がかかるようになるのです」（佐藤氏）

　特に近年のDX推進によって、全社を挙げた本格的なシステム開発が行われるようになった。それにより短期的な成果を追求するだけではもはや通用しない、といった事実が再認識されるようになった。

「業界では、結局はしっかりとした設計が重要だという認識へと戻りつつあります。時代はまさに“行ったり来たり”です。ただやはり要件定義の不備も多く見られるのが現状です」（佐藤氏）

　少し前の調査だが、日経クロステックが発表した2017年の調査結果によると、システム開発プロジェクトの最大の失敗理由は「要件定義」だった。そしていまだに要件定義で失敗するという声は多い。なぜ、これだけ失敗が繰り返されるのか。 【次ページ】要件定義が失敗する「3つの原因」