要件定義について書いておくか

こんなツイートを目にした。 

ちょっとSI系の若者達が誤解するとイカンので言っときますが。
「要件定義」ってお客様側のプロセスですよ。普通は基本設計以降と契約分けるし、受ける場合でも準委任契約です。

— 戦略的なビビ（Vivi） (@strategic_vivi) June 2, 2019

 要件定義が顧客側のプロセスだというのはその通り。このツイートをした。

昔、ギャラ貰って技術系Webサイトにこの件を書いたけど、日本の企業の場合ボトムアップで物事が進むことが多いので、要件定義に抜け漏れダブりが多くて、実際に開発しようとすると使えない物しか出てこない場合が多いのよ。なので、本来顧客側のプロセスである要件定義も有償で請けるってことになる。

— ꧁🐶꧂ (@shigeo_t) June 2, 2019

 背景はツイートの通り。多くの場合顧客側から出てくる要件定義書は使い物にならない。理由は後でもう少し詳細に書く。技術系Webサイトに書いた時の元原稿と図を発掘したので、ちょっと補足していく。原稿そのままだとCopyrightはオレに無いし原稿の文体はですます調だし、割と広範に気を使って書いた文章なので、バッサリと削って書こうと思う。なお、元ツイートと同様に受託開発を想定するので、要件定義の対象は何かの業務システム用であり、OSとか非業務のソフトウェアは対象としていない。

業務要件とは

業務要件とは何かについて整理する。業務には存在する理由があり、理由を外的要因・内的要因の２つの要因に分けて考えることができる。

図に示すように、外的要因では法令や制度、監督官庁の指導など、決められた範囲内で業務仕様を決めなければいけない部分がある。例えば、規制業種の場合は○○業法という形で法律として規定されているため、その規定にそって業務を進めエビデンスを残すという形になる。
どういう企業でもなんらかの購買を行い、なんらかの販売を行うサプライチェーンの１つを担っている。このとき他社との接点が生じる。サプライチェーンとの接点では、他社との調整が可能・必要な場合がある。

業務オーナーを決めろ

システム化がい必要な業務は、１つの部署で完結することは多くなく、複数の部門・部署にまたがって処理されていく。ここで問題になるのが「誰が決めるのか」「すりあわないときどうするのか」である。業務オーナー部門が決まっていなければ、なかなか業務要件・業務仕様は決まらない。エンドユーザー部門だけを集めても、それぞれ相反する要求でまとまらない可能性がある。

複数の部門／部署をまたがって処理されるとはいえ、その業務（あるいは事業）をやりたい部門／部署や、業務の結果に責任を持つ部門／部署がある。そのような部署をオーナー（部門）部署として決め、業務要件・業務仕様策定の中核を担ってもらう必要がある。本来は、ITシステム化するプロジェクトが発足した段階で業務オーナー部署が決まっているべきである。

通常は業務の起点となる部署Aか、最終承認をする部署Fなどが業務のオーナーとなって要件を定義していく必要がある。

なぜ多くの場合顧客が作る要件定義書は使い物にならないのか

ポイントは2つである。

SoDが無い

ひとつは職務分掌(SoD:Segregation of Duties)が明文化されていないため。日本の企業では長期雇用を前提とした組織運営を行っており、職務分掌を文書化する文化ではない。ある日突然担当者が変わってその日から即戦力として働いてもらうのであれば、SoDの決定と文書化必須である。しかし日本の場合はそこまでドラスティックに担当者が入れ替わることがないので、文書化する文化が育たなかったのだと考えられる。

SoDの決定とその文書化がされていない場合は、必要十分で関係者一同がわかるように、業務内容を洗い出した資料を作ることになる。ステークホルダーを整理するための資料を作るために、関係しそうな各部門／各部署からヒアリングしたりすることで、その業務の仕組みやそれぞれの部門／部署の関わり方が理解できる。

ところがこの部分を「わかった気になって」はしょってしまうので、顧客サイドの作った要件定義書では抜け・漏れ・ダブりが出てしまう。せめて、業務を俯瞰するIT屋が言うところの「アーキテクト」がいればいいのだが、各部署の作ったものをそのまま綴じたようなものを出してくることが多過ぎる。

精選 分掌・権限規程とつくり方―時代に即応した業務分掌・職務権限規程の手直し (規定とつくり方シリーズ 8)

whatとhow分離

ツイートでも書いたが、何を作るのかというwhatと、どのように作るのかというhowの分離は重要である。

　業務要件・業務仕様を策定しているときに、何を作るのかということを聞いているはずなのに、なぜかそのなかに「どう作られていてほしい」などのhow情報が含まれてくる。エンハンスの場合にはそれほど問題とならないが、新しいインフラ・アーキテクチャを前提としたリニューアル・プロジェクトなどの場合には、そのhow部分まで業務要件・業務仕様として受け取ってしまうと、足かせとなって実装できない業務要件・業務仕様となる。
＜何をすべきか＞というwhatにフォーカスすることが重要である。

準委任契約

