「PMに必要なのはコミュニケーション能力ではなく、コミュニケーションを設計する力」

という考え方について書きました。

では、そのコミュニケーションは、いつ設計すればよいのでしょうか。

私の答えは、プロジェクト開始時のキックオフミーティングです。

キックオフミーティングというと、次のような「説明会」のイメージを持っている方も多いでしょう。

• プロジェクトの目的を説明する
• スケジュールを共有する
• 体制を説明する

もちろん、それらも大切です。

しかし、人見知りだった私にとって、キックオフミーティングの一番の目的は違いました。

「初対面」を終わらせること。

これが、私にとってのキックオフミーティングの本当の価値でした。

人見知りにとって一番難しいのは「最初の一言」

私は昔から人見知りでした。

特に苦手だったのは、初対面の人との会話です。

プロジェクトが始まると、多くのメンバーやステークホルダーとは初めて仕事をします。

本来であれば、自分から声を掛けて関係を築いた方が良いのでしょう。

しかし私は、

• 「何を話せばいいんだろう。」
• 「今話しかけても迷惑ではないかな。」

そんなことばかり考えてしまい、自分から話しかけることができませんでした。

「そのうち話す機会があるだろう。」

そう思って先延ばしにしていたのです。

しかし、その「そのうち」は、決まってトラブルが起きたときでした。

キックオフをやらないと、プロジェクトは「いつの間にか」始まってしまう

ある時、キックオフミーティングを実施しなかったプロジェクトがありました。

気付けば、それぞれが作業を始め、プロジェクトは静かにスタートしていました。

しかし、そのプロジェクトではチームマネジメントがうまくいきませんでした。

プロジェクトメンバーは、

• 何のためにこのプロジェクトをやるのか
• どれほど重要なプロジェクトなのか

を十分に理解できていませんでした。

そのため、当事者意識も生まれにくく、PMである私が後から一人ひとりとコミュニケーションを取り、プロジェクトへの意識を高めていく必要がありました。

人見知りの私にとって、それは非常に大きな負担でした。

今振り返ると、問題はコミュニケーション能力ではありません。

プロジェクトのスタートを設計できていなかったのです。

キックオフは「説明会」ではなく「チームを作る場」

それ以来、私は必ずキックオフミーティングを実施するようになりました。

ただし、目的は説明ではありません。

私が一番大切にしているのは、

「このプロジェクトを成功させるチームを作ること」です。

そのために、必ず次のことを伝えています。

• このプロジェクトの目的
• なぜ今このプロジェクトが必要なのか
• ステークホルダーが期待していること
• 会社として期待していること
• PMとして、このプロジェクトにかける思い

スケジュールや体制は資料を見れば分かります。

しかし、

「このプロジェクトは重要なんだ。」

という熱意は、PM自身の言葉でしか伝えられません。

私は、この時間がプロジェクトメンバーの当事者意識を育てるのだと思っています。

不安を話してもらう時間が、未来のリスクを減らす

キックオフでは、もう一つ必ず行っていることがあります。

一人ひとりに、不安なことを話してもらうことです。

プロジェクトの規模によって時間は調整しますが、できる限り全員に話してもらいます。

すると、

• この技術は経験がありません
• スケジュールが少し心配です
• 他案件との兼務があります

など、さまざまな声が聞こえてきます。

これは単なる自己紹介ではありません。

私はこの時間を、リスクを見つける時間だと思っています。

さらに、この時間にはもう一つ大きな意味があります。

全員が一度は発言することで、

「話してもいい場なんだ。」

という空気が生まれます。

この最初の一言が、その後の相談のしやすさにつながっていくのです。

最初の30分が、その後数か月のコミュニケーションを変える

キックオフが終わると、不思議なくらいコミュニケーションが楽になります。

• チャットを送る
• 電話を掛ける
• 相談する

どれも心理的なハードルが下がるのです。

特に電話では、その効果を強く感じます。

相手は、私の顔を思い出しながら話してくれている。

私も、「一度話した相手だから」という安心感があります。

トラブルが起きたときも、

「すぐ連絡してください。」

と言えば、すぐに対応してくれることが増えました。

私はこれを、キックオフで築いた信頼関係のおかげだと考えています。

PMBOK®には「キックオフをやりましょう」とは書かれていない

PMBOK®には、

