はじめに

「ミスはゼロを目指す」。プロダクトを作る世界ではごく自然な発想です。バグはゼロが理想、要件はフルフィックスで実装、許容誤差は限りなく小さい方が良い。

ところが、私が長く身を置いてきたBPOの現場では、この発想がうまく噛み合わない場面が何度もありました。「100件のうち2件までのミスは許容される」といった許容誤差を含んだ品質基準で運用される世界が、確かに存在します。

同じ「プロジェクトマネジメント」という言葉で括られていても、SEの現場とBPOの現場では、PMの発想が根本的に違うのではないか。これが本記事で扱いたい仮説です。

この記事の立ち位置
私はBPO業界出身で、SEではありません。ただ、過去にRPA導入プロジェクトでシステム系出身の方とゼロから一緒に走った経験があり、そこで「プロダクトがある世界とない世界では、PMの発想が根本的に違う」と強く感じました。その後SEの方々と会話を重ねる中で形になってきた仮説をまとめたものが本記事です。SE側から見て違うところがあれば、ぜひ教えてください。

なお、SE型PMの記述は一般的に語られている整理を参照しつつ、私が現場で観察してきた範囲を重ねたものなので、SE側からすれば荒い部分もあると思います。議論のたたき台として読んでいただければ幸いです。

論じたい範囲

PMという言葉は広いです。修学旅行や飲み会の段取りも広義にはPMですが、ここで論じたいのは仕事の文脈に絞った話です。

労働集約型の事務代行であるBPOにおけるPMと、プログラミングを中心とするSEにおけるPMは、テーラリングの種別が根本的に異なるのではないか。

これが本記事の中心的な仮説です。

SE型PMとBPO型PMの基本構造

両者の特徴を対比すると以下のようになります。SE型は一般論ベース、BPO型は私の現場経験ベースです。

観点	SE型PM	BPO型PM
成果物	プロダクト（SaaS、Webアプリ等）を作る	プロダクトがなく、クライアント業務を運用
時間構造	単発的な納品（リリース）に向けバーンダウン	日次反復、月次で工数・配置を見直す
納品単位	一つ（少数）のプロダクト	申請書1000件、コール処理本数等の量産型
作業の依存性	高（コードベース・設計・仕様が相互依存）	低（事務工程は比較的独立）
WBSの複雑性	高（精緻に組む必然性）	低（混乱予防の装置として組む）
求められるスキル	領域横断で再利用できる汎用スキルの比重大	特定業務領域の知識＋コミュニケーション
品質の基準	バグゼロ志向、要件のフルフィックス（建前）	SLAによる許容誤差を含んだ品質基準

SE領域では、要件が明確な大規模開発は請負、仕様変更が多い開発は準委任、人の稼働を提供するSESといった契約形態が混在すると一般に整理されています。

「BPOにも高度判断業務はある」という反論への応答

ここで想定される反論があります。

「行政の窓口業務、税務BPO、医療事務BPOは高度な専門知識を要する。BPO＝低スキルというのは雑な括りではないか」

これは半分正しく、半分違うというのが私の見立てです。確かに行政窓口業務には特別法・一般法関係の理解を要する複雑な手続きがあります。税務・医療事務も同様に専門知識は不可欠です。

ただし、ここで問われるべきはスキルの性質です。

SEの汎用スキル：プログラミング・設計・テストなどは、技術スタックが変わっても根底のスキルセットをある程度持ち越せる側面があります
BPOの専門知識：領域固有性が高く、戸籍法の知識は税務BPOでは使えず、医療事務のレセプト知識は行政窓口では使えません

つまり「BPOにスキルが要らない」のではなく、「BPOで要求されるスキルは領域固有性が高く、SEの汎用スキルとは性質が異なる」という整理になります。この区別を踏まえても、SE型とBPO型の二分法は維持できると考えています。

テーラリングの重心はどこにずれるか（PMBOK領域マップ）

同じPMBOKを参照しても、テーラリングの重心はBPOとSEで明確にずれる、というのが本記事の核となる仮説です。

PMBOK領域	SE型の重心	BPO型の重心
統合管理	高	中
スコープ管理	高	中
スケジュール管理	高	中
コスト管理	中	高
品質管理	高	高（性質が異なる）
資源管理	中	高
コミュニケーション管理	中	高
リスク管理	高（性質が異なる）	高（性質が異なる）
調達管理	中	低（※注）
ステークホルダー管理	高	高

SE型の重心についての注釈
上記はWeb系・業務系・受託開発でよく語られる傾向をベースにした仮の整理です。Web系、業務系、組み込み系、インフラ系で重心は変わるはずで、たとえばインフラ系は調達管理の比重が高くなるでしょう。「SE型はこの重心だ」と確定的には言えない部分で、ぜひSE側から領域別のご意見を聞きたいところです。

BPO型の調達管理を「低」とした注釈
BPO型でも、コールセンター業務の一部を再委託したり、システム構築部分を別ベンダーに発注したりするケースは当然あります。それでも「相対的に低い」と整理したのは、BPOの主たる業務は受託した事務処理を自社要員で回すことであり、調達管理がPMの中核業務になることは少ないと観察しているためです。再委託が大きな比重を占める案件もあるので、案件特性によってブレる項目だと認識しています。

