システム戦略と企画

1. 情報システム戦略と業務プロセス

個別最適に陥らないための全体最適化の考え方と、EA・業務モデリング・BPR/BPMという道具の使い分けが分かります。

情報システム戦略とは、経営戦略を実現するために、情報システムをどんな姿にしていくかを定めた方針と計画です。出発点になる問題意識は、部門ごとに都合よく作ったシステムが乱立すると、同じ顧客データが三つの台帳に別々に入り、つなぐたびに変換処理が増え、全体としては誰も幸せにならないという現実です。これを避けるため、組織全体を見渡して重複や断絶をなくす全体最適化を掲げ、その方針を全体最適化方針、実現の道筋を全体最適化計画としてまとめます。方針を決めて優先順位を裁く場が情報システム戦略委員会で、ここに経営層が入っていないと、部門間の利害調整ができずに個別最適へ戻ってしまいます。責任者を置く場合はCIO（最高情報責任者）と呼び、経営とITの橋渡しを担わせます。

全体最適化を具体的に進めるための枠組みがEA（エンタープライズアーキテクチャ）です。組織の姿を四つの体系に分けて記述します。ビジネスアーキテクチャは業務の内容と流れ、データアーキテクチャは業務が扱う情報の構造と相互関係、アプリケーションアーキテクチャは業務を支えるシステムの機能構成、テクノロジアーキテクチャはそれを動かすハードウェア・ネットワーク・基盤ソフトウェアです。上の層が下の層の要求を決め、下の層が上の層を支える関係にあります。進め方は、まず現状（As-Is）を記述し、次にあるべき姿（To-Be）を描き、両者の差を洗い出して（ギャップ分析）、埋める順番を移行計画にする、という流れです。To-Beだけを描いても、現状との差が見えなければ何から手を付けるか決められません。共通に使える型をあらかじめ用意した参照モデルを使うと、記述の粒度がそろって比較しやすくなります。

業務そのものを作り直す取組みがBPR（ビジネスプロセスリエンジニアリング）です。既存の手順を前提に少しずつ改善するのではなく、業務の目的にさかのぼって業務プロセスを根本から設計し直します。ITはその手段として使いますが、順序が逆になってはいけません。いまの業務をそのままシステム化すると、無駄な承認段階や重複入力までシステムに固定してしまい、あとから変えにくくなります。BPRが一度きりの大きな作り直しであるのに対し、BPM（ビジネスプロセスマネジメント）は、業務プロセスの設計・実行・監視・改善というPDCAを回し続ける継続的な活動です。BPMを支えるソフトウェアがBPMSで、定義したプロセスをそのまま実行し、進行状況を計測して改善に返します。定型の手続をあらかじめ定めた順路で流す仕組みがワークフローシステムで、BPMの実行部分を担います。

業務を設計し直すには、まず現状を目に見える形にしなければなりません。そのための表記法がいくつかあります。DFD（データフロー図）は、データの流れに着目して業務を表す図で、処理（プロセス）・データストア・外部実体（源泉と吸収）・データフローの四つの記号だけで書きます。全体を1枚で表したコンテキストダイアグラムから、段階的に詳細化していくのが基本の使い方です。DFDは「データがどこからどこへ流れるか」は表せますが、処理の順序や条件分岐、タイミングは表せません。BPMN（ビジネスプロセスモデル表記法）は、レーンで担当者や組織を分け、イベント・アクティビティ・ゲートウェイ・シーケンスフローで、誰が何をどんな順で行うかを表します。分岐や並行、例外の扱いまで書けるので、部門をまたぐ業務の合意形成に向きます。ほかに、データの構造を表すE-R図、業務の状態変化を表す状態遷移図、UMLのアクティビティ図やユースケース図も使われます。要は、データの流れを見たいならDFD、手順と担当を見たいならBPMNやアクティビティ図、というように、見たいものに合わせて表記法を選ぶということです。

業務プロセスの善し悪しを測る物差しも決めておきます。最終的に達成したい目標がKGI（重要目標達成指標）、その達成に決定的に効く要因がCSF（重要成功要因）、CSFの進み具合を数値で追うのがKPI（重要業績評価指標）です。たとえば「解約率を年5%まで下げる」がKGIなら、CSFは「問合せへの初回応答の速さ」、KPIは「初回応答までの平均時間」といった具合につながります。KPIは、それを改善すればKGIに近づくと言える指標でなければ意味がありません。測りやすいというだけの理由で選んだ指標を追いかけると、指標だけが良くなって目的が達成されない事態を招きます。業務プロセスの改善では、こうした指標を先に決めてから現状を測り、改善後に同じ物差しで測り直すのが基本です。

