【第11回】「要件定義」を発注する側の気持ちで理解する

絶対それ、痛い目に遭うやつ

『いい感じ』の中身が、美咲とシステム会社で一致してないと、完成した頃に『これじゃない』ってなる。今日はそこを避ける方法の話

システム開発は、いきなりプログラミングから始まるわけじゃない。まずシステム化構想（何のためにシステムを作るか）を固めて、それを要件定義（具体的に何ができればいいか）に落とし込む

うん、この後の第12回でも詳しくやるけど、ここで大事なのは要件定義はユーザー側（発注する側）の仕事でもあるということ。開発会社にお任せじゃなく、『何が欲しいか』を言語化する責任は発注側にもある

そう。欲しいものを言語化する大変さに気づけたなら、もう半分理解できてる

じゃあ実際、システムを外部に発注するときの流れを見ていこう。まずRFI（情報提供依頼書、Request for Information）——複数の会社に対して『御社にはどんな技術や実績がありますか』と、情報提供を求める文書

そう、いわば下調べの段階。候補を絞り込んだあとに送るのがRFP（提案依頼書、Request for Proposal）。今度は『こういう要件で、こういうシステムを作りたい』と具体的に伝えて、各社から提案書と見積りをもらう

そのとおり。そして契約の段階になると、契約形態を選ぶことになる。代表的なのが請負契約と準委任契約

請負契約は、成果物の完成そのものを約束する契約。納期までに『動くシステム』を完成させる義務がある。一方準委任契約は、決められた業務を誠実に遂行することを約束する契約で、必ずしも特定の成果物の完成までは約束しない

そう。ちなみに、どちらの契約でも共通しているのが、発注側（ユーザー企業）には受注側の作業者に対する指揮命令権がないという点。『この人に直接あれやって』と指示できるのは、あくまで受注側の会社。これができるのは労働者派遣契約の場合だけ、という違いも覚えておくといい

最後にSLA（サービスレベルアグリーメント、Service Level Agreement）。これは開発の話じゃなく、システムを運用していく段階で交わす、『どの程度の品質・可用性でサービスを提供するか』を約束する文書。『稼働率99.9%以上を保証する』みたいな数値目標を定めることが多い

1つ目は、RFIとRFPの違い。『情報を集める段階』か『具体的な提案を求める段階』か、依頼するタイミングと目的で見分ける

請負契約と準委任契約の違い。成果物の完成を約束するかどうかで見分けるのが基本で、『発注側に指揮命令権がない』のは両方に共通するポイントとして、労働者派遣契約とセットで問われやすい

いいね。ここまででストラテジ系は完了。次からはマネジメント系、実際にシステムがどう作られていくか——さっき話した要件定義の続きから始めよう