【合格体験記】CompTIA Project+【用語集付き】

こんにちは。わさおです。CompTIA Project+に合格したので、勉強方法などをシェアしたいと思います。

合格までの流れ

試験時の私の経歴

コンサルティングファームで約6年間、プロジェクトマネジメント業務に従事。知識・経験はそれなりに持っている状態。

勉強時間

2~3時間/日×1週間=約14~20時間程度

勉強方法

① Udemyで模擬問題集を購入し、すべての試験で90%以上取れるまでやりこむ。ここで問題の傾向や日本語の癖などをつかむ。(海外の資格なので日本語がたまに変な部分があるのでそういうのを知っておく)【9時間くらい】

② TACのテキストで概要をつかむ。流し読み程度でOKだが、わからない単語や試験問題でよく間違えるような部分は重点的に読み、用語集を作っておく。【5時間くらい】

③ 試験直前に用語集を読みおさらいする【1時間くらい】※この記事を参考にしてみてください。

試験当日の感想

① 自宅でリモートで受けたのだが、試験官に机のものをすべてしまうように指示があったり、机の上や部屋の中でカメラを映す準備に10分くらいかかった。ヘッドホンやマイクなど問題ないと思っていたが、事前に片付けておかないといけない模様。

② 試験自体は1/3くらいは事前にやっていた模擬問題集とほぼ同じだった。(用語の書き方が若干違ったり、選択肢の順番が違ったりするものもあった)

③ 満点900点、合格点710点に対して、私のスコアは773点(約85%)だった。模擬問題集やっていなかったら不合格になっていたと思うので、対策で一番重要なのは模擬問題集をやりこむことだと感じた。

参考資料

TACテキスト

試験の内容が体系的にまとまっていて良かったです。実務にも使える内容だったので少し高かったですが、購入してよかったと思いました。

0~9

3層アーキテクチャ

ソフトウェアやシステムの設計方法の一つで、それぞれの層が異なる役割を果たすように構成されています。具体的には、以下のような層が存在します: プレゼンテーション層 (Presentation Layer): ユーザーインターフェースを提供し、ユーザーとの対話を担当します。主にユーザーが見たり操作したりする部分を含みます。 アプリケーション層 (Application Layer): ビジネスロジックやアプリケーションの処理を実行します。データの処理や制御フローなどの中核的な機能を持ちます。 データ処理層 (Data Layer): データの保存とアクセスを管理します。データベースやファイルシステムなどのデータの永続性と管理が行われる層です。 このような3つの層によって機能が分割され、各層が独自の役割を果たすことで、柔軟性や保守性の高いシステムを構築することが可能となります。

3点見積もり

楽観値、悲観値、最頻値の3点を考慮して見積もりを行う方法。

95パーセント現象(フェノメノン)

チームが最後の作業を完了できず、プロジェクトを終了することができない状態。

A

AC(Actual Cost)

実際に支出されたコストを指す。

B

BAC(Budget at Completion)

プロジェクトの予算上の総コストを示す指標ですが、プロジェクトの進行状況や実績を反映するものではありません。

C

CI/CDプロセス (Continuous Integration/Continuous Deployment) 

開発プロジェクトで新しいコードを自動的に頻繁に配信する方法。

CPI

EV÷ACの計算式で表すことができる。

E

EAC(Estimate At Completion):完成時総コスト見積り

プロジェクトが完了するまでの総予測コストを示す指標です。プロジェクトの進行状況や実績に基づいて、現時点からプロジェクトの予測コストを再評価するために使用されます。EACは、実績の総コストに未完了の作業の見積もりを加えることで計算されます。

EDRMS

電子文書および記録管理システム。書面の作成、保管、管理、検索、共有などの機能を提供し、内部フローの管理を支援するための効果的なソリューション。

ERP

企業全体のさまざまな部門やプロセスを統合し、ビジネスの効率性と効果性を向上させるために設計されたシステムです。ビジネス取引に関連する情報(販売、購買、在庫管理など)を一元管理し、組織全体での情報の共有と可視性を提供します。ERPシステムは、ビジネスプロセスの自動化、リアルタイムのデータ分析、予測能力などの機能を備えています。

