都市オペレーションの業務内容（都市デジタルトランスフォーメーションの業務を考える）

都市のデジタル変革を考える

都市のデジタル変革についてどれくらいご存知ですか?以下の記事は、著者が個人の仕事の概要と業界データ分析に基づいて共有したものです。アーキテクチャ、実装（マイクロ）、ビジネスモデルに関連するコンテンツが含まれます。一緒に見てみましょう！

この記事では、個人の仕事の概要と業界のデータ分析を組み合わせて、都市のデジタル変革のプロセスにおけるアーキテクチャ、モデルなどに関するいくつかの考えと概要について詳しく説明します。 （全文は約6,000語で、読むのに10分ほどかかると予想されます。）

図1 アーキテクチャ図

デジタル基盤は、コア基盤、アプリケーション基盤、サービス基盤の 3 つの基盤に分かれています。

1) コア基盤

中核となる基盤はデータです。情報はデータから構成されており、情報化の実現はデータから切り離すことはできません。

データ収集の手段は、「コア基盤」における重要なリンクです。データ収集プロセス中に、データ標準が統一されていない、データ ソースが多様である、データ品質レベルが不均一であるなどの状況に遭遇することがあります。

これらの問題を解決するために、著者は次のように考えています。

主にデータ収集とデータ標準構築という 2 つの目標を達成する特別なデータ センターを設立する必要があります。

同時に、データ センターは専門的かつ権威あるものである必要があります。専門性はデータのセキュリティを確保することであり、権限はデータ収集の範囲を確保することです。

例えば：

上海のモデルでは、「上海ビッグデータセンター」は上海市人民政府弁公庁傘下の公的機関として、政府データ、産業データ、社会データ、およびさまざまな側面のデータの収集とアプリケーション統合を担当しています。同時に、データリソースの収集、相互接続、共有、および適用に関する技術標準と管理方法も策定され、市内の各地区や部門のデータ管理業務の指針となる予定です。

広東省のモデルでは、データ構築単位はあらゆるレベルの政治局とデジタル局です。政治局とデジタル局も政府総局傘下の部門管理機関であるが、いくつかの要因の影響により、政治局とデジタル局にはデータ収集とデータ標準化作業において十分な役割を担う余地がなく、課題の複雑さを解決することに抵抗があるのではないかと筆者は考えている。そのため、データ収集の範囲が不完全になったり、基準に一貫性がなかったり、品質が低下したり、適時性が低下したりしやすくなります。

筆者は、データの基礎・調整業務を政治デジタル局/ビッグデータセンターなどの政府代表が主導し、国有情報技術企業と連携し、国有企業の製品知識と技術力の助けを借りて、データ収集とデータ標準構築を完了できる新しいデータサービスモデルが実現可能であると考えている。

最終的な目標は、協力的かつオープンなアプローチを通じて「政府データのスーパーレイク」を作成し、「データ川」を通じてさまざまな「小さなデータレイク」（政府データに限定されない）を接続し、異なる川や湖の間にさまざまな「政府水利プロジェクト」を構築して、データの伝送とセキュリティを確保することです。

そのため、デジタル変革のプロセスでは、データ収集メカニズムとデータドッキング標準を継続的に改善し、標準化された手段に基づいて、直接的または間接的に各分野からデータを収集し、「コア基盤」を構築する必要があります。

2) 申請根拠

データの適用にはプラットフォームのサポートが必要です。そこで、アプリケーション基盤、すなわちデータミドルプラットフォームという概念が提案されています。

データセンター（中核基盤）が構築された後、データ循環、データ計算、データ応用など、データを情報に変換するプロセスでデータをさらに処理する必要があります。

ここでのデータアプリケーションは、大画面（コックピット、コマンドセンター）にさらに反映されます。これは、大画面の実装に大量のデータ計算とアプリケーションが含まれるためです。

したがって、大画面などのニーズを実現するために、データミドルプラットフォームはデータの処理と計算を担当し、大画面などの製品ニーズに対してより優れた基本的なサポートを提供します。

筆者は、前述のデータミドルプラットフォームは、プラットフォームの所有権や管理の問題を考慮する必要があると考えています。データ ミドル プラットフォームの目的は、アプリケーションに優れた高速なサービスを提供することです。サービスがタイムリーな応答を得られない場合は、「お飾り」になってしまう可能性があります。

