ITパスポート マネジメント系_用語集


マネジメント系

・システム監査について
・ITガバナンスについて
・アローダイアグラムをみてクリティカルパスをだしてどこくいらい遅れても大丈夫か等
・作業の工数に関する計算問題とか追加するべき要員数の計算など
・ソフトウェア保守に該当する内容
・ファシリティマネジメントについて
開発プロセスに関してどれにあたるか(システム要件定義・システム設計・プログラミングなど)
・機能要件・非機能要件どちらにあてはまるか
・テスト(単体・結合・システム・運用)について
・開発モデルの特徴について(メインはウォーターフォールモデル・アジャイル開発など)
・伝達経路の計算
SLAで合意する内容について

3 マネジメント系_用語集

1 プロジェクトスコープマネジメント

プロジェクトの実施範囲(スコープ)を定義し、成果物単位でプロジェクト全体を階層的に要素分解したWBSの作成などを行う管理プロセス。プロジェクトの遂行に必要な作業を過不足なく含めることを目的としています。

2 プロジェクト品質マネジメント

プロジェクト作業に係る各プロセスの品質及び成果物の品質を保ち、定められた品質基準を達成するための管理活動です。

3 ITIL(Information Technology Infrastructure Library)

ITサービスを適切に運営管理するためのベストプラクティス(成功事例)を包括的にまとめたフレームワークです。
ITサービスマネジメント分野で広く支持され、業界標準の教科書的な位置づけになります。
英国商務省(OGC:Office Of Government Commerce)によって作成されています。

4 リファクタリング

外部から見た振る舞いを変更せずに、より良いプログラミングに書きなおすこと。

5 リバースエンジニアリング

既存のソフトウェアの動作を解析するなどして、製品の構造を分析し、そこから製造方法や動作原理、設計図、ソースコードなどを調査する技法です。

6 ペアプログラミング

二人一組でプログラムの実装を行い、一人が実際のコードをコンピュータに打ち込み、もう一人はそれをチェックしながら補佐するという役割を随時交代しながら作業を進めていく手法です。

7 テスト駆動開発

求める機能を明確化するために、プログラムを記述するよりも前にテストケースを作成する開発手法です。そのテストをパスする最低限の実装を行った後で、機能を維持したままコードを洗練していくという手順で開発を進めます。

8 SLM(サービスレベル管理)

SLA(サービスレベル合意書)に基づき、顧客要件を満たすITサービスの提供を実現し、その品質の継続的な改善に必要なプロセスを構築するための管理活動です。サービスレベルの維持・管理を行うために「モニタリング」「レポーティング」「レビュー」「改善」というPDCAサイクルを繰り返します。

9 アジャイル開発

顧客の要望に応じて、迅速かつ適応的にソフトウェア開発を行う軽量的な開発手法の総称です。スクラム開発やXP(エクストリームプログラミング)がアジャイル開発のフレームワークとして有名で、概ね数週間ごとに分析、設計、実装、テストのサイクルを繰り返しながら、次第に完成度を高めていくことが特徴です。
アジャイルAgile)には「俊敏な」「すばやい」といった意味があります。

10 ウォーターフォール

開発プロジェクトを時系列的に「要件定義」「外部設計(概要設計)」「内部設計(詳細設計)」「開発(プログラミング)」「テスト」「運用」などの作業工程(局面、フェーズ)に分割し、開発を上流から下流に一方方向に進める開発モデルです。最初は仕様を固め、それに沿って全部を作り上げるので、要求の変化に柔軟に対応することは困難です。

11 親和図

あるテーマに基づいて集めたデータを関連によってグループ化することで項目を整理する手法です。複雑に絡み合った問題や、まとまってない意見、アイデアなどを整理し、まとめるために用いられます。

12 ITガバナンス

