トップページ – ソフトウェア系

龜D/a製作所

PMBOKガイド第6版

10の知識エリア

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

品質マネジメント計画，品質保証，品質コントロールの三つのプロセスで構成されている。

品質マネジメント計画プロセスのアウトプット

品質保証プロセスのアウトプット

品質コントロールプロセスのアウトプット

組織のプロセス資産（Organizational Process Assets）

PMBOK®ガイドでは、組織のプロセス資産を大きく二つに分類しています。

変更要求

PMBOKガイド第5版によれば、変更要求とは「文書、プロジェクトのベースライン、成果物、またはこれらの組合せに対する修正が必要になる変更を行わせる正式な要求」のことです。

是正処置
予期される将来のパフォーマンスをプロジェクト計画書に沿ったものとするための活動。ベースラインからの差異を許容範囲内に収めるように処置すること。
例：あるタスクが，プロジェクトマネジメント計画書に記載したスケジュールから遅れたので，遅れを解消させるために要員を追加する。
予防処置
プロジェクトリスクによって好ましくない結果が発生する確率を低減するための活動。ベースラインの許容範囲から逸脱しないように処置すること。
欠陥修正
プロジェクトやプロダクトとの構成要素の欠陥を修正する活動。
更新
ステークホルダー等からの改善要求。

好機への戦略

●プロジェクト・リスク・マネジメント - 定性的リスク分析

PMBOKのリスクマネジメントでは，定性的リスク分析でリスク対応計画の優先順位を設定し，定量的リスク分析で数値によるリスクの等級付けを行う。

●プロジェクト調達マネジメント

調達作業範囲記述書・・・プロジェクトが提供するプロダクトやサービスを記述した文書となります。
各作業の要求事項、作成すべき成果物、作業への対価などを記述します。
外部調達先への依頼したり調達先選定時に評価したりする際に、調達作業範囲記述書を作成します。

https://www.pm-siken.com/kakomon/30_haru/am2_15.html

プロジェクト・スコープ・マネジメント - ローリングウェーブ計画法

WBSを作成する際、最下位レベルまで詳細化するのは直近に実施される作業のみとし、将来実施される部分については上位レベルまでに留めておくというように段階的に詳細化していく手法。

統合変更管理プロセス - コンフィギュレーション・マネージメント

コンフィギュレーション・マネジメントは、構成管理とも呼ばれ、変更に係る次の作業を実施する活動です。

資源平準化

資源の制約に基づき、資源の配分を最適化するためにアクティビティの開始日と終了日を調整する技法。共有される若しくは重要な資源が特定の期間や限られた量だけしか使えなかったり、人員などの共有資源が同時に実行される2つ以上のアクティビティに割り当てられた場合などに行われる。クリティカル・パスを変更する原因となることが多い。

フリーフロート

後続アクティビティの最早開始日を遅らせることなく当該アクティビティを遅らせることのできる期間。

トータルフロート

プロジェクト全体の余裕期間。

プロジェクトの品質コスト（COQ）

品質コストは、製品やサービスの品質に関わる作業の総費用で、 適合コストと不適合コストに分類されます。

適合コスト
製品やサービスを品質要求に合致させるために要する費用。 さらに予防コストと評価コストに大別される。
[予防コスト]
レビュー費、品質計画費、品質教育費、設備保全費など、品質不良を発生させないための予防活動に伴うコスト
[評価コスト]
受入れ検査費、出荷前検査費、品質監査費など、品質を評価し不良品を選別するための活動に伴うコスト
不適合コスト
発見された不良品に対処するために要する費用。さらに内部不良コストと外部不良コストに大別される。
[内部不良コスト]
手直し費、補修費、廃棄費など、出荷前に発見された不良品に伴い発生するコスト
[外部不良コスト]
クレーム対応費、修繕費、損害賠償費、製品回収費など、出荷後に発見された不良品に伴い発生するコスト

アーンド・バリュー評価基準

PMBOKでは、「アーンド・バリュー評価基準」という呼び方で、WBS要素作業の進捗基準が記載されています。

