PM・AI・IT用語辞典

プロジェクトマネージャーの略。プロジェクトの目的、範囲、進捗、課題、リスク、関係者との合意を管理し、プロジェクトを前に進める役割。作業を自分でこなすのではなく、プロジェクト全体を見渡すことが求められる。

プロジェクトリーダー、またはチームリーダーの略。開発チームや特定領域をリードし、PMと連携しながら実行を支える役割。技術的なリードとメンバーのタスク管理を担い、PMへのステップとして位置づけられることが多い。

プロジェクトマネジメントオフィスの略。複数案件の状況を見える化し、標準化、レポーティング、リスク検知、PM支援を行う役割または組織。個別プロジェクトの推進責任を持つPMとは異なり、横断的な管理・支援が主な役割。

Quality（品質）、Cost（コスト）、Delivery（納期）の頭文字。プロジェクト管理における基本の3要素。この3つはトレードオフの関係にあり、1つを優先すると他に影響が出ることがある。PM・PLが常に意識すべき観点。

プロジェクトで実施する範囲、または成果物の範囲。何をやるか、何をやらないかを明確にすることがプロジェクト管理の出発点。スコープが曖昧なまま進むとスコープクリープ（範囲の無制限拡大）が起きやすい。

Work Breakdown Structureの略。プロジェクト作業を分解し、作業単位や担当、期限を整理するための構造。「誰が何をいつまでに行うか」を整理する基本ツール。WBSが曖昧だと進捗確認や課題管理も機能しなくなる。

プロジェクト上の重要な節目。設計完了、開発完了、テスト開始、リリースなどの判断ポイントになる。マイルストーンに向けてタスクを逆算で管理することが重要で、単なる「予定日」ではなく「完了条件つきの節目」として設定する。

プロジェクトに関係する人や組織。顧客、上司、利用者、開発チーム、外部ベンダーなどが含まれる。誰がステークホルダーかを最初に整理することがPMの重要な仕事。ステークホルダーの期待と影響度を把握しておくことで、調整・説明の優先順位が明確になる。

計画と実績を比較し、遅延や未完了作業を早期に把握する管理活動。進捗率だけでなく、完了条件・未解決課題・残作業量を確認することが重要。「90%完了」のまま止まるケースに注意が必要。

すでに発生している問題を整理し、対応方針、担当者、期限を決めて解決へ進める活動。「リスク管理」とは異なり、すでに顕在化している問題を扱う。課題を放置すると炎上の原因になるため、早期の記録と対応が重要。

今後発生する可能性がある問題を事前に洗い出し、発生確率や影響度を踏まえて対策する活動。「課題管理」と明確に区別することが重要。影響度×発生確率でリスクの優先度を整理し、未然に手を打つことが目的。

自分やチームだけでは判断・解決が難しい問題を、上位者や関係者へ引き上げて対応を求めること。エスカレーションを遅らせることで問題が拡大するケースが多い。「報告したら負け」ではなく、積極的に行うべき行動。

プロジェクトの進捗、課題、リスク、今後の予定を整理した報告資料。単なる状況説明ではなく「判断材料の提供」が目的。読む人が何を決めればよいかわかる形にすることが重要。

遅れた作業やプロジェクトを立て直すために、原因、影響、対応策、再計画を整理すること。楽観的な見通しで「頑張る」だけでは解決しない。根本原因を特定し、現実的な計画に修正することが重要。

遅延、品質問題、顧客不信、課題放置などにより、プロジェクト運営が危険な状態になっている案件。炎上の兆候を早期に察知し、初動で適切な対応を取ることが重要。初動を誤ると信頼回復がより困難になる。

進捗、課題、リスク、品質、体制、顧客対応などの観点から、プロジェクトの健全性を確認すること。問題が深刻化する前に定期的に確認することで、炎上を予防できる。PMOが横断的に実施することも多い。

プロジェクト完了までに必ず通らなければならない、最も時間のかかる作業経路。この経路上のタスクが1日遅れると、プロジェクト全体の納期も1日遅れる。PM・PLがスケジュール管理において最優先で監視し、遅延の予兆があれば即対応すべきポイント。

