マネジメント

SLCP（Software Life Cycle Process）

ソフトウェア開発の構想から廃棄までの流れを標準化した枠組みです。
利用者（顧客）と開発者（ベンダ）の間で受け取りの違いが生じないように、国際規格の標準が定められています。

TCO (Total Cost of Ownership)

ハードウェアやソフトウェアの購入から、開発費、運用、破棄 まで含んだ、システム構築に掛かる総所有コスト(総コスト) を言います。
TCOは 見えるコスト と 見えないコスト を意識して考える必要があります。

ROI (Return of Investment)

費用対効果を示す指標で、投資利益率 と言います。（利益 ÷ 投資額 × 100%）
事業規模に関わらず、利益ベースでの採算性が確認できるので、システム構築の開発計画を立てる際の重要な指標となります。

業務要件定義

業務上実現すべき要件を定義します。
（利用者から聞き出した業務の手順や、入力情報、ルール、制約 など）

機能要件定義

業務要件を実現するために必要なシステムの機能を定義します。
（必ず搭載すべき機能、達成する基本部分）

非機能要件定義

起案者が考える機能要件以外の副次的な機能を定義します。
（性能、信頼性、セキュリティなど）

RFI（Request For Information）

ベンダ企業に対して、システム化の目的や業務要件を明示し、情報提供を依頼することです。

RFP（Request For Proposal）

ベンダ企業に対して、導入システムの基本方針や提案依頼事項、調達条件を明示し、提案書の提出を依頼するための文書です。

NDA（Non Disclosure Agreement）

他社に委託する際、お互いに知りえた相手方の情報を漏らさないようにする秘密保持契約書です。
契約書ですが、課税文書には該当しませんので、収入印紙の貼付は不要です。

UI（User Interface）

利用者とコンピュータの接する部分をユーザインターフェース と言います。

CUI	Charactor：キーボード入力
GUI	Graphical：マウス選択
VUI	Voice：声

UX（User eXperience）

利用者が、楽しく快適な体験ができることをユーザエクスペリエンスと言います。
UIでは視認性や操作性を重視しますが、UXでは体験に範囲を広げます。

ホワイトボックステスト

内部構造に注目（理解） して、開発者がプログラムの部品であるモジュールの単体テストを実施します。
内部構造の条件に合う複数のデータを使って、条件通り動くかテストします。

ブラックボックステスト

内部構造に考慮せずに、開発者以外がプログラムの部品であるモジュールの単体テストを実施します。
ランダムなデータを入力して結果を出力し、結果が仕様書通りか確認します。

結合テスト

単体テストが完了したモジュール ¹ を結合して、開発者がテストを行います。
特に モジュール間 でやり取りする命令や、データの受け渡しが仕様書通りに正しく実行されているかを確認します。

システムテスト

実際に業務で使うデータや、業務で発生が予想される例外データを使い、開発者が主体でテストしますが、利用者も協力してテストを行います。

• 機能テスト：システム要件に定められている機能が全て含まれているか
• 性能テスト：要求される処理能力や応答時間を満たしているか
• 例外処理テスト：間違ったデータを入力したときエラーとして認識されるか
• 負荷テスト：量的な負荷をかけてシステムが業務に耐えられるか
• 操作性テスト：操作性の良さや表示されるメッセージが分かりやすいか

レグレションテスト

修正や変更が、他の正常な機能に影響ないか、確認するためのテストです。

デグレード（de grade）

変更したソフトウェアの品質が、以前より悪くなることです。
以前修正した不具合やバグが再発・復活することは、デグレードバグと言います。

ウォータフォールモデル（Water fall model）

滝が上から下に流れるように、開発工程を進めていく技法です。
（要件定義 → システム設計 → プログラミング → テスト）

プロトタイピングモデル（Prototyping model）

開発初期に 試作品 （プロトタイプ） を作成して確認を得てから進める技法です。
（要件定義 → プロトタイプ作成 → 確認 → 修正 → 設計 → 開発 → テスト）

スパイラルモデル（Spiral Model）

システムを複数のサブシステムに分けて、順番に開発を進めていく技法です。
（①設計 → ①開発 → ①テスト → ②設計 → ②開発 → ②テスト）

RAD（Rapid Application Development）

ユーザーを含む少人数で仕様分析、設計、開発を進め、繰り返し試作品を作成して評価・改良することで完成品に近づけていく技法です。

アジャイル開発（Agile software development）

現在主流になりつつある開発技法で、システムを複数のサブシステムに分けて、完成後直ぐにリリースします。
（計画 → 設計 → 開発 → テスト → リリース）

スクラム（Scrum）

アジャイル開発の１種で、開発チームの作業とプロダクトに責任を持つプロダクトオーナーと、プロジェクトを円滑に進めることに責任をもつスクラムマスターが、3～9人程度のメンバーを率いて開発します。

エクストリーム・プログラミング（XP：Extreme Programming）

アジャイル開発の１種で、プログラマー中心の開発技法で、4つの価値（コミュニケーション／シンプル／フィードバック／勇気）をチーム内で共有することが特徴です。

ユーザー機能駆動開発（FDD：Feature Driven Development）

アジャイル開発の１種で、ユーザー目線で価値のある機能 を中心に開発を進める開発技法です。
開発する機能によってチームを分けて計画・設計しコーディングを行うので、アジャイル開発の中でも大規模な案件に対応しやすいのが特徴です。

