香港の共同管理型IT：あるメディア制作会社の役割分担

要点: 香港のメディア制作会社に所属する二人の社内IT担当者は、編集・ストレージ・配信のスタックについて、外部ベンダーが短期間で習得できる以上のことを理解している——それなのに、実際の時間の大半はパスワードのリセット、ノートPCの再構築、時間外のアラート対応に費やされている。共同管理型ITとは、その仕事のうちどちらの半分を実際に手放すかを決めることに他ならない。

香港のメディア制作会社の技術責任者が、IT担当の二人を呼んで、シンプルな質問を投げかけた。先週、実際は何に時間を使っていたのか。正直な答えは居心地の悪いものだった。二人合わせてパスワードを九回リセットし、不具合のあったWindowsアップデートの後にノートPCを二台再構築し、月曜の納品前にメールボックスの同期が止まったという金曜夜の電話に対応し、梱包エリア付近で四回も報告されているWi-Fiの死角を追いかけていた。彼らがあまり時間を使えていなかったのは、まさに彼ら自身の専門知識が本当に必要とされる仕事——すべての編集室が依存する共有ストレージアレイ、放送局の受け入れ仕様を満たさなければならない配信パイプライン、大きな案件が納品されるたびに滞留するレンダーキューだった。

これは二人の能力が足りないという話ではない。成長中のメディア企業の二人体制のIT部門であれば、日常的で反復的な業務量が使える時間を上回り、それを他に渡す先がない状況になったときに必ず起きることだ。共同管理型ITは、IT部門を丸ごと外注することの婉曲表現ではない。それは、ある具体的な問いに対する意図的な答えである。この仕事のうち、どれが本当にこの会社に固有のもので、どれが香港のどの会社もまったく同じ形で抱えている問題であり、したがってすでに24時間体制で回っている場所に任せるべきなのか。Brocentは2007年に北京で創業して以来マネージドITを提供しており、2016年から香港にオフィスを構え、2021年からはシンガポールに本社を置いている。以下に示すパターンは、技術基盤が専門側と一般企業側にきれいに分かれる企業で、Brocentが繰り返し目にしてきたものだ。

香港のメディア・コンテンツ制作業界

香港のメディア・コンテンツ制作セクターは幅広い企業を含む。ポストプロダクションハウス、広告・ブランデッドコンテンツのスタジオ、企業向け映像制作会社、放送・ストリーミング関連の供給企業、そして社内に制作部門を持つマーケティングエージェンシーなどだ。具体的な成果物が何であれ、その多くに共通しているのは、技術基盤がきれいに二つのまったく異なる部分に分かれているという点である。一方は専門性が高く、制作に直結する部分だ。すべての編集ベイが同時に読み書きする共有の高帯域ストレージ、特定のハードウェア上で負荷の高いソフトウェアを動かす編集・カラーグレーディング環境、レンダーやトランスコードのパイプライン、そしてクライアントや放送局、プラットフォームごとに異なる受け入れ仕様に合わせて組まれた配信プロセス。もう一方は一般的で、企業側に直結する部分だ。ノートPC、メールボックス、契約書や請求書のための共有ドライブ、ビデオ会議、経理システム、そしてスタジオ自体のウェブサイトやCMS。

専門側は、外部ベンダーが短期間で引き継ぐのが本当に難しい。メディアストレージのシステムは特定のコーデック、特定のプロジェクト構造、特定の納品期限を前提に構成されており、一般的なITベンダーがそれをあらかじめ理解している理由はない。企業側はその逆で、香港の他のどの100人規模の企業が運用しているものともほぼ同じであり、マネージドITベンダーは日々何千という同種のワークロードを扱っている。この状況にある企業の多くが抱える問題は、優れたIT人材がいないことではない。専門側で本当に優秀なIT人材が、結局は一般側の対応に大半の時間を取られてしまう、なぜならそれを担当する人が他にいないからだ。

具体的な場面: 110名のスタッフ、二人のIT担当者、締め切りに追われるスタック

本記事の複合的な想定はこうだ。約110名の香港のコンテンツ制作会社で、制作部門（編集者、カラリスト、モーションデザイナー、プロデューサー）、アカウント・クライアントサービス、営業、マーケティング、経理・総務に人員が分かれている。二人のIT担当者が会社全体を支えている。二人ともポストプロダクションかシステムエンジニアリングの経験を積んできた人材で、共有ストレージアレイのこと、編集チームが頼りにしている命名規則のこと、特定のレンダーノードがなぜ度々ネットワークから落ちるのか、そして帳簿上どのクライアントの納品仕様が最も厳しいかを理解している。この知識は、汎用ベンダーが初日から再現できるようなものではなく、実際に大きな価値を持つ。