スケジュールや見積もりに意図的に持たせた余裕時間。リスクや予期せぬ作業増に備えるための緩衝材。全タスクをバッファゼロで組むと、一つの遅延が連鎖してプロジェクト全体が炎上しやすい。プロジェクト後半のためにバッファを意図的に確保することが重要。

遅延や品質問題が発生した際に、プロジェクトをどう立て直すかをまとめた計画。問題の原因・影響範囲・挽回策・追加リソース・修正スケジュールなどを含む。炎上プロジェクトでは「状況把握→リカバリープラン作成→関係者合意」が初動の基本となる。

システムやサービスで実現すべき内容を、顧客や利用者と確認し、要件として整理する工程。「何を作るか」の合意を取るフェーズ。要件定義の曖昧さが後工程での手戻りや炎上の主要原因となるため、合意と記録が重要。

システムや業務に求められる条件や機能。何を満たす必要があるかを示す。機能要件（何をするか）と非機能要件（性能・セキュリティ・可用性など）に分けて整理することが一般的。

要件を実現するための具体的な設計内容や動作条件。「何をするか」という要件に対して「どのように実現するか」を定義したもの。仕様の合意が曖昧だと「言った・言わない」のトラブルにつながる。

合意済みの作業範囲や成果物の内容を変更すること。納期、工数、品質に影響するため管理が必要。変更を「断る」のではなく、「影響（工数・コスト・納期）を明確にして合意する」ことが目的。無管理な変更は炎上の一因になる。

仕様変更や追加要望を受ける際に、影響範囲、工数、リスク、合意内容を整理して管理すること。変更を受け入れるかどうかより、受け入れた際の影響を明確にして関係者で合意することが重要。

プロジェクトで作成・納品するもの。システム、設計書、テスト結果、マニュアルなどが含まれる。何が成果物で、誰が確認し、どの時点で完了とするかを最初に合意しておくことがトラブル防止の基本。

システムが「何をするか」を定めた要件。画面の操作内容、処理の流れ、入出力の仕様などが含まれる。非機能要件（性能・セキュリティなど）と区別して整理することで、開発・テストの見落としを防ぐことができる。要件定義の核心となる部分。

システムが「どのように動くか」を定めた要件。性能（応答速度）、可用性（稼働率）、セキュリティ、保守性などが含まれる。機能要件と比べて見落とされやすく、後から発覚すると設計変更が大きくなる。プロジェクト初期に確認・合意しておくことが重要。

成果物を顧客が受け入れ（検収）するために満たすべき条件。「何を満たせば完了か」を事前に合意しておくことで、テストフェーズでの認識違いや検収トラブルを防ぐことができる。ユーザーストーリーとセットで定義・管理されることが多い。

「誰が、何を、なぜするか」を短文で表した要件記述形式。「○○ユーザーとして、△△できる、なぜなら□□だから」の形式が基本。アジャイル開発で広く使われ、開発チームが実装の目的を共有しやすくなる。受け入れ条件とセットで管理すると効果的。

合意済みの仕様や計画を変更するための正式な申請。口頭や非公式なルートで仕様変更を受け入れると、スコープが膨らみ（スコープクリープ）納期遅延につながる。変更は必ず影響（工数・コスト・納期・品質）を見積もって承認を得るプロセスを通すことが重要。

Request for Proposalの略。発注者が複数のベンダーに対して提案を募るための文書。システム要件、予算感、スケジュール、評価基準などが記載される。PMはRFPを正確に読み解き、提案・見積もりの前提条件と認識ズレがないかを確認することが重要。

既製品のシステム（パッケージソフト）の機能と、実際の業務要件を比較する分析手法。「Fit」はそのまま使える箇所、「Gap」はカスタマイズや追加開発が必要な箇所を指す。ERP導入や基幹システム更新プロジェクトで必須の分析であり、コストと工数の見積もり精度に直結する。

関係者の認識や期待を揃え、方針や対応について納得した状態を作ること。口頭だけでなく、議事録や確認書面で記録することが重要。「言った・言わない」のトラブルを防ぎ、次の行動につなげるための基本。