ESG

企業や組織が持続可能な環境、社会的な責任、およびガバナンスの原則に従うことを指す。 コンピュータを不適切に廃棄すると、環境に影響を与える可能性があります。情報の漏洩についてのみではなく、ESG は PII よりも広範囲をカバーする。

ETC(Estimate to Complete)

プロジェクトを完了するために残りの作業にかかる見積もりコストを示す指標ですが、プロジェクトの総コストを正確に見積もるものではありません。

K

KGI(重要目標達成指標)

企業が最終的に目指す数値目標のこと。KGIに紐づく形でKPIが設定される。

KPI (主要業績評価指標)

一般に、これらの指標は、プロジェクトまたは組織の成功に重要な要素を評価するために使用されます。プロジェクト管理では、KPI はプロジェクトが特定の目標を達成しているかどうかを示すツールで構成されます。ベスト プラクティスは、プロジェクトの早い段階で KPI を定義することです。そしてそれらは定量化可能であり、定期的に測定されるべきです。一般的な KPI は、計画されたスケジュールとコストのベースラインに対してプロジェクトがどの程度うまく追跡されているか、およびプロジェクトのマイルストーンが達成されているかどうかに関係します。アメリカ国防総省においてはKPPと呼ばれる

L

LOI(Letter Of Internet)

交渉の過程で合意された事項を箇条書きのような簡単な形式でまとめられたものであり、企業の利益を保護する文書ではありません。

M

MOA

会社の基本規約。合意覚書。

Mou(Memorandum of Understanding)

団体間の合意の枠組みを形式的に文書化したもの。法的強制力はなく、相互の意向や意思の表示を示す文書。顧客とベンダー間でお互いの合意事項を確認するために使われる。成果物に関する規定などは無い

N

NDA(Non-Disclosure Agreement) 

2つ以上の組織が特定の機密情報を相互以外の者と共有することを防止するための合意文書。

P

PERT(プログラム評価レビュー技法)

楽観値、最頻値、悲観値に基づいて、各作業のスケジュールを決定するために使用されるツール。タスクの優先順位付けを行う。

PII(Personally Identitiable Information)

個人を特定できる情報。名前、住所、電話番号、社会保障番号、銀行口座情報など。血液型は含まれない。

PMO

複数のプロジェクトを同時に管理する組織。

R

RACI

キックオフで役割を説明するときにも使われる。RAMの一つ。

RAM(Responsibility Assignment Matrix):責任分担表

プロジェクトの役割と責任を示すための行列であり、各メンバーがプロジェクト内でどのタスクを担当するかを明確にする。キックオフミーティングで議論されたメンバーの役割と責任、タスク、マイルストーン、および主要な決定事項は、RAMによって文書化されるべき。

RFQ(Request For Quotation)

見積もりを依頼するための文書。

ROI

投資利益率。プロジェクトの投資効果を評価するために使用される。

RTM

各要求事項がプロジェクトの完了時点で間違いなく達成されていることを確認するために作成される。

S

SLA(Service Level Agreement)

サービスを提供する事業者が契約者に対し、どの程度のサービス品質を保証するかを提示したもの。納品成果物の品質、納期、サポートレスポンスなども定義する。ベンダーのパフォーマンスを管理出来る。

SMARTの原則

ゴールや目標を明確にする方法。目標設定を行う際には下記の5つに注意する。

 S:Specific = 具体的であること

 M:Measurable = 測定できること

 A:Agreed upon = 同意していること/Attainable = 達成可能であること

 R:Realistic = 現実的であること

 T:Time bound = 期日が明確であること

SOW(作業明細書)

プロジェクトの目的、作業範囲、作業場所、履行期間、成果物のスケジュール、適用基準、承認基準、特別な要件、支払いスケジュール、エンジニアの請求料金など、プロジェクトに関連する重要な情報を文書化したもの。SOWは、プロジェクトのスコープと期間を明確にし、プロジェクトチームがプロジェクトの目標を達成するための指針となる重要な文書。SOWは成果物や約束事項についての情報を提供するわけではない。

SWOT分析

自社の強み、弱み、機会、脅威の4つの視点から分析するもの。プロジェクトの選定に役立つ。

