なぜ日本企業ではテーラリングが起きないのか|PMBOKとプロジェクト管理の構造

テーラリングとは、プロジェクトの特性に合わせて標準プロセスを調整する考え方です。しかし日本企業ではテーラリングが機能しにくい構造があります。本記事ではPMBOKの考え方を整理しながら、その背景と組織設計の課題を解説します。 PMP

日本企業ではなぜテーラリングが起きづらいのか|PMBOKが示すプロジェクト管理の前提

テーラリング(Tailoring)とは、標準化されたプロセスや手法を、プロジェクトの特性に合わせて調整する考え方です。プロジェクトマネジメントの国際的な標準である A Guide to the Project Management Body of Knowledge でも、すべてのプロジェクトでテーラリングが必要であるとされています。

プロジェクトは、規模・期間・リスク・関係者・組織環境などが毎回異なります。そのため、標準プロセスをそのまま適用すると、管理が過剰になったり、逆に必要な統制が不足したりすることがあります。こうした状況に対応するために、プロジェクトの条件に合わせてプロセスや成果物を調整する考え方がテーラリングです。

しかし、理論としては広く知られているこの概念も、現実の企業では十分に機能しているとは言えません。とくに日本企業では、標準化されたプロセスが「守るべきルール」として扱われることが多く、プロジェクトの特性に応じた柔軟な調整が行われにくい傾向があります。

本記事では、テーラリングの基本概念を整理したうえで、なぜ日本企業ではテーラリングが起きづらいのかという構造的な問題を考えます。テーラリングを単なるプロジェクト管理のテクニックとしてではなく、組織のプロジェクト運営の設計という観点から整理していきます。


  1. テーラリングとは何か|ビジネス・IT・PMBOKで使われる意味
    1. テーラリングの意味と語源|Tailor(仕立てる)という概念
    2. ビジネス・IT・プロジェクト管理で使われるテーラリング
    3. 標準プロセスを調整するという考え方
  2. PMBOKにおけるテーラリングとは何か
    1. PMBOKが前提とする「すべてのプロジェクトは異なる」という考え方
    2. テーラリングの対象|プロセス・ツール・成果物
    3. なぜPMBOKではテーラリングが必須とされるのか
  3. テーラリングとカスタマイズの違い
    1. カスタマイズとの違い|製品調整とプロセス設計
    2. プロジェクト管理におけるテーラリングの意味
  4. テーラリングを行う目的とメリット
    1. プロジェクト特性に合った管理を設計できる
    2. 不要なプロセスを削減し管理コストを最適化する
  5. テーラリングの進め方|プロジェクト管理での基本ステップ
    1. プロジェクト特性(規模・リスク・期間)を分析する
    2. 標準プロセスや成果物を選択・調整する
    3. テーラリング内容をプロジェクト計画として定義する
  6. なぜプロジェクト管理は標準化できないのか
    1. プロジェクトは毎回条件が異なるという前提
    2. 不確実性とプロジェクト規模が管理方法を変える
  7. プロジェクト管理におけるテーラリングの具体例
    1. 小規模プロジェクトにおけるテーラリング
    2. DXプロジェクトにおけるテーラリング
    3. 大規模システム開発におけるテーラリング
  8. なぜ日本企業ではテーラリングが起きづらいのか
    1. 標準プロセスが「守るべきルール」になってしまう構造
    2. PMOがプロジェクト支援ではなく監査組織になる問題
    3. プロジェクト類型が設計されていないという構造
  9. テーラリングはPMの裁量ではなく組織設計である
    1. プロジェクト類型に応じた管理モデルを設計する
    2. PMOが担うべきテーラリング設計の役割
  10. 日本企業がテーラリングを機能させるための視点
    1. 標準プロセスと柔軟性を両立するプロジェクト管理
    2. テーラリングは戦略とプロジェクト管理をつなぐ
  11. まとめ

テーラリングとは何か|ビジネス・IT・PMBOKで使われる意味

テーラリングの意味と語源|Tailor(仕立てる)という概念

テーラリングという言葉は、英語の「tailor(仕立てる)」に由来しています。仕立て屋が顧客の体型や用途に合わせて服を調整するように、標準化されたプロセスや手法を状況に合わせて調整するという意味で使われるようになりました。

