基本情報技術者単語帳 - システム企画

新しいシステムの最も初期段階のいわゆる超上流工程の一部で、経営戦略や事業計画、現行の業務状況などを整理し、システム化の対象となる業務を選定して、システム導入後の業務や事業の全体像をまとめる。

構想について経営層の承認が得られたら、システム化する業務の内容を分析し、どのような情報システムが必要となるか、どのように開発・導入を進めるかなどの基本方針を策定するシステム化計画を行う。構想と計画を合わせた工程を「企画プロセス」と呼ぶこともある。

ビジネスアナリシス(BA：Business Analysis)とは、企業などの組織構造や業務内容、経営戦略などを理解し、その目標を達成するための解決策を見出し、関係者間の調整を行う一連の活動を指す。IT分野においてはシステム開発などの初期に行われるシステム企画や要求分析を的確に行うために必要とされる。

BABOKはビジネスアナリシスに求められる知識や技能を体系化したもので、2015年に刊行されたBABOK 3.0は全8章で構成される。「ビジネスアナリシスの計画とモニタリング」「引き出しとコラボレーション」「要求のライフサイクルマネジメント」「戦略アナリシス」「要求アナリシスとデザイン定義」「ソリューション評価」の6つの「知識エリア」に分かれており、全体で30のタスクを定義している。

人間の活動に伴って発生する大量のデータを正確かつ効率的に記録、蓄積し、用途に応じて計算や加工を行い、必要な形式で出力することを主な任務とする。1950年代のコンピュータシステムの商用化以降、企業や官公庁などが業務の遂行や効率化などのために構築・運用してきた情報システムの大半はこれに該当する。

一方、人間と他の人間、組織、物事などの間の結びつき、関与を作り出し、あるいは強化するために構築される情報システムは「SoE」(System of Engagement)と呼ばれ、1990年代頃から使われ始めた。近年では、蓄積された情報の加工や分析を通じて何らかの有用な洞察を得ることを主目的とする「SoI」(System of Insight)も用いられるようになっている。

携帯電話や電子メール、SNS、メッセンジャーなど人間の繋がりのサポートや共同作業、メッセージの伝達などを行うシステムが含まれる。企業内の業務システムでも、グループウェアやコラボレーションツールのように集団での業務や作業を促進するもの、顧客との接点を担うものなどは一種のSoEと考えることができる。

また、そのシステムに多くの人間が集まって関与することによって成り立つ仕組みを含める場合もある。例えば、Wikipediaのような利用者参加型のコンテンツ作成プロジェクト、オープンソースソフトウェアの開発、利用者間のモノやサービスの交換・提供を取り次ぐネットサービスなどがこれに該当する。

1950年代にコンピュータが現れた当初は、事務作業の効率化などのために大量のデータを記録・処理することが主目的の「SoR」(System of Record)しか存在しなかったが、1990年代頃から新たな情報システムの利用法としてSoEが普及し始めた。近年では、蓄積された情報の加工や分析を通じて何らかの有用な洞察を得ることを主目的とする「SoI」(System of Insight)も現れている。

一般的な半導体製造プロセスではシリコン単結晶の基板の表面に回路を形成するが、回路中にあるトランジスタのソースやドレインから基板のシリコンに向けて電流が漏れるリーク電流が大きな問題となっていた。

SoIではシリコンウェハをシリコン基板-絶縁膜-シリコン膜の3層構造に加工し、表面のシリコン膜に通常の製造プロセスで回路を形成する。基板の下層との間に絶縁膜があることによりリーク電流を減らすことができる。

素子の下面が直に絶縁膜に接するほどシリコン膜を薄くしたものをFD-SOI(Fully-Depleted SOI)、素子の下部にもシリコンの層が入り込む厚い膜を用いるものをPD-SOI(Partially Depleted SOI)という。前者のほうが電流の遮断効果が大きく性能や特性を大きく向上させられるが、製造が難しくコストが高いため、実際に多く使われるのは安価な後者である。

