「BPM」から「DM」へ。9月1日から、役割の呼び名を変えます

2026年9月1日から、見積書・提案書・契約書のポジション名を BPM（ブリッジプロジェクトマネージャー）から DM（デリバリーマネージャー）に変更します。

単価や契約条件に変更はありません。既存案件の担当者が入れ替わることもありません。変わるのは呼び名と、その役割が引き受ける責任の範囲です。

三度目のポジション名変更

ポジション名を変えるのはこれが三度目です。

一度目は2008年、VFAの創業時です。当時は日本のお客様とベトナムの開発チームのあいだに、何人もの人が並んでいました。ブリッジSE・ITコミュニケーター・テスター・開発者。工程ごとに役割を細かく分け、それぞれに人を当てる。18年前の受託開発ではこれが標準的なやり方でした。

分業には利点があります。一人あたりの守備範囲が狭いので、採用も教育もしやすい。ただ、間に立つ人が増えるほど判断が誰のものか曖昧になります。仕様の解釈がずれても、翻訳の問題なのか設計の問題なのか切り分けに時間がかかる。何よりプロジェクト全体の結果に責任を持つ人が、お客様側にしかいませんでした。

そこでVFAは間に立つ役割を一つに統合しました。二度目の呼び名がBPMです。

ブリッジプロジェクトマネージャーは一般的な職種名ではありません。VFAが社内でつくった呼び名です。翻訳と調整だけを担う「ブリッジ」ではなく、プロジェクトの進行そのものに責任を持つ人を置きたかった。その意図を名前に込めたつもりでした。

そのBPMを今回やめます。

なぜまた変えるのか

一番の理由は、お客様の側で「作るもの」の決まり方が変わったからです。

かつてのソフトウェア開発は正解が最初にある前提で組まれていました。お客様が要件を固め、仕様として渡してくださる。わたしたちはそれを速く、バグなく形にする。ゴールは動かない。だから間に立つ人の仕事は「正確に伝えること」でよかったのです。

いまはその前提が崩れています。

要因は一つではありません。市場の変化が速くなり、事業計画そのものの寿命が短くなりました。作っている数か月のあいだに競合も規制もお客様の社内体制も動きます。お客様の側では内製という選択肢が現実的になった。開発を取り巻く技術もAIを含めて数か月単位で入れ替わります。どれか一つが決定打なのではなく、これらが重なって、作りながら正解を探すやり方以外が成立しにくくなりました。

最初の打ち合わせの時点で、何を作るべきかがまだ固まっていない。そういう状態から始まる案件が以前より増えているように思います。事業計画そのものが動いているのですから、当然のことです。以前なら要件定義の遅れとして扱われたであろう状態が、いまは出発点として珍しくなくなりました。

ゴールが動くなら、間に立つ人の仕事も変わります。翻訳・議事録・進捗の中継。こうした橋渡しの実務は道具でかなりの部分が置き換えられます。代わりに重みを増したのは二つです。何を作らないかを決めること。決めたものを最後まで届け切ること。

「ブリッジ」という言葉は、渡す先に正解がある前提で成り立っています。その前提が消えた以上、この名前では役割を言い表せなくなりました。

DMは何をする人か

橋渡しは情報を運ぶ役でした。DMは結果を引き受ける役です。

DMが持つ責任は三つあります。一つ目は優先順位の決定。限られた期間で何を作り何を後回しにするかを、お客様と一緒に決めます。二つ目はデリバリーの完遂。仕様どおりに作り終えることではなく、リリースして使われる状態まで持っていくことに責任を持ちます。三つ目はリスクの早期提示。問題が小さいうちにお客様へ上げる。悪い知らせを遅らせないことをDMの評価基準に組み込んでいます。

「これまでのBPMは中継業務だけをしていた」という話ではありません。仕様を深く理解し、お客様の事業まで踏まえて開発を主導してきたメンバーはすでに何人もいます。DMは新しい仕事を発明したのではなく、そうした働き方を組織の標準として名付け直したものです。名前を変えるのは、一部の優秀な個人の裁量に頼る状態をやめるためです。

PMからCOEまで

呼び名が変わるのはDMだけです。ただし役割の定義は全ポジションで見直しました。

• PM：0から1のフェーズを担当します。お客様と向き合い、本当に解くべき課題を見極めて提案します
• DM：1から10のフェーズを担当します。リリースと改善のサイクルを回し、デリバリーを完遂させます
• Developer：実装だけを担当する役割ではありません。何のために作るのかを理解した上でAIと協働し、出てきたものを検収する判断を担います
• PMO：標準が守られているかを個別のプロジェクトを越えて確認し、データからトラブルの予兆を早期に掴みます
• COE：生産性と品質保証のための技術基盤を作り、全チームに配ります。個別のプロジェクトでは解ききれない難易度の高い技術課題も引き取って解決します

前の三つがプロジェクトを動かす層、後ろの二つがそれを支える層です。PMもDMもお客様と直接向き合います。DMが社内に引っ込んでPM経由でやりとりする形ではありません。

見積もりと進め方

以前のVFAは機能を全部洗い出して一括で見積もる形を取っていました。お客様が必要とおっしゃった機能だけでなく、「これはあったほうがいい」「本来こうあるべきだ」というものまで良かれと思って盛り込む。結果として他社より高く見える見積もりになっているケースもあったと思います。