「必ずキックオフミーティングを実施しましょう。」

とは書かれていません。

しかし、コミュニケーション・マネジメントでは、必要な情報を必要な人へ適切なタイミングで届けることが重要だとされています。

また、ステークホルダー・エンゲージメントでは、ステークホルダーとの良好な関係を構築し、維持することが求められます。

私は、この考え方を実践する最初の機会がキックオフミーティングだと考えています。

単なる説明会ではありません。

チームを作り、信頼関係を築き、コミュニケーションを始めるための最初のイベントなのです。

おわりに

私は今でも人見知りです。

初対面の人と話すことが得意になったわけではありません。

それでも、キックオフミーティングを大切にするようになってから、コミュニケーションに対する苦手意識は大きく減りました。

理由は簡単です。

自分を変えたのではなく、コミュニケーションが生まれる環境を設計したからです。

キックオフミーティングは、プロジェクト開始の儀式ではありません。

チームが同じ方向を向き、安心して相談できる関係を作るための第一歩です。

だから私は、人見知りのPMほどキックオフミーティングを大切にしてほしいと思っています。

あなたへの問いかけ

あなたのプロジェクトのキックオフミーティングは、「説明会」で終わっていませんか。

それとも、チームを作るための最初のコミュニケーション設計になっているでしょうか。

The post 人見知りのPMほどキックオフミーティングをやるべき理由 first appeared on PM道場.

しかし、「標準どおりに進めないということ？」「自由にやり方を変えていいの？」と誤解されることも少なくありません。

テーラリングとは、プロジェクトの特性に合わせて、プロジェクトマネジメントの進め方を最適化することです。

この記事では、テーラリングの意味や具体例、実務での活用方法、PMBOK®やプロジェクトマネージャ試験で重要なポイントまでわかりやすく解説します。

一言でいうと

テーラリングとは、「プロジェクトの状況に合わせて、マネジメントの進め方を最適化すること」です。

テーラリングとは

プロジェクトには、それぞれ異なる目的や規模、リスク、関係者、開発手法があります。

そのため、すべてのプロジェクトに同じ管理方法を適用しても、必ずしも成果が出るとは限りません。

テーラリングとは、組織の標準プロセスやPMBOK®の考え方を基に、プロジェクトの状況に応じて必要なプロセスや成果物、管理方法を選択・調整することを指します。

なぜテーラリングが必要なのか

例えば、2週間で完了する小規模プロジェクトと、3年間続く数百人規模のプロジェクトでは、必要な管理のレベルは大きく異なります。

どちらにも同じルールを適用すると、小規模プロジェクトでは管理コストが増え、大規模プロジェクトでは管理が不足する可能性があります。

プロジェクトに最適な管理方法を選択することが、テーラリングの目的です。

テーラリングの具体例

小規模プロジェクトの場合

• WBSを簡潔にする
• 会議の回数を減らす
• リスク管理表を簡略化する
• 進捗報告を口頭中心にする

大規模プロジェクトの場合

• 詳細なWBSを作成する
• 定例会議を体系化する
• レビュー工程を増やす
• 品質管理やリスク管理を強化する

どちらも正しく、プロジェクトに合った方法を選択することが重要です。

テーラリングとカスタマイズの違い

テーラリングは、「成果物を変える」のではなく、「プロジェクトの進め方を変える」という点が大きな違いです。

実務ではこんな場面で活用される

例えば、過去のプロジェクトでは、すべての設計書について3回のレビューを実施していたとします。

しかし、今回のプロジェクトでは、既存システムの軽微な改修であり、影響範囲も限定的です。

この場合、レビューを2回に減らしたり、一部をペアレビューへ変更したりすることもテーラリングです。

一方で、重要な機能追加を行う場合には、レビューを増やす判断もテーラリングに当たります。

よくある勘違い

テーラリングは手抜きではない

プロセスを減らすことだけがテーラリングではありません。

必要に応じてレビューや管理を強化することも、立派なテーラリングです。

自由に変更してよいわけではない

テーラリングは、組織のルールやガバナンスを踏まえた上で、合理的な理由に基づいて実施することが重要です。

プロジェクトマネージャ試験ではここが重要

IPAのプロジェクトマネージャ試験では、「プロジェクトの特性に応じた管理方法を選択した理由」が論述で問われることがあります。

