システム開発契約とは|システム開発契約の基本と契約書作成上のポイント

１．はじめに

現在、業務そのものに変革をもたらすとともに、現代のビジネス環境をとりまく激しい変化に対応し、自社の競争力を高めるデジタル技術の活用、いわゆる「デジタルトランスフォーメーション」（DX）が注目を集めています。

そこで、今回はDXの根幹を成すといっても過言ではないシステム開発の基本とシステム開発契約書作成上のポイントについてご紹介します。

２．システム開発契約とは

（１）システムとは

システムという言葉は様々な場面で用いられますが、本コラムにおけるシステムとは情報システムのことを指します。
「情報システム」とは、企業等において、コンピューターやその周辺機器、通信ネットワーク、ソフトウェア等を使用して様々な業務上の処理を行うものをいいます。

（２）システムの構成要素

システムは主に、コンピューターを動かすためのプログラムであるソフトウェアと機械設備であるハードウェアから構成されています。

（３）システム開発における当事者

発注元であるユーザと発注に基づきシステム開発を行うベンダがシステム開発の当事者となります。
ベンダはもちろんのこと、ユーザも個人ではなく企業であることがほとんどです。

一般的な取引であれば、発注者が、受注者に対し、注文を行えば、商品が届くのを待つだけですが、システム開発においては、ユーザが自身の事業の実現や効率化のために、ベンダに開発を依頼することになるので、まずユーザ自身が、ベンダに対し、システムに求める機能等を明確に示す必要があります。
システム開発契約においては、一般的な取引と異なり、発注者たるユーザの役割は重要といえます。
またベンダもユーザのニーズを正確にくみ取り、ユーザが真に求めるシステムの開発を行う必要があることから、ユーザとベンダとの密な連携が重要となってきます。

（４）システム開発の流れ

システム開発の方法には様々なものがありますが、以下①から③の工程で開発が進められていくのが一般的です。
これをウォーターフォール型開発といいます。

①　企画・提案・見積段階

ユーザは、システムに対する要望を抽出したうえで、ベンダに対して、「提案依頼書」（RFP）という形で、システム開発の提案を求めます。
ユーザから依頼を受けたベンダは、具体的にどのようなシステムをいつまでにいくらで作ることができるかを「提案書」という形で、提案していくことになります。

ユーザとベンダ間でシステムの最終的な完成像についての認識が共有されていないと、出来上がったシステムの仕様について後々トラブルになる可能性があるため、この段階でユーザとベンダの間で協議を重ね、可能な限り認識を共有したうえで契約を締結することが重要です。

②　開発段階

契約締結後、ベンダは、システム開発に着手していきます。
ベンダは、まず、ユーザからの提案をもとに、システムが備えるべき機能等、必要な要件を具体化します。
これを要件定義といいます。

定義された要件に基づき、設計・製造がなされていきます。
設計が決まり、これに基づいて製造が始まった段階で、仕様を変更しようとすると、多大なコストがかかってしまいます。
後々、仕様を変更せざるを得ない状況にならないよう、契約締結後も、ユーザとベンダが継続して連携することが必要です。

製造が完了すると、システムが正常に動作するかを試験する必要があります。
またシステムが正常に動作しても、これがユーザの環境でも同じように動作するとは限りませんから、ユーザの使用していた従前のシステムから新システムへの移行を行う必要もあります。

③　運用・保守段階

いったんシステムがユーザの環境下で正常に動作しても、これがずっと正常に作動し続けるとは限りません。
ベンダは、システムが正常に動作し続けるように監視する必要があり、仮に障害が発生した場合には適切に対応する必要があります。

運用・保守については、何をもってこれを履行したといえるかが、開発等に比べて明確ではありません。
そこで、運用・保守段階において要求されるサービスの質を可視化することを目的としたサービスレベルアグリーメント（SLA）が導入される場合があります。
運用・保守段階に限らず、システム開発においては、その性質上、どの段階をとってみても、ユーザとベンダの責任の所在が不明確になる傾向にあるので、契約締結段階で、これをある程度明確にしておくことが必要です。

＜ウォーターフォール型開発のイメージ＞

（出典：https://www.musk.co.jp/recruit/business/work.html）

３．システム開発契約の類型と性質

（１）多段階契約と一括契約