ビジネス分野では、標準化されたルールやプロセスをそのまま適用するのではなく、組織やプロジェクトの条件に合わせて最適化する考え方を指します。たとえば、企業の業務プロセスやシステム導入では、一般的なフレームワークをそのまま導入するのではなく、自社の業務や組織構造に合わせて調整することが必要になります。この調整の考え方を広く指す言葉として、テーラリングが使われます。

この概念は、ITやプロジェクトマネジメントの分野で特に重要視されています。なぜなら、ITプロジェクトは不確実性が高く、同じ手法をすべてのプロジェクトに適用することが現実的ではないためです。プロジェクトの条件に応じて管理方法を調整するという発想は、プロジェクトマネジメントの基本的な考え方の一つとなっています。

ビジネス・IT・プロジェクト管理で使われるテーラリング

ビジネスの現場では、テーラリングはさまざまな場面で使われています。業務プロセスの設計、ITシステムの導入、プロジェクト管理など、標準化された方法論を現場に適用する必要がある領域では特に重要です。

たとえばITシステム導入では、一般的なフレームワークや開発手法をそのまま使うことはほとんどありません。組織の業務プロセスや規模、セキュリティ要件などに合わせて、手法やプロセスを調整する必要があります。

プロジェクトマネジメントの分野でも同様です。小規模なプロジェクトと大規模なプロジェクトでは、必要な管理レベルが大きく異なります。小規模プロジェクトでは詳細なドキュメントや承認プロセスが過剰になることがありますが、大規模プロジェクトでは逆に厳格な管理が必要になります。

このように、標準化された方法論を状況に合わせて調整するという考え方は、ビジネスやITの現場では広く使われており、プロジェクト管理でも重要な概念となっています。

標準プロセスを調整するという考え方

テーラリングの本質は、標準プロセスをそのまま適用するのではなく、状況に応じて調整するという点にあります。標準プロセスは、多くの組織やプロジェクトで共通して使えるように設計されています。そのため、どうしても抽象度が高く、個別のプロジェクトにそのまま適用すると無理が生じる場合があります。

たとえば、厳格な変更管理プロセスは大規模プロジェクトでは重要ですが、小規模なプロジェクトでは管理コストが過剰になることがあります。逆に、リスクの高いプロジェクトでは、より厳密なリスク管理が必要になります。

このような状況に対応するために、標準プロセスをプロジェクトの条件に合わせて調整する必要があります。テーラリングは、こうした調整を意図的に行うための考え方です。

重要なのは、テーラリングが単にプロセスを省略することではないという点です。プロジェクトの特性を踏まえて、どのプロセスをどの程度の厳密さで適用するのかを設計することが、テーラリングの本来の意味です。


PMBOKにおけるテーラリングとは何か

PMBOKが前提とする「すべてのプロジェクトは異なる」という考え方

プロジェクトマネジメントの国際標準である Project Management Institute が発行するPMBOKでは、すべてのプロジェクトが異なるという前提が明確に示されています。

プロジェクトは一時的な活動であり、目的、組織、関係者、技術、環境などが毎回異なります。そのため、同じプロジェクト管理手法をすべてのプロジェクトにそのまま適用することは現実的ではありません。

PMBOKでは、標準プロセスはあくまで参考モデルであり、各プロジェクトの条件に合わせて調整する必要があるとされています。この調整の考え方がテーラリングです。

つまり、PMBOKは特定の方法論をそのまま適用することを求めているのではなく、状況に応じて適切な管理方法を設計することを前提としています。この点は、プロジェクト管理を理解するうえで非常に重要な考え方です。

テーラリングの対象|プロセス・ツール・成果物

PMBOKにおけるテーラリングは、単に手法を選択することではありません。プロジェクト管理に関わるさまざまな要素を調整することを意味します。

主な対象は、プロセス、ツール、成果物などです。プロセスとは、リスク管理、変更管理、スコープ管理などの管理手順を指します。ツールは、プロジェクト管理ソフトや分析手法などです。成果物は、計画書、WBS、リスク登録簿などのドキュメントです。

たとえば、小規模プロジェクトでは詳細なWBSを作成しない場合があります。逆に、大規模プロジェクトでは詳細なリスク管理や変更管理が必要になります。

このように、プロジェクトの特性に応じて、どのプロセスをどの程度適用するのかを決めることがテーラリングの中心になります。

なぜPMBOKではテーラリングが必須とされるのか

