マネジメント系 用語一覧

アプリケーションの内部にエージェントを常駐させ、実行時の動作を監視して[[TEC_910]]を検出する手法。SASTとDASTの利点を組み合わせた技術。

品質[[STR_751]]（QMS）に関する国際標準規格。製品やサービスの品質を継続的に改善し、顧客満足を高めるための指針。

情報セキュリティマネジメントシステム（ISMS）の構築・運用に関する国際標準規格。情報の[[TEC_852]]、[[TEC_786]]、可用性を維持するための指

ITインフラ（サーバー、ネットワーク等）の構成を、手動操作ではなく「プログラムコード」として記述し、自動で構築・管理する手法。

ID（ユーザー認証）の管理機能をクラウド経由で提供するサービス。シングルサインオン（SSO）や[[TEC_671_b]]などを一元管理する。

ビジネスの要望に応じたITサービスを安定的に提供し、その品質を維持・向上させるための管理活動。

システムの基盤を守る「全般統制」と、個別の業務処理の正しさを守る「業務処理統制」。

短い期間での反復開発を繰り返し、柔軟に仕様変更に対応する開発モデルです。

現状を客観的に評価・分析し、影響や有効性を判断することです。

作業の順序関係を矢印と丸印で表し、工期を管理するネットワーク図。

ITサービスの構成要素に対して、変更を正式に依頼するための文書や手続き。[[MNG_134]]プロセスの起点となるもの。

災害やシステム障害が発生してから、サービスを「いつまでに」復旧させるかという目標時間。目標復旧時間。

災害やシステム障害が発生した際、失われたデータを「過去のどの時点」まで遡って復旧させるかという目標値。目標復旧時点。

ITサービスの品質を低下させたり、中断させたりする予期せぬ出来事のことです。

「迅速な復旧」を目指す[[TEC_261]]と、「再発防止」を目指す[[TEC_757]]。

システムを動かすための土台となる、設備や基盤のことです。

IaCにおいて、サーバーやネットワークの構成情報を再利用可能な「型紙（テンプレート）」として記述したファイル。

実体（Entity）と実体間の関連（Relationship）を構造化して表現する図。

プロジェクトの進捗を、完了した作業の「当初の予算金額」として換算した価値。出来高。

プロジェクトの進捗を、作業の達成度（価値）を金額に換算して評価する手法。

作成者が主導し、関係者で[[TEC_932]]やプログラムの内容を確認するレビュー手法です。

上流から下流へ、工程を一つずつ順番に完了させて進める伝統的な開発手法。

ソフトウェア開発の検証工程におけるテストの種類。

開発されたシステムが実際の業務で支障なく使えるかを、利用者が確認する最終テスト。

技術的なプラクティスを重視し、品質と柔軟性を高める[[TEC_389_b]]手法。

ソフトウェアエンジニアリングの考え方を用いて、システムの運用を自動化し、高い[[TEC_692]]とスピードを両立させる手法、またはその職種。

サービスレベルを測定するための具体的な指標（メトリクス）。

ソフトウェアの企画、開発、運用、保守、廃棄までの一連の活動を定義したものです。

問題や課題を、より上位の担当者や専門チームに引き継いで対応を求めること。

ソフトウェアを構成する全ての部品（ライブラリ、モジュール、オープンソース等）をリスト化した、いわば「ソフトウェアの成分表」。

ユーザーから頻繁に寄せられる質問とその回答をまとめたもの。

ソフトウェアの規模を、ユーザーから見た機能の数や複雑さで測定する見積り手法。

ITサービスに障害が発生してから、次の障害が発生するまでの平均時間です。

AI（人工知能）を活用して、ITシステムの運用業務を自動化・効率化する手法や技術。

AIシステムが[[TEC_709]]、透明性、安全性、プライバシー保護などの倫理・法的基準を満たしているかを客観的に評価・検証するソフトウェアや手法。

AIシステムを開発・提供・利用する際に、品質、安全、倫理などを確保するために遵守すべき指針。

SAST、DAST、IASTなど、複数のセキュリティ診断ツールの結果を統合し、リスクの優先順位付けと一元管理を行う手法。

プロジェクトの開始から現時点までに、実際に費やされたコストの総額。実コスト。

コンピュータシステムや周辺機器を操作し、日々の運用業務を実行する担当者のこと。

システムが異常や設定のズレを検知した際、人間の手を介さず、あらかじめ定義されたルールや[[TEC_1209]]に従って自動的に元の正常な状態に戻す機能。