プロジェクトの状況、課題、リスク、対応方針を顧客にわかりやすく説明すること。事実・影響・対応策・次のアクションをセットで伝えることが重要。「大丈夫です」だけでは信頼回復につながらない。

会議で話した内容、決定事項、TODO、担当者、期限を記録した文書。「何が決まったか」「誰が何をするか」が明確な議事録が次の行動につながる。情報共有だけの議事録ではプロジェクトは動かない。

会議や報告の後に実行すべき具体的な作業。担当者と期限を明確にすることが重要。「確認する」「検討する」などの曖昧な記録ではなく、「誰が、何を、いつまでに」の形で記録することで確実に前に進む。

いつ、誰が、どのような前提で、何を決めたかを記録したもの。後から「なぜそう決めたのか」を確認できるようにするためのドキュメント。炎上時や顧客トラブル時に根拠として活用できる。

報告、連絡、相談の略。仕事を進めるうえで必要な基本的コミュニケーション。PMやPLは「相談を受けやすい雰囲気」を作ることも重要。問題が起きたときに早く相談できる関係が、炎上を防ぐ。

関係者間で「同じ理解・前提・認識を共有している状態」にすること。言葉の定義、期待する成果、役割分担などを明示的に確認する。認識ズレが発覚するのが後になるほど修正コストは上がる。プロジェクト序盤のキックオフ時に徹底することが炎上防止の第一歩。

顧客が持つ要求や期待を、実現可能な内容に交渉・調整する顧客対応スキル。「できない」をはっきり伝えたうえで代替案を提示し、顧客の納得を得ることが重要。放置すると納品時の「こんなはずじゃなかった」というトラブルに直結する、顧客折衝の核心的な実務能力。

会議後に作成した議事録を参加者間で確認し、記載内容の誤りや抜け漏れを修正するプロセス。決定事項と未決事項の認識を揃えるために必須の手順。送付後に「内容に誤りがあれば〇日以内に連絡ください」と依頼することで、認識ズレを防ぐエビデンスとして機能する。

プロジェクトに影響を与える、または影響を受ける人物・組織を洗い出し、その関与度・影響力・関心を整理する分析。誰に何をいつ伝えるかのコミュニケーション計画を立てる基盤となる。プロジェクト初期にPMが実施すべき作業の一つで、抵抗勢力の早期把握にも役立つ。

複数の関係者が折り合いのつく合意に向けて交渉するスキル。一方的な主張ではなく、相手の事情や優先事項を理解したうえで代替案を提示することが重要。PL・PMはベンダーや顧客との仕様調整・工数交渉・スケジュール調整でこのスキルを日常的に使う。

成果物が求められる品質を満たしているかを確認し、問題を防止・改善する活動。QA（品質保証：仕組みづくり）とQC（品質管理：実際のチェック活動）に分けて考えることが多い。早期のレビューとテストが品質確保の基本。

設計書、コード、資料などを確認し、誤りや不足、改善点を見つける活動。設計レビュー、コードレビュー、議事録レビューなどがある。「早いレビュー＝早い問題発見」が品質管理の基本原則。後工程での手戻りを防ぐ。

システムや機能が期待通りに動作するかを確認する活動。単体テスト、結合テスト、システムテスト、受入テストなどのフェーズがある。テスト計画を早期に立て、テスト結果を進捗・品質の指標として管理することが重要。

システムや成果物が期待通りに動作しない状態、または要求を満たしていない状態。優先度なしに全件一律対応しようとすると重要な問題の対応が遅れる。重要度と緊急度でトリアージ（優先度付け）することが重要。

発生した問題が再び起きないよう、原因を分析し、仕組みや運用を改善すること。「反省して気をつける」だけでは再発防止にならない。原因の根本を特定し、プロセスや仕組みで防ぐ視点が重要。

レビューを実施する際に「何を確認するか」を整理したチェック視点。動作確認だけでなく、要件との整合性・保守性・セキュリティリスク・ユーザー影響など多面的な観点を持つことで見落としを減らせる。レビュー品質はレビュー観点の質で決まるといっても過言ではない。