新しいシステムの最も初期段階であるいわゆる超上流工程の一部で、システム化構想によってシステム化の対象に選定された業務について、その内容を分析・整理し、ふさわしいシステム方式や目標とする品質などを基本方針として策定する。

大まかなスケジュールやコストの概算も同時に行うことが多い。システム化計画が完了・承認されると、計画の実行段階へ移行し、開発の初期段階である要件定義プロセスなどへ進むことになる。

システム化によって実現する新しい業務モデルを固める段階であり、ここで経営戦略に合致した的確な計画が立てられなければ、この後の工程でシステムが滞りなく完成しても有益な効果は得られない。

金融の分野で、投資対象をその特性によって分類し、投資額の配分を調整することでリスクとリターンのバランスを調整する「ポートフォリオ理論」をIT投資に応用したものである。

IT投資の対象をプロジェクト単位やアプリケーション単位、共通した特徴を持つ種類ごとなどで分類し、共通の評価項目で客観的な比較を行って投資額を配分することで、属人性や部門間の力関係などの影響を排して企業戦略に沿った最適なIT投資を実現しやすくなる。

投資対象の分類の仕方は様々な方式が提唱されているが、マサチューセッツ工科大学(MIT)の経営大学院スローン校情報システム研究センターが提唱する著名な「MITモデル」では、IT投資を「戦略」「情報」「トランザクション」「インフラ」の4つに分類する。

また、経済産業省が発表した「業績評価参照モデル(PRM)を用いたITポートフォリオモデルの活用ガイド」では、「戦略目標達成型」「業務効率化型」「インフラ構築型」の3つに分類し、それぞれについて戦略適合性や実現性などの項目に基づいて評価を行う。

要求分析では、利用者が業務を行うにあたって、そのシステムやソフトウェアを使って何がしたいのか、何ができなければ困るのかといった内容を、開発側スタッフ(開発委託先の営業担当者など)による聞き取りや話し合いを通じて明らかにしていく。

結果は主に利用者が普段使っている言葉を使ってまとめられ、「要求定義書」などの形で文書化されることが多い。「要求分析」と「要求定義」はほぼ同義語と解されるが、要求の分析結果を文書などにまとめる工程のみを「要求定義」とし、要求分析の一工程とみなす立場もある。

次の段階として、明確化された利用者の要求を元に、システムやソフトウェアに実装すべき機能や満たすべき性能などを決定する「要件定義」が行われるが、要求分析は要件定義の一部として独立した工程とはみなさない場合もある。

対象物が「何を」できなければならないかを、完成後、実際に利用に供された状況に即して記述する。具体的な構成や構造、機能の実現方法や実装手法など、「どのように」それを実現するのかはこの段階では問わず、設計段階で策定する。

基本的には「文書ファイルの全文検索ができる」といったように機能について記述する(機能要件)が、「できる」というだけでは解釈に幅があり、「確かに『できる』がこの現場では実用にならない」という状況が生まれる余地があるため、「最大1万件の文書ファイルを10秒以内に全文検索できる」といったように性能などの特性についても定義する場合がある(非機能要件)。

何をもって良い要求仕様書とするかには分野や対象物などによって様々な考え方があるが、一例として、ソフトウェア開発の要求仕様書についての国際規格であるIEEE 830では、「正確で」(Correct)、「曖昧さがなく」(Unambiguous)、「過不足なく」(Complete)、「一貫性があり」(Consistent)、「重要度や安定性によって順位付けされており」(Ranked for importance and/or stability)、「検証可能で」(Verifiable)、「変更可能で」(Modifiable)、「追跡可能である」(Traceable)という8つの特性を挙げている。

要件定義では、利用者がそのシステムで何がしたいのかを元に、それを実現するために実装しなければならない機能や、達成しなければならない性能などを開発者が検討して明確にしていく。

まとめられた成果は「要件定義書」として文書化されることが多い。一般的にこの段階では「何が」必要なのかを定義するに留め、それを「どのように」実現するかは後の工程で検討される。