その専門業務と並行して、110名規模の企業が生み出すあらゆる業務がのしかかる。ノートPCの払い出しと再構築、メールボックスとカレンダーの問題、デスクエリアと編集室の両方をカバーするWi-Fi、エンドポイントセキュリティ、バックアップ、経理チームが使う会計ソフト、そして決して空にならないヘルプデスクのキュー。そして制作の仕事は締め切り駆動型であり、9時から18時という勤務時間には配慮してくれない——放送枠、クライアントのローンチ日、月曜朝までに編集して納品しなければならない週末のイベント。そのため時間外のアラートは、その時たまたま連絡がつく人に届くことになり、実際にはそれが無期限に同じ二人のうちのどちらかを意味する。

現実の問題その一: 二人の専門家がすべての問題のエスカレーション先になっている

二人のIT担当者が会社唯一のIT機能であるため、彼らはあらゆる種類の問題のエスカレーション先になってしまい、それは本来彼らの専門知識を必要とする問題に限らない。若手プロデューサーのノートPCがWi-Fiにつながらない、営業担当のOutlookが不要なパスワードを求めてくる、経理の誰かが印刷できない——これらのどれも、メディアストレージのアーキテクチャを理解している人材を必要としないが、そのすべてが同じ二つの受信箱に届く。他に振り分ける先のキューが存在しないからだ。結果として、制作スタックに関する組織的な知識に本当に依存する、価値の高い差別化業務が、本来きちんと配置されたヘルプデスクが日常業務として処理すべき一般業務によって絶えず中断される。ストレージ権限の修正を待っているカラリストが、それを対応すべき担当者がパスワードのリセットを誰かに教えている間、ただ待たされている——これは会社が実際に支払っているのに、どこにも項目化されていないコストだ。

現実の問題その二: どちらかが休暇を取ると代役がいない

二人体制には本当の意味での冗長性がない。一人が有給休暇を取ると、もう一人が両方の業務量を引き受けることになり、会社が慣れているサービス水準は、その不在の期間だけ静かに低下する。二人が同時に対応できない場合——病気、カンファレンス、家庭の緊急事態——会社には実質的にIT機能が存在しなくなり、社内の誰もがそれを、口には出さなくとも承知している。これは仮定の極端な例ではない。二人しかいない以上、どちらかが対応できない状況は月に一度は起こることであり、めったにないことではない。会社のほぼすべての部門が、誰かが意図的に決めたわけでもないのに、「あの二人のIT担当に聞く」という単一障害点を日常業務の中に組み込んでしまっている。

現実の問題その三: パッチ適用と監視が誰の正式な仕事にもなっていない

問題を未然に防ぐ仕事——パッチ管理、エンドポイント監視、バックアップの検証、セキュリティアラートのレビュー——は、対応中のチケットのキューが決して空にならないときに、まさに後回しにされやすい種類の業務だ。それは明示的に誰かの担当になっていることはほとんどなく、「手が空いたときにやる」類の仕事であり、締め切り駆動型のメディア企業では、手が空いている時間などめったにない。これが生む危険は抽象的なものではない。パッチが当たっていないエンドポイント、何週間も前から静かに失敗し続けているのに誰も気づいていないバックアップ、誰にも処理する時間がなく三日間未読のまま放置されたセキュリティアラート——こうした穴は、専任の管理型ITセキュリティサービスという機能がまさに埋めるために存在するものだ。それは社内の担当者がこの仕事のやり方を知らないからではなく、他に何が燃えていようと関係なく、毎日、決まった予定に従ってそれを実行することを、誰の実際の仕事にもしてこなかったからにすぎない。

現実の問題その四: エスカレーションの実態は「メッセージに返信した人が対応する」

この状況にある企業の大半に、実際のインシデント・エスカレーションプロセスは何かと尋ねると、正直な答えはこうなる。誰かがWhatsAppやSlackで、オンラインに見える方のIT担当者にメッセージを送り、その人が自分で対応するか、転送する。何が緊急に該当するかの書面上の定義はなく、正式なオンコール体制もなく、普段返信している人が納品の締め切りに没頭していて二時間メッセージに気づかなかった場合の代替策もない。これはほとんどの場合うまくいく。なぜなら、存在しないプロセスの穴を、二人の有能な人材が埋めているからだ。しかし、それがまさに一番重要な瞬間に機能しなくなる——月曜の放送枠の直前、深夜のレンダー失敗。土曜の夜11時のランサムウェアアラート。「メッセージに返信した人が対応する」は、明確でテスト済みのエスカレーション経路とは決して同じものではないからだ。