同時に、大画面の価値は、ビジネスに対する理解度やデータの機密性に密接に関係しています。したがって、データミドルプラットフォームの構築は、データモデリングレベルの大きなテストとなります。

最後に、データミドルプラットフォームの構築時には、データモデリングプロセス中の業務認識の違いにより、その後の大画面指標の偏差を回避するために、データ製品とデータエンジニアが業務で緊密な連携を形成することが推奨されます。

3) サービスベース

データ応用の過程では、ほとんどの技術的能力が公共サービス属性を持っているため、サービス基盤の概念が提案されています。サービス基盤には、サービスミドルプラットフォームとアルゴリズムセンターが含まれます。

サービスミドルプラットフォームとは、主に公共の機能や技術を標準化してパッケージ化し、権限に基づいて適切に内部または外部に公開することを指します。例: 人口データベース、法人データベース、空間地理データベースなど。

アルゴリズムセンター（ハブ）とは、主にアルゴリズム機能を標準化してパッケージ化し、権限に基づいて社内外に技術機能を適切に付与することを指します。例：AI認識、ナレッジグラフなど。

4) まとめ

データが中核であり、アプリケーション基盤とサービス基盤はデータ基盤から派生したものです。これら 3 つの基盤は、プラットフォームを実現するだけでなく、カスタマイズによる拡張性、つまり「汎用性」、「実用性」、「使いやすさ」も備えている必要があります。

デジタルアプリケーションは、スマートプラットフォーム、コマンドセンター、特別プロジェクトの 3 つのタイプに分かれています。著者は、意思決定はユーザーの使用状況とビジネスデータの蓄積に基づいて行われるため、スマート プラットフォームの適用がコマンド センターよりも優先されると考えています。

構築の考え方は、使用によって生成されるデータ分析や使用中に生じるフィードバックを通じて、コマンドセンターの構築と改善を逆に促進することです。

著者はこの考え方を「まずアプリケーションを優先し、実際の意思決定のニーズを探る」と呼んでいます。上海にも「使える、使いやすいから、使いたくなる、愛着が湧く」という同様のスローガンがある。

つまり、まずは使えるようにし、次に使いやすくなるように磨きをかけ、最後に意思決定の改善を通じてアップグレードして、使いたくなるものにします。

1) スマートプラットフォームに関しては、主な役割から、次の3つの方向に分けることができます。

1. 公務員（準公務員）：主に公務員（準公務員）向けのプラットフォームです。行政機能から始まり、プラットフォームやデジタル情報技術を使用して、機能的な作業をより効率的かつインテリジェントに完了・実行し、都市運営をより適切に管理します。このようなプラットフォームには、スマート司法、スマート裁判所、スマート環境保護、スマート緊急対応、スマート政党建設、スマート政府問題などが含まれます。
2. 国民、法人およびその他の組織: このタイプのプラットフォームは、主に国民、法人およびその他の組織にサービスを提供しており、つまり、人々の生活に役立っています。このようなプラットフォームには、スマートヘルスケア、スマートパーキング、スマート教育、スマートコミュニティなどが含まれます。
3. その他: このタイプのプラットフォームは、主に業界、セクター、オブジェクトなどの定義コンテンツなど、他の方向のコンテンツを提供します。このようなプラットフォームには、スマート農業、スマートビジネス、スマート観光、スマートパークなどが含まれます。

2) コマンドセンターはスマートプラットフォームとは異なります。プラットフォームは主に目標（仕事の目標、人々の生活の目標など）に役立ち、コマンドセンターはリーダーシップに役立ちます。

大画面、データ分析、レポート、週報、月報を通じてリーダーに意思決定支援を提供し、都市の運営状況を直感的に把握します。

このようなセンターには、作戦管理指揮センター、世論センター、早期警戒センターなどが含まれます。

注目すべきは、既存の政務システムの意思決定支援製品の内容が、データの可視化に重点を置いていることである。データ分析の可視化が実現できていないと個人的には思っています。分析の主導権は依然としてユーザー自身が握る必要があります。しかし、ユーザーの時間と情報レベルをうまく活用できているでしょうか？これは考えなければならないテーマです。

