PM
(ぴーえむ)プロジェクトマネージャーの略。プロジェクトの目的、範囲、進捗、課題、リスク、関係者との合意を管理し、プロジェクトを前に進める役割。作業を自分でこなすのではなく、プロジェクト全体を見渡すことが求められる。
プロジェクトマネジメント、PMO、生成AI、ITエンジニア向けビジネススキルに関する用語を、初学者にもわかりやすく整理しました。ロードマップや講座を学ぶ前に、気になる用語を確認できます。
SEARCH
キーワード・カテゴリ・難易度・役割で絞り込めます。
全50件中 50件を表示中
CATEGORY JUMP
GLOSSARY
条件に一致する用語がありません。
キーワードやカテゴリを変更して再検索してください。
プロジェクトマネジメントを学ぶ前に押さえたい基本用語です。
プロジェクトマネージャーの略。プロジェクトの目的、範囲、進捗、課題、リスク、関係者との合意を管理し、プロジェクトを前に進める役割。作業を自分でこなすのではなく、プロジェクト全体を見渡すことが求められる。
プロジェクトリーダー、またはチームリーダーの略。開発チームや特定領域をリードし、PMと連携しながら実行を支える役割。技術的なリードとメンバーのタスク管理を担い、PMへのステップとして位置づけられることが多い。
プロジェクトマネジメントオフィスの略。複数案件の状況を見える化し、標準化、レポーティング、リスク検知、PM支援を行う役割または組織。個別プロジェクトの推進責任を持つPMとは異なり、横断的な管理・支援が主な役割。
Quality(品質)、Cost(コスト)、Delivery(納期)の頭文字。プロジェクト管理における基本の3要素。この3つはトレードオフの関係にあり、1つを優先すると他に影響が出ることがある。PM・PLが常に意識すべき観点。
プロジェクトで実施する範囲、または成果物の範囲。何をやるか、何をやらないかを明確にすることがプロジェクト管理の出発点。スコープが曖昧なまま進むとスコープクリープ(範囲の無制限拡大)が起きやすい。
Work Breakdown Structureの略。プロジェクト作業を分解し、作業単位や担当、期限を整理するための構造。「誰が何をいつまでに行うか」を整理する基本ツール。WBSが曖昧だと進捗確認や課題管理も機能しなくなる。
プロジェクト上の重要な節目。設計完了、開発完了、テスト開始、リリースなどの判断ポイントになる。マイルストーンに向けてタスクを逆算で管理することが重要で、単なる「予定日」ではなく「完了条件つきの節目」として設定する。
プロジェクトに関係する人や組織。顧客、上司、利用者、開発チーム、外部ベンダーなどが含まれる。誰がステークホルダーかを最初に整理することがPMの重要な仕事。ステークホルダーの期待と影響度を把握しておくことで、調整・説明の優先順位が明確になる。
プロジェクトの状態を把握し、問題を早期に見つけるための用語です。
計画と実績を比較し、遅延や未完了作業を早期に把握する管理活動。進捗率だけでなく、完了条件・未解決課題・残作業量を確認することが重要。「90%完了」のまま止まるケースに注意が必要。
すでに発生している問題を整理し、対応方針、担当者、期限を決めて解決へ進める活動。「リスク管理」とは異なり、すでに顕在化している問題を扱う。課題を放置すると炎上の原因になるため、早期の記録と対応が重要。
今後発生する可能性がある問題を事前に洗い出し、発生確率や影響度を踏まえて対策する活動。「課題管理」と明確に区別することが重要。影響度×発生確率でリスクの優先度を整理し、未然に手を打つことが目的。
自分やチームだけでは判断・解決が難しい問題を、上位者や関係者へ引き上げて対応を求めること。エスカレーションを遅らせることで問題が拡大するケースが多い。「報告したら負け」ではなく、積極的に行うべき行動。
プロジェクトの進捗、課題、リスク、今後の予定を整理した報告資料。単なる状況説明ではなく「判断材料の提供」が目的。読む人が何を決めればよいかわかる形にすることが重要。
遅れた作業やプロジェクトを立て直すために、原因、影響、対応策、再計画を整理すること。楽観的な見通しで「頑張る」だけでは解決しない。根本原因を特定し、現実的な計画に修正することが重要。
遅延、品質問題、顧客不信、課題放置などにより、プロジェクト運営が危険な状態になっている案件。炎上の兆候を早期に察知し、初動で適切な対応を取ることが重要。初動を誤ると信頼回復がより困難になる。
進捗、課題、リスク、品質、体制、顧客対応などの観点から、プロジェクトの健全性を確認すること。問題が深刻化する前に定期的に確認することで、炎上を予防できる。PMOが横断的に実施することも多い。
何を作るか、どこまで作るかを整理するための用語です。
システムやサービスで実現すべき内容を、顧客や利用者と確認し、要件として整理する工程。「何を作るか」の合意を取るフェーズ。要件定義の曖昧さが後工程での手戻りや炎上の主要原因となるため、合意と記録が重要。
システムや業務に求められる条件や機能。何を満たす必要があるかを示す。機能要件(何をするか)と非機能要件(性能・セキュリティ・可用性など)に分けて整理することが一般的。
要件を実現するための具体的な設計内容や動作条件。「何をするか」という要件に対して「どのように実現するか」を定義したもの。仕様の合意が曖昧だと「言った・言わない」のトラブルにつながる。
合意済みの作業範囲や成果物の内容を変更すること。納期、工数、品質に影響するため管理が必要。変更を「断る」のではなく、「影響(工数・コスト・納期)を明確にして合意する」ことが目的。無管理な変更は炎上の一因になる。
仕様変更や追加要望を受ける際に、影響範囲、工数、リスク、合意内容を整理して管理すること。変更を受け入れるかどうかより、受け入れた際の影響を明確にして関係者で合意することが重要。
プロジェクトで作成・納品するもの。システム、設計書、テスト結果、マニュアルなどが含まれる。何が成果物で、誰が確認し、どの時点で完了とするかを最初に合意しておくことがトラブル防止の基本。
顧客、上司、チームと認識を揃えるための用語です。
関係者の認識や期待を揃え、方針や対応について納得した状態を作ること。口頭だけでなく、議事録や確認書面で記録することが重要。「言った・言わない」のトラブルを防ぎ、次の行動につなげるための基本。
プロジェクトの状況、課題、リスク、対応方針を顧客にわかりやすく説明すること。事実・影響・対応策・次のアクションをセットで伝えることが重要。「大丈夫です」だけでは信頼回復につながらない。
会議で話した内容、決定事項、TODO、担当者、期限を記録した文書。「何が決まったか」「誰が何をするか」が明確な議事録が次の行動につながる。情報共有だけの議事録ではプロジェクトは動かない。
会議や報告の後に実行すべき具体的な作業。担当者と期限を明確にすることが重要。「確認する」「検討する」などの曖昧な記録ではなく、「誰が、何を、いつまでに」の形で記録することで確実に前に進む。
いつ、誰が、どのような前提で、何を決めたかを記録したもの。後から「なぜそう決めたのか」を確認できるようにするためのドキュメント。炎上時や顧客トラブル時に根拠として活用できる。
報告、連絡、相談の略。仕事を進めるうえで必要な基本的コミュニケーション。PMやPLは「相談を受けやすい雰囲気」を作ることも重要。問題が起きたときに早く相談できる関係が、炎上を防ぐ。
成果物の品質を守り、問題の再発を防ぐための用語です。
成果物が求められる品質を満たしているかを確認し、問題を防止・改善する活動。QA(品質保証:仕組みづくり)とQC(品質管理:実際のチェック活動)に分けて考えることが多い。早期のレビューとテストが品質確保の基本。
設計書、コード、資料などを確認し、誤りや不足、改善点を見つける活動。設計レビュー、コードレビュー、議事録レビューなどがある。「早いレビュー=早い問題発見」が品質管理の基本原則。後工程での手戻りを防ぐ。
システムや機能が期待通りに動作するかを確認する活動。単体テスト、結合テスト、システムテスト、受入テストなどのフェーズがある。テスト計画を早期に立て、テスト結果を進捗・品質の指標として管理することが重要。
システムや成果物が期待通りに動作しない状態、または要求を満たしていない状態。優先度なしに全件一律対応しようとすると重要な問題の対応が遅れる。重要度と緊急度でトリアージ(優先度付け)することが重要。
発生した問題が再び起きないよう、原因を分析し、仕組みや運用を改善すること。「反省して気をつける」だけでは再発防止にならない。原因の根本を特定し、プロセスや仕組みで防ぐ視点が重要。
複数案件や組織全体のプロジェクト管理を支える用語です。
プロジェクト管理の方法、フォーマット、会議体、報告内容などを揃え、ばらつきを減らすこと。複数のプロジェクトで使う手順・ツールを統一することで品質の均一化と知識共有を促進する。PMOの主要な役割の一つ。
関係者や管理職に向けて、状況、課題、リスク、判断事項を整理して報告すること。PMOが複数プロジェクトの状況を経営層・管理職に届けることが多い。「情報を集める」のではなく、「判断に使える形で届ける」ことが重要。
複数のプロジェクトを横断して、進捗、課題、リスク、体制、品質を把握する管理方法。個別プロジェクト担当者では見えにくい横断的な問題を早期に検知し、組織全体のプロジェクト品質を高める。
複数の情報を一覧できるようにまとめた画面や資料。進捗、課題、リスクなどを可視化するために使う。PMOが複数案件の状況を管理職・経営層に伝える手段としても活用される。「見ればわかる」形にすることが重要。
組織として定めたプロジェクト管理のルールやテンプレート。WBSテンプレート、課題管理票、リスク管理票、ステータスレポートフォーマットなどが含まれる。標準化された雛形があることでPM個人の負荷を下げ、品質を均一化できる。
ChatGPT、Claude、Geminiなどを業務で使うための基本用語です。
文章、画像、コード、要約、アイデアなどを生成できるAI。PM業務では情報整理や文書作成の補助に使える。ChatGPT、Claude、Gemini、Copilotなどが代表例。出力をそのまま使うのではなく、人間が確認・修正することが前提。
OpenAIが提供する生成AIチャットサービス。文章作成、要約、壁打ち、プロンプト実行などに使える。GPT-4oなど複数のモデルが提供されている。PM業務では報告文作成・課題整理・議事録作成・メール文案などに活用できる。
Anthropicが提供する生成AIサービス。長文読解、文章作成、要約、構造化された出力などに使われる。安全性・論理的な文章生成に定評がある。Claude Codeはエンジニアリング・業務自動化に特化したバージョン。
Googleが提供する生成AIサービス。文章生成、要約、情報整理などに使われる。Google WorkspaceやGoogle Searchとの統合が進んでおり、業務効率化に活用できる。
AnthropicのClaudeを活用したコーディング支援ツール。コード修正だけでなく、ドキュメント整理や開発作業の補助にも使える。テックエイドのAI Toolkitでも活用されている。
生成AIに対して入力する指示文。目的、前提、出力形式を明確にすると、より使いやすい回答を得やすい。役割・前提・指示・制約・出力形式を含めることが良いプロンプトの基本。PM業務では実務シーンに合わせたテンプレートが有効。
PM業務で使えるAI Contexts、Prompt Template、Claude Code Skillsなどをまとめた無料リソース。テックエイドが提供し、GitHub上で公開されている。AIを使い始める際の実務参考資料として活用できる。
AIに役割、前提、制約、出力形式などを伝えるための文脈情報。プロジェクトや業務の背景をAIに伝えることで、より適切な出力を得やすくなる。テックエイドのAI Toolkitで複数のAI Contextを公開している。
顧客名、個人名、契約情報、認証情報などを伏せたり置き換えたりして、機密情報を入力しないようにする処理。AIに業務情報を入力する前に必ず行うべきセキュリティ対応。「〇〇社」→「顧客A」のように置き換えるだけでも有効。
ITエンジニアが報告、相談、資料作成、顧客対応で使う用語です。
報告、相談、会議、資料作成、顧客対応など、仕事を進めるために必要な非技術的スキル。ITエンジニアやPMがキャリアアップするうえで、技術スキルと並んで重要とされる。「コミュニケーション力」「論理的思考力」「文書作成力」などが含まれる。
相手に伝える目的で、情報、論点、結論、比較、判断材料を整理して文書やスライドにまとめること。「作るための資料」ではなく「読む人が判断できる資料」を目指すことが重要。AIを使って構成案や文章のたたき台を作ることもできる。
何を判断すべきか、何が問題なのか、どの選択肢があるのかを整理すること。会議や報告の前に論点を整理することで、議論が本筋からずれず、意思決定が速くなる。AIを使って「論点整理のたたき台」を作ることも有効。
関連リソース
現在の立場や課題に合わせて、学ぶ順番を確認できます。
PMに必要なスキル全体像を確認できます。
進捗報告、課題管理、顧客説明などに使えるプロンプトを探せます。
PM業務で使えるAI Contexts、Prompt Template、Claude Code Skillsをまとめています。
PM、AI活用、ビジネススキル、炎上対応などの講座を確認できます。
対象講座で使える講師クーポンを確認できます。
NEXT STEP
用語を単独で覚えるだけでは、実務で使える知識にはなりにくいです。関連するロードマップや講座を使って、どの順番で学ぶかを確認しましょう。