デジタルプラクティス Vol.11 No.2 (Apr. 2020)

アジャイル開発の理解を深めつつ
契約の仕組みとモデルを整える 

秦泉寺久美(日本電信電話(株)),高岡詠子(上智大学),平岡 敦(たつき総合法律事務所)
司会 藤瀬哲朗((株)三菱総合研究所),山下博之((独)情報処理推進機構)

 日本でアジャイル開発が期待したほど普及していない原因の1つとして,契約にかかわる問題が挙げられる.日本では,IT人材の所属割合がIT企業が72%に対しユーザ企業が28%と,米国等の欧米主要国に比べてIT企業所属の比率がかなり高い[1]ことから,ITシステム開発では契約の締結を避けられない.しかし,アジャイル開発には従来のウォーターフォール型開発における契約の仕組みをそのまま適用することはできない.そのため,多くの企業等では,アジャイル開発は社内での試行にとどまり,本格的な導入には至っていないのが現状である.そこで,本特集における掲載論文を補完するために,アジャイル開発の契約に焦点を当て,その問題に取り組む実務者や研究者等が集まり,意見交換を行った.

飯塚敏浩
秦泉寺久美(日本電信電話株式会社)
日本電信電話株式会社(NTT)ソフトウェアイノベーションセンタ 主任研究員.早大大学院理工学研究科修了.NTT研究所での映像処理・符号化・通信の研究開発,事業会社での政府系大規模ネットワームシステム開発を経て,現在は開発標準の策定などNTT研究所でのソフトウェア工学の現場実践に従事.博士(国際情報通信学).
小松孝司
高岡詠子(上智大学)
慶應義塾大学理工学部数理科学科卒業,同大大学院理工学研究科計算機科学専攻博士課程修了,博士(工学).現在,上智大学理工学部教授.専門分野は医療,教育分野等におけるWebアプリ/スマホアプリ等開発と運用.2007年本会山下記念研究賞受賞,2013年度本会学会活動貢献賞受賞,主な著書:『チューリングの計算理論入門』,『シャノンの情報理論入門』(講談社ブルーバックス),『計算の科学と手引き』(2019),『計算事始め』(2013)および『情報科学の基礎』(2007).
長谷川好範
平岡 敦(たつき総合法律事務所)
1990年早稲田大学第一文学部哲学科卒業.2019年筑波大学大学大学院ビジネス科学研究科企業法学専攻博士前期課程修了.修士(法学).1990年から(株)シーエーシーに勤務.2000年司法試験合格,2002年から弁護士(たつき総合法律事務所),現在に至る.日弁連弁護士業務改革委員会副委員長,第二東京弁護士会業革委員会委員長,情報処理推進機構(IPA)社会実装推進委員会委員・情報処理技術者試験委員,内閣府日本経済再生本部裁判手続等のIT化検討会委員等.
立木 豪
司会:藤瀬哲朗(三菱総合研究所)
(株)三菱総合研究所原子力安全事業本部 兼 科学・安全事業本部.電気通信大学大学院修士課程修了後,三菱総合研究所入社,現在に至る((財)新世代コンピュータ技術開発機構研究所主席研究員,慶應義塾大学SFC研究所訪問所員,同大学SDM研究所研究員,(独)情報処理推進機構ソフトウェア・エンジニアリング・センター主査).高性能計算にかかわる研究,ソフトウェア工学および高信頼性システムの調査研究,研究開発事業マネジメント業務に従事.
有馬英樹
司会:山下博之((独)情報処理推進機構)
1981年京都大学大学院修士課程(情報工学)修了.同年,日本電信電話公社(現NTT)入社.2003年に(株)NTTデータに転籍.2004~2008年,JSTに出向.2009年に(株)NTTデータアイ入社,同時にIPAに出向.ソフトウェアエンジニアリングやモデル契約関連の業務に従事.2003~2008年,科学技術振興調整費プログラムオフィサー.2010~2014年,本会電子化知的財産・社会基盤研究会主査.2007~2015年,情報規格調査会SC6専門委員会委員長.IEEE,本会各会員.

参加者の取り組み紹介

藤瀬:デジタルプラクティス誌編集委員の藤瀬です.本日は,お忙しいところをお集まりいただき,ありがとうございます.今回のアジャイル開発の特集においては,各社における開発手法上の工夫を実践した取り組み等に関する多くの論文が寄せられましたが,アジャイル開発の導入を阻害する要因の1つと言われている契約に関するものは残念ながらありません.そこでこの座談会ではその問題をテーマとして取り上げました.ここには,特にアジャイル開発における契約にかかわる取り組みを行われている方々にお集まりいただきましたが,まずみなさま方の取り組み内容について簡単にご紹介願います.