3) 特別プロジェクトは主に、大規模、緊急かつ重要なタスクを対象としています。上記の 2 つとは異なり、特別プロジェクトではタスクの緊急性と厳しさが増します。

こうしたトピックには、ビジネス環境、伝染病の予防と管理、経済回復などが含まれます。

4) まとめると、著者は、特別プロジェクトとプラットフォームの間にはシナリオやビジネスの重複があると考えています。建設プロセス中、異なるメンバー間の場合は、密接なコミュニケーションと連絡が必要です。一人で戦うのではなく、団結して戦わなければなりません。

最初の部分では、主にマクロの観点から基礎と応用に関する考えを詳しく説明し、2 番目の部分では、主にミクロの観点からモデルと動作メカニズムに関する考えを詳しく説明します。

都市のデジタルトランスフォーメーションは、長いサイクルと多くの関係が絡む複雑なプロジェクトであるため、プロジェクトモデルに関しては、筆者自身の仕事経験に基づいた実践について簡単に述べるだけにとどめます。

私の経験では、情報技術プロジェクトには、従来のプロジェクト モデルと新しい運用モデルという 2 つの構築モデルがあります。

1) プロジェクトモデル プロジェクトモデルはシステム要件と機能構築によって導かれ、システム構築のハードウェアおよびソフトウェア要件と機能要件に基づいてプロジェクトが確立されます。

プロジェクト モードのプロセスで、著者は遭遇した次の 2 つの問題をまとめました。

①需要の問題

プロジェクト提案は通常、需要調査よりも早く開始されるため、多くの要件や機能設計が推測に基づいて提案され、実際のアプリケーション シナリオに完全に適合しない可能性があります。

しかし、スマートシティの構築、特に人々の生活に関わるスマートシティの構築は、ユーザーの実際の価値を中心に据える必要があると私は考えています。そのため、このプロジェクトモデルでは、受注時の施工が期待通りにいかないという状況が発生します。

②サービスの問題

ある程度、プロジェクト モデルは基本的に 1 回限りの構築サービスであり、最大で数年間のサポート サービスが付随します。さらに、ビルダーのコストの問題を考慮すると、サポート サービスの品質は平均的です。

しかし、近代都市の発展は急速です。建設プラットフォームが都市化の進行に追いつけず、建設需要が必須でないシナリオに適用できない場合、いつかは放棄されることになります（つまり、非効率的な建設になります）。

2) 運用モデル：運用モデルは、ユーザー価値とユーザーサービス指向の情報技術プロジェクト構築モデルであり、提供されるサービスの数と要件、構築するシステムの内容に基づいて構築されます。

このモデルはシステム構築コンテンツ自体を完全に放棄するものではないことに留意してください。システム構築（ソフトウェア機能設計）は残っていますが、この内容はソリューションの中核ではありません。

運用モデルのメリットは、プラン策定の過程で、ユーザーのより詳細なニーズを深く掘り下げる必要がなく、ユーザーにどのようなサービスを提供するかを考えることに集中できることです。プロジェクト モデルよりも抽象的です。

モデルを運用する過程で、著者は遭遇した次の 2 つの問題をまとめました。

①指標の問題

運用モデルの難しさは、サービスの内容をどのようにセグメント化するか、サービスの境界をどのように定義するか、サービスの枠組みをどのように計画するか、そしてサービスをどのように定量化するかにあります。定量化の核心はプロジェクト金額の計算にあります。これは、プロジェクトに関与する人々のレベルをテストするのに適したテストになる可能性があります (監査リスクが伴うため)。

②境界問題

運用モデルはシステム構築そのものを弱体化させますが、この内容が弱体化しているからこそ、プロジェクト構築の過程で、システム構築の境界をどう把握するか、コストをどうコントロールするか、プロジェクト構築の優先順位をどう計画するかが比較的難しい問題となります。

スマートシティの主な主体には、管理者、アプリケーション開発者、システムインテグレーター、サービスオペレーター、サードパーティ機関などが含まれるため、著者にはその複雑さを説明する専門的能力がありません。したがって、以下の議論は、著者が経験したプロジェクトの観点のみに基づいて行われます。

