目次
システム開発委託契約とは
システム開発の基礎
システム開発と法律
多段階契約方式
システム開発と準委任
再委託の制限
システムインテグレーションと損害賠償
IT契約ととベンダーロックイン
経済産業省モデル契約
システム開発委託契約とは
システム開発委託契約とは、情報システム（ないしはソフトウェア）の開発・運用・保守を、ユーザー（発注者）がベンダー（受注者）に対して委託する契約です。情報システムを構築する上では、専門的知識を有するベンダーに対して、その開発を委託する必要があり、こうしたシステム開発委託契約を欠くことができません。こうした契約は、情報システムの企画・開発から運用・保守までを統合して委託することから、システムインテグレーションと呼ばれることもあります。
システム開発とRFP
システム開発は、ユーザーがその内部的意思決定としてシステム化計画を立案した後、複数のベンダーにRFP（Request for Proposal）すなわち提案依頼書を送付して委託先を検討した上で、選定したベンダーとの要件定義を経て、システム開発を実施し、さらにシステムテストや運用テストを行うことにより進展します。
このようにシステム開発においては多数の開発工程が存在し、そのそれぞれにおいてユーザーとベンダーの負担する責任や役割は異なります。またベンダーが確定した段階では、そのベンダーがいかなる成果物を開発するべきか特定していないことが通常であり、その具体的な設計は、その後の開発工程に委ねられています。
システム開発のリスク
こうした当事者間の責任の流動性や不確定要素に起因して、システム開発の過程では、諸々のコミュニケーションエラーが発生するリスクがあります。こうした意思疎通の齟齬は、ベンダーの瑕疵担保責任として、当事者の紛争に発展する可能性があります。
このようなリスクを予防するため、システム開発委託契約においては、その開発工程に応じ、当事者の役割分担や契約不適合責任などについてあらかじめ合意して法的な権利義務関係として整理し、さらに仕様の変更管理手続きや責任者などについても合意しておかなければなりません。こうすることで、紛争処理にあたって違反行為の差し止めや損害賠償などの法的手段が確保されるのみならず、当事者間の紛争予防につながり、さらに開発のスムーズな進行とその予測可能性の向上に資することになります。
また情報システムの信頼性・安定性という観点から、システム開発に当たっても、成果物の非機能要件の一部として、そのセキュリティ仕様が重要となっています。DX(デジタルトランスフォーメーション)の進展に伴い、情報システムはもはや社会経済の基盤として機能しているといえます。そのため情報システムのセキュリティが不完全である場合、被害は広範囲におよび、SQLインジェクションによる個人情報の大量流出や、ランサムウェアによる生産管理システムの機能停止など、その損失は莫大なものとなる可能性があります。
こうしたリスクを予防するため、システム開発にあたってセキュリティ仕様書を取り交わすなどして、開発する情報システムのセキュリティ要件を明確化する必要があります。またベンダーからの情報提供のもと、ユーザーにおいても、研修の実施や社内規程の整備をはじめとして、人的・物的な安全措置を確保することが求められます。
関連記事：「業務委託契約について」
システム開発の方式
システム開発の方式としては、伝統的なウォーターフォール型の開発手法のほか、アジャイル開発やプロトタイピング開発など、様々な開発手法が存在します。
ウォーターフォール型
企業の基幹システム
ウォーターフォール型は、計画・設計・実装・テストの各工程を順次に実施する開発手法であり、最もオーソドックスな方法であるといえます。滝が流れるように開発が進展することから、このように呼ばれます。
その利点として、スケジュール管理が容易であり、完成品の仕様が早期に確定する点があります。一方で前工程の完成を前提に開発が進展することから、後戻りができません。そのため開発途中での仕様変更に対する柔軟性を欠き、前工程に不具合があった場合には、その修正が困難となるおそれがあります。
開発期間と製品仕様についての予測可能性が高いことから、企業の基幹システムなどの大規模なシステム開発に向いています。
アジャイル開発
ゲーム、ECサイト、Webサービス
これに対して、設計から実装までをサブシステムごとに区分し、それらのサブシステムの開発を繰り返すアジャイル開発（Agile）においては、仕様変更が容易であり、さらに不具合にも柔軟に対処することができます。
2001年の「アジャイルソフトウェア開発宣言」により、アメリカのユタ州で次世代の開発方法として提唱された手法であり、Agileは「敏捷」「活発」などを意味します。開発途中で検証が可能であるため品質の向上につなげやすく、優先的なサブシステムから完成させることができるため、納期を短縮する上でも有効な開発方法です。
ただし開発期間や完成品の仕様についての予測可能性が損なわれるため、開発が長期化したり、予算が増大するリスクもあります。ゲームやECサイトなど、ユーザーにとっての使用感が重要なシステムの開発に向いています。
プロトタイピング開発
小規模なシステム開発
プロトタイピング開発は、プロトタイプすなわち試作品を製作し、その評価を踏まえて次の試作品を製作していく開発手法です。一から開発をやり直す必要があるため大規模なシステム開発には向いていない一方で、企画段階で開発内容が不明確であっても、試作品の評価と検証を踏まえて、その内容を具体化していくことが可能です。
ほかにもスパイラル開発やDevOpsなどの開発手法が存在し、それぞれの手法により、開発するシステムの分節化の方法や検証方法が異なり、それに応じてメリット・デメリットが存在します。
システム開発の工程
システム開発は、ウォーターフォール型の開発を実施する場合には、以下のような工程により進展します。各工程において、ユーザーとベンダーが負担する責任や役割分担は異なります。なおアジャイル開発などのほかの手法による場合であっても、要件定義＞設計＞開発＞検証という基本的な開発プロセスは共通です。
企画段階
ユーザーにおいて、どのような情報システムの構築が必要であり、そのための予算規模や開発期間をどの程度見積もるかなど、システム構想ないしはシステム化計画を企画立案し、経営者の決済を経て、内部的な意思決定を行います。なおプロジェクトマネジメントの観点から、PM（プロジェクトマネージャー）を任命するなど、実行体制を整備することも求められます。
DD（Due Deligence）段階
システム構想を実現するため、どのベンダーに開発を委託するかを決定します。そのためにはベンダーの開発能力や開発コストのみならず、開発の規模や開発するシステムの性質に応じて、その財務的な基盤やコンプライアンス体制などについてもDDを行い、比較検討をしなければなりません。
DDの手順としては、情報提供依頼書（RFI：Request for Infomation）によりベンダーに開発実績や会社概要などについての情報提供を依頼した後、候補となるベンダーに対しては、提案依頼書すなわちRFP（Request For Proposal）を提示し、案件に対する具体的な見積もりを依頼します。
RFPの内容としては、開発の目的や開発条件のほか、その情報システムに必要な機能要件やセキュリティや拡張性などの非機能要件に関する要求を提示します。また開発に必要な範囲内で、ユーザーの経営方針やIT投資方針などについても開示します。なお損害賠償責任や再委託の制限などの契約事項について要求がある場合には、これらもRFPの内容にすることが考えられます。ユーザーからのRFPに対して、ベンダーは提案書を提出します。提案書には、システムの機能などのシステム構想をはじめとして、開発計画や開発体制などが記載されます。
RFIやRFPは必須ではありませんが、これらの手順を経ることにより、内部的に開発目的が明確化するとともに、ベンダーの実効的な比較検討が可能となります。また開発内容が早期に共有されるため、以後の開発工程の円滑な進展が期待できます。
要件定義
要件定義とは、開発の前工程であり、開発する情報システムの機能要件や非機能要件をユーザーがベンダーの専門的支援のもとに具体化し、要件定義書としてドキュメント化する過程です。ユーザーの業務要求を要求定義した上で、ベンダーが主体となって要件定義を実施する場合もあります。
要件定義における機能要件としては、既存のビジネスフロー（Asisモデル）を定義した上で、それを情報システムの導入によりどのように効率化するかを、導入後のビジネスフロー（Tobeモデル）に業務処理定義書などとして定義するとともに、ER図（Entity Relationship Diagram）などを用いて業務を概念的にドキュメント化し、構築する情報システムの機能を定義します。これに対し、非機能要件としては、RASIS（Reliability・Availability・Serviceability・Integrity・Security）の５要素が一般に上げられ、信頼性・可用性・保守性・保全性・安全性の確保が重要となります。
さらにセキュリティや拡張性などのほか、保守管理体制をはじめとする人的・組織的な要件についても検討をします。また開発そのものに関する要件として、開発期間や開発予算についても「ラフスケジュール」や概算見積りとして試算し、後続の開発工程についての共通理解を形成しておくことが望ましいといえます。
なおユーザーによる追加的変更要求に対しベンダーが対応する義務が争われた野村＝IBM訴訟（東京高裁2021.4.21)は、「ＣＲ（変更要求）を繰り返して……プログラム製作作業の十分な時間的余裕を奪った野村証券側に、より大きな原因がある」として、仕様確定後にユーザーが変更要求を繰り返したことによる開発の遅延に対しては、ユーザーが責任を負うとしています。
このように仕様が未確定なままに開発工程を進めることは、開発の遅延と混乱を招くのみならず、場合によってはユーザーによる変更要求が制限されることがあります。したがって要件定義段階において、ユーザー・ベンダー間のみならず、ユーザー内部においても、IT部門と業務部門において、完成品の仕様について十分な検討をしておく必要があります。
開発段階
要件定義の内容に基づいて、ベンダーが情報システムの開発を実施する段階です。開発段階は、外部設計、内部設計、コーディングの三つの段階に分かれます。ベンダーは「外部設計書」「内部設計書」を各工程の成果物としてユーザーに納品し、さらに確定見積もりをユーザーに提示します。ユーザーはこれらの設計書及び見積もりに基づき、開発の費用対効果を検証します。
開発① 外部設計
外部設計は、システム設計とも呼ばれ、情報システムの全体像を、その機能的な側面から設計します。機能要件として、画面設計として、管理画面をはじめとするユーザーインターフェースや印刷時に出力される帳票などの書式を画面遷移図や項目一覧表などを用いて確定し、さらにバッチ設計やDB(データーベース）設計のほか、外部システムとの連携方法などを決定します。非機能要件としては、情報システムの性能や信頼性について基準値を定め、その検証方式を含めて設定します。セキュリティ仕様についても、外部設計時に非機能要件の一つとして確定し、「セキュリティ仕様書」としてドキュメント化します。セキュリティ仕様として記載するべき内容としては、利用者認証、権限管理、ログ管理などの方法や、通信暗号化機能や不正プログラム対策などが挙げられます。
こうした外部設計は「アーキテクチャ設計」と「機能設計」からなり、アーキテクチャ設計において実行環境や開発言語などを確定した上で、機能設計において各モジュールの仕様を確定します。
なお外部設計段階において情報システムの開発内容が具体化されるため、ユーザーにより「外部設計書」が承認された段階で、その仕様を確定することが考えられます。仕様が確定するということは、変更要求が制限される点でベンダーにとってメリットがありますが、ユーザーとしても、開発期間や開発費用についての予測可能性が担保され、開発が頓挫するリスクを抑えることができます。外部設計段階で仕様を確定した場合には、内部設計段階校での要件追加や仕様変更、未確定事項については、変更管理手続きに服することとなります。
開発② 内部設計
これに対し内部設計は、システム方式設計ないしは詳細設計とも呼ばれ、外部設計を実現するための内部的な処理方法を設定します。外部設計で設計した機能をモジュール単位に機能分割をした上で、モジュール間のデータフローやデータベースの構造を決定し、外部設計で確定したインターフェースについても、表示テキストやエラー処理などを具体化します。
外部設計がシステムを機能面から設計する段階であるのに対し、内部設計はシステムを内部構造という観点から設計する段階であるため、専門知識を有するベンダーがその裁量により実行するべき段階であるといえます。
開発③ コーディング
コーディングは、内部設計を踏まえて、HTML・CSSのようなマークアップ言語ないしはJavaScript、PHP、C++、Unityのようなプログラミング言語を用い、コードを構築する過程です。情報システムが、これまでの工程におけるような観念的な存在ではなく、ソースプログラムとして、動作や検証が可能な対象として実装されるプロセスであるといえます。
検証段階
実装された情報システムが要件定義書ないしは設計書において合意された仕様を満たしているかどうかについて、ソフトウェアテスト、システム結合テスト、システムテストを実施して検証をします。企画・開発段階と検証段階の各工程を1対1の関係でとらえるV字モデルにおいては、これらはそれぞれ内部設計、外部設計、要件定義に対応します。
検証① ソフトウェアテスト
ソフトウェアテストは単体テストとも呼ばれ、モジュールがそれ自体として正常に稼働するかどうかを検証します。V字モデルにおいては、開発段階における内部設計への適合性の検証に当たります。想定された機能を実行できているかどうかの機能テストや、その効率性を検証する性能テストや負荷テストなどを、ベンダーの責任において実施します。
検証② システム結合テスト
単体テストにおいて動作が確認されたモジュールについて、それらが結合された集合体であるコンポーネントないしはシステムにおいて、想定された機能を果たし、正常に稼働するかどうかを検証します。V字モデルにおいては、開発段階における外部設計への適合性の検証に当たります。
検証③ システムテスト
システムが外部設計の仕様通りに機能するかどうか検証します。V字モデルにおいては、企画段階における要件定義への適合性の検証に当たります。要件定義はユーザーが主体となって実施するため、システムテストもユーザー主体で実施することも考えられます。ベンダー主体でシステムテストを実施する場合においても、検証方法や検証項目などについては、ユーザーが指定することが望ましいといえます。
運用・保守段階
情報システムは開発が完了した後も、その運用と保守に専門的知識を有するベンダーの関与が必要となります。ユーザーが情報システムを実際に業務で運用することで検証する運用テストを実施した上で、システムを安定稼働させるための定期メンテナンスなどの運用業務および機器の故障などのインシデントからの復旧をはじめとする保守業務を継続的に行います。
これらの運用保守業務は不定形のサービスであり、ベンダーがどの程度の責任を負担するのかは明確ではありません。そのため委託内容を特定し、ユーザーとベンダーの役割分担を明らかにするため、サービスレベル契約（SLA:Srvice Level Agreement）を活用することも考えられます。SLAにおいては、障害対応やセキュリティ対策など委託業務の範囲を特定するとともに、サービスレベルとして、システムの稼働率やインシデント発生時の復旧時間などについて合意しておきます。
システム開発と多段階契約
システム開発委託契約の方式としては、一括請負方式と多段階契約方式があります。開発工程のそれぞれにおいてユーザーとベンダーに求められる責任や役割が異なる上、初期工程において成果物の仕様を確定することが困難であることから、開発工程ごとに契約を締結する多段階契約方式が望ましいといえます。多段階契約方式においては、発注時に各個別契約に共通する事項を基本契約として合意した上で、各工程において、さらに個別契約を締結します。
システム開発の基本契約の記載事項
基本契約における合意事項として、以下のような項目があります。なお契約を締結するタイミングとしては、RFPや提案書の提示を経て、ユーザーが開発を委託するベンダーを選定した段階で、要件定義など開発行為に着手する前に締結をします。ただしやむを得ず基本契約締結前に開発を発注する場合には、紛争予防の観点から「仮発注合意書」などを用い、事後に基本契約を締結することを前提として、その時点での暫定的な合意事項を文書化して合意することが望ましいといえます。
用語の定義：IPAによる「共通フレーム2013」などに準拠し、用語を定義します。
個別契約の成立：個別契約の成立方法について合意します。
適用関係：個別契約で異なる合意をした場合に、どちらが優先するかを確定します。
再委託の方法：再委託にユーザーの事前承諾を要するかどうかについて合意します。
責任者・主任担当者：相手方への通知などの権限を有する責任者を特定します。
開発実施体制：連絡協議会の設置等、プロジェクト管理のための体制を整備します。
知的財産権：特許権や著作権について、その帰属や使用権の内容を合意します。
変更管理手続き：確定仕様を変更する場合にいかなる手続きによるかを合意します。
秘密保持：ユーザーの営業秘密やベンダーのノウハウについて秘密の保持をします。
契約不適合責任：定義書・設計書への不適合への責任について合意します。
解除：信用不安や債務不履行など契約の解除事由を特定します。
損害賠償：損害賠償の範囲・上限や請求権の行使期間などについて合意します。
紛争解決：当事者間の協議や裁判管轄などについてあらかじめ特定しておきます。
システム開発の個別契約の記載事項
これに対し個別契約においては、具体的な作業内容のほかに納入するべき仕様、作業期間や納期、検査方法などについて合意します。個別契約においていかなる事項を合意すべきかについては、基本契約において合意項目を特定しておきます。また個別契約ごとに再見積もりを実施し、分割発注するという方式を採る場合には、委託料とその支払方法についても個別契約の合意事項となります。
なおユーザーとベンダーの役割分担として、その開発工程が準委任契約であるか請負契約であるかについても、各個別契約において明確にしておく必要があります。
システム開発と準委任
システム開発委託契約の契約類型としては、準委任と請負に分けることができます。委託契約が準委任であるか請負であるかは、業務委託契約一般について問題となりますが、システム開発委託契約においては、当事者間の役割分担が流動的であり、かつ完成品の仕様や開発期間・開発費用など、成果物についての予測可能性が他の業務委託に比べて低いという点において、その契約がどちらの契約類型であるかということが、当事者間で争点化しやすいといえます。
準委任は民法656条・643条を根拠とし、請負は民法632条を根拠とします。「準委任」は「事務をすること」を相手方に委託することを内容とするのに対し、「請負」は「仕事の完成」を相手方に委託することを内容とします。
民法643条：委任は、当事者の一方が法律行為をすることを相手方に委託し、相手方がこれを承諾することによって、その効力を生ずる。
民法632条：請負は、当事者の一方がある仕事を完成することを約し、相手方がその仕事の結果に対してその報酬を支払うことを約することによって、その効力を生ずる。
その契約が準委任であれば、受任者は委任事務を「善良な管理者としての注意義務」すなわちシステム開発委託契約であれば、システム開発についての専門知識を有するベンダーとして通常求められる程度の義務を尽くしていれば、その成果物の成否については責任を負いません。
ユーザーがその情報システムによって所期の業務効率化を実現することができなかったとしても、ベンダーが委任事務を誠実に処理した結果である限り、その契約の履行として欠けるところはありません。また民法上は、準委任契約の履行に要した費用は委任者が負担する一方で、受任者は委任者への事務の処理状況の報告義務を負い、再委託も制限されます。
システム開発と請負
これに対しその契約が請負であれば、請負人は「仕事の完成」の義務を負担するため、要件定義書や設計書などにより確定した仕様の通りの情報システムを納品するべき義務を負い、成果物が仕様に適合しない限り、その瑕疵を修補しなければなりません。また民法上は、請負人は仕事の完成に要した費用を自ら負担する一方で、再委託は自己の責任においてすることができます。
このように準委任と請負では当事者が負担する責任に相違があり、請負契約のほうが瑕疵担保責任を負うベンダーの責任はより大きくなります。準委任形式は、委任者であるユーザーがベンダーの支援のもと自ら成果物を完成すべき工程に適しているといえます。一方で請負形式は、ベンダーが主体となって処理するべき工程に適しており、完成するべき「仕事」が特定している必要があるため、成果物の仕様をあらかじめ確定することができることが、請負契約とする条件となります。
システム開発と契約形式
そのためV字モデルにおいて対応する工程の契約類型を同一とする考え方を採るならば、要件定義は業務用件を知り得るユーザーが主体となるため準委任契約とし、内部設計、コーディング、ソフトウェアテスト、システム結合テストについては、ベンダーがその専門知識をもって業務を実施するべきであるため請負契約とすることが合理的です。これに対して外部設計とシステムテストについては、当事者の経験やノウハウの程度により、どちらを主体として位置づけることもでき、準委任と請負のいずれの契約形式も考えられます。ただし実務上は、外部設計・システムテストは請負契約とすることが多いようです。
再委託の制限
企業の基幹システムのような大規模なシステム開発においては、ベンダーが単独ですべての開発を実施することは現実でないことが考えられ、再委託を基本契約においてあらかじめ許容しておくことが求められます。
「ITゼネコン」という用語に掲揚されるように、「システムインテグレーター」と呼ばれる元請けベンダーの受託業務が、一次下請けから二次下請けというように数次の再委託がされることが、業界慣行としても定着しています。一方で再委託が無制限になされた場合、プロジェクトマネジメントが困難となるだけではなく、開発に使用されているユーザーの秘密情報が外部に漏洩するリスクが増大し、ユーザーの権利利益が侵害される恐れがあります。
このようなリスクを予防するため、再委託条項において、ベンダーによる再委託を制限する必要があります。その方法としては、ベンダーが再委託をした場合には、ユーザーに再委託先や再委託業務の内容について通知するとする方法のほか、ベンダーが再委託をするにはあらかじめユーザーの承諾を要するとする方法もあります。後者の方法による場合は、ユーザーの保護として手厚いものとなりますが、再委託が拒否された場合にベンダーが開発の継続に困難を生じるリスクもあるため「ユーザーが再委託の承諾を拒否するには、正当な理由を要する」などとして、拒否できる場合を制限しておくことも考えられます。
関連記事：「下請法について」
システムインテグレーションと損害賠償
システム開発委託においては、開発期間が長期間にわたり、また開発費用も高額となることがあり、そのような場合には開発が頓挫したときにユーザーからベンダーに対して巨額の損害賠償が請求されることがあります。前述の野村＝IBM訴訟の一審判決は、IBMに対して16億円の支払いを命じており、スルガ銀行＝IBM訴訟の一審判決（東京地H24.3.29）は、74億円の損害を認定しています（控訴審はこれを43億円に減額）。
このような大規模なシステム開発案件でない場合であっても、情報システムのバグやセキュリティの脆弱性に起因して想定外の損害が発生したり、開発が断念されて当事者間で紛争となるリスクは存在するため、ベンダーとしては、損害賠償の上限を基本契約において限定しておくことを検討しなければなりません。またユーザーとしても、瑕疵担保責任とあわせて、ベンダーに対して責任追及が可能なように、合理的な範囲の損害賠償責任を確保しておく必要があります。
損害賠償責任の制限の方法としては、「当事者の責に帰すことができない事由から生じた損害、当事者の予見の有無を問わず特別の事情から生じた損害、逸失利益については賠償責任を負わない」のように、損害賠償の範囲を限定するほか、その上限額を設定する方法もあります。上限額としては「個別契約に定める取引金額の額を上限とする」などとして、その契約の取引金額を用いることが考えられます。
関連記事：「損害賠償条項について」
IT契約とベンダーロックイン
公正取引委員会は「官公庁における情報システム調達に関する実態調査について」と題する報告書（R4.2.8）において、いわゆるベンダーロックインの問題について調査を実施しています。これは全国約1000の自治体が調査対象となっています。
ベンダーロックインとは、その情報システムに特殊な仕様が含まれていたり、改修の変更履歴をベンダーが管理していることなどにより、その情報システムの改修や運用保守を、そのシステムを開発したベンダーしか事実上実施することができない状態となっていることを指します。またソフトウェアに関する著作権をベンダーが有することによる権利処理上の問題であることもあります。
IT契約と独占禁止法
このようなベンダーロックインを利用して官公庁の情報システムに関する入札を妨げ、競合他社を競争から排除しているとされる場合には、「私的独占」などとして独占禁止法に抵触するおそれがあるとしています。本報告書の射程は、国や自治体の公共入札案件に限られますが、これらの入札においてベンダーロックインを意図的に発生させるような行為は、公正取引委員会による警告や措置命令の対象となるリスクがあります。
関連記事：「独占禁止法について」
経済産業省モデル契約
システム開発委託契約については、ユーザーとベンダーの双方の立場と法律専門家などの知見をまとめ、情報システム開発に関する取引構造を透明化しその生産性の向上に資するため、経済産業省において「モデル契約」が公開されています。
情報システム・モデル取引・契約書https://www.meti.go.jp/policy/it_policy/softseibi/model1.html
「モデル契約」は、2007年に経済産業省から「情報システム・モデル取引・契約書」が公開されたのを受けて、IPA（独立行政法人情報処理推進機構）が2011年にアジャイル開発などの開発方式についての「非ウォーターフォール型開発用モデル契約書」を公開していました。さらにセキュリティ対応やプロジェクトマネジメント義務などについての検討を踏まえた「情報システム・モデル取引・契約書（第二版）」が経済産業省により2020年12月22日に公開されています。
「モデル契約」はユーザーとベンダーが対等の立場で実施する企業の基幹システムなどの大規模なシステム開発を想定して構成されているため、中小規模のシステム開発やいずれかの当事者の立場が顕著に優位な取引に適用する上では限界がありますが、ベンダーの業界団体等による契約書ではないため、より公正な内容であることが期待できます。
なお経済産業省は「情報システム・モデル取引・契約書（第二版）」とあわせて「情報システム開発契約のセキュリティ仕様作成のためのガイドライン」と「セキュリティ仕様策定プロセス」を公開しており、セキュリティ仕様の策定にあたり準拠することができます。