品質管理とリスク管理は両者とも比重が高いですが、中身が異なります。

品質管理：SE型はバグ・要件充足度、BPO型は処理精度・SLA達成率
リスク管理：SE型は技術的負債・要件変更、BPO型は要員離脱・品質ばらつき・法改正対応

人員配置と育成設計の論理も違う

PMBOK領域の重心がずれる結果として、人員配置と育成設計の論理も大きく分かれます。

観点	SE型	BPO型
配置の論理	スキルマッチング型	頭数とローテーション型
求めるスキルの性質	汎用性が高く領域横断で再利用可能	領域固有性が高く、業務領域を移ると積み直し
スキル獲得の方向	技術スタック・設計力の深化	業務マニュアル習熟＋判断力の段階的拡張
人の互換性	低（欠員の代替が難しい）	高（手順習熟で一定水準まで到達）
欠員時のリカバリ	同等スキル保有者の確保が必要	ローテーションと応援要員で吸収可能
育成施策の中心	1on1の技術指導、コードレビュー、勉強会、技術書購読	マニュアル整備、OJT設計、習熟度確認、キャリアステップアップ
マネージャーの主業務	スキル深化支援と技術的意思決定	要員配置の最適化と業務標準化
新人立ち上げ期間	スキル習熟に長期（半年〜数年）	業務手順習熟は比較的短期（数週間〜数ヶ月）

スキルの性質の違いが、欠員リスクや育成施策の中身まで連鎖的に変えているのが分かります。SE型は「人が抜けると穴が開く」構造で、BPO型は「人が抜けても回り続ける」構造です。逆にBPO型は「特定領域の知識を持つ人を新規領域に投入しても再立ち上げに時間がかかる」というハンディキャップを持ちます。

本題：「ミスはゼロを目指す」が通じない現場

ここで冒頭の話に戻ります。ある現場で観察された印象的なエピソードを、抽象化して書いておきます。

SE出身の方がBPO現場のマネージャーになった時、ミスを出さないように業務プロセスを細かく管理しようとされていました。SE型の発想としては自然だと思います。プロダクトの世界では「バグはゼロを目指す」が建前として基本にあると聞きます。許容誤差は限りなく小さい方が良い、という発想です（実際にはテストカバレッジやリリース後の重大バグ許容数といった許容誤差の考え方もあるとは聞きますが、少なくとも建前としてはゼロ志向が強いように見えます）。

ところがBPO現場ではこれが噛み合いませんでした。

BPOにはSLA（サービスレベル合意）というものがあって、「100件のうち2件までのミスは許容される」「処理時間の95%が指定時間内に収まること」といった許容誤差を含んだ品質基準で運用されます。

すべてを完璧に管理しようとすると、現場メンバーが疲弊し、コミュニケーションコストが膨張し、結果として全体の処理量が落ちました。

つまり、SE型マネジメントの**「ミスを出さない」志向と、BPO現場の「許容誤差を設計に織り込む」志向**の間には、構造的なギャップがあるように見えます。

これは「BPOの品質意識が低い」という話ではありません。量産処理を持続可能な形で回し続けるために、許容誤差を設計に織り込むのが合理的だ、ということです。完璧主義で回すと、現場が壊れる前に処理量が落ちます。

ちなみに、この「許容誤差を設計に織り込む」という発想は、BPOに限った話ではないかもしれません。SREのSLO設計、製造業の不良品率管理、医療の事故率管理など、量産・運用系の業務全般に共通する設計思想のようにも見えます。SE側の方にとっては、SLOの話と接続して読んでいただけると、案外距離が近いテーマかもしれません。

逆もまた然りで、BPO出身者がSE型PMに転じる時も同種のギャップが生じうるはずです。「許容誤差で回す」発想をプロダクト開発に持ち込めば、品質が崩れる場面が出てくるでしょう（こちらは私の実体験ではないので、SE側の方のご意見を聞きたいところです）。

仮説のまとめと問いかけ

BPO型PMとSE型PMは、PMBOKという共通の地図を持ちながら、現場では別の生き物として運用されているのではないでしょうか。両者を「同じPM」として論じる教科書は多いですが、実務ではテーラリングの重心、人員配置の論理、納品の構造、そして許容誤差の扱い、すべてが違うように見えます。

この仮説が正しいとすると、PM研修・PM資格・PM職の採用基準は、もっと類型ごとに分解された方が現場に届くものになるはずです。実務的な含意としては、SE出身者がBPO現場に来る時は「許容誤差を織り込んだ運用」への発想転換が、BPO出身者がSE現場に行く時は「依存関係の精緻な設計」への発想転換が、それぞれ必要になるのではないかと考えています。

最後に問いかけです

SE側の方へ：本記事のSE型PMの描写は実態に照らして合っていますか。「うちの領域はこうじゃない」というご意見をぜひ
BPO側の方へ：私の整理は現場の感覚と合っていますか
どちらでもない方へ：この二分法に収まらない第三の類型（アジャイル開発、プロダクトマネジメント、研究開発プロジェクト等）はどう位置づけるべきか、ご意見があればぜひ

これは現時点での仮説です。皆さんの反応で精緻化していきたいと考えています。