主に利用者側の視点から業務手順を明確化して分析し、情報システムで何がしたいのかをまとめる工程と、これを元に開発者側の視点からシステムが何をすべきか、何が必要かをまとめる工程に分割して考える場合もあり、前者を(狭義の)要件定義と区別して要求定義と呼んだり、両者とも要件定義内の工程として業務要件とシステム要件と呼び分けたりする。

主に大企業などが専門の事業者にシステム開発を委託する際に用いられるウォーターフォール型の開発モデル(前工程を完全に終わらせて次工程に移る方式)では、要件定義はプロジェクトの最初に一度だけ行われ、これを元にシステムの仕様や設計が固められる。

一方、アジャイル開発など同じ工程の流れを循環的に繰り返す反復型の開発モデルでは、前の反復で作られた半完成品に触れながら要件定義を繰り返し、段階的に要件を明確化・詳細化していく手法が用いられる場合もある。

「オブジェクト指向」(object-oriented)はコンピュータプログラムの構成法の一つで、関連するデータと手続きを一つにまとめた「オブジェクト」(object)をプログラムの基本的な構成単位とし、オブジェクト間の相互作用として様々な処理を記述していく。

オブジェクト指向分析はこの考え方をシステム化の対象領域の分析に用いるもので、システムが取り扱う業務などの構成要素や情報の流れ、手続きなどを分析し、属性と操作をひとまとまりにしたオブジェクトとその相互作用として記述していく。結果はUMLなどを用いて図に表すことが多い。

ここで現れるオブジェクトはソフトウェアの実装上のオブジェクトとは異なり、現実世界に登場する主体や手続きを忠実にモデル化したものとなる。これをコンピュータプログラム上でどのように取り扱うかについては分析に続いて行われる「オブジェクト指向設計」(OOD：Object-Oriented Design)工程で検討される。OOAとOODを合わせて「OOAD」(Object-Oriented Analysis and Design：オブジェクト指向分析設計)という。

システムが扱うデータの流れを整理するための図法で、対象となるシステムと利用者や外部のシステムなどのデータの流れを図示する場合と、システム内の構成要素(データストアやプロセスなど)間の流れを図示する場合がある。

データは発生源から様々な処理(プロセス)を経て出力先へ収まる。一つの図にあまり多くの要素を図示すべきではないとされ、。全体的で抽象的なレベルから作図し、段階的に詳細化した図を描いていくという手法が用いられることが多い。

DFDでは、データの保管や取り出しを行う「データストア」を平行な上下二本線で、データを処理するソフトウェアなどの「プロセス」を丸で、データの発生源や出力先である「外部実体」(ターミネータ)を長方形あるいは楕円で示す。これらの要素の間をデータの流れ(フロー)を表す矢印で結んでいく。

プロセスには入力と出力を表す「フロー」がそれぞれ一つ以上必要で、データストアや外部実体は入力または出力のいずれか一方のフローが必要となる。また、各フローの一方の端は必ずプロセスでなければならない。

一般的な表現形式では、表の上半分を条件、下半分を判断(動作、行動ということもある)とし、左端の列に条件や判断の項目を列挙する。条件の行には右にその正否(当てはまるか否か)を列挙していくが、このとき各列の正否の組み合わせがすべて異なるようにする。判断の行には、各列の条件の組み合わせの時にどのような判断となるかを記載していく。

列の数は条件の組み合わせの数だけ必要なため、2の条件数乗となる。すなわち、条件が2つなら(条件A：Yes,条件B：Yes)(Yes,No)(No,Yes)(No,No)の4列だが、3つなら8列、4つなら16列といったように条件が増えることに2倍に増えていく。

決定表は様々な分野で用いられるが、ITの分野ではシステム開発などでシステムの挙動を指定するために仕様書などに記載したり、テスト時にテストケースと正しい結果の対応関係を分かりやすく整理するために用いられることが多い。