PMBOKでテーラリングが重要視されている理由は、プロジェクトの多様性にあります。プロジェクトは、規模、期間、技術、リスク、組織環境などが大きく異なります。そのため、単一の管理方法で対応することは難しいのです。

もしすべてのプロジェクトに同じ管理プロセスを適用すると、管理コストが過剰になったり、逆に必要な統制が不足したりする可能性があります。

テーラリングは、この問題を解決するための考え方です。プロジェクトの特性を踏まえて、必要なプロセスや成果物を選択し、管理方法を設計することで、効率と品質の両方を確保することができます。

この意味で、テーラリングは例外的な手法ではなく、プロジェクト管理の基本的な前提といえるでしょう。


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

カスタマイズとの違い|製品調整とプロセス設計

テーラリングと似た言葉として「カスタマイズ(Customization)」があります。両者は混同されることも多いですが、対象と目的が異なります。

カスタマイズは主に「製品」や「サービス」を顧客の要求に合わせて変更することを指します。たとえば、ソフトウェアの機能を追加したり、ユーザーインターフェースを顧客仕様に変更したりすることはカスタマイズにあたります。対象は製品やシステムそのものです。

一方、テーラリングは「プロセス」や「管理方法」を調整することを意味します。プロジェクト管理では、どのプロセスを適用するのか、どの程度の厳密さで管理するのか、どの成果物を作成するのかといった運用ルールを調整することがテーラリングです。

つまり、カスタマイズが成果物や製品の調整であるのに対し、テーラリングはプロジェクトを進めるための管理の仕組みを調整する考え方です。この違いを理解しておくと、プロジェクト管理の議論が整理しやすくなります。

プロジェクト管理におけるテーラリングの意味

プロジェクト管理の文脈でテーラリングが使われる場合、その対象は主に管理プロセスです。プロジェクトの条件に合わせて、管理の厳密さや手順を調整することが中心になります。

たとえば、リスクの低い小規模プロジェクトでは、詳細なリスク管理プロセスを導入すると管理コストが過剰になる場合があります。この場合、リスク管理の手順を簡略化することが合理的です。逆に、技術的な不確実性が高いプロジェクトでは、より詳細なリスク分析が必要になることがあります。

このように、プロジェクトの特性に応じて管理方法を設計することが、プロジェクト管理におけるテーラリングの意味です。

重要なのは、テーラリングがプロセスの削減を目的とするものではないという点です。管理コストと統制のバランスを取りながら、プロジェクトにとって最も合理的な管理方法を設計することが本来の目的です。


テーラリングを行う目的とメリット

プロジェクト特性に合った管理を設計できる

テーラリングの最大の目的は、プロジェクトの特性に合った管理方法を設計することです。プロジェクトは、規模、期間、関係者、技術、リスクなどが毎回異なります。そのため、同じ管理方法をすべてのプロジェクトに適用することは合理的ではありません。

たとえば、数人で数週間実施するプロジェクトと、数百人が関わる数年規模のプロジェクトでは、必要な管理レベルが大きく異なります。小規模プロジェクトでは、複雑な承認プロセスや詳細なドキュメント管理が過剰になる場合があります。一方、大規模プロジェクトでは、統制が弱すぎるとリスク管理や変更管理が機能しなくなる可能性があります。

テーラリングを行うことで、プロジェクトの規模やリスクに応じた管理レベルを設計することができます。これにより、管理の効率と統制のバランスを取ることが可能になります。

不要なプロセスを削減し管理コストを最適化する

プロジェクト管理には多くのプロセスやドキュメントが存在します。これらは重要な役割を持っていますが、すべてのプロジェクトで同じレベルの管理が必要とは限りません。

標準プロセスをそのまま適用すると、管理のための作業が過剰になり、プロジェクトチームの負担が増えることがあります。会議や報告書の作成が増えすぎると、本来のプロジェクト活動に割く時間が減ってしまう可能性があります。

テーラリングを適切に行うことで、必要なプロセスは維持しつつ、不要な管理作業を削減することができます。これにより、管理コストを抑えながらプロジェクトの成果を最大化することが可能になります。


テーラリングの進め方|プロジェクト管理での基本ステップ

プロジェクト特性(規模・リスク・期間)を分析する

テーラリングを行う最初のステップは、プロジェクトの特性を理解することです。プロジェクトの規模、期間、技術的な難易度、関係者の数、組織への影響などを整理します。