アジャイルソフトウェア開発宣言

「アジャイルソフトウェア開発宣言」は、従来型のソフトウェア開発の
やり方とは異なる手法を実践していた17名のソフトウェア開発者が、
それぞれの主義や手法についての議論を行い、 2001年に
公開されました。そこには、彼らがソフトウェア開発を行ううえで
重視している「マインドセット」が書かれていました。
その後、このマインドセットは、世界中のソフトウェア開発者達に支持され、
”アジャイルソフトウェア開発” という名で世に広まりました。

アジャイルソフトウェア開発宣言の読みとき方

カウボーイコーディング

カウボーイコーディングは、各々の開発者が「自分が良いと思うプログラミング」をバラバラに行うこと。
職人的な個人技に依存するカウボーイコーディングには、明確な手法が欠如している。
カウボーイコーディングで開発を行うチームのメンバーは、自分たちがそれぞれ正しいと感じた作業を行う。
すなわち「開発メンバーのそれぞれが、正しいと思うやり方でバラバラに開発すること」を指す。非常に俗人性が高く、明確な手法が欠如した、開発プロセスとは呼べないやり方。
エース級開発者が他の開発者の作業がもどかしくて全部自分でやろうとしたり、メンバー間の仲が悪くてコミュニケーション不足になるとしばしばカウボーイコーディングが始まりますので気をつけましょう。

クリティカルチェーン・プロジェクトマネジメント（CCPM）

作業工程の従属関係とリソースの従属関係の両方を考慮に入れて、作業所要期間を決めている最も長い作業の流れのことをクリティカルチェーンと呼ぶ。

プロジェクトバッファ

バッファを各作業工程（タスク）毎には管理せず、プロジェクト全体で管理するもの。ネットワーク図の上ではクリティカルパスの後ろに置く。

合流バッファ

クリティカルパス以外のタスクで、クリティカルパスに合流するタスクの完了時期に持たせる。

IFPUG法(International Function Point Users Group)

IFPUG機能規模測定手法。 JIS X 0142：2010として標準化されている。

データファンクション
アプリケーション境界の内部又は外部のデータに対する利用者要件を満たす機能。データファンクションには，ILF及びEIFがある。

内部論理ファイル（ILF）
アプリケーション境界内にあるデータのまとまり。
外部インタフェースファイル（EIF）
アプリケーション境界外にあるデータのまとまり。

トランザクションファンクション
データを処理するためにアプリケーションが利用者に提供する機能。トランザクション ファンクションには，EI，EO及びEQがある。

外部入力（EI）
アプリケーション境界外からデータを受け取り、内部論理ファイルを変更したり、システムの動作を変える処理を行う。
外部出力（EO）
アプリケーション境界外にデータを計算等によって加工して提供する処理。システムの動作を変える処理を含む場合もある。
外部照会（EQ）
アプリケーション境界外にデータを提供する処理。データの加工やシステムの動作を変える処理は行わない。
パーキンソンの法則

英国の歴史学者・政治学者パーキンソンの著作『パーキンソンの法則：進歩の追求』で提唱された法則。

ブルックスの法則

IBMの開発者であるフレデリック・ブルックスが著作「人月の神話」で提唱した。
「遅れているソフトウェアプロジェクトへの要員追加はさらに遅延を発生させるだけだ」

ユースケース駆動開発(UCDD)

ユースケース駆動開発とは、システムの機能を利用者から見たシステムの振る舞いを記述したもの（ユースケース）に分割し、それを基に要求分析から実装までの工程を進めていく開発手法。

ユースケース駆動開発は以下の4つで構成されます。

分析、設計、実装、テストの各工程の成果物がユースケースごとに作成されますから、要件ごとの開発状況を把握することが可能となります。

テスト駆動開発（Test-Driven Development、TDD）

はじめにテストコードを書いてからプログラムを実装する開発方法。エクストリームプログラミング(XP:eXtreme Programming)のプラクティスのうちの1つ。

リーンソフトウェア開発

トヨタ生産方式（TPS）を参考に考案された開発手法のひとつ。