T

TCPI (To-Complete Performance Index)

プロジェクトの残りの作業を完了するために必要な効率を示す指標ですが、直接的に総コストを見積もるものではありません。

W

WBS

「フェーズ」→「成果物」→「成果物作成のための作業」の順で細分化していく。このような考え方を段階的詳細化と呼び、計画の立て方をローリングウエーブ計画法と呼ぶ。

Wikiナレッジベース

情報を集中的に保存し、検索機能を持つツール。ウェブベースで、複数のユーザーが情報を作成、編集、共有することができる。

あ行

アジャイル

アジャイル開発の特徴は自律チーム。自主的な組織なためプロジェクト管理のサポートはほとんど必要無い。

アローダイアグラム法(PERT図)

プロジェクトの各工程にかかる日程を可視化する。

移転

リスクを他の関係者に移管することを意味する。

インシデントレスポンス

インシデント発生後の事後対応のこと。品質監査人がソフトウェアテスト中に不審なコードを発見した場合、これはインシデントレスポンスのトリガーとなる可能性がある。

エスカレーションパス

問題や課題が発生した場合に、適切な管理チームや上位の関係者に報告し、サポートや解決策を求めるための手順やプロセスを文書化したもの。

エピック

バックログアイテムのこと。

オフショア

アウトソーシングの委託先が海外企業のこと。

か行

回帰テスト

変更が加えられた後にアプリケーションをテストして、その変更がコードの古い領域で問題を引き起こしたかどうかを確認するプロセス。

課題ログ

ロジェクトで発生した問題やリスクなどの課題を文書化するためのツールです。プログラミングエラーはプロジェクトの課題と見なされる可能性があります。プロジェクトチームは、プログラミングエラーに関する情報を課題ログに記録し、追跡および解決することが期待されます。

活用

予期せぬ出来事や状況を利用して競争力や成果を向上させるための戦略

期待時間

(楽観値 + (4 x最頻値) +悲観値) ÷ 6

機能型組織

組織ごとに専門性を持った人材が育ちやすい。プロジェクトの独立性は薄くなる。プロジェクトマネージャーの権限も弱い。プロジェクトマネージャーがメンバーを評価し、メンバーの組織の上司に報告する。最終人事評価は組織の上司。

金メッキ

ステークホルダーの期待値を上回るためにスコープ以上の機能を追加する俗語。金メッキが多すぎると結果的にPJに無理が生じ、失敗に終わるため注意が必要。

クオリティゲート

IT におけるマイルストーンであり、品質基準のベンチマークを提供するように設計されている。クオリティゲートを使用すると、プロジェクトが次のフェーズに進む前に、事前に定義された基準を強制的に満たすことができる。

クラッシング

クリティカルパス上のタスクにプロジェクトメンバーを多く投入すること。もしくはスキルの高いメンバーに変更することにより、所要期間の短縮をはかるもの。

計画

ロジェクトの目標、目的、成果物が洗練され、管理可能な作業単位に分割されます。プロジェクト マネージャーは、時間とコストの見積もりを作成し、各アクティビティのリソース要件を決定します。計画には、コミュニケーション、リスク、人事、品質、調達など、プロジェクト管理の他の重要な領域が含まれます。

軽減

リスクを軽減するための戦略。

欠陥ログ

バクの報告、追跡、管理に使われる。

コスト基準

プロジェクトのスコープや目標が明確化され、ステークホルダーとの合意が形成される必要がある。このため、プロジェクト憲章が署名される前の時点が最適。

コストベースライン

週単位や月単位といった時間軸で配分した予算。

コラボレーションサイト

チームメンバーがリアルタイムで情報やファイルを共有し、コミュニケーションを行うためのプラットフォーム。チャット機能、フォーラム、ドキュメント共有、タスク管理など、さまざまなコミュニケーションツールが提供されている。

コントロールチャート(管理図)

プロセスのパフォーマンスを監視し、品質管理のための統計的なツールです。サンプル製品が許容範囲内であるかどうかを判断するためには、コントロールチャートを使用して製品の特定の測定値や指標の変動を追跡する。 コントロールチャートには、上限制約線と下限制約線が設定されており、これらの範囲内で測定値が安定している場合、製品は許容範囲内であると判断できる。一方、制約線を超える変動がある場合、製品は許容範囲外である可能性がある。