組織をまたぐ改善では、外部に任せるという選択肢も出てきます。自社の中核でない業務をまとめて外部の専門事業者に委託するのがBPO（ビジネスプロセスアウトソーシング）で、給与計算やコールセンタが典型です。効果は、専門事業者の規模の経済とノウハウを使えることと、自社の資源を中核業務に集中できることにあります。一方で、委託した業務の知見が自社から失われ、後から内製へ戻しにくくなること、委託先の品質や情報管理に依存することが代償です。したがって、何を中核業務とみなすかという判断が先にあり、その線引きなしにコストだけを理由にBPOを選ぶと、あとで戦略の自由度を失います。全体最適化とは、こうした「自社でやること」と「任せること」の線引きも含めた設計だと考えると、EAやBPRの位置づけが見えてきます。

/* DFDで使う記号は4つだけ */外部実体（源泉と吸収）: システムの外側にあるデータの出どころと行き先。例 顧客, 取引先銀行処理（プロセス）      : データを受け取って変換し、送り出す働き。例 受注を登録するデータストア          : データが留まる場所。例 受注ファイル, 商品マスタデータフロー          : 上の3つの間を流れるデータ。矢印に名前を付ける。例 受注データ /* 受注業務の第1階層をDFDで書き下すと */顧客 --注文書--> [1 受注を登録する] --受注データ--> 《受注ファイル》《商品マスタ》 --在庫数--> [2 在庫を引き当てる] --引当結果--> 《受注ファイル》《受注ファイル》 --出荷指示--> [3 出荷を指示する] --出荷指示書--> 倉庫 /* DFDに書けないもの: 処理の順序, 条件分岐, 実行のタイミング, 制御の流れ *//* それらを表したいときはBPMNやアクティビティ図を使う */

用語

全体最適化

部門ごとの個別最適で生じる重複や断絶をなくし、組織全体として効率と効果が最大になるよう情報システムを設計する考え方。方針と計画の形で文書化する。

CIO

最高情報責任者。情報システム戦略の策定と全体最適化に責任を持ち、経営戦略とITを結び付ける役割を担う経営層の職位。

EA

エンタープライズアーキテクチャ。組織の姿をビジネス・データ・アプリケーション・テクノロジの4体系で記述し、現状とあるべき姿の差から移行計画を作る枠組み。

ギャップ分析

現状（As-Is）とあるべき姿（To-Be）を並べ、両者の差を洗い出す作業。差が見えて初めて、何から着手するかの優先順位を決められる。

参照モデル

EAで用いる、あらかじめ用意された記述の型。業務やデータの分類体系を共通化することで、部門間で粒度をそろえて比較できるようにする。

BPR

ビジネスプロセスリエンジニアリング。既存の手順を前提とせず、業務の目的にさかのぼってプロセスを根本から設計し直す取組み。ITは目的ではなく手段として使う。

BPM

ビジネスプロセスマネジメント。業務プロセスの設計・実行・監視・改善のPDCAを継続的に回す活動。一度きりの作り直しであるBPRとは時間軸が異なる。

ワークフローシステム

申請から承認までの定型の手続を、あらかじめ定めた順路に沿って電子的に流す仕組み。BPMの実行部分を担い、滞留箇所の可視化にも役立つ。

DFD

データフロー図。処理・データストア・外部実体・データフローの4記号でデータの流れを表す。処理の順序や条件分岐、タイミングは表現しない。

コンテキストダイアグラム

対象システム全体を一つの処理として描き、外部実体との間のデータの出入りだけを示したDFDの最上位の図。ここから段階的に詳細化していく。

BPMN

ビジネスプロセスモデル表記法。レーンで担当を分け、イベント・アクティビティ・ゲートウェイ・シーケンスフローで手順と分岐を表す。部門をまたぐ業務の合意形成に向く。

KGIとCSFとKPI

KGIは最終的に達成したい目標、CSFはその達成に決定的に効く要因、KPIはCSFの進み具合を測る数値指標。KPIは改善すればKGIに近づくものを選ぶ。

BPO

ビジネスプロセスアウトソーシング。中核でない業務を外部の専門事業者にまとめて委託すること。資源の集中が利点だが、知見の流出と委託先依存が代償になる。

例題

出典・根拠：IPA「応用情報技術者試験（レベル3）」シラバス Ver.7.2 大分類7：システム戦略　中分類17：システム戦略

