OSPOリーダの原則をPMIの考え方から紐解いてみた

Please scroll down for the English version.

要約

本記事では、"Open Source Program Office (OSPO)" は "Open Source (Software)" を活用するための "Program Office" である、という考えの基、 Project Management Institute（PMI）¹ が2024年4月に新たに取り纏めた "The Standard for Program Management 5th-Edition 5th-Edition" ² に記述されている「８つの原則」という最新の体系から、"OSPOリーダー" や "OSPOプログラムマネージャ" が遵守するべき原則は何か、という新たな観点を紐解いてみました。これらの観点が、OSPO活動を効率的に推進し、組織全体のオープンソース戦略を強化するための指針となれば幸いです。

はじめに

OSPO（Open Source Program Office）という言葉をご存知でしょうか？

また、既にご存知の方の中には、"OSPO" とは "Open Source Program" のための "Office" と解釈されている方はいませんでしょうか？

正確な答えは、"OSPO" という単語を最初に使い始めたGoogleなどに問い合わせをしないとわかりませんが、"OSPO" に含まれる "P"、 つまり “Program” はコンピュータへの命令や指示をする "Computer Program" のことではなく、"OSPO" は "Open Source (Software)" と "Program Office" という２つの単語の造語である、と思われます。

そこで本記事では、"OSPO" は "Open Source (Software)" を活用するための "Program Office" である、という考えの基、 Project Management Institute（PMI）¹ が策定した "プログラムマネジメント" の最新の考え方から、"OSPOリーダー" や "OSPOプログラムマネージャ" が遵守するべき原則、という新たな観点で紐解いてみます。

"OSPO" とは？

"OSPO" とは、企業や組織の内部に設置され、オープンソースソフトウェア（OSS）の管理や戦略策定などを担う部署あるいはチーム、と言われています。

歴史的な観点では、Googleが最初のOSPOの１つを2004年頃に組織したとも言われています。

また、OSPOの組織構成・役割・責務・課題については、深層考察：『オープンソース プログラム オフィス』にて、OSPO組織を成熟度の観点で０～４の５つのステージに整理して、それぞれ詳しく説明がなされています。

本記事では、これら既存の観点とは別の観点として、“Open Source Program Office“ の “Program Office” の意味を、"プロジェクト" や "プログラム" 等を定義する米国の非営利団体である PMI¹ の最新の考え方からヒントを得てみたいと思います。

特に、本記事で着目する "プログラム" については、 "The Standard for Program Management" ² に記述されてます。また、2024年4月に改訂された第５版の第２章には、 "プログラムマネージャを導く「８つの原則」" が新たに体系化されました。

そこで、この "プログラムマネージャを導く「８つの原則」" という新たな観点を紐解くことで、OSPO組織活動を牽引するリーダ が遵守するべき原則を紐解いてみます。

そもそも、 "プログラム" って何？

実は、PMI¹という、プロジェクトマネジメント等を策定する組織が定義した概念の１つに、"プログラム" というものがあります。

まず、 "プロジェクト" を整理

まず、皆さんが社内でもよく耳にされる "プロジェクト" に関して簡単に整理してみます。

PMI¹が策定した、プロジェクトマネジメントのガイド本であるPMBOK²第７版によりますと、"プロジェクト" とは、「 "独自" のプロダクト、サービス、所産（価値）を創造するために実施する "有期性" のある業務」と定義されています。

ポイントは、明確な始まりと終わりがある "有期性" と、生成する成果物に不確実性が伴う "独自性" の２つが あることです。（逆に、継続的で反復性がある業務は "定常業務" ということになります）
　
また、"プロジェクト" の進捗やリスクなどの管理を担う "プロジェクトマネージャ（PM）" は、自身のプロジェクトの成果が最大になることを常に考えて行動をします。

"プログラム" とは

次に、本記事で着目する "プログラム" に関して簡単に整理してみます。