次のフェーズへ進む前に品質基準を満たしているかを確認する通過判定の仕組み。設計→開発→テスト→リリースなどの各フェーズの入口に設けることで、品質問題を後工程に持ち込まないようにする。PMOが品質ゲートの基準設定と判定を管理することが多い。

プログラムのコードの誤りや欠陥のこと。意図しない動作・計算誤り・処理の抜けなどが含まれる。「不具合」が動作の問題全般を指すのに対し、バグはコード上の誤りを指す。テストで検出し、修正後に確認テスト（リグレッションテスト）で解消を確認するのが基本手順。

修正や改修により、それまで正常に動作していた機能が壊れてしまう現象。デグレとも呼ばれる。修正後にリグレッションテスト（既存機能の再確認）を行うことで防ぐことができる。プロジェクト終盤での発生はスケジュールに大きな影響を与えるため、リリース前の確認が特に重要。

問題の根本原因を探るために「なぜ」を繰り返す分析手法。「なぜ遅延した？→なぜ見積もりが甘かった？→なぜ前提確認が不足していた？」のように掘り下げる。表面的な対策に留まらず真因に対処することで、再発防止策の効果を高めることができる。

テストケース数を機能規模（ステップ数や画面数など）で割った比率。テストが十分に実施されているかを判断する品質指標の一つ。「テストを実施した」だけでなく「どれだけ網羅できているか」を数値で把握することで、PMやPMOが品質状況を客観的に評価できる。

テストの目的・範囲・手法・スケジュール・担当者・合格基準などを定めた文書。場当たり的にテストを進めず、戦略的に管理するために必要。開発初期段階から作成し、要件定義の段階で受け入れ条件と紐づけて定義することが品質確保の理想的なアプローチ。

プロジェクト管理の方法、フォーマット、会議体、報告内容などを揃え、ばらつきを減らすこと。複数のプロジェクトで使う手順・ツールを統一することで品質の均一化と知識共有を促進する。PMOの主要な役割の一つ。

関係者や管理職に向けて、状況、課題、リスク、判断事項を整理して報告すること。PMOが複数プロジェクトの状況を経営層・管理職に届けることが多い。「情報を集める」のではなく、「判断に使える形で届ける」ことが重要。

複数のプロジェクトを横断して、進捗、課題、リスク、体制、品質を把握する管理方法。個別プロジェクト担当者では見えにくい横断的な問題を早期に検知し、組織全体のプロジェクト品質を高める。

複数の情報を一覧できるようにまとめた画面や資料。進捗、課題、リスクなどを可視化するために使う。PMOが複数案件の状況を管理職・経営層に伝える手段としても活用される。「見ればわかる」形にすることが重要。

組織として定めたプロジェクト管理のルールやテンプレート。WBSテンプレート、課題管理票、リスク管理票、ステータスレポートフォーマットなどが含まれる。標準化された雛形があることでPM個人の負荷を下げ、品質を均一化できる。

組織で同時並行して進む複数のプロジェクト全体を、戦略目標との整合性・リソース配分・優先順位の観点で管理する仕組み。個別プロジェクトの集合体を俯瞰的に見ることで、全社レベルでの投資判断やリソースの最適配分が可能になる。PMOが担う高度な管理機能の一つ。

プロジェクトマネジメントのスキルや経験を持つ人材を計画的に育てる取り組み。OJTだけでなく、ロードマップ整備・メンタリング・研修・振り返り支援などを組み合わせることが効果的。PMOが組織としてPM育成の仕組みを整備・推進する役割を担うことが増えている。

進行中のプロジェクトが定められた標準・プロセス・計画通りに運営されているかを第三者が確認する活動。問題を早期発見して改善を促すことが目的。PMOや外部専門家が実施することが多く、炎上プロジェクトの健全化や再発防止にも活用される。