経営陣がステークホルダのニーズに基づき、組織の価値を高めるために実践する行動であり、情報システムのあるべき姿を示す情報システム戦略の策定及び実現に必要となる組織能力です。
ITを用いた企業統治という意味があります。ITガバナンスの構築と推進は経営者の責務であり、経営目標を達成するための情報システム戦略の策定、組織規模でのIT利活用の推進などがITガバナンスの活動に該当します。

13 FAQ(Frequently Asked Questions)

頻繁に寄せられる質問とそれに対する回答をまとめておき、利用者が自分で検索できる仕組み。

14 イテレーション

アジャイル開発で、全体の開発期間を数週間程度の短い期間に区切って、この小さな開発単位ごとに設計・開発・テストを反復します。
このアジャイル開発における開発サイクルのことを、XP(エクストリームプログラミング)では「イテレーション」といいます。
スクラム開発では、「スプリント」と呼びます。

15 DevOps(デブオプス)

開発を意味するDevelopmentと運用を意味するOperationを組み合わせた造語で、開発担当チームと運用担当チームが緊密に協力・連携し、自動化ツールなどを活用して柔軟かつ、スピーディーに開発を進めるソフトウェア開発の手法です。継続的インテグレーション、継続的デリバリ、継続的デプロイメントの3つのプラクティスを利用することにより、開発効率の向上、迅速なリリース、信頼性の向上、共同作業による文化の醸成などが期待できます。

ナレッジマネジメント

組織内の各個人がもつ知識やノウハウを組織全体で共有し、有効活用する仕組み

16 PMBOK(Project Management Body of Knowledge)

プロジェクトマネジメントに関する知識を体系的にまとめた参考書のようなもので、通称は「ピンボック」です。PMBOKアメリカの「PMI」というプロジェクトマネジメントの普及拡大を目的とした非営利団体によって作られました。現在では、PMBOKはプロジェクトマネジメントの世界標準となっています。
PMBOKの目標は、「QCD(品質、費用、納期)」の管理です。

PMBOKでは、プロジェクトの開始から終結までの流れを「立ち上げ」→「計画」→「実行」→「監視・コントロール」→「終結という5つのプロセスに分割し、定義しています。

・1 立ち上げプロセス
 プロジェクトの開始前に、その認可を得るプロセスが「立ち上げプロセス」です。 プロジェクトに必要な情報であるプロジェクトの目的、目標、予算、成果を定義し、プロジェクト憲章の作成とステークホルダー(利害関係者)の特定を行います。

・2 計画プロセス
 計画プロセスは、プロジェクトの目的、目標を達成するための作業計画を立案し、作成するというプロセスで、同プロセスの中にさらに20もの詳細なプロセスが定義されています。このとき、目標の定義と洗練や、プロジェクト実行時の一連の行動の流れも含めて規定します。

・3 実行プロセス
 実行プロセスは、立案した計画に基づいて人員と資源を調整し、プロジェクトを実行するというプロセスです。もっとも資源を消費するプロセスであり、実行の結果によっては計画を更新し、ベースラインを再設定する必要があります。

・4 監視・コントロールプロセス
 このプロセスは、プロジェクト実施中の作業について、計画と差異が発生していないかを継続的にチェックして、差異が検出されたならば、その是正を行います。

・5 終結プロセス
 終結プロセスは、所定のプロセスが完了していることを検証し、プロジェクトやフェーズを公式に終結させるプロセスです。ただ終了をするだけでなく、プロジェクト実行において獲得した情報や経験を保管し、次のプロジェクトに役立てることが重要とされています。


次に、5つのプロセスを実行していくために必要な、10個の知識エリアと呼ばれる分野を紹介します。
PMBOKの10の知識エリア

1)統合マネジメント
  プロジェクト全体の方針を決め、調整する分野が「統合マネジメント」です。他の9つの知識エリアを統合し、マネジメントする位置づけにあります。

2)スコープマネジメント
  プロジェクトの範囲(=スコープ)を定めた上で、プロジェクトの目標を達成するために必要な成果物とタスクを定義し、目標達成を確実に行うための分野です。プロジェクトの成否に影響する最重要項目とも言われています。(プロジェクトで実行すべき作業のこと)