"プログラム" とは、「個別プロジェクトでは得ることができないベネフィットを、"複数プロジェクトの相乗効果" で実現する集まり」という記載が "The Standard for Program Management" ³にあります。

いわゆる "プロジェクトマネージャ（PM）" は、自身のプロジェクトの成果が最大になることを目指しているため、もしかしたら、組織全体の方向性や、他のプロジェクトとの方向性とズレる可能性があります。

それでは組織全体としての成果が得にくいため、「複数プロジェクトの相乗効果の最大化」を考える必要があります。

この役割を担うのが "プログラムマネージャ（PgM）" であり、複数のプロジェクト間での相乗効果の最大化を目指す集まりを "プログラム" と呼びます。

蛇足になりますが、"OSPO" の "PO" は "Program Office" であるということを裏付ける事実として、"OSPO Program Manager" という肩書で、OSPO組織活動をリードする立場からご発表やご発言をなさっている方を拝見する機会があります。

"プログラム" と "プロジェクト" の関係は？

以下に、１つの "プログラム" と、プログラムを構成する３つの "プロジェクト" との関係を単純化した図を示します。

詳しくは本記事で記載しませんが、プログラムを構成する他の要素として、"サブ・プログラム" や "オペレーション" もあります。

また、プロジェクトマネジメントオフィス：PMO（PgMOと区別するために "PjMO" と記載することがあります） や、 プログラムマネジメントオフィス：PgMO とは、個々のプロジェクトに特化した支援を提供したり、個々のプロジェクトから独立してプログラム内の複数プロジェクトを支援したりする役割を担います。

プログラムマネージャ が遵守するべき原則

ここで、天下り的になりますが、PMI¹が2024年に4月に改訂した最新の "The Standard for Program Management 5th-Edition" では、"プログラムマネジメント" を実践する上で、プロジェクトマネージャ（PgM）が遵守するべき「８つの原則」が新しく体系化されました。

本記事では、誤解を招かない程度に自分の解釈を、なるべく簡単な日本語で記載するようにします。

ステークホルダー：

プログラムの利害関係者を味方にする
（プログラムの利害関係者にNOと言わせない）

ベネフィットの実現：

プログラムの成果を組織戦略に合致させて組織にベネフィットを生み出す
（プログラムが生み出すものすべてに意味がなければならない）

相乗効果：

複数のプロジェクトの複雑さや相互依存関係を考慮してプログラムを最適化する
（個々のプロジェクトが個々に達成できる以上のものを生み出す）

チーム・オブ・チームズ：

変化を柔軟に受け入れ、様々なリスクにも適応しながらプログラムを推進する
（プログラムメンバの一致団結）

チェンジ：

プログラム立ち上げ時に決めた約束事等を必要に応じて柔軟に変革する
（現実との差分が無いかと常に危機感を持ちながら）

リーダシップ：

プログラムが目指す成果に向かうように推進する強力なリーダシップを持つ

リスク：

プログラムが直面するリスク（好機・脅威）を管理してリスク対応計画を最適化する

ガバナンス：

プログラムを上手く回すためのルールの策定とその適応、またルールが遵守されているかどうかを監視する
（プログラムの成功の可能性を高めるため）

"OSPOリーダ" が遵守するべき原則とは？

ここで、上記のプログラムマネージャが遵守すべき「８つの原則」において、

• 「プログラム」　　=>　「OSPO組織の活動」
• 「プロジェクト」　=>　「OSSを活用する開発案件」

と単語を変換して、意味が通る言葉へ変換してみます。

つまり、
"OSPO組織活動を牽引するリーダ" が遵守するべき「８つの原則」
は、以下のように解釈ができます。

ステークホルダー：

OSPO組織活動の利害関係者を味方にする
（OSPO組織をオペレーションする際に利害関係者から応援をしてもらえるように、NOと言わせないように）

ベネフィットの実現：