秦泉寺:私は,アジャイル開発の推進に関するNTTグループの議論に参加する中で,ユーザ企業(発注者)の立場で,研究所におけるアジャイル開発促進のための契約の在り方と運用について企画,法務,知財,契約,会計の各々の担当と検討を行ってきました.私は開発現場の立場で参加しました.R&D(Research and Development:研究開発)は試行錯誤の面があり,アジャイル開発がフィットすることが多いのです.後に詳しく紹介しますが,契約書策定とコンプライアンスを遵守した運用設計を行い,開発現場のアジリティとアジャイル開発の効果を損なわない運用を実証するためにトライアルを実施しました.

高岡:私は,情報処理学会の「情報処理に関する法的問題研究グループ(LIP)」の主査を務めています.LIPでは,アジャイル開発のモデル契約書の作成を行っています.2018年の全国大会で初版を紹介したのですが,それに対する意見を踏まえた新しい版が完成したところです.

平岡:私は,弁護士として,契約や紛争解決等の法的実務に携わっていますが,高岡先生のLIPのメンバとして,アジャイル開発のモデル契約作成にも参加しています.

山下:私は,情報処理推進機構(IPA)が行っているモデル契約見直しの検討のうちで,デジタルトランスフォーメーション(DX)時代に求められるアジャイル開発等の新しい開発形態への対応についての検討をとりまとめています.具体的には,IPAが2012年に公開した「非ウォーターフォール型開発に適したモデル契約書」[2]の改定を行っています.そのために設置している「DX対応モデル契約見直し検討WG」には,高岡先生と平岡弁護士にも主査や委員としてお世話になっています.

アジャイル開発の導入を阻害する契約関連の課題

藤瀬:ありがとうございます.それぞれの立場が理解できたと思います.それでは,ここでの議論の始めとして,アジャイル開発の導入を阻害している契約にかかわる課題について,それぞれのご経験をもとにお話しいただけないでしょうか.どなたからでも結構です.

平岡:ここでの議論を始めるにあたっての共通認識を確認する意味で,まず,ソフトウェア開発における契約について,アジャイル開発との関連性から整理しておきたいと思います.

受託でのソフトウェア開発における契約類型としては,請負,準委任,派遣の3種があります.請負は一定の仕事を完成させるもの,準委任は一定の事務を行うものであり,仕事や事務の内容がソフトウェア開発ということです.派遣は,仕事や事務のために人そのものを行かせるものです.請負契約では,契約時に仕事の内容,すなわち開発ソフトウェアの仕様が固まっている必要がありますが,アジャイル開発では,必ずしもすべてが確定しているわけではないし,固まった部分も途中で変更されることがよくあります.これに対して準委任契約では,ソフトウェア開発を行うもののその完成を保証するものではないため,発注者にはリスクが伴います.一方,派遣契約にはこのような問題はありませんが,受託側にノウハウが残りにくいことから,開発企業としては受託しない傾向にあります.

高岡:開発途中での頻繁な要求変更の許容や継続的デリバリを特徴とするアジャイル開発の受発注形態としては,派遣契約が最適と思うのですが,残念ですね.

山下:開発受託企業のビジネスとしては,いわゆる“人貸し”は好まないということですね.

秦泉寺:請負契約は,契約前にすべての要求が確定していることが前提なので,要求が進化するアジャイル開発には根本から馴染まないですね.請負契約を複数回締結することで要求の進化に対応することも考えられますが,納品時の受注側の社内検査の稼働,何度も契約を締結することによる契約稼働によって運用のアジリティが犠牲となることが予想されます.

平岡:規模の大きな企業ほど,一般に,社内決裁などに時間がかかるため,短期間に何回も契約を締結する運用は難しいですね.

山下:準委任契約は要求進化と継続的デリバリに親和性が高いので,最近のアジャイル開発では,準委任契約を採用するところが多いと聞いています.

