3 通の提案書、ひとつの本当の違い — シンガポールのエンジニアリング事務所はどう選んだか

要点: シンガポールの中小企業——55 名規模の設計エンジニアリング事務所——の机の上に、マネージド IT 事業者の提案書が 3 通あった。月額はどれも近く、3 社とも 24 時間 365 日のサポートと「プロアクティブ監視」を約束していた。意思決定は 6 週間止まった——選べなかったからではなく、3 通の文書の中に本当に比較できるものが何ひとつなかったからである。最終的に 3 社を分けたのは、商業条件ではなく構造だった。

これはシンガポールの専門サービス事務所が Brocent に持ち込む類の意思決定をもとにした、説明用の複合シナリオである。特定の顧客ではない。登場する 3 通の提案書は意図的に匿名で、その「かたち」だけで描いている——実在の同業他社が何をしていて何をしていないかを、こちらから語るつもりはない。営業の場でそれをやる提供者は、あなたのことを後日どう語るかを教えてくれている。

IT の障害が、そのまま請求の障害になる事務所

この複合シナリオの事務所は、シンガポールの約 55 名の建築・設備エンジニアリングコンサルタントである。構造グループ、建築設備グループ、小さなビジュアライゼーションチーム、そしてそれらをまとめるプロジェクトマネージャー。彼らの仕事は「ファイルが重い」——一般的なオフィス IT の助言が一貫して過小評価してきた種類の重さである。

統合された BIM モデル 1 件が数ギガバイトに達することがあり、しかもそれは単一ファイルではなくリンクされたモデルの集合体で、6 人前後が同時に開く。ワークステーションはメールが動くノート PC ではない。グラフィックスカードまで指定された機械であり、「同等品」に置き換えられると、その差は 90 分で終わっていたレンダリングが 4 時間かかるという形で現れる。プロジェクトのアーカイブはコールドストレージでもない。2 年前にクローズした案件が、施主の変更要望で再び開かれ、モデルツリー全体が外部参照を解決できる状態のまま戻ってこなければならない。

そして仕事の締め切り駆動ぶりは、とりわけ容赦がない。入札提出には時計がついている。意匠と設備コンサルタントとの整合期限にも時計がついている。当局への提出にも時計がついている。火曜の午後にファイルサーバーが遅いとき、そのコストは「不便」ではない。待たされて消える請求可能時間に、待っている人数を掛けたものであり、しかもその週は事務所がいちばんそれを負担できない週である。

この事務所のマネージングディレクターが IT の選定を調達上の形式として扱うことを拒んだのは、まさにそれが理由だった。この商売では IT の停止は請求不能時間へ直接換算され、その換算が起きていることに事務所の他の誰も気づかない。

比較できない 3 通の提案書と、6 週間

候補の絞り込みはすでに終わっていた。3 社とも信頼でき、いずれもマネージングディレクターが信頼する人物の推薦だった。提案書は 2 週間のうちに順次届き、そこから意思決定は動かなくなった。

事務所が見ていたものを、かたちだけで書く。

提案 A は月額が明らかにいちばん安く、全 9 ページで、サービスをカテゴリで説明していた。「ヘルプデスクサポート」「プロアクティブ監視」「セキュリティ管理」「バックアップ管理」。どのカテゴリも見出しがあり、その下に 2〜3 文が続く。

提案 B は 41 ページでいちばん長く、3 社で最大手の会社から届き、詳細なツール一覧を含んでいた。名指しの RMM プラットフォーム、名指しのエンドポイント保護製品、名指しのバックアップ製品、名指しのチケッティングシステム、名指しのドキュメントツール。

提案 C は価格が中間、詳しさも中庸で、冒頭に応答時間のコミットメントを「優先度 × 目標時間」の表として置いていた。

3 社とも 24 時間 365 日を約束していた。3 社とも「プロアクティブ監視」という語を使っていた。3 社ともオンボーディングを提供していた。月額は互いに 15% 程度の範囲に収まっていた。

3 回読み終えたマネージングディレクターの正直な総括は、「同じサービスの 3 バージョンを 3 つの価格で見ているのか、それとも本当に違う 3 つのサービスがたまたま似た金額なのか、判断がつかない」だった。これは居心地の悪い立場であり、業界が認めるよりもはるかに一般的である。

この比較の、どこが実際に壊れていたのか