2. ソリューションとクラウドの選び方

SaaS・PaaS・IaaSの責任分界を押さえ、クラウド移行やSOA・API連携をどんな基準で選ぶかが判断できるようになります。

自社で機器を持って自社で運用する形をオンプレミスといい、これに対して、ネットワーク越しに必要なだけ計算資源やサービスを借りる形をクラウドコンピューティングといいます。米国NISTの定義では、クラウドの本質的な特徴を五つ挙げます。利用者が事業者とやり取りせずに資源を確保できるオンデマンドセルフサービス、ネットワーク経由でどこからでも使える幅広いネットワークアクセス、複数の利用者で物理資源を共有する資源の共用、需要に応じて即座に増減できる迅速な弾力性、使った量が計測され従量課金の根拠になる測定されたサービスの五つです。この五つのうち、判断に効くのは弾力性と従量課金です。需要の変動が大きい業務ほどクラウドの相対的な利点が大きく、負荷がほぼ一定で長期に使い続ける業務ほどオンプレミスのほうが安くなる可能性が出てきます。

サービスモデルは三つに分かれます。IaaS（Infrastructure as a Service）は、仮想サーバ・ストレージ・ネットワークといった基盤だけを借りる形で、OSから上は利用者が用意します。PaaS（Platform as a Service）は、OSとミドルウェア、実行環境まで事業者が用意し、利用者はアプリケーションとデータを載せます。SaaS（Software as a Service）は、完成したアプリケーションそのものを使う形で、利用者が管理するのは自分のデータと設定、利用者アカウントだけです。ここで大事なのが責任共有モデルです。事業者と利用者のどちらが何に責任を負うかは層で決まり、上のモデルへ行くほど利用者の責任範囲は狭くなります。ただし、どのモデルでも利用者の責任として必ず残るものがあります。自社のデータそのもの、アクセス権限の設定、利用者アカウントの管理です。「SaaSだからセキュリティは事業者任せでよい」という判断は成り立たず、設定ミスによる情報公開は利用者側の責任になります。

配備モデルは、単一組織が専用で使うプライベートクラウド、不特定多数が共用するパブリッククラウド、共通の関心を持つ複数組織で共用するコミュニティクラウド、これらを組み合わせて連携させるハイブリッドクラウドに分かれます。似た言葉のマルチクラウドは、複数の事業者のパブリッククラウドを併用する形で、特定事業者への依存（ベンダロックイン）を避けたり、事業者ごとの得意分野を使い分けたりする狙いがあります。ハイブリッドが「自社環境と外部を組み合わせる」話であるのに対し、マルチクラウドは「外部を複数使う」話だ、と区別すると混同しません。なお、事業者の設備に自社の機器を置かせてもらう形をハウジング、事業者の機器を借りる形をホスティングといい、これらは仮想化と自動化を前提とするクラウドとは別の概念です。

既存システムをクラウドへ移す方法にもいくつかの段階があります。仮想サーバへほぼそのまま載せ替えるリフトアンドシフト（再ホスト）は、短期間で移せる代わりに、クラウドの弾力性や運用の自動化といった利点をあまり享受できません。ミドルウェアや実行基盤をクラウドのマネージドサービスへ置き換える方式（リプラットフォーム）はその中間、アプリケーションの構造から作り直す方式（リファクタリング）は、効果が最も大きい代わりに費用と期間がかかります。市販のSaaSへ乗り換える、あるいは廃止するという判断もあります。実務では、まず移せるものを短期間で移し、効果の大きいものから順に作り直す、という二段構えが取られることが多くなります。移行の判断で見落とされがちなのが、データの持ち出しにかかる通信料金と、事業者固有のサービスに依存することで生じる乗り換えの困難さです。

システムどうしをつなぐ考え方も整理しておきます。SOA（サービス指向アーキテクチャ）は、業務機能を独立した部品（サービス）として定義し、それらを組み合わせてシステムを構成する設計思想です。業務が変わったときに、組み合わせを変えるだけで対応できることを狙います。似た方向の発想を、より小さい独立した単位と独立した配備で徹底したのがマイクロサービスアーキテクチャで、サービスごとに別のチームが別の技術で開発し、個別に配備できます。柔軟さと引き換えに、サービス間通信の遅延、分散したデータの整合、障害箇所の特定の難しさといった運用の負担が増えます。連携の実装手段としては、HTTPとJSONを使うWeb API、とりわけリソースをURIで表し、GETやPOSTなどのメソッドで操作するRESTスタイルが主流です。公開したAPIを通じて他社サービスと結び付き、新しい価値を生む動きをAPIエコノミーと呼びます。

