1.　はじめに

デジタルディスラプションによって，従来のサービスが新興企業によって安価に迅速に提供される時代になった．また，2025年の壁を超えるべく企業のデジタルトランスフォーメーション[1]が喫緊の課題であるなか，顧客や市場の声を迅速にサービスやプロダクトに反映していくことの重要性が高まっている．それには，優先順位の高い要求からソフトウェアとして実現し，迅速にリリース可能であるアジャイルソフトウェア開発（以降，アジャイル開発）の導入・推進が必須となる．しかし，日本のアジャイル開発の導入率は大企業を中心に40%程度[2]で，ウォータフォール開発と比較して低い割合にとどまっている．2001年にアジャイルマニフェスト[3]が発表され，海外ではアジャイルコンファレンス^*1のような数千人規模の参加者を擁する巨大な商用コンファレンスが盛況を極める世の中の動向とは異なり，思うようにアジャイル開発を普及・推進できない日本企業も多い．

日本におけるソフトウェア開発は従前より受託開発が主流であり，要件を開発前に確定させるウォータフォール開発が採用されてきた．そして，受託開発を支える契約形態は，民法で規定されている請負契約であった．発注側企業は，契約締結から支払い完了までの契約プロセスと開発プロセスに関連する法制度を遵守するために，請負契約のための制度を策定し，内部統制下にて厳格に運用している．そのような状況下で，開発プロセスが従来と大きく異なるアジャイル開発を適用しようとすると，法制度遵守のための労力が無視できず，アジャイル開発の特徴を生かしきれないという問題があった．つまり，発注側企業がアジャイル開発を導入推進できない大きな理由が契約運用の障壁であった．一方で，アジャイル開発に適した全く新しい契約形態の出現も期待されたが，約120年ぶりに改正され2020年4月から施行されている民法に，新しい契約形態は盛り込まれていない．

発注側企業がアジャイル開発を推進していくには，開発現場が現行制度にあわせるのではなく，開発現場が動きやすい制度設計にすることが必要である．ビジネスアジリティを実現できる組織へ変容させていくには“ボードレベルが関与すると成熟度が上がる”（[4]p.11参照）という報告もあるように，組織を大きく変えるにはトップダウン的なアプローチが必要である．

本稿では，受託契約でのソフトウェア開発においてアジャイル開発を推進していくことを目的とし，発注側企業の目線で課題を明らかにする．また，課題を解決するために，準委任契約（履行割合型）をベースとしたアジャイル開発契約制度設計と運用方法（契約スキーム）を提案する．さらに，提案契約スキームによる運用トライアルを行い，契約関連プロセスが開発現場の負荷とならず迅速に遂行できることとアジャイル開発のメリットが保たれることを確認した．

以降，2章では関連動向と本検討の前提条件，3章では法制度に関連したアジャイル開発の課題，4章では法制度遵守を念頭においた契約スキームの提案，5章ではトライアル結果と考察，6章でまとめと今後の課題について述べる．

2.　関連動向と前提条件

2.1　関連動向と本検討の関係

アジャイル開発のための契約形態は，早くから公的機関にて検討されてきた[5], [6], [7]．2012年に情報処理推進機構（以降，IPA）から出されたモデル契約書[5]は請負もしくは準委任契約のどちらにも対応可能で，全体の期間と金額を基本契約で締結し，個別契約（スクラム^*2におけるスプリント^*3に相当）を都度締結する内容となっている．加えて，アジャイル開発のスプリント計画やレビューを想定した連絡調整会議を設置していた．情報処理学会情報処理に関する法的問題（LIP）研究グループ（以降，LIP）でも当初は同様のアプローチ[8]で検討を進めていた．しかし，多くの発注企業では契約締結に一定の日数が必要であり，このような短期間に複数回の契約締結を繰り返す方法は現実的ではなかった．

また，2020年にIPAおよびLIPから最新のアジャイル開発契約の雛型[6], [7]が公開された．アジャイル開発の体制と，バックログの優先順位に基づく開発であることが強調されている．旧モデルにあった基本契約・個別契約の考え方は採用せず，準委任契約1本で締結する方式に修正された．また，連絡調整会議は削除されている．

筆者らはIPAやLIPの取り組みを参考にしつつ，発注側企業として現行法制度を遵守する場合のアジャイル開発契約運用の課題を抽出し，対応策を検討してきた[9], [10]．図1に実効的な契約書と内部運用の関係を示す．実効的な契約書には，契約書雛型をベースに，受発注双方で合意した利害に関係する詳細な契約条件や，内部運用を反映した条文が盛り込まれる．内部運用とは法制度や企業の内部統制を遵守した一連の契約制度運用である．つまり，実効的な契約書と運用は併せて検討しなければならない．筆者らが4章で提案する契約スキームは，IPA [6]やLIP [7]の契約の考え方（契約書雛型）に対して発注側視点から運用面を補完する一例として位置付ける．