JIS Q 21500:2018(プロジェクトマネジメントの手引)

3 プロジェクトマネジメントの概念

3.6 プロジェクトガバナンス

ガバナンスは，組織を指揮し，管理する枠組みである。
プロジェクトガバナンスは，プロジェクト活動に明確に関連する組織ガバナンスの分野を含むものであるが，これに限定されない。
プロジェクトガバナンスは，次のような対象を含むことがある。
− マネジメント構造の定義
− 使用する方針，プロセス及び方法論
− 意思決定の権限の範囲
− ステークホルダの責任及び説明義務
− 報告，課題及びリスクの上層管理者への嘆願などの相互作用
一般に，プロジェクトの適切なガバナンスを維持する責任は，
プロジェクトスポンサ※1又はプロジェクト運営委員会※2に対して割り当てられる。
※1プロジェクトスポンサ・・・プロジェクトの目的及び便益に責任を負う
※2プロジェクト運営委員会・・・上級経営レベルでの指導をする

相互作用するプロセス群

管理プロセス群を除き，様々なプロセス群間の相互作用は，
各プロセス群内の個々のプロセスを通じて行われる。
図6には，管理プロセス群とほかのプロセス群とのつながりを示しているが，
管理プロセス群のプロセスは，プロジェクト全体だけでなく，
個々のプロセス群を管理するために使用するため，
管理プロセス群は自立したものとみなしてもよい。

プロジェクト憲章の作成

プロジェクト憲章を作成する目的は，次の点にある。

プロジェクト憲章は，プロジェクトを組織の目的に関連付けるものであり，あらゆる適切な委任事項，
義務，前提及び制約を明らかにすることが望ましい。

表2−プロジェクト憲章の作成：主要なインプット及びアウトプット

主要なインプット 主要なアウトプット
− プロジェクト作業規定書
− 契約
− ビジネスケース又は以前のフェーズの文書 		− プロジェクト憲章

計画のプロセス群

4.3.3 プロジェクト全体計画の作成

4.3.11 スコープの定義

スコープの定義の目的は，プロジェクトの最終状態を定義することによって，
目標，成果物，要求事項及び境界を含むプロジェクト・スコープの明確さを
達成することである。
プロジェクト・スコープの定義は，プロジェクトが組織の目的に
どのように寄与するかを明らかにすることである。
プロジェクト・スコープ規定書は，将来のプロジェクトの決定，
並びにプロジェクトの重要性及びプロジェクトを遂行して成功させたときに
現実化する便益を伝達するためのベースとして使用することが望ましい。

主要なインプット 主要なアウトプット
− プロジェクト憲章
− 承認された変更		 − スコープ規定書
− 要求事項

4.3.12 WBSの作成

4.3.13 活動の定義

4.3.16 資源の見積り

4.3.17 プロジェクト組織の定義

4.3.21 活動の順序付け

4.3.22 活動期間の見積り

4.3.23 スケジュールの作成

4.3.25 コストの見積り

4.3.26 予算の作成

4.3.28 リスクの特定

4.3.29 リスクの評価

4.3.32 品質の計画

4.3.35 調達の計画

4.3.38 コミュニケーションの計画

対象群：コミュニケーション

コミュニケーションの計画の目的は，プロジェクトのステークホルダの情報及び
コミュニケーションのニーズを決定することである。 プロジェクトは，プロジェクトの情報を伝達する必要性があるが，
情報のニーズ及び配布の方法は多様である。プロジェクト成功の要因には，
ステークホルダの情報のニーズ及び全ての法令要求に従った情報のニーズを特定すること
並びにそのニーズを満たすための適切な手段の明確化を含んでいる。
地理的に分散した要員，多様な文化などの要因，及び組織的要因は，
コミュニケーション要求事項に重要な影響を及ぼすことがある。
このプロセスは，プロジェクトの計画の早い時期に始め，ステークホルダの特定及び分析に続いて，
定期的にレビューし，必要に応じて改訂し，プロジェクトを通じて継続的な有効性を確保することが望ましい。
コミュニケーションの計画は，情報に関する要求事項を定め，
そして適正なステークホルダによってこれをプロジェクトを通じて容易に入手できるようにすることが望ましい。