OSPO組織活動の成果を組織戦略に合致させて組織にベネフィットを生み出す
（OSPO組織活動が生み出すものすべてに意味がなければならない）

相乗効果：

OSSを活用する複数の開発案件間の「複雑な関係」や「相互依存関係」を考慮してOSPO組織活動を最適化する
（OSSに関して個々の開発案件が達成できる以上の成果を、OSPO組織活動として生み出す）

チーム・オブ・チームズ：

変化を柔軟に受け入れ、様々なリスクにも適応しながらOSPO組織活動を推進する
（OSPOリーダとOSPOメンバの一致団結）

チェンジ：

OSPO組織活動立ち上げ時に決めた約束事等を必要に応じて柔軟に変革する
（OSPO組織のルールやOSSコンプライアンスの対処ルールなど、定めたルールはベストではないと常に危機感を持ちながら）

リーダシップ：

OSPO組織活動が目指す成果に向かって、OSPO組織活動を推進する強力なリーダシップを持つ

リスク：

OSPO組織活動が直面するリスク（好機・脅威）を管理してリスク対応計画を最適化する

ガバナンス：

OSPO組織活動を上手く回すためのルールの策定とその適応、またそのルールが遵守されているかどうかを監視する
（OSPO組織活動の成功の可能性を高めるため）

いかがでしょうか？

「うんうん、それは大事だよね」と、ご納得いただけた点や、
「なるほど、それは大事だね」と、新しい観点を見付けて頂いた点があったかもしれません。

また、場合によっては「それって、そんなに大事なの？」と、あまり納得できなかった点があったかもしれません。

これらは、ご自分の今までの成功体験や失敗体験からくる認知バイアスに依存しているところもあり、マネジメント体系を学ぶ際の "よくある感じ方" だと思います。

ご自分の疑問点や納得がいかない点を大事にして、自分が納得できるまで深堀をして頂けたら幸いです。

最後に、"OSPO組織活動" と、３つの "OSSを活用する開発案件" との関係に変換した図を示します。

さいごに

最後まで読んでいただきまして、どうもありがとうございます。

本記事では、既存の観点とは別の観点から、OSPO活動を効率的に推進し、組織全体のオープンソース戦略を強化するためのヒントを探してみました。

OSPOの認識が乏しい組織では、OSPOリーダがOSPOの概念を根付かせることや、OSPOリーダがOSPO活動を牽引して行くことは、一筋縄ではなかなかいかないと思います。

皆様がOSPO組織を牽引する際の一助になれば幸いです。

---

The OSPO Leader Principles Unraveled from the PMI Approach

Summary

Based on the recognition that an "Open Source Program Office (OSPO)" is a "Program Office" for the use of "Open Source (Software)", this article explores a new perspective on the principles that "OSPO Leaders" and "OSPO Program Managers" should follow.
This perspective is derived from the "Eight Principles" outlined in the latest framework, "The Standard for Program Management 5th Edition", compiled by the Project Management Institute (PMI) in April 2024.
I hope that these perspectives will serve as a guide to effectively advance OSPO activities and strengthen the organisation's overall open source strategy.

Introduction

Do you know what an OSPO (Open Source Program Office) is?

Also, for those who may already know, does anyone think that "OSPO" means an "Office" for an "Open Source Program"?

To know the exact meaning, we would have to ask organizations like Google, who first started using the word "OSPO."

But it seems that the "P" in "OSPO," which stands for "Program," doesn't mean a "Computer Program." Instead, "OSPO" is probably a combination of "Open Source (Software)" and "Program Office."

So, in this article, I will look into what an OSPO leader does, thinking of an "OSPO" as a "Program Office" to make the best use of "Open Source (Software)." I will do this using the latest Program
Management standard from the Project Management Institute (PMI)¹.

What is "OSPO"?

An "OSPO" is said to be a department or team within a company or organization that manages Open Source Software (OSS) and develops related policies.