システム開発は、前述２（４）のとおり、いくつかの段階を経て行われ、契約締結後の要件定義段階まで開発すべきシステムの仕様が明らかではありません。
そこでシステム開発契約においては、工程ごとに契約締結を行うことが一般的です。
これを多段階契約といいます。

もっとも、システム開発の内容によっては、全体の工程を一つとして契約締結を行う場合もあります。
これを一括契約といいます。

（２）どちらを選ぶべきか

多段階契約の場合、工程ごとに契約を締結するので、工程ごとにかかる費用の見積もりを出すことができる反面、契約ごとに交渉をすることが必要となります。
一括契約の場合、契約締結は１回のみで、契約時に費用の総額が確定できる反面、見積もり自体に無理がある場合、開発そのものが頓挫しかねません。

したがって、どちらの契約形態もメリットとデメリットがあるといえます。
多段階契約と一括契約どちらを選択するかは状況によっても変わり得るものではあるため、どちらを選ぶべきであるかについて正解はないといえるでしょう。
もっとも、経済産業省所管の情報処理推進機構がシステム開発契約における契約書の雛形として、多段階契約を前提とするものを示していること等から、実際の現場においては、多段階契約を選ぶことが多いと思われます。

（３）請負と準委任

一般に、締結を検討している契約が民法上の典型契約のいずれに当たるかは非常に重要です。
というのは、民法上のどの契約類型に当たるかは契約書の記載の方向性に関わるからです。
システム開発契約については、通常、請負又は準委任契約のどちらかに当たると考えられています。

請負とは、当事者の一方がある仕事を完成することを約束して、相手方がその仕事の結果に対して報酬を支払うという契約類型です（民法６３２条）。

他方で、準委任とは、当事者の一方が法律行為でない事務を行うことを相手方に委託し、相手方がこれを承諾するという契約類型となります（民法６５６条）。

この二つの類型の一番の違いは、請負契約においては仕事の完成がその内容となっているが、準委任契約ではそうではないという点にあります。

システム開発契約がどちらの類型に当たるかについては、前述したとおり、工程ごとに異なるという考え方が一般的です。

まず、企画・提案・見積段階では、開発すべきシステムの内容が未確定であることから、仕事を完成させることが不可能ですので、準委任と考えるのが一般的です。

これに対し、開発段階以降においては、すでに開発すべきシステムの内容は定まっていることから基本的には請負と考えるべきですが、試験段階以降については、性質上、ユーザが関わる部分が多くなることから、準委任とする考え方もあります。

４．契約書作成上の注意点

（１）序論

ここまで、システム開発の流れの基本部分とシステム開発契約の性質について述べてきました。
以下では、システム開発契約の特殊性が契約書にどのように反映されているかという観点から、契約書の条項のうち特に重要と考えられるものについてご紹介します。

なお、実際は基本契約に基づいて、工程ごとに個別契約を締結することになりますが、重要な条項は基本契約と個別契約で共通していますので、今回は基本契約に絞って検討していきます。

（２）システム開発基本契約書の条項例

①　契約の目的

システム開発契約では契約締結段階で、開発すべきシステムの内容が確定していないことが多いため、契約の目的については、以下のように、抽象的な記載にとどめ、詳細については、各個別契約で規定することが一般的です。

【条項例】

第●条　本契約は、甲が、甲の○○○システムのコンピュータソフトウェアの開発にかかる業務（以下「本件業務」という。）を乙に委託し、乙はこれを受託することに関する基本的な契約事項を定めることを目的とする。

②　定義

システム開発契約に限らず、契約書上で用いられる用語の解釈に幅があると、その解釈をめぐり、契約当事者間で後々トラブルになる可能性があります。
またシステム開発契約特有の問題として、システム開発に関する専門用語の多くは、明確な定義を有していません。
契約当事者間で、用語の定義に対する認識の違いがあることが多いため、他の契約類型と比較して、契約書上これを明確にする必要性は高いといえます。

③　役割分担

ベンダは、単にユーザの協力を求めることのみならず、開発作業を阻害する要因等の発見に主体的に努め、これに対処する義務を負うと考えられています。
これをプロジェクトマネジメント義務といいます。

一方で、ユーザも、どのような機能を要望するかを明確にベンダに伝え、ベンダとともに要望する機能について検討し、最終的に機能を決定する等の協力義務を負うと考えられています。