2.2　本稿で想定するアジャイル開発

図2に本稿で想定するアジャイル開発をウォータフォール開発と比較して示す．開発前に要件が確定し，開発後に一度だけソフトウェアをデリバリ（給付）するウォータフォール開発に対して，アジャイル開発は下記の特徴を持つ．

• 1.要件が進化する．
• 2.ソフトウェアが継続的にデリバリされる．
• 3.開発メンバ間にて密なコミュニケーションが行われる．

これらは，ウォータフォール型開発には無い特徴なので，従来の契約運用にのっとってアジャイル開発をすると，発注側企業において様々な課題を生じる．詳細は3章で述べる．

2.3　途上解としての準委任契約

2020年にIPAやLIPから公表されたアジャイル開発の雛型[6], [7]は，準委任契約を採用している．筆者らも同様に準委任契約を採用する．

発注者視点でその理由について述べる．アジャイル開発が十分浸透している欧米ではインハウス，すなわち内製での開発が主流である．しかし，長年にわたって受託契約でのソフトウェア開発に頼ってきた日本のユーザ企業（発注側企業）が内製主体のアジャイル開発に移行していくには，開発者育成という課題をクリアする必要がある．現状では，まだまだ受託契約に頼らざるを得ない．

表1に受託でのソフトウェア開発の代表的な契約である請負契約，準委任契約，派遣契約の全般的な特徴を記す．前二者は民法で，後者は労働者派遣法でそれぞれ規定されている．

アジャイル開発の特徴である継続的デリバリと要件進化が可能な受託契約としては，発注者が受託者側の作業者に直接指示ができる派遣契約が最適とされる．しかし，受注会社が多次請けを採用している場合，たとえば1次請けの会社が2次請けの要員を発注側企業に派遣することはできない（労働者派遣法）．受託側企業が多次請けをしていない場合でも，人貸しに終始し，収益の増大につながらないため，受託側企業は派遣契約による社員の専属専任を好まない傾向がある．結果的に，発注側企業は，派遣契約では開発体制を構築できない．

請負契約は契約前に要件が確定していることが前提であるので，要件が進化するアジャイル開発には根本から馴染まない．繰り返されるデリバリ時に発生する受注側の社内検査稼働や，対価の支払われない瑕疵対応稼働も開発と並行して発生するため，受託側の稼働がひっ迫する．加えて，要件が定まらないままで瑕疵責任^*4を問われる請負契約は受託側のリスクが高く，採用に至らない場合が多い．

一方で，準委任契約は作業内容の確定と作業に対する受託側の善管注意義務はあるものの，成果物に対する完成責任および瑕疵責任は負わない契約である．バグ修正依頼も含めた頻繁なフィードバックに逐次的にソフトウェアを開発するには都合がよい．よって，インハウスでの開発が可能になるまでの当面の解として本検討に採用した．

その他の前提条件としては，3～6ヶ月の契約期間，数名からなる開発チームでのスクラム[11]での開発を想定している．また，契約は発注側と1次請け間を対象とする．迅速性という観点では，何らかの形で会計・契約のための業務アプリケーションを利用できることを想定している．

3.　法制度遵守にかかわる課題

発注側企業が留意しなければならない主な法制度のうち，開発プロセスがアジャイル型になることで（従来型の）契約運用に課題を生じる観点を以下に列記する．

• ・適切な作業指示（下請法）
• ・期限内の支払い（下請法）
• ・ソフトウェアの適切な資産化（税法）
• ・偽装請負リスク回避（労働者派遣法）

図3にこれらの法制度の観点を前述のアジャイル開発の特徴と関連付けて示す．以降に課題の詳細を述べる．

3.1　要件進化と適切な作業指示

下請法は，買いたたきや支払い遅延によって多大な影響を被る，立場の弱い受託会社を保護することを目的とした法律である[12], [13]．発注側企業は，適切な作業指示と期限内の支払いを求められる．

アジャイル開発にて要件が進化する状況下においても，下請法適用会社に対して，支払い期限と発注内容を含む事項の発注書面化と期限内の支払いの義務がある[12], [13]．スプリントごとに要件が進化し作業内容が変わっていくので，発注側企業ではスプリントごとの作業指示が必要である．

