いやぁ、参ったね。日本企業もDX（デジタルトランスフォーメーション）の一環として基幹システムの刷新などに取り組むご時世だから、「要件定義は誰の仕事か」なんて常識中の常識だと思っていたんだが、とんでもない間違いだったな。そう、要件定義はシステム開発の依頼者である客側の仕事に決まっているはずなんだが、今はそうではないらしい。なんと、SIerなど受注者側の仕事だと思い込んでいる技術者らが結構いると分かったのだ。本当に驚いてしまったよ。
システム開発における要件定義は客の仕事に決まっている。何せ、SIerなどITベンダーにシステム開発を依頼するとしても、客の企業が「自分たちはどんなシステムを欲しているのか」を明確にしてITベンダーに正しく伝えないと、まともなシステムなんて構築できるはずがないからね。ましてDXの一環としての新規システム開発やシステム刷新ならば、客の企業が自分たちの業務をどう変革するのか、どんな新しいビジネスを創るのかがあってのことだからね。客が要件定義しないで、いったいどうするの。
要するに、要件定義は昔から客の仕事に決まっており、最近では客が要件をきちんと定義する重要性はますます高まっているというわけだ。ところが、である。要件定義を客の仕事だと認識していない技術者が増えている。30年ほど前には、客の企業もITベンダーも要件定義を客の仕事だと認識していた。なのに今や客の企業でもITベンダーでも、その大原則が崩れ始めているようだ。私がそれを思い知ったのは、次のようなX（旧Twitter） のツイートがきっかけだった。
システム開発における要件定義はいったい誰の仕事なのか――。最近、そんなことをよく考えるようになった。「何を言っているの。要件定義は依頼者側の仕事に決まっているじゃないか」と笑われるかもしれないが、依頼者とは誰で、その依頼者に要件定義ができるのか。ほとんどの企業のIT部門は無理だぞ。
実は、これは私が2025年6月9日にXでツイートしたものだ。読んでもらえば分かる通り、要件定義は客の企業の仕事に決まっているとの認識を前提にしている。その上で、客の企業ではIT部門が劣化したことなどで、満足に要件定義ができなくなってしまった。さあどうする、というのがこのツイートの趣旨なのだが、要件定義はITベンダーの仕事だなどとする「反論」が多数寄せられたのだ。そのせいか結構バズったので、Xのアカウントを持つ読者の中にも目にした人が結構いるかと思う。
中には「要求定義と要件定義を取り違えている」と忠告するコメントもあったな。要するに、客の企業はシステムに対してどんなことを求めるのかという「ざっくりした」要求をまとめ（定義し）、それを基にITベンダー側で非機能要件なども含めシステムに求められる要件をきちんと定義すべきだ、という理屈だ。ちなみに要求定義は英語では「Requirement Definition」だし、要件定義は「Requirements Specification」だよね。Definitionはもちろん定義でSpecificationは仕様だから、一見もっともらしい話ではある。
だけどさ、要求定義と要件定義、Requirement DefinitionとRequirements Specificationとの切り分けは、何だか機械的過ぎる気がするぞ。システムの規模にもよるが、日本では要件定義の中に要求定義の要素を盛り込んで一体化しているケースが多いし、米国でもRequirement DefinitionとRequirements Specificationを分けない場合が多いと聞く。結局のところ、要求定義やRequirement Definitionをまとめるのは主にシステムの利用者側であり、要件定義やRequirements Specificationをまとめるのが主に技術者ということだろう。
そのように考えていたら「あっ、そうか」と思い至ったぞ。昔、といっても35年ぐらい前だが、私がまだ駆け出しの記者だった頃、取材で訪れた大企業のIT部長に「要件定義ってITベンダーがやるのですか」と聞いて「そんなの、我々の仕事に決まっているだろ」とあきれられて赤面した苦い記憶がある。当時の大企業も既に、今で言うところのSIerである大手ITベンダーに依存する傾向があった。それでも少なくとも要件定義は自分たちの仕事だと明確に自覚していた。
なぜならば当時、大企業のIT部門の多くは曲がりなりにも技術者集団だったからだ。要件定義は結局のところ、開発すべきシステムの基本的な仕様をまとめる作業にほかならないから、ITやシステムを理解している技術者が担ったほうがよい。ただし、要件定義は「こんなシステムをつくってほしい」というのをまとめる作業でもあるから、依頼者側つまり客側の人間が手掛ける必要がある。当時なら技術者であり客側の人間はIT部員たちであるから、IT部長は「そんなの、我々の仕事に決まっているだろ」と言い切ったわけだ。
しかも、同じ企業の中だからな。要件定義から要求定義を分離して、自社の経営陣や事業部門に対して「要求をまとめて提出してくれ」などと要請することはなかった。IT部員が自ら事業部門の業務プロセスを調べたり、事業部門の人たちとディスカッションすることで現状の課題やシステムによる解決策を探ったりした。確かに当時から既に、プログラミングなど手を動かす作業はほとんどやらないIT部門が増えていたが、少なくとも要件定義は自らの業務としてしっかりやっていたよね。
ところが、1990年代初頭のバブル崩壊以降、日本は「失われた30年」と呼ばれる経済の大スランプ期に突入してしまう。インターネットの爆発的普及を起点とするデジタル革命の時期とほぼ重なったにもかかわらず、多くの日本企業でIT部門は「収益を生まない間接部門」として扱われ、リストラのターゲットとなってしまった。もちろん企業によって多少の違いはあったものの、何せそんな時期が30年も続いたからな。結果、多くのIT部門が技術力を失い、素人集団へと落ちぶれていった。
素人集団と化したIT部門は当然、要件定義すらできなくなってしまう。だから、企業が大規模なシステム開発やシステム刷新を再開しても、IT部門は単なる「発注窓口」として要件定義なども含めてSIerをはじめとしたITベンダーに丸投げするしかない。ITベンダーの技術者が客に代わって、本来は客の仕事である要件定義を代行したわけだ。システム開発の大半でそんな代行作業が10年、20年と続けば、SIerなどの技術者が「要件定義は自分たちの仕事だ」と思い込んでも不思議ではない。
それにSIerは人月商売の親玉だからな。客のご用を聞いて人月工数を膨らませるのがビジネスの基本だ。当然「ご用聞き＝要件定義」となるよね。で、自分たちが要件定義をやるから、客は要求定義、つまり「システムにどんなことを求めるのか」を明確にしてください、という話になるわけだ。だけど、素人集団と化したIT部門や事業部門が「こんなシステムをつくってほしい」と明確に言えるわけがない。こうした要件定義に関わる勘違いやレベルの低さが、後の設計・開発段階でプロジェクト炎上などの悲劇をもたらすことになるわけだ。