いまは三つの段階に分けています。

1. PoC：実際に試作しながら、作るべきものを見極めます
2. MVP：プロダクトとして成り立つ最低限の機能に絞り、まずリリースします
3. イテレーション：2週間から1か月の単位で優先順位をつけ直しながら改善を重ねます

工程が一つ増えたわけではありません。これまで一つのリリースにまとめていたものを三つに分けただけです。同じものを作るのに期間が延びたり費用が増えたりすることはありません。むしろ動くものを見てから残りを決められるぶん、作らずに済む機能が出てきます。

最初にすべてを固めきらないぶん、最初のリリースまでは以前よりかなり早くなりました。初期リリースまでの期間と費用は現時点の要件に合わせてお出しします。ご発注の判断に必要なものですから、そこを曖昧にはしません。

VFAの見積もりは初期開発の費用だけを積んだものではありません。PoCからMVPのリリース、その後の維持と改善までを一つの体制として見積もっています。現場やエンドユーザーが使い始めてから出てくる要望にどう応え続けるか。そこまで含んだ金額です。初期開発だけを対象にした見積もりとは含まれる範囲が違います。

優先順位は必ず変わります。着手時点で決めた機能一覧が半年後もそのまま最適である保証はどこにもありません。作るものを先に全部決めきる見積もりは、その変化を織り込めない。だから途中で順番を組み替えられる形を標準にしています。

目的は機能を増やすことではありません。一つ足すなら一つ減らせないか。そこを一緒に考えるのがDMの仕事です。

速さと品質のぶつかり合い

早く出すことと壊さないこと。この二つは本来ぶつかります。速くやれば品質は落ちるし、守ろうとすれば遅くなる。これを現場の頑張りで両立させようとすると、どこかで必ず破綻します。人は疲れますし忙しくもなります。

そこでVFAはこれを仕組み側で担保することにしました。社内でAI Foundationと呼んでいる基盤です。

実態は、開発者が使うIDEに最初から読み込まれるVFA独自のプラグインとルールセットです。AIエージェントの制御、環境の仮想化と隔離、セキュリティ監査の仕組みなどが組み込まれておりリスクの低いところでは全速力を出し、高いところでは自動的にブレーキがかかる。やっていることはそれだけです。ルールをドキュメントに書くだけではいずれ読まれなくなります。だからルールを実行環境そのものに埋め込み、安全なやり方が標準になるようにしました。

基盤はLayer 1からLayer 4までの4層で構成され、プロジェクトが負うリスクに応じた4段階の水準で適用されます。対象は機密情報を扱う環境の安全性・生成されたコードの品質と脆弱性のレビュー・自動テストによる回帰の防止です。市場に出るソフトウェアほど求められる水準は厳しくなります。監査もExcelの手作業ではありません。GitHub上で自動的に行われ、どのプロジェクトがどの水準で動いているかがレポートとして出ます。

テストについては、この数年で事情が変わりました。以前は時間と予算の制約から、本当は書きたいテストコードを諦めざるを得ない案件が数多くありました。AIを使えるようになったいまは、その量を実装できます。壊さずに直し続けられるかどうかはここで決まります。

まだ完成ではありません。運用しながら育てている最中です。

お客様への影響

• 表記の変更：2026年9月1日以降にお出しする見積書・提案書・契約書から、BPMの表記がDMに変わります
• 単価・契約条件：変更ありません
• 担当者：既存案件の担当者は変わりません。呼び名が変わるだけです
• 進め方：新しい役割に沿ったワークフローの調整は、案件ごとに個別にご相談しながら進めます。9月1日を境に一斉に切り替わるものではありません

最後に

名前を変えるだけなら簡単です。難しいのは、その名前どおりに振る舞える人を育てるほうです。

それでも呼び名から変えることにしたのは、名前が仕事の輪郭を決めてしまうからです。「ブリッジ」と呼ばれている限り、本人も周囲もその人を情報の通り道として扱ってしまう。ときにはお客様も。実際にはもっと踏み込める人たちを、名前が押し戻していました。

DMという呼び名は、その押し戻しをなくすためのものです。ご発注いただいた案件の結果に、名前と顔のある責任者が一人立つ。そこはこれからも変えません。

ご不明な点がありましたら、担当の営業またはPMOまでお気軽にお問い合わせください。

よくあるご質問

Q. 単価は変わりますか。 A. 変わりません。呼び名の変更に伴う価格改定は行いません。

Q. 現在の担当者は変わりますか。 A. 変わりません。これまでBPMとして担当していたメンバーがそのままDMとして担当を継続します。

Q. 契約書を巻き直す必要はありますか。 A. 既存契約について、名称変更のみを目的とした締結し直しはお願いしません。9月1日以降に新規で作成する書類から順次切り替わります。

Q. 進め方は9月から急に変わるのですか。 A. いいえ。役割の定義は9月1日付で切り替わりますが、実際の進め方は案件ごとにご相談しながら移行します。

Q. オフショア開発ではなくなるのですか。 A. 開発拠点がベトナムにあることは変わりません。変えているのは進め方のほうです。正解を受け取って作る形から、正解を一緒に探す形へ。