問題は提案書が不誠実だったことではない。それぞれが内部的には一貫していて、外部的には比較不能だった——違う問いに答えているので、並べても信号が出ない。

損害を与えていたのは、具体的に 4 つの空白である。

「応答時間」のスタートラインが揃っていなかった。 提案 C の表は 3 通のうち最も厳密な文書に見えた。数字が入っていたからである。だが精読すると、そのコミットメントは所定の時間内にチケットを受け付けることだった。受付は実在する有用なものだ——自分の問題が待ち行列に入ったことがわかる——が、エンジニアが作業を開始することとは違い、解決とはなおさら違う。レンダーファームが午後いっぱい止まっていても、受付目標は完璧に達成できてしまう。事務所が 3 社に「その時計は何を測っているのか」を書面で述べるよう求め直したところ、3 つの答えは互いに違っており、その違いを元の文書は完全に覆い隠していた。

「含む」が 4 通りの意味を持っていた。 提案 B のツール一覧は机の上で最も具体的な文書であり、同時に最も気まずい問いを呼ぶ文書でもあった。サービスが 5 つの個別ライセンス製品であるなら、その継ぎ目は誰のものなのか。エンドポイントツールはデバイスを見る。チケッティングは依頼を見る。ドキュメントツールは誰かが書き留めることを覚えていたものを見る。リモートセッションとそれを引き起こしたチケットを結ぶものも、チケットとそれが触れた資産を結ぶものも、どこにもない。これは仮想的な整理整頓の話ではない。事務所の前の提供者が「先週の木曜にこのマシンに入ったのは誰で、なぜか」に 2 日がかりの再構成なしには答えられなかった理由そのものである。

オンボーディングが、終点のない手続きだった。 3 通ともその語を使っていた。どれも「終わった状態」がどう見えるかを書いていなかった。名指しされた成果物も、述べられた受入基準も、移行が成功したか否かを事務所が言える日付も、存在しなかった。専門サービス事務所において、終わりの定まらない移行は中立的なリスクではない。進行中のプロジェクト期限と重なり、未完の引き継ぎは「遅れた IT プロジェクト」ではなく「逃した当局提出」として姿を現す。

ドキュメントが誰のものかを、誰も述べていなかった。 これはマネージングディレクター自身が経験から持ち出した論点で、3 社とも触れていなかった。ネットワーク図、資産台帳、ライセンス一覧、ランブック、管理者資格情報が提供者自身のプラットフォームの中にしか存在しないなら、その提供者から離れることは自社環境をゼロから再構成することを意味する。それは月額のどこにも現れないスイッチングコストであり、しかも最悪のタイミングで発見される。

3 通をようやく比較可能にした問い

膠着を破ったのは、評価を「このサービスは何を含むか」から「このサービスはどう組み立てられているか」へ組み替えたことだった。4 つの構造的な問いがその大半を担い、そのどれもがこの事務所自身が経験済みの問題から出てきている。

これは 1 台のエンジンか、ツールの積み重ねか

この事務所の以前の体制は、まさに「ある製品が別の製品に引き渡す地点」で失敗していた。そこで最初の問いはこうなった。エンジニアがワークステーションに接続したとき、そのセッションは、チケットと資産と履歴を保持しているのと同じシステムの中の 1 レコードとして存在するのか。それとも、そのどれも知らないリモートアクセス製品の中に住んでいるのか。

これは中立的な観察ではなく Brocent 自身のアーキテクチャ上の立場なので、そのように読んでほしい。BCS Beam はツールの積み重ねではなく 1 台のエンジンとして構築されており、その具体的な帰結として、サポートチケットから起動されたリモートセッションはそのチケットに紐づく。だから履歴は 3 つの断片ではなく 1 つの物語として読める。単一プラットフォームはまた、それぞれ独自の方針を持つ SaaS ツールの寄せ集めではなく、単一の監査証跡と単一ベンダーのデータ取り扱い方針を意味する。

これがエンジニアリングコンサルタントにとりわけ効くのは、「再び開かれるプロジェクト」があるからだ。2 年前の案件が戻ってくるとき、問いは考古学的になる。このワークステーションの構成はどうだったか、どのライセンスが入っていたか、何がいつ変わったか。ツールの積み重ねは断片で答える。単一のレコードは 1 回の照会で答えるか、答えられないと正直に認めるかのどちらかである。

その引き継ぎは、終点のあるプロジェクトか