たとえば、技術的な不確実性が高いプロジェクトでは、リスク管理や進捗管理をより厳密に行う必要があります。一方、既存システムの軽微な改善プロジェクトでは、簡略化した管理プロセスでも十分に対応できる場合があります。

このように、プロジェクトの条件を整理することで、どの程度の管理が必要なのかを判断しやすくなります。

標準プロセスや成果物を選択・調整する

プロジェクトの特性を把握したら、標準プロセスの中から必要なものを選択し、調整します。リスク管理、変更管理、品質管理などのプロセスをどの程度適用するのかを決めます。

また、成果物の種類や作成レベルも調整します。すべてのドキュメントを詳細に作成する必要があるとは限りません。プロジェクトの規模や重要度に応じて、必要な成果物を選択します。

このプロセスでは、管理の厳密さと効率のバランスを取ることが重要です。管理が過剰になるとプロジェクトの進行が遅くなる可能性がありますが、管理が不足するとリスクが見えにくくなります。

テーラリング内容をプロジェクト計画として定義する

テーラリングで決定した内容は、プロジェクト計画として明確に定義する必要があります。どのプロセスを適用するのか、どの成果物を作成するのか、どのような承認プロセスを設けるのかを整理します。

これにより、プロジェクトメンバーや関係者が管理方法を理解しやすくなります。また、途中で管理方法が変わってしまうことを防ぐ効果もあります。

テーラリングは、プロジェクトの途中で即興的に行うものではなく、計画段階で設計されるべきものです。この点を明確にしておくことで、プロジェクト運営の一貫性を保つことができます。


なぜプロジェクト管理は標準化できないのか

プロジェクトは毎回条件が異なるという前提

プロジェクト管理が完全に標準化できない最大の理由は、プロジェクトが毎回異なる条件で実施される活動だからです。プロジェクトは、期間、目的、関係者、技術、組織環境などがそれぞれ異なります。同じ企業の中であっても、まったく同じ条件で実施されるプロジェクトはほとんどありません。

たとえば、新規サービスの開発プロジェクトと、既存システムの保守改善プロジェクトでは、求められる管理方法が大きく異なります。前者では不確実性が高く、柔軟な意思決定や試行錯誤が必要になる場合があります。一方、後者では安定した運用を前提とした計画的な管理が重要になります。

このような違いがあるにもかかわらず、同じ管理プロセスをすべてのプロジェクトに適用すると、現場との間にズレが生じます。管理が過剰になったり、逆に必要な統制が不足したりすることが起こりやすくなります。

そのため、プロジェクト管理では標準プロセスをそのまま適用するのではなく、状況に応じて調整することが必要になります。テーラリングという考え方は、この前提に基づいています。

不確実性とプロジェクト規模が管理方法を変える

プロジェクト管理の方法を決定するうえで重要な要素の一つが、不確実性です。技術的な難易度が高いプロジェクトや、前例の少ないプロジェクトでは、計画段階で将来を完全に予測することが難しくなります。そのため、柔軟な意思決定や短いサイクルでの検証が必要になります。

一方、要件が明確で、過去に類似プロジェクトの実績がある場合は、計画的な管理が有効になります。この場合、詳細な計画と厳格な変更管理によって、プロジェクトを安定的に進めることができます。

プロジェクトの規模も管理方法に影響します。数人のチームで短期間に実施するプロジェクトでは、複雑な管理プロセスは必ずしも必要ありません。しかし、大規模なプロジェクトでは、関係者が多く、意思決定の構造も複雑になるため、より厳密な管理が必要になります。

このように、不確実性やプロジェクト規模によって最適な管理方法は変わります。そのため、プロジェクト管理を完全に標準化することは難しく、テーラリングによる調整が必要になります。


プロジェクト管理におけるテーラリングの具体例

小規模プロジェクトにおけるテーラリング

小規模プロジェクトでは、管理プロセスを簡略化するテーラリングが行われることが多くなります。たとえば、数人のチームで数週間の期間で実施されるプロジェクトでは、詳細なドキュメントや複雑な承認プロセスが過剰になる場合があります。

このような場合、プロジェクト計画書を簡略化したり、進捗管理をシンプルなタスク管理ツールで行ったりすることがあります。リスク管理や品質管理も、形式的なプロセスではなく、チーム内のコミュニケーションを中心に運用されることがあります。