午後Ⅱでは、「プロジェクトの規模やリスクを考慮し、どのように管理方法を工夫したか」を説明できると、高い評価につながります。

PMBOK®第7版では、テーラリングはすべてのプロジェクトで継続的に実施すべき重要な考え方として位置付けられています。

PM道場のワンポイント

テーラリングとは、「ルールを変えること」ではなく、「成功する確率を高めること」です。経験の浅いプロジェクトマネージャほど、「前回うまくいった方法」をそのまま適用しがちです。しかし、プロジェクトは毎回異なります。

規模、メンバー、技術、顧客、リスクが違えば、最適な管理方法も変わります。

優れたプロジェクトマネージャは、「標準を守ること」ではなく、「このプロジェクトにとって最も効果的な管理方法は何か」を常に考えています。

それこそが、テーラリングの本質です。

関連用語

• プロジェクトマネジメント
• PMBOK®
• プロジェクトライフサイクル
• フェーズ
• ガバナンス
• WBS
• リスクマネジメント
• 品質マネジメント

まとめ

テーラリングとは、プロジェクトの規模や目的、リスクなどに応じて、マネジメントの進め方を最適化することです。

すべてのプロジェクトに同じ管理方法を適用するのではなく、そのプロジェクトに最も適した方法を選択することが成功への近道になります。

PMBOK®第7版でも重要な考え方であり、実務でもプロジェクトマネージャに求められる重要なスキルの一つです。

関連記事

• PMBOK®とは？
• ガバナンスとは？
• プロジェクトライフサイクルとは？
• WBSとは？

よくある質問（FAQ）

Q. テーラリングとは何ですか？

A. プロジェクトの状況に応じて、プロジェクトマネジメントの方法やプロセスを最適化することです。

Q. テーラリングはプロセスを減らすことですか？

A. いいえ。必要に応じてプロセスを減らすこともありますが、逆にレビューや管理を強化することもテーラリングです。

Q. PMBOK®ではテーラリングは重要ですか？

A. はい。PMBOK®第7版では、すべてのプロジェクトで継続的にテーラリングを行うことが重要な考え方として示されています。

The post テーラリング（Tailoring）とは？PMBOK®での意味を初心者向けにわかりやすく解説す first appeared on PM道場.

• 令和5年度秋期 プロジェクトマネージャ試験 午後Ⅱ
  
  問題冊子はこちら
  
  出典：IPA 独立行政法人 情報処理推進機構

※掲載している問題冊子へのリンクおよび試験問題の著作権は、IPA 独立行政法人 情報処理推進機構に帰属します。最新情報はIPA公式サイトをご確認ください。

特に、統合マネジメントを軸に「プロジェクトの独自性に応じた調整力」が問われました。

結論｜なぜ修整（テーラリング）したかが軸

以下の流れで書けば説得性のある論文となります。

• 設問ア：独自性＋何を重視したか
• 設問イ：どう修整したか（テーラリング）
• 設問ウ：効果と改善（PDCA）

「なぜ修整したか（つまり独自性にどう対応したか）」がすべての軸になる

設問ア｜独自性と重要なマネジメント対象を関連付ける

以下3点について説明します。設問イ以降を論述内容を考慮に入れながら独自性を踏まえて説明しましょう。

• ①システム開発プロジェクトの目標
• ②目標達成のために時間、コスト、品質以外に重要と考えたプロジェクトマネジメントの対象
• ③重要と考えた理由

① プロジェクトの目標は定量的に書く

プロジェクトの目標を具体的、定量的に説明しましょう。定量的に示した方が、達成できたか否かを客観的に説明することができるので説得性が増します。ここでプロジェクトの独自性についても触れられると以降の説明がしやすくなります。

例：

• 処理時間を30％短縮
• 障害発生件数を月5件以下
• 納期遵守率100%

数値で書くことで説得力が上がります。
「短納期案件」「新技術導入」などの独自性も必ず入れましょう。

※独自性とは今まで経験したことがないことを言います。些細なことでも問題ありません。この独自性がそのプロジェクトにおいて注意しなければならないことになります。

② 時間・コスト・品質以外で重要な対象は知識エリアから選択

