#21:ベンダーの「できます」を疑え ─ プロジェクト初期に行う『構造品質の監査』の正体
お世話になっております。 YMGアドバイザリーの山口です。
前回Vol.20では、体制図に「監理者（Project Supervisor）の席」がないことが、DXプロジェクトの炎上を構造的に招くと論じました。
監理者は審判（レフリー）であり、スケジュールの番人ではなく、設計の品質番人だという点をお伝えしました。
では、その審判は、いったい何を見て笛を吹くのか。
今回は、その「目線の正体」を明かします。
スケジュールは「順調」、しかし構造は「崩壊」している
経営層の手元にある週次レポートを思い浮かべてください。
マイルストーンはGreen。課題管理表の消化率は80%超。ベンダーとの定例会も「特段の問題なし」という言葉で締められる。
これほど「安心できる」レポートが、同時にこれほど「危険なシグナル」であることを、私はこれまで何度も目撃してきました。
DXプロジェクトの悲劇の構造は、驚くほど一貫しています。
要件定義・設計フェーズでひそかに埋め込まれた構造の歪みが、誰にも検知されないままコードに実装され、UATに至って初めて「こんなはずじゃなかった」として炎上する。手術のタイミングを逸した後の改修は、設計段階の何十倍ものコストを要求します。
問題は、現場の誰も「手を抜いていない」ことです。PMは勤勉に課題を管理し、ベンダーは誠実に要件を実装する。それでも炎上する。なぜか。
「進捗監査」と「構造監査」という、根本的に異なる二種類の監査が混同されているからです。
進捗監査とは、「期限通りに動いているか」を確認する行為です。これはPMが担います。
構造監査とは、「期限通りに間違った方向へ走っていないか」を確認する行為です。これは、現場知とアーキテクチャ思考を両立させた監理者にしか担えません。
ここで強調したいのは、両者が見ているものはまったく異なるという点です。
監理者の仕事は、上流の複数の視点からシステムの「骨格」を診断することです。
※なお、ここで述べる「ベンダーの『できます』」は、ベンダー側に悪意があるという話ではありません。（ベンダーさんを敵に回す意図は全くありません）
問題は、体制図の中に“構造品質を守る役割”が制度として存在しないことです。
結果として、誰も悪くないのに炎上が起きる、というお話です。
視点①：データの循環（Closed-loop）に「断絶」はないか？
現場DXの最大の価値は、フィールドから吸い上げたデータが、次の意思決定や製品・サービスの改善に自動的にフィードバックされる「循環」を作ることにあります。
しかし、多くのプロジェクトがこの循環に辿り着かず、「電子化された日報」として終焉を迎えます。
監理者が要件定義の段階で最初に問うべき問いはこれです。
「現場から入力されたこのデータは、誰の、何の判断に、どのタイミングで届くのか？」
ベンダーが誠実に設計した仕様書を開いても、この問いへの答えが書かれていないことは珍しくありません。
データの「入力画面」の仕様は詳細に記述されていても、そのデータが「どこへ行き、何を変えるのか」というアウトプットの設計が欠落している。
入口と出口がつながっていないならば、それはシステムではなく「高機能な紙」です。
そして、この断絶は設計書のどのチェックボックスにも引っかかりません。PMの課題管理表には「データ活用設計の欠落」という項目が存在しないからです。
監理者は、ここで初めて笛を吹きます。
視点②：その仕様は「現場のDNA（AM-BOM）」に背いていないか？
フィールドサービスやアフターサービス現場に長く携わってきた私が繰り返し目撃するのは、「標準化」という名の下に行われる「現場の競争力の破壊」です。
ベンダーは良心的に、こう提案します。
「この業務フローをシステムの標準機能に合わせて整理すれば、カスタマイズコストを大幅に削減できます。」
この言葉は、技術的には正しい。しかし、監理者はここで立ち止まり、逆の問いを投げかけます。
「その『整理』の中に、捨ててはいけない現場の判断ロジックが含まれていないか？」
AM-BOM（As-Maintained BOM）の概念は、まさにここに直結します。
熟練技術者が長年かけて積み上げた「この機械のこの部位は、カタログ上の寿命より早く（または、遅く）交換すべき」という暗黙知。標準検査手順書には載っていない、現場固有の判断の連鎖。
こうした「生きた知識体系」は、システムのデータベース設計レベルで破壊されることがあります。
同時に、監理者は逆の過誤にも目を光らせます。
現場の「今のやり方」への固執が、将来の拡張性を殺すケースです。
「ウチの現場はこうじゃないと動かない」という声は、現場の声である以前に、システムへの過負荷な要求である場合があります。
ビジネスの必然性とシステムの論理性の矛盾を突き、どちらにも阿ることなく「設計の正しさ」を守る。
これが監理者の仕事であり、PMにも現場担当者にも担えない役割の本質です。
視点③：「取ってつけた機能（Bolted-on）」の賞味期限を問う
「ご安心ください。それも対応できます。」
プロジェクト会議でベンダーのこの言葉を聞くとき、自身の経験からの自省を込めて、私は必ずある問いを胸の中で立ち上げます。
「その『できます』は、5年後もメンテナンス可能か？」
ベンダーの「できます」は多くの場合、「工数をかければ技術的に実装可能」という意味です。これは事実であり、嘘ではありません。
しかし監理者が問うのは、全く別の次元の話です。
不足機能を補うために追加されたカスタマイズや外部連携は、製品のコアバージョンアップのたびに動作確認を要します。
次のフェーズで追加されるモジュールとの結合に際し、摩擦を生じさせます。チームの誰もが「ここは触るな」と囁く禁断の領域になります。
技術的負債は、積み上がるまで経営者には見えません。
しかし監理者には、設計書の段階で見えます。
要件定義の会議室で、ある機能の実装方針が決まった瞬間に、「これは3年後にスパゲティになる」という未来が、経験あるアーキテクトには読めるのです。
この「賞味期限の診断」は、ベンダーに悪意がなくても、PMが優秀であっても、誰も行いません。
監理者だけが、プロジェクトの外側から冷徹な視線で問い続けられます。
「耐震診断」なき建築を、許してはいけない
建築の世界には、「耐震診断」という概念があります。外観がどれほど美しくとも、内部構造に欠陥があれば、震災の一撃で崩壊する。
だからこそ、着工前・施工中の構造検査を法律が義務付けています。
DXプロジェクトには、この義務がありません。スケジュール管理の書類はあっても、構造品質を検査する第三者の関与を定めた標準は存在しません。
結果として、外観は美しいウォーターフォールの工程表を保ちながら、内側で設計の歪みが蓄積されていきます。
設計段階での構造監査コストは、リリース後の構造改修コストと比べて桁違いに小さく済みます。
欠陥の発見・修正コストがフェーズが進むほど急増することは、ソフトウェア工学で広く知られています。
経営者の皆様に問いかけたいことがあります。
皆さんの組織でのプロジェクトの週次レポートに「Greenが並んでいる」という事実は、安堵の根拠になりますか？
経営者が本当に問うべきは、「いつ終わるか」ではなく、「この構造で10年戦えるか」のはずです。
YMG Advisory：スポット構造監査のご案内
（進む／止めるの判断材料として）
YMG Advisoryでは、進行中のプロジェクトに対して「スポット構造監査」を提供しています。
要件定義書・基本設計書・システム構成図などをもとに、以下の三視点から構造の歪みを診断し、経営・マネジメント層への直接レポートとして提出します。
Closed-loopの断絶：入力データは誰の意思決定に届くのか
AM-BOM整合性：現場の判断ロジックは破壊されていないか
Bolted-on負債：その「できます」は将来も保守可能か
「今のプロジェクトが少し心配だ」と感じている経営者・推進責任者の方、ぜひご相談ください。
問題が小さいうちなら、手術は最小限で済みます。
取り上げてほしいテーマ、ご質問、ご相談などございましたら、お気軽に ymg-info@ymg-advisory.com までご連絡ください。
次回Vol.22では、構造監査の結果を受けて監理者が「ゴーサイン」と「ストップ」を判断する意思決定ロジックを解説します。
編集後記
上記の記事は「監理者さえいれば解決する」という論調に傾きやすい構成かもしれません。
しかし正直に言えば、監理者の介入が「遅すぎる」プロジェクトは、監理者の関与前から既に取り返しのつかない政治的合意形成がなされていることが多いのではないでしょうか。
「スポット監査」も、発注が設計完了後では診断より”慰問”に近くなるリスクがあります。
Vol.22以降では、この「監理の限界」についても正直に論じる価値があるかもしれません。
皆さまからの信頼を本物にするためには、都合の悪い真実も語ることが不可欠だと考えています。