ようやく春らしい陽気になってきましたね。
さて以前、「準委任契約の特性について考える」という記事で、私のコンサルティングサービスに照らし合わせた、「準委任契約」に基づく受委託業務の実践面での私の考え方を、
また、前回の「準委任契約の特性のついて考える（その２）」という記事で、準委任契約に関する私の基本的な理解についてご紹介しました。
今回は、ソフトウェア開発の各プロセスにおける「準委任契約」の適用について、私の理解・考え方を整理しておきたいと思います。
ソフトウェア開発のプロセスにおいては、いろいろな整理があります。
経済産業省「情報システムの信頼性向上のための取引慣行・契約に関する研究会」やＩＰＡ「共通フレーム２００７」など、たいへん参考になる、論理的に統合・整理された考え方があります。
しかし、今回は、少しシンプルに、以下のプロセスで整理していきます。
１．システム化企画
２．システム要求定義
３．システム要件定義
４．システム基本設計
５．システム詳細設計～結合テスト
６．総合テスト
７．運用テスト
８．その他、データ移行
１．システム化企画
これは、ユーザ企業が主体となって、事業戦略や事業計画に沿うシステム化構想を策定するプロセスになります。
成果物は、システム化企画書になります。
このプロセスにおいては、コンサルタントなどの外部メンバーは「支援」者に位置づけられ、また、本プロセスの要求仕様や成果物も定まらない状況の場合が非常に多いです。
よって、外部メンバーとの契約は「準委任」になるべきだと、私は考えています。
２．システム要求定義
これは、ユーザ企業が主体となって、システム化構想に沿うシステムへの具体的な要求事項を取りまとめるプロセスになります。
成果物は、システム要求仕様書やシステム提案依頼書になります。
このプロセスでも、あくまでもコンサルタントなどの外部メンバーは「支援」者に位置づけられます。
よって、外部メンバーとの契約は「準委任」になるべきだと、私は考えています
なお、次に記載する「システム要件定義」との違い・区別に関する私の考え方は、
過去の記事「要求定義と要件定義」をご参照願います。
３．システム要件定義
これは、ユーザが主体となりつつ、構築ベンダーがシステム要件を確認し文書化するプロセスになります。
パッケージソフトウェアのフィット＆ギャップも、本プロセスに含まれます。
このプロセスでユーザ企業が構築ベンダーに依存し過ぎると、失敗プロジェクトを生み出す可能性が高くなります。
よって、構築ベンダーとの契約は「準委任」になるべきだと、私は考えています。
なお、例えば既存システムを構築したベンダーへ再構築を委託する場合など、
「概算金額で請負契約を締結してからシステム要件定義を開始する」ケースが多くあります。
これは、ユーザ企業としては、契約金額の上限が確定できる（ように感じられる）というメリットがあり、
また、構築ベンダーとしても、完成までの契約が確定できる（要件定義後にベンダー変更がされにくくなる）というメリットがあります。
以上から、「概算金額で請負契約を締結してからシステム要件定義を開始する」方式は採用され易いパターンなのですが、
その場合、ユーザ企業は「要件を詰め込むだけ詰め込む」
その逆に構築ベンダーは「グレーゾーンの要件は追加扱いにする」
という意識が働くようになり、双方の不信感や不満が高まる危険性があります。
よって、信頼関係があったとしても（逆に信頼関係があるからこそ）、
システム要件定義は「準委任」として実施することをお勧めしたいと思います。
その他、例えば２０人月程度のシステム開発で且つシステム要求定義が一定レベルまでできていれば（システム要求仕様書が十分なレベルで作成できていれば）、
私は、システム要件定義プロセスは省略しても良い、と思っています。
４．システム基本設計
これは主にシステム外部設計に相当します。
このプロセスについては、「準委任と請負のどちらでも良いが、どちらかと言えば準委任を推奨する」という考え方が多いように感じています。
また、大手ＳＩｅｒにおいては、基本は準委任のようです。
（ただし実際は、まだ請負で実施しているケースの方が多いような印象です。）
私は、システムへの要求内容にもよりますが、１００人月未満のプロジェクトであれば基本設計を「請負」にしたい、と考えています。
理由は、それが可能なレベルで「システム要求定義」や「システム要件定義」が実施されているべきである（基本設計書にインプットする要求仕様が十分なレベルであるべき）、ということと、
基本設計の後には構築ベンダーのスイッチが現実的には難しく、よって構築ベンダーにこの段階から成果物責任を負ってほしい、という気持ちがあるからです。
※その他、以下の記事もあわせてご参照下さい。
「基本設計フェーズにおける注意事項など」
５．システム詳細設計～結合テスト
これは「請負」が一般的且つ妥当だと思っています。
６．総合テスト
「総合テスト」とは何か？ということを省略しますが、
原則、基本設計と同じ形態（例えば、基本設計が請負であれば、総合テストも請負）にすることが、一般的且つ妥当だと思っています。
※その他、以下の記事もあわせてご参照下さい。
「ソフトウェアの総合テスト」
７．運用テスト
これは、ユーザ企業が主体で実施すべきです。
よって例えば、構築ベンダーやコンサルタントなどの外部メンバーが、運用テスト計画作成や運用テスト支援作業を実施する場合、契約形態は「準委任」になります。
ただし実際には、導入後の定着化期間を含めた契約期間を設定した上で、「請負」にしているケースが多いように感じています。
※その他、以下の記事もあわせてご参照下さい。
「顧客のシステム受入テスト（運用テスト）」
８．その他、データ移行
このプロセスについてはどうでしょうか？
一般的に、あるべき姿としては「準委任」であると言われる場合が多いように感じています。
私も反対ではないのですが、ポイントはデータの変換作業にあると考えています。
データ変換作業をユーザ企業で実施するのであれば、その後のデータ移行作業は「請負」で良い、と私は思います。
また、データ変換作業を構築ベンダーが実施する場合、その分析は「準委任」、分析結果に基づく変換作業または移行プログラム作成は「請負」、その両方を一つの作業とする場合は「準委任」が好ましいように感じています。
しかし実際には「請負」を採用する場合も多いです。
いずれにしても、データ移行についてユーザ企業と構築ベンダーが契約前に、データ移行の範囲、作業内容（ＷＢＳ）と役割分担を明確化することが重要になります。
※その他、以下の記事もあわせてご参照下さい。
「データ移行は慎重な対応を」
「システム切り替えは慎重な対応を」
以上、システム開発プロセスにおける「準委任」の採否について、私の考え方を整理・紹介してみました。
少しでもご参考になればうれしく思います。
＜関連記事＞
「準委任契約の特性について考える」
「準委任契約の特性のついて考える（その２）」
「準委任契約の特性について考える（その４）」
「超上流工程からシステム運用テストまでにおける考慮事項」
さて以前、「準委任契約の特性について考える」という記事で、私のコンサルティングサービスに照らし合わせた、「準委任契約」に基づく受委託業務の実践面での私の考え方を、
また、前回の「準委任契約の特性のついて考える（その２）」という記事で、準委任契約に関する私の基本的な理解についてご紹介しました。
今回は、ソフトウェア開発の各プロセスにおける「準委任契約」の適用について、私の理解・考え方を整理しておきたいと思います。
ソフトウェア開発のプロセスにおいては、いろいろな整理があります。
経済産業省「情報システムの信頼性向上のための取引慣行・契約に関する研究会」やＩＰＡ「共通フレーム２００７」など、たいへん参考になる、論理的に統合・整理された考え方があります。
しかし、今回は、少しシンプルに、以下のプロセスで整理していきます。
１．システム化企画
２．システム要求定義
３．システム要件定義
４．システム基本設計
５．システム詳細設計～結合テスト
６．総合テスト
７．運用テスト
８．その他、データ移行
１．システム化企画
これは、ユーザ企業が主体となって、事業戦略や事業計画に沿うシステム化構想を策定するプロセスになります。
成果物は、システム化企画書になります。
このプロセスにおいては、コンサルタントなどの外部メンバーは「支援」者に位置づけられ、また、本プロセスの要求仕様や成果物も定まらない状況の場合が非常に多いです。
よって、外部メンバーとの契約は「準委任」になるべきだと、私は考えています。
２．システム要求定義
これは、ユーザ企業が主体となって、システム化構想に沿うシステムへの具体的な要求事項を取りまとめるプロセスになります。
成果物は、システム要求仕様書やシステム提案依頼書になります。
このプロセスでも、あくまでもコンサルタントなどの外部メンバーは「支援」者に位置づけられます。
よって、外部メンバーとの契約は「準委任」になるべきだと、私は考えています
なお、次に記載する「システム要件定義」との違い・区別に関する私の考え方は、
過去の記事「要求定義と要件定義」をご参照願います。
３．システム要件定義
これは、ユーザが主体となりつつ、構築ベンダーがシステム要件を確認し文書化するプロセスになります。
パッケージソフトウェアのフィット＆ギャップも、本プロセスに含まれます。
このプロセスでユーザ企業が構築ベンダーに依存し過ぎると、失敗プロジェクトを生み出す可能性が高くなります。
よって、構築ベンダーとの契約は「準委任」になるべきだと、私は考えています。
なお、例えば既存システムを構築したベンダーへ再構築を委託する場合など、
「概算金額で請負契約を締結してからシステム要件定義を開始する」ケースが多くあります。
これは、ユーザ企業としては、契約金額の上限が確定できる（ように感じられる）というメリットがあり、
また、構築ベンダーとしても、完成までの契約が確定できる（要件定義後にベンダー変更がされにくくなる）というメリットがあります。
以上から、「概算金額で請負契約を締結してからシステム要件定義を開始する」方式は採用され易いパターンなのですが、
その場合、ユーザ企業は「要件を詰め込むだけ詰め込む」
その逆に構築ベンダーは「グレーゾーンの要件は追加扱いにする」
という意識が働くようになり、双方の不信感や不満が高まる危険性があります。
よって、信頼関係があったとしても（逆に信頼関係があるからこそ）、
システム要件定義は「準委任」として実施することをお勧めしたいと思います。
その他、例えば２０人月程度のシステム開発で且つシステム要求定義が一定レベルまでできていれば（システム要求仕様書が十分なレベルで作成できていれば）、
私は、システム要件定義プロセスは省略しても良い、と思っています。
４．システム基本設計
これは主にシステム外部設計に相当します。
このプロセスについては、「準委任と請負のどちらでも良いが、どちらかと言えば準委任を推奨する」という考え方が多いように感じています。
また、大手ＳＩｅｒにおいては、基本は準委任のようです。
（ただし実際は、まだ請負で実施しているケースの方が多いような印象です。）
私は、システムへの要求内容にもよりますが、１００人月未満のプロジェクトであれば基本設計を「請負」にしたい、と考えています。
理由は、それが可能なレベルで「システム要求定義」や「システム要件定義」が実施されているべきである（基本設計書にインプットする要求仕様が十分なレベルであるべき）、ということと、
基本設計の後には構築ベンダーのスイッチが現実的には難しく、よって構築ベンダーにこの段階から成果物責任を負ってほしい、という気持ちがあるからです。
※その他、以下の記事もあわせてご参照下さい。
「基本設計フェーズにおける注意事項など」
５．システム詳細設計～結合テスト
これは「請負」が一般的且つ妥当だと思っています。
６．総合テスト
「総合テスト」とは何か？ということを省略しますが、
原則、基本設計と同じ形態（例えば、基本設計が請負であれば、総合テストも請負）にすることが、一般的且つ妥当だと思っています。
※その他、以下の記事もあわせてご参照下さい。
「ソフトウェアの総合テスト」
７．運用テスト
これは、ユーザ企業が主体で実施すべきです。
よって例えば、構築ベンダーやコンサルタントなどの外部メンバーが、運用テスト計画作成や運用テスト支援作業を実施する場合、契約形態は「準委任」になります。
ただし実際には、導入後の定着化期間を含めた契約期間を設定した上で、「請負」にしているケースが多いように感じています。
※その他、以下の記事もあわせてご参照下さい。
「顧客のシステム受入テスト（運用テスト）」
８．その他、データ移行
このプロセスについてはどうでしょうか？
一般的に、あるべき姿としては「準委任」であると言われる場合が多いように感じています。
私も反対ではないのですが、ポイントはデータの変換作業にあると考えています。
データ変換作業をユーザ企業で実施するのであれば、その後のデータ移行作業は「請負」で良い、と私は思います。
また、データ変換作業を構築ベンダーが実施する場合、その分析は「準委任」、分析結果に基づく変換作業または移行プログラム作成は「請負」、その両方を一つの作業とする場合は「準委任」が好ましいように感じています。
しかし実際には「請負」を採用する場合も多いです。
いずれにしても、データ移行についてユーザ企業と構築ベンダーが契約前に、データ移行の範囲、作業内容（ＷＢＳ）と役割分担を明確化することが重要になります。
※その他、以下の記事もあわせてご参照下さい。
「データ移行は慎重な対応を」
「システム切り替えは慎重な対応を」
以上、システム開発プロセスにおける「準委任」の採否について、私の考え方を整理・紹介してみました。
少しでもご参考になればうれしく思います。
＜関連記事＞
「準委任契約の特性について考える」
「準委任契約の特性のついて考える（その２）」
「準委任契約の特性について考える（その４）」
「超上流工程からシステム運用テストまでにおける考慮事項」