目標達成のために時間、コスト、品質以外に重要と考えたプロジェクトマネジメントの対象は、PMBOK®︎ガイドの知識エリアから選択するのが良いです。 時間、コスト、品質以外には、統合、スコープ、資源、調達、コミュニケーション、リスク、ステークホルダーがあります。これもプロジェクトの独自性に関連のあるもの選びましょう。

• リスクマネジメント
• ステークホルダーマネジメント
• コミュニケーションマネジメント

独自性に関連するものを選ぶことが重要です。

③ なぜ重要か＝独自性と結びつける

重要と考えた理由は独自性を関連させて説明しましょう。独自性とは他のプロジェクトとは違うところ。独自性があるからこそ、マネジメントの仕方も変わってくるので、独自性そのものが重要と考えた理由になります。

例：

• 新技術で不確実性が高い → リスク管理が重要
• 初めての利害関係者が多い → ステークホルダー管理が重要

設問イ｜テーラリングは“修整前後の比較”で書く

下記3点を論じます。設問アで説明した内容をより具体的に説明しましょう。修整前後を比較したしながら説明できると良いです。

• ①マネジメントの方法を修整したもの
• ②修整が必要と判断した理由
• ③修正した内容

① 修整したマネジメント方法を修整前と比較しながら説明

修整したマネジメント方法を説明しますが、修整前後を比較しながら説明しましょう。そうすることで、修整が必要な理由を理論的に説明することができます。

例：

• 定例会議の頻度を週1→週2に変更
• リスクレビューを追加

② 修整が必要な理由は独自性を根拠とする

修整が必要な理由は独自性を根拠とすることで説得性が増します。独自性とはそのプロジェクトで注意すべき点になります。注意すべき点を考慮してテーラリングを行うことで、しっかりとしたマネジメントを行うことができます。

• 短納期で情報共有不足が発生
• 新技術で問題が予測困難

③ 修整内容は具体的、定量的に

プロジェクトマネジメントの方法は、基本的には組織のルールや過去の良好事例を参考にすることが多いです。しかし良好事例だからだと言って、同じように進めてはプロジェクトマネジメントがうまくいかないことがあります。そのため、テーラリングするのです。この問いではそこの説明が求められています。修整前の標準または過去の事例からどのように修整したのかを具体的に説明しましょう。

例：

• 修整前：週1回の進捗会議
• 修整後：週2回＋日次チャット報告

設問ウ｜“定量評価＋PDCA”で書く

下記3点を論じます。テーラリングしたことを実施する。それが問題ないかをモニタリングして、問題があれば対策する。こうしてプロジェクトマネジメントしていきます。この問いでは、定量的に評価して、しっかりとした対応をとったかの説明が求められています。

• ①修整の有効性をどのようにモニタリングしたか
• ②モニタリング結果とその効果
• ③必要に応じて行った対応

① モニタリング方法は定量評価できるものを

モニタリングの方法は様々なものがあります。KPI達成度・計画と実績の差異分析・EVM・関係者満足度・リスク発生率など定量的に有効性を評価できるモニタリングをすることで説得性が増します。定量的に設定したプロジェクトの目標に関連づけましょう。

例：

• KPI達成率（％）
• 計画と実績の差異（遅延〇日、コスト〇円など）
• EVM（アーンドバリューマネジメント）
• 顧客満足度（％）

② 結果とその効果も定量的に

モニタリング結果とその評価について説明します。結果は定量的に説明しましょう。評価はプロジェクトマネージャとしての主観的な評価ではなく、メンバーや顧客などの客観的な評価が良いです。

例：

• 遅延件数が10件→2件に減少
• 顧客満足度が80％→95％

③ 必要な対応はPDCAを説明する

必要になった対応について論じます。プロジェクトマネージャはPDCAを回すことも必要なので、Checkの結果、どのようなActionを取ったのかを説明しましょう。このActionの次のPlanをどのように設定したかも論じましょう。他のプロジェクトの参考に資するものであればさらに良いです。

例：

• 追加の進捗管理ルールを導入
• リスク管理プロセスを標準化

まとめ

この問題は難しく見えますが、論じることはシンプルです。

• 独自性を明確にする
• それに合わせて調整（テーラリング）する
• 効果を定量で示す

この3ステップを意識して論理的に説明することで、論文の質は大きく向上します。

The post IPAプロジェクトマネージャ試験 午後Ⅱ対策 ｜【令和5年度秋 問1】 first appeared on PM道場.