実行のプロセス群

4.3.4 プロジェクト作業の指揮

対象群：統合

プロジェクト作業の指揮の目的は，承認されたプロジェクト成果物を提供するために，
プロジェクト全体計画に定義した作業の遂行をマネジメントすることである。

管理のプロセス群

4.3.5 プロジェクト作業の管理

対象群：統合

プロジェクト作業の管理の目的は，プロジェクト全体計画に従って，
統合的な方法でプロジェクト活動を完了することである。
このプロセスは，プロジェクトを通じて遂行することが望ましく，
パフォーマンスを測定すること，プロセス改善に影響することがある測定値及び傾向を評価すること
並びにパフォーマンスを改善するためにプロセス変更を引き起こすことを含む。

主要なインプット 主要なアウトプット
− プロジェクト計画
− 進捗データ
− 品質管理測定値
− リスク登録簿
− 懸案事項ログ 		− 変更要求
− 進捗報告書
− プロジェクト完了報告書

4.3.6 変更の管理

対象群：統合

4.3.14 スコープの管理

対象群：スコープ

主要なインプット 主要なアウトプット
− 進捗データ
− スコープ規定書
− WBS
− 活動リスト		 − 変更要求

4.3.19 資源の管理

対象群：資源

資源の管理の目的は，プロジェクトの要求事項を満たすように
資源をプロジェクト作業の実施に必要な資源を確保し，
必要な方法で配分することである。
資源の利用可能性の矛盾は，機器の故障，天候，労働不安，技術的問題など，
不可避の環境に起因して発生することがある。このような環境では，
現状又は次の活動のための資源の要求事項が変わることによって
活動の再スケジューリングを要求することがある。このような不足を特定し，
資源の再配分を容易にする手順を確定しておくことが望ましい。

主要なインプット 主要なアウトプット
− プロジェクト計画
− スタッフ配置
− 資源の利用可能性
− 進捗データ
− 資源要求事項 		− 変更要求
− 是正処置

4.3.20 プロジェクトチームのマネジメント

対象群：資源

4.3.24 スケジュールの管理

対象群：時間

主要なインプット 主要なアウトプット
− スケジュール
− 進捗データ
− プロジェクト計画 		− 変更要求
− 是正処置

4.3.27 コストの管理

4.3.31 リスクの管理

4.3.34 品質管理の遂行

4.3.37 調達の運営管理

4.3.40 コミュニケーションのマネジメント

RACIチャート

タックマンモデル

成立期(Forming)
チーム形成の初期段階。メンバー同士がお互いのことを知らず、様子を見ている。
動乱期(Storming)
チームの行動が開始される段階。意見の食い違いや人間関係についてメンバー間の対立が生まれる。
安定期(Norming)
チーム内での個々の立場が安定し、メンバーの共通目標であるプロジェクトの成功に向けて集中する段階。
遂行期(Performing)
チームとして成熟した段階。メンバー同士の信頼性が高くなり、チームとして機能することで生産性が高まる。
解散期(Adjourning)
目的を達成し、プロジェクトから離れる。

カークパトリックモデル

カークパトリックの4段階評価とは、反応、学習、行動、成果の4段階で教育や研修の効果を測定するモデル。

レベル 定義 測定内容と項目
1 Reactions：反応 研修後のアンケートで受講者の反応をみることで、受講者の理解度・満足度を測定する。
2 Learning：学習 研修で学習した内容について、理解度テストや検定試験、実技試験で習得度合いを測定する。
3 Behavior：行動 研修後に日常業務でどのような行動変容が現われたかを評価するもので、受講者へのヒアリングや仕事への取り組み方など、職場で観察可能なものは上司や部下が評価する。
4 Results：結果 その研修を実施したことで、どれだけ売上を上げたのか、利益を得たかをみる。「営業担当者研修」であれば売上実績や新規開拓件数、「製造担当者研修」であれば、コストダウンや生産性向上などを測定する。結果が出るまでに時間のかかる効果ではなく、効果が出るまでのプロセスを見る指標を測定するとよい。