Brocentの見解: 本当に問うべきは「社内か外注か」ではない

この状況にある企業にとって有用な問いは、「ITを社内に残すべきか外注すべきか」ではない。そう問うと、答えは常に「コントロール」と「コスト」の二者択一のように聞こえてしまい、現場で実際に起きていることを見落とすことになる。より良い問いは、この仕事のうちどれが本当にこの会社に固有で、どれが同種の企業ならすでに解決策を持っている問題なのか、というものだ。一般業務——ヘルプデスクのキュー、エンドポイントのパッチ適用、日常的な監視、標準インフラの時間外アラート——は、すでに24時間体制で回っていて、そのためのプロセスがすでに整っている部署に任せるべきだ。差別化された業務——ストレージアーキテクチャ、配信パイプライン、特定クライアントの技術要件に関する関係——は、それを構築し、なぜそのように構築したかを理解している人材のもとに残すべきだ。

この分担は、書面に落とし込まれて初めて実際に機能する。「基本的な部分は外部のプロバイダーが担当し、制作関連の部分は自社の人間が担当する」という口頭の合意は、キックオフミーティングでは合理的に聞こえるが、数か月のうちに崩れていく。境界があいまいなチケットは、最終的にすべて最も連絡しやすい相手——たいていはすでに背景知識を持つ社内チーム——に既定でまわされてしまうからだ。明確な包含・除外リストを作り、定期的に見直し、環境の変化に応じて更新することが、境界がその役割から解放されるはずだった二人の元に静かに戻ってくるのを防ぐ手段になる。Brocentが2007年以来共同管理型の体制を運用し、2016年に香港オフィスを開設して以来培ってきた経験からいえるのは、長期的に機能し続ける体制は、契約時の良好な口頭合意ではなく、書面化された境界線を持つ体制だということだ。

共同管理型の体制が実際にカバーするもの

このような企業にとって、共同管理型の体制は通常、明確に書面化された一般業務とインフラ業務の範囲を引き渡す一方で、社内の専門家が制作システムに集中し続け、それに触れるあらゆる事案の指名エスカレーション先であり続けられるようにするものだ。

チケットキュー。 パスワードのリセット、アカウントの発行と削除、プリンターや周辺機器の問題、一般的なソフトウェアサポート、そして現在社内の専門家を中断させている日常のヘルプデスク業務量は、独自のスタッフとサービスレベルを持つ専用キューに移行する。これにより、若手プロデューサーのWi-Fi問題が、カラリストのストレージ権限対応の一時間を奪うことはなくなる。

エンドポイントとパッチ管理。 企業側のノートPCとデスクトップは、制作チームがその週に追われている締め切りとは無関係に、予定に沿って動くマネージドのパッチ適用・監視サイクルに組み込まれる。これはまさに二人体制で最も確実に抜け落ちる部分であり、マネージドの機能が絶対に飛ばさないように設計されている部分でもある。

監視と時間外アラート。 インフラの監視と、本物の24時間365日のヘルプデスクが、「オンラインの人にメッセージを送る」という非公式なパターンに代わり、実際のオンコールプロセス、明確な重大度モデル、文書化された対応時間を提供する。土曜夜のインフラアラートに、誰かがたまたまスマートフォンを確認するかどうかに依存しない、実際の対応手段が生まれる。

社内専門家への指名エスカレーション。 共有ストレージアレイ、編集・カラーグレーディング環境、レンダーパイプライン、特定クライアントの納品要件など、制作スタックに触れるあらゆる事案は、それを担当する社内チームに名指しでエスカレーションされ、彼らはそのシステムの権威であり続ける。プロバイダーは制作環境をゼロから学ぼうとするのではなく、すでにそれを理解している人材へ、その場しのぎではなく文書化された引き継ぎプロセスを通じて経路付けする。

想定ではなく、定期的に見直される境界線。 包含・除外リストは、会社が新しいストレージプラットフォームを追加したり、新しい編集室を開設したり、配信ワークフローを変更したりするたびに、決まった頻度で見直され、契約時に固定されたまま放置されることはない。

二つの側面が実際に交差する場所