平岡:企業取引で契約書を取り交わす目的は,合意内容を明確にして紛争を予防するとともに,万が一紛争が生じたときに権利・義務を明確にして裁判を通じて紛争を解決することにあります.ところが,アジャイル開発の場合,開発対象は刻々と変容し,また,開発にかかわるプレイヤ(プロダクトオーナー(PO),スクラムマスター,スクラムチーム,開発チーム,等)が従来の請負や準委任の典型的な当事者とは一致しないという特殊な環境の下で行うため,合意内容の確定や権利・義務の構成は,通常の開発委託の契約(請負,委任等)がすんなり当てはまらないんです.

高岡:無理に典型的な契約を当てはめてしまうと,アジャイルの思想がなし崩しになりかねないリスクがありますしね.

山下:そうなんです.そういった問題をどのような工夫により解決するかが,モデル契約の作成においては最も悩んでいるところなのですね.

秦泉寺:従来型の契約の類型および運用がアジャイル開発になじまないことに加え,ソフトウェア開発の取引とその周辺に関する社内の運用方法を策定することが課題でした.加えて,NTTの研究開発のスキームがベースにあって,契約書はそれを反映したものになっていないといけない.そのため,契約書そのものについては,IPAから公表されているひな型をそのまま使えるわけではなく,NTTの制度運用を反映し,さらにコンプライアンスを遵守するための運用を盛り込んだ契約書にカスタマイズして,NTT研究所はこれで行きましょう,となるところまでがすごく厳しかったです.

平岡:確かに,先ほども言いましたが,社内の諸制度がしっかりしている企業ほど,新しい概念を導入することは難しいですね.

髙岡:社内の抵抗も大きいのではないかと思います.

秦泉寺:はい.さらに,契約書以外についても,運用に関するポイントが3つありました.1つは,発注側の立場なので,税制です.つまり,特にサービスに寄与するソフトウェアを作成した場合,サービスに導入する前に固定資産化しないといけないのですよ.開発したソフトウェアを継続的に顧客向けサービスに使用するとなると,必ずそれぞれのリリースタイミングで資産化が必要になります.それをどのように,どういう契機でやっていくのかということが課題でした.

平岡:モデル契約の検討で税制の話は?

山下:IPAでは議論していないですね.

高岡:LIPでもあまり考えていなかったです.

秦泉寺:あるアジャイル開発を推進している受注側企業に資産化の話をしたときに,何ですかそれってって言われてしまったことがあるのです.ということは,受注側からすると見えづらいところかもしれませんね.発注側は絶対にそれはやらないといけないのですけれども.

平岡:契約書の中にそれが出てくるかというと,あまり…….

秦泉寺:出てこない.

高岡:出てこないですよね.

秦泉寺:運用に関するポイントの2番目は,下請法ですね.まだ下請法に該当するような企業とアジャイル開発をやっているわけではないのですけれども,今後はたぶんAIが得意な小規模な企業と協働する機会は増えていくと想像されましたのでその対応について検討しました.下請法では,作業指示と作業に対する支払の期限を書面としてその都度出すこと,が求められているのですね.これを,短期間ごとに個別の契約を繰り返し結ぶようなスタイルにおいて,契約の締結そのものにそれなりの時間を要する中で,どうクリアしていくかということが課題でした.

山下:アジャイルの理念からすれば,開発ソフトウェアについて市場からのフィードバックを素早く得るためにすぐに現場で使ってもらうことを前提にしているので,そうなると納品が発生して,当然そうすると資産にもなっている,償却もしていかなければいけない,下請法的には2カ月以内に支払いをしないといけないという話ですよね.そこを書面で発注書というのがないといけないという…….

秦泉寺:そうです,その通りです.

山下:そのようなところを短いサイクルで生真面目にまわしていくことは,恐らく一般の,特に大企業の法務部門では,不可能ですよね.

秦泉寺:そうですね.

山下:だから特別な何か仕組みを作って,簡易にまわしていく制度が,これは契約というよりも運用ができていないと.

秦泉寺:そうです.

平岡:現実には非常に難しいですね.契約書には書いていないけれども,そういう運用体制を作る,それを簡易にやれるような,ワークフローのシステムを作っていくということをお勧めする,というかたちになるのでしょうね.契約の中で明示的にアジャイル開発方式を採用すると明言してあり,できれば何らかの具体的な開発標準のようなものが参照されていれば,契約本文中に運用体制が書かれていなくても,契約の変更なしに運用で回していくことも可能になるかもしれません.