選択の判断は、機能の適合、費用、統制の三つで考えると整理できます。SaaSは、標準機能で業務が回るなら最も安く速い選択ですが、業務のほうを標準機能に合わせる覚悟が要ります。過度なカスタマイズを求めるなら、SaaSの利点は失われ、PaaSでの構築や内製のほうが妥当になります。IaaSは自由度が高い代わりに、OS以上の運用と脆弱性対応が自社に残ります。統制の面では、データの保存場所が国外になる場合の法令適用、事業者の監査報告書の入手可否、サービス終了時のデータ返却条件を、契約前に確認しておく必要があります。クラウドの採用可否は技術の問題に見えて、実際には「業務を標準に合わせられるか」「統制を契約で担保できるか」という経営判断になります。

/* RESTスタイルのWeb APIの例（受注リソース） */GET    /orders            受注の一覧を取得するGET    /orders/1024       受注番号1024を取得するPOST   /orders            受注を新規に登録するPUT    /orders/1024       受注番号1024を置き換えるDELETE /orders/1024       受注番号1024を削除する /* 応答の例 */HTTP/1.1 201 CreatedContent-Type: application/json{ "orderId": 1024, "status": "accepted" } /* 状態をサーバに持たせないので、台数を増やすだけで処理能力を伸ばせる *//* URIは操作ではなくリソースを表す。/getOrder のような設計にはしない */

用語

クラウドの5つの特徴

オンデマンドセルフサービス、幅広いネットワークアクセス、資源の共用、迅速な弾力性、測定されたサービス。判断に効くのは弾力性と従量課金の2つ。

IaaS

仮想サーバ・ストレージ・ネットワークなどの基盤を借りる形態。OS以上は利用者が用意し、運用も脆弱性対応も利用者に残るため自由度が高い。

PaaS

OSとミドルウェア、実行環境まで事業者が用意する形態。利用者はアプリケーションとデータに集中できるが、使える言語や構成は事業者の枠内に限られる。

SaaS

完成したアプリケーションを利用する形態。最も速く安く始められるが、業務を標準機能に合わせる必要があり、過度なカスタマイズには向かない。

責任共有モデル

事業者と利用者の責任範囲を層で分ける考え方。上位のモデルほど利用者の範囲は狭まるが、自社データ、アクセス権限の設定、アカウント管理は常に利用者に残る。

ハイブリッドクラウド

自社のプライベート環境とパブリッククラウドを組み合わせ、連携させて使う配備モデル。機密性の高い処理を自社に残す使い分けに用いる。

マルチクラウド

複数の事業者のパブリッククラウドを併用する形。特定事業者への依存を避け、得意分野を使い分ける狙いがある。ハイブリッドとは論点が異なる。

ベンダロックイン

特定の事業者や製品に固有の機能へ依存した結果、他へ乗り換える費用が大きくなり、実質的に離れられなくなる状態。

リフトアンドシフト

既存システムをほぼそのまま仮想サーバへ載せ替えるクラウド移行。短期間で移せるが、弾力性や運用自動化といったクラウドの利点は限定的にしか得られない。

SOA

サービス指向アーキテクチャ。業務機能を独立したサービスとして定義し、組み合わせてシステムを構成する設計思想。業務変更への追随のしやすさを狙う。

マイクロサービス

小さく独立したサービスに分割し、それぞれを個別に開発・配備する方式。柔軟だが、通信の遅延、分散データの整合、障害箇所の特定という運用負担が増える。

REST

リソースをURIで表し、GETやPOSTなどのHTTPメソッドで操作するWeb APIの設計スタイル。状態を持たない呼出しにすることで拡張しやすくする。

APIエコノミー

自社の機能をAPIとして公開し、他社サービスと結び付くことで新たな価値や収益を生む経済圏。決済や地図の連携が代表例。

例題

出典・根拠：IPA「応用情報技術者試験（レベル3）」シラバス Ver.7.2 大分類7：システム戦略　中分類17：システム戦略

3. システム化企画と調達

構想から要件定義までの段取りと、RFI・RFPによる調達、請負と準委任の使い分けが分かります。