元ツイートを再掲する。

ちょっとSI系の若者達が誤解するとイカンので言っときますが。
「要件定義」ってお客様側のプロセスですよ。普通は基本設計以降と契約分けるし、受ける場合でも準委任契約です。

— 戦略的なビビ（Vivi） (@strategic_vivi) June 2, 2019

オレなら基本設計までを準委任契約にするように努力するけどな。

それはさておき、準委任契約とは何か。弁護士先生の回答を引用する。 

民法６３４条は「法律行為」の委託、受託を委任契約の要件としています。
　そして、同６５６条で「法律行為でない事務」の委託にも委任契約の条文を准将するとしています（準委任契約）。「法律行為でない事務」であり、「法律以外の事務」ではありません。
　そして、法律行為とは、人が意思表示によって法律効果（権利義務関係）を発生させるという法律要件（法的な意味のある事実）をいいます。
　よって、交渉のように意思表示を含む行為を他人に依頼する場合には委任契約となります。意思表示を含まない行為を依頼する場合には準委任契約となります。

 「准将」は多分「準用」の間違いだと思うけど、簡単に言えば委任＝「法律行為の委託」で、その民法634条の条文を法律行為以外に準用するので「準委任」である。

では請負契約と準委任契約の違いとは。

請負契約は、請負人が仕事を完成することを約し、注文者がこれに対して報酬を支払うことを内容とする契約です。一方、準委任契約は、仕事の完成ではなく、一定の事務処理行為を行うことを約する契約です。

つまり、請負契約では成果物を完成させて納品し検収を受けてお支払いまで進むのに対し、準委任契約では事務処理をすればOK。硬い言い方で書いた文を引用すると、

準委任契約では、納品物が想定どおりに完成しなくとも、事務処理自体が適切に実施されれば対価を請求できますし（民法648条2項）、受任者の責めに帰することのできない事由によって履行の中途で契約が終了したときには、受任者は、すでにした履行の割合に応じて報酬を請求することができます（民法648条3項）。

ということになる。冒頭に書いた通り、要件定義は顧客サイドのプロセスを代行するので、請け負ってはいけないと言うこともできる。

このセクションの頭に「オレなら基本設計までを準委任契約にするように努力する」と書いたのは、だいたい基本設計完了をもって後続の工程の再見積を行うので、準委任→請負→請負という契約にするより準委任で基本設計まで→開発工程を請負のほうが契約行為の回数が減ることと、基本設計もできれば(作るのは自分たちだけど)承認するのは顧客なので顧客側プロセスに入れて、自分たちの責任を減らしたいというセコい考えからである。間違いなくセコいということは言える。だから「努力する」なのである。

ここで負けて要件定義確定後再見積とかになると、設計してみたら思ったよりも工数が膨らんでプロジェクト参加者が死にそうになることもある。まずは基本設計(請負でもいい)後の再見積を死守、次が基本設計も準委任にするというのがプロジェクト参加者に安らかな睡眠をもたらす。

ハウスウェルネスフーズ ネルノダ 100ml×6本 [機能性表示食品 ]

おまけ

 元ツイ主のもう一つのツイートに引っ掛かった。 

あとお客様が「要件定義書です」って言って単なる要求文書出して来た場合、多分「要件定義」という言葉が無かった昔のプロセスと勘違いしてるだけなので、怒らずに普通に基本設計の工数二倍にしてね。
昔はそうしてたのね。要件定義って比較的最近の生まれ( ´Д｀)

— 戦略的なビビ（Vivi） (@strategic_vivi) June 2, 2019

 おいおい、比較的最近ってのはオレが仕事についた30年以上前の事かと思って調べてみた。 

情報化社会を迎えた1980年代にRDBなどが整備された後、経営戦略や業務システムにDOAを積極的に利用していこうという流れが活発化しました。
いわゆる情報システム部門が企業の中に設置され、企業活動をコンピュータによって効率よくサポートするための設計が重視されるようになりました。

この頃から、現在のソフトウェア開発、システム構築の定番である「要求定義」「要件定義」「外部設計」「内部設計」などの開発手法が定着していきます。
その背景には、企業活動を支援するという成果を出すためにはソフトウェアやシステムをどのように設計したら良いかという、上流工程への意識の向上があったわけです。

 だよねえ。オレがこの業界に入った時にはすでに要件定義は存在してたよ。使い物にならない理由は上述通り。比較的最近＝30年以上というのはパワーワードだなｗオレはそこまで年寄りではない。

あと、ここで「上流工程」という単語が出てきたけど、それこそSI系とかITコンサル系の若者が誤解するポイントである。「上流工程」やってるからって偉いわけじゃない。それこそ職務分掌の一つである。実装する担当者がいなかったらいつまで経ってもシステムはできない。

言いたいことはまだあるけど、クソ長くなったのでおしまい。技術系サイトに書いた記事はまだ残っているので、リライトはしたけど探せばオレの名前と当時の所属はわかる。探さないように。

関連するのはこんなところですかね。