重要なのは、管理を省略するのではなく、プロジェクトにとって合理的な管理レベルを設計することです。小規模プロジェクトでは、迅速な意思決定と柔軟な対応が重要になるため、過剰な管理を避けるテーラリングが有効になります。

DXプロジェクトにおけるテーラリング

DX(デジタルトランスフォーメーション)プロジェクトでは、不確実性が高いことが多く、柔軟な管理方法が求められる場合があります。新しい技術やビジネスモデルを扱うプロジェクトでは、初期段階で要件が完全に定義できないことも珍しくありません。

このような場合、ウォーターフォール型の厳格な計画管理だけでは対応が難しくなることがあります。そのため、短いサイクルでの開発や検証を行うアプローチを採用することがあります。

ただし、すべてをアジャイル型にする必要があるわけではありません。組織の意思決定プロセスやガバナンスに合わせて、計画管理と柔軟な開発手法を組み合わせるケースもあります。このような管理方法の設計も、テーラリングの一つといえます。

大規模システム開発におけるテーラリング

大規模なシステム開発プロジェクトでは、逆に管理プロセスを強化するテーラリングが行われることがあります。関係者が多く、予算やリスクの影響が大きいため、厳格な管理が必要になる場合があります。

たとえば、変更管理プロセスを明確に定義し、要件変更の承認プロセスを厳格にすることがあります。また、リスク管理や品質管理も詳細なプロセスを設けることで、問題の早期発見と対応を可能にします。

このように、テーラリングは必ずしもプロセスを簡略化することではありません。プロジェクトの特性に応じて、必要な管理を強化することもテーラリングの一つです。


なぜ日本企業ではテーラリングが起きづらいのか

標準プロセスが「守るべきルール」になってしまう構造

多くの日本企業では、標準化されたプロセスが「守るべきルール」として扱われる傾向があります。本来、標準プロセスは参考モデルとして用意されているものですが、実際の現場では変更が難しい固定的なルールとして運用されることがあります。

その結果、プロジェクトの特性に合わせてプロセスを調整することが難しくなります。現場のプロジェクトマネージャーがプロセスを調整しようとしても、標準ルールから外れることに対する心理的な抵抗や組織的な制約が生じる場合があります。

このような状況では、テーラリングの考え方があっても実際には機能しません。標準プロセスが柔軟な運用を前提としていない場合、プロジェクト管理は形式的な手続きになりやすくなります。

PMOがプロジェクト支援ではなく監査組織になる問題

PMO(Project Management Office)は、本来プロジェクト管理を支援する役割を持つ組織です。プロジェクトマネージャーが適切にプロジェクトを運営できるよう、ガイドラインや支援を提供することが期待されています。

しかし実際には、PMOが監査組織のような役割を担うケースも少なくありません。プロジェクトが標準プロセスに従っているかどうかをチェックすることが主な役割になってしまう場合があります。

このような状況では、プロジェクトマネージャーがテーラリングを行うことが難しくなります。標準プロセスから外れることが問題視されるため、現場ではルールを守ることが優先されるようになります。

結果として、テーラリングという考え方が存在していても、実際のプロジェクトでは活用されないという状況が生まれます。

プロジェクト類型が設計されていないという構造

もう一つの要因は、プロジェクトの類型が組織として整理されていないことです。多くの企業では、すべてのプロジェクトに同じ管理ルールが適用されています。

しかし実際には、プロジェクトにはさまざまな種類があります。新規事業開発、システム改善、基幹システム刷新など、それぞれ性質が異なります。本来であれば、プロジェクトの種類に応じて管理方法を変える必要があります。

プロジェクト類型が定義されていない場合、テーラリングは個人の判断に依存することになります。その結果、組織として一貫した管理方法を設計することが難しくなります。

このような構造では、テーラリングは制度としてではなく、現場の裁量として扱われることになります。そのため、組織全体でテーラリングが機能しにくくなるのです。


テーラリングはPMの裁量ではなく組織設計である

プロジェクト類型に応じた管理モデルを設計する

ここまで見てきたように、テーラリングは本来、個々のプロジェクトマネージャーが場当たり的に判断するものではありません。プロジェクトの特性に応じて管理方法を調整するという考え方は、むしろ組織として設計されるべきものです。

そのためには、まずプロジェクトの種類を整理する必要があります。すべてのプロジェクトを同じ枠組みで扱うのではなく、性質の違いを前提に管理モデルを設計することが重要です。

