システムアーキテクト用語集

Last-modified: 2015-10-16 (金) 12:44:09

システムアーキテクトは、IPA試験において、次のような人物が想定されている。

高度IT人材として確立した専門分野をもち、ITストラテジストによる提案を受けて、

情報システム又は組込みシステムの開発に必要となる要件を定義し、

それを実現するためのアーキテクチャを設計し、情報システムについては開発を主導する者

もう少し平たく言えば、ITストラテジストが建てた戦略や、顧客から相談を受けて、情報システムや組込みシステムの要件を考え、顧客自身も気づいていない要件を詰めて、システムをソフトウェア、ハードウェア、手作業も含めて設計する人。
実際の開発は、現場監督であるプロジェクトマネージャーや、各種スペシャリスト、プログラマーと協力して開発を進める。

A

AA, Application Architecture, アプリケーションアーキテクチャ, 適用処理体系
EA(=Enterprise Architecture) において、データ処理と業務の関係を定義するモデル。
AC, Autonomic Computing, 自律コンピューティング, 自律型コンピューティング
コンピュータが自ら考え問題を解決するもの。
As-Is, 現状有姿
現在の姿を現す言葉。どちらかといえば契約書用語。システムアーキテクトにおいては、要件定義の際に、現在の状態を分析するというような場合に「As-Isがどうの～」と言うかもしれない。

B

BA, Business Architecture, ビジネスアーキテクチャ, 業務体系
EA(=Enterprise Architecture) において、業務目標の設計や業務機能構成を定義するモデル。
BCP, Business Continuity Plan, 事業継続計画
企業のビジネスを継続させるための計画。たとえば、自然災害発生時の行動指針や、なるべく早期に復旧するための備えなどのこと。
BI, Business Intelligence
業務情報を上手く活用する方法の総称。データマイニング、OLAP、ETLなどが代表的。
BPMN, Business Process Modeling Notation,業務プロセスモデリング記法
業務プロセスをグラフィカルに表すための記法。
BPO, Business Process Outsourcing
自社の一部の業務を完全に外部に委託すること。たとえばソフトウェアテストや経理、ウェブシステム全般など。
BPR, Business Process Re-engineering
BRM, Business Reference Model
エンタープライズアーキテクチャの参照モデルの１つ。組織全体でシステムの共通化の対象領域を洗い出すためのモデル。
Bottom-up approach, ボトムアップアプローチ
要求分析の手法のひとつ。

C

Capacity Planning, キャパシティプランニング
に要件を満たす性能を予測し、システム設計すること。具体的にはネットワーク帯域、利用者数、CPU負荷、メモリ使用量など多岐にわたる。
CMMI, Capability Maturity Model Integration, 能力成熟度モデル統合
組織やチームの成熟度を表すための指標。最後の「Integration＝統合」が意味しているのは、元々別々のCMM（SA-CMM, SE-CMM, SW-CMM, IPD-CMMなど)を「統合したところから来ている。５段階のレベルがある。Initial, Repeatable, Defined, Managed, Optimizingである。
CPFR, Collaborative Planning Forecasting Replenishment, 協調・計画・予測・補充
CRM, Consumer Relationship Management, 顧客連携管理
CSF, Critical Success Factor, 主要成功要因
KPIと似ているが、KPIを達成するための手段のことをさす。
CTI, Computer Telephony Integration, コンピューター電話統合
CX, Customer eXperience, 顧客体感価値

D

DA, Data Architecture, データ体系
EA(=Enterprise Architecture) において、データとデータ間の関係を定義するモデル。
DOA, Data Oriented Approach, データ中心アプローチ, データ指向アプローチ
データ構造やデータフローに着目してシステム設計を行う手法。データに重きを置いて、そこに関わるプロセスを設計していく。こうすることで、データの重複がなく、更新プロセスの重複もなくなる。逆にプロセスを中心に行うのは、POA。

E