[[TEC_391]]が公開されており、誰でも自由に利用、修正、再配布ができるソフトウェア。

会計の適切性や有効性を確認する監査活動。

業務上の問題を発見し、改善策を実行・評価する一連の繰り返しの仕組み。[[MNG_035]]などの総称。

本番環境にあえて障害（カオス）を意図的に引き起こし、システムの耐性や自動復旧能力を検証・向上させる手法。

監査を実施する際に従うべき、基本的な規範や判断のよりどころ。

証拠の入手と評価の適切性や有効性を確認する監査活動。

[[MNG_181]]が、情報システムの処理の妥当性を検証するために、時系列に従って追跡できる一連の記録。

監査の過程で収集した証拠や実施した手続きを記録した文書。

監査証拠を収集するために[[MNG_181]]が実施する具体的な調査・検証活動。

監査を実施する専門家。独立した立場で評価・報告を行う。

監査の結果を取りまとめ、依頼者や関係者に報告するための正式な文書。

作業状況を視覚化し、仕掛かり中の作業数を制限して効率を上げる管理手法。

プロジェクトや組織を運営・維持するために必要となる、実作業以外の人件費や経費。

組織の外部にある独立した第三者が行う監査。客観性と[[TEC_692]]が高い。

ユーザー要件を実現するために、システムの具体的な機能や動作を定義する工程。

システムが「何をするか」を定義した要件。入力、処理、出力などの機能を規定する。

要件定義に基づき、ユーザの視点からシステムの機能を定義する外部設計工程。

企業が利用する複数の[[STR_184]]に対し、一貫したセキュリティポリシーを適用・監視するための仲介ソリューション。

システムの変更作業について、そのリスクや影響範囲を多角的に評価し、承認や助言を行う組織体。変更諮問委員会。

組織が継続的に品質を向上させるための、方針・目標・プロセスを体系化した管理システム。

品質管理において、データを視覚的に整理・分析し、問題解決や改善を行うための7つの代表的な手法の総称。

ファイルの変更履歴を管理する分散型の「バージョン管理システム」。チーム開発において欠かせない[[STR_271]]。

Gitを用いたプログラムコードの管理・共有を行うための[[STR_184]]やプラットフォーム。

Gitベースの[[TEC_391]]管理・共有プラットフォーム。世界最大手。

Gitベースの[[TEC_391]]管理プラットフォーム。自社サーバ運用も可能。

業務の適切性や有効性を確認する監査活動。

UMLの一つで、システムの構造を「クラス」とその間の静的な関係性で表現した図。

現状に満足せず、[[MNG_035]]などを通じて業務の品質や効率を永続的に向上させ続ける活動。

ITサービスとプロセスを継続的に評価・改善し、ビジネス価値を高める活動。

コードの変更を自動でテストし、合格したものを「人間を介さず」自動で本番環境へ公開する手法。

複数の[[TEC_608]]を組み合わせて、モジュール間のインターフェースやデータの受け渡しを確認するテスト。

発注したシステムや成果物が、注文通りの品質や機能を備えているかを確認し、受け取ること。

プロジェクトや業務の振り返り（レトロスペクティブ）を、Keep、Problem、Tryの3つの視点で整理する手法。

インフラ環境において、時間の経過とともに実際のサーバー設定などが、本来あるべき設計図（コード）からズレてしまう現象。

データ処理や分析に用いる手法の一つ。

[[STR_052]]とIT[[MNG_110]]の[[STR_767]]をまとめた、世界標準の[[STR_753]]。

[[TEC_919]]（Copyright）の概念を逆手に取り、利用者に「自由」を保証しつつ、その自由が将来の利用者にも受け継がれるようにする考え方。

変更内容を確定させること。DBでは[[TEC_446]]の永続化、開発では[[TEC_391]]の保存・反映、ビジネスでは責任を持った約束を意味する。

プロジェクトに関わる全ての人（ステークホルダー）が必要な情報を、適切なタイミングで共有・流通させるための管理活動。

予期せぬ事態（災害、事故、不祥事、システム障害等）が発生した際に、被害を最小限に抑え、業務を継続・復旧させるための緊急時対応計画。

対話を通じて、相手が自ら考え、行動し、目標を達成できるように支援するコミュニケーション手法。答えを教えるのではなく、引き出すことに主眼を置く。

顧客からの電話による問い合わせや相談、受注を一括して受け付ける拠点のことです。