cookieを使ったシングルサインオン

マッシュアップ

他サイトで公開されているWebサービスのAPIを組み合わせて一つの新しいWebサービスのように機能させることをいいます。公開されているWebサービスには多岐にわたり、代表的なもので「Google Map」「Yahoo!オークション」「AmazonWebサービス」「Twitter」などがあります。

共通脆弱性評価システム CVSS （ Common Vulnerability Scoring System)

CVSS は、情報システムの脆弱性に対するオープンで汎用的な評価手法であり、ベンダーに依存しない共通の評価方法を提供しています。

CVSSでは次の3つの基準で脆弱性を評価します。

SOA(Service Oriented Architecture)

機能の変更や拡張をサービス(機能)単位でのフレキシブルなシステムの組み換えを可能とし、業務環境の変化に柔軟に対応することを目標としているため、個々のサービスが部品として独立し、サービス間の関係が疎結合(分離している)であることが重要

データ管理者（DA:Data Administrator）

業務の実世界から概念設計、システム化の範囲で論理設計などデータそのものの管理を行う。

データベース管理者（DBA:DataBase Administrator）

DAが設計した論理データモデルから物理設計を行い、データベースを構築したり、構築後のデータベースの運用設計および運用保守などデータベースの管理を行う。

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

<企業・団体等が組織活動のために、施設とその環境を総合的に企画、管理、活用する経営活動/p>

デザイン思考

顧客のニーズを出発点として、顧客が本当に欲する製品やサービスを企画・設計することを目的とします。

ベロシティ

「実計測に基づいた一定の時間内における作業量」、すなわちチームが1回のイテレーションで完了させたユーザーストーリーのストーリーポイントの合計値を示します。

コンティンジェンシー予備

プロジェクトで設けられる資金、期間のうちあらかじめ特定されたリスクが発生した場合に対処するために見積もられた予備の資金や期間のことです。 PMBOK（プロジェクトマネジメント知識体系）ではコンティンジェンシー予備はコストやスケジュールなどのベースラインに含まれており、予備を利用するときはプロジェクトマネージャーの裁量で使用することができる。 また。コンティンジェンシー予備のほかに、事前に特定ができない不測の事態が発生した場合に備えるための予備の資金や期間をマネジメント予備と言い、こちらはプロジェクトの総予算に含まれ使用する場合はプロジェクトマネージャーはプロジェクトスポンサーに承諾を得える必要があり、承諾を得た場合に使用することができます。

全体の生産性

https://www.pm-siken.com/kakomon/04_aki/am2_11.html

工程別の生産性が次のとおりのとき，全体の生産性を表す式はどれか。
〔工程別の生産性〕
　設計工程：Xステップ／人月
　製造工程：Yステップ／人月
　試験工程：Zステップ／人月

ア \( X+Y+Z \)
イ \( \frac{X+Y+Z}{3} \)
ウ \( \frac{1}{X} + \frac{1}{Y} + \frac{1}{Z} \)
エ \( \frac{1}{ \frac{1}{X} + \frac{1}{Y} + \frac{1}{Z} } \)

Mathjaxの解説pdf

解説

全体の生産性についてわかりやすいように、具体的な値を設定して考えてみましょう。

[開発規模]
20kステップ
[生産性]
設計工程：4kステップ／人月
製造工程：2kステップ／人月
試験工程：4kステップ／人月

この条件の下では、作業全体が完了するまでに

の工数が必要であることになります。
これらをすべて足すと作業全体の工数は「5人月＋10人月＋5人月＝20人月」です。
20kステップを完了するために20人月を要するので、この例の場合、
全体としての生産性は1kステップ／人月ということになります。

