「.NET 開発基盤部会 Wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。
目次 †
概要 †
- 試験のテクニック類を纏める。
- 知らないと選択肢を絞るのに苦労するというか絞れなくなる。
詳細 †
ITTO †
概要 †
- ITTO
- I : input
- TT : tool & technic
- O : output
TT †
IO †
- プロセスの要素と呼ばれることがある。
- 当該プロセスのインプットである場合、前プロセスのアウトプットとなる。
- 当該プロセスのアウトプットである場合、後プロセスのインプットとなる。
引っ掛け †
- 聞いたことが無い要素が混じっているケース。
（知識不足で聞いたことが無いケースも多いので、模試でカバー）
- コンテキストに沿っていないケース（成否を決定する要素を持っていない）
- TTと見せかけて、プロセス群の中の１マネジメント・プロセス。
- I/O、TT/IOが逆。
- I/Oが逆になっているケース
- TTを問うているのにIやO要素が混じっているケース。
- IOを問うているのにTT要素が混じっているケース。
例えば組織体の環境要因（EEF）に含まれるPMIS。
- 前後のプロセスのITTOを含める。よく引っかかる。
- 当該プロセスのIに、前後のプロセスのIを含める（加工前のIと加工後のI）。
- 当該プロセスのOに、前後のプロセスのOを含める（直接的Oと間接的O）。
- 他のプロセス群や知識エリアのTTの要素へ言及しているケース
（アリがちなのが、当該 知識エリアの前プロセスのTTへ言及しているケース）
- Oの"子要素"を選択肢に含める（前述より更に解り難くなる）。
- 当該プロセスのOの"子要素"に、前後のプロセスのOを含める。
- 当該プロセスのOに、前プロセスのOの"子要素"を含める。
用語の定義 †
- 基本的に用語の定義を覚えていれば回答可能。
- 覚えれば覚える程（、選択肢の除外にも役立ち）、正答率が増す。
モンテカルロ分析 †
モンテカルロ・シミュレーションはスケジュール、コストの"リスク"などで使用される。
- シミュレーションや数値計算を乱数を用いてコストのリスクを決定する手法
- 「入力値をランダムに選び、シミュレーション結果を得る」ということを繰り返す。
- 結果として、想定されるスケジュール、コストの確率分布を表現し、見積りに幅をもたせる。
計算を要するもの †
公式暗記系。
- 分類
- 費用便益分析 : BCR
- キャッシュ・フロー分析
- 回収期間分析
- 正味現在価値（NPV : Net Present Value）
- 内部収益率（IRR : Internal Rate of Return）
- BCR、NPV、IRRともに数字としては大きい方がイイ。
- BCR : 大きい方がイイ（１より大きければ投資
- NPV : 大きい方がイイ（正の値であれば投資
- IRR : 大きい方がイイ
PV, EV, AC, BACが与えられる。
- スケジュール
- SV = EV - PV
- SPI = EV / PV
- コスト
- CV = EV - AC
- CPI = EV / AC
- ETC = (BAC - EV) / CPI
残作業のコスト見積り
- EAC = ETC + AC
完成時総コスト見積り
- TCPI
- = (BAC - EV) / (BAC - AC)
- = (BAC - EV) / (EAC - AC)
- 説明
- EAC : 現在の差異が継続するとみられる場合の将来予測
- TCPI : 現在の予算内で収めるCPI（コスパ）の算出
- パターン
- コスト超過傾向の場合（CPIが1.0を下回る）、
EACが再設定された時のTCPIの算出（1.0を上回る）。
三点見積 †
ベータ分布の分母が6なのは、± 3σ＝6σ なので 6 と覚えたらイイ。
- 平均値
- 最頻値(tM) : 最も可能性が高い
- 楽観値(tO) : 最良のケース
- 悲観値(tP) : 最悪のケース
- 期待値
- 三角分布の期待値 : tE = (tO + tM + tP) / 3
- ベータ分布の期待値（加重平均） : tE = (tO + 4tM + tP) / 6
- ベータ分布の標準偏差 = (tP - tO) / 6
- 標準偏差毎の確率
ベータ分布で、標準偏差毎の確率が決まっている。
- 期待値 ± 1 * 標準偏差（σ） : 68.26%
- 期待値 ± 2 * 標準偏差（σ） : 95.44%
- 期待値 ± 3 * 標準偏差（σ） : 99.73%
- 注意
- 確率を、逆に覚えていたので注意、±1σは99%ではなく68%
- ±ｎσ＝２ｎσなので、１σと２σを間違える可能性がある。
クリティカル・パス法 †
- ラグを予想する変則的な問題
- ラグを含むパスのうち長い方がクリティカル・パス
- このパスを用いて、ラグを予想する。
- 開始日か終了日か
- 終了日：当該アクティビティの終了日
- 開始日：前のアクティビティの終了日（＋ラグ）
- 参加者の数 = 3 経路 = 3 で計算すると公式を思い出し易い。
(n * (n - 1)) / 2
(3 * (3 - 1)) / 2 = 3 * 2 / 2 = 3
- 引っ掛け
- 自分を足し忘れるという「むらの英雄」的な引っ掛けがある。
- 何気に、パスの数ではなく、値の増減を問うているケースがある。
CPXXのフィー計算 †
- CPIF(Incentive fee)のフィー計算
納入者側の共有率がｘ％の時（ショート or オーバーで ± 符号が変わるので注意）
- CPPC, T&M
そもそもフィーに該当するものが無い。
価格 = 実総コスト +（実総コスト * ｘ）
人件費の計算 †
其々の要素を分けて書いて計算する。
- 基本給付額
- 付加給付額
- ボーナス
- オーバーヘッド・コスト
選択肢の絞り込み †
問題からキーワードを拾う †
キーワードを認識しないと間違える。例えば、
- サーヴァント・リーダが答えの問題に、
「自律的」と「支援」のキーワードがあった。
の選択肢から二者択一するのに「支援」が重要になる。
- プロセスを問う問題に、
「計画」と「監視」のキーワードがあった。
の選択肢から二者択一するのに「監視」が重要になる。
「監視」で、再「計画」が行われることがある。
何を問っているか？考える。
- その他
- 一般的過ぎる選択肢ではなく、専門用語（ITTO）を含む選択肢を選択する。
- 正否・可否などの、どちらを問うているか確認する。
統合（知識エリア） †
プロセス群の概要を聞かれた場合は、
特定の知識エリアに絞らないで、
統合知識エリアの内容を回答する。
立上・終結（プロセス群） †
プロジェクトを中断する場合、セーブ・ロード的な意味で、
実施内容 †
- プロセス、プロセス群には色々な実施内容があるが、
出題されて回答するのは、プロセスの主要な目的に対応する実施内容に絞る。
- 例えば、チーム育成は、
協調、士気、活気、結束の向上の効果もあるが、
チームメンバの期待と行動を明確化して生産性を向上させる。
と、広義の「実施内容＋効果」以外を選択肢から除く。
前提条件の追加 †
- 何か最優先の前提条件が追加された場合も、
従来の前提条件が無くなる訳ではない。
タイミング関連 †
倫理・職務規定とも関連が深そう。
- 報告
報告には、精度が必要。
- 精度が低い状態で報告すべきではない。
- 緊急度が低い情報が組織を跨ぐ場合、
先ず、組織内で対応を相談する。
- 対策が先で、原因・影響の調査は、その後。
（例１：スコープ変更 < コスト・スケジュール変更 < トレーニング, etc.）
（例２：コスト・スケジュール影響調査、計画書の修正 < リスク対応策の実行、コンティンジェンシー活用など）
- 対策できないものは、原因・影響の調査。報告は、その後。
- 原因・影響の調査は、より、直接的な不明点（または大きな影響）の調査が先。
（例：見積精度の、不明点＝見積根拠、原因追求＝相見積もり）。
- 通報
報告とは、また異なる。
- 通報の前に、理由・背景を知る。
- 通報の前に、諭告、通告、警告を行う。
- 契約
- 支払停止 < 債務不履行文書（履行強制、損害賠償請求、契約解除） < 解決策を探る。
- 訴訟・提訴 < 裁判外紛争解決手続（ADR）< 紛争 < 和解交渉
- 最初のインプット ≠ 重視するインプット
- 監視・制御のプロセス群
- 最初のインプット：作業パフォーマンス・データ
- 重視するインプット：作業パフォーマンス情報
- 知識エリア
- 統合
- ステークホルダー
ステークホルダー関与度評価の後、
値の増減 †
- 値を増減させて変更した場合、
- 変えた後の値ではなく、増減を問うているコトがある。
原因の説明 †
原因を説明するPMBOK用語を選択する。
xV < 0 & yPI > 1 †
xVとyPIを不等号を変えて問う変則技
- [x = s, y = c] or [x = c, y = s].
- 不等号を x と y の式で変える。
似たような言葉 †
検査 ≠ 査定、監査 †
- 検査 ≠ 査定
- 検査：各種、評価を行って、数値の算出を行う。
- 査定：検査の結果を分析して取り調べて金額・等級などを決める。
- 中古車の車両検査（= 検査 + 査定）で言うと、
XXX憲章 †
- プロジェクト憲章（立上）
憲章が承認されればプロジェクトは組織内で支持を得る（≒ 横串）。
- チーム憲章（計画）
- チームの価値観、合意、ガイドラインなどを示す。
（グローバル化による多国籍化で重要性が増している。）
- キックオフとともに、チーム育成に重要になる。
憲章と計画書 †
- プロジェクト・マネジメント計画書
- ≒ プロジェクトと機能の格子点の計画（分担とスケジュール等）
- ∴ 計画が承認されればプロジェクトは機能部門からも支持を得る。
ビジネス目標、プロジェクト目標 †
利益測定
XXX SOW †
契約作業範囲記述書（SOW: Statement of Work）
XXX Breakdown Structure †
WBS : Work Breakdown Structure
ワーク・ブレークダウンストラクチャ / 作業分解図 / 作業分割構成 / 作業の詳細構造
- PBS : Product Breakdown Structure
- プロダクト・ブレークダウン・ストラクチャ / 製品分割構成
- WBSとマトリクス状に交差させて、セルに成果物を配置（作業と成果物）
- RBS : Resource Breakdown Structure
- リソース・ブレークダウン・ストラクチャ
- WBSとマトリクス状に交差させて、コストを配置（作業とリソース）
- CBS : Cost Breakdown Structure
- コスト・ブレークダウン・ストラクチャ / 原価要素体系 / 費用区分構成
- WBSとマトリクス状に交差させて、コストを配置（作業とコスト）
- OBS : Organization Breakdown Structure
- 組織ブレークダウン・ストラクチャ / 組織分割構成
- WBSとマトリクス状に交差させて、セルにワークパッケージ（CA）を配置（作業と組織）
- RBS : Risk Breakdown Structure
- リクス・ブレークダウン・ストラクチャ
- WBSとマトリクス状に交差させて、セルにリスクを配置（作業とリスク）
- EV
実際の出来高（スケジュール的な意味での進捗）
- 比率であるため、
- トレンド（傾向変動）を示す。
- 従って、傾向分析に使用できる。
- 特定期間の測定値が継続的に続く。
と予想される場合、長期で利用できる。
SEAM, RAM, RACI †
- SEAM : ステークホルダー関与度評価マトリックス
- RAM, RACI
- RAM : 責任分担マトリクス
- RACI : RACIマトリクス
- RACI-VS（VARISC）
- CAIRO（RACIO）
- RASCI
- （別の）RACI
XXXログ、XXX登録簿 †
- 課題ログ
- 課題マネジメント（課題のトラッキング）
- 実行、監視・制御プロセス群のアウトプット
- 変更ログ
- 主に、変更管理での変更を記録する。
- 変更管理以外の更新版発生時の変更も記録する。
XXXシステム †
- コンフィギュレーション・マネジメント・システムは情報システムではなく仕組み。
品質系 †
PMP：品質マネジメント
- 品質マネジメント計画のツールと技法。
- 品質マネジメント計画だけではなくコスト見積のツールと技法でもある。
- コストが解らないと計画が立たない
- 意思決定には、費用便益分析を使用する。
- 起源
おっさんの名前を覚える。
- (c) クロスビー（フィリップ・B・クロスビー
- (j) ジュラン（ジョセフ・M・ジュラン
- (d) デミング（W・エドワーズ・デミング
- (s) シューハート（ウォルター・A・シューハート
- 全社的品質管理 : Total Quality Control（TQC）
- 総合的品質管理 : Total Quality Management（TQM）
- 統計的品質管理 : Statistical Quality Control（SQC）
- シックスシグマ（米モトローラが開発、 6σ（通常は、3σ））
- カイゼン（継続的改善、QCサークル、第一が人々の質、第二が成果物）
- 能力成熟度モデル統合（CMMI、5つの発達段階）
- 品質工学（TM：タグチメソッド）
- サンプリング
- 計数サンプリング
- 計量サンプリング
- 統計的サンプリング
用語 †
- 品質尺度
- 品質と等級
- 使用適合性
- 品質(信頼性/安全性/使い勝手/機能展開/サービス)
プロジェクトの †
プロジェクトの開始の判断材料となる文書は？ †
プロジェクトの中止の判断材料となる文書は？ †
プロジェクトの終結後もステーク・ホルダーに参照される文書は？ †
プロジェクト・マネジメント・ビジネス文書 > プロジェクト・ベネフィット・マネジメント計画書
プロジェクトの成功と失敗の判断材料は？ †
プロジェクト目標の達成の度合い。
その他 †
法則系 †
- 工数
- パーキンソンの法則
仕事の量は、与えられた時間を使い果たすまで膨張する（バッファは埋まる）。
- ホフスタッターの法則
作業にはいつも予測以上の時間がかかる（見えていないものがあるから。この逆は少ない。）
- ブルックスの法則
遅延に要員追加で対応すると、コミュニケーション・パス増加で更に遅延を生む。
- 原因・結果
- パレートの法則
多くの現象では、結果の80%は原因の20%で決まっている。
- 働きアリの法則と同じ意味合いで使用される。
- 組織全体の2割程の要人が大部分の利益をもたらしており、
要人が間引かれると、残りの中の2割がまた大部分の利益をもたらす
- スタージョンの法則
- どんなものも、その90％はカスである。
- 90%のSF作品をゴミカス扱いするのと同じ基準を用いれば、
映画、文学、消費材などその他あらゆるものの90%も同様にゴミである。
- マーフィーの法則
うまくいかなくなる可能性のあるものは何でも、うまくいかなくなる。
- 多くはユーモアの類で笑えるもの
- 認知バイアスのサンプルとして捉えることが可能なものも少数ある。
- 組織
- ピーターの法則
組織において、すべての従業員は無能のレベルまで昇進する傾向にある。
- 能力主義の階層社会では、人間は能力の極限まで出世する。
- 有能な平構成員は、無能な中間管理職になる。
- 各階層は、無能な人間で埋め尽くされる。
- 組織の仕事は、まだ出世の余地のある人間によって遂行される。
- コンウェイの法則
ソフトウェアのどの部分であれ、それを作った組織の構造を反映する。
- 例えば、
開発するチームを5つに分けて進めた場合、
ソフトウェアの構造も大きく5つに分かれる。
- コンパイラを4つのグループで作れば、4パス・コンパイラになる。
（パスとはメモリ要件で、コンパイル処理 → 中間生成物を分けた層）
- リーナスの法則
目玉の数さえ十分あれば、どんなバグも深刻ではない。
- ヴィルトの法則
ソフトウェアは、ハードウェアが高速化するより急速に低速化する。
- ザウィンスキーの法則
あらゆるプログラムは、それがメールを読めるところまで拡張しようとする。
そこまで拡張できないプログラムは、それができるものにとってかわられる。
- ポステルの法則
送信するものに関しては厳密に、受信するものに関しては寛容に。
- インターネットの通信を貫く大原則である
- RFC 793 "be conservative in what you do, be liberal in what you accept from others."
- ハードウェア
- ムーアの法則
集積回路におけるトランジスタの集積密度は、約18ヶ月ごとに倍になる。
- ロックの法則
マイクロプロセッサ製作にかかるコストは、4年ごとに2倍になる。
- ネットワーク
- リードの法則
大きなネットワークの有用性は、
特にソーシャルネットワークの場合、
ネットワークの大きさとともに指数関数的に増加する。
- メトカーフの法則
ネットワーク理論において、システムの価値は
そのシステムのユーザ数の二乗近くに比例する。
監査 †
監査は、複数のプロセス群にある。
※ 何故か、パフォーマンス測定ベースライン（PMB）に関係が無い部分のみ。
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