ソフトウェア開発では、プログラムを作成する前にシステムの設計や構造、振る舞いを定義し、発注者と開発者、あるいは開発チーム内で仕様について共通認識を得る必要がある。その際、説明が文章や箇条書きだけだと分かりにくく、多数の要素の複雑な相互作用などを簡潔に表現することが難しい。

UMLでは、システムをオブジェクトの組み合わせとしてモデル化し、その構造や仕様を図表によって記述するための表記法を定めている。システムの構成要素の定義や、要素間の関連性、要素の振る舞いなどを図示することができる。

図表の描き方が人や組織によってまちまちでは相互理解に支障を来すが、標準化されたUMLという共通の「言語」を用いることで、書き手の意図を正しく読み手に伝えることができる。システムの様々な側面を伝達できるよう、UMLには14種類の図が用意されている。

UMLの仕様は1996年に当時のラショナル・ソフトウェア(Rational Software)社(2003年に米IBM社が買収)が策定した。その後、仕様の策定・改訂は業界団体のOMG(Object Management Group)が行うようになった。UML1.4が2005年にISO/IEC 19501として、UML 2.4が2012年にISO/IEC 19505としてそれぞれ国際標準となっている。

図の種類

UMLで定義される図は大きく分けて、システムの構造を表す「構造図」(structure diagram)と、動作や変化を表す「振る舞い図」(behavior diagram)の2種類に分類される。

構造図には「クラス図」(class diagram)、「オブジェクト図」(object diagram)、「コンポーネント図」(component diagram)、「パッケージ図」(package diagram)、「配置図」(deployment diagram)、「複合構造図」(composite structure diagram)、「プロファイル図」(profile diagram)がある。

振る舞い図には「アクティビティ図」(activity diagram)、「ユースケース図」(use case diagram)、「ステートマシン図」(state machine diagram)、「相互作用図」(interaction diagram)がある。

相互作用図はさらに、「シーケンス図」(sequence diagram)、「コミュニケーション図」(communication diagram、以前はコンポーネント図と呼ばれていた)、「タイミング図」(timing diagram)、「相互作用概要図」(interaction overview diagram)に分かれる。

まず業務で扱うデータ全体をERモデル(Entity-Relationship model)など何らかの手法でモデル化し、データベースやデータファイルの設計や構造などとして明確化する。プログラムはこのデータ群を業務手順に従って入出力、加工、保存する道具として設計・実装される。

企業などが永続的に保存・管理するデータの種類や意味、形式などは比較的安定しており、これをシステム構造の基礎におくことで、業務内容や手順に変更があってもデータベース部分はそのままでプログラムのみを修正・置するといった更新が行いやすくなる。

また、DOAでは具体的な処理内容やプログラムの実装とは切り離してデータを定義・蓄積するため、様々なシステムや部門(野心的なプロジェクトでは全社・全システム)で共有される情報資産としてのデータ基盤を構築することができる。一度データ基盤を整えれば、システムやプログラムの追加や修正も局所的な変更で対応できるようになる。

DOAやそれに類似する考え方(DCE：データ中心工学、IE：インフォメーションエンジニアリングなど)は1970年代に広まったもので、それ以前は業務の流れや処理の手順などを中心にシステムを設計するPOA(Process Oriented Approach：プロセス中心アプローチ)が一般的だった。

これは業務の一部の手順を自動化する小規模なプログラムの開発には適していたが、システムの規模や対象の範囲が広がると、データの形式や扱い方が部署やシステムごとに異なり整合性がないことが開発や運用の効率悪化を招くようになり、データを中心に据えるDOAの考え方が脚光を浴びるようになった。

企業の場合、直接的なステークホルダとしては金銭の授受や損益が生じる株主や経営者、従業員、労働組合、債権者、発注先、提携先、貸主や地主、顧客、取引金融機関、税務当局などが含まれる。

間接的には、事業の監督官庁や所管官庁、事業所所在地の周辺住民や自治体などが含まれることもある。企業とステークホルダを対置する文脈では、経営者や株主については企業自身と一体の存在である(企業を「取り巻く」存在ではない)としてステークホルダから外す考え方もある。

