プログラムマネージャーについて話すときにモヤモヤするのはなぜか
Rebuild.fm 126: Anti-Democratic Product Management (higepon) で Technical Program Manager について言及があった時に、「アジャイルでスプリントを回すとか、大きい意味での会社の依存関係を解決する。」「スクラム マスターのようなもの。」というような形で表現されていましたが、日本ではプログラム マネージャーをあまり見かけませんし、プログラム マネージャーをしている人を見ても結局何をする人なのかよくわからない、という方もいるかと思います。
そこで、プログラム マネージャーがどういう役割なのか、その補足説明をしてみよう思います。ちなみに予め断っておきますが、私自身はプログラム マネージャーがいる組織に在籍したことはありませんし、日本ではそのような組織の存在もあまり聞いたこともありません。また、プログラム マネージャーがいる企業（北米や西ヨーロッパ諸国等含む）でも働いたことはありませんので実情がどうなのかはほぼ知りません。その辺りは差し引いて読んでもらえればと思います。
プログラム マネージャーとは
まず、プログラム マネージャーのプログラムですが、これはコンピューターを動かすプログラムのプログラムではありません。アポロ プログラム（アポロ計画, Apollo program）のような意味でのプログラムなのですが、ではプログラムとは計画なのかと言われるとそれにも少し注釈が必要だと考えていて、例えば PMI （プロジェクト マネジメント協会）ではプログラムをこのように定義しています。
個々にマネジメントすることでは得られないベネフィットを実現するために、調和のとれた方法でマネジメントされる、相互に関連するプロジェクト、サブプログラム、及びプログラム・アクティビティのグループと定義している。(...)プログラムとは、企業戦略を実行し、事業または組織のゴールと目的と達成するための手段である。[1]
少し抽象的なのと横文字が多くてわかりにくいですが、企業が持つビジョンとミッション、それに繋がる企業戦略に沿って決定された投資対象や資源の分配、提供する価値、ビジョンの達成方法（ポートフォリオ マネジメント）をベースとして実際に（有期で）活動をする単位、せっかくアポロ計画を引き合いに出したので、一例にしてみればこのような感じでしょうか。
- アメリカ合衆国のビジョン
- 上記ビジョンに基づいたアメリカ合衆国のミッション
- 上記ミッションを達成するための戦略
- 宇宙開発、宇宙空間の平和目的あるいは軍事目的における長期間の探査のために NASA を設立（ポートフォリオ）
- 人間をつきに送り、安全に帰還させる目的でアポロ計画を開始（プログラム）
- ロケットの打ち上げ、宇宙船の設計開発、遠隔通信手段の確立と実装など（複数のプロジェクト）
Podcast 内の higepon 氏の「すごく偉い人達にレポートをすることをやっている人もいる」という発言も、上の例に照らし合わせると企業戦略により近い人に対して、コスト実績やスケジュール、予算等のフィードバックを行っているということでプログラム マネージャー（上記のような計画をマネジメントする人）の実態が垣間見えてくるのではないかと思います。
さらに少し上記とは異なった視点でアジャイルな文脈を含みますがアジャイル ソフトウェア要求からプログラムマネジメントに関連する部分を引用してみます。
(...)プログラムレベルでは顧客向けのプロダクト、システム、アプリケーションスイート全体を納品するというより大きな企業の目的のために、複数のチームを制御するメカニズムを提供する組織、プロセス、要求のモデルがある。チームレベルでは、チームは権限を委ねられ、かなり自己組織化し、自己管理している。チームは、チームのプロダクト オーナーの管理下にあるローカル バックログに基づいて開発を行う。(...)ところが、プログラム レベルでは課題が変わり、この一段大きな規模でアジャイルさをうまく実行するためのさらなる課題に企業は直面する。このレベルの目的には以下が含まれる。
ビジョンとロードマップを維持する
プログラムに対するビジョンを継続的に定義し、伝えるとともに、チームが共通の目的に向かって開発を行えるようにロードマップを維持する
リリース管理
企業が選択した開発のリズムでリリース インクリメントを構築するために、複数のチームの作業を調整する。
品質管理
複数チームの開発結果を集めたもの（システム）が定期的に統合されるようにする。それらでは性能、セキュリティー、信頼性に関する要求や、守らねばならない外部の標準が満たされている。
配置
チームがシステムをエンド ユーザーに届ける能力、責任範囲、権限を持たないような場合、この重要な作業はプログラム レベルで管理されなければならない。
リソース管理
タイムリーに求められる価値を納品するというプログラムの能力における制約やボトルネックに対処するために必要なリソースを調整する。
障害を取り除く
プログラムのリーダーや管理者は、チームの制御の及ばない致命的な問題のような複数のチームから沸き起こる障害を取り除く責任も担う。[2]
それでもプログラム マネージャーが実務として何をしているのか想像しにくいでしょうか。その場合、アポロ計画を開始するところをソフトウェアもしくはプロダクトのリリース（による価値の提供）に置き換えてみてはどうでしょうか。
実は、アジャイルソフトウェア要求第 14 章には、中規模以上のソフトウェア企業やプロダクト志向の会社では、上記のプログラム レベルのマネジメントを実施する役割としてより明確にプロダクト マネージャーという役割が担っていると書かれています。詳細は続く第 15 章及び 16 章を読んでもらうのが良いかと思いますのでここでは省略しますが、その役割として戦略的な目標をチームのメンバーと共有/方向性を揃えたり、プロダクト開発のリズムを作ったり（アジャイルリリース列車）することが挙げられています。
プログラムとしてプロダクトを考えた時、例えば昨今の SaaS 企業を始めとしたプロダクトの頻繁なリリースは上記の内容を非常に短い期間で行っていることに他ならないかと思います。そういう意味では higepon 氏が所属する組織で元（テクニカル）プログラムマネージャーがプロダクトマネージャーに着く事例があったというのはキャリアとしてはそれほど不自然ではない気がします。
※ただし、PMI が想定するプログラム マネージャーとアジャイルソフトウェア要求が想定するプロダクト マネージャーの役割は価値を提供する対象の違いやプログラムの性質の違い等から必ずしも同じことを行うわけではないと思います。
さて、プログラム マネージャーが上記のような活動をする一方、引き合いに出ていたスクラム マスターの役割についてスクラム ガイドを引用すると以下の通りとなります。
スクラムマスターは、スクラムの理解と成立に責任を持つ。そのためにスクラムマスターは、スクラムチームにスクラムの理論・プラクティス・ルールを守ってもらうようにする。
スクラムマスターは、スクラムチームのサーバントリーダーである（訳注：メンバーが成果を上げるために支援や奉仕をするリーダーのこと）。スクラムマスターは、スクラムチームとやり取りをするときに役に立つこと／立たないことをスクラムチームの外部の人たちに理解してもらう。スクラムマスターは、こうしたやり取りに変化をもたらすことで、スクラムチームの作る価値を最大化する。[3]
冒頭で断った通り、実際の企業規模や組織構造に依存して必要な役割は変わってくるので、常にこうだ、ということではありませんのでプログラム マネージャーがスクラム マスターを兼務している可能性については言うに及びません。しかしながら、定義上の役割だけではなく一方がマネージャーであるのに対して他方はリーダーであるとすれば、2つの役割は大きく異なっていると思われるので兼務は大変そうだな、という印象です。
脚注
[1] Project Management Institute, Inc.(PMI)(2013). The standard for program management third edition. PMI（プロジェクトマネジメント協会日本支部（訳）(2013). プログラムマネジメント標準 第3版 プロジェクトマネジメント協会日本支部）(pp. 4-5)
[2] Dean Feffingwell (2010). Agile software requirements. Addison-Wesley Professional（ディーン・レフィングウェル オージス総研（訳）（2014）. アジャイルソフトウェア要求 翔泳社）(pp. 54-55)
[3] Ken Schwaber and Jeff Sutherland (2013). The scrum guide. http://www.scrumguides.org/docs/scrumguide/v1/scrum-guide-us.pdf（角征典（訳）(2013). スクラムガイド http://www.scrumguides.org/docs/scrumguide/v1/Scrum-Guide-JA.pdf）(p. 6)
