こんにちは、モノタロウの EC サイト開発グループに所属している田上といいます。
モノタロウには 2019 年に中途で入社し、入社以来ずっとフロントエンドまわりのことに携わっています。最近は開発業務ではなくプロジェクトマネジメントなどのマネジメント業務をすることが多いです。
さて、どんな企業でも、新規事業の立ち上げや既存事業の改善など、複数のプロジェクトが並行で進むことはよくあることかと思います。
しかし、それらを推進していく中で、
- A プロジェクトの成果として改善した ○○ の指標が、B プロジェクトの結果によって相殺されてしまった！
- △ さんがいろんなプロジェクトで引っ張りだこになって、結局どのプロジェクトもその方がブロッカーとなりうまく進まなかった！
みたいな事態に遭遇したことはないでしょうか？
こういった「複数のプロジェクト間で目標や成果、リソースのバッティングが発生して成果が最大限に出せていない」という状況が、モノタロウのサプライチェーン領域の改善においても発生していました。
今回はそういった事態に立ち向かうために “プログラムマネジメント” というマネジメント手法を取り入れてみたので、
- 具体的に何をどうすすめたのか？
- その結果どうだったのか？
についてお話していきたいと思います。
- ことのはじまり
- そもそも “プログラム” とは
- プログラムマネジメントは何をするのか
- モノタロウにおいてプログラムマネジメントをどう実践したか
- 導入した成果
- ふりかえってみて思う難しかったところ
- おわりに
ことのはじまり
2022 年の 8 月、会社全体としてやるべきことを整理しているときに、サプライチェーンに関連するやりたいことを並べてみると複数のプロジェクトが並行で進むことがわかりました。
これらのプロジェクト群は
- 最終的に改善したいビジネス目標が同じである
- 改善したい領域（サプライチェーン・調達領域）が同じである
という性質を共通して持っており、個々のプロジェクトマネジメントだけではプロジェクト間の連携をうまくすることができず、最大限の成果が発揮できないことが予想されました。
具体的には、まず、「最終的に改善したいビジネス目標が同じである」場合は、各プロジェクトの目的や方向性を揃えないと最大限の成果が出ない可能性が出てきます。
極端な例でいうと、あるプロジェクトが出荷遅れ率を改善しようと施策を実施したとしてその結果出荷遅れ率は改善したが同時に受注件数も減少したとします。この時一方で別のプロジェクトが受注件数を増やそうと施策を実施していた場合、本来受注件数の改善施策として 100 の効果が出ていたところ、別の施策の効果によってその成果が軽減されてしまう可能性が出てきます。
そのため、全体として何を重要視して改善をしていくのか・各プロジェクト間でのトレードオフ関係はないかということを統合的に管理していく必要が出てきます。
次に、「改善したい領域が同じである」場合は、リソース（人員）・開発箇所 のバッティングが発生する恐れが大きくなります。
このとき、優先度を明らかにする・重複が発生しないようにするといった調整をしないと、本来一番推進したいプロジェクトの進捗が遅滞する可能性が出てきます。
そこで、これらの問題発生を防止し円滑なプロジェクト推進をしていくための手段として複数プロジェクトの統括マネジメント 、”プログラムマネジメント” というものを導入することになりました。
2023 年 1 月から “プログラム” として体制を組成し動き始めることになり、私はその体制においてプログラムマネージャー（プロジェクトでいうところのプロジェクトマネージャーのようなロール）を務めることになりました。
しかし、実際のところその時の私は「プログラムマネジメントっていう言葉自体は PMBOK*1 で見たことがあるような気がするな〜」くらいの認識しかなく、具体的に何をどう進めていいのかわからない状態でした。
そこで、まずはプログラムマネジメントという手法について調べるところから始めました。
そもそも “プログラム” とは
プログラムとは、一般的には「ビジネス戦略を達成するための一連の複数のプロジェクトの集まりのこと」と定義されています。
急にいわれてもあまりピンときませんよね。
少しだけ抽象化した原理・原則の話に立ち返ってお話すると、モノタロウでは、”会社 → 部門 → グループ・チーム” というレイヤー階層があり、そのレイヤーひとつひとつに
- 目的：達成したいことは何か
- 戦略：そのために何をいつ実施するのか
- 戦術：それらは具体的にどうやるのか
が決まっています。そして、上位レイヤーの “戦略・戦術” は下位レイヤーの “目的・戦略” として落とし込まれる、という構造になっています。
レイヤー構造は多少異なるかもしれませんが、他の会社でも同じ構造になっているところはあるのではないかと思います。
これをプログラムに置き換えると以下のようになります。
つまり、プログラムの定義でいう「ビジネス戦略を達成するための一連のプロジェクト」とは「会社で策定した戦略を共通の目的として取り組むプロジェクト群」と言い換えることができます。
そのため、プロジェクトと比較してみると、実施期間や成功基準というところに違いが出てきます。
プログラムマネジメントはビジネス戦略の達成のために
- 各プロジェクトの目標をビジネス戦略と一致させること
- リソース・リスクなどを俯瞰的に管理し各プロジェクトを成功へ導くこと
を責務として動いていくことになります。
プログラムマネジメントは何をするのか
プログラムマネジメントにおいて具体的に実施することは大きく分けて以下の 4 つに分類されます*2。
- プログラム憲章の作成
- ビジネス戦略・ベネフィット*3 の定義・管理
- リスク・課題・品質といった諸般のマネジメント
- プロジェクト間の依存関係の調整、優先度整理
1. プログラム憲章の作成
プログラムの計画・マネジメントに対する責任を確立するために、以下のようなことを記載した文書を作成・公表します。
- プログラムの目指すもの（ビジネス戦略）
- プログラムの成功基準
- プログラムとして管理するPJ群と各成功基準
- プログラムをどう管理するか
2. ビジネス戦略・ベネフィットの定義・管理
プログラムにおいて、
- 達成したいビジネス戦略は何か？
- それによって得られるベネフィットは何か？
を定義し、プログラムに参画しているメンバーが認識できるようプログラム憲章などに起票して管理していきます。
なお、ビジネス戦略の達成によって得られるベネフィットについては、プログラム開始直後から全容が明らかになっているケースはあまりありません。
例えば、「顧客満足度の向上が得られる」というのがベネフィットだったとして、満足度を具体的にどう測るのか？といったそもそもの定義があいまいなケースもあれば、各種プロジェクトを推進していく中で状況に応じて「○○ セグメントにおける顧客満足度の向上」という風に変化していくこともあります。
そこで、ベネフィットはプロジェクトの推進状況に応じて ”特定→分析” の過程を何度か繰り返して詳細化していく必要があります。
3. リスク・課題・品質といった諸般のマネジメント
プロジェクトマネジメントにおいて、スコープマネジメント・コストマネジメントなどいくつかのマネジメント領域が定義されているかと思いますが、それと同じようなマネジメント領域がプログラムにおいても定義されています。
プロジェクトマネジメントについてご存じの方は見ていただくとわかる通り、マネジメント分類についてはプロジェクトマネジメントの考え方と同じです。
しかし、プログラムマネジメントではマネジメント対象が “プログラム” となるのでカバー範囲が広くなったり、それに付随してアプローチの仕方が変わったりと、プロジェクトマネジメントとは多少やり方が異なってくる部分があります。
4. プロジェクト間の依存関係の調整、優先度整理
プログラムに包括されているプロジェクトは基本的には関連性の深いプロジェクトばかりです。
そこで、
- 各プロジェクトの境界線、つまりそのプロジェクトのミッションは何なのかというところを明らかにしプロジェクト間で必要な連携を明らかにする
- その状態を維持しつつ、必要に応じてプロジェクト内外で優先度を調整する
といったことを行うことで、ビジネス戦略達成のためにプログラム全体として重要な事項が推進されるような環境を整える必要があります。
とはいえ、これだけでは実際に何をどうしていけばいいのかイメージを付けづらいと思うので、モノタロウではどう実践していったのかを具体的に見ていきたいと思います。
モノタロウにおいてプログラムマネジメントをどう実践したか
1. プログラム憲章の作成
プログラム憲章は、プログラムの体制を組成してから一番初めに作成を始めました。
実際に作成したドキュメントの目次は以下のような形になっています。
プログラムの目的
今回のモノタロウでいうと “サプライチェーンの改善” というのがプログラムの目的として挙げられますが、それだけ聞いても何を目指しているのかわかりませんよね。
そのため、「そもそもなぜ改善をやりたいのか」という背景や「改善をした先で何を達成したいのか」ということを誰が見てもわかるような粒度で書いていく必要がありました。
私自身はプログラムマネージャーという役割で、背景や戦略の部分をどうしたいのかという意思決定権を持っていなかったため、それらについて意思決定権を持っているプログラムオーナーの方と丁寧に認識を合わせたうえで言語化を行っていきました。
作成した後は、実際にこの憲章を読むよう促す機会が多くあるわけではなく、どちらかといえばここで整理した内容をベースとして期ごとのキックオフなどで改めてメッセージとして伝えていくことで参画メンバーへ意識付けをしていきました。
プログラムの対象範囲
プログラム発足当初は、9 つのプロジェクト（主要メンバーが 50 名程度）が紐づいていました。まずは各プロジェクトごとに以下の項目を書き出して一覧化していきました。
- プロジェクトオーナーがだれか
- 何をするのか（プロジェクトの概要）
- 何を達成したら完了するのか（プロジェクトの完了条件）
また、各プロジェクトごとに期ごとに「何をどこまで達成するのか」という OKR を策定していただき、それをもとに全体のマイルストーンを作成するようにしました。
リスクと課題
プロジェクトと同じようにプログラム全体としてもリスク・課題を管理していきますが、各プロジェクトで出たものを一元的に管理するわけではありません。
各プロジェクト内で完結するもの・解決をすべきものに関しては各プロジェクトごとに管理していただき、プロジェクト内での解決が困難と判断したものや他のプロジェクトでも共通であると判断したものはプログラムの課題やリスクとして管理していくという形にしました。
そこで、
- どういう時にプログラムマネージャーにエスカレーションをしてほしいのか
- どこで伝えてほしいのか
といったことを明記しました。
実際は「プログラムの課題なのかプロジェクトの課題なのかわからないんですが…」という問い合わせがきて都度調整をすることが多かったですが、必要があればエスカレーションをしてほしいことを記載しておくことで、判断に迷うケースも気軽にお声がけいただけるようになりました。
プログラム・ガバナンス
プロジェクトのマネジメントは個々のプロジェクトに一任しているのですが、プロジェクト同士の連携だったりステアリングコミッティへのコミュニケーションといったプログラム全体としてコントロールをする必要がある部分についてはルールを策定していきました。
特に気を付けた点としては、関係プロジェクトが多いのでプログラムマネージャーが各プロジェクトの誰とコミュニケーションをとっていくのかコミュニケーションパスが明確になるように体制図を作成しました。
関連ドキュメント
いくつか作ったドキュメントはあるのですが、一番早い段階から作成を始めたのは用語集でした。
というのも、当時紐づいていた 9 つのプロジェクトは、プログラムが組成される前から個々に推進されていたプロジェクトもあれば、今後始動していくプロジェクトもあり、参画メンバーの知識レベルが必ずしもそろっているわけではありませんでした。
実のところ、かくいう私もプログラムマネージャーに任命されるまではサプライチェーンの領域には一切関わったことがなく、わからない言葉にあふれている状態でした。
そこで、参画メンバーの知識の平準化やキャッチアップの平易化を目指して用語集の作成を始めました。
私一人ではそもそも何がわからないのかわからない状態だったので、プロジェクトメンバーに対して以下のようなお願いをして起票をしていただき、各用語の意味についても詳しい人に記入いただくようにお願いして、みんなで作成を進めていきました。
実際に作成した用語集はプロジェクトの統廃合などで新しいメンバーが参画した際に「キャッチアップするのに助かった」という声をいただいています。
2. ビジネス戦略・ベネフィットの定義・管理
各プロジェクトのメンバーは基本的には自分たちのプロジェクトの成果にどうしてもフォーカスを当ててしまって、その背景にあるビジネス戦略が同じであるということにはなかなか意識が向きません。
しかし、そこを認識していないと各プロジェクトでの意思決定が誤った方向に向いてしまう可能性が出てきます。
そこで、
- ビジネス戦略や目的として何があるのか
- それを実現するための手段どしてどういうプロジェクトがあるのか
- それを達成したら得られる利益、ベネフィットはどういうものなのか
という紐づきを理解して動いていける状況やキャッチアップするための手段を作る必要がありました。
その手段として、はじめに “ベネフィットリング”、ベネフィット達成のために関係する複数プロジェクトの成果の関連性を俯瞰して可視化した図を作成しました。
しかし、実際にプロジェクトを推進していくと別の課題が出てきました。
まず、プログラムとして管理していたプロジェクトの多くは探索型（プロジェクト開始時にゴールが決まっておらず色々検証をしながらゴールを定めていくような）プロジェクトが多く、プロジェクトのゴールをただちにきっちり決めるのが難しい状況にありました。
例えば「○○ の仕組みを使える取引先企業を増やして成果を拡大していこう」としていたプロジェクトがあったとして、推進していく中で「対象となりうる企業は全体で数千もいるが、どこまで拡大できればゴールといえるのか？」と途中でゴールの境界線がわからなくなる、といったケースです。
とはいえ、いつまでもゴールがない状態で推進するわけにはいきません。プロジェクトは永続的に続けるものではなく終わりを決める必要があります。
そのゴールを決めていくためには
- どういう指標を見ればよいのか
- その指標を測るためのデータが揃っているのか
- プロジェクト間での成果の依存関係はどうなっているか
- 各指標のインパクトはどれくらいか
といったことを明らかにしていく必要がありました。
また、この各プロジェクトで追うべき指標やその全体像が分からないことによってプロジェクト内で決断をしづらく、意思決定スピードが遅くなってしまうという別の課題も発生していました。
例えば、あるプロジェクトで「出荷遅れ率(下図青枠)を改善したらよさそう」という目星をつけられたとして、上位の KPI や周辺の KPI の解像度が低いと「改善しよう」と断言することができずにプログラムオーナーに判断を仰いでしまう、といったケースです。
そこで、まずは各プロジェクトの KPI を整理していくことにしました。
ただ、プログラムマネージャーだけでは知見が足りないところも多々あったのでサプライチェーン周りの数値に詳しい方を集めてアナリストチームを組成し、各プロジェクトの効果計測をサポートしていただきながらプログラム全体としての KPI の整理を進めていくことにしました。
実際、アナリストチームの方に動いていただくことで KPI の分解や KPI レポートのダッシュボード化などを進めていただくことができました。
今後はダッシュボードをさらにブラッシュアップして、定期的にプログラムのメンバーで数値目標を監視するといった運用を始めようと考えています。
3. リスク・課題・品質といった諸般のマネジメント
マネジメント領域として定義されている分類も多く、やったことをすべて挙げると枚挙にいとまがないので、いくつかピックアップしてご紹介させていただきます。
各プロジェクトの定例 MTG への参加
プログラムマネージャーとして各プロジェクトの進捗を把握するのはもちろん、リスク・課題の顕在化の検知や状況変化の検知をする必要がありました。
プログラム全体として進捗を報告していただく場はあったのですが、プログラム組成当初はそもそも各プロジェクトメンバーが普段どうプロジェクト推進をしているのかもわかっていない状況だったのでそこのキャッチアップの意味も込めて、基本的にはすべての定例 MTG には参加するようにしました。
参加することで、プログラムマネージャーにエスカレーションすべき事象のキャッチアップがしやすくなったケースもあったのですが、他のプロジェクトとの依存関係がそこまで複雑でないプロジェクトにおいては全体の報告 MTG で要点だけお話いただくだけで十分ということもありました。
PO MTG の開催
先ほども少し触れた通り、プログラムで管理していたプロジェクトは探索型プロジェクトが多く、頻繁に方針の変更などが発生していました。
その中で、ビジネス的な観点を踏まえて意思決定を行うためにプログラムオーナーにエスカレーションをしなくてはならないケースも多くあったのですが、それまでは月一の頻度で進捗報告をする会議体しかなく判断を仰げる機会がほとんどありませんでした。
そこで、以下を目的として PO MTG（プロジェクトオーナー ミーティング）というのを隔週で開催していくことになりました。
- プログラムオーナーとのコミュニケーション
- 各プロジェクトのオーナー同士での情報共有・相談
- 各プロジェクトのプロジェクトオーナーが集まって話すことで全体として統一した意思決定の促進
ただ進捗を報告するだけではなく相談を行える場という形で設けたことによって、プログラムオーナーへの話を通しやすくなったのはもちろん、プロジェクトオーナー同士で必要な情報共有も促進することができました。
ワークショップの開催
プログラムの関係者は主要なメンバーだけでも 50 名程度おり、しかも複数部署の人が集まっていたので、当然顔と名前が一致しない人もいる状況でした。
しかし、同じ目標に向かってプロジェクトを推進していく関係上、プロジェクト間の連携は基本的には必須になってきます。
この連携を少しでもスムーズにするために、誰が何をやっているのかを知るとともに心理的安全性を少しでも上げる必要がありました。
また、プログラムの背景や目的の共通認識を持ったり、必要な知識の平準化を行うことで、各プロジェクトが同じ目標に向かって一丸となって進んでいける土台作りが必要でした。
そこで、主要メンバーをオフラインで一堂に集め
- プログラムの背景・目的の共有
- 業務・システム知識の平準化
を行うための MTG を丸一日かけて開催しました。
知識の平準化では商品の登録から配送までのモノタロウの業務における一連の流れについて理解を深めるために “バリューストリームマッピング” と “イベントストーミング” という 2 つの手法*4を用いてワークショップを行いました。
範囲が広いので「一度ですべてを理解してもらおう」ということを目的としたというよりは、一通り話を聞くことで
- どういう業務があるのか
- 自分が詳しくないところはどこなのか
- そこは誰が（どの部署が）担当なのか
- そこは誰が詳しいのか
をまず理解していただくことを目的としていました。
その後、実際にプロジェクトを推進していく中で
- フロントエンドシステムのことだからとりあえず ○○ さんに聞こう
- △△ 業務のことだから ×× 部門の人に聞けばよさそう
といった形でプロジェクトメンバー同士がスムーズにコミュニケーションを取れている様子がちらほら見られるようになりました。
4. プロジェクト間の依存関係の調整、優先度整理
プロジェクト憲章の作成の項目でも述べたように、まずはどんなプロジェクトがあり、それらは何を達成しようとしているのかというのを整理していきました。
そのうえで、各プロジェクトの定例 MTG に参加する中で依存関係がある部分や連携が必要な箇所、進め方が曖昧な部分などを検知して、その都度関係者を集めて認識をすり合わせる MTG を実施していきました。
ここまでのやったことを振り返って総括してみると、まず、プログラムとしてのサイクルとプロジェクトとしてのサイクルの2 種類があり、プログラムマネジメントでは、
- プログラムのサイクルがきちんと回るようにリード（責任をもって管理・推進）していく
- プロジェクトのサイクルが円滑に回るようにサポートしていく
ということを基本的にはやっているのかなと思います。
導入した成果
プログラムマネジメント自体は現在進行形で継続しているので最終成果について触れることはできないのですが、約半年程進めてみた時点で、各プロジェクトのプロジェクトオーナーに感想をヒアリングしてみました。
導入してよかった点
- 関連しているプロジェクト間の影響・依存がある部分を検知し調整してもらえたこと
- プロジェクトのほうで個別に確認・調整する必要がなくなり、目の前のプロジェクトに集中することができた
- 自分たちが解決しようとしている課題を他のプロジェクトが別のアプローチで解こうとしている、という事態を防いでもらえているという安心感があった
- 将来的な目標など含めた全体的な視点でプロジェクトの整理をしてもらえたこと
- プロジェクト内ではスモールスタートを重要視していて、将来の話をなかなかできてなかったので
今後期待する点
- この取り組みの経緯が分かるような資料の作成
- プログラムマネジメントの仕組み化（標準化）
ふりかえってみて思う難しかったところ
はじめ、右も左もわからない状況から始まったところを思うと幾分やるべきことが見えるようになったと思いますが、当初を思い返すと難しかったなと思う点が 2 つあります。
必要になる知識の幅が広くて複雑
今回モノタロウでプログラムマネジメントを導入した領域においては、商品の調達からお客様の手元に商品を届けるまで、モノタロウの業務フローの一から十まであらゆるポイントが改善対象となっていました。
そのため、全体のフローをざっくり把握しておかないと各プロジェクトの話についていくのはとても難しい状況でした。
また、私はこれまでフロントエンド開発に関連するプロジェクトにしか携わったことがなく、バックエンドシステムや業務フロー改善がメインのプロジェクトは門外漢であったこともあり、把握しておいたほうがいい知識の量が圧倒的に多かったです。
これは今回の領域特有の話かといわれるとおそらくそういうわけではなく、プログラムという単位になると自然と守備範囲が広がるので認知しないといけない範囲は広がっていくんじゃないかなと思います。
全体像が不確定
最終的に目指すところ、ベネフィットやビジネス戦略は明らかなのですがそこに至るまでの道筋はいくつも分岐があり、例えば、
- どういう指標を改善するかという選択肢が多くある
- この指標もプロジェクトの進捗など状況によって変化していく
- この指標を改善しよう！となった時も改善するための手段は複数ある
といった感じで、何が最適といえるか？は正直不明瞭な状態でした。
この課題は現在もまだ完璧に解決したとは言えない状況ですが、KPI 構造の整理を進めながら明確化していこうと考えています。
おわりに
今回は、モノタロウのサプライチェーン領域の改善において発生していた「複数のプロジェクト間で目標や成果、リソースのバッティングが発生して成果が最大限に出せていない」という状況への対処として “プログラムマネジメント” という手法を導入したお話を紹介しました。
はじめ、プログラムマネジメントについて調べたとき、「それは何者なのか？」といった概念の説明がされている読み物は見つかるのですが「具体的にどう実践していけばいいか？」といったことが説明されている資料は少なく、ベストプラクティスが何かというところは正直よくわかりませんでした。
そんな中で、モノタロウにおける最適解は何かを模索しながら実践をしていった結果をご紹介させていただいたので、同じ課題を持っていてもやり方が適さない部分はあるかもしれません。ただ、一つの事例として少しでも参考になれば幸いです。
また、今回ご紹介させていただいたプログラム以外にも、モノタロウでは色々なプロジェクトが企画され推進されています。プロジェクトマネジメントや複数のプロジェクトを統括してマネジメントすることに興味のある方は、カジュアル面談も実施していますので、ぜひ カジュアル面談登録フォーム よりご応募ください！
*1:『プロジェクトマネジメント知識体系ガイド（PMBOKガイド）第7版』に記載があります。
*2:今回、プログラムマネジメントについて調べる際に以下の書籍・サイトを参考にさせていただきました。
- 『プログラムマネジメント教本』 ― アンリ近藤 (2022)
- プログラムマネジメントの完全ガイド | Asana
- プログラムマネージャーとプロジェクトマネージャーの違いで知っておくべきポイント | Asana
*3:ここでいうベネフィットとは金銭的な利益のことではなく、サービスや機能などなんらか施策を行った結果として得られる恩恵（例えば改善の結果、顧客満足度が上がりました・それが上がった結果お客様の離脱率が低減しました、など）を指しています。
*4:バリューストリームマッピングについては、モノタロウの他のプロジェクトでも活用されており、その時実施した内容はワークショップの開催にご協力いただいたクリエーションライン株式会社様にて記事が作成されていますので、ご興味のある方はそちらも御覧ください。 https://www.creationline.com/clientvoice/case29