3.2　継続的デリバリと期限内の支払い

さらに，下請法では，デリバリされるソフトウェアの対価を給付より60日以内に支払う義務があることを規定している．

アジャイル開発ではソフトウェアは継続的にデリバリされる．次節で述べる「資産化」を適切にするために，発注側企業ではスプリントごとに支払いが必要である．ここで留意しなければいけないのは，支払いの期日の基点となる「給付日」をどこに設定するかである．請負契約においては納品・検収を基点とするのに対し，準委任契約では納品が無いので給付日をどの時点にするかを見極めなければならない．

3.3　継続的デリバリと適切な資産化

開発して取得したソフトウェアは税法上資産として計上する必要がある．資産は企業の所得とみなされ，所得に対して法人税等が課される．この資産計上を「資産化」という．資産化後に使用開始されると減価償却が始まる．よって，発注側企業では適切なタイミングで資産化する必要がある．資産化額はソフトウェアの発注費用や発注側企業の労務費等が合算されて計上される．

アジャイル開発では継続的デリバリによってサービスに利用するソフトウェアが逐次生産される．すなわち，サービス利用を目的としたソフトウェアがリリースされるたびに発注側企業では資産化が必要になる．

3.4　密なコミュニケーションと偽装請負リスク回避

本来，派遣契約を締結すべきところを請負契約や準委任契約（両者をまとめて法律的に「請負」と記載）で契約すると“請負を偽装している”とみなされ，労働者派遣法等の罰則対象になる．厚生労働省のガイドライン[14]で定められている「注文主と労務者に指揮命令関係を生じない」ことが重要である．

アジャイル開発ではウォータフォール開発よりも密なコミュニケーションが想定される．その場合においても，指揮命令関係を生じさせないように，受発注双方の企業でより注意を払う必要がある．

4.　課題解決のための契約スキーム

4.1　概要

前章で述べた課題を解決するために，筆者らはアジャイル開発に特化した契約プロセス（契約スキーム）を策定した．契約スキームとは契約締結から支払いまでの一連のプロセス群で，後に実効的な契約書に反映される．

図4にスキーム概要を示す．本契約スキームは，一契約に対して複数の個別業務を規定することを最大の特徴とする．個別業務とは，一定の期間（スプリント等）におけるソフトウェア開発に資するすべての作業の集合体である．以下に契約スキームの概要を列挙する．

• ・開発対象全体の契約期間および概算金額上限を契約書にて締結
• ・契約後に個別業務を複数回設定
• ・個別業務の作業内容を「個別業務指示書」で定義し受発注双方で合意
• ・個別業務の精算根拠として受注側が「作業終了報告書」に実作業時間を記載，発注側が確認

4.2　個別業務ごとの作業指示

個別業務の概念を用いることで，要件が進化していく状況でも，下請法上の適切な作業指示が可能となる．また，従来手法の基本契約を締結した後に複数回の個別契約をする場合[5], [8]と比較し，本方式では，契約は1回であるので，契約行為にかかわる稼働の軽減が期待できる．

個別業務期間中に新たな作業や変更が生じた場合は，4.5節で述べる連絡調整会議を開催し，発注者と受注者が合意のうえ個別業務指示書を変更できる．

筆者らの組織では，個別業務指示書は下請法の3条書面に必要な情報をすべて盛り込み，3条書面として扱った．作業指示の粒度は特定の機能を構築するために必要となる作業まで細分化する．分析・検討・設計，コーディング，検証，環境構築，文書作成，不具合対応，会議体などの典型的な作業項目をあらかじめ作業カテゴリとして定義し，機能名と作業カテゴリによって「〇〇機能の検証作業」などの明確な作業指示を行った．なお，個別業務指示書と作業終了報告書をまとめて「個別業務指示書兼作業終了報告書」として運用している．

4.3　個別業務ごとの期限内支払い

下請法上の期限内の支払いは，個別業務ごとに支払い期限を設定することで実現する．

筆者らの組織では，作業実績として計上された全作業時間に対して支払いを行った．具体的には個別業務指示書の内容に対する受託側の実作業時間が作業終了報告書に記載され，個別業務の支払額として確定する．これは，作業に対して受託側がコミットした予定稼働分（金額）を支払う方[15]や，定型業務委託などの一般的な準委任契約で用いられる月極め定額制とは異なる．