プロジェクトの重要な意思決定を行うための上位委員会。発注者・経営者・部門長などが参加し、方針決定・予算承認・課題解決の判断を行う。PMはステコミに向けて課題・リスク・判断依頼事項を整理してエスカレーションする役割を担う。

Key Performance Indicatorの略。目標達成に向けた進捗を測る主要指標。プロジェクト管理では「課題解決率」「テスト消化率」「バグ検出数」などが使われる。PMOが複数プロジェクトのKPIを集計・比較することで、組織全体の状況把握と早期異常検知が可能になる。

Earned Value Managementの略。計画コスト・実コスト・完了した成果の価値の3軸でプロジェクトの進捗とコスト効率を定量的に測る手法。「進捗65%なのにコストは80%消化」という状況を数値で可視化できる。PMP試験でも必須の管理手法として知られる。

プロジェクトや業務で得た知識・教訓・ベストプラクティスを組織全体で共有・活用できる仕組みをつくること。個人の経験に留めず再利用可能なナレッジとして蓄積することで、組織全体の能力向上につながる。PMOが推進役となり、生成AIを活用して検索しやすい形で整備することも有効。

組織やプロジェクトを適切に管理・監督するための仕組みや規則。意思決定の権限・説明責任の所在・承認プロセスなどを明確にすることで、リスクを防ぎ信頼性を高める。AIガバナンスのように特定領域への適用も拡大しており、PMOが担う管理の核心となる概念。

文章、画像、コード、要約、アイデアなどを生成できる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」のように置き換えるだけでも有効。

Large Language Modelの略。大量のテキストデータで学習した大規模な言語モデル。ChatGPT・Claude・Geminiなどの生成AIの基盤技術。文章生成・要約・翻訳・コード生成などが可能で、PM業務では文書作成・情報整理・壁打ちなどの補助に広く活用できる。

Retrieval-Augmented Generationの略。AIが回答を生成する際に、外部の文書やデータベースを参照して精度を高める手法。社内ドキュメントや過去のプロジェクト情報をAIに読み込ませて活用するシステム構築に使われる。精度の高い業務AIを実現するための中心的な技術。

目標が与えられると自律的に計画・実行・検索・ツール使用などを繰り返して作業を完了するAIシステム。単なる質問応答AIと異なり、複数ステップを自分で組み立てて動く。PM業務の自動化や定型作業の代替として注目されており、Claude Codeなどがその代表例。

生成AIが事実と異なる情報を、あたかも正しいかのように出力する現象。AI特有のリスクの一つ。PM業務でAIを活用する際は出力をそのまま信用せず、重要な情報は必ず一次情報で確認することが前提となる。「AIを使うなら検証セット」として覚えておくべき概念。

生成AIの動作ルール・役割・制約・出力形式などを事前に設定する指示文。ユーザーが都度入力するプロンプトとは異なり、会話全体の前提として機能する。業務用AIツールやチャットボット開発で使われ、AIの応答品質を安定させるために不可欠な設定。

AIへの指示文に、期待する出力例を2〜5個程度含めることでAIの精度を高めるプロンプト手法。「このような形式で出力してほしい」という例を示すことで、AIの出力を望ましい形式に近づけることができる。プロンプトエンジニアリングの基本技法の一つ。

LLMがテキストを処理する際の単位。単語や文字の一部に相当する。モデルが一度に処理できるトークン数（コンテキストウィンドウ）は有限で、長い資料をAIに渡す際にはトークン制限に注意が必要。APIコストもトークン数で決まるため、コスト管理の観点でも重要な概念。

AIを安全・公平・透明に活用するためのルール・体制・プロセスの整備。組織としてAI利用ポリシーを定め、情報漏洩・バイアス・誤利用などのリスクを管理する。AIの業務活用が進む中でPMやPMOが押さえておくべき組織的課題となっており、ガバナンス不在のAI導入はリスクにつながる。

生成AIから望ましい出力を得るためにプロンプトを設計・改善するスキル。役割・前提・出力形式・制約を明確にし、Few-shotや思考連鎖（CoT）などの手法を活用する。特別なプログラミング知識がなくてもAIの出力精度を向上させられる実践的スキルとして注目されている。