1) マネージャー プロジェクトの主な調整者および意思決定者であるマネージャーは、通常、政府が担当します。

マネージャーはプロジェクトの推進において重要な主導的役割を果たします。

例えば、ある省のスマートプラットフォームプロジェクトは、省政府の重点プロジェクトであるにもかかわらず、実際の管理者は省政府の構成部門（総弁公室が主導していない）です。この部門も大きな発言権を持っていますが、それでも、この方針に賛同しない、または十分に協力しない部門もいくつかあります。

そのため、実際にプロジェクトを推進する過程では、業界の各部門との密接な連携が不足する可能性があります。主導部門は標準を策定し、統一された標準に従ってプロジェクトを実施するだけです。そのため、ユーザーにとっての実用性はそれほど高くなく、使用率も高くありません。

例えば自治体のスマートプラットフォームプロジェクトでは、自治体の重要プロジェクトでもあります。省との違いは、実際の管理者は市政府の内部代理部門であり、対応する構成部門もビジネスリーダーとテクニカルリーダーに任命されることです。

すべてのプロジェクトの推進と報告は、主に市政府の内部機関と部門に基づいています。プロジェクトの推進や部門間の連絡に多少の障害が生じる可能性はありますが、主要プロセスの円滑な進行には影響しません。

2) アプリケーション開発者: プロジェクトのアプリケーション開発者は通常、企業です。

ある省のスマートプラットフォームプロジェクトモデルでは、「xx企業」は省デジタル政府建設・運営センターであり、トップレベルの設計、プラットフォーム構築、ビジネスイノベーションなどのサービスを提供しています。残りのシステム構築、実装、運用サービスは協力企業（エコパートナー）が担当します。

このモデルの利点は、「xx 企業」が省のデジタル政府プロジェクトの最高レベルの統一性、アーキテクチャの専門性、データ セキュリティを確保し、プロジェクトの配信プロセスを標準化できることです。

デメリットとしては、まず第一にビジネス知識が弱いという問題があることです。 「xx 企業」は標準と統一に重点を置いているため、ビジネス研究には依然として一定の制限があります。

同時に、「xxエンタープライズ」はユーザーとのコミュニケーションの直接の架け橋を担っています。システムビルダー（エコロジカルパートナー）は、ユーザーとのタイムリーかつ直接的な調査やコミュニケーションを実施することができず、その結果、ビルダーの需要設計における品質と革新性が不十分になります。

第二に、配送サイクルが長いです。成功または失敗はプロセスの仕様によって異なります。プロジェクトは静的なものではありません。プロジェクトの実施中にプロセス仕様を時間内に変更できない場合、プロジェクトの納品サイクルが延長され、建設業者のコストも増加します。

ある都市のスマートプラットフォームプロジェクトモデルでは、ビジネス部門（都市の構成部門）がビジネスのリーダーと需要のコントローラーであり、技術部門（都市の下部機関）がテクノロジーのリーダーとエンパワーメントの提供者であり、建設会社（メーカー）がプロジェクトのビルダーです。また、市役所、事業部、構成部署のプロジェクトチームにも参加し、共同でプロジェクトの構築と実施を推進します。

このモデルは、ビルダー、つまり建設会社の専門性と標準化、つまり標準建設とプロジェクト建設を遂行するのに十分な専門能力があるかどうかをテストします。

建設プロセス中、プロジェクトビルダーは、製品、設計、テスト、運用、保守など、プロジェクトの実装に参加して完了するためのさまざまな役割を必要とします。

動作メカニズムを私が理解する方法は次のとおりです。

1) マイルストーン マイルストーンはプロジェクトの中核です。

このマイルストーンは通常、プロジェクト マネージャーによって設定され、各時点で完了する必要がある作業目標を定義します。この目標は、プロジェクトの背景（原動力）として、すべてのパートナーに文書を通じて通知されます。

2) 実施計画のマイルストーンが策定された後、建設関係者は管理者と協力して、各マイルストーンの推進および実施の取り決めを精緻化します。これらは、関係する各ユニットや時点の配置に至るまで、さまざまな次元に従ってグループ化または分類できます。