コンフリクトマネジメント

コンフリクト(利害衝突)を解消するための管理手法。

さ行

サンクコスト

既に投入されたコストやリソースが追加のコストやリソースを要求せずに捨てられることを指します。この場合、既に予算の一部が使用されているにもかかわらず、まだ完了していない作業パッケージがあるため、サンクコストの発生が示唆されます。

スコープ記述書

PJ計画段階でスコープ記述書が承認されたら、次にプロジェクトマネージャーはWBSを作成する。

スコープクリープ

承認されていない (つまり、合意された範囲を超えて) 新しい製品、要件、または作業の機能を追加することを指します。 上級管理チームの指示に従うことで、そのような事象が発生する可能性が高まります。

スコープ検証

完成した成果物を公式に受け入れるプロセス。

スタンドアップ(デイリースクラム)

プロジェクトチームメンバーが日々の進捗状況、課題、および次のステップについて報告し合うための短い会議。

ステークホルダー分析

ステークホルダーの利害、影響力、関心度(要求)を分析すること。これをマトリクス上に表現することで期待値をコントロールし、プロジェクトマネジメントを円滑に行えるようになる。プロジェクトにネガティブな意見を持つステークスホルダーには特に真摯な対応を心掛ける。

スモークテスト

製品の基本的な機能や主要な機能が正常に動作しているかどうかを確認するために行われる最初のテストです。スモークテストは通常、製品のリリース後すぐに行われ、問題の早期発見と製品の基本的な安定性の確認を目的としています。

前提条件

事前に決めておかなければプロジェクト計画が策定出来なくなってしまう条件。

ソーシャルエンジニアリング

人間の心理的な隙や行動のミスにつけ込み、不正に個人情報や機密情報を入手すること。

た行

対峙

状況や問題に直面し、解決策を見つけるために関係者との対話や議論を行うアプローチ。

妥協

プロジェクトマネージャーが両当事者が最終設計について意見を提供できるようにしていることは、妥協になります。両者が何かを失ったり侵害したりすることは示されておらず、意見の平滑化が求められています。

タスクボード

プロジェクトの進捗状況を視覚的に表示するためのツール。通常はタスクや作業項目がカードやポストイットなどの形式で表示される。

出典『Jira

チームトレーニング

チームがこれまで一緒に仕事をしたことがない場合に必要なステップ。以下を実施する。

・チームメンバーの紹介

・プロジェクトの目的とスコープ

・コミュニケーションのルールとプロセス

・作業の手順とプロセス

チケット駆動開発(TiDD)

各タスクをチケットとして登録し、チケット単位に優先度付けや進捗管理を行う開発手法。

鎮静

プロジェクトの円滑な進行と関係者間の信頼関係を保つために、状況を落ち着かせ感情的な緊張を和らげることが目的。

低減

リスクの可能性や影響を軽減するための措置を講じるリスク管理アプローチ。

ディシジョンツリー

複雑な意思決定プロセスを可視化し、さまざまな選択肢とそれに伴う結果を表すために使用されるツール。

出典『STUDY HACKER

ディフェクトログ

プロジェクトマネージャーや開発チームがソフトウェアのバグや問題を追跡するためのツール

統一期/標準期

チームが互いに適応し、協力して働くことができるようになり、プロジェクトの目標に向けて効果的に作業を進める段階を指す。チームメンバーはお互いに信頼し、協力し、共通の目標に向かって協力して取り組む。

特性要因図

問題や課題の根本原因を特定するために使用される。

な行

ニアショア

アウトソーシングの委託先が国内地方企業のこと。

は行

バーンダウンチャート

残作業を示す日次推移グラフ。

出典『asana

バランススコアカード

企業活動の戦略やビジョンを4つの視点(①財務 ②顧客 ③業務プロセス ④学習と成長)で分類し、それぞれのKPIを定めて評価するもの。

パレート図