秦泉寺:3つ目の運用に関するポイントは,これは請負でも同様なのですけれども,偽装請負リスク回避に関することですね.これについては皆さんが悩まれているようでして,アジャイル開発は密なコミュニケーションをとることを最大の特徴としているので,どうやってその課題をクリアしていくんだと.以上の3つ,税制対応,下請法対応,偽装請負リスク回避が,契約の周辺にある運用上の主な課題ということになります.

平岡:要は,組織固有の内部統制に準じ,契約書はその運用を反映し,各種帳票は外部監査に耐えられるものでなければならない.同時に,制度運用が開発現場のアジリティを損なうものではあってはならない.こういうことでしょうか.

藤瀬:ありがとうございます.それでは,以降,これまでに挙げられた課題についてひとつひとつ議論していきましょう.

アジャイル開発の理解不足も一因

高岡:それぞれの課題について議論する前に,こういったことが課題として挙げられるということ,あるいはアジャイル開発がうまくいかないということの根本には,アジャイル開発についての理解不足があるような気がするのですけど.

山下:そうですね.そもそもアジャイルという新しい開発スタイルがどのようなものかについて,正しく理解されていないことも導入を妨げているということですね.そのために,従来の契約との整合がとれずに契約に踏み切れなかったり,ウォーターフォール型の場合と同様の契約で開発を始めてもうまく進まずに途中で頓挫したりする.

平岡:実際のトラブル事例を見ても,ユーザ企業,ベンダ企業それぞれに問題があるのですが,当事者間の理解不足のまま開発を開始していることが原因となっているケースが多いですね.

高岡:よく「なんちゃってアジャイル」とか言われますけど,アジャイルっぽいことをしているけれどそれはアジャイルではない,というのがよくありますね.そういう人たちに本来のアジャイルがどういうものかを分かってもらうことも重要ですね.

山下:はい.IPAではアジャイル開発のモデル契約について検討しましたが,契約の前に,アジャイルについて適切に理解することが重要だという共通認識が検討メンバにあって,そのための啓発メッセージも発信しているところです.

秦泉寺:アジャイルの理解不足と言えば,企業のいろいろな部門がアジャイル開発を理解していないと運用が回らないと思いました.今回の取り組みで分かったのですが,アジャイルは従来のウォーターフォール型とは異なる新しいスタイルなのに,ウォーターフォールの考え方から抜け出せない.いろんなことをどうしてもウォーターフォールの枠組みで考えてしまう.やはり,そこには無理があり,ゆがみが生じますね.

山下:アジャイル開発を多く受託されている,あるベンダの方から聞いたのですが,社内ルールとして請負契約しかできないから,請負契約でアジャイル開発をやってほしい,と言われたことがあるそうです.製造業の会社だそうです.

秦泉寺:経営層からマインドを変える必要がありますね.

高岡:確かにそう思います.

アジャイル開発にかかわる社内の制度設計例

藤瀬:その話題については今日はここまでにして,それでは秦泉寺さん,先ほど紹介されたNTT研究所でのアジャイル開発促進のための制度設計について,詳しく説明願います.

秦泉寺:はい,アジャイル開発の特徴に関連した法制度面において,特に留意しなければいけないと思われる点は,先ほどお話ししたように,下請法,税制,偽装請負リスク回避の3点です.すなわち,下請法適用会社に対して,発注側は適切な作業指示と期支払をしなければならないとされています.具体的には,支払期限と発注内容を含む事項の発注書面化と給付から60日以内の支払義務があります.また,アジャイル開発では継続的デリバリによってサービスに利用するソフトウェアが逐次生産されるため,これらソフトウェアの適切な資産化が必要です.そして,厚生労働省のガイド[3]では,(アジャイル開発の場合に限らず)労働者派遣法に抵触しないために,「注文主と労務者に指揮命令関係を生じない」ことを基本としています.受発注双方の作業責任者を通じたコミュニケーションが必要ということです.

高岡:そういえば,2年前の情報処理学会全国大会のLIPセッションでは,偽装請負に関する議論がたくさんありましたね.

平岡:そうでした.

秦泉寺:はい,私も聴いていました.話を続けますと,これらの課題への対応方法について説明する前に,前提として,私どもの契約スキームを紹介した方が理解しやすいと思います.NTT研究所の契約スキームでは,開発対象全体の契約期間および概算金額を合意した準委任契約を1本締結した上で,その契約の下で,一定期間ごとに個別業務を設定し,個別業務での作業指示と支払を繰り返します.具体的には,個別業務開始時に作業内容を「個別業務指示書」で定義し連絡調整会議の場にて受発注双方で合意する,支払時には個別業務の精算根拠として実稼働時間を記載した「作業終了報告書」を連絡調整会議にて発注側が確認する,個別業務期間中に新たな作業が生じた場合は,その都度連絡調整会議を開催し,発注者と受注者が合意の上,個別業務指示書を修正する,というものです.