また、規模や事業内容、文脈によっては、同業企業(競合企業)や業界団体、政治家、従業員の家族、(顧客以外の)消費者、求職者、証券会社や株式市場、投資家、報道機関、研究機関、事業分野に企業活動に関連するNPOやNGO(環境団体や人権団体など)などがステークホルダに含まれることもある。

企業に限らず、官公庁や非営利団体など様々な種類の組織や集団、人物、事件、製品、案件などについて、利害関係のある人や組織を総称してステークホルダという。

なお、個別のある利害関係者について、株主を指すなら株主、従業員を指すなら従業員と言えば良いため、あえて「ステークホルダ」という言い回しをするのは、複数の異なる種類の利害関係者をまとめて総称する必要がある場面に限られる。

製品やサービスを買い手・利用者に対して直に販売する事業者などを指し、自らがその製品を開発・製造しているとは限らない。開発元や製造元が別にいる場合はこれを「メーカー」(maker)と呼ぶことがある。また、買い手・利用者のことは「ユーザー」(user)「カスタマー」(customer)「クライアント」(client)などという。

インテグレータとベンダ

企業や官庁などから委託を受けて情報システムをオーダーメイドで開発・構築して販売する事業者を「システムインテグレータ」(SIer)というが、インテグレータから見てシステムの構成要素(機器や既製ソフトウェアなど)の供給元のことをベンダー企業と呼ぶ。

ある特定の企業の製品(コンピュータ本体や周辺機器、オペレーティングシステム、ミドルウェア、開発ツールなど)だけでシステムを構築することを「シングルベンダー企業」、複数の企業の製品を組み合わせて構築することを「マルチベンダー企業」という。

一方で、情報システムの発注者・利用者の側(ユーザー企業)からは、インテグレータのことをシステム全体の売り主として「ITベンダー企業」「システムベンダー企業」「開発ベンダー企業」などと呼ぶことがあり、ベンダー企業という語の使用や解釈には立場や文脈に留意する必要がある。

製品やサービスに求める要件や調達条件などを決定するために必要な情報を集めるために発行するもので、一般的にはこれを元にRFP(Request For Proposal：提案依頼書)を作成し、具体的な提案の募集と発注先の選定に移る。

発注元の担当者や担当部門は発注先の専門事業者に比べて技術や当該分野の事情などに通じていないことが多くあり、自らの必要とするシステムや製品などをどのように定義・記述すればよいか決めかねる場合がある。

また、初めて発注するタイプのシステムや、Web関連など技術変化の速い分野で久しぶりにシステムを更新するような場合、取引したことのない業者に発注する場合などには、システムの構成要件や調達条件を記述するための基礎的な情報が不足していることがある。

このような場合にRFIが作成され、事業者から必要なシステムに関連する情報を提供してもらい、適切なRFP作成に役立てる。同時に、事業者に発注の可能性があることを知らせて提案の準備を促したり、RFIの結果を比較してRFPを発行するに足る能力があるか事前審査(スクリーニング)を行う場合もある。

RFIに盛り込む項目は業界や発注元によって様々だが、RFI作成の趣旨や目的を説明し、事業者の基本情報、提供している製品やサービスの概要、同種のプロジェクトの経験や遂行能力などを尋ねることが多い。事業者が何を答えれば良いか迷わないよう、問い合わせ事項を明確にするのが重要で、記入式の回答書の雛形(テンプレート)などを添付することも多い。

一般的なRFPには、まずシステム導入の目的や背景、現状の課題を記述し、今回の案件の範囲や目標、目安となるスケジュールや予算規模などを提示する。選定の進め方や日程、選定方針なども指定する。現行のシステムが存在する場合はその概況を記述したり、発注元企業の組織や事業、業務の説明を加えることもある。

これを踏まえ、提案を依頼したい項目を挙げていく。案件の内容によるが、システムの概要や要件、開発体制、開発手法、納品される成果物の構成、運用・保守の方法や内容、スケジュール、費用の見積もり、契約方法などを要求することが多い。