さらに，筆者らの組織では支払いの基点となる給付日を（個別業務終了日や契約の終了日ではなく）個別業務開始日とした．これは，「受託側作業によって作成されたコードを含むあらゆる情報成果物は常時発注側企業の管理下にある」[12], [13]という前提に立っている．これにより，成果物であるソフトウェアを発注側がいつでもサービスへ導入することができる．支払い額の決定，請求書発行，支払などの運用を考慮すると，60日以内の期限を遵守するには，個別業務期間は最長でも4週間程度である．

4.4　個別業務ごとの適切な資産化

法人税等の算出を適切に行うことに加え，ソフトウェアをタイムリーにサービスへ導入するために，個別業務ごとに給付されたソフトウェアを資産化し，使用開始する．個別業務ごとに確定した受託先への支払い額と内製労務費を合算して，個別業務終了ごとに資産化する．ただし，すぐにはサービス導入せず，後日一部の機能だけをサービスに導入する場合は，開発終了後にその機能のみを資産計上することもできる．

4.5　連絡調整会議の設置による偽装請負リスクの緩和

個別業務内容の合意，作業責任者への作業指示，プロジェクトの進捗や報告，問題点の洗い出しなどの場として連絡調整会議を設ける．「注文主と労務者に指揮命令関係を生じないこと」を徹底したコミュニケーションを意識付けることが狙いである．ただし，連絡調整会議を設けるだけでは偽装請負（労働者派遣法違反）リスク回避にはならない．

4.6　実効的な契約書への落とし込み

運用や受発注間での利害関係が整理され，契約条文が詳細化される．表2に契約書条文項目例を示す．本契約スキームが関連する部分とそれ以外からなる．契約スキームを反映した条文には，個別業務の概念を用いること，（筆者らの組織の場合は）個別業務指示書で指示した業務に対する対価を実績払いすること，個別業務開始から60日以内に支払いが行われることなどが記載される．詳細化された契約条文は受発注双方で合意され，運用可能な契約書が完成する．

5.　トライアル

5.1　トライアルの目的

前章で述べた契約スキームの運用可能性を評価するために，アジャイル準委任契約書トライアル版を作成し，トライアルに賛同した受託会社と契約内容を事前に合意したうえで，2018年8月～2020年3月にトライアルを実施した．トライアルでは以下の3点を確認した．

• ・本契約スキーム運用の迅速性
• ・本契約スキームでのアジャイル開発の効果
• ・本契約スキームでのアジャイル開発の生産性

アジャイル開発の生産性評価については文献[16]に詳細が述べられているため，本稿では割愛する．

5.2　運用フロー

図5に運用フローの概略を示す．発注側の開発主管組織が契約伝票を起票し，契約・会計担当組織が契約行為や支払いを実施する．契約締結は1回のみで，他の運用中の契約形態と同じである．一方，支払いは各個別業務の終了時に行われる．また，本格運用を想定し，全案件を下請法対応とすることで，対応漏れリスクを回避した．

5.3　トライアル案件

個別業務が1回以上終了した案件が延べ10件に達した2019年6月末時点でトライアルの評価を実施した（開発終了7件，継続中3件）．表3に10案件^*5のサマリを記載する．

それぞれの代表的な個別業務期間は2–4週間であった．案件のドメイン（ソフトウェアの種別）はネットワークシステム，業務支援ツール，ソフトウェア開発支援ツールの3カテゴリであった．参考までに総開発規模は数KLOC（Kilo Lines of Code）から50KLOCと幅広かった．

5.4　運用の迅速性

一連の契約処理，支払い処理，資産化処理に費やした作業時間について，2019年6月末までに終了した7案件5組織が主観的に評価をした結果を表4に記す．評価「3」が請負契約と同程度の作業時間，「1」，「2」はより多くの作業時間を有し，「4」，「5」は作業時間がより少なかったことを示す．

最初の2組織（P1，P2）の評価が低いのは，2018年に更改された契約・会計業務アプリケーションプログラムの不具合に起因する．不具合が修正された後にトライアルに参加した3組織（P3–P5）は，請負契約と同程度の作業時間であったという主観評価を得た．

契約処理に要する作業時間は，他の請負契約等と同じスピード感で実施できた．個別業務ごとに支払いが生じることついては，そもそも納品行為が無いために請負契約では必須となる納品検査や納品証跡作成作業時間が省かれ，追加の負荷にならなかったと考えられる．受託側からは実績作業時間の合意から請求書発行までの期間が短いという点以外は特に重大なコメントはなかった．

5.5　アジャイル開発の効果