平岡:民法には,準委任とはいっても,善良な管理者の注意義務をもって債務を履行しなければならないという規定があります.

秦泉寺:そうですね.何を指示したのかを監査に耐えられるだけの証跡として残す必要があると私たちは考えていました.だからそういうような形式にしています.さて,それでは,各課題への具体的対応方法について説明します.

まず,下請法を遵守するために,個別業務開始日から60日以内に支払を実施する必要がありますが,精算額の決定,請求書発行,支払などの個別業務終了以降の社内プロセスを考慮すると,60日以内の期限を遵守するには,個別業務期間,すなわち1イテレーションの期間は最長でも4週間程度としなければいけないことが分かりました.したがって,これをルール化しました.

次に,資産化については,個別業務ごとの成果物に対して資産化を可能とすることにしました.支払い時は,作業終了報告書に基づき個別業務単位で金額を確定します.

3番目の労働者派遣法対応では,「注文主と労務者に指揮命令関係を生じないこと」を徹底したコミュニケーションを改めて意識することを狙いとして,受発注双方の作業責任者がプロジェクトの進捗報告や問題点の洗い出しの上で指示内容を合意する場とする連絡調整会議を設けることとしました.

これらの仕組みについてトライアルを行い,法制度遵守と運用のアジリティ,アジャイル開発の効果の両立が達成できたことを確認しました.しかし一方で,契約・会計システムの利用,帳票での管理,コミュニケーションにおいて限界や課題があることが分かりました.詳細については,情報処理学会の研究会で発表しています[4].

藤瀬:ありがとうございます.こういった取り組みについてはあまり外部に紹介されることがないと思いますので,大いに参考になりますね.

アジャイル開発のモデル契約例

藤瀬:それでは次に高岡先生,先ほど紹介されたLIPでのモデル契約作成について,詳しく説明願います.

高岡:ありがとうございます.LIPでは,2年前の学会セッションで最初のモデル契約を公開しましたが,それは,アジャイル開発を実施していく上で最低限,ITシステム開発ベンダとITシステムの発注者が守らなければならない事項を盛り込んだものでした.その後,そのモデル契約に関する議論の内容を踏まえてその改訂版を作成し,今年(2020年)3月の全国大会で公開予定だったのですが,新型コロナウィルス感染拡大の影響で全国大会が中止になりましたので,モデル契約の公開も延期することにしました.5月のアジャイルジャパン2020☆1の前までにLIPのWebページ☆2で公開する予定です.改訂にあたっては,ユーザとベンダ双方がメリットを感じられる契約形態として準委任型をベースとした契約書の作成を試みました.そして,当事者(発注者・受注者)双方が,開発にかかわるプレイヤ(プロダクトオーナー,スクラムマスター,スクラムチーム,開発チーム等)とともに,刻々と変化するビジネスや技術環境等に応じてどのような役割を担い,どのような善管注意義務や協力義務を尽くすべきであるのか,という点について,契約書の中,特に前文に結構細かく書き込みました.そのため,できあがったモデル契約書は,作成に携わった実務家と法律家がそれぞれの立場からの思いを込めたものとなっています.

平岡:アジャイル開発の最大の特徴として,開発途中で仕事の内容が頻繁に変化することがあると思うのですが,それを法律というか契約に取り込むためには,大きく2つのアプローチがあると考えています.1つは,契約内容の確定方法からのアプローチであり,アジャイルについてのそのような特徴が共有されているという前提で,対象とする開発がアジャイルで進められていたという事実さえ契約条項中で認められれば,たとえ契約書にアジャイル開発の進め方に関する具体的な条項がなくても仕事等の内容変化が法的に有効なものとして認められる,というものです.もう1つは,事後的な変化を許容するアプローチであり,元々事情変更の原理は予見できなかった場合にのみ認められていたものを,アジャイルで開発するという合意があった場合には,この予見可能性の要件を緩和して仕事等の内容変更を有効なものとして認める,というものです.LIPのモデル契約では,前者のアプローチを志向しています.