3)スケジュールマネジメント
  時間当たりの生産性を高めるために時間の管理をする分野がスケジュールマネジメントです。2017年PMBOK第6版のリリースに伴って、「タイムマネジメント」から、「スケジュールマネジメント」に名称が変更されました。

4)コストマネジメント
  プロジェクトを予算内で完了させるために必要なコストの見積もりや予算設定、コントロールをするのがコストマネジメントです。現実的な予算を設定し、予算を超過しないようにマネジメントを行います。

5)品質マネジメント
  プロジェクトのプロセスや、プロジェクトによってできた成果物の品質の管理をする分野が品質マネジメントです。プロジェクトの品質とは、成果物がクライアントの要求に一致しており、使用に適していることを指します。

6)資源マネジメント
  プロジェクトの目的を達成するために人材だけでなく物的資源を調達・管理し、プロジェクトを遂行できるチームを組織する分野が資源マネジメントです。 2017年PMBOK第6版のリリースに伴って、「人的資源マネジメント」から「資源マネジメント」へ、名称と内容が変更されました。

7)コミュニケーションマネジメント
  コミュニケーションマネジメントは、ステークホルダー(利害関係者)との適切なコミュニケーションを行うために必要であり、具体的にはプロジェクト情報の生成、収集、配布、保管、検索、最終的な廃棄を行います。ポイントとしては、ただ伝達すればいいわけではなく、相手の理解を得るところまでが求められます。

8)リスクマネジメント
  リスクとは、安全かどうかが不確実なものを指します。リスクを避けてばかりいるとチャンスが得られない可能性も高く、リスクは必ずしも悪いものではありません。そこで、プロジェクトにとってマイナスになるリスクを予防し、コントロールしながら継続的に管理、調整する必要があります。

9)調達マネジメント
  作業の実行に必要なプロダクト、サービス、所産をプロジェクト・チームの外部から購入または取得する際に、業者の管理をすることを調達マネジメントと定義しています。調達には契約がつきものですが、契約だけがこの領域の目的ではありません。選定から納品の進捗管理検収まで、調達に必要なすべての管理を行います。

10)ステークホルダーマネジメント
  ステークホルダー(利害関係者)にとって必要な情報を収集し、その保管・伝達を管理する分野がステークホルダーマネジメントです。 2012年公開のPMBOKガイド第5版で、コミュニケージョンマネジメントから独立して新設された知識エリアです。

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

組織が保有または使用する全施設資産、及びそれらの利用環境を経営戦略的視点から総合的かつ統括的に企画、管理、活用する管理手法です。土地、建物、構築物、設備などの「業務用不動産」を管理対象とします。

18 ブラックボックステスト

システムへの入力とそれに対して得られる出力だけに着目して、様々な入力に対して仕様書通りの出力が得られるかどうかを検証していくテストで、主にシステムテストで用いられる。システムの内部構造を考えずに検証を行うのでブラックボックステストと呼ばれている。

19 ホワイトボックステスト

プログラムやモジュールの単体テストとして実施されるテスト手法で、内部構造に基づき仕様書通りに動作するかを検証するために実施される。内部構造が明らかな状態でテストを行うこからホワイトボックステストと呼ばれている。

20 共同レビュー

利用者(顧客)開発者が共同して設計書などの体系的な検査を行うことです。システム要件の定義には利用者も参加し、開発側との認識の違いを埋めたり、必要な機能や能力などが含まれているかを確認したりすることが重要です。

21 プロジェクト人的資源マネジメント

プロジェクトチームのメンバが各々の役割と責任を全うできるように管理することで、プロジェクトチームのパフォーマンスを維持することを目的とする活動です。
このプロセスには、「プロジェクトチームの編成」「プロジェクトチームの育成」「プロジェクトチームのマネジメント」などの活動があり、人のパフォーマンスを最大化することを目的に、要員の育成もその活動に含まれます。