システムを作ると決めてから作り始めるまでには、順番の決まった段取りがあります。まずシステム化構想の立案で、経営上の課題からシステム化の対象業務と目的、期待する効果、大まかな全体像を描きます。次にシステム化計画の立案で、対象範囲、開発方式、体制、概算費用、スケジュール、投資対効果、リスクを具体化して、投資の可否を経営が判断できる材料にします。そして要件定義で、利用者にとって何ができればよいかを定めます。ここで押さえるべきは、構想と計画は「何のために作るか」「投資に見合うか」を決める段階であり、要件定義は「何を作るか」を決める段階だという役割の違いです。共通フレームでも、企画プロセスと要件定義プロセスは開発プロセスの前段として位置づけられています。順番を飛ばして要件定義から始めると、そもそも何のための投資だったかが誰も答えられなくなります。

要件は三つに分けて考えます。業務要件は、新しい業務をどう回すかという業務側の要求です。機能要件は、システムが何をするかという振る舞いの要求です。非機能要件は、性能、可用性、拡張性、運用性、移行性、セキュリティ、システム環境といった、機能以外の品質と制約の要求です。応用情報でよく問われるのは非機能要件の扱いで、これが曖昧なまま契約すると、後で「応答が遅い」「障害時に戻せない」といった揉め事になります。合意の粒度をそろえるための道具がIPAの非機能要求グレードで、可用性・性能拡張性・運用保守性・移行性・セキュリティ・システム環境とエコロジーの六つの観点ごとに、達成すべき水準を段階で示して選ばせる形になっています。要件定義の成果物は要件定義書で、これに合意しないまま設計へ進むのは、行き先を決めずに出発するのと同じです。

作るものが決まったら、誰に作ってもらうかを決めます。調達の入口がRFI（情報提供依頼書）で、市場にどんな製品や技術があるか、どの事業者が対応できそうかという情報を集める段階です。ここではまだ提案を求めません。次にRFP（提案依頼書）で、システム化の背景と目的、要件、前提条件と制約、提案してほしい範囲、契約条件、そして提案の評価基準とスケジュールを示して、正式に提案を求めます。RFPに要件と評価基準を書いておくことが要点で、これが曖昧だと事業者ごとに前提の違う提案が出てきて比較できません。受け取った提案書は、あらかじめ決めた基準と重み付けに従って評価します。金額だけで選ぶと、実現性の低い安値提案を掴むことになりかねないので、技術的な実現性、体制、実績、保守の条件も含めた総合評価にするのが通例です。評価の公正さを保つため、評価基準は提案を受け取る前に確定させ、評価に関わる者と提案者との個別接触を制限します。

契約の形は、成果に対して払うのか、行為に対して払うのかで大きく変わります。請負は、当事者の一方がある仕事を完成することを約束し、相手方がその仕事の結果に対して報酬を支払う契約です（民法 第632条）。仕事の完成が義務なので、完成しなければ原則として報酬を請求できません。引き渡した目的物が種類または品質について契約の内容に適合しない場合は契約不適合責任を負い、注文者は不適合を知った時から1年以内に通知しなければ、追完請求・報酬減額請求・損害賠償請求・解除ができなくなります（民法 第637条）。また、仕事が完成しない間は、注文者はいつでも損害を賠償して契約を解除できます（民法 第641条）。委任は、法律行為をすることを相手方に委託して承諾を得る契約で（民法 第643条）、法律行為でない事務の委託には委任の規定が準用され、これを準委任といいます（民法 第656条）。システム開発の役務提供は法律行為ではないので、準委任にあたります。

準委任では、受任者は委任の本旨に従い、善良な管理者の注意をもって事務を処理する義務を負います（民法 第644条）。つまり求められるのは、決められた品質の作業を誠実に行うことであって、成果物の完成そのものではありません。報酬は、特約がなければ請求できず、履行した後に請求するのが原則で、履行の割合に応じた請求も定められています（民法 第648条）。なお、平成29年の民法改正で、委任事務の履行により得られる成果に対して報酬を支払う型が明文化されており（民法 第648条の2）、いわゆる成果完成型の準委任がこれにあたります。したがって「準委任なら成果物に関する定めは一切ない」という理解は正確ではありません。契約はいつでも解除できるのが委任の原則ですが、相手方に不利な時期の解除などでは損害賠償が必要になります（民法 第651条）。請負との違いを一言でいえば、完成義務と契約不適合責任を負うのが請負、善管注意義務を負うのが準委任、ということになります。