LLMが一度の会話で参照できるテキストの最大長。トークン数で表される。コンテキストウィンドウが大きいほど、長い議事録や仕様書をそのまま渡して処理できる。業務でAIを使う際に「長すぎてうまく処理できない」という問題の理解に必要な概念で、モデル選定の重要な指標でもある。

報告、相談、会議、資料作成、顧客対応など、仕事を進めるために必要な非技術的スキル。ITエンジニアやPMがキャリアアップするうえで、技術スキルと並んで重要とされる。「コミュニケーション力」「論理的思考力」「文書作成力」などが含まれる。

相手に伝える目的で、情報、論点、結論、比較、判断材料を整理して文書やスライドにまとめること。「作るための資料」ではなく「読む人が判断できる資料」を目指すことが重要。AIを使って構成案や文章のたたき台を作ることもできる。

何を判断すべきか、何が問題なのか、どの選択肢があるのかを整理すること。会議や報告の前に論点を整理することで、議論が本筋からずれず、意思決定が速くなる。AIを使って「論点整理のたたき台」を作ることも有効。

物事を筋道立てて考え、根拠のある結論を導くための思考技法。「なぜそう言えるのか」「他の可能性はないか」を意識して整理する。PM・PLが顧客への説明・提案書作成・課題解決の場面で日常的に活用するスキルで、ITエンジニアのキャリアアップにも直結する。

Mutually Exclusive, Collectively Exhaustiveの略。「重複なく、漏れなく」情報を整理する考え方。問題分析や報告書作成で視点の重複や抜け漏れを防ぐために使う。ロジカルシンキングの基本ツールとして、PM・ITコンサルタントがよく活用する。

情報が不完全な段階でも最善の仮説を立てて行動し、検証しながら精度を高めるアプローチ。「全部調べてから動く」のではなく「仮説→検証→修正」を繰り返す。PMがスケジュールや見積もりを作る際にも、仮説ベースで早期に動いて関係者と擦り合わせることが重要。

会議やワークショップで参加者の発言を引き出し、議論を整理・誘導して目的に到達させるスキル。主役は参加者であり、ファシリテーターは場をコントロールする役割。PMが主催するキックオフ・課題解決会議・ワークショップなどで不可欠なスキルとして位置づけられる。

上司と部下、またはPMとメンバーが1対1で行う定期的な対話の場。業務の進捗確認だけでなく、課題の壁打ち・キャリア相談・メンタル確認など多目的に使われる。信頼関係の構築とプロジェクトの早期課題発見に効果的で、週次・隔週での実施が一般的。

プロジェクト内外の関係者・上位者・チームメンバーが持つ「こうなるはず」という見込みを、事前に言語化して共有する汎用的なコミュニケーション技術。顧客だけでなく社内・上司・開発チームとの間でも行う。ギャップを早期に埋めることで手戻りや摩擦を減らす。

報告書や提案書の冒頭に置く「全体の要約」。忙しい経営者や管理職が本文を読まなくても意思決定に必要な情報が得られるよう設計する。「結論→理由→詳細」の順で書くことが基本で、AIを使って下書きを作ることも有効なアプローチ。

行動・成果・資料などに対して改善を目的とした意見を返すこと。「ダメ出し」ではなく「より良くするための情報提供」という認識が重要。PMは上位者・顧客・チームメンバーからフィードバックを受け取り主体的に改善する姿勢が求められる。1on1や定期レビューの場で行うことが多い。

スライドや資料を使って情報・主張・提案を聴衆に伝える行為。スライドの見やすさよりも「伝わる構成」が重要。導入（目的）→本題（論点・根拠）→まとめ（結論・次のアクション）の流れを意識することで説得力が増す。AIを使って構成案や話し言葉の文案を作ることも有効。

会議の進行計画や議題リスト。「何を、何のために、何分で話すか」を事前に参加者に共有することで会議が脱線しにくくなる。PMが主催する会議では必ずアジェンダを準備し、終了5分前に結論・TODOを確認するのが基本的な進行スキルとして身につけておきたい習慣。