事務所はこの問いを要求として書き直した。移行を、フェーズと期間と成果物と「終わる時点」を持つ計画として見せてほしい、と。

参考として、Brocent のマネージドサービスにおける引き継ぎは 4 フェーズ・3 か月の引き継ぎとして構造化されている。第 1〜2 週に現地調査と IT 監査、第 2〜4 週に知識移転と CMDB 構築、第 3〜6 週にシャドーイングと再シャドーイング（エンジニアが基準を満たすまで観察下で作業する）、第 3 か月から本格稼働。比較にとって重要なのは期間ではなく成果物のほうである。すべての資産・構成・ソフトウェアライセンスを目録化した構成管理データベース。反復作業ごとに書かれた標準作業手順。監査から特定された「インフラの弱点上位 3 件」と、その是正を先送りせず移行期間内に組み込むこと。ヘルプデスク → スーパーバイザー → アカウントマネージャーという経路を明示したエスカレーションマトリクス。そして、移行が取りこぼした知識のギャップを見つけるために存在する、稼働後 30 日の正式レビュー。

提供者にこの形そのものを求める必要はない。必要なのは、何らかの終点を含む形を出せる提供者である。「最初の数か月で慣れていきます」は計画ではなく、請求書の付いた願望だからである。

セッションログを見せてもらえますか

マネージングディレクターがいちばん気に入った問いはこれだった。形容詞では答えられないからである。

候補の提供者に、リモートサポートのセッションが顧客側からどう見えるかを実演してもらってほしい。具体的には——スタッフの PC にエンジニアが接続するとき、エンジニアの名前が表示される同意プロンプトは出るか。セッション中、画面にバナーは出続けるか。ユーザーは誰にも尋ねずに、アクティブなセッション数と接続中のアカウントを確認できるか。そして事後に、誰が、どのデバイスに、いつ、どのモードで、どのチケットに対して接続したかの記録は残るか——そしてそれは、厚意として依頼するのではなく自分で取得できるか。

これらは Brocent 自身のエンドポイントエージェントが実装している具体的な挙動だが、これを尋ねる理由はブランドの好みではない。答えがデモで 5 分あれば検証可能であり、提案書には書けないことを教えてくれるからである。すなわち「安全なリモートサポート」が、システムの性質なのか、営業担当の保証なのか。守秘義務のもとで顧客の図面を預かる事務所にとって、この違いは学術的なものではない。

関連する問いが 2 つ随伴する。セッションデータはどこに置かれ、経路の途中にサードパーティのリモートコントロールクラウドは挟まっていないか。そしてエージェントのセキュリティ監査部分は、あなたのマシン上で実行できるのか、観察のみか。Brocent の監査エージェントは意図的に読み取り専用である——設定、ソフトウェアインベントリ、更新状況を報告し、インストール済みソフトウェアを毎日グローバルな CVE カタログと突き合わせて実際の悪用リスクで優先度付けするが、何も実行できない。手を動かす作業は、同意され記録されたリモートサポート経路でのみ発生する。あなたの提供者の答えが何であれ、推測せずに述べさせてほしい。

ドキュメントは私たちのものか

最後の問いは一文で、すべての提案書に向けられる。2 年後に解約したら、私たちは正確に何を持って出られますか。

良い答えは成果物を名指しする——資産台帳、ネットワークドキュメント、ランブック、ライセンス一覧、資格情報——そして形式と期間を添える。悪い答えは「これまで問題になったことはありません」という安心である。この演習のあとマネージングディレクターが定めた規則は率直だった。契約書で名指しできないものは存在しない。

提供者の切り替えを実際に実行する手順は独自の落とし穴を持つ別の主題で、香港の商社が何も壊さずに提供者を切り替えた事例に詳しく書いている。提案段階で関係するのはもっと狭い点である。退出条項は、その提供者がまだあなたを獲得しようとしている段階で、この関係をどう考えているかを教えてくれる。

採点し直した比較はどうなったか

3 通を上の 4 問に通し直したとき、順位は変わった。それ以上に重要なのは、順位の理由が、マネージングディレクターがパートナーに一文ずつで説明できるものになったことである。

最安だった提案 A は、部分的にはスコープが実際に狭いから安かったことがわかった。カテゴリ見出しの下に何があるかを誰かが尋ねた途端、他の 2 通より覆う範囲が狭くなった。これは提供者への批判ではない。正しく値付けされた、より小さいサービスであり、ニーズのより単純な事務所にとっては正解だったかもしれない。ワークステーションが指定機器であり、アーカイブが再び開かれることに耐えねばならない事務所にとっては、正解ではなかった。