21 ITサービスマネジメント・問題管理

問題の根本原因を突き止め、インシデントの再発防止のための恒久的な解決策を提示する一連の活動です。また将来発生し得る障害を予見し、可能な限り防止する能動的な活動も行います。

22 プロジェクトのコミュニケーション方法

1)双方向型・・・会議や電話
2)プッシュ型・・メールやFAXおよび報告書
3)プル型・・・・電子掲示板やイントラネットへの掲載

23 類推見積法

過去に経験した類似のシステムについての実績データを基にして、システムの相違点を調べ、同じ部分については過去のデータを使い、異なった部分は経験から規模と工数を見積もる方法です。低コストで簡単に見積もることができ、システムの詳細機能が固まる前の初期段階から適用可能ですが、担当者の能力によって見積り結果のバラつきが生じやすい特徴があります。

24 積み上げ法

システムの機能をモジュール単位に分割した後、モジュールごとの工数を割り出し、それを足し合わせて全体の工数とする方法です。類推法は積み上げ法よりも低コストで見積りが可能です。

25 プロジェクトスコープマネジメント

プロジェクトの実施範囲(スコープ)や成果物を定義し、プロジェクトチームが行うべき作業を階層的に細分化したWBSの作成を行う管理プロセスです。プロジェクトの遂行に必要な作業を過不足なく含め、プロジェクトを成功させることを目的とします。

26 プロトタイプ(Prototype)

開発の初期段階で、利用者の要求する仕様との整合性を確認したり、問題を洗い出したりするなどのために作成される簡易的な試作品です。
プロトタイプを用いる開発モデルでは、利用者に完成品のイメージを早期に理解させ、承認やフィードバックを得ながら開発を進めていくため、開発後半での後戻りや完成時に不具合が発覚することを防ぐことができます。

27 SLM(Service Level Management)

サービスレベル合意書(SLA)に基づき、顧客要件を満たすITサービスの提供を実現し、その品質の継続的な維持・改善を行う管理手法、またはそれを目的として活動するプロセスです。

28 ウォータフォールモデル

開発プロジェクトを時系列に「要求定義」「外部設計(概要設計)」「内部設計(詳細設計)」「開発(プログラミング)」「テスト」「運用」などの作業工程(局面、フェーズ)に分割し、開発を上流から下流に一方向に進める開発モデルです。
原則として前工程が完了しないと次工程に進まない(設計中にプログラミングを開始するなどの並行作業は行わない)ことで、前工程の成果物の品質を確保し、システム開発の一貫性を保証します。ウォータフォールモデルは、工程管理がしやすく大規模なシステム開発に向いていますが、工程の後戻りが生じると大幅な時間のロスが生じるといった欠点があります。

29 スパイラルモデル

サブシステムごとに開発プロセスを繰り返し,利用者の要求に対応しながら改良していく手法である。

分析 → 設計 → プログラミング → テスト → 評価(改良及び追加機能を繰り返す)
開発工程を繰り返しながら開発工程の規模を拡大(機能の改良・追加)し、開発コストの増加などのリスクを最小にしつつシステム開発を行う開発モデルです。

30 プロトタイピングモデル

システム開発の早い段階で試作品を作成し,利用者の意見を取り入れながら要求や仕様を確定する手法である。

31 ITサービスマネジメント

・インシデント管理
 インシデント管理は、システムの異常終了や構成機器の障害発生などのようにサービスの中断やサービス品質の低下につながるような事象が発生した時に、サービスの中断時間を最小限に抑えて速やかに回復することを目指すプロセスです。

・変更管理
 変更管理は、変更作業にともなうリスクを管理し、リスクとメリットを考慮してリリース管理プロセスへ引き継ぐかどうかの評価を行うプロセスです。

・問題管理
 インシデントや障害原因の追及、および恒久的な対策、再発防止策の提案を目的としたプロセスです。