これまで情報システム業界では、口約束やあいまいな発注による開発現場の混乱や紛争の発生、納期の遅れやシステム障害などに悩まされてきた。事前にRFPを通じて調達条件や契約内容を明らかにしておくことで、こうした混乱を未然に防ぐことができる。RFPに先立って必要な情報を集めるためにRFI(Request For Information/情報提供依頼書)を発行する場合もある。

購入を希望する物品やサービスの仕様や数量を示し、相手方に購入する際の価格の提示を要求するもので、納期や受渡方法、納品場所、支払方法など、取引に付帯する情報を記入する場合もある。

既製品や一般的な製品を購入したい場合は最初からRFQを作成することができるが、システム開発や業務・事業の委託などの場合には製品仕様や発注要件などを定めるために下準備としてRFI(Request For Information/情報提供依頼書)やRFP(Request For Proposal/提案依頼書)などを発行することが多い。

組織の目的を達成し、逸脱が起こらないようにするため、組織の管理者、経営者が整備、運用する制度である。企業においては経営陣が従業員を監督する仕組みと解されるが、営利法人に限った概念ではなく、公的な機関や非営利法人においても求められる。

日本では会社法および金融商品取引法の一部(日本版SOX法)がそれぞれ独立に企業に対する内部統制の規定を定めており、前者は主に大企業(大会社)、後者は主に上場企業(有価証券報告書を提出する会社)に適用される。

よく参照される企業会計審議会内部統制部会の報告では、内部統制の目的を「業務の有効性・効率性」「財務報告の信頼性」「法令遵守」「資産の保全」の4つとしており、これを達成するため、「統制環境」「リスクの評価と対応」「統制活動」「情報の伝達」「モニタリング」、「ITへの対応」の6つを基本的な要素と定義している。

内部統制のうちIT分野に属する規定や活動を「IT統制」という。現代の企業活動にITの利用は不可欠であり、ITを適切に利用する統制、ITを活用した内部統制の実施のどちらも重要となる。IT統制はさらに「IT全社的統制」「IT全般統制」「IT業務処理統制」に分類される。

企業法令遵守とは、企業が業務の遂行にあたって法律や条例、政令、規制、業界団体などが定めた規則や申し合わせ事項、自主規制といった各種のルールを遵守することを意味する。外部で制定されたものに加えて、自社内で独自に定めた社内規則や倫理規定、行動規範などを対象に含めることもある。

法令遵守は企業統治(コーポレートガバナンス)および内部統制の重要な構成要素の一つとされ、担当の部署や体制を設けたり、社内通報制度などの仕組みを整備することもある。株式市場では上場審査などに関連する項目があり、上場後も内部統制報告書などで報告・開示が義務付けられている。

一般的には遵守する対象は何らかの形で明文化されたルールであり、倫理や道徳、社会的規範、常識などモラルやマナーの範疇に属するものは含まれないが、これらを含めて法令遵守の対象にすべきであるとする考え方もある。

企業が単に合法に活動するのみに留まらず、市民社会の一員として社会に与える影響に対して相応の責任を負うべきであるとする考え方を「CSR」(Corporate Social Responsibility：企業の社会的責任)という。

CSR調達は取引先からの調達業務にこの考え方を適用したもので、調達条件の設定などを通じて、調達先の企業に対しても自社のCSR規範に準じる水準の社会的責任を果たすよう求める。具体的な基準は企業によって異なるが、人権の尊重や労働環境の適正化、環境への配慮、反腐敗(贈収賄の禁止など)などの項目で構成されることが多い。

CSR調達の中でも、企業が生産活動などで使用する部材や原材料、製造設備などについて、省資源・省エネルギーで製造された製品や、汚染物質や有害物質を含まない製品など、環境負荷の低いものを優先的に選択することを「グリーン調達」(green procurement)という。