高岡:私たちは,アジャイルの思想や現場のプラクティスを最大限尊重した望ましい契約を作るという難題にチャレンジしたと自負しています.

藤瀬:先生,ありがとうございます.それでは,IPAでのモデル契約の見直しは,どのようなものですか.

山下:はい,では,IPAでのモデル契約の見直しについて説明します.IPAでは,2012年に,基本/個別契約モデルと組合モデルという2種のアジャイル開発,当時は非ウォーターフォール型開発と言っていましたが,それ向けのモデル契約書を公開しました[2].しかし,当時のアジャイル開発の普及状況や社内制度上の対応等の事情から,データはとっていないのですが,あまり利用されてはいないと思われます.その後,アジャイル開発は徐々に普及してきていると考えています.また,一昨年から,経産省がDXの推進に取り組みはじめ,DX時代の有力なシステム開発スタイルの1つとしてアジャイル開発がこれまで以上に注目され出しました.ところが,契約にかかわる課題があってアジャイル開発の普及が阻害されているということで,モデル契約見直しの検討がスタートしたのです.検討は,ユーザ企業,ベンダ企業,関連業界団体に法律専門家からなる委員会で議論し,中立的な立場でユーザ企業・ITベンダいずれかにメリットが偏らない契約書の作成を目指しました.高岡先生と平岡弁護士にもお世話になっています.今回のモデルでは,世の中の実情を踏まえ,準委任契約1本の形態を採用しました.特徴の1つは,アジャイル開発における各プレイヤの役割やプラクティス等の詳細については,「アジャイル開発進め方の指針」として別文書に抜き出し,契約書の外側に位置付けたことです.これは,アジャイルのプロセスを契約書の条文に細かく書きすぎると,アジャイルが有するせっかくの柔軟性を損なってしまいかねないという懸念があったためです.実際の現場でも,具体的な開発の進め方については社内開発標準を参照するというように,このような方法が使われています.このモデル契約は,今年3月末に公開しています[5].

平岡:IPAのモデル契約の本旨というか,1つの特徴というのは,あまり契約本体にやり方そのものを細かく書きすぎないで,アジャイルの開発のやり方自体は,指針とかそういったものに譲って,それでそこを,ちょっと曖昧な言い方だけれども,ふんわりと契約が参照している.法律の言葉で言うと,契約には普通,当事者の意思表示が表れているのですけれども,その意思表示というのはやはり全部書き切れないのですよね,所詮,言葉なので.開発というのは背景にいろんな思想や事情があるのだけれども,全部は契約では規定し切れないので,その行間を埋めるためのものとして,指針が機能する.法律の言葉で言うと,「契約当事者の合理的意思解釈を行う」とよく言うのですけれども,その契約書そのものを見てもはっきりとは書いていない.裁判官でもこういう規定があるということは,この裏には当事者はこういうことを考えていたんでしょと,合理的に考えられるので,当事者の意思を解釈しますと言って,あなたにはこういうことをする義務があったのにしていないからお金を払いなさい,というようなことになるのですね.それがおそらく今回の指針だと,その合理的意思解釈の部分は指針に書いてあるので,裁判所は揉めたときに,契約書以外にそれも見て,でも指針にこう書いてあるから,あなたはこの義務があったんじゃないのと言って,あなたの負けです,みたいなことをたぶんやるようになるのだと思います.

藤瀬:ありがとうございます.2つのモデル契約それぞれに特徴があって興味深いですね.

秦泉寺:ところで,それぞれのモデル契約では,先ほど議論のあった偽装請負について,どのように扱っていますか.

山下:そこはかなり時間をかけて議論されたところです.こういうことが偽装請負になる/ならないというよりは,アジャイル開発の標準的なプロセスはこういうものだということを明確にして,それがいくら見たとしても偽装請負の入る余地がないというふうに思わせるようなものをきちんと定義すればいいのでは,という考え方が委員会内では大勢でしたが,そのことを具体的にモデル契約書に落とし込むのが大変でした.私個人のアイディアとしては,タスクが並べられ,自分からその1つを取りに行って仕事をして返す,誰かから命令されるのではなく自らの意思で行うというやり方ですよと,あらかじめ決めておくことでよいのではと思います.それが本来の自律型のアジャイルのはずなので.