5.4節と同じ5組織に対して発注側企業の担当者にヒアリングした結果の分布を図6に示す．回答率は100%である．ヒアリングの観点は(1)スピード，(2)ビジネス価値，(3)チーム/ステークホルダ[17]に関するもので主観評価にて評価した．評価は5段階評価で行われ，評価「3」を「アジャイル開発として期待どおりであった」とした．点数が多いほど満足度が高い．

その結果，すべての観点においてアジャイル開発として期待どおり（「3」）以上の回答が得られた．さらに，ビジネス価値観点における「ムダな開発はしなかった」「優先順位（価値）の高いものから提供できた」，チーム/ステークホルダとの関係の観点における「受発注会社間の距離感が縮まった」において，「4」もしくは「5」の回答が得られ，予想以上の満足度の高さがうかがえた．5.4節の結果と合わせて，アジャイル開発の効果を損なうことなく契約締結から支払までのプロセスが迅速に運用できたと言える．

5.6　総括と課題

2020年1月末時点で27件が契約締結に至り，特にトラブルもなく遂行され，2020年度内に全件完了した．本検討の目的である「アジャイル開発の導入・推進」をトップダウン的な契約制度設計によって達成できた．また，トライアル結果から，法制度遵守と運用の迅速性，アジャイル開発の効果のすべてが満足できる結果になった．本結果および生産性評価[16]（本文では割愛）に基づき，「アジャイル準委任契約」を2020年度から本格運用することとなった．

しかし，依然としていくつかの課題が残った．まず，個別業務ごとの支払い，資産化のためには個別業務の最短期間は，受託側の請求書発出から始まる一連の処理の頻度を考慮すると，1–2週間が限界と思われる．資産化のタイミングは個別業務期間よりは短くはならないので，サービス導入の最速のサイクルは個別業務の期間，すなわち1–2週間となる．よって，デイリーリリースは事実上不可能である．これは，顧客や市場に対して，より迅速な価値提供をする場合に，クリティカルな課題となる．また，筆者らの組織のように給付日を個別業務開始日とする場合，下請法で規定された60日以内の支払いを実現するためには，4週間を超える個別業務は支払い期限までの余裕が無いため，現実的ではない．加えて，案件ごとに最長でも4週間ごとの支払い処理が生じるため，案件数が劇的に増大した場合に，会計業務がひっ迫する恐れがある．

帳票での作業指示，作業確認にも個別業務期間が短いほど稼働が無視できない．将来的にはプロジェクト管理アプリケーションプログラムへの投入事項をそのまま監査証跡として扱えることが望まれる．

密なコミュニケーションについては，ウォータフォール開発に比較してはるかに高い頻度でなされるチーム内のコミュニケーションをどこまで厳密に管理するかという課題は依然として残った．

筆者らの組織は対応できていたが，一つの契約と複数の支払いを紐づけて管理できる契約・会計業務アプリケーションプログラムは必須である．対応していない場合は，制度設計と契約・会計業務アプリケーションプログラムの検討・構築・改修は同時に進める必要がある．

6.　まとめと提言

デジタルディスラプションの時代が到来するなかで，アジャイル開発の促進を目的とし，開発者が安心安全にアジャイル開発を遂行できるよう，発注者側が現行法制度の遵守と運用の迅速性を両立させるための契約スキームについて述べた．準委任契約を規定している民法に加え，アジャイル開発の特徴に関連して，特に下請法，税法，労働者派遣法に留意する必要があることを明らかにした．2018年度から実施しているアジャイル契約トライアルにおいて，法制度遵守とアジャアル開発の効果，運用の迅速性をともに実現できることを実証した．また，トップダウン的な制度設計によってアジャイル開発が促進できることを示した．

一方で，デイリーリリースのような顧客や市場へのより迅速な価値提供，短期間での都度の支払いを実施する会計業務，密なコミュニケーションにおいて，限界や課題があることを述べた．デジタルディスラプション時代を日本企業が生き抜くためには，適切な運用稼働での顧客や市場へのさらなる迅速な価値提供が望まれる．現行法を遵守しこれらを実現するための公的ガイドラインの整備が早急に望まれる．

謝辞　本スキームを策定するのに協働いただいたNTT法務担当，研究企画部門，知財センタ，契約センタ，情報ネットワーク総合研究所企画部および会計担当，トライアルに参加いただいたNTT研究所の所員，受託会社であるNTTテクノクロス株式会社，NTTアドバンステクノロジ株式会社，NTT-ATテクノコミュニケーションズ株式会社の関係者に感謝申し上げる．また，受発注におけるアジャイル開発の課題に対して議論いただいた株式会社NTTデータ，NTTコムウェア株式会社，NTTレゾナント株式会社他グループ関係各社に感謝する．