したがって、実際に開発を行うベンダのみならず、発注者側であるユーザの積極的な介入が重要であるといえることから、両者の役割分担については契約書上、明確にする必要があります。

【条項例】

第●条　甲及び乙は、本件業務の円滑かつ適切な遂行のためには、乙の有するソフ

トウェア開発に関する技術及び知識の提供と甲によるシステム仕様書の早期かつ

明確な確定が重要であり、甲乙双方による共同作業及び各自の分担作業が必要と

されることを確認する。甲及び乙は、甲乙双方による共同作業及び各自の分担作業

を誠実に実施するとともに、相手方の分担作業の実施に対して誠意をもって協力

するものとする。

２．甲乙双方による共同作業及び各自の分担作業は、別添のとおりとし、各個別契

約においてその詳細を定めるものとする。

３．甲及び乙は、共同作業及び各自の実施すべき分担作業を遅延し又は実施しない場合、それにより相手方に生じた損害の賠償も含め、かかる遅延又は不実施について相手方に対して責任を負うものとする。

 

④　責任者

システム開発はユーザとベンダの共同作業であり、密な情報交換が必要となります。
情報等の授受が確実になされるように、情報が行き来するルートを一本化する意味で、責任者に関する規定を置くことは重要です。
十分な意思疎通を担保する規定として、この他にも連絡協議会の定期的な開催に関する規定を置くことも推奨されています。

【条項例】

第●条　甲及び乙は、各個別契約締結後すみやかに、各個別契約における各自の責

任者をそれぞれ選任するとともに、書面により、相手方に通知する。なお、当該個

別契約において双方の体制図を定め、当該体制図に当該責任者を記載することを

もって書面による通知に代えることができるものとする。

２．甲及び乙は、事前に書面により相手方に通知することにより、責任者を変更できるものとする。

３．甲の責任者は、次の各号に定める権限及び責任を有するものとする。

（各号については省略します。）

４．乙の責任者は、次の各号に定める権限及び責任を有するものとする。

（各号については省略します。）

５．甲及び乙が選任すべき責任者の人数は、各個別契約において定めるものとする。

６．責任者が複数の場合には、甲及び乙は協議の上、総括責任者をおくことができるものとする。

 

⑤　業務従事者

システム開発契約は、既述のとおり、ユーザとベンダ間における請負か準委任という形式をとるのが一般的であり、ベンダの従業員は、あくまでベンダの指揮命令下で業務に当たらなければなりません。
ただ実際は、ベンダからユーザに対する労働者派遣のようなことも行われている場合があります。
これを偽装請負といいます。
偽装請負は、労働者派遣法等の法令に抵触するおそれがありますので、法令遵守の観点から、以下のような条項を入れておくべきでしょう。

【条項例】

第●条　本件業務に従事する乙の従業員（以下「業務従事者」という。）の選定については、乙が行う。

２．乙は、労働法規その他関係法令に基づき業務従事者に対する雇用主としての一切の義務を負うものとし、業務従事者に対する本件業務遂行に関する指示、労務管理、安全衛生管理等に関する一切の指揮命令を行うものとする。

３．乙は、本件業務遂行上、業務従事者が甲の事務所等に立ち入る場合、甲の防犯、秩序維持等に関する諸規則を当該業務従事者に遵守させるものとする。

 

⑥　ユーザの協力義務の明示

ユーザが協力義務を負うことについては、前述③のとおりですが、とくにユーザの関与が求められる工程においては、協力の具体的な内容について、別途規定を置くとよいでしょう。

【条項例】

（要件定義作成支援業務の実施）

第●条　乙は、第●条所定の個別契約を締結の上、本件業務として甲が作成した情報システム構想書、システム化計画書等に基づいて、甲による要件定義書の作成作業を支援するサービス（以下「要件定義作成支援業務」という。）を提供する。

２．乙は、情報処理技術に関する専門的な知識及び経験に基づき、甲の作業が円滑かつ適切に行われるよう、善良な管理者の注意をもって調査、分析、整理、提案及び助言などの支援業務を行うものとする。

（ソフトウェア運用準備・移行支援業務の実施）

第●条　乙は、第●条所定の個別契約を締結の上、本件業務として甲が行うシステムテスト、導入・受入支援及び本件システムを現実に運用するために行う運用テスト業務につき、甲のために必要な支援を行う。

