※学習ノートなので内容には不備がある可能性があります。
PMBOK（Project Management Body of Knowledge）
プロジェクトマネジメントに関するノウハウや手法を体系立ててまとめたもの、10の知識エリア×5つのプロセス×3つのパートの3次元マトリクスとなる
10の知識エリア
１．総合マネジメント
２．スコープマネジメント
３．スケジュールマネジメント
４．コストマネジメント
５．品質マネジメント
６．資源マネジメント
７．コミュニケーションマネジメント
８．リスクマネジメント
９．調達マネジメント
１０．ステークホルダーマネジメント
5つのプロセス、立ち上げ、計画、実行、管理・監視、終結
| 10の知識エリア | 立ち上げ | 計画 | 実行 | 監視コントロール | 終結 |
|---|---|---|---|---|---|
| ①プロジェクト統合マネジメント | ・プロジェクト憲章の作成 | ・プロジェクトマネジメント計画書の作成 | ・プロジェクト作業の指揮、マネジメント ・プロジェクト知識のマネジメント | ・プロジェクト作業の監視、コントロール ・統合変更管理 | ・プロジェクトやフェーズの終結 |
| ②プロジェクト・スコープ・マネジメント | ・スコープマネジメントの計画 ・要求事項の収集 ・スコープの定義 ・WBSの作成 | ・スコープの妥当性確認 ・スコープのコントロール | |||
| ③プロジェクト・スケジュール・マネジメント | ・スケジュールマネジメントの計画 ・アクティビティの定義 ・アクティビティの順序設定 ・アクティビティ所要期間の見積もり ・スケジュールの作成 | ・スケジュールのコントロール | |||
| ④プロジェクト・コスト・マネジメント | ・コストマネジメントの計画 ・コストの見積もり ・予算の設定 | ・コストのコントロール | |||
| ⑤プロジェクト品質マネジメント | ・品質マネジメントの計画 | ・品質のマネジメント | ・品質のコントロール | ||
| ⑥プロジェクト資源マネジメント | ・資源マネジメントの計画 ・アクティビティ資源の見積もり | ・資源の獲得 ・チームの育成 ・チームのマネジメント | ・資源のコントロール | ||
| ⑦プロジェクト・コミュニケーション・マネジメント | ・コミュニケーションマネジメントの計画 | ・コミュニケーションのマネジメント | ・コミュニケーションの監視 | ||
| ⑧プロジェクト・リスク・マネジメント | ・リスクマネジメントの計画 ・リスクの特定 ・リスクの定性的分析 ・リスクの定量的分析 ・リスク対応の計画 | ・リスク対応策の実行 | ・リスクの監視 | ||
| ⑨プロジェクト調達マネジメント | ・調達マネジメントの計画 | ・調達の実行 | ・調達のコントロール | ||
| ⑩プロジェクト・ステークホルダー・マネジメント | ・ステークホルダーの特定 | ・ステークホルダー・エンゲージメントの計画 | ・ステークホルダー・エンゲージメントのマネジメント | ・ステークホルダー・エンゲージメントの監視 |
3つのパート、入力、ツールと実践技法、出力
変更要求
プロジェクトで発生する課題への対処法として変更要求が提案される。
PIMBOKでは変更要求のタイプを「是正処置」「予防処置」「欠陥修正」「更新」の4つに分類している
是正処置
プロジェクト作業を、プロジェクトマネジメント計画書に沿うように再調整する意図的な活動。
例：ある作業の、スケジュールが遅れているので要因を追加する、など。
予防処置
プロジェクト作業の将来のパフォーマンスがプロジェクトマネジメント計画書に沿うようにする活動の事。
例：あるサブシステムの成果物の品質が、要求されるレベルを満たさないことが予想されるので、設計ドキュメントのレビューに有識者を参加させる。
欠陥修正
不適合プロダクトを修正する活動の事。
例：受入テストにおいて、あるサブシステムのプログラムが要求仕様を満たしていないことが判明したので、プログラムを修正する。
更新
正式にコントロールされているプロジェクト計画書や計画書などに対する、アイデアの追加や修正の反映をすること。
例：法規制が改定されたので、新しい法規制に対応するための活動をWBSに追加する。
組織のプロセス資産
プロジェクトマネジメントにおいて考慮すべき内外の多くの要素を、組織プロセスの資産と、組織体の環境要因に分けて整理している。
組織プロセス資産
プロジェクトで利用できる資産でプロジェクトの管理下にはないもの。
１．プロセスと手順
組織のおける仕事のやり方、組織の標準プロセス、品質方針と手順、標準化されたガイドライン、パフォーマンス測定、課題と欠陥のコントロールなど
所属している組織特有の、計画書、プロセス、方針、手続き、知識ベース。
２．企業の知識ベース
企業や組織が持つノウハウや情報
システムを構築するノウハウ、効率の良い物流のノウハウなど
組織体の環境要因
プロジェクトチームの外部にあってプロジェクトの計画プロセスに影響を与える様々な要因を含んだもの。
ステークホルダのリスク許容度、組織のインフラストラクチャ、組織の文化・体制・ガバナンスなど
プロジェクト憲章
プロジェクトの存在を正式に認可するために必要な文書。スポンサーが承認を行う
プロジェクトマネージャの特定、ステークホルダー、目標、制約条件などが記載される
プロジェクト作業範囲記述書
組織のビジョン、目標及びビジネスニーズとともに、プロジェクトが提供するプロダクト、サービスなどを明確にした文書。
プロジェクトマネジメント計画書
どのようにプロジェクトを実施し、監視し、コントロールするのかを定めるために、プロジェクトを実施するためのベースライン、並びにプロジェクトの実行、コントロール、および終結する方法を明確にした文書。
プロジェクトスコープ記述書
プロジェクトの最終状態を定義することによって、プロジェクトの目的、成果物、要求事項及び境界を含むプロジェクトスコープを明確にした文書。
ローリングウェーブ計画法
計画を段階的に詳細化する手法。要件定義では大雑把にしか見えていないため大まかに計画し、設計段階になったらより近くなって見えてくるので詳細化する。これを繰り返す
リスクの種類
リスクには、プロジェクトで管理できない全体リスクと、管理できる個別リスクがある。
全体リスクの例は、経済、社会、政治情勢など。
個別リスクの例は、遅延や超過など。
またリスクは、ポジティブ・リスクと、ネガティブ・リスクに分かれる。
リスク対応戦略
| リスクの種類 | リスク対応戦略 | 説明 |
|---|---|---|
| プラスのリスク | 活用 | 好機を確実にとらえようとする |
| 強化 | リスクの発生確率を大きくする | |
| 共有 | 好機をとらえることのできる人と行動を共にする | |
| 受容 | そのまま受け入れる | |
| マイナスのリスク | 回避 | リスク要因となる脅威を取り除く |
| 転嫁 | リスクを第三者へ移転する | |
| 軽減 | リスクの発生確率を小さくする | |
| 受容 | そのまま受け入れる |
定性的リスク分析
リスクの発生確率と影響度からリスクの優先度を決定するプロセス
ツール
発生確率・影響度マトリックス
リスクの発生確率と影響度を数値化してマトリックス表記したもの、2つの値を掛け合わせたものがその結果となる。掛け合わせた数値の結果で等級付けができる。リスクはマイナスのリスク（脅威）だけでなく、プラスのリスク（好機）もある。
定量的リスク分析
特定したリスクがプロジェクト全体に与える影響を数量的に分析するプロセス
ツール
感度分析
ある前提となる値を動かすと、最終結果がどのくらい変化するかという、感度を分析すること。プロジェクトではどのリスクがプロジェクトに最も影響を及ぼすか考える。事象の発生が最終結果に及ぼす影響が大きい順（不確実性が高い順）に並べるトルネード図が良く使われる
期待金額価値分析（EMV）
リスクが顕在化したときの影響金額に発生確率を乗じて求める。リスクはプラスとマイナスの値がある
デシジョンツリー
取りうる選択肢と発生する事象についてツリー構造で分析し、最終的な選択肢の期待値を求める手法
ステークホルダーの関与度の管理
ステークホルダーを特定して、ステークホルダー関与度マトリックスにまとめ、ステークホルダーエンゲージメント計画書を作成する。
ステークホルダー関与度マトリックス（Stakeholder Engagement Assesment Matrix）とは、各ステークホルダーの現在の関与度（Current）と、求められる関与度（Desired）を可視化するツール
ステークホルダーエンゲージメント計画書とは、効果のある関与を助長する戦略と行動を記述した計画書の事
関与度の５段階
不認識：プロジェクトの存在を認識していない
抵抗：プロジェクトの進行を邪魔する
中立：プロジェクトに対して抵抗も支持もしない
支援型：プロジェクトの進行を支持する
指導：プロジェクトをリードする
エンゲージメントは婚約（約束）という意味があるが、ここでは、絆や愛着といった意味で使われる。
ワークパッケージ
プロジェクトの工程を階層的に小さな単位に分解したWBS（WorkBreakdownStructure）において、管理する最小単位作業の事。
ワークパッケージごとに詳細な作業の内容を記述したものをWBS辞書と呼ぶ。
パーツAの設計、開発、テストなどの1つ1つがワークパッケージ。
ワークパッケージの作業見積もり法
重み付けマイルストーン法
行程中に進捗が明確に判定できる意味のあるマイルストーンを設定して進捗管理する。ドキュメント初版完了で40％、社内レビュー完了で60％、顧客承認で100％等。
固定比配分法
作業を開始したら50％、完了したら100％というように作業の開始と完了の2時点において計上する進捗率を決めておく。配分比率には25/75、50/50、75/25などがある。
出来高パーセント見積もり法
担当者の主観で出来高を配分する。
アクティビティ
ワークパッケージをさらに作業（タスク）にまで細分化したもの
プレジデンスダイアグラム法
ワークパッケージを構成するアクティビティを並べたスケジュールネットワーク図。
作業順序を明確にして、作業関係を、リード（先行と後続のアクティビティを重ねることができる）とラグ（先行と後続のアクティビティを重ねることができない）に分類し、作業関係図を図示する。
FS関係（Finish-to-Start）先行のアクティビティが完了してから後続のアクティビティを開始する。
SS関係（Start-to-Start）2つのアクティビティを同時に開始する。
アジャイル開発
スクラム
経験的プロセス制御の理論を基本としており、スプリントと呼ばれる周期で、検査と適応を繰り返しながら開発を進める。
エクストリームプログラミング（XP）
比較的小規模な開発に適した、プログラミングに焦点を当てた開発アプローチであり、5つの価値を高めるように開発を進める。
コミュニケーション：開発チーム内、顧客とのコミュニケーション。
シンプル：最初の設計を極力シンプルにし、そのほかは必要になった時に盛り込む。
フィードバック：顧客からのフィードバックで必要な機能を洗い出し、無駄な機能を作らない。
勇気：最初に綿密な計画を立てない分、途中で大胆な変更が求められることがある。
尊重：ほかのメンバーを尊重する姿勢。
特徴的なプラクティス
反復：1つのイテレーションが１，２週間となるように区切り、設計、実装、テスト、リリースを繰り返す。
共通の用語：用語集を作成してコミュニケーションの齟齬を無くす。
テスト主導型：テスト駆動開発でも採用されるように、テストを先に作る。
ペア・プログラミング
ストーリーの作成：ストーリーカードと呼ばれる、開発する予定の機能を書いた紙を用意し顧客と相談し実装の優先を決める。
ユーザ機能駆動開発（FDD）
Feature Driven Developmentは、利用者から見て価値があるまとまりを一つの機能単位とし、その単位ごとに設計や構築などの5つのプロセスを繰り返しながら開発を進める。
ベロシティ
「速さ」を表す英語
チームの生産性の測定単位であり、ある期間で製造、確認、受入れが行われた成果物の量を表すもの
スクラム開発で1スプリントにチームが消化したポイントの合計、タスクごとにポイントがふられているため、チームが消化した作業量となり、次回のスプリント計画での作業量目安となる
ストーリー・ポイント
開発規模を見積もる際の規模の単位、ユーザストーリ同士を比較し、相対的な量で表す
バックログ
完了待ちのプロダクト要求事項と成果物を組み合わせたものをビジネスにおける優先度順に並べたもの。
バーンアップチャート、バーンダウンチャート
定められた機関で完了した作業量と作業残量をグラフにして進捗状況を表す
リーンソフトウェア開発
トヨタ式生産方式をソフトウェア開発に適用した開発手法。具体的な実践手順ではなく、プラクティス作り出すのに役立つ7つの原則とそれを実現する22のツールが定義されている。
１．無駄をなくす
そもそも無駄なもの（作ったが使われないもの）を作る等。少しづつ顧客と進めていく事で解決できる。
２．品質を作りこむ
不具合はなるべく早く（前のフェーズ）で見つけた方が修正コストが小さくて済む。最後に品質を上げようとするのではなく、その工程ごとで品質を作りこむ。
３．知識を作り出す
プロジェクトは過去に同じものはない、そのため、早めに対象プロジェクトからプロジェクト固有の知識（開発ノウハウやチームの生産能力等）を生み出すことが大切。
４．決定を遅らせる
決定をなるべく後ろ倒しにできれば、そのぶん精度の高い決定が下せる。
５．早く提供する
全部できてから顧客に見せて「違う」と言われたら大ごとになる。顧客に早めに提供してフィードバックをもらおう。
６．人を尊重する（権限を委譲する）
ソフトウェアの詳細を理解しているPGなどの実際に作業する人に技術的な決定権を与えて、最終的な品質を上げる。
６．全体を最適化する
ソフトウェア単体で考えるのではなく、ソフトウェアを含む顧客の業務全体を考え、最適化する。
EVM（Earned Value Management）
アーンドバリュー分析はプロジェクトマネジメントにおいて進捗状況の把握、管理を行う手法の一つ。作業の到達度を金銭などの価値に変換したEV（EarnedValue：出来高）という概念で把握する
EV（EarndValue：出来高）
ある地点までに完了した工程の予算コスト合計値、作業の到達度を金銭的な価値に換算したものととらえることができる
プロジェクト開始から数ヶ月経って、そこまでに完了している作業の見積もりコスト合算値はどれくらいかということ。
PV（PlannedValue：計画価値）
計画時に見積もられたある地点までに到達すべき作業の予算コストの合計値のこと
AC（ActualCost：実コスト）
ある地点までに投入した実際のコストの事
SV（ScheduleVariance：スケジュール差異）
ある地点での、EV - PVの値
値が正であればスケジュールは前倒し、負であれば遅延していると言える
SPI（SchedulePerformanceIndex：スケジュール効率指数）
EV ÷ PVで計算された値
1以上ならスケジュール前倒し、1以下なら遅延している
CV（CostVariance：コスト差異）
ある地点での、EV - ACの値
値が正であればコストが予算内に収まっており、負なら予算を超過している
CPI（CostPerformanceIndex：コスト効率指数）
EV ÷ ACで計算された値
1以上なら予算内のコストで対応できており、1以下ならコスト超過している
ファンクションポイント法
IFPUG法
１．ソフトウェアのファンクションを明確にする
２．ファンクションタイプを決定する
外部入力（EI）、外部出力（EO）、外部照会（EQ）、内部論理ファイル（ILF）、外部インタフェースファイル（EIF）の5つのタイプに分類する
論理的なデータの蓄積「データファンクション」：ILF、ELF
データの入出力「トランザクションファンクション」：EI、EO、EQ
３．全てのファンクションについて3段階（高、中、低）に分類する
４．２と３の結果をもとにファンクションポイントを計算する
契約形態
| 項目 | 請負契約 | 準委任契約 | 派遣契約 |
|---|---|---|---|
| 完成責任 | 有 | 無 | 無 |
| 瑕疵担保責任 | 有（通常1年） | 無 | 無 |
| 指揮命令関係 | なし | なし | 契約元が労働者へ 指揮命令する |
| 作業場所 | 自由 | 自由 | 指定 |
| 著作権の帰属 | 原則契約先 | 原則契約先 | 原則契約元 |
システム及びソフトウェア品質モデル
有効性
利用者がシステムで目的を達成できるか
効率性
利用者が目標達成するために使用したシステムの資源は非機能要求を満たしているか（PCのリソース、時間、資金等）
満足性
実用性
システムを利用したことでの目標達成状況は利用者を満足させているか
信用性
システムは利用者が意図したとおりに動いているか
快感性
利用者がシステム利用で喜びを感じるか
快適性
利用者がシステムを快適に利用できるか
ITIL
JIS Q 2000-1：2012 サービスマネジメントシステム要求事項
監査及び要求事項
監査員は、自らの仕事を監査してはならない。
監査の基準、範囲、頻度及び方法は文書化しなければならない。
不適合を周知し、優先度付けをし、処置の責任を割り当てなければならない。
あらかじめ定めた間隔でSMS及びサービスをレビューしなければならない。
非機能要件
可用性（アベイラビリティ）
システムの稼働率、ダウンタイム、ディザスタリカバリー、メンテナンスでの停止時間等
パフォーマンス
同時アクセス数、ピーク時のアクセス数、レスポンス速度等
拡張性（スケーラビリティ）
データ容量、データ件数件数が将来どのくらい増えるかという事
セキュリティ
不正アクセス、Dos攻撃への対応、利用制限等
運用性
運用監視、不正書き込みの監視、データ更新時のメンテナンス性等
ユーザビリティ
ユーザーの使いやすさ
移行性
現行システムから新システムへの移行に関する要件、移行期間、対象、移行方法等
システム環境・エコロジー
システム設置環境やエコロジーに関する要求
用語
調達作業範囲記述書（Statement of Work：SOW）
買手が売り手に対して、仕様、必要量、品質レベル、パフォーマンスデータ、実施期間、作業場所、その他要求事項などの要求事項を記載したもの。プロジェクト完了後の調達品の運用サポートなど必要な付帯サービスに関する記述も含める。
クリティカルチェーン法
リソースの競合、不足によってクリティカルパスが伸びないようにバッファを設ける。
プロジェクト全体のバッファ（プロジェクトバッファ）とクリティカルチェーン上のアクティビティとそれ以外のアクティビティの合流地点に設けるフィーディングバッファ（合流バッファ）、同じ資源を使うタスクが競合しないように設けるリソースバッファ（資源バッファ）がある
RACIチャート
タックマンモデル
チームの成長を4段階に分けてとらえたもの
形成期、成立期（Forming）不安、緊張、遠慮、様子見
混乱期、動乱期（Storm）主義主張のぶつかり合い
統一期、安定期（Norm）共通の規範や役割が出来上がる、個人の思考や行動の特性を理解し合う
機能期、遂行期（Perform）チームが機能して成果が生まれる、リーダーが言わなくてもメンバーが自律的に動く
解散期（Adjourning）：作業を完了してプロジェクトから転出していく段階
混乱期をよりよく乗り越えることがポイント、事なかれ主義×、冷静にお互いをフィードバックする
クラッシング
クリティカルパス上の工程に資源を投入して、プロジェクト工期を短くする手法、遅れを取り戻すのにも使われる
工数をぶち込むイメージ？
ファストトラッキング
予定された順番に勧めていくべき作業を、先行作業が完了する前に並行して後続作業を進めることでスケジュールを短縮する。遅れを取り戻すのにも使われる。
手直しが必要になるといったリスクが増す。
マッシュアップ
2つ以上のWebサービス（API）を利用して新しいサービスを生み出すこと
元々マッシュアップは音楽用語で、異なる音源のトラックをそれぞれ取り出してミックスし一つの楽曲にすること
36協定
労働基準法36条に基づく労働協定
企業が法務労働時間（1日8時間、週40時間）を超えて労働を命じる場合、所轄の労働基準監督署への届けが必要となる
CSIRT（Computer Security Incident Response Team）
シーサートと呼ばれ、国家や企業内においてコンピュータインシデントセキュリティに関する報告を受け取り、調査し、対応活動を行う組織
コンフィギュレーション・マネジメント
システムの機能、性能などを保持するために、システムのドキュメント、管理ツール、ハードウェア、ソフトウェアを管理すること
PMBOKの中では統合管理の中の変更管理にあたる
プロジェクトのプロダクト、サービス、所産、構成要素などの特性に対する変更と実施状況を記録・報告したり、要求事項への適合を検証するためのプロダクト、所産又は構成要素に対する監査を支援したりする活動の事。
コンフリクト・マネジメント
組織内でネガティブなイメージの、コンフリクト（衝突、対立）を、組織の活性化や成長のチャンスととらえ、積極的に問題解決を図ろうとすること
コンフリクトの解消をゼロサムではなく、WinWinとなるような解決方法を目指す
プロジェクトポートフォリオマネジメント
ポートフォリオマネジメントは金融資産を、リスク回避しながら、収益性を高めるように、バランスよく投資するという意味が含まれるが、それのプロジェクトバージョン
組織内のプロジェクトを総括的にとらえ、全体の状況管理や分析を行い組織全体の効率化を実現する
COCOMO
ソフトウェア開発の見積もり手法の一つ、数式は「T=k×（LOC）^ｘ」となる
T：工数
k：補正関数、成果物、ハードウェア、開発者、プロジェクトの属性などから決まる1以上の係数
LOC：ソフトウェアの期待コード行数
x：開発規模の大小や複雑性などから決まる1.05か1.25の乗数
問題文では「T＝3.0×（LOC）^1.12」の数式が与えられた
RoHS指令
基準値を超える鉛、水銀などの有害物質を電気・電子機器に使用することを制限するためにEUが制定し施行しているもの。
テンペスト攻撃
モニタやキーボード、ネットワークケーブルなどから放射されている微弱な電磁波を傍受し解析することで情報を盗み取る攻撃の事。
直行表、All-Pair法（ペアワイズ法）
テストケース作成の手法、例えば、ピザを作るシステムで、ピザの種類、ピザの生地、トッピングの組み合わせを全てテストしたら大変なことになる。
世の中のバグの97%は2因子間の組み合わせまでチェックしておけば防げる。という根拠のもとにテストケースを減らす手法。2因子間の組み合わせを網羅する。
直行表と、All-Pair法の違い：直行表は2因子間の取りえる値の組み合わせが同一回数になるようにする。All－Pair法は2因子間の組み合わせが1回以上あればOKとする。
リバースエンジニアリング
既存のプログラムからそのプログラムの仕様を導き出すこと
RFP（Request For Proposal）
システム導入や、業務委託を行うにあたり、発注先に具体的な提案を依頼する文書。システムの目的や、概要、要件や制約事項が記入される
RFI（Request For Information）
システム導入にあたって、現在の状況において利用可能な技術・製品、導入実績など実現手段に関する情報提供をベンダに依頼する文書