問題の優先順位を特定するために使用されるツールの一つです。与えられた表の中で、パレート図を使用すると、製品の表面的および物理的損傷に関連する2つの主要な欠陥のうち、最も重要な欠陥を特定することができます。 パレート図は、問題の頻度や重要度を棒グラフとして表示し、問題のパターンや影響の大きさを視覚的に表現します。これにより、最も頻繁に発生する問題や最も大きな影響を与える問題を優先的に対処することができます。

出典『Backlog

ビジネスケース(プロジェクト企画書)

プロジェクト立上げを検討するための企画書。プロジェクトとして投資するかどうか経営者が判断する材料が記述される。以下の項目が記述される。市場の需要、組織のニーズ、顧客要求、技術進歩、法的要件、生態系の影響、社会的ニーズ。

ヒストグラム

度数分布表をグラフにしたもの。度数分布表とは、データをいくつかの区間(階級)に分け、それぞれの区間に含まれるデータの個数(度数)を表の形式で表したもの。

出典『Office Hack

ファストトラッキング

プロジェクトのスケジュールを短縮するために並行して進行するタスクを増やす手法です。プロジェクトマネージャーは、既存のリソースを最大限に活用するために、タスクの依存関係と優先順位を見直し、複数のタスクを同時に進行させます。これにより、製品の市場投入を競合他社よりも早めることができます。

フィージビリティ・スタディ

プロジェクトが実現可能かどうかを確認するための事前調査のこと。

フォーミング(形式)

チーム開発の段階。プロジェクトマネジャーがチーム構成を決定する。

プレシデンスダイアグラム法

プロジェクトのアクティビティの依存関係に注目し、論理的順序関係を図式化していく技法。

出典『WonderShare

プログラム

複数の関連するプロジェクトを組み合わせ、共通のビジョンや目的を達成するために実施される取り組み。プログラムは複数のプロジェクトを統合し、リソースや成果物の共有、リスク管理、戦略的な調整を行う。組織のポートフォリオに組み込まれることがある。プロジェクトと異なり、開始と終了は定義されていない

プロジェクト

プロジェクトの特性は①有期性、②独自性(ユニーク性)、③明確な目的がある、の3点。役割と責任の明確化がプロジェクト運営の要。プロジェクトマネージャー1人が責任を持つような構造はうまくいかない。責任を分散して当事者意識を持たせることが重要。

プロジェクト型組織

マンネリしにくい。ノウハウがプロジェクトに紐付いてしまい、会社として蓄積しにくい。

プロジェクト完了レポート

プロジェクトの最終段階で作成される文書であり、プロジェクトが成功裏に完了したことを確認し、検証するために使用されます。

プロジェクト憲章

プロジェクトスポンサーやプロジェクトマネージャーが最初に作る必要がある成果物。プロジェクト憲章が承認されることで正式にプロジェクトマネージャに権限が与えられる。プロジェクト憲章はプロジェクト企画書やプロジェクト計画書を使うこともある。プロジェクト開始を正式に認めるドキュメントを作成することが重要。

プロジェクトコーディネーター

プロジェクトマネージャーのサポート役として問題解決や組織単位の調整を行う人。

プロジェクト準備・立ち上げ

プロジェクトの最初のプロセス。以下のようなハイレベルなタスクを行う。

 1.) ビジネスケースの評価/投資判断

 2.) プロジェクトマネージャの選定

 3.) プロジェクト憲章の作成・発行

 4.) ステークホルダーの特定

プロジェクトスケーラー

プロジェクトのスケジュール管理に責任を持つ人。

プロジェクトスケジューラー

プロジェクト スケジュールの作成と維持、タイムラインと期日の伝達、スケジュールのパフォーマンスの報告、およびスケジュールの変更を関係者やプロジェクト チームのメンバーに伝達する責任がある。

プロジェクトスポンサー/プロジェクトオーナー

プロジェクトを擁護する責任が最も大きいのはプロジェクトスポンサーです。プロジェクトスポンサーは、プロジェクトの成功に責任を持ち、プロジェクトのビジネス目標を達成するために必要なリソースとサポートを提供する役割を担っています。新しい方法論の導入を承認する責任があるプロジェクト予算やハイレベルな要求の承認。プロジェクトマネージャの任命、指導などを行う。プロジェクト立ち上げの経緯をプロジェクトマネージャに説明する