Historically, [Google] (https://opensource.google/about "History of OSPO") is said to have organized one of the first OSPOs around 2004.

The structure, roles, responsibilities and challenges of OSPOs are explained in detail in "A Deep Dive into Open Source Program Offices", organizing them into five stages of maturity from 0 to 4.

In this article, I would like to explore a different perspective by unraveling the meaning of "Program Office" in "Open Source Program Office" using the latest thinking from PMI¹, a U.S. non-profit organization that defines "projects" and "programs".

Specifically, this article focuses on "programs," which are described in "The Standard for Program Management" ². Chapter 2 of the fifth edition, revised in April 2024, reorganizes the "8 Principles that should guide the work of a Program Manager".

By unraveling these "8 Principles that should guide the work of a Program Manager", which represent the latest thinking, I hope to gain insights into the role of leaders who drive OSPO activities.

What is "Program"?

Actually, there is a concept called "Program," which is defined by an organization called PMI¹ that sets project management standards.

Let's remember "Project"

Let's start by explaining what a "Project" is, a term you often hear in business.

According to the 7th edition of the PMBOK², a guide to project management from PMI¹, a "Project" is defined as "a temporary endeavor undertaken to create a unique project service or result".

The key points are that it is "temporary", with a clear beginning and end, and "unique", where the outcome is somewhat uncertain. (On the other hand, ongoing and repetitive work is called "operations.")

Also, a "Project Manager (PM)" is responsible for managing the progress, risks, and other aspects of a "Project" and always acts to maximize the project's outcome.

"Program" is

Next, let's briefly explain what a "Program" is, which is the focus of this article.

A "Program" is described in "The Standard for Program Management 5th-Edition" ³ as "a group that aims to achieve benefits that cannot be achieved by individual projects alone, by enhancing the synergies between multiple projects".

A typical "Project Manager (PM)" focuses on maximizing the success of his or her own project, which can sometimes lead to a mismatch with the overall direction of the organization or with other projects.

Therefore, in order to achieve good results for the entire organization, we need to think about "maximizing the synergy of multiple projects".

The person responsible for this is called a "Program Manager (PgM)", and a group that aims to maximize the synergy between multiple projects is called a "Program".

As a side note, it supports the idea that "PO" in "OSPO" stands for "Program Office" when you see people presenting themselves with the title "OSPO Program Manager," leading activities in the OSPO organization.

What is the relationship between "Program" and "Project"?

Below is a simplified diagram showing the relationship between one "program" and the three "projects" that make up the program.

Although not detailed in this article, other components that make up the program include "subprograms" and "operations".

In addition, the Project Management Office (PMO), sometimes referred to as the "PjMO" to distinguish it from the Program Management Office (PgMO), is responsible for providing specialized support to individual projects or to multiple projects within the program, regardless of the project.

What are the "8 Principles" that should lead the work of a Program Manager ?

Referring to the "The Standard for Program Management 5th-Edition" ³ revised by PMI
¹ in April 2024, it includes "8 principles" that Program Managers (PgM) should follow when practicing "Program Management." These principles are outlined below.

In this article, I will provide my interpretation in simple words to avoid any misunderstandings.

Stakeholders

Getting program stakeholders on your side
(Not allowing stakeholders to say "NO" to the program)

Benefits Realization

Aligning program outcomes with organizational strategy to create value
(Everything the program produces must be meaningful)

Synergy

Optimizing the program by considering the complexity and interdependencies of multiple projects
(Creating more than what individual projects can achieve alone)

Team of Teams

Accepting change flexibly and adapting to various risks while pushing the program forward
(United teamwork among program members)

Change

Flexibly changing commitments made at the start of the program as needed
(Always being mindful of gaps between plans and reality)

Leadership

Strong leadership to drive the program toward its desired outcomes

Risk

Manage the risks (opportunities and threats) facing the programme and optimise the risk response plan

Governance

Creating and applying rules to run the program smoothly, and monitoring if these rules are being followed
(To increase the chances of program success)

What is the Role of an "OSPO Leader" According to PMI's Definition?

In the context of the "8 principles" that program managers should follow, let's replace some terms:

• "Program" => "OSPO Activities"
• "Project" => "Development Projects Using OSS"

We can then reinterpret these principles as follows for the "OSPO Leader" who manages OSPO activities.

In other words, the "Eight Principles OSPO Leadership Should Follow" can be interpreted as follows:

Stakeholders:

Align the interests of stakeholders involved in OSPO activities to gain their support.
(Ensure stakeholders do not say "NO" to OSPO activities)

Benefit Realization:

Align the outcomes of OSPO activities with organizational strategies to create value.
(Everything that OSPO activities produce must be meaningful)

Synergy:

Optimize OSPO activities by considering the "complex relationships" and "interdependencies" among various development projects using OSS.
(To produce results of OSPO organizational activities that go beyond what individual development projects can achieve with respect to the OSS)

Team of Teams:

Adapt to changes and various risks while driving forward OSPO activities.
(Ensure unity between OSPO leaders and members)

Change:

Flexibly modify agreements made at the start of OSPO activities as needed.
(Continuously maintain awareness of any gaps between current OSPO activities and their rules)

Leadership:

Exhibit strong leadership to advance OSPO activities toward desired outcomes.

Risk:

Manage the risks (opportunities and threats) facing the OSPO's organisational activities to optimise risk response planning

Governance:

Establish and adapt rules to effectively manage OSPO activities and monitor compliance.
(Enhance the likelihood of success for OSPO activities)

How do you feel about it?

You might find some points that you already recognize and agree with, thinking "That's important," and discover new perspectives, realizing "Oh, that's important too."

And in some cases, "Is this really that important?" and in some cases, there may have been points that were not so satisfying.

I think this is a "common feeling" when learning about management systems, so I would appreciate it if you could dig deeper and evaluate the points that you have questions about or disagree with.

Additionally, here is a simplified diagram showing the relationship between "OSPO activities" and the three "Development Projects Using OSS" that make them up. Other components like sub-OSPO activities or OSPO operations can also be included.

Closing Remaks

Thank you for reading to the end.

In this article, I have tried to look for tips on how to effectively promote OSPO activities and strengthen the organization's overall open source strategy from a different perspective than the existing one.

In organizations where OSPO awareness is low, it is not easy for OSPO leaders to embed the concept of OSPO and for OSPO leaders to lead OSPO activities.

I hope this article serves as a helpful resource in guiding your OSPO-related efforts.

1. Project Management Instituteの略。プロジェクトマネジメントの標準化を目的として研究と普及を推進する国際的な非営利組織。プロジェクトマネジメントに関するPMP（Project Management Professional）や、プログラムマネジメントに関するPgMP（Program Management Professional）などの国際資格の認定も行う。
   PMI stands for Project Management Institute. It is an international non-profit organization that promotes research and dissemination of project management and aims to standardize it. The institute also offers international certifications such as PMP (Project Management Professional) for project management and PgMP (Program Management Professional) for program management. ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸ ↩⁹ ↩¹⁰ ↩¹¹

2. PMIが策定したプログラムマネジメント標準。第5版が2024年4月にリリース。本記事を執筆した2024年11月末の時点で、残念ながら日本語版はまだ出版されていません。
   The Program Management Standard developed by PMI. The 5th edition was published in April 2024. Unfortunately, as of the end of November 2024, when this article was written, the Japanese version has not yet been published. ↩ ↩² ↩³ ↩⁴ ↩⁵

3. Project Management Body of Knowledgeの略。PMIが策定したプロジェクトマネジメント知識体系ガイド。
   Short for Project Management Body of Knowledge. It is a guide to the project management knowledge framework developed by PMI. ↩ ↩² ↩³