EA, Enterprise Architecture
主に日本政府が定めた情報システム開発を効率よく合理的に構築できる手法。システムアーキテクト試験が国家試験である限り、このEAが問われ続けるので要重点項目。政府が作成したとはいえ、全然ダメなことを言っているわけではない。むしろ覚えておくべき。
ECR, Efficient Consumer Response
ED, External Design, 外部設計
要件定義に基づいて、システム機能設計、コード設計、論理設計、画面帳票設計、外部インタフェースなどを設計すること。
E-R Model
ERP, Enterprise Resource Planning
ETL, Extract Transform Load
データの抽出し（Extract）、変換し（Transform）、乗せる（Load）から来ている。データウェアハウスからデータを取り出し、データベースに書き込むこと。BIのひとつ。

F

Fail Safe, フェールセーフ、フェイルセーフ
故障や不具合発生時に、できる限り使用者の不利益に繋がらない設計とすること。
Fail Soft, フェールソフト、フェイルソフト
故障や不具合発生時に、その発生部を切り離して、残りの部分でできる限り処理を続行する設計とすること。
Fault Avoidance, フォールトアボイダンス
できる限り、故障や不具合を回避するよう設計すること。
Fault Masking, フォールトマスキング
故障や不具合が発生しても、それが外部に影響しないようにすること。
Fault Tolerance, フォールトトレランス
故障や不具合が発生しても、それを許容し、被害を最小限に保ちつつ、正常な動作を続行すること。
Forward engineering, フォワードエンジニアリング
非機能要件であるシステム開発上の要件「開発方式」の１つ。
Functional Requirement/Non-Functional Requirement, 機能要件/非機能要件
機能要件はユーザーの主目的であり、ユーザー自身も意識している要求のこと。「～～したい」という要求から来るもの。非機能要件は、ユーザーの主目的ではなく、ユーザー自身が意識していない要求で、例えば操作性や性能、処理時間、セキュリティ、内部統制、システム移行の手順など、システムアーキテクトが見つけて上手く聞き出すべきもの。

G

H

HIPO model, Hierarchy plus Input-Process-Output model
システムの図式化方式の１つ。階層的に「入力-処理-出力」を図式化する。階層化していないものを「IPO model」と呼ぶ。

I

ID, Internal Design, 内部設計
ED（外部設計）とSA（システム方式設計）に基づき、システム実装環境の具体か、コンポーネント設計、データベースの物理設計、モジュール設計などを行うこと。
Inspection, インスペクション
非機能要件であるシステム開発上の要件「品質レビュー」の１つ。
IPO model, Input-Process-Output model
「入力-処理-出力」を図式化したもの。「入力するデータ群→処理内容→出力するデータ群」のように記述する。
ISMS, Information Security Management System, 情報セキュリティマネジメントシステム
ITIL, Information Technology Infrastructure Library
ITの利用に関わる「上手く行くためのコツ」をまとめたもの。主には、３つのP、People、Process、Productが大事とされている。そしてプロセスを分類した、「インシデント管理」「問題管理」「変更管理」「リリース管理」「構成管理」などを定義している。
I.T. governance, ITガバナンス
企業におけるITの利用を継続的に最適化するための仕組み。

J

Japan Common Frame, 共通フレーム, ソフトウェアを中心としたシステムの取引に関する共通フレーム
システム開発に祭し、発注側と受注側の意識がずれないようにするためのガイドライン。特にISO/IEC 12207を基にした共通フレーム2007が有名。

K

KPI, Key Performance Indicators, 重要業績評価指標
業績の価値を表した指標のこと。これを設定し、その達成度合いによって評価する。また達成するための手段としてCSF（主要性高要因）の達成が必要となる。

L

M

MDX, Multi Dimensional Expression

N

NPV, Net Present Value, 正味現在価値
投資評価法の１つ。次の式で求める。「【NPV】＝【将来発生するキャッシュフローの現在価値の合計】－【初期投資額】＋【残存価額の現在価値】」。t年後のキャッシュフローを「F(t)」とすると、t年後のキャッシュフローの現在価値は、「F(t) / (1 + r)^t」となる。ここで「r」は「割引率（discount rate）」。「現在価値」とは将来の貨幣価値を現在の貨幣価値で表したもの。「割引率」とは将来の貨幣価値が現在の価値から比べて、どう変わっているかを表す数値。たいてい1.05などが使われる。

O