２．乙は、情報処理技術に関する専門的な知識及び経験に基づき、甲の作業が円滑かつ効果的に行われるよう、善良な管理者の注意をもって支援業務を行うものとする。

 

⑦　仕様の変更等

ユーザとベンダとの間のシステムの完成像に関する認識の共有は不可欠です。
認識のずれが生じる代表的な場面として、途中でシステムの仕様が変更されたことについて契約当事者双方がきちんと認識していないことが考えられます。
仕様に関する認識のズレは完成品の性能等をめぐるトラブルにつながる可能性が極めて高いので、この点について、契約書上きちんと定めておく必要があります。
またユーザとベンダの情報共有の観点から、各個別業務の途中段階でのユーザによる承認や、やむを得ない事情により、未決事項が残ったまま、次の工程に進まざるを得ない場合の未決事項の取り扱いについても定めておくとよいでしょう。

【条項例】

（確定仕様等の変更）

第●条　甲又は乙は、本件業務に関する甲乙間での合意事項の変更（以下「確定仕様等の変更」という。）を希望する場合は、その変更内容、理由等を明記した書面

により相手方に申し入れるものとする。

２．前項による申し入れがあるとき、甲及び乙は、当該変更の可否について協議する。

３．前項の協議の結果、甲及び乙が当該変更につき合意した場合、甲乙双方の責任者の承認をもって、確定仕様等の変更が確定するものとする。

（変更協議不調等に伴う契約終了）

第●条　確定仕様等の変更につき、協議が調わない場合、甲及び乙は、委託業務の未了部分について本契約及び個別契約を解除することができる。

（未確定事項の取扱い）

第●条　甲は、乙が本件業務を遂行するのに必要な事項を、甲のやむを得ない事情により確定して提示することができない場合、甲は、当該未確定事項の内容とその確定予定時期、未確定事項の確定により請求する追完、修正により委託料、作業期間、納期及びその他の契約条件の変更を要する場合に甲がこれを受け入れること、その他必要となる事項を甲が確認の上、甲乙記名押印した書面を作成することにより、甲は、当該未確定事項の確定後、乙に対して確定した要件定義書、外部設計書の追完、修正の業務を請求することができるものとする。この場合、甲は、未確定事項が確定したときは直ちに乙にその内容を書面で提示するとともに、必要となる要件定義書又は外部設計書の追完又は修正の業務をすみやかに乙に請求するものとする。

２．甲による追完又は修正の請求は、第●条所定の変更管理手続によってのみこれを行うことができるものとする。

⑧　契約不適合責任

システム開発契約においても、他の契約類型と同様に、以下のように、契約不適合責任に関する規定を置くことになります。
加えて、システム開発契約においては、その規定の仕方にも注意が必要です。
ベンダが、当初予定されていた工程を全て終え、納品したものについて、ユーザが、自身の求める水準に達していないことから追完を求めることがあります。
これに対し、ベンダは、求められたシステムは既に完成しており、ユーザの要求は設計変更を求めているに等しく、追加の料金を支払ってもらわなければ作業を行うことはできないとして、ユーザとベンダ間で対立が起きることが考えられます。

この点、裁判例によれば、通常予定された使用をする際に合意された機能に支障を生じさせるようなバグが残っているような場合には、契約不適合があると考えてよいといえますので、この点を踏まえたうえで、契約不適合の内容についても契約書上、規定すべきでしょう。

【条項例】

第●条　検収完了後、納入物についてシステム仕様書との不一致（バグも含む。以下本条において「契約不適合」という。）が発見された場合、甲は、乙に対して、当該契約不適合の修正等の履行の追完（以下本条において「追完」という。）を請求することができ、乙は、当該追完を行うものとする。但し、甲に不相当な負担を課するものでないときは、乙は、甲が請求した方法と異なる方法による追完を行うことができる。

２．前項にかかわらず、当該契約不適合によっても個別契約の目的を達することができる場合であって、追完に過分の費用を要する場合、乙は前項所定の追完義務を負わないものとする。

３．甲は、当該契約不適合（乙の責めに帰すべき事由により生じたものに限る。）

により損害を被った場合、乙に対して損害賠償を請求することができる。

４．当該契約不適合について、追完の請求にもかかわらず相当期間内に追完がなされない場合又は追完の見込みがない場合で、当該契約不適合により個別契約の目的を達することができないときは、甲は本契約及び個別契約の全部又は一部を解除することができる。

