TRACERY Lab.(トレラボ)

TRACERY開発チームが、要件定義を中心として、システム開発で役立つ考え方や手法を紹介します。

要件定義の難しさ

TRACERYプロダクトマネージャーの haru です。

システム開発は、企画、要件定義、設計、実装、テストというプロセスに大きく分けることができます。

開発者にとって、設計、実装、テストは仕事内容をイメージしやすい領域です。

ビジネスに近い立場の人々は、企画段階での企画書作成などを具体的にイメージできるでしょう。

しかし、要件定義に関しては、何をすべきか不明瞭でイメージしにくいという人も多いかもしれません。

この記事では、システム開発における要件定義の位置づけ、そして要件定義が難しい理由について説明します。

開発プロジェクトが失敗する一番の理由と世の中で求められている人材

システム開発が失敗する一番の理由を知っていますか?

日経クロステック、日経ビジネスが開発プロジェクトの失敗理由を調査した結果をみてみます。

日経XTechの調査結果
日経ビジネスの調査結果

上記は2017年、2018年に行われた調査結果ですが、いずれも『要件定義』に関する理由が1位です。

また、ビズリーチが発表した、『レジュメ検索・検索トレンド』の検索キーワード1位は『開発要件定義』でした。(2022年) 翌2023年の結果でも、要件定義は8位にランクインしています。

2022年レジュメ検索トレンド
2023年レジュメ検索トレンド

これらの調査結果をみると、要件定義が原因でシステム開発がうまくいかないことが多く、その結果として要件定義ができる人材が企業で求められているということが見えてきます。

要件定義は誰が何をするのか

システム開発のプロセス

システム開発の4プロセス

システム開発のプロセスは、上の図のように4つのプロセスに分けられます(ここでは「作る」ことにフォーカスし、テストは除いています)。

  • 企画 『なぜそのシステムを作るのか』という目的(Why)
  • 要件定義 『何を作るのか』(What)
  • 設計 『どのようにシステム・ソフトウェアを作るのか』(How)
  • 実装『実際に作る』(Make)

4つのプロセスは『レストランでの食事』に例えられる

レストランの例え

4つのプロセスを身近な例として、『レストランでの食事』に例えてみます。

まず『企画』は、食事のプランニングです。

何のために(Why)レストランで食事をするのでしょうか?親交を深めるためなのか、誰かの誕生日のお祝いなのか、理由は様々ですが、『仲良くなる』『お祝いをする』といった目的があると思います。ここまでが企画の部分です。

食事の目的が決まったら、何の料理を食べるのか、を考えます。ここが『要件定義』にあたります。

友達の誕生日を祝うため(企画)、友達の好物であるハンバーグを食べに(要件定義)、いろんな種類のハンバーグを頼めるお店に行こう(要件定義)、といったイメージです。

ここまでが、お客さんが担当する部分です。

続いて、お客さんからの注文(要件)を元に、レストラン側が料理をどのように作るのかを考えます。『設計』に当たる部分です。

どのように(How)、焼くのか煮込むのか、ドリアに乗せるのか、チーズを入れるのか、お客さんからの注文(要件定義)を元にどんな風に調理をするのかを決めていきます。

そうした調理方法(設計)を元に料理をつくります(実装)。

料理に例に説明しましたが、一連のプロセスは、「料理を注文する側」のお客さんと「料理を作る側」のお店側に分けられます。

ビジネス側と開発側の境界線

これはシステム開発も同じです。『企画』と『要件定義』、そして『設計』と『実装』とに分けられます。ただし「ビジネス側」「開発側」はロール(役割)と捉えてください。ビジネス側が開発の仕事を担当することもありますし、開発側がビジネスに携わることもあります。ここが料理とは異なる点です。

ビジネスを『事業』と『業務』に分けて理解する

ビジネスは事業と業務で構成される

ビジネスは『事業』と『業務』に分けて考えられます。

『事業』とは組織が社会的または組織的な目的を達成するために行う継続的な活動の全体を総称したものです。『業務』とは、事業を実現するために行う現場の仕事、オペレーションや運用を指します。

例えば「全世界に商品を販売したい」という目的をもった越境EC事業*1があるとします。

『事業』を実現するためには、商品をどこから仕入れるのか、商品の在庫管理はどうするのか。顧客に商品を届けるための物流などを考える必要があります。これらが『業務』です。この『業務』を行うためにはどのようなITのシステムが必要なのかを最終的に定義するまでが要件定義です。

要件定義の難しさ

要件定義における専門性の谷

要件定義における専門性の谷

ここまで説明してきたように、事業・業務を行う『ビジネス側』の役割(ロール)をもった人が要件定義を行います。

ここで問題になるのが、一般的にビジネス側の人は、ITシステムそのものへの知識やシステム開発プロジェクトの経験が少ないということです。

そのため、事業や業務に必要なITシステムがどのようなものなのかを定義することが難しくなります。

一方で、開発側の人も一般的にビジネスの知識や経験が少ないため、事業や業務に関して定義することが難しくなります。

ここが要件定義の難しさであり、要件定義のおける専門性の谷といえるでしょう。

この専門性の谷のために、冒頭で示したように多くのシステム開発が要件定義を理由として失敗していると考えられます。

この専門性の谷を渡るためには、ビジネス側と開発側の協力が特に必要になってきます。

そして、要件定義を推進し、様々なニーズを取りまとめられる人が世の中で求められている人材です。

要件定義ではビジネスと開発の協力が特に必要. Photo by Unsplash Antonio Janeski

まとめ

本記事では以下のことを説明しました。

  • システム開発が失敗する一番の理由と世の中で求められている人材
  • システム開発全体において要件定義は誰が何をするのか
  • 要件定義の難しさ(専門性の谷)

要件定義における専門性の谷を乗り越えるための『要件定義に必要なスキル』については以下の記事で説明します。

tracery.jp

この記事を書いた人
haru

佐藤治夫。株式会社ビープラウド代表取締役社長。TRACERYのプロダクトマネージャー。エンジニアとして活動を始めて以来、モデリングを中心としたソフトウェアエンジニアリングを実践している。Xアカウント: https://x.com/haru860

*1:インターネットを利用して異なる国や地域にある顧客に商品やサービスを販売するオンラインビジネスの形態。このビジネスモデルでは、企業は国境を越えて製品を提供することで、より広範な市場へアクセスし、多様な顧客層にリーチすることが可能になる。