プロジェクトマネジメントはプロダクトマネジメントに接近する
この記事はアドベントカレンダー「PM（プロダクトマネジメント/プロジェクトマネジメント） Advent Calendar 2024」の12月13日の記事として書いています。
今回は日常、情シスでプロジェクトマネジメントをしていながら、実はプロダクトマネジメントをしているんじゃないかという個人的な疑問みたいなことを書いてみたいと思います。
プロジェクトマネジメントとプロダクトマネジメントの対比
まずはプロジェクトマネジメントとプロダクトマネジメントの内容というか立ち位置みたいなものを比較してみます。あくまでも一般的というか、若干はワタクシの偏見みたいのも入っているのはご容赦ください。
プロジェクトマネジメント
プロジェクトマネジメントは基本的に作るべきもの（要件や仕様）が決まっていて、それを構築していくためのコストとスケジュールをマネジメントするのが基本形です。事前にしっかりと要件定義を行い仕様を決めて、その要求仕様というか約束した機能に対してSIerがコストとスケジュールを提案して完成請負契約で受託するのにとても適した方法であるウォーターフォール手法のもとで発展してきました。約束するものはコストと納期です。
プロダクトマネジメント
プロダクトマネジメントの背景はコスト（チーム）とスケジュール（評価されるサイクル）と目的・目標だけが決まっていて、その目標・目的のために必要な機能を考え、ステークホルダーと合意し、その優先順序を決めて開発チームと合意していく事で約束された目的や目標を達成していくためのマネジメントで、アジャイルやスクラムによる継続的な機能強化で発達してきています。そして約束するものは製品やサービスによるビジネス成果です。
こう考えるとプロジェクトマネジメントとプロダクトマネジメントとはイメージは近いもののけっこうベクトルが反対方向な事がわかると思います。
情シスではプロジェクトマネジメントもプロダクトマネジメンとも一緒
しかしながら情シス、つまりユーザー企業のシステム導入・開発の現場ではまぁまぁ一緒くたに扱われているのが現実だったりします。どちらにせよなんかシステムなりプログラムのようなものを作ることは変わらないですし、経理的には投資案件、つまりはビジネス効果を生むもの（プログラム・プロダクト）を完成させて無形固定資産にする・・・経理的、予算的には同じようなものなので、偉い人たちから見れば一緒なのです。
というわけで役割や開発のスタイルがどうあっても「プロジェクトマネージャ」がそのマネジメントを担うことになったりします。
特にJTC（ジャパン・トラディショナル・カンパニー）においては、慣れ親しんできたSIerに丸投げ委託（ウォーターフォールですらない何か）のスタイルで馴染みのある「プロジェクト」という言葉が頭から離れないのです。その裏はいい加減な要件でわがままな変更をしつつSIerからバッファやリスク費用をぼったくられ続ける〜その裏では担当するエンジニアが・・・・みたいなブラックな世界が渦巻いているのですが・・・・
そんなんだからアジャイルを「途中で要件変えてもOKな開発」みたいにしか考えていないのです。つまりはプロジェクトマネジメントで充分と思うわけです。
「プロジェクト失敗」の変化
しかしながらプロジェクトマネジメントにおける「失敗」は最近になって大きく変わります。特にユーザー企業にとってのそれは大きく変わってきています。
かつては「プロジェクトの失敗」はほとんどが「コスト超過」や「納期の遅延」でした。一説にはコストも納期も守れた「成功プロジェクト」は３０％とも言われてきました。しかしながらプロジェクト管理技術の向上やPKGやSaaS、PaaSなどの発展や開発環境の改善などにより、最近は７０%以上とまで言われるようになってきました。
その反面目立ってきたのが「ちゃんと完成できたのに利用されない」とか「期待したビジネス効果が生まれない」というような、今までと違ったタイプの「失敗」です。システムの目的や目標が大きく違ってきているのがその原因です。
従来の「集計作業の効率化」や「会計処理基幹の短縮」のような効果に対する対策が確実というか因果関係が明確なものから、「売上の拡大」とか「顧客満足の向上」みたいな確実な対策がはっきりと見えていないタイプのシステム化の目的・目標に変わってきているのが「プロジェクト失敗の原因」に変わってきています。
経営者から見れば「完成しなくて失敗」も「使い物にならなくて失敗」も対して変わりはありません。
プロジェクトマネジメントは必然的にプロダクトマネジメントに接近する
その結果、ユーザー企業の「プロジェクトマネジャー」に求められるものは大きく変化します。今まではとにかくSIerにパワハラというかカスハラみたいなマネをして、コストと納期を守らせていれば評価されたのですが、こんどは要件定義というか「何を作らせるのか」に真剣に取り組まなけれれば「プロジェクトの失敗」になってしまうのです。
いままでは業務部門から聞き取った要求をそのまんま受け入れて資料を作って、確認会議して議事録にしっかり記録を取らせていればよかったのですが、今はその要求の背景や、理由、その改善に寄って期待される効果までしっかり理解して、その機能によるビジネス成果をちゃんと見極めて、それの開発の要否から優先順位まで責任を持たないといけなくなったのです。
そしてその実現のためには作ったものに対するフィードバックもしっかりと測定して、短いサイクルで改善策を継続的に考えないといけなくなったのです。
「プロジェクトマネージャー」の中そのままに、いつのまにか求められることは「プロダクトマネジメント」に変わってきているのです。