工程によって不確実性の度合いが違うので、一つの契約で全工程をまとめるのは無理があります。そこでIPAの情報システム・モデル取引・契約書では、工程ごとに契約を分ける多段階契約の考え方を採ります。要件が固まっていない要件定義のような工程は準委任、要件が確定していて成果物を特定できる設計から製造の工程は請負、利用者の主体的な関与が前提となる受入支援や運用テストの支援は準委任、というように工程の性質で選び分けるのが基本です。要件が未確定の段階で請負契約を結ぶと、何をもって完成とするかを決められないまま完成義務だけが生じ、揉め事の温床になります。モデル取引・契約書は中立の立場で作られており、平成29年民法改正への対応のほか、プロジェクトマネジメント義務と協力義務、セキュリティ、複数契約の関係といった論点も整理されています。なお、委託先の要員に自社が直接指揮命令を行うと、契約の名目が請負や準委任でも実態は労働者派遣とみなされる（偽装請負）ため、指揮命令系統を混ぜないことが運用上の大前提になります。

/* 調達の流れと、それぞれの段階で確定させるもの */1. RFI（情報提供依頼）  : 市場にどんな解があるか。事業者の対応可否と概略情報を集める2. RFP（提案依頼）      : 目的, 要件, 制約, 提案範囲, 契約条件, 評価基準を提示して提案を求める3. 提案書の受領         : 事業者から機能, 体制, 実績, 見積金額, スケジュールの提案を受ける4. 提案評価             : 事前に決めた基準と重みで採点する。金額のみで決めない5. ベンダー選定と契約   : 工程の性質に応じて請負か準委任かを選ぶ（多段階契約） /* 工程と契約形態の対応の目安 */要件定義       -> 準委任（要件が未確定なので完成の定義ができない）外部設計       -> 準委任または請負（成果物を特定できるかで判断）内部設計から製造, 結合テスト -> 請負（成果物が特定でき、完成を判定できる）システムテスト, 受入支援     -> 準委任（利用者の主体的な関与が前提）

用語

システム化構想の立案

経営上の課題から、システム化の対象業務・目的・期待効果・全体像を描く段階。何のために作るのかを定める、企画の入口。

システム化計画の立案

対象範囲・開発方式・体制・概算費用・スケジュール・投資対効果・リスクを具体化し、投資の可否を経営が判断できる材料にする段階。

非機能要件

性能、可用性、拡張性、運用保守性、移行性、セキュリティ、システム環境など、機能以外の品質と制約に関する要求。曖昧なまま契約すると後の紛争の種になる。

非機能要求グレード

非機能要件の合意を助けるためにIPAが示す枠組み。6つの観点ごとに水準を段階で提示し、発注側と受注側が同じ物差しで選べるようにする。

RFI

情報提供依頼書。市場にどんな製品や技術があり、どの事業者が対応できるかという情報を集める段階の文書。提案そのものはまだ求めない。

RFP

提案依頼書。背景と目的、要件、前提と制約、提案範囲、契約条件、評価基準とスケジュールを示して正式に提案を求める文書。

提案評価

あらかじめ定めた基準と重み付けに従って提案書を採点する作業。金額だけでなく実現性・体制・実績・保守条件を含めた総合評価にするのが通例。

請負

仕事の完成を約束し、その結果に対して報酬を支払う契約。完成義務と契約不適合責任を負う。根拠は民法 第632条。

準委任

法律行為でない事務の委託。委任の規定が準用される。受任者は善管注意義務を負うが、成果物の完成義務は原則として負わない。根拠は民法 第656条。

善管注意義務

善良な管理者の注意をもって委任事務を処理する義務。準委任における受任者の中心的な義務で、根拠は民法 第644条。

成果完成型の準委任

委任事務の履行により得られる成果に対して報酬を支払うと約した型。民法 第648条の2に定めがあり、準委任でも成果に報酬を結び付けられる。

多段階契約

工程ごとに契約を分け、工程の性質に合った契約形態を選ぶ考え方。要件が固まっていない工程は準委任、成果物を特定できる工程は請負とするのが基本。

情報システム・モデル取引・契約書

IPAが公開する、発注側と受注側の中立を目指したモデル契約書。多段階契約、民法改正への対応、プロジェクトマネジメント義務と協力義務などを整理している。

偽装請負

契約の名目は請負や準委任でありながら、発注者が委託先の要員へ直接指揮命令を行い、実態が労働者派遣になっている状態。

例題

出典・根拠：IPA「応用情報技術者試験（レベル3）」シラバス Ver.7.2 大分類7：システム戦略　中分類18：システム企画

4. IT投資の評価とデジタル技術の活用

