このメモはl’Observatoire du Long Termeからの転記であり、スケールアップにおける建築家の役割についての個人的な考察がそれに続きます。
マンハッタン南部の狭く不規則な通りは、予測不可能な名前とあらゆる角度で交差する交差点があり、幅が広く直角に交差する碁盤目状の通り（1番街から220番街まで）と大通り（1番街から12番街まで）が並ぶニューヨークの他の地域とは著しく対照的である。
その理由は歴史的なものだ。17世紀初頭、ニューヨークがオランダの交易拠点として機能し始めた頃は、都市計画など存在しなかった。街路は住民の通行路に沿って作られたり、必要に応じて追加されたりして、包括的な構想はなかった。そのため、ニューヨークへの移動は（特に外国人観光客にとっては）困難であり、公共事業の計画も難しく、都市の成長を組織的に管理することも困難だった。
マンハッタン南部は（差し迫ったニーズに対応する）配管工によって整備されたのに対し、ニューヨークのその他の地域は（交通ニーズに関する長期的なビジョンと、シンプルさと全体的な効率性への配慮に基づいて）建築家によって設計された。
管理システムにも同じことが言えます。一部のシステムは、追加のアーキテクチャ設計の手間を犠牲にして、ユーザーの時間を最適化するように設計されています。一方、他のシステムは、配管工が次から次へと漏水箇所を修理するように、形式的な手続きや一貫性のない文書を積み重ねることで、規則作成者の労力を最小限に抑えています。
シンガポールは、公共政策をユーザーの効率を最大化するように設計・管理することを目的とした「エンジニアリング・アプローチ」を採用することで、最初のカテゴリーにおいて圧倒的な優位性を誇っています。すべての新規規制は十分なメリットを実証する必要があり、既存の規制は最適化と不要になった場合の廃止を目的とした定期的な効率性レビューを受けています。機能的な「アーキテクチャ規則」が課せられ、ユーザーにとっての文書や手続きの効率を「最適化」しています。これには、共通データ標準、事前入力済みフォームの広範な使用（標準データに基づく）、共通ソフトウェアコンポーネントの必須使用（例えば、支払いやデータ収集用）などが含まれます。
デジタル化を担当する機関は、チーフアーキテクトとして重要な役割を果たし、各省庁の標準実装担当のファンクショナルアーキテクトに頼っています。デジタル技術は、プロセスの簡素化や調和化にしばしば役立ちます。手順をデジタル化する際に、これらの手順、あるいは手順に必要な情報や文書の過剰な多様性によるコストが明らかになります。デジタル化以前は、この複雑さはユーザーが負担していました。デジタル化によって、この多様性によるコストが明らかになり、部門間で異なるプロセスを調和させることによるメリットも明らかになります。
(画像クレジット: Agentic Design Patterns)
フランスでは、企業や利用者は、行政手続きの複雑さによる「時間的負担」がヨーロッパで最も高い部類に入り、長期展望研究所の推計では、その負担はGDPの6ポイント（約1,700億ユーロ）に相当する。過去の簡素化の取り組みは、見直し（通常は新たな条文によって回避される）や法典の書き換え（通常は後にさらに複雑化する形で修正される）など、単発的な試みにとどまることが多かった。
このような取り組みの規模を拡大し、長期的に定着させるには、2つの方法がある。1つ目は、シンガポールが行ったように、ソフトウェア/ITの都市化に触発されたアーキテクチャ原則と、（管理中心のアプローチではなく）ユーザー中心のアプローチを導入することで、行政生産を再構築することである。
2つ目は、「時間税」を評価し、例えば500億ユーロの削減といった目標を設定することです。まずは限られた手段から始めることができます。例えば、上位100の主要な手続きにかかる時間をサンプリングしてみるのも良いでしょう。「ノーモスコープ」という共同ツールを使えば、利用者が直面する手続き上の問題点を共有することも可能です。フランスの家計はかつてないほど逼迫しているため、生活の質の向上に貢献しない負担から解放する必要があります。
管理上の複雑さに関して言えば、それは「より多くの設計要素が必要で、より少ない配管工事が必要だ」ということを意味する。
余談：スケールアップにおける複雑性の整理
見出しへのリンク
なぜ一部のスタートアップ企業は成長して成功を収める一方で、他の企業は苦戦するのか、私はしばしば疑問に思ってきました。その答えは、たいていの場合、適材適所の人材配置にあります。それを実現するためには、アーキテクトが実際にどのような役割を担うべきかを理解することが重要です。
スープ、キッチン、そしてメニュー
見出しへのリンク
スタートアップを、スープを提供するレストランに例えて考えてみましょう。最初のスープが大ヒットし、事業の成長を後押ししました。レストランが拡大するにつれ、料理人が増え、レシピも増え、物事はより複雑になっていきました。新しい料理人とレシピが増えるたびに、厨房の作業は遅くなっていきました。この問題を解決するため、スタートアップの創業者たちは、物事を軌道に乗せるためにプロジェクト管理オフィス（PMO）を設立することにしました。
PMOチームはすぐに、重要な何かが欠けていることに気づきました。それは、キッチンの運営方法に関する明確な計画です。彼らは、各調理担当者に具体的な責任を与え、詳細なタスクリストを作成し、見積もった作業量に基づいてマスタープランを作成することで、この問題を解決しようと試みました。しかし、どれもうまくいきませんでした。PMOは、その理由が分かりませんでした。すべて文書化されているのに、なぜ機能しないのでしょうか？
問題は、その本にはスープの作り方は書いてあったものの、スープの中身が何であるべきかは書かれていなかったことだった。PMOは、もはや単に1種類のスープを作っているのではなく、製品開発者（PM）が作成したメニューに応じて、さまざまな料理を作るために使えるスープストックを作っているということに気づいていなかった。PMOチームは、本当の問題を解決する代わりに、計画なしに道路を増設するように、ただ単にプロセスを「配管」しているだけだった。
PMOが本当に必要としていたのは、北マンハッタンの道路のように、すべてがスムーズに運用され、時間とともに拡張できる、適切に設計されたシステムだった。PMOの過ちは、複雑さを整理するための計画の設計図を作成するアーキテクトが必要であることを認識していなかったことだった。
多くのスケールアップ企業では、エンジニアリングディレクター（https://www.hatica.io/blog/metrics-and-kpis-for-director-of-engineering/）が1人しかおらず、そのディレクターはアーキテクチャの設計だけでなく、チームの成長マインドセット（https://online.hbs.edu/blog/post/growth-mindset-vs-fixed-mindset）の確保にも責任を負っています。目標は、効率性を押し付けるのではなく、チームが効率性を主体的に担えるようにすることです。これらのステップが完了して初めて、スケールアップの準備が整うのです。
プロジェクト主導型組織
最近、HBRの記事「プロジェクト主導型組織」(https://hbr.org/2026/01/the-project-driven-organization)を偶然見つけました。組織設計、リーダーシップ、価値創造という3つの要素を中心とした構造的なアプローチは素晴らしいと思います。しかし、一つ欠けている点があります。それは、アイデアを収益性の高い製品に変えるための戦略です。
下の図は、元のコンセプトを再構成したもので、アイデアを収益性の高い製品に変えるための戦略とも言える「ロードプラン」という要素を追加しました。また、異なるチーム間の橋渡し役となる「エンジニアリングチーム」も追加しました。
この図では、建築家が道路計画に意見を出しているのでしょうか？それとも、道路計画が建築家への意見として与えられているのでしょうか？あるいは、建築家がプロジェクトチームに意見を出しているのでしょうか？文脈によっては、どれも正解です。重要なのは、道路を建設するのはエンジニアリングチームであり、彼らはそれに従うための計画、つまり「具体化」するための設計図を必要としているということです。
プロジェクトを利益に変える
下の図は、キッチンの設計と整理の良し悪しを示しているのでしょうか？それとも、PMOがどれだけ効率的に運営し、利益につなげられるかを示しているのでしょうか？
(画像提供: )
物事が複雑になりすぎて手に負えなくなったときは、次の2つのシンプルなルールで複雑さを整理することを考えてみてください。「もっと構造を設計し、配管は少なくする」！