DevOps（Development Operations）

開発 (Development) と 運用 (Operations) に分かれていたものを一つにして、連携してシステム開発と改善を進めようという考え方です。

リバースエンジニアリング（Reverse engineering）

通常のシステム開発では、設計書に従って、プログラムを作成しますが、レガシーシステム（歴史あるシステム）では、仕様書が無い、改修内容が仕様書に反映されていない ケースがあります。
リバースエンジニアでは、既存のプログラムを解析して仕様書を作成します。（逆に戻すという意味です。）

プロジェクト（Project）

プロジェクトとは、特定の課題のもと、各部門から専門家を集めて編成し、決められた期間と予算で、目標を定めて活動する集団のことです。

プロジェクトマネージャ（PM）	プロジェクトを管理・統括する責任者
プロジェクトリーダ（PL）	PMを補佐し、プロジェクトメンバを束ね、実行・推進する人
プロジェクトメンバー	プロジェクトを実行する構成員
ステークホルダ（ベンダー）	プロジェクトの利害関係者（顧客・株主・地域など）

ファンクションポイント法（FP法）

帳票数、画面数、ファイル数などから、ソフトウェアの機能を定量的に把握し、それに基づいて、ソフトウェアの開発工程や開発費用を見積もる手法です。
利用者から見える部分を単位として見積もるので、利用者にとって分かりやすい特徴があります。

プログラムステップ法（LOC：Line of Code）

開発するプログラムのステップ数を基に、開発規模を見積もる手法です。
開発者の能力によってステップ数が変わるので、見積り差異が発生しやすい特徴があります。

COCOMO法（Constructive Cost Model）

予想されるプログラム行数に、開発者の能力や要求の信頼性などの補正係数を掛け合わせて、開発工数や期間、要員や生産性を見積もる手法です。
担当する開発者の単価により、見積り金額に幅が発生しやすい特徴があります。

類推見積り法

過去に経験したシステムと類似している場合、過去の実績値を基に開発工数を見積もる手法です。

サービスマネジメント

利用者の要求事項を満たすために、運営管理されたサービスを、効果的に提供する仕組みのことです。
利用者から見えるところでは、ヘルプデスク (サービスデスク) があります。
問い合わせ対応だけでなく、障害発生時の復旧や、問題の抜本解決、サービスを提供するための資産管理も行います。

ITIL (Information Technology Infrastructure Library)

1980年代に英国で始まったITサービスマネジメントにおける 成功事例 (ベストプラクティス) をまとめたガイドラインです。

SLA (Service Level Agreement)

ITサービスの品質に関する利用者との合意のことを言います。
SLAでは、サービス提供時間帯、問い合わせ時間、保証する稼働率、障害時の復旧時間 などを定義して、利用者と合意します。

ファシリティマネジメント

データセンタなどの IT関連施設や設備 について、経営者の視点から、適切に使われているか、改善監視することです。
施設管理とも呼ばれ、コスト削減や快適性、安全性、機密性の確保など、施設全体の管理を目的としています。

システム監査

監査対象とは関わりを持たない第三者が、客観的 に情報システムの安全性や信頼性 などを、点検、評価することです。
企業内の監査部門が行う内部監査と、第三機関に依頼して行う外部監査があります。
経済産業省が公表した システム監査基準 では、システム監査業務の品質を確保し、有効且つ効率的に監査を実施するための行為規範をまとめています。

情報セキュリティ監査

情報セキュリティに関わるリスクのマネジメントが、リスクマネジメントに基づき、適切にコントロールが整備され、運用されているか 評価します。

内部統制

企業の事業目的や経営目標に対し、それを達成するために必要なルール、仕組みを整備し、適切に運用することです。
上場企業では、金融商品取引法(J-SOX法) により、決算時、財務諸表と共に内部統制報告書 と 内部統制監査報告書 を提示し、公開しなければなりません。
（金融庁の所管：財務諸表の信頼性の確保、事業活動に関わる法令等の遵守）

モニタリング

内部統制が有効に機能していることを、継続的に監視、評価することです。
会社法と金融商品取引法では、内部統制の整備が求められています。

職務分掌

業務における不正や誤りが発生するリスクを減らすために、仕事の役割分担や、仕事の権限を明確にすることです。
担当者間で相互けん制が働くように設定します。

IT統制

ITを利用した情報システムに関するリスクを低減させるための内部統制です。
業務が正確に処理される統制（業務処理統制）と 業務全体の統制（全般統制）があります。

コンプライアンス（Compliance：法令遵守）

法律を遵守してルールを守った企業活動を行うことです。
近年は、法律を守るだけでなく、社会通念や倫理、道徳も含みます。

コーポレートガバナンス（Corporate Governance：企業統治）

会社は経営者のものではなく、資本を投下している株主のもの という考え方のもと、企業経営を監視する仕組みのことです。

ITガバナンス（I.T. governance：IT統治）

コーポレートガバナンスの要素の１つで、企業などが経営方針に則ってIT戦略を策定し、情報システムの導入や運用を組織的に管理・統制する仕組みのことです。

レピュテーションリスク（Reputational risk）

企業などの評判やブランドイメージが低下することで様々な悪影響をもたらすリスクのことです。
（評判リスク・風評リスク）