DX 時代 の 必修スキル「システム導入AtoZ」。

〇 AI導入は「プロジェクト」ではない？ プログラムの視点が不可欠な理由。

皆さんの企業では「プログラムマネジメント」を自社のIT戦略に組み込み、実践しているだろうか？ ここで言うプログラムは、JavaやCOBOLなどで書かれたソースコードのことではなく、プロジェクトの上位概念で「目的を達成するためにマネジメントする関連プロジェクトやサブプログラム、業務の集合」のことである。「ユーザーはプログラムマネジメントに本格的に取り組まないとまずい」と筆者は考えている。

ビジネスにおけるプログラムとは。

ソースコードのイメージを払拭していただくためにもう少し補足する（図1）。ITに携わっている中でプログラムと聞くとどうしてもJavaやCOBOLを思い起こすが、通常の会話では、運動会のプログラムやコンサートのプログラムのように使われる。これは、プログラムの語源がpro-（前に、公に）＋gram（書く）、つまり「前もって書かれ、公に示された手順や道筋」であることに由来する。運動会のプログラムは、徒競走や綱引き、玉入れなど、複数の競技から構成される。

図1、プログラムとは。

これをビジネスに置き換えると、プログラムの構成要素はプロジェクトや定常業務であり、超大規模プログラムになると、プログラム自体が階層構造を取る場合もある。プログラムは、経営とプロジェクトをつなぐ役割を果たす（図2）。

図2、プログラムとプロジェクトの関係。

どんな場合にプログラムマネジメントは有効か？

単独のプロジェクトとしてマネジメントするより、プログラムとしてマネジメントした方がよいケースを3つのパターンに分け、以下に示す。

① 段階的パターン。

プログラムを構成するプロジェクトを時間軸に沿って順次立ち上げ、段階的に仕上げる。図3に例として「データセンターの集約プログラム」を示した。社内に散在するサーバーを地域ごとにデータセンターへ集約し、情報共有の促進や運用効率の向上を狙う案件だが、一気にできる規模でなければ、最初に東京センターへの集約プロジェクトを立ち上げ、完了後に大阪センター、それからグローバルの拠点と段階的に集約していく。

図3、プログラムのパターン①〔段階的パターン〕。

このパターンが、最もプログラムマネジメントの概念をイメージしやすい。データセンターに集約する効果を組織全体で得るには、配下のプロジェクトに対して強いガバナンスが必要である。展開の順序（どのプロジェクトから立ち上げるか）、先行プロジェクトの経験や教訓を引き継いでいく仕掛けや体制、長期間にわたるため経営環境やステークホルダー、技術の変化への対応などがプログラムレベルでの課題である。

② 分割パターン。

大きなプロジェクトを細かく切ってプログラム的にマネジメントする。図4に例として「システム統合プログラム」を示した。企業統合に伴い、事業や業務の単位に分けて両者の相対するシステムを統合する。

図4、プログラムのパターン②〔分割パターン〕。

①の段階的パターンと異なるのは、同時に複数のプロジェクトが並行して走ることである。戦略的なシステムもあれば、品質を重視するシステムもあるなど、プロジェクトの特徴は、業務により異なり、関与するステークホルダーも異なる。筆者は、巨大プログラムにベンダー側のPMO（プロジェクト・マネジメント・オフィス）に在籍して関わったことがあるが、配下のプロジェクトを同じレベルで管理することはできない。どのように重点的に監視するプロジェクトを選ぶか、プロジェクトマネジャーなどの人的リソースの配分、状況を把握するための会議体やリポーティングといった、コミュニケーションルールの設定などがプログラムレベルでの課題である。

①段階的パターンと②分割パターンを根拠に「プログラムマネジメントが大事だ」と言っても説得力に欠けるかもしれない。事例が少ないため身近に感じる人は少ないと思う。筆者が、特に重要だと考えているのは、次の「DX（デジタルトランスフォーメーション）推進パターン」だ。

③ DX推進パターン。

人工知能（AI）などの新技術を適用してトランスフォーメンションを図る。ユーザー側でDXを推進するプログラムの典型的な進め方を図5に示した。業務部門もしくは技術に精通したIT部門から生まれたアイデアをもとに企画を立案する。企画が審議され、承認されると予算が付き、PoC（Proof of Concept）と呼ばれる実現性や効果を検証するいくつかのプロジェクトが立ち上がる。PoCの結果を評価し、Goなら実業務に適用するためのシステム開発プロジェクトが立ち上がる。そして、運用を含めてトランスフォーメーションの成果につなげる。

図5、プログラムのパターン③〔DX推進パターン〕。

以前のコラムで、トランスフォーメーションを主導するケースについて「単独のプロジェクトで考えるとプロジェクトの位置付けを定義しにくい」と書いたが（※1）、今回のテーマであるプログラムマネジメントは、これを受けている。DX推進プログラムは、新事業の創出やビジネスプロセスの変革に結び付いて初めて成功と言える。PoCや個々のプロジェクトがうまくいったというのは、プログラムの視点ではマイルストーンにすぎない。このために企画段階で、一連の流れをプログラムとして定義することが大事である。

※1 関連記事：そのプロジェクトは本当に成功したのか、業務アプリ開発で一番重要なこと

DX推進の問題点として、トランスフォーメーションではなく「ツールの導入自体が目的化してしまった」、あるいはPoCについて「いつの間にか予算を超過している」、「いつの間にか立ち消えになっている」、「テーマが変わっている」、「いつの間にか本稼働して実業務で使っている」、「PoCが終わらない」などが挙がってくる。PoCや配下のプロジェクトの位置付けを明確にし、プロジェクトマネジャーの上位職としてプログラムマネジャーの役割と権限、責任を明確にすることが解決の糸口になる。特に「PoCが終わらない」については、当事者のプロジェクトマネジャーが打ち切る決断をするのは難しい。上位職のプログラムマネジャーの介入が必須である。

だが、プログラムマネジメントは、どうも影が薄い。試しにWebサイトで「プログラムマネジメント」と入力して、検索してみてほしい。プロジェクトマネジメントに比べて圧倒的に情報が少ない。なぜこんなことになっているのだろう？ プロジェクトマネジメントに携わる者として、筆者にも責任があることは重々承知だが、少し考察してみたい。

プログラムマネジメントの技術を真に必要とするのはユーザー側。

前節で示した関連記事にも書いたように、業務アプリ開発プロジェクトは、ニーズのあるユーザー側で立ち上がる。その延長でユーザーがベンダーに開発を発注する。プログラムも同様で、ユーザー側で立ち上がる。では、発注についてはどうだろうか？ 審議や評価のゲートを含むプログラムを丸ごと発注するケースはまずないと考える。DXに関しては、自前で開発することが増えているが、発注するならプロジェクト単位、企画段階のコンサルテーション、PoCの共同実施という形が多いだろう。PoCは、新しい技術のノウハウを蓄積したいという思惑がベンダー側とユーザー側で一致する。

となるとベンダーがプログラムマネジメントに取り組む機会はなく、関心も高まらない。ベンダーからノウハウが提供されることを期待できない。ベンダーが行うパッケージ開発はどうだろう？ 確かにプロトタイプの作成からβ版開発など、一連のプロジェクトを通して製品化する。ただ、ここで求められるのはプログラムマネジメントではなく、ヒット商品を産み出すために必要なプロダクトマネジメントである。

プログラムマネジメントは、ユーザー側で取り組むべきテーマだと思うのだが、いかがだろうか？ プログラムマネジメントもプロジェクトマネジメントと同様、頭で考えているだけではダメで、実戦経験の中からしかナレッジは獲得できない。