たとえば、既存システムの改善プロジェクトと、新規事業開発のプロジェクトでは、求められる管理方法が大きく異なります。前者では、品質管理や変更管理を重視した計画的な運営が求められることが多くなります。一方、後者では、不確実性が高いため、柔軟な意思決定や短いサイクルでの検証が重要になる場合があります。

このようにプロジェクトの特性が異なるにもかかわらず、同じ管理プロセスを適用すると、管理の過不足が生じやすくなります。プロジェクト類型を整理し、それぞれに適した管理モデルを設計することは、テーラリングを組織として機能させるうえで重要な取り組みといえます。

PMOが担うべきテーラリング設計の役割

プロジェクト管理を組織として設計するうえで重要な役割を担うのが、PMOです。本来、PMOはプロジェクト管理の標準化と支援を目的とした組織です。標準プロセスの整備だけでなく、プロジェクトマネージャーが適切にプロジェクトを運営できるよう支援することが求められます。

この観点から見ると、PMOの役割は単にルールを定めることではありません。プロジェクトの特性に応じて管理方法を調整できる仕組みを設計することが重要になります。

たとえば、プロジェクトの規模やリスクに応じて適用するプロセスを定義したり、プロジェクト類型ごとに管理モデルを整理したりすることが考えられます。こうした仕組みが整備されていれば、プロジェクトマネージャーがテーラリングを行う際の判断基準が明確になります。

PMOが監査組織として機能するだけでは、テーラリングは現場で実行されにくくなります。むしろ、テーラリングを支援する組織としての役割を強化することが、プロジェクト管理の成熟度を高めることにつながります。


日本企業がテーラリングを機能させるための視点

標準プロセスと柔軟性を両立するプロジェクト管理

テーラリングを機能させるためには、標準化と柔軟性のバランスを取る必要があります。標準プロセスは、組織として一定の品質や統制を確保するために重要な役割を持っています。しかし、標準プロセスを固定化してしまうと、プロジェクトの特性に応じた柔軟な運営が難しくなります。

そのため、標準プロセスを「守るべきルール」としてではなく、「参考モデル」として位置づけることが重要になります。プロジェクトの特性に応じて、どのプロセスをどの程度適用するのかを調整できるようにすることで、標準化と柔軟性の両立が可能になります。

このような考え方は、プロジェクト管理を単なる手続きではなく、組織のプロジェクト運営の仕組みとして捉えることにつながります。標準化と柔軟性のバランスを取ることが、テーラリングを実践するうえでの重要な視点になります。

テーラリングは戦略とプロジェクト管理をつなぐ

テーラリングは単なる管理手法ではなく、組織の戦略とプロジェクト管理をつなぐ役割を持つ考え方でもあります。企業の戦略や事業環境によって、求められるプロジェクトの種類は変わります。

新規事業を重視する企業では、不確実性の高いプロジェクトが増える可能性があります。この場合、柔軟な意思決定や短いサイクルでの検証を可能にする管理方法が必要になります。一方、安定した事業運営を重視する企業では、品質や統制を重視した管理方法が求められることがあります。

このように、企業の戦略とプロジェクト管理の方法は密接に関係しています。テーラリングは、こうした関係を整理し、組織として適切なプロジェクト管理の仕組みを設計するための重要な考え方といえるでしょう。


まとめ

テーラリングとは、標準化されたプロセスや手法をプロジェクトの特性に合わせて調整する考え方です。プロジェクトマネジメントの国際標準であるPMBOKでも、すべてのプロジェクトでテーラリングが必要とされています。

しかし現実の企業では、この考え方が十分に機能しているとは限りません。とくに日本企業では、標準プロセスが強く固定化され、プロジェクトの特性に応じた柔軟な調整が行われにくい構造があります。標準ルールを守ることが優先されることで、本来必要なテーラリングが実行されないケースも少なくありません。

本来、テーラリングはプロジェクトマネージャー個人の裁量だけに任せるものではありません。組織としてプロジェクトの類型を整理し、それぞれに適した管理モデルを設計することが重要になります。

プロジェクトは常に異なる条件で実施されます。そのため、標準プロセスを固定化するのではなく、状況に応じて管理方法を設計できる仕組みが必要になります。テーラリングは、プロジェクト管理の技術であると同時に、組織がどのようにプロジェクトを運営するかという設計の問題でもあるといえるでしょう。

コメント

タイトルとURLをコピーしました