投資回収期間・ROI・NPV・TCOで投資の善し悪しを判断し、IoTやAI、データ利活用の使いどころを見極められるようになります。

IT投資は「効果がありそうだから」では通りません。金額に換算した効果と費用を並べて、投資に値するかを説明できる形にします。最も単純なのが投資回収期間法（ペイバック法）で、初期投資を毎年の効果額で回収し終えるまでの年数を求めます。分かりやすく、短いほどリスクが小さいと言えるのが利点ですが、回収後に生じる効果を一切考えないという弱点があります。回収に3年かかるが10年効果が続く案と、2年で回収するが3年で終わる案では、回収期間だけを見ると後者が勝ってしまいます。次にROI（投資利益率）で、投資額に対して得られた利益の割合を示します。ここで注意したいのは、分子が「効果額」ではなく「利益」だという点です。年間の効果額から、その効果を得るためにかかる運用費を差し引いた額を使います。運用費を引き忘れると、実力より良い数字が出ます。

お金の時間価値を考慮するのがNPV（正味現在価値）です。1年後の100万円は、いま手元にある100万円より価値が低いという前提に立ち、将来の効果額を割引率で割り引いて現在価値に直します。n年後の金額の現在価値は、その金額を（1 + 割引率）のn乗で割った値です。すべての年の現在価値を合計し、そこから初期投資を引いた値がNPVで、正なら投資に値すると判断します。割引率を高く設定するほど将来の効果は小さく評価されるので、リスクの高い案件には高い割引率を当てるという使い方をします。NPVがちょうど0になる割引率をIRR（内部収益率）といい、これが資本コストを上回るかどうかで判断する方法もあります。回収期間法とNPVを比べると、回収期間法は時間価値も回収後の効果も無視するのに対し、NPVは両方を織り込むぶん、判断の根拠としては強くなります。

費用の側を漏れなく数えるための考え方がTCO（総所有コスト）です。導入時にかかるイニシャルコスト（機器、ソフトウェアライセンス、構築費、移行費、教育費）だけでなく、稼働後に毎年かかるランニングコスト（保守費、通信費、電力、運用要員の人件費、更改費用）まで含めた総額で比べます。導入費が安い案が、運用費まで含めると高くつくというのはよくある話で、クラウドとオンプレミスの比較はまさにこれにあたります。初期投資が大きく年間費用が小さい案と、初期投資がなく年間費用が大きい案は、どこかの年で総額が並びます。何年使うつもりかを決めなければ、どちらが安いかは決まりません。IT投資を性質で分類して配分を考える見方もあり、業務の効率化を狙うもの、情報活用を狙うもの、事業の変革を狙うもの、共通基盤を整えるものでは、期待する効果の測り方もリスクの大きさも異なります。

近年の投資判断の中心にあるのがデジタル技術の活用です。IoTは、機器やセンサをネットワークにつなぎ、現場の状態を継続的に取得して活用する仕組みです。振動や温度の変化から故障の兆しを捉えて壊れる前に手を打つ予兆保全、現実の設備を仮想空間に写し取って挙動を試すデジタルツインなどが代表的な使い方になります。大量の機器を安く長期間つなぐため、低速だが低消費電力で遠くまで届くLPWAのような通信方式が使われます。すべてのデータをクラウドへ送ると通信量と遅延が問題になるので、現場側の機器で一次処理を行うエッジコンピューティングと組み合わせるのが定石です。IoTで押さえるべき判断は「何を測れば意思決定が変わるか」であり、測れるからという理由でデータを集めても、使い道がなければ通信費と保管費だけが積み上がります。

AIの使いどころも、万能の道具としてではなく、向き不向きで考えます。機械学習は、正解付きのデータから規則を学ぶ教師あり学習、正解なしでデータの構造を見つける教師なし学習、試行錯誤の結果に報酬を与えて方策を学ぶ強化学習に大別されます。需要予測や与信判定のように過去データと結果の対応が大量にある領域、画像や音声のように人手では処理量が追いつかない領域は向いています。反対に、判断の根拠を明示する必要がある領域、正解データが揃わない領域、めったに起きない事象の予測は苦手です。実務上の要点は三つあります。学習データの偏りがそのまま出力の偏りになること、なぜその結論になったかを説明しにくい場合があること（説明可能性の問題）、そして生成AIでは事実と異なる内容をもっともらしく出力することがあることです。したがってAIの出力を最終決定にするのではなく、人が確認して責任を負う設計にするのが基本になります。