OLA, Operational Level Agreement, 運用レベル契約
クライアントに対するITサービスのサポートおよびデリバリに関する責任範囲や障害発生時の活動、措置を定義する。サービス事業者と社内部門との間で交わす契約。
OLAP, On-Line Analytical Processing
:BIの１つで、多次元データを素早く解析する。
Object-oriented approach, オブジェクト指向分析
要求分析の手法のひとつ。

P

PBP法, Pay Back Period Method, 回収期間法
投資評価法の１つ。投資した金額を最も早く回収できるものに投資するという方法。
PMBOK, Project Management Body of Knowledge, プロジェクトマネジメント知識体系ガイド
ソフトウェアに限らずプロジェクトマネジメントに関する知識（ベストプラクティスなど）をまとめたもの。
Petri Net Model, ペトリネットモデル
分散システムの図法。状態遷移＆クラス図といった感じで、オブジェクト同士の関係（入出力と個数と方向）を表す。
POA, Process Oriented Approach, プロセス中心アプローチ, プロセス指向アプローチ
プロセスに着目してシステム設計を行う手法。プロセスに重きを置いて、そこに関わるデータを設計していく。プロセスを中心にしてしまうと、部署をまたぐシステムを開発すると、必ずのように、データの重複、プロセスの微妙な差異からくる微妙な重複などが起こり、システムが無駄に膨れ上がってしまう。逆にデータを中心に行うのは、POA。

Q

QFD, Quality Function Deployment, 品質機能展開
Queueing Theory, 待ち行列理論
システムのタスクが確率的に発生する場合に、その発生確率や処理時間などから、タスクが平均的にどのくらいの時間で終わるかを理論立てたもの。レジを例にとるとわかりやすい。たとえば、１時間あたりにレジに並ぶ人の人数を60人としたとき、「平均到着数λ」は「λ＝60 [1時間あたり到着人数]」、「λ＝1 [1分当たり到着人数]」となる。レジでは、平均的に１人あたり30秒かかるとしたとき「平均サービス時間T」は、「T＝30 [秒]」、「T＝0.5 [分]」となる。さらにその逆数は、1分あたりに何人処理できるかとなるので「平均サービス数μ」は、「μ＝2 [1分当たり処理人数]」となる。ここで、レジがどれくらい混んでいるかを考えると「平均利用率ρ」は、「ρ＝λ／μ」＝「平均到着数／平均サービス数」で求められる（処理能力が高ければ、平均サービス数が大きくなり、利用率が低下する。一方、到着数が処理能力を上回ると、列に並ぶ人数が増え続けることになる）。ということで、「ρ＝１／２」で「0.5」となる。つまり、平均的な混雑度合いは0.5となる。1の場合はいつも利用されていてレジの人は休む暇なしで、0の場合は全く混雑していない。そして、【平均待ち数Ｌ】は「Ｌ＝ρ／（１－ρ）」となる。ここから【平均待ち時間Ｗ】は「Ｗ＝Ｌ／λ」で表すことができる。

R

RD, Requirements Definition, 要件定義
これから開発するシステムについて、そこでやりたいことをまとめること。なるべく抜けなく、漏れなく、具体的に定義して、後で問題が起こらないようにする必要がある。
Reverse engineering, フォワードエンジニアリング
非機能要件であるシステム開発上の要件「開発方式」の１つ。
Review meeting, レビューミーティング
非機能要件であるシステム開発上の要件「品質レビュー」の１つ。
RFC, Request For Change, 変更要求
プログラムやサービスに対してユーザーから開発者や管理者に送られる要求のこと。
RFI, Request For Information, 情報提供要求
RFP, Request For Proposal, 提案要求
これから開発してほしいシステムにおいて、やりたいことをまとめた文書。RFPをもとに、システム要件をベンダーが定義する。当然ながらRFPを出す側は開発に関しては素人なので、ベンダー側が多くを考慮する必要がある。とはいえ、完全に任せるわけにもいかないので、次の６項目をRFPに含めることが産業構造審議会によって推奨されている。(1) システムの概要、(2) 依頼事項、(3) 指示事項、(4) 開発体制と開発環境、(5) 保証要件、(6) 契約事項。
Round-Robin, ラウンドロビン
非機能要件であるシステム開発上の要件「品質レビュー」の１つ。
RTO, Recovery Time Objective, 目標復旧時間
BCP（事業継続計画）に盛り込む具体的な項目の１つ。「目標とする復旧時間」のことで、災害等から復旧するまでの時間の目標値。定め方は事業の種類によってさまざまではあるが、この目標値をたとえば１か月とすれば、その１か月間で事業を再開でき、大きな痛手もないということになる。