計画が策定された後、マネージャーはプロジェクト推進会議を組織し、会議でプロジェクトの重要性と各ユニットへの要件を明確にするために、すべての参加ユニットに手紙を送ります。

3) 実施計画に基づいて、プロジェクト建設当事者とプロジェクト参加者は、より詳細な逆スケジュール計画を決定します。

逆スケジューリング計画が策定された後、一定期間内に何らかの形で管理者に報告され、他の参加者にコピーされます。計画の推進に遅延や困難が生じる恐れがある場合は、適時に会議を開催し、調整と解決を図ります。

4) ワーキンググループは、上記の計画に従ってワーキンググループを構成し、ワーキンググループの責任者と連絡先を特定し、計画の進捗状況とリスクを伝えるために定期的なプロジェクト会議を開催するものとする。

5) バージョン計画: 計画に従ってバージョンを計画します。バージョン計画プロセス中に、バージョン外の要件またはタスクが発生する可能性があり、動的な調整とタイムリーなレポートが必要になります。

バージョン計画におけるロール機能に関するいくつかの考えを以下に示します。

①プロジェクトマネージャー（PMO）

プロジェクト マネージャーには、外部コミュニケーションと内部コミュニケーションという 2 つの役割があります。

1. 外部プロジェクト マネージャーは、顧客とのコミュニケーション、顧客との良好なコミュニケーション関係の確立、プロジェクト情報のタイムリーな収集と報告を担当します。
2. 社内プロジェクト マネージャーは、プロジェクトのフォローアップ、プロジェクトまたはバージョンの進行状況の管理、プロジェクト コンテンツの細分化、リソースの合理的な計画、プロジェクト レポート資料の出力を担当します。

②プロダクトマネージャーなどのその他の役割

全員が自分の仕事をしている間、製品担当者はプロジェクト チーム全体の目標、つまり目標の統一とビジネスの専門性を調整する必要があります。配達は配達のためだけに行うことはできません。さらに重要なのは、各メンバーがビジネスについて一定の理解を持つことです。

概要: バージョン配信は、特にパートナーが多い場合には、変更要素の多い作業です。最も重要なのは、いかに情報を統合し、リスクを防ぐかです。

著者は、スマート シティの方向性は人々と都市の運営に役立つことであると考えています。しかし、サービスの前提は生存であり、生存の核心は価値です。企業が競争の中でどのように生き残り、より大きな価値を提供するかは、ビジネスモデルの重要な部分です。

著者は、プロジェクト実施のプロセスにおいて、デリバリー中心のコンセプトを放棄し、製品中心のコンセプトに焦点を当てる必要があると提案しています。

これは、各都市の市場、環境、条件が均一ではないためです。製品が外部に浸透したり、ベンチマークになったりする必要がある場合は、スマートシティプロジェクトの構築プロセス中に各事業セグメントを可能な限り分離し、各事業セグメントが独立して運営できるようにする必要があります。

第二に、プラットフォームは可能な限り他の都市でも複製および適応できるように、可能な限り汎用的、または高度に拡張可能である必要があります。

政府や企業向けの情報サービスの範囲内で、純粋に公共福祉サービスの製品化されたコンテンツがまだ存在すると著者は考えていることは言及する価値がある。こうしたコンテンツは、商業的な発想を捨て、「公共福祉サービス」の観点から出発し、人々の問題を効果的に解決する必要があります。定量的な問題の解決から始めて、継続的に投資し、公共の福祉価値を生み出します。

最後に、収益の面では、政府からプロジェクト収益を得ながら、標準化された機能やデータをサービスとしてパッケージ化し、B サイドに販売できるでしょうか。

上記の内容は、あくまでも私が仕事や読書の中でまとめた個人的な考察です。説明に不適切な点がありましたら、ご批判、ご訂正をお願いいたします。ありがとう！

Baidu City デジタル変革ホワイトペーパー - Liu Jie、Xu Zhifa

新しいスマートシティの設計と建設 - 劉 易勝

この記事はもともと @小刘 によって Everyone is a Product Manager に掲載されました。無断転載禁止

タイトル画像はCC0プロトコルに基づいたUnsplashからのものです

この記事で述べられている意見は著者自身の意見のみを表しており、人人士品夢家プラットフォームは情報保存スペースサービスのみを提供します。