平岡:恐らく,まず指揮命令の定義があるのですよね?指揮命令というのは何なんだと.要するに別の会社の従業員に指揮命令すると駄目なのですね.だから,それでアジャイルでやっている開発チームの中で,別の会社の人が交じっているわけじゃないですか.その中で,やっていることは指揮命令ではないんだということをまず明確にしてあげればよくて,そのためには指揮命令というのは何かというところをちゃんと明らかにする.指揮命令というのは,言ったら逆らえずに必ずやらないといけないような指揮なのだと思うのですよね,基本.よほど不合理じゃない限り.その点,アジャイルで言っているお互いのサジェスチョンだったりというのは,反論することもできるし,従わなくてもいいわけじゃないですか.だから指揮命令では本当はない.

高岡:指揮命令の定義をちゃんとするというのはいいのですよね.こういう場合はもう指揮命令に当たらないと.それがどこかに,ガイドラインになんか書かれるとすごくいいかなと.

山下:指揮命令とはという,解説とかで.

高岡:そう,解説に.

山下:実際にあり得るのは,プロダクトオーナーから開発メンバに対して,勘違いするPOがいて,自分が指揮できると思いこんで指揮をしてしまうみたいなのは本当に指揮命令になってしまうので,それを防ぐための何か,それは教育が必要ですね.加えて,契約書には,POは指揮命令はするものではないと.

高岡:そうそう.

山下:明確に書くか.

高岡:そう,書くか.

山下:そういうふうに書かれていれば,仮に指揮命令を受けてしまった人は,いや,契約書にこう書いてあるでしょと言って反抗することによって偽装請負になることを未然に防げる,という良いところもある.

秦泉寺:たぶん皆さん指針が欲しい.本当に指針があれば,それを参照して,こういうふうにやっているんだよというふうに言えるから.みんなそうですよ,発注側なんて.そういうお墨付きが欲しい(笑).

今後の期待

山下:ここにきて,情報処理学会とIPA/経済産業省という2つの機関でそれぞれモデル契約が作成されたり,NTT研究所におけるアジャイル開発促進のための社内制度の実践例が紹介されたりということから,今後,それらを参考としたアジャイル開発の導入が進むことが期待できますね.

秦泉寺:私どもの研究所では,今回の運用設計の結果,アジャイル開発の採用案件が1年半のトライアル期間において30契約に迫り,劇的に増加しています.やはり,仕組みをきちんと作ることが重要だと思いました.

平岡:たぶんウォーターフォールだって,それができたころはなじみがなかったと思うのですよ.基本設計だ,詳細設計だとか言ったって,今から30年前,40年前か知りませんけれども,最初はたぶん法務の人も,なんだこれはと思ったんだと思うんです.だからやはり時代が変わって,今度,アジャイルの要素が入った契約が出てくれば,最初は戸惑うかもしれないけれども,まあそのうち慣れてくるんじゃないのかなという気もちょっとしますけれどもね.

山下:そうこうするうちに,DXが進むと内製が多くなり,究極的には,システム開発の契約は,特にアジャイル開発の契約は,なくなってしまうかもしれませんね.

高岡:そうは言っても,AIとか自動走行とかの分野では,内製だけになることは考えにくいのではないかと思います.

藤瀬:DX時代の関連ビジネスの黎明期において,アジャイル開発手法の適用は必須ということですね.そして,アジャイル開発手法をうまく適用するための工夫が重要ということでしょうか.

本日は,どうもありがとうございました.

2部の様子 右手前から:仲山氏,伊藤氏,上田氏,古中氏,植松氏,藤瀬氏,吉野氏
インタビューの様子 右から時計回りに:平岡氏,山下氏,藤瀬氏,秦泉寺氏,高岡氏
参考文献
  • 1)(独)情報処理推進機構:IT人材白書2017(2017年4月25日).
  • 2)(独)情報処理推進機構:非ウォーターフォール型開発に適したモデル契約書の改訂版を公開(2017年4月17日更新),https://www.ipa.go.jp/sec/softwareengineering/reports/20120326.html
  • 3)厚生労働省:労働者派遣・請負を適正に行うためのガイド(2015).
  • 4)秦泉寺久美,神 明夫,夏川勝行:アジャイル開発のための準委任契約制度設計と課題,情報処理学会第85回電子化知的財産社会基盤研究会(EIP),Vol.2019-EIP-85, No.13(2019年9月20日).
  • 5)(独)情報処理推進機構/経済産業省:情報システム・モデル取引・契約書<アジャイル開発版> (2020年3月31日),https://www.ipa.go.jp/ikc/reports/20200331_1.html