S

SA, System Architect Design, システム方式設計
要件定義の非機能要件に基づき、処理方式、操作性、性能、処理能力、拡張性、信頼性、システム構成、セキュリティ、内部統制、データ管理、システム開発、移行、運用管理、システム保守などを設計すること。
SCM, Supply Chain Management
SLA, Service Level Agreement
ユーザーとベンダー（サービス事業者）が交わすサービス水準に関する契約。
SLCP, Software LifeCycle Process
SSM, Soft Systems Methdology, ソフトシステムズ方法論
問題を「やわらかに」解決していく方法。様々な人々の異なった意見を七つのステージを経て合意形成を行う。特に問題や答えが明確でない問題について役立つ。
Stakeholder, ステークホルダー, 利害関係者
システムアーキテクトにとっては、要件を整理する際にお伺いを立てるべき人々のこと。直接のユーザーはもちろん、ユーザー側の上司、部下、管理部門、ベンダー側としても水平展開したいという思惑を持つITストラテジストなど、様々な利害関係者がいる。

T

TA, Technical Architecture, 技術体系
EA(=Enterprise Architecture) において、ITインフラの構成など技術的な要素を定義するモデル。
To-Be, あるべき姿
こうなるべきだという姿。理想形。システムが本来「こうなっていれば上手くいく」という場面で使う。「As-Is」との対比。
Top-down approach, トップダウンアプローチ
要求分析の手法のひとつ。

U

UC, Underpinning Contract, 基盤契約
通信事業者など、外部サービスプロバイダと締結する契約。サービス事業者が外部サービスプロバイダーやサプライヤーと結ぶ契約。
UML

V

W

Walkthrough, ウォークスルー
非機能要件であるシステム開発上の要件「品質レビュー」の１つ。
WFA, Work Flow Architecture, 業務流れ図

X

XBRL, Xtensible Business Reporting Language, 拡張可能な事業報告言語
財務情報の電子データ用言語。

Y

Z

Zachman framework, ザックマンフレームワーク
EA（Enterprise Architecture）作成時に元になったもの。

あ

か

業務処理統制
特定業務に関する内部統制。全般統制に比べ、具体的な内容になる。例えば「人事システムの機能ごとに利用者を限定するアクセス管理」など。次の５つに分類できる。(a) 入力統制：データの網羅性、正確性の確保、改竄の検知。(b) 処理統制：制約に対する誤謬摘示、修正回復。(c) 出力統制：処理統制＋出力結果の保護。(d) マスターデータ統制：変更に対する手続承認、認可。(e) アクセス統制：不正アクセス防止。これらを表形式にして「リスクコントロールマトリックス」とする。
工事完成基準
システムの完成してから売上と原価が計上される方式。
工事進行基準
売上と原価を工事の進捗度に応じて分散して計上する方式。2009年度以降、受託ソフトウェア開発事業で原則として工事進行基準を適用する義務がある。

さ

システム管理基準
システム適格性確認テスト
システム要件にあっているかどうかを確認する。
システム要件
開発するシステムの、目標、対象範囲、利害関係者、機能要件、非機能要件などを定義したもの。
全般統制
複数の業務処理統制に関係する方針や手続きなど、業務処理統制が有効に機能し続けるための統制活動。例えば「ITシステムの開発、保守規定」や「外部委託に関する契約」。

た

超上流工程
ビジネス企画のこと。システム開発としてとらえていた部分よりも前にあるので。

な

内部統制
新会社法やJ-SOX（日本版SOX法）によって義務付けられていること。会社が不正を働かないようにするため、あるいは社員が不正を働かないようにするため、あるいは会社が存続し、社会に貢献し続けるために、業務が適正に行われているかを確認すること。ITシステムについても、対応が求められる。

は

ま

や

ら

わ