JIS X 25010:2013(システム及びソフトウェア製品の品質要求及び評価(SQuaRE)

信頼性（reliability）

明示された時間帯で，明示された条件下に，
システム，製品又は構成要素が明示された機能を実行する度合い。
品質副特性として、成熟性、可用性、障害許容性（耐故障性）、回復性をもつ。

成熟性（maturity）

信頼性の品質副特性その1。
通常の運用操作の下で，システム，製品又は構成要素が信頼性に対するニーズに合致している度合い。 注記 成熟性の概念は，通常の運用操作の下で要求されたニーズに成熟性以外の品質特性が合致している度合いを示すために成熟性以外の品質特性に適用することもできる。

可用性（availability）

信頼性の品質副特性その2。
使用することを要求されたとき，システム，製品又は構成要素が
運用操作可能及びアクセス可能な度合い。
外面的には，可用性は，システム，製品又は構成要素が作動状態でいる間の
合計時間の割合で総合評価することができる。
それゆえ，可用性は，（故障の頻度を左右する）成熟度，障害許容性（耐故障性）
及び（各故障後の停止時間を左右する）回復性との組合せである。

障害許容性（耐故障性）（fault tolerance）

信頼性の品質副特性その3。
ハードウェア又はソフトウェア障害にもかかわらず，
システム，製品又は構成要素が意図したように運用操作できる度合い。

回復性（recoverability）

信頼性の品質副特性その4。
中断時又は故障時に，製品又はシステムが直接的に影響を受けたデータを回復し
システムを希望する状態に復元することができる度合い。
故障に伴い，コンピュータシステムが一定の時間停止することが時々あるが，
そのシステムの回復性によって，停止時間は決まる。

非機能要件 - 使用性(usability)

明示された利用状況において，有効性，効率性及び満足性をもって明示された目標を達成するために
明示された利用者が製品又はシステムを利用することができる度合い。
以下の副特性をもつ。

利用時の品質モデル

共通フレーム2013

共通フレームとは、情報処理推進機構（ IPA ）によって制定されている「ITシステム開発の作業規定」であり、ITシステムにかかわるすべての関係者にとっての共通言語となることを目指したものです。

  1. 合意プロセス
  2. テクニカルプロセス
  3. 運用・サービスプロセス
  4. 支援プロセス
  5. プロジェクトプロセス
  6. 組織のプロジェクトイネーブリングプロセス
  7. プロセスビュー
  8. 修整プロセス

システム適格性確認テストプロセスは，各システム要件について，実装の適合性がテストされ，システムの納入準備ができていることを確実にすることを目的とする。

ソフトウェアの品質特性モデル JIS X 0129-1(ISO/IEC9126)

保守性

修正のしやすさに関するソフトウェア製品の能力。修正は，是正若しは向上，又は環境の変化，要求仕様の変更及び機能仕様の変更にソフトウェアを適応させることを含めてもよい。

ITIL 2011 edition

ITIL 2011 editionでは、ITサービスの主要な活動を以下の５つの段階にまとめています。

インシデント及びサービス要求管理

　 プロセス内容 概要
1 インシデントの識別と記録 サポートデスクの連絡を元にインシデントレコードを起票する。インシデントの対応に必要な情報を収集・整理する。
2 インシデントの分類 インシデントを分類し、カテゴリ、緊急度、影響度、優先度を設定し、初期サポートを行う。
3 インシデントの調査と診断 初期サポートで解決できないインシデントをエスカレーションし、専門家による高度な分析を行う。
4 インシデントの解決と復旧 専門家が提示した解決策を実行し、復旧する。
9 インシデントのクローズ 利用者が満足すれば、解決済みとし、インシデントをクローズする。

できなかった問題

https://www.pm-siken.com/kakomon/30_haru/am2_24.html
https://www.pm-siken.com/kakomon/30_haru/am2_19.html
https://www.pm-siken.com/kakomon/29_haru/am2_19.html
https://www.pm-siken.com/kakomon/29_haru/am2_23.html
https://www.pm-siken.com/kakomon/29_haru/am2_24.html
https://www.pm-siken.com/kakomon/27_haru/am2_20.html
https://www.pm-siken.com/kakomon/27_haru/am2_21.html