５．乙が本条に定める責任その他の契約不適合責任を負うのは、検収完了後●ヶ月であって、かつ甲が当該契約不適合を知った時から●ヶ月以内に甲から当該契約不適合を通知された場合に限るものとする。但し、前条の検収完了時において乙が当該契約不適合を知り若しくは重過失により知らなかった場合、又は当該契約不適合が乙の故意若しくは重過失に起因する場合にはこの限りでない。

６．第1項、第3項及び第4項の規定は、契約不適合が甲の提供した資料等又は甲の与えた指示によって生じたときは適用しない。但し、乙がその資料等又は指示が不適当であることを知りながら告げなかったときはこの限りでない。

⑨　資料等の取り扱い

システム開発において、ユーザは、ベンダに対し、様々な情報提供を行い、これに伴う資料等の提供も必要になる場合があることから、その管理方法等についても契約書上規定しておく必要があります。
またユーザとベンダ間で共有される情報のなかには、機密情報も存在することから、これに関する取り扱いも他の契約類型と同様に規定する必要があります。
システム開発契約においては、契約に至るまでの段階でも、お互いの機密情報を開示しあうことになることから、その段階で秘密保持契約（NDA）を結ぶことも考える必要があります。

⑩　個人情報

開発されたシステムは、ユーザの事業に用いられ、システムの内容いかんによっては、ユーザの従業員の個人情報が記録されていくことになります。
このシステムをベンダが保守する際、法的にはベンダにユーザの従業員の個人情報の取扱いが委託されたことになります。
この場合、委託者たるユーザにはベンダによる個人情報の取扱いについての監督義務が生じる（個人情報保護法３２条）ため、法令遵守の観点から、この点についての条項も定めておくべきと考えられます。

【条項例】

第●条　乙は、個人情報の保護に関する法律（本条において、以下「法」という。）に定める個人情報のうち、本件業務遂行に際して甲より取扱いを委託された個人データ（法第２条第６項に規定する個人データをいう。以下同じ。）及び本件業務遂行のため、甲乙間で個人データと同等の安全管理措置（法第２０条に規定する安全管理措置をいう。）を講ずることについて、個別契約その他の契約により合意した個人情報（以下あわせて「個人情報」という。）を第三者に漏洩してはならない。なお、甲は、個人情報を乙に提示する際にはその旨明示するものとする。また、甲は、甲の有する個人情報を乙に提供する場合には、個人が特定できないよう加工した上で、乙に提供するよう努めるものとする。

２．乙は、個人情報の管理に必要な措置を講ずるものとする。

３．乙は、個人情報について、本契約及び個別契約の目的の範囲内でのみ使用し、本契約及び個別契約の目的の範囲を超える複製、改変が必要なときは、事前に甲から書面による承諾を受けるものとする。

４．個人情報の提供及び返却等については、第●条（資料等の提供及び返還）を準用する。

⑪　知的財産権の取扱い

ベンダが開発したシステムについては、著作権をはじめとする知的財産権が発生する場合があるため、その権利の帰属について規定する必要があります。

また、開発されたシステムが他者の知的財産権を侵害している場合のベンダの責任についても規定する必要があります。
もっとも、開発段階で、侵害しうる知的財産権全てを洗い出すは現実的に難しいことから、ベンダの責任については限定的に考えるのが一般的です。

【条項例】

（システムの著作権）

第●条　本契約及び個別契約の履行に伴い作成された著作物の著作権は、甲又は第三者が従前保有していたものを除き、乙に帰属するものとする。

２．乙は、個別契約で定める日をもって、甲に対し、本契約若しくは個別契約の履行又は本件システムの自己使用に必要な範囲に限定して、納入物及び提出物に含まれる乙の著作物に関する非独占的使用権を許諾するものとする。

（知的財産権侵害の責任）

第●条　甲が納入物に関し第三者から著作権、特許権その他の産業財産権（以下本条において「知的財産権」という。）の侵害の申立を受けた場合、次の各号所定のすべての要件が充たされる場合に限り、第●条（損害賠償）の規定にかかわらず、乙は、かかる申立てによって甲が支払うべきとされた損害賠償額及び合理的な弁護士費用を負担するものとする。但し、第三者からの申立てが甲の帰責事由による場合にはこの限りではなく、乙は、一切責任を負わないものとする。