制作側と企業側は、上記の区分ほどきれいに分離しているわけではなく、共同管理型の体制はそれを考慮する必要がある。メディアファイルは最終的に共有ストレージアレイを離れ、耐久性のあるオフサイトの場所に置かれる必要がある。そのバックアップとアーカイブの層をきちんとした管理型ITクラウドサービスに載せることは、それが保護しているのが会社の最も価値ある資産であるにもかかわらず、明確に一般業務に属する。営業や経理のチームが使う企業ネットワークは、スイッチ、Wi-Fi、ファイアウォールといった物理インフラを、編集室が依存するネットワークと共有しているため、一方のセキュリティと監視は、もう一方に直接的な影響を及ぼす。よく書かれた範囲文書は、こうした接点を、その時々の都合で分類するのではなく、明示的に扱う。

何でも引き受ける社内二人体制 vs 完全外注（制作スタックの知識を失う）vs 書面化された包含・除外リストを持つ共同管理（Brocentのモデル）

• 何でも引き受ける社内二人体制 — 制作スタックについて、苦労して積み上げた深い知識があり、編集室で何かが壊れたときには本当に素早く対応できる。代償は、二人の専門家が毎週の大半の時間を一般業務のチケットに費やしてしまうこと、どちらかが休暇を取ると本当の代役がいないこと、そしてパッチ適用や監視のような予防的な業務が、対応中のキューが決して空にならないために無期限に後回しにされることだ。
• 完全外注（制作スタックの知識を失う） — 代役と一般業務チケットの問題は解決するが、メディアストレージや編集ワークフロー、納品仕様についてまったく背景知識を持たないベンダーに、社内チームが何年もかけて調整してきたシステムの責任を渡すことになる。学習曲線そのものが、会社が最も余裕を持てない締め切り駆動の瞬間にリスクを生み、どこにも書き残されていない組織的知識は、実質的に解雇された人材とともに会社を去っていく。
• 書面化された包含・除外リストを持つ共同管理（Brocentのモデル） — 一般業務のチケット、パッチ適用、監視、時間外アラートは、24時間体制で運用するために構築されたプロバイダーに移り、社内の専門家は制作スタックの所有権を保持し続け、あらゆる問題の既定の第一対応者ではなく、その指名エスカレーション先になる。正直なトレードオフは、これが境界線を書面化し定期的に見直した場合にのみ機能するという点だ。口頭の握手は、数か月のうちに「社内のあの二人に聞く」という元の状態に静かに戻っていく。

技術基盤の両側をつなぐ

この転換を検討しているメディア企業にとって、実際の出発点は通常、技術基盤のうち企業側の部分になる。なぜならそこは、あらゆるマネージドITプロバイダーがすでに大規模に運用している領域だからだ。24時間365日のヘルプデスクは、現在社内の専門家を中断させているパスワードのリセット、ノートPCの問題、時間外アラートを吸収する。管理型ITクラウドサービスは、バックアップ、アーカイブ、そして制作に固有ではないインフラを引き継ぎ、そこには会社が本当に失うわけにいかないメディア資産のオフサイトコピーも含まれる。そして管理型ITセキュリティサービスは、パッチ適用、エンドポイント監視、アラートのトリアージを、たまたまどの専門家に午後の空き時間があるかに依存しない、決まった予定に乗せる。これらのいずれも、社内チームが自ら構築したシステムを手放すことを求めるものではない。求められるのは、彼らが構築しなかったシステムの周りに書面上の線を引き、それを毎日、無期限に運用するために構築された部署に任せることだ。

よくある質問

共同管理型ITは実際には何を意味するのか

それは、技術基盤を「外部プロバイダーに移す業務」と「社内チームに残す業務」という二つの書面化されたカテゴリーに分けることを意味し、完全な社内対応と完全な外注のどちらかを選ぶことではない。実際には、プロバイダーがヘルプデスクのキュー、エンドポイントのパッチ適用、インフラの監視、標準システムの時間外アラートを引き受け、社内の専門家は制作に固有のシステムの所有権を保持し、それに触れるあらゆる案件の指名エスカレーション先になる、という形が一般的だ。この体制は、「基本的な部分と専門的な部分」というおおまかな感覚ではなく、書面化された包含・除外リストによって定義される。

共同管理は社内のIT人員が置き換えられることを意味するのか

いいえ。この体制は、現在社内の専門家の時間を奪っている一般業務を取り除くことで、彼らが自分たちにしかできない仕事に集中できるようにするために、特別に設計されたものだ。彼らの役割は、あらゆる種類のチケットの既定の第一対応者から、制作システムに関する指名の権威へと変わり、開かれたキューではなく、明確なエスカレーション経路が彼らに向けて設けられる。この転換を検討している企業は、たいてい専門家の時間を守り、燃え尽きを減らそうとしているのであって、彼らの知識を置き換えようとしているのではない。メディア企業においてその知識は何年もかけて築かれたものであり、通常は外部ベンダーが短期間で再現できるものではない。