・リリース管理
 変更管理プロセスで承認された変更作業について、実際のサービス提供システムへ変更作業を行うプロセスです

32 リエンジニアリングモデル

既存のソフトウェアを利用して新しいソフトウェアを作成するための開発モデル全般を指します。

33 リスクマネジメント

脅威,脆弱性,リスクは次のように定義されます。(IPA Webサイトより引用)

・脅威
 システム又は組織に危害を与える事故の潜在的原因

脆弱性
 脅威によって影響を受ける内在する弱さ

・リスク
 ある脅威が脆弱性を利用して損害を与える可能性

リスクは、脅威と脆弱性が結びつくことで生じ、守るべき情報資産の価値が高いほどリスクが大きくなります。リスクの大きさは、「発生確率×損害の大きさ」で評価されますが、発生確率は「脅威と脆弱性」によって決まり、損害の大きさは「資産価値」で決まるので、リスクの大きさは、資産価値,脅威,脆弱性の3要素の関係で評価されます。

34 SLA

SLAを締結することによって、利用者と提供者の双方に次のようなメリットがあります。
 1 双方がサービスレベルについての共通認識を持つことができる
 2 委託者は、サービスレベルの妥当性を確保でき、サービスが未達成時は保険となる
 3 提供者側は、サービス提供の責任範囲を明確化することができる

35 リスクコントロールマトリクス(RCM:Risk Control Matrix)

業務上に潜在するリスクとそれに対するコントロール(統制)の関係を一覧表にしたものです。内部統制の6要素のうち「リスクの評価と対応」と関係が深く、「業務フロー図」「業務記述書」とともに内部統制の整備状況を明確にするための3点セットと呼ばれています。
RCMの作成には、業務プロセスに存在するリスクと、実施しているコントロールを対応付けて記述することで、どのコントロールがどのリスクの低減のために存在するのかを明確にする意図があります。

36 プロジェクト人的資源マネジメント

プロジェクトチームのメンバが各々の役割と責任を全うすることでプロジェクトチームとして機能し、プロジェクトの目標を達成することを目的とするプロセスです。
このプロセスでは、「プロジェクトチームの編成」「プロジェクトチームの育成」「プロジェクトチームのマネジメント」などが実施されます。

37 システム設計

1 外部設計
  システムを「利用者側から見た」設計を行います。つまり、ユーザーインターフェースなど、利用者が実際に手に触れる部分の設計を行います。
 
 *なんとか画面 OK → 〇〇処理へ
         Cancel → 前画面へ

2 内部設計
  システムを「開発者から見た」設計を行います。つまり、外部設計を実現するための実装方法や物理データ設計などを行います。

*うんたらシステム → 〇〇機能 → 処理A → ファイルA
                 → 処理B → ファイルB
          → 〇〇機能

3 プログラム設計
  プログラムを「どう作るか」という視点の設計を行います。プログラムの構造化設計やモジュール同士のインターフェイス仕様などがこれに当たります。

*処理A → なんたらチェック → チェック1
                → チェック2
     → ファイル出力

38 システム設計

1 システム設計方式  -システム要件を「ハードウェア」「ソフトウェア」「手作業」に振り分ける
2 ソフトウェア要件定義-ソフトウェア要件(機能や性能)を決める。主にインターフェースとデータ
3 ソフトウェア方式設計-ソフトウェア要件(機能や性能)をプログラムの単位まで分割する。
4 ソフトウェア詳細設計-「プログラムの単位まで分割された要件」をさらに「コーディングができる単位」まで分割する

39 テスト

システムが仕様通りに動くか確認する工程。
それと同時に、要件定義プロセスで明確にした「業務に必要な条件(業務要件)」がきちんと実現されているかも確認します。
システムテスト」「結合テスト」「ブラックボックステスト」「ホワイトボックステスト」「ソフトウェア受入れ」がよく出題される。