プロジェクトに関わる利害関係者（ステークホルダー）の間で、意見の対立を調整し、最終的な意思決定に対して全員の承諾を得ること。

作業を最も早く開始できる時刻。先行作業がすべて完了した直後の時点。

プロジェクトの完了期限を遅らせずに、作業を開始しなければならない最も遅い時刻。

投入した時間や労力に対して、どれだけの成果を上げられるかの度合い。

[[STR_343]]等において、特定のサービスが故障や遅延を起こした際、その影響がシステム全体に波及しないよう、自動で通信を遮断する仕組み。

落雷などによって発生する瞬間的な過電圧（サージ）から、精密機器を保護すること。

コンピュータサーバーやネットワーク機器を集中して設置・運用するための専用の部屋。

ITサービスの提供・継続的改善に関わる運用概念。

ITサービスの提供・継続的改善に関わる運用概念。

ITサービスの提供・継続的改善に関わる運用概念。

ITILにおいて、日々のサービス運用を円滑に行うための5つのプロセスの総称です。

ITサービスの提供・継続的改善に関わる運用概念。

ITサービスの提供・継続的改善に関わる運用概念。

ITサービスの提供・継続的改善に関わる運用概念。

ITサービスの提供者と利用者が、提供されるサービスの品質レベルについて合意し、明文化した契約文書。サービス品質合意書。

ITサービスの提供・継続的改善に関わる運用概念。

提供されるサービスの品質や性能を具体的に数値化した指標のことです。

サービス品質の目標値を合意し、その維持・向上を図る活動。

[[TEC_339]]において、情報の入力から出力に至るまでの過程を後から追跡できるように記録されたログや証憑資料。

[[TEC_339]]を計画通りに遂行するために、予備調査、本調査、評価・結論、報告といった各工程に必要な人員と時間を算出すること。

システム全体を本番に近い環境で動作させ、要件定義通りに機能や性能が満たされているかを確認するテスト。

システムの企画から開発、運用、そして廃棄に至るまでの一連の段階（プロセス）。

プロジェクトの計画（予定）と実際の作業の進み具合（実績）を比較し、遅れがないかを監視・調整すること。

クラウド環境において、ユーザーやサービスに割り当てられた「権限」を監視・管理し、過剰な権限を特定して最小化する手法。

クラウド環境の設定ミス（ストレージの公開設定など）を自動で継続的にスキャンし、セキュリティの「姿勢（Posture）」を正すための管理手法。

組織におけるシステム開発・プロセスの「成熟度」を評価するための指標です。

ITサービスを構成する資産や構成アイテム（CI）の情報を一元管理する[[TEC_1140]]。

UMLの一つで、オブジェクト間のやり取りを「時間経過」に沿って表現した図。