グリーン調達における環境への配慮には、製造・流通工程における二酸化炭素(CO₂)排出量の削減や省資源・省エネルギーなど主にCSR(企業の社会的責任)の観点から求められるものと、規制化学物質の削減や排除など法令適合(コンプライアンス)やリスク管理の観点から必要となるものがある。

グリーン調達調達を実施している企業などは独自の調達基準を策定し、調達元に対して特定の物質の使用を控えるよう求めたり、原料や部材に含まれる物質の種類や含有量の報告を求めたり、環境関連の認証・資格の取得を求めたりしている。

工業製品に含まれる化学物質の規制は国や地域により異なるため、グローバルに活動する製造業では生産国で問題にならない物質が販売国の規制に抵触するといった問題が生じることがある。各社がグリーン調達を推進するのは単にCSR対応や企業イメージの向上などのためだけでなく、こうした問題に対応するためでもある。

似た概念として、主に国や自治体、消費者などが最終製品を購入する際に環境負荷の低い製品を積極的に選ぶことを「グリーン購入」というが、グリーン調達をグリーン購入の同義語として用いることもある。

業務委託には「請負契約」と準委任契約がよく用いられるが、請負契約は仕事の完成を目的とし、受注者は委託された業務を完成・完了させて成果を発注者に引き渡す義務を負う。一方、準委任契約は定められた期間だけ業務を遂行することが目的で、仕事の完成の成果物の保証(瑕疵担保責任)などの義務は生じない。

成果を保証せず作業の遂行自体を委託する点では「派遣契約」にも似ているが、派遣の場合は発注者が作業者に直に指揮・命令できる一方、準委任契約で発注した仕事は受注者側の責任において遂行される。発注者が直接監督することは偽装請負となり違法となる。

なお、「準」のつかない「委任契約」は法律行為の実施を委託する契約のことで、弁護士と依頼人の間などで交わされるものである。弁護士資格のない者が委任契約を結んで法律行為を行うことは弁護士法で禁止されている。

依頼主側に人員を送り業務に就かせる人材派遣と異なり、業務を実施するための資金、人員、施設、設備、材料などは請負側の責任で用意・調達する。また、従業員の労務管理や指揮命令は請負側の管理監督者が行わなければならない。

依頼主側の監督者が請負側のスタッフを指揮するなど、これらの要件を満たさない場合、実態は直接雇用や労働者派遣であるのに請負契約を装った「偽装請負」となり、職業安定法や労働基準法などに対する違反となる。

請負契約と準委任契約

業務請負では具体的な契約形態として「請負契約」と「準委任契約」のいずれかが用いられることが多い。

請負契約とは、仕事の完成を目的として、納期までに成果を納めて対価を得る契約形態で、受注者は納期までに委託された業務を完遂して成果を発注者に引き渡す義務を負う。成果物に不具合がある場合も受注者側の責任で対応する義務がある(瑕疵担保責任)。

一方、準委任契約は仕事の完成などは保証せず、定められた期間だけ業務を遂行することを委託する契約形態である。派遣に近いが、請負契約の一種であるため発注者による直接の指揮監督は認められない。IT分野では「SES」(システムエンジニアリングサービス)の呼称で定着している。

一般的なソフトウェア製品では、コンピュータへの導入(インストール)時に画面上に契約条件が表示され、利用者が「同意する」などと書かれたボタンを押すなどして意思を示すことで契約が締結されたとみなされる(クリックラップ契約)。パッケージに書面が添付され、記録メディアの開封時に自動的に許諾したとみなす場合もある(シュリンクラップ契約)。

具体的な条文や条件は製品によって異なるが、著作権などの権利の所有者の宣言・確認や、購入者に許可される行為と禁止される行為、ソフトウェアの使用に伴い生じた結果についての開発元の免責などがうたわれることが多い。

多くの場合、購入者本人が使用する以外の行為のほとんどは禁止あるいは厳しく制限されており、特に、第三者への譲渡や販売、貸与、複製、改変、二次著作物の作成、逆コンパイル、リバースエンジニアリングなどは明示的に禁止されていることが多い。