データを使えるようにする土台の整備も投資の対象です。分析用に整理して蓄積した基盤がデータウェアハウス、加工前の生データを形式を問わずそのまま溜める場所がデータレイクです。前者は用途を決めて構造化してから入れるのに対し、後者はとりあえず溜めて後から使い道を決められる、という違いがあります。用途別に切り出した小規模なものがデータマート、大量データから規則性や関連を見つけ出す手法がデータマイニング、集計と可視化で意思決定を支援する仕組みがBIツールです。組織横断でデータの定義や品質、権限を管理する取組みをデータガバナンスといい、これがないと同じ「売上」という語が部門ごとに違う意味で使われ、分析結果が食い違います。行政や企業が二次利用できる形で公開するデータがオープンデータで、自社データと組み合わせることで新しい示唆が得られます。データ利活用への投資は効果が読みにくいので、まず問いを立て、その問いに答えるために必要なデータだけを対象に小さく試す、という進め方が現実的です。

/* 正味現在価値（NPV）の計算 */○実数型: npv(実数型: 初期投資, 実数型の配列: 効果額, 実数型: 割引率)  実数型: 合計 ← 0  for (n を 1 から 効果額の要素数 まで 1 ずつ増やす)    合計 ← 合計 + 効果額[n] / (1 + 割引率)ⁿ  endfor  return 合計 - 初期投資 /* 投資回収期間（毎年の効果額が一定でない場合） */○実数型: payback(実数型: 初期投資, 実数型の配列: 効果額)  実数型: 累計 ← 0  for (n を 1 から 効果額の要素数 まで 1 ずつ増やす)    if (累計 + 効果額[n] ≧ 初期投資)      return (n - 1) + (初期投資 - 累計) / 効果額[n]    endif    累計 ← 累計 + 効果額[n]  endfor  return -1  /* 期間内に回収できない */

用語

投資回収期間法

初期投資を毎年の効果額で回収し終えるまでの年数で評価する方法。分かりやすいが、回収後に続く効果とお金の時間価値を考慮しない。

ROI

投資利益率。投資額に対する利益の割合。分子は効果額そのものではなく、効果額から運用費などを差し引いた利益である点に注意する。

NPV

正味現在価値。将来の効果額を割引率で現在価値に直して合計し、初期投資を引いた値。正なら投資に値すると判断する。

割引率

将来の金額を現在価値に直すときに用いる率。n年後の金額は（1 + 割引率）のn乗で割る。リスクが高い案件ほど高い率を当てる。

IRR

内部収益率。NPVがちょうど0になる割引率。これが資本コストを上回るかどうかで投資の可否を判断する方法がある。

TCO

総所有コスト。導入時のイニシャルコストと、稼働後のランニングコストを合わせた総額。何年使うかを決めないと案の比較ができない。

予兆保全

センサで得た振動や温度などの変化から故障の兆しを捉え、壊れる前に手を打つ保全方式。停止による損失と保全費用の両方を下げられる。

デジタルツイン

現実の設備や工程を仮想空間に写し取り、実物を動かさずに挙動や変更の影響を試せるようにする仕組み。

LPWA

低消費電力で広い範囲をカバーする無線通信方式の総称。通信速度は低いが、多数のセンサを長期間つなぐIoT用途に向く。

エッジコンピューティング

現場に近い機器側でデータの一次処理を行う方式。クラウドへ送る通信量と応答遅延を抑えられ、IoTと組み合わせて使われる。

教師あり学習と教師なし学習

前者は正解付きのデータから入力と出力の対応規則を学ぶ方式、後者は正解なしでデータの構造や集まりを見つける方式。強化学習は報酬を手掛かりに方策を学ぶ。

説明可能性

AIがなぜその結論を出したのかを人が理解できる度合い。与信や採用のように理由の提示が求められる領域では、精度だけでなくこの性質が要件になる。

データウェアハウスとデータレイク

前者は用途を決めて構造化したうえで蓄積する分析基盤、後者は生データを形式を問わずそのまま溜める置き場。後から使い道を決められるのが後者の利点。

データガバナンス

組織横断でデータの定義・品質・権限を管理する取組み。これがないと同じ語が部門ごとに違う意味で使われ、分析結果が食い違う。

例題

出典・根拠：IPA「応用情報技術者試験（レベル3）」シラバス Ver.7.2 大分類7：システム戦略　中分類18：システム企画

演習：この章の問題を解く

ランダム出題の演習ツールです（JavaScript が有効な場合に動きます）。上の「確認問題」はそのままでもすべて読めます。