最大手で最長文書の提案 B は、ツールについては最も明快な答えを、ツール間の継ぎ目については最も弱い答えを返した。事務所の判断は——これは事実ではなく判断である——5 つの製品から組み立てられたサービスは、自分たちがすでに経験した失敗、つまり「製品間の隙間を誰も持たない」という失敗を再現するだろう、というものだった。

応答時間表のあった提案 C は、時計の定義が書面で明確化されたあとで評価が上がった。これ自体が記録に値する。問うたことが提案書を変えたのである。 押されたときにコミットメントを正確に書面で言い直す提供者は、更新時やインシデント時にどう振る舞うかについて、有用な何かを示している。

ほぼ同一の 3 通を分けたもの

• 最安の提示額。 *実際に示しているもの:* たいていはスコープの狭さ、ときに本当に無駄のない運営、まれにスコープ外請求で利幅を回収する意図。*検証法:* 各カテゴリ見出しの下に何があるかを尋ね、別途請求になる作業の例を 3 つ出させる。*これが正解になるとき:* あなたのニーズが本当に狭く、かつそれを仮定ではなく確認したとき。
• 最大のブランド。 *実際に示しているもの:* 規模、プロセスの成熟度、たいていは長いツール一覧。*注意点:* サービスが 1 台のエンジンなのか、継ぎ目の持ち主がいない複数のライセンス製品なのか。そして 50 名の事務所が重点顧客になるのか端数になるのか。*検証法:* 具体的に誰が担当するのか、その人が休暇のときに何が起きるのかを尋ねる。
• 構造的な適合。 *実際に示しているもの:* その提供者が、サービスが何を含むかだけでなく、どう組み立てられているかを考えたということ。*4 つのテスト:* ツールの積み重ねではなく単一の監査証跡を持つ 1 台のエンジン。成果物と終点を持つプロジェクトとしての引き継ぎ。同意があり、可視で、自分で検証できる形で記録されるリモートアクセス。そして契約上あなたのものであるドキュメント・資格情報・ランブック。*正直な但し書き:* 構造的適合は Brocent が最適化している方向なので、この項目は中立的な発見ではなく表明された立場として扱ってほしい。価値は、この 4 問を私たちを含む全員に問うことにある。

売られるのではなく、選ぶ

この物語の事務所が提供者を選んだのは、どれかが議論に勝ったからではない。6 週間の停滞のあとで、ようやく「答えが実際に異なる 4 つの問い」を手に入れたからである。しかもその違いは、営業が説明したリスクではなく、自分たちが実際に経験した問題に対応していた。

移植できるのはそこである。値打ちのある評価基準は、自分自身の失敗から生えてきたものだけだ。ワークステーションが指定機器でアーカイブが再び開かれるコンサルタントには、ウェブサイトが営業パイプラインである流通業者とは違う答えが必要で、汎用チェックリストはどちらにもうまく働かない。

いまこのような比較の途中にいるなら、次に有用なことは 2 つある。マネージド IT サービスが何と呼ばれているかではなく何で構成されているかを読むこと。そして誰かの提案書に依存しない基準点を持つために公開プラン価格を確認すること。この 4 問を私たちに向けたいならお問い合わせから。そして他の 2 社にも同じことを。それが要点である。

Brocent は 2007 年、北京での創業以来、企業の IT 運用を担ってきた。香港オフィスは 2016 年から、シンガポールは 2021 年からグループのグローバル本社である。私たちがあなたの最終候補で勝つ、とは言わない。あなたの最終候補が、決められるものになるほうがよい。

よくある質問

見積もっている内容が違う提案書を、どう比較すればよいですか？

含有物の比較をやめ、構造の比較を始めてください。含有物リストは各社が自社の語彙で書くもので、だからこそ 3 通並べても信号が出ません。構造の問いは、包装ではなくアーキテクチャについての問いなので、答えが直接比較できます。これは 1 つのシステムか複数の製品か。移行計画は何で、いつ終わるのか。リモートアクセスについて何が見えて何を監査できるのか。最後に何を所有するのか。この 4 問を書き出し、候補全社に同じものを送り、書面で回答を求めてください。元の文書では見えなかった差が、はっきり出ます。

応答時間 SLA は実際に何を約束していますか？