パッチを当てるだけの従来の[[TEC_911]]を超え、組織が攻撃にさらされている「暴露（エクスポージャ）」を継続的に特定・評価・修正し続ける管理[[STR_7

クラウド設定（CSPM）、中身の保護（CWPP）、権限管理（CIEM）などを一つのプラットフォームに統合し、開発から運用までの[[STR_754]]を一貫して守

日本国内のコンピュータセキュリティインシデントに関する報告の受付、対応支援、情報発信を行う一般社団法人。

停電などの電源供給停止時に、自前で電気を発生させて供給を継続するための装置。

システムを新バージョンへ更新（デプロイ）した直後、自動テストなどで異常を検知した際、人間の手を介さず即座に旧バージョンへ戻す仕組み。

目標達成に向けた「プロセス」の進捗度合いを測定するための指標。[[STR_070_b]]。

需要を統制・管理するための仕組みや活動。

組織の[[TEC_804]]対策が、ルール通りに適切に実施されているかを、独立した第三者が客観的に点検・評価すること。

チームの協力と自己組織化を重視する、[[TEC_244]]の代表的な枠組み。

スクラム（アジャイル開発の手法）を実践するために必要な役割を備えた、少人数の自己組織化された集団。

プロジェクトで実施すべき作業の範囲と、成果物の定義。

設計・実装・テスト・評価（リスク分析）を繰り返し、徐々にシステムを完成させる手法。

ITサービスに関するあらゆる問い合わせ（故障、質問、要望など）を一括して受け付ける「唯一の窓口」。[[TEC_335]]。

ソフトウェア開発の検証工程におけるテストの種類。

プロジェクトの実行や目標達成において、自由な意思決定や行動を妨げる外部的、あるいは内部的な「制限」。

ITインフラや[[TEC_1142]]の「記述方法」の二大思想。目標とする『状態』を書くのが[[TEC_788]]、達成するための『手順』を書くのが[[TEC_

[[TEC_386]]において、アクセスを許可するための「条件（ポリシー）」を保存・管理する中心的な場所。

基準となる作業を決め、それと比較して他の作業の規模を「○倍」と見積もる手法。

テスト工程において、時間の経過やテストの実施量に伴い、発見される累積バグ数がどのように推移するかを示す数学的モデル。

本番稼働後のシステムに対し、不具合の修正や改善、環境変化への対応を継続的に行うこと。

ソフトウェアの企画、開発、運用、保守、廃棄に至るまでの一連のプロセス。

ある特定の業務のやり方や状況を、特定の担当者しか把握しておらず、他の人が代わりを務められない状態。

特定の作業や活動に対して、厳格に制限された一定の「持ち時間」。[[TEC_244]]で重要視される時間管理の考え方。

データ処理や分析に用いる手法の一つ。

ビジネスの現状やプロジェクトの状況を、複数のグラフや指標を用いて一画面にまとめて表示するツール。

ソフトウェア開発の検証工程におけるテストの種類。

プロジェクト全体を、実行可能なレベルまで細かく「作業単位」に分解した階層構造図。作業分解構成図。

アローダイアグラムにおいて、作業の順序関係のみを表す所要時間0の作業。

「チケット」と呼ばれる作業単位でタスクを管理し、開発を進める手法。

部署や役職に関わらず、組織の全員が参加して製品やサービスの品質を高めていく経営管理手法。総合的品質管理。

テストを実行するために必要な、入力データ、操作手順、期待される結果のセット。

システムの動作確認（テスト）のために準備された、入力用のデータ。

ソフトウェアの品質を評価するための指標。開発規模（プログラムの行数等）に対する、テスト項目数や発見されたバグ数の割合。

ICTを活用し、時間や場所の制約を受けずに働く形態（テレワーク）と、休暇先で仕事を行う形態（ワーケーション）。

地震や火災などの災害によってシステムが停止した際、速やかに復旧させるための対策や活動。

膨大なデータを分析・シミュレーションし、経営者や管理者が迅速かつ的確な意思決定を行えるよう支援するシステム。

LLMへのプロンプト（指示文）を、人間の試行錯誤ではなく、プログラムのように「宣言的」に記述し、自動で[[TEC_834]]するための[[STR_753]]。

業務上の「データ」の構造や流れを中心に据えて、システムを設計する手法です。

開発（Dev）、セキュリティ（Sec）、運用（Ops）を一体化し、開発の全工程でセキュリティを組み込む手法。

[[TEC_1081]]（開発と運用の連携）にSecurityを統合し、開発の初期段階からセキュリティ対策を組み込む（シフトレフト）考え方。

業務改善を効率的に進めるための「Plan（計画）→ Do（実行）→ Check（評価）→ Act（改善）」の4段階を繰り返す手法。[[MNG_035]]の別名。

DFDにおいて、ファイルやデータベースなど、データを長期間蓄積・保存しておく場所。

システムや業務の中で、データがどこから入り、どこへ流れていくかという移動経路のことです。

業務やシステム内でのデータの流れを、4つの記号で視覚的に表現した図。

業務で扱うデータの構造や関係性を、図や数式を用いて体系的に整理・定義すること。

組織が保有するデータを「いつまで保存し」「いつ、どのように破棄するか」を定めた明確なルール。

仕事の結果（特性）と、それに影響を与える原因（要因）の関係を、魚の骨のような形で整理した図。フィッシュボーン図。

不確実な要素がプロジェクトの結果に与える影響度を、重要度の高い順に並べた感度分析用の棒グラフ。

一方を優先すると、もう一方が犠牲になるという「両立できない関係」のことです。

システムの仕様、操作方法、開発過程などを、後から参照できるように文書として記録・管理すること。文書化。

組織内部の者が、業務の適正さや効率性をチェックし、経営目標の達成を支援する活動。身内の健康診断。

システム内部で発生した事象や操作の内容を証明するために、組織内で作成・保存される記録のこと。

企業が自発的に整備・運用する、業務を適正かつ効率的に遂行するための社内の仕組み（ルールやプロセス）。

プロジェクトにおいて、未完了の作業や実装すべき機能を、優先順位を付けてリスト化したもの。

プロジェクトの「残作業量」を縦軸に、経過時間を横軸に取ったグラフ。作業がいつ完了するかを視覚的に把握するためのツール。

OSやソフトウェアの修正プログラム（パッチ）を、組織内の多数の端末に対して計画的に適用・管理すること。

項目別の件数を「棒グラフ」で多い順に並べ、その「累積構成比」を「折れ線グラフ」で重ね合わせた図。重要事項の特定に用いる。

プロジェクトの作業工程を網目状に図解し、工期を計画・管理する分析手法。

要件定義などの工程で、ユーザーや関係者から対面で要望や現状を聞き取る調査手法。

製品の規格、業務の手順、情報の形式などを統一し、誰でも同じ品質で扱えるようにルール化すること。[[MNG_136]]の解消。

良い品質を作るためのコスト（予防・評価）と、悪い品質が原因で発生したコスト（失敗）を合計し、総コストを最小化する計算。

ソフトウェアが備えるべき品質の多角的な指標。ISO/IEC 25010で定義される。

米国の[[MNG_099]]協会（PMI）が策定した、プロジェクトマネジメントの知識体系をまとめたガイドブック。

計画、実行、評価、改善の4段階を繰り返し、業務を継続的に改善し続ける手法。

プロジェクトの現時点までに、本来完了しているはずの作業に対して割り当てられた予算額。計画値。

建物や設備などの物理的な環境を、最適に管理・活用する手法。

会議やプロジェクトにおいて、中立的な立場から進行をサポートし、参加者の発言を促して、合意形成や課題解決へ導く手法。

データ処理や分析に用いる手法の一つ。

サーバーの構築や管理を一切意識せず、特定のイベント（画像アップロード等）をきっかけにプログラムの「関数（機能）」のみを実行する仕組み。

必要な時だけ関数単位でコードを実行する[[STR_184]]。

サーバの管理を意識せずにアプリケーションを開発・実行できる仕組み。

[[TEC_339]]の結果、[[MNG_181]]が出した「改善勧告」に対して、被監査部門が適切に改善を行っているかを確認すること。

ソフトウェア開発の検証工程におけるテストの種類。

一度記録されたら、削除や書き換えが一切不可能なログ（記録）のこと。[[TEC_822]]防止機能（WORM）を備えたストレージなどに保存される。

アジャイル開発において、チームがプロセスの質を向上させるために行う改善の場。

プロジェクト全体の計画・実行・監視を統括し、QCD（品質・コスト・納期）の達成に責任を持つ役割。

プロジェクトの納期に影響を与えずに、個別の作業を遅らせることができる許容時間。

[[MNG_020]]において、完了時に予測される予算の過不足（VAC）と、当初の予算内に収めるために『これから』達成すべき[[MNG_191]]（TCPI）。

システム開発の各工程（上流から下流）と、対応するテスト工程の対応関係をV字型に示したモデル。

内部構造を意識せず、入力に対する出力が正しいかを確認するテスト手法。

設計書に基づき、プログラミング言語を用いてソースコードを記述し、単体テストを行う担当者。

プロジェクトの予算を策定し、承認された予算内で完了するように管理すること。

プロジェクトの情報をいつ・誰に・どのように伝達し、管理するかを計画・実施すること。

プロジェクトの目的達成のために実施すべき作業の全範囲（全タスク）。

プロジェクトの作業範囲（スコープ）を定義し、過不足なく管理すること。

プロジェクトを予定された納期までに完了させるために、スケジュールを管理すること。

プロジェクトの目標達成のために編成された、専門性を持つメンバーの集まり。

特定の目標を達成するために、期限、予算、品質などの[[MNG_129]]の中で、人、物、時間を計画・調整・統制すること。

組織全体のプロジェクト管理を支援し、品質や進め方を統一する専門組織です。

プロジェクトに従事し、割り当てられたタスクを遂行する構成員のこと。

プロジェクトの成功に影響を与える不確実な事象を特定し、対応を計画・管理すること。

プロジェクトマネージャの指示のもと、現場のチームや実務作業を指揮・統括する責任者。

特定の目的や結果を得るために行われる、一連の手順や活動の流れ。工程。

製品（プロダクト）を完成させるために必要な、あらゆる「やりたいこと・やるべきこと」を優先順位順に並べたリスト。

開発の早い段階で試作品を作成し、ユーザーの確認を得ながら進める手法。

早い段階で試作品（プロトタイプ）を作り、ユーザーの確認を経て開発を進める手法です。

システム開発の初期段階で作成する、主要な機能を確認するための「試作品」のこと。

ユーザーからの問い合わせや障害報告に対し、一元的に対応する窓口。

ITシステムへの変更（修正、追加、削除）によって発生するリスクを評価し、承認や優先順位付けを行うプロセス。

ある操作を1回行っても、複数回行っても、結果（システムの状態）が同じになる性質のこと。

[[TEC_244]]（スクラム）において、1イテレーション（スプリント）でチームが完了できる作業量。

2人の開発者が1台のPCを共有し、協力して一つのプログラムを作成する手法。

ソフトウェア開発において、人為的ミスを減らし品質を高めるための二人体制によるチェック手法。

稼働中のシステムを正常に保ち、不具合の修正や機能の改善を行う活動。

内部のプログラム構造や論理の流れが正しく動作するかを確認するテスト手法。

プロジェクトや障害対応の終了後に、振り返りと教訓の抽出を行う活動。

セキュリティルールや[[STR_670]]の「方針（ポリシー）」をプログラムコードとして記述し、自動的に適用・監視する管理手法。

プロジェクトのスケジュールにおいて、重要な節目や区切りとなるポイント。期間を持たない「点」として管理される。

プロジェクトの重要な節目（マイルストーン）のみを表示し、進捗を管理する図表。

プロジェクトの完了を待たず、あらかじめ設定した「重要な節目（マイルストーン）」を達成するたびに、分割して報酬を支払う契約方式。

複数のWebサービスや[[STR_009_a]]を組み合わせて、新しいサービスを構築する手法。

組織の目標を達成するために、ヒト・モノ・カネ・情報などの資源を効率的に活用・管理する活動。管理、経営。

複雑な現実世界の事象を、目的に応じて簡略化・抽象化して表現すること。

システムやネットワーク、業務の状況を継続的に監視・測定し、異常がないかを確認すること。

ユーザーが必要とする機能を、「誰が・何を・なぜしたいか」という短い文章で表現したもの。

UMLの一つで、システムの機能と外部ユーザ（アクター）とのやり取りを表現した図。

[[TEC_339]]の実務手順。まず概要を把握し（予備調査）、その結果に基づいて重点的な検証を行う（本調査）。

ある作業が完了してから、次の作業が開始されるまでに存在する「空き」の時間。

開発支援ツールや[[MNG_229]]を活用し、少人数で短期間にシステムを完成させる開発手法。

システムの「現在の状態」を「理想の状態（設計図）」に一致させるために、差分を自動で検知・修正し続ける繰り返しのサイクル。

リスクを特定し、その大きさを分析・評価する一連のプロセス。

将来発生する可能性があるリスクを特定し、組織的に対応・管理する活動。

既存の製品やプログラムを解析して、その設計情報や仕組みを導き出すこと。

外部から見た動作を変えずに、プログラムの内部構造を整理して[[TEC_606]]を高めること。

システムの利用者が、操作や運用を正しく行うための手順を説明した文書。

開発したソフトウェアやシステムを、本番環境で利用可能にすることです。

変更が承認されたソフトウェアやハードウェアを、本番環境へ安全に導入する活動。

承認された変更を、実際にテスト環境から本番環境へ安全に導入（展開）し、利用可能にするプロセス。

データ処理や分析に用いる手法の一つ。

システムが障害や攻撃を受けた際、どれだけ耐え、どれだけ迅速に正常な状態へ復旧できるかという「しなやかな強さ」を数値化した指標。

組織のセキュリティ対策の有効性を検証するため、攻撃者（レッドチーム）の立場から、実際の攻撃手法を用いてシステムや組織に擬似的な攻撃を仕掛けるテスト手法。

作成した[[TEC_932]]やプログラムの内容に誤りがないか、関係者で検査する作業です。

システムやネットワークの動作記録（ログ）を収集・解析し、不具合の特定やセキュリティの監視、利用状況の把握を行うこと。

[[TEC_391]]をほとんど書かずに、視覚的な操作でアプリケーションを開発する手法やツールの総称。

最小限のコード記述でアプリを開発できるプラットフォーム。

コード記述を一切せずにアプリを開発できるプラットフォーム。

業務の一連のやり取りや手続きの流れ、およびそれを電子化して自動で進める仕組み。

[[STR_259]]には在宅勤務、モバイルワーク、[[STR_210]]勤務が含まれる。ワーケーションは「Work（仕事）」と「Vacation（休暇）」を組