プロバイダーに任せるものと社内に残すものはどう決めるのか

出発点となる問いは、あるシステムや業務が本当にこの会社に固有のものか、それとも同規模の企業であればすでに標準的な解決策を持っている問題かということだ。パスワードのリセット、エンドポイントのパッチ適用、メールボックスの管理、インフラの監視は、ほぼどの100人規模の企業でもほとんど変わらず、それを規模を持って運用するために構築されたプロバイダーに任せるべきだ。共有ストレージアレイ、編集・カラーグレーディング環境、レンダーパイプライン、そしてクライアント固有の納品要件は、この会社に固有であり、それを構築し調整してきた人材のもとに残すべきだ。結果は、時間とともに揺らいでいく暗黙の了解としてではなく、定期的に見直される明確なリストとして書き残される。

社内チームの役割やキャリアパスはどうなるのか

彼らの役割は通常、範囲としては狭まる一方で、専門性としては深まる。同じ午後の中でパスワードのリセットとストレージアーキテクチャの両方に注意を分散させる代わりに、本当に彼らの専門知識を必要とするシステムに時間を使い、プロバイダーがエスカレーションする相手として認められた権威になる。ポストプロダクションやシステムエンジニアリング出身の専門家の多くにとって、これはむしろ元々やりたかった仕事に近い。一般業務のチケット対応の負担は、たいてい採用時に依頼された仕事ではなく、既定として引き継いでしまったものだったからだ。

インシデントが境界をまたぐとき、誰が責任を負うのか

これはまさに、書面化された包含・除外リストとエスカレーションプロセスが、インシデントが起きている最中ではなく、起きる前に答えておくべき問いだ。よく設計された共同管理契約は、システムのカテゴリーごとに誰が第一対応の責任を持つかを明記し、プロバイダー所有のインフラから制作システムへと問題が越境した際の引き継ぎプロセスを定義し、その引き継ぎがどれくらいの速さで行われるべきかの期待値を設定する。境界線を事前に書き残しておくことこそが、インシデントが「これは誰の責任だったのか」という言い争いに発展するのを防ぐ。

有給休暇や退職の際には何が起きるのか

これは共同管理モデルの最も明確な利点の一つだ。以前は二人の専門家のどちらかが不在になるたびに止まったり遅れたりしていた一般業務が、誰が休暇中かに関係なく、プロバイダーのチームによって継続的にカバーされるようになる。そして、ある専門家が退職した場合、以前はその人の頭の中にしかなかった組織的知識のリスクは小さくなる。なぜなら一般業務側はそもそもその人に依存していなかったからだ。本当に引き継ぐべき制作固有の知識は、会社全体を巻き込む慌ただしい対応ではなく、より明確で規模の小さな引き継ぎ課題になる。

共同管理は完全マネージドと比べて料金の決まり方がどう違うのか

共同管理の料金は、一般的により狭く明確に定義された範囲を反映する。プロバイダーは明示的に対象範囲に含まれる業務カテゴリーに対して請求するのであり、会社内のすべてのシステムの完全な所有権に対して請求するわけではない。一方、完全マネージドの料金は、プロバイダーがゼロから学ぶ必要のあるシステムを含め、技術基盤全体をカバーする。どの企業でも一般業務と専門業務の境界線は異なるため、正確な比較方法は、汎用の価格表ではなく、この特定の企業のために書かれた範囲に対して行うことになる。料金についての話し合いは、包含・除外リストから始めるべきであり、その逆ではない。

あなたの制作スタックに合った分担を見つける

メディア制作会社は、「二人体制が限界を超えて疲弊すること」と「編集室を動かし続けている組織的知識を失うこと」のどちらかを選ばなければならないわけではない。実際の出発点は、正直な棚卸しだ。あなたのITチームは先週、実際に何に時間を使っていたのか、そのうちどれだけが、彼らの価値の源泉である専門知識を本当に必要としていたのか。もし答えが上記のシナリオに近いなら、意味のある次の一歩は、あなたのストレージ、配信、制作システムについて、書面化された境界線をどこに引くべきかを話し合うことであり、汎用のマネージドIT見積もりを当てはめることではない。あなたのチームにとって共同管理型の分担がどのようなものになるか、ぜひお問い合わせください。