それは時計が何を測っているかに完全に依存し、マネージド IT の提案書で最も誤読されやすい数字です。チケットの受付を約束する提供者もいれば、人が診断を開始することを約束する提供者、優先度帯ごとの解決を約束する提供者もいます。これらはまったく違う約束でありながら、似た見た目の数字を伴いがちです。Brocent 自身の公開コミットメントは P1 重大インシデントの 15 分初動応答で、より低い優先度には公開された階層があります——しかし数字は定義よりはるかに重要ではないので、各社に自社の定義を書面で述べさせ、同じスタートラインを比べていることを確認してください。

私たちの IT ドキュメントとパスワードは誰のものですか？

契約書がそう定めた側のものです。だからこそこれは会話ではなく契約書に属します。具体的に尋ねてください。解約時に、資産台帳、ネットワークドキュメント、ランブック、標準作業手順、ライセンス一覧、管理者資格情報を受け取れるか。どの形式で。何日以内に。オンボーディング中にきちんとした構成管理データベースを作る提供者にとって、これらはすべて自然な副産物です。ですから歯切れの悪い答えは、ドキュメントが可搬な形で存在しないか、提供者がそれを交渉材料とみなしているかのどちらかを示します。どちらも署名前に知る価値があります。

提供者の切り替えにはどのくらいかかるべきですか？

小規模な専門サービス環境の構造化された引き継ぎは、週末ではなく通常 3 か月の作業です。Brocent 自身の流れは、調査と監査、知識移転と CMDB 構築、シャドーと再シャドー、第 3 か月からの稼働、そして正式な 30 日レビューです。両極端を疑ってください。2 週間での切り替えを約束する提供者は、優れたドキュメントを引き継いでいるか、インシデントを通じてあなたの環境を学ぶつもりかのどちらかです。移行がいつ終わるか言えない提供者は、そもそもスコープを定めていません。切り替えそのものの手順、とくに引き継ぎに非協力的な現提供者への対応は、提供者切り替えの詳細で別途扱っています。

オンボーディングには何が含まれるべきですか？

最低限、次のものです。実際に何を持っているかの書面像を生む現地調査と監査。資産・構成・ライセンスを目録化した構成管理データベース。反復作業について文書化された標準作業手順。既存チームまたは前ベンダーとの知識移転セッション。特定されたインフラの弱点と、記録ではなく日程に入った是正。役割が名指しされたエスカレーション経路。そして定義された稼働開始と稼働後レビュー。提案書のオンボーディングの節が「あなたが受け取る成果物の一覧」として読めないなら、それはプロジェクトではなく意向を述べています。

提供者のリモートアクセス制御は、どう確認すればよいですか？

スライドではなく、エンドユーザー視点のライブデモを求めてください。エンジニアが接続したときにスタッフに何が見えるかを観察します。同意プロンプトは出るか、そこにエンジニア名は出るか、セッション中にバナーは残るか、アクティブなセッションと接続中のアカウントを一目で確認できるか。次に事後の監査記録を見せてもらいます——誰が、どのマシンに、いつ、どのモードで、どのチケットに対して——そして自分でエクスポートできるかを尋ねます。あわせて、そのデータがどこに置かれ、経路にサードパーティのリモートコントロールサービスが挟まっていないかも尋ねてください。5 分の実演は、セキュリティ姿勢に関するどんな段落よりも多くを語ります。

最安を選ぶべきですか？

ときには本当にそうです——ただし、それが安いのはスコープが小さいか運営が無駄ないからであって、空白があなたが後で請求される場所だからではない、と確かめたあとに限ります。検証法は、各スコープ見出しの下に何があるかを尋ね、月額の外に落ちる作業の例を求めることです。正直に値付けされた狭いサービスは、ニーズの狭い事務所にとって正当な選択肢です。広いサービスと同じ言葉で説明された狭いサービスは、4 か月目に出会うことになる問題です。

他社との契約期間中の場合はどうすればよいですか？

まず解約条項を読み、次にデータとドキュメントの条項を読み、それから自社のプロジェクトカレンダーから逆算してください。有用な問いは「出られるか」ではなく「いつが最も損害の小さい窓か」であり、締め切り駆動のコンサルタントにとってそれは法務の判断であると同時に日程の判断です。真剣な新提供者は、自分たちの開始日ではなくあなたの提出日を軸に移行を計画し、計画を提示する前にカレンダーを見せてほしいと言うはずです。