プロジェクトポートフォリオ

プログラムマネージャーが優先順位付けを行う際に考慮すべき要素は①会社のビジョン②ミッションステートメントの2点。

プロジェクトの完了条件

プロジェクトの成果物が受け入れられ、導入される基準。受入基準やカットオーバークライテリアなどと呼ばれる。

プロジェクトの三大制約

プロジェクトを制約する時間、コスト、クオリティー間の関係のこと。プロジェクトの三大制約をサポートするために、プロジェクトの最終フェーズで使用する必要があるアクティビティはプロジェクトの評価である

ベースライン

プロジェクトのライフサイクル全体を通じて進捗状況とパフォーマンスを測定するための基準点として機能する、プロジェクト計画の承認済みバージョンです。

変更管理

1. 変更を特定して文書化します。
2. 変更の影響と正当性を評価します。
3. 承認権限を特定し、承認を取得します。
4. 変更を実施します。 また、プロジェクト マネージャーは変更を実装するための計画を作成する必要があります。 これには、プロジェクトの計画、スケジュール、予算、リソースの変更が含まれる場合があります。
5. 変更を検証し、プロジェクトの品質をチェックします。
6. 関連文書を更新し、変更のデプロイの連絡をします。
7. 回帰試験計画を作成します。

変更管理委員会(CCB)

プロジェクトの範囲、スケジュール、予算、またはその他のプロジェクト コンポーネントの変更を検討および承認する責任を負う、指定されたグループまたは委員会です。CCB は、プロジェクトの目的、制約、全体的な管理に対する潜在的な影響に基づいて、変更が評価および承認されることを保証します。この場合、プロジェクト管理計画のタイプミスは文書の変更とみなされます。小さな変更のように見えるかもしれませんが、プロジェクトのドキュメントに対する変更は、一貫性と正確性を維持するために適切な変更管理プロセスを経る必要があります。リソースの制約によりプロジェクトが予定どおりに完了しないことに気づいたときは変更要求を変更管理委員会に提出する。

変更諮問委員会(CAB)

変更管理およびそのプロセスを評価する高度なスキルを持つ代表者チームのこと。

ポートフォリオマネジメント

複数のプロジェクトの収益性を考慮し、利益の最大化を図るマネジメント。

ま行

マイルストーン

・主要イベントのプレースホルダーとみなされる

・所要時間がない

マトリクス型組織

機能型とプロジェクト型の混合型。定常業務をしながらプロジェクト業務をするため、業務負荷が大きくなる。マトリクス型組織ではプロジェクトマネージャーと組織の部門長の両方の指揮系統がある。一方、機能型組織では組織の部門長が優先されるプロジェクトマネージャーと組織の部門長が協力してプロジェクト業務をやる場合はマトリクス型組織。

マネジメントリザーブ

スポンサーが捻出できる予備費。

マルチオーサリングソフトウェア

複数のユーザーが同じドキュメントで同時に作業できるようにするソフトウェアの一種。成果物のバージョン管理の維持などに利用する。Jira、Backlogなどのプロジェクト管理ツールが使われることが多い。

ら行

リアルタイム調査

プロジェクトチームのメンバーに対して即座に質問やフィードバックを求めることができるツール。

リスク登録簿

問題が発生した場合(例:予算の増加リスク発生)にリスク登録簿の更新が必要。リスク登録簿が更新されることによりリスクオーナーに通知される。リスクの説明、影響度、発生確率、対策などが含まれます。

ロールバック計画

変更の実装中に障害や中断が発生した場合に、システムまたはインフラストラクチャを以前の状態に戻す方法を記述したコンティンジェンシー計画のこと。ITインフラストラクチャの変更を実装する場合に必要になる

わ行

ワークパッケージ

WBSの最下層のタスク。単体テスト、結合テストといった粒度感。ワークパッケージよりさらに細かい粒度としてアクティビティ(テストケース作成、テストデータ作成など)がある。アクティビティには順序関係・依存関係(開始-開始、開始-終了)がある。