①　甲が第三者から申立てを受けた日から●日以内に、乙に対し申立ての事実及び内容を通知すること

②　甲が第三者との交渉又は訴訟の遂行に関し、乙に対して実質的な参加の機会及びすべてについての決定権限を与え、並びに必要な援助をすること

③　甲の敗訴判決が確定すること又は乙が訴訟遂行以外の決定を行ったときは和解などにより確定的に解決すること

2.　乙の責に帰すべき事由による知的財産権の侵害を理由として納入物の将来に向けての使用が不可能となるおそれがある場合、乙は、乙の判断及び費用負担により、（ⅰ）権利侵害のない他の納入物との交換、（ⅱ）権利侵害している部分の変更、（ⅲ）継続使用のための権利取得のいずれかの措置を講じることができるものとする。

3.　第１項に基づき乙が負担することとなる損害以外の甲に生じた損害については、第●条（損害賠償）の規定によるものとする。

 

⑫　第三者ソフトウェアの利用

システム開発において、ベンダは、自前のソフトウェアだけを用いるわけではなく、実際は第三者が権利を有するソフトウェアも用いて、開発を進めていくことが少なくありません。
したがって、第三者ソフトウェアに関する契約不適合や権利侵害についても条項を設けておくとよいでしょう。

【条項例】

第●条　乙は、本件業務遂行の過程において、本件ソフトウェアを構成する一部として第三者ソフトウェアを利用しようとするときは、第三者ソフトウェアを利用する旨、利用の必要性、第三者ソフトウェア利用のメリット及びデメリット、並びにその利用方法等の情報を、書面により提供し、甲に第三者ソフトウェアの利用を提案するものとする。

２．甲は、前項所定の乙の提案を自らの責任で検討・評価し、第三者ソフトウェアの採否を決定する。

３．前項に基づいて、甲が第三者ソフトウェアの採用を決定する場合、甲は、甲の費用と責任において、甲と当該第三者との間で当該第三者ソフトウェアのライセンス契約及び保守契約の締結等、必要な措置を講じるものとする。但し、乙が、当該第三者ソフトウェアを甲に利用許諾する権限を有する場合は、甲乙間においてライセンス契約等、必要な措置を講ずるものとする。

4.　乙は、第三者ソフトウェアに関して、著作権その他の権利の侵害がないこと及び契約不適合のないことを保証するものではなく、乙は、第1項所定の第三者ソフトウェア利用の提案時に権利侵害又は契約不適合の存在を知りながら、若しくは重大な過失により知らずに告げなかった場合を除き、何らの責任を負わないものとする。但し、前項但書の場合で、甲乙間においてライセンス契約が締結され、当該ライセンス契約に別段の定めがあるときには、当該定めによるものとする。

 

⑬　輸出関連法令の遵守

開発されるシステムの内容いかんによっては、これを外国へ輸出する際、技術情報等の軍事転用の防止を目的とする法令等の規制に服する場合があります。

【条項例】

第●条　甲は、乙から納入された納入物を輸出する場合には、外国為替及び外国貿易法その他輸出関連法令を遵守し、所定の手続をとるものとする。なお、米国輸出関連法等外国の輸出関連法令の適用を受け、所定の手続が必要な場合も同様とする。

５．おわりに

以上、システム開発の基本的な流れと契約書作成上のポイントについて、検討してきました。
今回紹介した内容は、システム開発そのものや開発契約の締結に関して少なくともおさえておくべきポイントをまとめたにすぎません。

クラウドやAIの登場により、開発されるシステムそのものは、日々進化し続けていますので、実際の取引の現場にいらっしゃる方々は日々これに関する知識をアップデートしていく必要があります。

また、本コラムで紹介したシステム開発契約の流れは、概略にすぎませんので、実際のシステム開発契約書は、より詳細な開発の流れを前提として作成していく必要があります。
経済産業省が所管する情報処理推進機構が、「情報システム・モデル取引・契約書」と題して、現状のシステム開発の潮流を踏まえた契約書の詳細な雛形を発表しています（URL：https://www.ipa.go.jp/ikc/reports/20201222.html）ので、こちらを参考にしてみるとよいでしょう。

本コラムが、システム開発事業に関わる知識の習得のきっかけ又は一助になりましたら幸いです。