「"要望"、"要求"、"要件"、"仕様"」という言論闘争に疲れたあなたへ
著者について
長いことIT業界で活動し、ITプロジェクトの不幸をたくさんみてきました。
ベンダー側もユーザ企業側も悪いところがある、は総論ですがそれ自体は評論でしかなく何の面白味もありません。
そのため、不幸の原因や向き合い方についてベンダー側・ユーザ側、経営・営業・エンジニア(PM)と経験を積み、研究と臨床を繰り返してきました。人と技術が絡むもので変数が多いので専門領域を絞っています。事業において重要な位置をCRMやフロントシステム、CRMとERPの間あたりです。とりわけ、Salesforce界隈のエコシステムを観察し、手を変え品を変え活動しています。
はじめに
直近、NHK社のシステム開発におけるベンダーへの訴訟が話題になりましたね。
また、ちょっと前にも文化シヤッター社のSalesforce導入を巡る訴訟も大きな話題になりました。
個々の内容や事情については、具体的に知りませんし、ネガティブな感情を持たれる方も多いと思うので触れません。また、どうすれば良かった、という答えを出すこともしません(出来ません)
ただ、こうしたニュースが流れるとX(Twitter)では事業会社が悪い、ベンダーが悪い、こうした意見が飛び交います。
そして、その中で度々登場する論点が
「要求(または要求定義)」と「要件(または要件定義)」の違い
といった議論です。
要求を定義せずベンダーに押し付けるユーザ企業(事業会社)が悪い、定義した要件が緩かったのが悪い、といった使い方ですが
それが答えなら、何十年もシステムエンジニアリングは同じ失敗を繰り返さないはずです。きっと構造的な問題と向き合って考え続ける必要があるのだと思います。
本noteは、答えを出さずに考えたい、という方をターゲットに、共に構造の捉え方を引き上げていけたらと思って書いています。
1.要件定義とは一体何なのか？
1-1.ユーザ企業主体？ベンダー企業主体？
まずは印象論から入ります。
"要求"は、ユーザ寄り、"要件"はベンダ寄り、こんなイメージでしょうか。
昔のシステムエンジニアリングにおいては、よく"要求分析"という言葉を使いました。
しかしながら、分析というと、まるでユーザの中に要求が存在していて、ベンダーがそれを整理するイメージになりがちです。つまりユーザ主体です。
また、"要件定義"というと、一般にはシステム開発独特の用語に見えますので、ユーザの要望を元に、システムの仕様はプロであるベンダーが定義してくれるように思いがちです。つまりベンダー主体。
いずれにしろ、ユーザがインプットしてベンダーがアウトプットする、左右の対立構造に見えています。インプットが悪いのか、アウトプットが悪いのかという対立です。
1-2.言葉の定義に正解はあるのか？
持論で、言葉の定義をしだすと多くの言葉狩り警察が湧いてきますので極力避けていきます。
日本の現場だと要求、要件、仕様を区別しようという意見をよく見ます。そして、長年システムの仕事をしてきた身としては、概ね理解する内容が多いのも事実です。
ですが、言葉を分けることの意味の方が大事で、その定義は毎度個々にした方がよいと思います。(PRJ単位や、ある程度共通化できるなら組織単位など)
定義を決めつけても意味がない、という主張ではなく、毎度配慮し擦り合わせる必要があるだろう、という考えです。
昔と違って、ITシステムのエンジニアリングは通例や常識の通じる専門家・プロ同士の仕事ではとっくに無くなっているからです。(昔も今も？)
1-3.システムズエンジニアリング標準に照らして考える
標準として何を取り上げるかにも論争があると思いますし、標準だから正解という話はしません。
が、ISO/IEC/IEEE15288(原典英語)などをベースに示唆を得ていきたいと思います。
英語においては要求・要件という言葉の区別はなく、"Requirement"という言葉にまとめられています。
要求や要件などのバリエーションは、日本独自にニュアンスの圧縮がかかった言葉だといえるでしょう。
日本では概ね、ステークホルダ(組織や人)のRequirementを決めることを要求定義と呼び、
システムのRequirementを決めることを要件定義、と主張されることが多いように観測しています。
前者を含んだ全体を広義の要件定義とし、要求定義をステップとみなす見方もあります。
もっとシンプルに、ニーズを要求、仕様を要件と呼ぶ、というのもよく見かけます。
英語でまとめられた標準においては様々なRequirementという同じ言葉としてまとめられているのは面白い点です。普段、我々が要件や要求として区別して呼んでいるものも、実は同じ性質を持った言葉なのではないか、そんなことが示唆されている気がします。
正解を決めることはしませんが、
一つ、上記のようなエンジニアリング標準を確認していく中で、"Requirement"の定義を探ると興味深い示唆があります。(著作物にあたると思うので意訳につき異論認めます)
"Requirement"は、ニーズ・要望に対して、"条件や制約"を加味した上で変換したり、表現したものである、といった定義です。
条件や制約を加味するというのは例えば
「リモートワークを導入したい」というニーズだと一言ですが、それにより発生するリスクの担保といったビジネス目的に照らして圧縮されている条件が実際にはある訳なので、"セキュリティポリシーに準拠したアクセス制御を実装すること"とか"週1回以上のオフィス出勤を必須とすること" といった組織方針による条件が加わってくるイメージです。
ここにヒントがあると感じます。
1-4.我々は本当は"何と何"を区別したいのか？
実は、日本における言葉の論争において本当に論者が問題にしているのは、Requirementという言葉に含まれる"条件や制約"の部分なのではないか？と考えています。
皆さんが本当に言いたいのは、言葉を分けよという話ではなく、"(無邪気な)ニーズ・(曖昧な)要望"と要件や要求という言葉は区別すべきである、という主張なはずです。
となると、ユーザ主体かベンダー主体かはあまり関係ありません。となると、ユーザ主体かシステムの専門家であるベンダー主体かはあまり関係ありません。
議論を眺めていると、話が混ざってるように感じます。
ビジネスや業務上の目的設定とシステム的な手段設定を取り違えるなという話と、
ビジネスやシステムのニーズという種に対して"条件や制約"を付け加えて明確化しようという話です。
僕の意見としては、前者の議論ではなく、後者の論点には価値があると思っています。前者は結局ビジネス目的の設定が悪いか、システム的な手段の検討が甘いかというどっちが悪いか話を表現しているに過ぎないからです。
問題は、ユーザ企業の組織や人のもつRequirementが緩いか(=ニーズレベルなのか)、システムのRequirementが緩いか(同様)という話です。ビジネス目的に対してシステムを作るは当たり前の話で、Requirementとして十分な品質のビジネス要求(要件)、システム要求(要件)をどうしたら作れるか？の議論をするのが本質的だと思います。
いずれも、仕様(Specification)に向かっていくグラデーションをきちんと作ることが一般の要件定義という上流工程において、重要である認識です。
目的を捉えて、様々な要求や要件が表現として十分な品質にできているか？が本来の論点だと考えます。
2.要件定義の難しさを構造的に理解する
2-1."左右分担構造"の限界について
図で表現します。"ユーザ企業主体？ベンダー企業主体？"の節で触れた点です。
いずれにしろ、ユーザがインプットしてベンダーがアウトプットする、左右の対立構造に見えています。
左右分担とは例えばこういうイメージです。(下図)
契約、SOWといったもので、責任分解をして分担できるのが理想ですが、全てを言語化して定義できる訳ではないので、実際には曖昧さを残すことになります。責任分解するラインを、仮に発注線/受注線と名付けます。
実際には、中間の曖昧さをどう明確化しよう、という活動以前の問題があります。
それは"心理的発注線および受注線が、そもそも互いに離れやすい"という点です。社内他部署との協業や上司部下でも同じ構造があります。
発注側は究極には目的に純粋であり、受注側は究極的には飯のタネとなるリソースや専門性に純粋です。(下図)
お客様が丸投げとか、ベンダーがいけてない、みたいな話はよく聞きます。
しかし、実際の質はさておき、原則として「そう見えるものである」というのが構造上の真実なのではないかと思います。(下図)
結局のところ、意思決定までのフェーズ、プロジェクト開始後のフェーズそれぞれにおいて、"お互い様"の部分があります。そして、お互い様の部分をどうにかすることが、付加価値としてとても高い部分です。
ですが、ビジネス上の発注/受注のパワーバランスの問題もあり、その間の空白部分は中々埋まらないか、どちらか一方が過剰に努力することになりがちです。(下図)
このように、責任境界の周辺にモヤのかかったプロジェクトが、すったもんだありながら、なんとかソフトランディングする、という極めて不安定なプロセスを繰り返しているというのがシステム導入の現場における実情ではないでしょうか。
技術が変化する中でも、変わらずに続いている問題です。
2-2.要件(要求)定義が左右の対決ではない理由
これまで記載した通り、要求や要件という"言葉の区別"によって解決できるものでもなければ、役割をきっちり分けて、左右分担する構造には限界があります。
これは要求であって、要件じゃない、みたいな論調で他方をねじ伏せるのには一定の無理が出てくると思います。(仕事を受ける際の線引きや約束ごととして、合理的かつ合意可能な基本ラインを決めようという意図は賛成です)
あくまでも、アーキテクチャやデザインといった、解決策の"設計"やその先の実装に繋がるインプットを出力するプロセスをどう考えるか？という未来へ進まなければいけません。
実際、新規サービス開発のようなものであれば、ベンダーが踏み込んでユーザ企業と共に要求そのものを開発しなければいけないような場面もあるでしょう。
また、連携する既存システムや、技術方式の指定・制約があるのであれば、ユーザ側も設計に踏み込んだ要求を出す必要もあるでしょう。
要求や仕様が当たるかどうか分からないなら、作って出して見る、という進め方も重要です。
究極、その進め方が望まれ、合意出来てるなら、要求が仕様っぽくても、要件が要望っぽくても問題にはならないこともあるでしょう。
2-3."ユーザは要求のすべてを持っていない"という事実
左右対立構造で語ることが難しい点の一つは、要求は仕様であり、仕様は要求であるという話です。
目的と手段、の関係にも似ています。
目的だと思っていたことも、その上位目的からすると"手段"に変化します。同様に、アーキテクトが設計した仕様は、サブシステムの実装者からすると要求になります。
昨今はスクラッチシステムではなくパッケージやPaaSのカスタマイズを前提としたプロジェクトが増えました。
要求は顧客が持つべきだ、という意見もわかりますが
ユーザが全てを知ることが不可能な"パッケージ製品やプラットフォーム"の制約(これも一つの要求)を知るわけではありません。
また、ユーザ企業が海外のベンダーに発注するとして、その国の法律や慣習やルールを知るわけではありません。
つまり、ユーザが要求定義をして、ベンダーが要件定義をすべきだ、という左右構造は現実的に不可能なことが多いと思うのです。
要求(ニーズに対して条件や制約を加味した表現)をつくるには、ベンダー側の知見が必要です。
具体的には
"パッケージ標準機能を活用せずにプロジェクトがうまくいかなかった"
とか
"見積時点では標準機能の活用をN%とし、オブジェクト数いくつとレポート数いくつ程度を目安としていた"
とか言っても、それは中々無理めなコミュニケーションシステムだな…
と思う訳です。
裏を返せば、既存システムや業務を理解するのはベンダー側にとって限界のあることですから、システム的な仕様や制約についてもユーザ側の知見が必要ということでもあります。
そしてシステムのオーナーはユーザ企業側であることに違いありませんが、
ベンダー側の主張として要求は顧客(ユーザ企業)が持つべきだというのも無理があります。
最後に
実際には、プロジェクトの広義のステークホルダーなど外部環境を含め、様々なパワーバランスや圧力が動くのがプロジェクトです。
ですが、そもそもの"左右分担できっちり分けられる仕事である、という誤解"があるならばそれをキャンセルし、要求や要件の定義は双方に努力する必要のある工程であるという構造を前提に取り組みたいものだと思います。
その上で、切った張ったの押し合いをするも良し、理想やビジョンとしてよく語られる"共創"を目指すも良し、
各々が、各々の持ち場で、現実のプロジェクトにおいて戦っていければと思います。
最後まで読んでいただき有り難うございます。
良ければスキ(♡)や、Xでのフォローなどお願い致します。
https://x.com/yonyonsaeki
いいなと思ったら応援しよう！
