『未来から現在を設計する』――生成ポテンシャルから日本の未来実装時間を引き寄せる文明アーキテクチャ（第2回）（第Ⅰ部 Future Pull――未来を現在へ引く 第1章 未来生成ポテンシャル〜第2章 時間を設計する）
第Ⅰ部 Future Pull
――未来を現在へ引く
未来について考えるとき、私たちは通常、現在から先を見る。
人口を予測する。
経済を予測する。
Technologyの進歩を予測する。
社会の変化を予測する。
そして、その未来へ備える。
この方法は必要である。
しかし、本書ではもう一本の時間軸を加える。
未来から現在を見る。
⸻
たとえば、2035年に実現している社会を考える。
AIが行政、産業、医療、教育の中で安全に利用されている。
医療Dataが適切に連携され、予防と治療がより滑らかにつながっている。
人口減少地域でも、交通、物流、医療、行政Serviceが維持されている。
大学の研究成果が、企業や社会へ迅速に移転されている。
Energy Systemがより分散化され、災害にも強くなっている。
こうしたFuture Stateを置いたとき、
問いは、
「2035年にはどうなっているだろうか」
から、
「その状態を実現するために、2026年から何を始める必要があるのか」
へ変わる。
これが、Future Pullの出発点である。
⸻
未来を現在へ引くとは、
未来を強制的に早めることではない。
未来の状態から、
必要条件を現在へ逆算することである。
Technology。
制度。
資本。
人材。
Data。
Infrastructure。
研究。
社会的合意。
それらのうち、
何がすでに存在しているのか。
何が不足しているのか。
何に時間がかかるのか。
誰が動く必要があるのか。
未来を分解すると、
遠い将来像は、
現在の具体的な課題へ変わる。
⸻
このとき、
未来までの距離は年数だけではなくなる。
ある未来は、
Technologyが完成していないため遠い。
別の未来は、
制度が整っていないため遠い。
別の未来は、
資金が不足しているため遠い。
さらに別の未来は、
必要なものがすべて存在しているのに、
組織同士が接続されていないため遠い。
つまり、
未来までの距離とは、
実装条件の距離
である。
⸻
Future Pullは、
この距離を短縮する。
ただし、
必要な時間まで削るわけではない。
医薬品の安全性確認。
基礎研究。
Infrastructure建設。
人材育成。
社会的合意。
これらには、
本質的に必要な時間がある。
短縮すべきなのは、
その間に存在する不要な待ち時間である。
情報が届かない。
判断が止まる。
制度とTechnologyが別々に動く。
研究と産業が接続されない。
実証結果が次の政策へ反映されない。
こうした時間を減らす。
速くするのではなく、止まっている時間を減らす。
それだけでも、
未来は大きく近づく。
⸻
そして、
Future Pullは、
未来の可能性を現在の中から発見する方法でもある。
未来に必要なものを逆算すると、
現在にすでに存在している資源が見えてくる。
企業。
大学。
研究。
Technology。
医療機関。
金融資産。
地域。
文化。
Infrastructure。
人材。
これらは、
現在の社会を維持するためだけに存在しているのではない。
組み合わせを変えれば、
次の社会を生み出す資源になる。
つまり、
未来の一部は、
すでに現在に存在している。
まだ、
未来として接続されていないだけである。
⸻
ここで重要になるのが、
Potential Space
である。
現在には、
一つの未来だけが含まれているわけではない。
同じAIでも、
行政へ接続する未来。
医療へ接続する未来。
教育へ接続する未来。
Manufacturingへ接続する未来。
文化へ接続する未来。
さまざまな可能性がある。
資本の配分を変えれば、
別の産業が成長する。
制度を変えれば、
別のServiceが成立する。
教育を変えれば、
十年後の人材構成が変わる。
現在は、
複数の未来へ分岐できる。
Future Pullとは、
その中から一つの未来を絶対化することではない。
複数の可能性を比較し、実装可能な方向を選ぶこと
である。
⸻
だから、
Future Stateも固定しない。
未来を置く。
現在から実装する。
Realityを見る。
想定と違えば修正する。
そして、
Future Stateそのものも更新する。
未来から現在へ。
現在から未来へ。
この往復を続ける。
Future Pullは、
一度だけ未来を決める長期計画ではない。
未来と現在を継続的に接続する方法
である。
⸻
この方法は、
日本にとって特に重要になる。
日本には、
未来を生み出す能力が存在している。
一方で、
その能力が社会実装へ到達するまでに時間がかかる場合がある。
研究から事業へ。
Technologyから制度へ。
Startupから市場へ。
実証から全国展開へ。
大学から産業へ。
地域の成功から他地域へ。
この間に存在する距離を短縮できれば、
新しい資源を大量に追加しなくても、
未来実装速度を上げられる可能性がある。
⸻
第Ⅰ部では、
そのための基本構造をつくる。
第1章では、
未来生成ポテンシャル
を扱う。
未来はどこに存在するのか。
Potential Spaceとは何か。
Future Stateをどう置くのか。
未来からRequirementをどう引くのか。
そして、
Future Pullとは何なのか。
未来を現在へ引くための基本的な考え方を整理する。
⸻
第2章では、
時間そのものを設計する。
社会には、
複数の時間がある。
予測時間。
制度時間。
技術時間。
文明時間。
それぞれの速度は違う。
Future Pullは、
これらを同じ速度へ揃えるものではない。
時間がかかるものを早く開始し、
短期間で実装できるものは先に試し、
並行できる工程は並行する。
つまり、
未来までの時間を、
一つの直線としてではなく、
複数の実装時間として設計する。
⸻
ここから、
本書のArchitectureが始まる。
まだ、
政府も日本銀行も産業界も医療も個別には扱わない。
まず、
それらすべてに共通する問いをつくる。
どの未来を置くのか。
現在には何があるのか。
何が足りないのか。
何に時間がかかるのか。
今日から何を始められるのか。
この問いを持ったうえで、
次の部から日本の具体的なRealityへ入っていく。
⸻
未来は、
日付の向こう側にだけ存在しているのではない。
未来に必要なTechnologyの一部は、
すでに存在している。
必要な人材もいる。
資本もある。
研究もある。
制度もある。
地域もある。
文化もある。
まだ足りないものもある。
しかし、
何が足りないのかを知ることができれば、
準備を始めることができる。
⸻
未来を待つ。
未来を予測する。
未来へ備える。
そこから、
もう一段進む。
未来から必要条件を引く。
現在の資源を接続する。
実装可能なものからRealityへ変える。
この方向へ時間軸を一本加える。
それが、
Future Pullである。
未来は、
時間が経過した先にだけあるのではない。
未来から現在まで、
実装の線を引いた瞬間、
その未来は、
すでに現在から始まっている。
第1章 未来生成ポテンシャル
第1節 未来はどこに存在するのか
未来は、まだ存在していない。
少なくとも、Realityとしては存在していない。
2035年の日本。
2050年の社会。
次世代の医療。
新しい産業。
AIと共存する行政。
それらは現在から見れば、まだ実現していない状態である。
では、
未来はどこに存在するのか。
⸻
一般的には、
未来は「これから来る時間」として理解される。
今日の次に明日が来る。
2026年の後に2027年が来る。
時間が経過し、
社会が変化し、
未来が現在になる。
この意味では、
未来はまだ存在していない。
しかし、
社会を設計する立場から見ると、
もう少し違う捉え方ができる。
未来は、
完成したRealityとして存在していなくても、
可能性として現在に存在している。
⸻
たとえば、
新しい医薬品の候補物質が発見されたとする。
まだ薬ではない。
患者も治療していない。
しかし、
研究を進め、
安全性と有効性を確認し、
承認され、
製造されれば、
将来の治療になる可能性がある。
その未来は、
まだRealityではない。
しかし、
完全な「無」でもない。
候補物質。
研究Data。
研究者。
設備。
資金。
臨床試験。
制度。
これらの中に、
未来の治療へ到達できる可能性が存在している。
⸻
AIも同じである。
あるAI技術が存在する。
現在は、
文章作成や情報整理に使われている。
しかし、
行政Dataと接続すれば、
行政Serviceを変える可能性がある。
医療Dataと接続すれば、
医療支援へ展開する可能性がある。
製造現場と接続すれば、
生産工程を変える可能性がある。
教育へ接続すれば、
学習方法を変える可能性がある。
つまり、
一つのTechnologyの中に、
複数の未来が存在する。
ただし、
まだどの未来も完全には実現していない。
⸻
ここで、
未来を二つに分けて考えることができる。
実現した未来。
そして、
実現可能な未来。
前者は、
未来の日付が現在になったとき、
Realityとして観測できる。
後者は、
現在のTechnology、Knowledge、資本、人材、制度、社会条件の組み合わせによって、
実現する可能性を持っている。
本書が扱うのは、
主として後者である。
⸻
未来生成ポテンシャルとは、
現在から次の状態を生み出せる可能性である。
重要なのは、
未来が一つではないことである。
同じ現在から、
複数の未来へ進むことができる。
ある資本を、
既存事業へ投資する。
Startupへ投資する。
基礎研究へ投資する。
地域Infrastructureへ投資する。
投資先によって、
数年後のRealityは変わる。
同じ現在でも、
選択によって未来は分岐する。
⸻
政策も同じである。
人口減少という同じ条件から、
公共Serviceを縮小する未来もあり得る。
Digital化によって維持する未来もある。
地域拠点を集約する未来もある。
自動運転や遠隔医療を導入する未来もある。
複数の政策を組み合わせる未来もある。
つまり、
人口推計が一つだからといって、
社会の未来まで一つに決まるわけではない。
条件は未来を制約するが、未来を一意には決めない。
⸻
この違いは重要である。
未来予測では、
「何が起こる可能性が高いか」
を考える。
未来設計では、
「どの未来を実現できるか」
を考える。
さらに、
「どの未来を実現したいか」
を考える。
そして最後に、
「そのために現在何を変える必要があるか」
へ戻る。
ここで、
未来は予測対象から、
設計対象へ変わる。
⸻
しかし、
未来を自由に選べるわけではない。
現在には制約がある。
財政。
人口。
法律。
Technology。
資源。
地理。
国際関係。
人材。
社会的価値観。
これらを無視した未来像は、
Visionにはなっても、
実装可能な未来にはならない。
したがって、
未来生成ポテンシャルは、
願望とは区別しなければならない。
Potentialとは、現在の条件から実装経路を引くことができる可能性
である。
⸻
その経路が重要になる。
たとえば、
2050年に新しいEnergy Systemを実現したいとする。
そのためには、
発電技術。
送電網。
蓄電。
設備投資。
規制。
土地。
人材。
Supply Chain。
地域との合意。
が必要になる。
これらを現在から2050年まで接続できるなら、
その未来には実装可能性がある。
接続できないなら、
不足している条件を明らかにしなければならない。
つまり、
未来の存在場所とは、
遠い未来の日付だけではない。
現在から未来へ到達する経路の中にも存在している。
⸻
そして、
未来はTechnologyだけに存在するのではない。
制度にも存在する。
新しい法律。
新しい行政手続き。
新しい金融制度。
新しい教育制度。
それらが実現すれば、
現在では成立しない事業や生活が可能になる。
未来は、
制度の選択肢としても存在している。
⸻
人材にも存在する。
現在大学で学んでいる学生が、
十年後に研究者になる。
Engineerになる。
医師になる。
起業家になる。
行政官になる。
芸術家になる。
現在の教育は、
未来の社会能力を形成している。
つまり、
未来の一部は、
現在育成されている人間の中に存在する。
⸻
資本にも存在する。
現在の資金を、
何へ投資するか。
その選択によって、
未来の生産能力が変わる。
工場。
研究所。
Data Center。
病院。
大学。
Energy Infrastructure。
文化施設。
Startup。
現在の投資は、
未来のRealityを先に建設している。
この意味で、
資本は、
未来へ移動するための手段であると同時に、
未来を現在から形成する手段
でもある。
⸻
文化にも未来は存在する。
芸術。
音楽。
文学。
映画。
Design。
これらは、
社会がまだ制度化していない価値観や感覚を、
先に表現することがある。
後になって、
社会がその表現に追いつく。
つまり、
未来は、
研究所やTechnology企業だけで生まれるわけではない。
人間の想像力の中にも、
まだRealityになっていない社会の可能性が存在する。
⸻
さらに、
過去の中にも未来の材料がある。
伝統。
地域文化。
神社。
寺院。
祭り。
工芸。
古いInfrastructure。
過去から継承されたものは、
過去に属しているだけではない。
現代のTechnologyや産業と新しく接続すれば、
別の価値を生み出すことがある。
伝統を保存するだけでなく、
未来へ翻訳する。
すると、
過去の資産が、
未来生成ポテンシャルへ変わる。
⸻
したがって、
未来は一つの場所に存在しているわけではない。
Technologyにある。
Knowledgeにある。
制度にある。
資本にある。
人材にある。
地域にある。
文化にある。
自然にある。
社会課題の中にもある。
そして、
それらの関係の間にある。
⸻
特に重要なのは、
最後の点である。
未来の多くは、
一つの資源だけでは実現しない。
AIだけでは医療は変わらない。
医療Data。
医師。
病院。
制度。
患者。
Security。
Finance。
それらが接続されて初めて、
新しい医療がRealityになる。
つまり、
未来生成ポテンシャルは、
個々の要素の中だけでなく、
まだ接続されていない要素の間に存在する。
⸻
この視点を持つと、
現在の見え方が変わる。
何が不足しているかだけではなく、
何がすでにあるかを見る。
さらに、
何と何を接続できるかを見る。
日本には、
多くの企業がある。
大学がある。
研究機関がある。
医療機関がある。
金融資産がある。
地域資源がある。
文化がある。
Infrastructureがある。
未来がないのではない。
未来になる前の要素が、現在に分散して存在している。
⸻
だから、
未来を探すために、
未来の日付まで待つ必要はない。
現在を見る。
Technologyを見る。
制度を見る。
人を見る。
資本を見る。
地域を見る。
文化を見る。
そして、
その間を見る。
そこに、
まだRealityになっていない未来がある。
⸻
未来とは、
遠い時間の先に完成して待っている世界ではない。
現在の中に存在する複数の可能性が、
選択され、
接続され、
実装された結果として現れるRealityである。
したがって、
未来はどこに存在するのか。
本書の答えは、
明確である。
未来は、まだ実現されていない現在の可能性の中に存在する。
そして、
その可能性を発見し、
未来へ到達できる形に組み替えること。
そこから、
未来の設計が始まる。
第2節 Potential Space
現在から未来へ向かう道は、一つではない。
同じTechnology。
同じ資本。
同じ人材。
同じ制度。
同じ社会課題。
それらを持っていても、どのように組み合わせ、何を選択するかによって、異なる未来が生まれる。
この、現在から実現可能な複数の未来が存在する領域を、本書ではPotential Spaceと呼ぶ。
⸻
たとえばAIを考える。
AIを既存業務の効率化だけに使う未来がある。
新しい製品やServiceの開発に使う未来もある。
医療へ接続する。
教育へ接続する。
行政へ接続する。
製造へ接続する。
科学研究へ接続する。
同じ基盤技術から、多数の未来が分岐する。
AIそのものが未来なのではない。
AIと社会の何を接続するかによって、未来が変わる。
そこにPotential Spaceがある。
⸻
国家も同じである。
日本には、
人口。
産業。
資本。
Infrastructure。
大学。
研究機関。
医療制度。
地域。
文化。
自然。
そして長い歴史がある。
これらを現在の配置のまま維持すれば、その延長として一つの未来が現れる。
しかし、配置や関係を変えれば、別の未来が生まれる。
大学と企業の関係を変える。
金融とStartupの関係を変える。
医療とTechnologyの関係を変える。
中央政府と自治体の関係を変える。
地域とEnergyの関係を変える。
文化と産業の関係を変える。
新しい資源を追加しなくても、
関係を変えるだけで未来の選択肢は増える。
⸻
この視点は、
従来の未来予測とは異なる。
予測では、
現在の状態とTrendから、
最も起こりそうな未来を推計する。
Potential Spaceでは、
現在の条件から、
どのような未来が実現可能なのか
を広く見る。
つまり、
Forecastが一本の可能性の高い線を探すのに対し、
Potential Spaceは、
その周囲に存在する複数の経路を見る。
⸻
ただし、
Potential Spaceは無限の空想ではない。
実現可能性には制約がある。
Technology。
資金。
法律。
人材。
時間。
自然環境。
国際関係。
安全性。
社会的受容。
これらによって、
実現できる未来と、
現時点では実現できない未来が分かれる。
したがって、
Potential Spaceを考えるときには、
可能性だけでなく、
Constraint
も同時に見なければならない。
⸻
たとえば、
人口減少地域で、
すべての公共Serviceを現在と同じ形で維持することは難しいかもしれない。
しかし、
Serviceそのものを維持する方法は一つではない。
行政をDigital化する。
遠隔医療を導入する。
移動Serviceを統合する。
物流と交通を組み合わせる。
公共施設を複合化する。
複数自治体で機能を共有する。
人口というConstraintは変わらなくても、
設計の選択肢は存在する。
制約があることと、未来が一つに決まることは同じではない。
⸻
Potential Spaceを見る意味は、
ここにある。
問題に対して、
一つの解決策をすぐに決めない。
まず、
どのような選択肢が存在するのかを見る。
そのうえで、
費用。
効果。
Risk。
実装時間。
社会的影響。
将来の変更可能性。
を比較する。
未来を選択する前に、
未来の選択肢そのものを広げる。
⸻
これは政策において重要である。
一度大規模なInfrastructureを建設すれば、
数十年間使うことになる。
一度制度を固定すれば、
多くの企業や生活がその制度へ適応する。
だから、
現在の最適解だけで決めてはいけない。
将来、
Technologyや人口構造が変わったとき、
別の選択肢へ移行できるかを見る必要がある。
つまり、
良い未来設計とは、
一つの未来を完璧に固定することではない。
将来の選択可能性を残すこと
でもある。
⸻
企業経営でも同じである。
一つのTechnologyへすべての資源を集中すれば、
成功した場合の利益は大きい。
しかし、
市場環境が変われば大きなRiskになる。
複数の研究開発。
複数の市場。
複数の事業モデル。
複数の提携先。
一定の選択肢を保持しておけば、
Realityの変化に応じて方向を変えられる。
Potential Spaceは、
未来の可能性を増やすだけではない。
不確実性へ対応するための余地
でもある。
⸻
ここで、
生成ポテンシャルの意味がさらに明確になる。
生成ポテンシャルとは、
未来を一つ生み出す能力ではない。
複数のFuture Stateへ移行できる能力
である。
Technologyが汎用的であるほど、
多くの産業へ応用できる。
人材が複数領域を理解しているほど、
異なる仕事へ移動できる。
Dataが標準化されているほど、
新しいServiceへ再利用できる。
Infrastructureが柔軟であるほど、
新しい用途へ対応できる。
つまり、
Potential Spaceを広く保つことは、
社会の適応力を高めることでもある。
⸻
日本全体で考えるなら、
重要なのは、
一つの国家Visionへすべてを固定することではない。
複数の地域で、
異なる未来を試す。
複数の企業が、
異なるTechnologyを開発する。
大学が、
異なる研究を進める。
金融が、
複数の可能性へ資本を配分する。
政府は、
その試行を可能にする制度環境を整える。
すると、
日本全体が、
一つの巨大なProjectではなく、
多数の未来を同時に探索するPortfolio
になる。
⸻
この構造には大きな利点がある。
どの未来が成功するかを、
最初から完全に予測する必要がない。
小さく試す。
結果を見る。
有効なものへ資源を増やす。
機能しないものは修正する。
必要なら終了する。
そして、
新しい可能性を試す。
これは、
企業のInnovationだけではなく、
政策や社会設計にも使える。
⸻
AI時代には、
Potential Spaceはさらに広がる。
AIによって、
設計。
分析。
Simulation。
Programming。
研究。
Content制作。
業務Automation。
などのコストが下がれば、
以前なら試すことのできなかった案を、
より小さな費用で検証できる。
つまり、
AIの重要な効果の一つは、
既存業務を効率化することだけではない。
社会が探索できる未来の数を増やすこと
にある。
⸻
しかし、
選択肢が増えるだけでは、
未来は実現しない。
Potential Spaceが広すぎれば、
何を選ぶべきか分からなくなる。
だから、
次に必要になるのが、
Future Stateである。
どのような社会を目指すのか。
どの問題を解決したいのか。
どの価値を守りたいのか。
何を優先するのか。
その方向があることで、
Potential Spaceの中から、
実装すべき未来を選ぶことができる。
⸻
ここで、
Potential SpaceとFuture Stateの関係が見える。
Potential Spaceは、
可能な未来の集合である。
Future Stateは、
その中から選ばれた、
実現を目指す状態である。
そして、
Current StateからFuture Stateへ到達するために、
Requirementを引く。
この構造が、
Future Pullの基本になる。
Potential Space
→ Future State
→ Requirement
→ Implementation
→ Reality
⸻
ただし、
Realityが変化すれば、
Potential Spaceも変化する。
新しいTechnologyが登場する。
法律が変わる。
国際情勢が変わる。
人口が変わる。
新しい研究成果が生まれる。
すると、
昨日まで不可能だった未来が、
今日には実現可能になることがある。
逆に、
可能だと思っていた未来が、
実現困難になることもある。
だから、
Potential Spaceは固定された地図ではない。
Realityとともに更新され続ける未来の選択空間
である。
⸻
この考え方は、
未来を早めるうえでも重要である。
十年後まで待たなければ実現できないと思っていたものが、
新しいTechnologyによって、
三年で可能になるかもしれない。
制度変更によって、
一年で始められるかもしれない。
既存のTechnologyを組み合わせれば、
すでに実装できるかもしれない。
Potential Spaceを継続的に見直すことで、
未来実装時間そのものを更新できる。
⸻
日本に必要なのは、
未来を一つ決め、
全員がそこへ進むことだけではない。
多くの可能性を保持する。
小さく試す。
比較する。
学習する。
有効なものを拡大する。
そして、
新しい可能性が生まれれば、
再び探索する。
この能力を持つことで、
社会は未来の変化に対応できる。
⸻
未来は、
一本の線の先にあるのではない。
現在の周囲には、
まだRealityになっていない複数の可能性が広がっている。
その空間を認識する。
制約を知る。
選択肢を増やす。
Future Stateを選ぶ。
そして、
実装する。
未来を設計する最初の仕事は、未来を決めることではない。
まず、
どのような未来が存在し得るのかを見ること
である。
その広がりが、
Potential Spaceなのである。
第3節 Future State
Potential Spaceには、複数の未来が存在する。
しかし、可能性を広げるだけでは、未来は実装されない。
どの方向へ進むのか。
何を実現するのか。
どの状態を目指すのか。
それを定める必要がある。
本書では、
実現を目指す未来の状態
をFuture Stateと呼ぶ。
⸻
Future Stateは、単なる目標ではない。
たとえば、
「AI先進国になる」
「地方を活性化する」
「医療を改革する」
「経済を成長させる」
という言葉だけでは、Future Stateとしては十分ではない。
何が変われば、実現したと言えるのか。
誰の生活がどう変わるのか。
どの制度が動いているのか。
どのTechnologyが使われているのか。
どの主体が何を担っているのか。
そこまで記述されて初めて、
未来を現在へ引くことができる。
⸻
たとえば、
「医療のDigital化」を目標にする。
これだけでは、
何を実装すべきか決まらない。
Future Stateとして記述するなら、
患者が自分の医療情報へ安全にアクセスできる。
医療機関間で必要な情報が適切に共有される。
医師はAIによる診療支援を利用できる。
日常の健康Dataが、本人の同意のもとで予防へ活用される。
研究や創薬にも、適切な形でDataが利用される。
こうして、
未来の状態を具体化する。
すると、
現在との違いが見えてくる。
⸻
行政でも同じである。
「行政DXを進める」
ではなく、
Future Stateを置く。
住民が同じ情報を何度も提出する必要がない。
多くの手続きがOnlineで完結する。
行政機関のDataが、法律とSecurityの範囲内で適切に連携される。
職員は定型業務ではなく、
複雑な相談や政策形成へ時間を使う。
AIを利用した場合には、
どのような判断が行われたのか確認できる。
この状態まで書けば、
必要なSystem、制度、人材、Dataが見えてくる。
⸻
つまり、
Future Stateには、
Requirementを引き出せるだけの具体性
が必要である。
しかし、
細部まで固定しすぎてもいけない。
十年後に使われている具体的なSoftwareやDeviceまで、
現在から決める必要はない。
Technologyは変化するからである。
重要なのは、
手段ではなく、
実現されている状態
を記述することである。
⸻
たとえば、
2035年の地域交通について、
特定企業の自動運転車を何台導入すると決める必要はない。
それよりも、
高齢者を含む住民が、
自家用車を運転できなくても、
病院、買物、行政Serviceへ必要な時間で移動できる。
という状態を置く。
その状態を実現する手段は、
自動運転かもしれない。
On-demand Busかもしれない。
Taxiとの統合かもしれない。
将来登場する別のTechnologyかもしれない。
Future Stateは、
目的を固定し、手段には選択余地を残す。
これが重要である。
⸻
Future Stateを置くもう一つの意味は、
複数主体の方向を合わせることにある。
たとえば、
医療の未来を考える場合、
政府。
病院。
大学。
製薬企業。
医療機器企業。
AI企業。
保険者。
自治体。
患者。
それぞれが別の目的を持っている。
すべてを一つの組織へ統合することはできない。
しかし、
共有できるFuture Stateは置ける。
たとえば、
必要な人が、必要な医療へ、安全かつ持続可能な形でアクセスできる状態
である。
この状態を共有すれば、
それぞれの主体が、
自分の役割から必要な行動を考えられる。
⸻
したがって、
Future Stateは、
中央から配られる命令ではない。
複数主体が協働するための共通参照点
である。
政府は制度を見る。
企業はTechnologyと事業を見る。
大学は研究を見る。
金融は資本を見る。
地域は生活を見る。
それぞれの視点を保持したまま、
同じ未来状態を参照する。
これによって、
異なる主体の時間を接続できる。
⸻
Future Stateには、
時間軸も必要である。
2030年。
2035年。
2040年。
2050年。
しかし、
日付だけを置くのではない。
遠いFuture Stateと、
近いFuture Stateを接続する。
たとえば、
2050年のEnergy Systemを考える。
そこから、
2040年には何が必要か。
2035年には。
2030年には。
そして、
今年何を始める必要があるのか。
未来の状態を段階化する。
すると、
長期Visionが現在の行動へつながる。
⸻
このとき、
すべてを一度に完成させる必要はない。
Future Stateの一部を、
先に実装することができる。
一自治体。
一病院。
一大学。
一企業。
一地域。
小さな範囲で、
未来状態を先行してつくる。
そこで機能すれば、
別の場所へ展開する。
つまり、
Future Stateは、
遠い未来の完成図であると同時に、
現在に小さく実装できるPrototype
にもなる。
⸻
そして、
Future Stateは固定しない。
これは非常に重要である。
未来には不確実性がある。
AIの性能が急速に向上するかもしれない。
Energy Technologyが変わるかもしれない。
人口推計が変化するかもしれない。
国際環境が変わるかもしれない。
社会の価値観も変わる。
だから、
Future Stateは、
一度決めたら変更できない国家目標ではない。
Realityを見ながら更新する。
⸻
実装する。
結果を見る。
問題を発見する。
新しいTechnologyを知る。
社会の反応を見る。
そして、
Future Stateを修正する。
Future State
→ Implementation
→ Reality
→ Review
→ Updated Future State
この循環を繰り返す。
Future Stateは、
未来を固定するためではなく、
未来へ向かって学習するために存在する。
⸻
さらに、
Future Stateは一つである必要もない。
人口。
経済。
医療。
Energy。
Security。
文化。
環境。
それぞれについて、
複数Scenarioを持つことができる。
経済成長が高い場合。
低い場合。
Technologyが急速に進歩する場合。
国際環境が不安定になる場合。
複数の未来を想定する。
そして、
どのScenarioでも必要になる条件を見つける。
たとえば、
Cybersecurity。
人材育成。
Energy Security。
Data Infrastructure。
医療体制。
こうしたものは、
複数Scenarioに共通して必要になる可能性が高い。
それなら、
早く投資する合理性がある。
⸻
この考え方によって、
Future Stateは予測と対立しなくなる。
Forecastを使って、
起こり得る環境を知る。
Potential Spaceから、
可能な選択肢を見る。
その中から、
実現を目指すFuture Stateを置く。
そして、
複数Scenarioに耐えられるArchitectureを設計する。
つまり、
Forecastは未来を読む。
Future Stateは未来を選ぶ。
両方が必要なのである。
⸻
日本全体についても、
Future Stateを一つの標語にする必要はない。
重要なのは、
社会の各領域で、
具体的な未来状態を記述することである。
政治。
行政。
金融。
産業。
Healthcare。
教育。
Energy。
Infrastructure。
文化。
地域。
それぞれについて、
「何をするか」ではなく、
「どの状態を実現するか」
を書く。
⸻
政策では、
しばしば手段が目的化する。
AIを導入する。
補助金を出す。
施設を建てる。
法律を改正する。
しかし、
これらはすべて手段である。
Future Stateから考えれば、
問いは変わる。
そのAIによって、
何が改善したのか。
補助金によって、
どの産業能力が生まれたのか。
施設によって、
誰の生活がどう変わったのか。
法改正によって、
どの未来が可能になったのか。
手段ではなく状態を評価する。
これがFuture Stateの重要な役割である。
⸻
そして、
Future Stateを置くことで、
現在の価値も変わる。
未来に必要なTechnologyが、
すでに日本企業にあるかもしれない。
必要な研究が、
大学で進んでいるかもしれない。
必要な人材が、
別の産業にいるかもしれない。
必要な地域モデルが、
一つの自治体ですでに実施されているかもしれない。
未来から現在を見ることで、
現在に埋もれていた資源が見つかる。
Future Stateは、
未来を示すだけではない。
現在のPotentialを発見するための観測点
にもなる。
⸻
だから、
Future Stateを置くことは、
未来を決めつけることではない。
未来へ向かうための、
暫定的な座標を置くことである。
そこから現在を見る。
Gapを見る。
Requirementを見る。
実装する。
Realityから学ぶ。
必要なら座標を動かす。
この柔軟性が、
不確実な未来には必要になる。
⸻
Potential Spaceには、
多くの未来が存在する。
しかし、
すべてを同時に実現することはできない。
資本も、
人材も、
時間も有限である。
だから、
社会は選択しなければならない。
何を守るのか。
何を変えるのか。
何へ投資するのか。
何を先に実装するのか。
Future Stateとは、
その選択を可能にするための未来側の基準である。
⸻
未来を現在へ引くには、
まず、
引くべき未来を記述しなければならない。
ただし、
未来を細部まで固定しない。
実現したい状態を明確にし、
そこへ至る手段には選択可能性を残す。
Potential SpaceからFuture Stateを選ぶ。
そして次に、
その未来から、
現在へ必要条件を引く。
ここから、
Future Pullは、
構想から実装へ移り始める。
第4節 未来からRequirementを引く
Future Stateを置くと、次の問いが生まれる。
その未来を実現するために、何が必要なのか。
ここで未来は、理念から実装課題へ変わる。
Future Stateを構成する条件を一つずつ現在へ引き戻す。
本書では、その条件を、
Requirement
と呼ぶ。
⸻
たとえば、
2035年の医療について、
「住む場所にかかわらず、必要な医療へ継続的にアクセスできる状態」
をFuture Stateとして置く。
この未来を実現するには何が必要か。
医療人材。
病院と診療所。
救急体制。
遠隔医療。
医療Data。
通信Infrastructure。
AIによる支援。
医薬品供給。
在宅医療。
診療報酬。
地域交通。
一つのFuture Stateから、
複数のRequirementが現れる。
⸻
ここで重要なのは、
現在できることから未来を考えるのではなく、
未来に必要なものから現在を見ること
である。
現在の予算。
現在の組織。
現在の制度。
現在のTechnology。
これらだけを起点にすると、
未来も現在の延長になりやすい。
Future Pullでは、
先にFuture Stateを置く。
その未来に必要なら、
現在存在しない制度もRequirementになる。
現在不足している人材も。
まだ整備されていないDataも。
研究段階のTechnologyも。
未来側から見ることで、
現在の制約に隠れていた課題が見える。
⸻
Requirementは、
単なる要望ではない。
「AIをもっと使うべきだ」
「研究投資を増やすべきだ」
「地方を活性化すべきだ」
という表現だけでは、
実装へ移れない。
誰が必要なのか。
何が必要なのか。
どの水準まで必要なのか。
いつ必要なのか。
何に依存しているのか。
そこまで分解する。
Future Stateを実装可能な条件へ翻訳する。
これがRequirementを引くということである。
⸻
行政を例にすると分かりやすい。
Future Stateとして、
「多くの行政手続きが、住民にとって簡単で、行政内部でも重複なく処理される状態」
を置く。
そこから、
本人確認。
共通Data。
System間連携。
行政手続きの標準化。
Cybersecurity。
AI利用基準。
職員Training。
法的責任。
住民Support。
といったRequirementが導かれる。
すると、
「行政DX」という大きな言葉が、
具体的な実装課題へ変わる。
⸻
さらに、
Requirementには順序がある。
すべてを同時に実行できるとは限らない。
Dataが整理されていなければ、
高度なAIを導入しても十分に機能しない。
電力網が整っていなければ、
新しいEnergy設備を大量に導入してもSystem全体が安定しない。
専門人材がいなければ、
Technologyを購入しても運用できない。
つまり、
Requirement同士には、
Dependency
が存在する。
⸻
未来実装時間を短縮するうえで、
このDependencyは極めて重要である。
何を最初に始めるべきか。
何を並行できるか。
何が完了するまで待つ必要があるか。
それを整理する。
たとえば、
十年かかる人材育成は、
早く始めなければならない。
二年で整備できる制度は、
必要な時期から逆算できる。
数か月で開発できるSoftwareは、
前提条件が整ってからでも間に合うかもしれない。
未来からRequirementを引くことで、
現在のPriorityが決まる。
⸻
この考え方は、
予算編成にも影響する。
通常、
予算は現在の組織や事業を基準に編成される。
しかしFuture Stateから見ると、
現在の組織区分と、
未来のRequirementが一致しないことがある。
HealthcareとAI。
MobilityとEnergy。
大学と産業。
文化と観光。
防災とDigital Infrastructure。
未来の課題は、
複数の省庁や産業を横断する。
したがって、
Requirementから考えると、
縦割りでは見えにくかった接続が見えてくる。
⸻
Financeでも同じである。
未来の産業を実現するには、
どの段階で、
どの種類の資本が必要なのかを見る。
基礎研究には研究資金。
StartupにはRisk Capital。
工場建設には長期融資。
Infrastructureには長期投資。
事業拡大には市場からの資金調達。
すべてを「資金不足」とまとめない。
Future Stateから逆算して、
必要な資本の種類と時期
を特定する。
すると、
金融も未来実装Architectureの一部になる。
⸻
Requirementを引くときには、
Technologyだけを見ないことも重要である。
新しいTechnologyが社会で機能するためには、
制度。
人材。
業務。
Data。
Finance。
Infrastructure。
利用者。
安全性。
文化。
が関係する。
Technologyが完成していても、
他のRequirementが不足していれば、
Realityにはならない。
未来を早めるためには、
最も進んだTechnologyを見るだけではなく、
最も遅れている必要条件を見る必要がある。
⸻
これは、
いわゆるBottleneckを見つけることでもある。
十個のRequirementのうち、
九個が完成していても、
最後の一個がなければ実装できない場合がある。
医療Technologyはある。
医師もいる。
病院もある。
しかし、
必要なDataを共有できない。
それだけで、
新しいServiceが成立しないことがある。
その場合、
未来を早めるために必要なのは、
さらに高性能なTechnologyではない。
Data連携である。
未来実装速度は、最も遅いRequirementによって決まることがある。
⸻
だから、
Future Pullでは、
新しいものを増やす前に、
何がBottleneckなのかを見る。
Technologyなのか。
制度なのか。
人材なのか。
資本なのか。
Dataなのか。
社会的合意なのか。
主体間調整なのか。
ここを正しく特定できれば、
限られた資源を、
未来実装時間を最も短縮できる場所へ投入できる。
⸻
Requirementには、
もう一つ重要な分類がある。
共通Requirement
である。
複数の未来に共通して必要になる条件がある。
たとえば、
安全なDigital Identity。
高品質なData Infrastructure。
Cybersecurity。
AI人材。
研究基盤。
安定したEnergy。
高度な通信Infrastructure。
こうした基盤は、
一つの産業だけに使われるものではない。
行政。
医療。
金融。
産業。
教育。
複数領域で利用される。
ならば、
個別Projectごとにつくるより、
共通基盤として整備したほうが、
社会全体の未来実装時間を短縮できる。
⸻
ここから、
Architectureという考え方が必要になる。
未来ごとに個別のProjectをつくるだけでは、
同じRequirementが何度も現れる。
共通するものは共有する。
領域固有のものは分ける。
中央で持つもの。
地域で持つもの。
民間が持つもの。
公共が持つもの。
それらを整理する。
未来からRequirementを引くことは、
やがて、
日本全体のArchitectureを発見すること
につながる。
⸻
ただし、
Requirementは固定ではない。
Realityが変われば、
必要条件も変わる。
新しいTechnologyによって、
以前必要だったInfrastructureが不要になるかもしれない。
制度改正によって、
新しい事業モデルが可能になるかもしれない。
AIによって、
必要人員が変わるかもしれない。
だから、
Requirementも継続的に更新する。
⸻
Future Stateを置く。
Requirementを引く。
実装する。
Realityを見る。
そして、
Requirementを修正する。
Future State
→ Requirement
→ Implementation
→ Reality
→ Updated Requirement
未来設計は、
一度完成させる設計図ではない。
実装によって学習する設計である。
⸻
ここで、
Future Pullの時間方向がはっきりする。
通常は、
現在の資源を確認し、
できることを考え、
未来目標を設定する。
Future Pullでは、
逆から始める。
Future State
↓
Requirement
↓
Current State
↓
Gap
↓
Priority
↓
Implementation
未来が、
現在の行動順序を決める。
⸻
この方法を使えば、
2050年という遠い未来も、
現在の行動へ接続できる。
2050年に必要な人材がいる。
ならば、
教育は現在から始める。
2040年に必要なInfrastructureがある。
ならば、
建設期間から逆算する。
2035年に必要な制度がある。
ならば、
制度設計と実証を先に始める。
2030年に必要なTechnologyが、
すでに存在している。
ならば、
現在から実装できる可能性を調べる。
こうして、
未来の日付から、
現在の開始日を引く。
⸻
ここに、
未来実装時間を短縮する核心がある。
未来を早めるために、
すべてを急ぐ必要はない。
未来から必要条件を正確に引けばよい。
時間のかかるものを早く始める。
並行できるものは並行する。
Bottleneckを先に解く。
共通基盤を整える。
すでに存在するものは再利用する。
そして、
実装可能なものからRealityへ変える。
⸻
未来は、
大きなVisionだけでは現在へ来ない。
Visionを、
Requirementへ変換しなければならない。
何が必要か。
誰が担うか。
何に依存するか。
いつ始めるか。
どこまで実装するか。
そこまで引いたとき、
未来は初めて、
現在の仕事になる。
Future StateからRequirementを引く。
それは、
未来を語る段階から、
未来を実装する段階へ移る、
最初の具体的な操作なのである。
第5節 未来を現在へ翻訳する
Future Stateを置く。
そこからRequirementを引く。
しかし、それだけでは未来は動かない。
Requirementを、
現在の制度、組織、予算、Technology、人材、事業へ変換しなければならない。
未来の言葉を、
現在が実行できる言葉へ置き換える。
これを、本書では、
未来を現在へ翻訳する
と呼ぶ。
⸻
たとえば、
「誰もが必要な医療へ継続的にアクセスできる社会」
というFuture Stateがある。
そこから、
遠隔医療。
医療Data連携。
医療人材。
AI支援。
在宅医療。
地域交通。
医薬品供給。
といったRequirementが導かれる。
しかし、
現場が必要とするのは、
さらに具体的な問いである。
どの病院で始めるのか。
どの自治体が参加するのか。
誰がSystemを開発するのか。
どのDataを接続するのか。
どの法律を確認するのか。
予算はいくら必要なのか。
誰が責任を持つのか。
いつ実証を開始するのか。
ここまで降ろして、
初めて未来は現在のProjectになる。
⸻
つまり、
未来から現在への翻訳には、
段階がある。
Future State
→ Requirement
→ Program
→ Project
→ Action
未来の状態を、
必要条件へ変える。
必要条件を、
政策や事業へ変える。
政策や事業を、
具体的なProjectへ変える。
Projectを、
今日実行できるActionへ変える。
この変換が途切れると、
未来はVisionのまま残る。
⸻
国家政策では、
この断絶が起こりやすい。
「Digital社会を実現する」
「Green Transformationを進める」
「地方創生を実現する」
「科学技術立国を再構築する」
方向としては正しくても、
それだけでは現場は動けない。
誰が。
何を。
いつまでに。
どの予算で。
どの制度のもとで。
どの指標を使って。
どこまで実装するのか。
未来の言葉を、
行政が実行できる単位まで翻訳する必要がある。
⸻
企業でも同じである。
「AI企業になる」
という経営方針だけでは、
現場は変わらない。
どの業務へAIを導入するのか。
どのDataを使うのか。
どのSystemと接続するのか。
誰をTrainingするのか。
何を内製し、
何を外部企業へ委託するのか。
どの指標で効果を測るのか。
ここまで翻訳されることで、
経営Visionが、
投資判断と業務変更へ変わる。
⸻
翻訳には、
主体ごとの言語も必要になる。
政府は、
政策、法律、予算で考える。
企業は、
事業、顧客、投資、収益で考える。
金融は、
Risk、Return、信用、資本で考える。
大学は、
研究、教育、論文、人材で考える。
医療は、
安全性、有効性、患者、診療で考える。
自治体は、
住民、地域、公共Service、財政で考える。
同じ未来でも、
主体によって実行言語は異なる。
⸻
たとえば、
「地域Healthcareを持続可能にする」
というFuture Stateを共有していても、
政府には、
制度設計というRequirementになる。
自治体には、
地域医療計画になる。
病院には、
診療体制の再設計になる。
大学には、
医療人材育成になる。
Technology企業には、
医療支援Systemの開発になる。
金融には、
設備や事業への資金供給になる。
一つの未来が、
複数の現在言語へ翻訳される。
⸻
ここで重要なのは、
全員に同じ仕事をさせないことである。
Future Stateは共有する。
しかし、
役割は分ける。
政府がTechnologyをすべて開発する必要はない。
企業が法律をつくることもできない。
大学が金融市場を運営する必要もない。
それぞれが、
自分の機能を使って未来へ参加する。
つまり、
未来を現在へ翻訳するとは、
Future Stateを主体ごとのRoleへ分解すること
でもある。
⸻
さらに、
時間への翻訳が必要になる。
2050年のFuture Stateを、
2050年まで待って実行することはできない。
2050年から逆算する。
2040年には、
何が成立している必要があるのか。
2035年には。
2030年には。
そして、
2026年には何を始めるのか。
未来を、
Milestoneへ変換する。
すると、
遠い未来が、
現在のScheduleへ変わる。
⸻
ここで、
未来実装時間という考え方が効いてくる。
Requirementごとに、
必要時間が違う。
基礎研究には長い時間がかかる。
人材育成にも時間がかかる。
Infrastructure整備にも時間が必要である。
一方、
Software導入や小規模実証なら、
短期間で始められることがある。
だから、
未来を現在へ翻訳するとき、
すべてを同じ開始日にする必要はない。
必要時間から逆算して開始日を決める。
⸻
空間への翻訳も必要である。
全国で一斉に実装するのか。
特定地域から始めるのか。
一つの病院なのか。
一つの大学なのか。
一つの企業なのか。
未来は、
最初から国家Scaleで実装しなくてもよい。
小さなScaleで、
Future Stateの一部を先行実装する。
そして、
Realityを見る。
この方法によって、
未来を現在へ安全に移すことができる。
⸻
また、
未来を現在へ翻訳するときには、
現在の制度を無視してはいけない。
理想的には制度変更が必要でも、
現行制度の範囲内で始められることがある。
まず、
現在の法律で何ができるかを見る。
既存予算で何ができるか。
既存組織で何ができるか。
既存Technologyで何ができるか。
それでも足りない部分だけを、
制度改革や新規投資へ回す。
これは、
未来実装時間を短縮するうえで重要である。
⸻
すべてを新しくつくる必要はない。
すでにあるものを使う。
既存の行政System。
既存の病院。
既存の大学。
既存の企業。
既存の金融機関。
既存のInfrastructure。
既存の文化施設。
それらを再接続する。
未来を現在へ翻訳するとは、
新しい世界をゼロから建設することではなく、
現在のRealityを未来に使える形へ組み替えること
でもある。
⸻
ここで、
「できない理由」も翻訳対象になる。
法律上できない。
予算がない。
人材がいない。
Dataがない。
責任主体が決まらない。
社会的合意がない。
これらを、
単なる障害として終わらせない。
法律上できないなら、
どの条文や制度が問題なのか。
予算がないなら、
必要額と資金源は何か。
人材がいないなら、
何人、どの能力が必要なのか。
Dataがないなら、
何を収集すべきなのか。
具体化する。
ConstraintをRequirementへ再翻訳する。
すると、
「できない」が、
「何を変えればできるか」
へ変わる。
⸻
これは、
未来を早めるうえで大きな違いを生む。
曖昧な障害は、
長期間残る。
具体化された障害は、
担当者を決められる。
予算を付けられる。
期限を設定できる。
検証できる。
つまり、
翻訳とは、
未来を理解しやすくするためだけの作業ではない。
未来を実行可能にするための作業
なのである。
⸻
さらに、
翻訳は一方向ではない。
未来から現在へ翻訳する。
現在で実装する。
すると、
Realityから新しい情報が返ってくる。
想定より費用が高い。
利用者が使わない。
別のTechnologyのほうが良い。
制度変更が不要だった。
新しいRiskが見つかった。
こうした情報を、
再びFuture Stateへ返す。
Future
→ Translation
→ Implementation
→ Reality
→ Feedback
→ Future
翻訳は、
この往復の中で更新される。
⸻
ここで、
未来設計と未来実装がつながる。
未来設計だけなら、
Future Stateを描くところで終わる。
未来実装だけなら、
現在の課題を一つずつ処理することになる。
Future Pullは、
その二つを接続する。
未来から方向を引き、
現在からRealityを返す。
この循環によって、
未来は空想にならず、
現在も単なる問題処理にならない。
⸻
日本全体について考えると、
翻訳層は極めて重要になる。
研究成果を産業へ翻訳する。
Technologyを制度へ翻訳する。
社会課題を市場へ翻訳する。
地域の成功を全国政策へ翻訳する。
世界のTechnologyを日本社会へ翻訳する。
日本の文化やTechnologyを世界へ翻訳する。
未来実装速度は、
この翻訳能力によって大きく変わる。
⸻
未来が見えていないから、
実装が遅いとは限らない。
未来像は、
すでに多く存在している。
Technologyもある。
研究もある。
資本もある。
人材もいる。
それでも未来がRealityにならないとすれば、
その間に、
翻訳の断絶
が存在している可能性がある。
⸻
だから、
未来を現在へ引くために必要なのは、
さらに大きなVisionだけではない。
未来を、
現在の制度へ。
予算へ。
事業へ。
研究へ。
人材育成へ。
地域へ。
Projectへ。
そして、
今日のActionへ。
一段ずつ翻訳することである。
未来は、
理解されたときではなく、
現在の誰かが実行できる形になったとき、初めて現在へ入る。
Future StateをRequirementへ。
RequirementをProjectへ。
ProjectをActionへ。
その翻訳によって、
未来は遠い時間の先から、
現在のRealityへ移り始めるのである。
第6節 Future Pull
ここまで、
未来がどこに存在するのかを見た。
Potential Spaceを見た。
Future Stateを置いた。
そこからRequirementを引いた。
そして、
未来を現在が実行できる言葉へ翻訳した。
これらを一つの動作としてまとめたものが、
Future Pull
である。
Future Pullとは、
未来を予測して待つのではなく、
実現したい未来の状態から、必要な条件と行動を現在へ引き戻す方法
である。
⸻
従来の未来計画は、
現在から未来へ進む。
現在の人口。
現在の財政。
現在のTechnology。
現在の産業。
そこから、
何年後に何が可能になるかを考える。
Future Pullでは、
逆方向も使う。
まず、
Future Stateを置く。
その状態から、
現在へ問いを返す。
何が必要か。
何が足りないか。
何がすでにあるか。
誰が動く必要があるか。
どこから始められるか。
つまり、
Present → Future
だけでなく、
Future → Present
を加える。
⸻
この二つの方向は、
対立しない。
現在から未来を見ることで、
制約がわかる。
未来から現在を見ることで、
必要条件がわかる。
両方を重ねると、
未来設計が現実的になる。
Current Reality
→ Forecast
と、
Future State
→ Requirement
を接続する。
その間にある差が、
実装課題になる。
⸻
たとえば、
人口減少地域の未来を考える。
現在から予測すれば、
人口。
税収。
医療人材。
公共交通。
商業。
などの縮小が見える。
Future Pullでは、
その予測を否定しない。
その条件の中で、
「住民が必要な生活Serviceへ継続してアクセスできる状態」
をFuture Stateとして置く。
すると、
遠隔医療。
On-demand交通。
行政Digital化。
物流再編。
地域拠点。
人材共有。
といったRequirementが現れる。
人口予測は変わらなくても、
社会のFuture Stateは変えられる。
これが、
Future Pullである。
⸻
つまり、
Future Pullは、
未来を楽観的に見る方法ではない。
むしろ、
Current Realityを正面から受け入れる。
人口減少。
財政制約。
人材不足。
国際競争。
Energy。
災害Risk。
これらを無視しない。
そのうえで、
その条件の中で、どの未来まで実装可能なのか
を問う。
未来を現実から逃がさない。
同時に、
現在を過去の延長へ固定しない。
ここに、
Future Pullの基本姿勢がある。
⸻
Future Pullの第一の機能は、
未来を具体化すること
である。
「豊かな日本」
「強い経済」
「安心できる社会」
という言葉だけでは、
実装できない。
何が成立している状態なのかを書く。
Future Stateを明確にする。
すると、
未来は抽象的なVisionから、
検証可能な状態へ変わる。
⸻
第二の機能は、
不足をRequirementへ変えること
である。
人材が足りない。
Dataがつながっていない。
投資が不足している。
制度が対応していない。
これらを、
単なる問題として残さない。
何人必要か。
どのDataが必要か。
どの資本が必要か。
どの制度を変更する必要があるか。
具体的な条件へ変える。
問題が、
実装項目になる。
⸻
第三の機能は、
現在にすでにあるものを発見すること
である。
未来から見ると、
現在の資産の意味が変わる。
ある大学の研究。
ある企業のTechnology。
ある自治体の実証。
ある病院のData。
ある地域の文化資源。
それまで個別に存在していたものが、
未来のRequirementとして見えてくる。
Future Pullは、
未来にないものを探すだけではない。
現在に埋もれている未来資源を見つける。
⸻
第四の機能は、
時間を逆算すること
である。
十年かかるものは、
今始める。
三年かかるものは、
必要時期から逆算する。
短期間で実装できるものは、
先にPrototypeする。
Requirementごとに時間を分けることで、
遠い未来を、
現在のScheduleへ変換する。
ここで、
Future Pullは、
未来実装時間を短縮する方法になる。
⸻
第五の機能は、
複数主体を接続すること
である。
未来の医療を、
厚生行政だけで実現することはできない。
病院。
大学。
製薬。
Technology企業。
金融。
自治体。
患者。
複数主体が必要になる。
Future Stateを共通参照点にすれば、
それぞれの役割を整理できる。
政府には制度。
大学には研究。
企業には事業。
金融には資本。
地域には実証。
Future Pullは、
異なる組織を一つに統合するのではなく、
一つの未来へ向けて接続する。
⸻
第六の機能は、
Bottleneckを発見すること
である。
未来に必要な条件をすべて並べると、
何が最も遅れているかが見える。
Technologyはある。
資本もある。
しかし制度がない。
ならば、
制度がBottleneckである。
制度もTechnologyもある。
しかし現場人材がいない。
ならば、
Trainingが重要になる。
未来を早めるために、
すべてを同じ割合で強化する必要はない。
最も大きなBottleneckを解けば、
実装全体が進むことがある。
⸻
そして第七の機能が、
学習である。
Future Pullは、
未来を一度決めて終わる方法ではない。
Future Stateを置く。
現在へ引く。
実装する。
Realityを見る。
うまくいかなければ修正する。
新しいTechnologyが現れれば、
Future StateもRequirementも更新する。
つまり、
Future Pullは、
継続的なBackcastingと実装の循環
である。
⸻
最小に書けば、
Future Pullは、
次の流れになる。
Potential Space
→ Future State
→ Requirement
→ Current State
→ Gap
→ Priority
→ Implementation
→ Verification
そして、
Verificationの結果を、
再びFuture Stateへ返す。
この循環が回る。
⸻
ここで、
一つ重要な区別が必要になる。
Future Pullは、
未来から現在へ「答え」を持ってくる方法ではない。
未来はまだ存在していない。
だから、
絶対的な正解を持っていない。
Future Stateは、
現在の意思決定を助けるための仮説である。
Realityで検証し、
必要なら変更する。
つまり、
Future Pullは、
未来による現在の支配ではない。
未来を使った現在の意思決定方法
なのである。
⸻
これは、
国家計画にとって特に重要である。
国家は、
一度決めた未来像を、
何十年も固定することがある。
しかし、
Technologyや国際環境が急速に変化する時代では、
固定した長期計画だけでは対応できない。
長期方向は持つ。
しかし、
実装経路は更新する。
Future Stateも、
必要に応じて見直す。
長期性と柔軟性を両立する。
Future Pullは、
そのための方法になる。
⸻
また、
Future Pullは、
中央集権的な未来設計を必要としない。
国家全体のFuture Stateがある。
同時に、
企業のFuture State。
地域のFuture State。
大学のFuture State。
医療機関のFuture State。
一人の人間のFuture State。
複数の未来が存在する。
それぞれが、
自分のScaleでRequirementを引く。
そして、
必要な場所で接続する。
つまり、
Future Pullは、
分散して実行できる。
⸻
たとえば、
一つの自治体が、
十年後の地域交通を描く。
Future StateからRequirementを引く。
自動運転。
道路。
通信。
高齢者支援。
Finance。
法律。
現在できることから実証する。
その成果を国へ返す。
別の地域が利用する。
Future Pullは、
国家の大計画からだけではなく、
地域の小さな実装からも動く。
⸻
企業も同じである。
未来市場を見る。
必要なTechnologyを逆算する。
研究開発を始める。
大学と連携する。
人材を育てる。
設備投資する。
つまり、
企業経営そのものがFuture Pullになり得る。
大学も。
医療も。
文化も。
それぞれが、
未来から現在へ時間軸を引くことができる。
⸻
だから、
本書でFuture Pullを一つの専門的なPlanning手法としてだけ扱わない。
より広く、
日本社会の異なる主体が未来を現在へ接続する共通方法
として扱う。
政府には政策言語で。
金融には資本配分として。
企業には経営戦略として。
大学には研究計画として。
医療にはClinical・Healthcare Designとして。
文化には創造と継承として。
同じ構造を、
現在の言葉へ翻訳する。
⸻
ここに、
本書で可能な限り既存の制度や産業の言葉を使う理由もある。
新しい概念を理解するために、
長い翻訳期間を置く必要はない。
Future Pullという一つの方向だけ共有すればよい。
未来の状態を置く。
必要条件を引く。
現在から始める。
この構造なら、
現在の政府。
企業。
病院。
大学。
地域。
が、
それぞれの既存の仕組みの中から動き始められる。
⸻
Future Pullの目的は、
未来を壮大に描くことではない。
未来を現在の仕事へ変えること
である。
2035年の未来を、
今年の政策へ。
2040年の産業を、
今年の研究開発へ。
2050年の社会を、
今日の教育へ。
遠い未来から、
現在の開始点を引く。
⸻
そして、
一つ実装する。
Realityが変わる。
すると、
未来までの距離が短くなる。
さらに、
新しい可能性が見える。
そこから、
またFuture Stateを更新する。
つまり、
Future Pullには終点がない。
未来を一度現在へ引けば終わるのではなく、
現在が変わるたびに、未来をもう一度引き直す。
この循環によって、
社会は未来を待つだけではなくなる。
未来を見て、
現在から動く。
Realityから学び、
また未来を見る。
それが、
Future Pullなのである。
第7節 未来は現在へ近づく
未来は、時間が経過すれば自動的に現在になる。
しかし、
実現したい未来が、自動的に実現するわけではない。
Technologyが存在していても、
制度が整わなければ社会には入らない。
研究成果があっても、
事業化されなければ生活は変わらない。
資本があっても、
未来へ配分されなければ新しい産業は生まれない。
未来と現在の間には、
時間だけでは説明できない距離がある。
Future Pullが短縮するのは、
この距離である。
⸻
第1章では、
未来を一つの到達日としてではなく、
現在の中に存在する可能性から考えてきた。
現在には、
Technologyがある。
Knowledgeがある。
資本がある。
人材がある。
制度がある。
Infrastructureがある。
地域がある。
文化がある。
それらの組み合わせによって、
複数の未来が成立し得る。
その広がりが、
Potential Spaceである。
⸻
しかし、
可能性が存在するだけでは足りない。
そこで、
Potential Spaceの中にFuture Stateを置いた。
どのような状態を実現するのか。
何を守るのか。
何を変えるのか。
誰の生活をどう変えるのか。
Future Stateによって、
未来に方向が生まれる。
そして、
その未来からRequirementを引く。
⸻
未来に必要なTechnology。
制度。
人材。
資本。
Data。
Infrastructure。
社会的合意。
それらを現在へ並べる。
すると、
未来は遠いVisionではなく、
不足している条件の集合
として見えるようになる。
ここで初めて、
未来までの距離を具体的に扱える。
⸻
たとえば、
あるFuture Stateまで、
十個のRequirementが必要だとする。
そのうち八個がすでに存在しているなら、
未来は想像していたほど遠くない。
残り二個を実装すればよい。
逆に、
Technologyだけが完成していても、
制度、人材、資本、Infrastructureが不足しているなら、
その未来はまだ遠い。
未来までの距離は、
暦の年数ではなく、
未実装のRequirementによって測ることができる。
⸻
この見方をすると、
「2035年のTechnology」が、
2028年に実装されることもあり得る。
反対に、
すでに利用可能なTechnologyが、
2040年になっても社会へ広がらないこともある。
未来の日付と、
未来の実装時期は、
同じではない。
だから、
未来を早めるとは、
時計を速く進めることではない。
未来成立に必要な条件を、より早く揃えること
である。
⸻
そのためには、
すべてを急ぐ必要はない。
時間のかかるものを、
早く始める。
並行できるものを、
並行する。
Bottleneckを、
先に解く。
共通基盤を、
複数領域で共有する。
すでに存在するものを、
再利用する。
小さく試せるものは、
先に試す。
この積み重ねによって、
未来実装時間は短くなる。
⸻
特に重要なのは、
待ち時間を減らすこと
である。
研究が完成するまで、
制度設計を始めない。
制度が完成するまで、
実証を始めない。
全国統一の仕組みができるまで、
地域導入を始めない。
こうした直列的な進め方では、
時間が積み上がる。
しかし、
安全性を確保しながら並行できる工程は存在する。
研究しながら制度を検討する。
制度を検討しながら限定的に実証する。
実証しながら人材を育てる。
複数の時間を並行させる。
すると、
未来は現在へ近づく。
⸻
また、
全国で完成するまで、
未来と呼べないわけではない。
一つの病院で、
未来の医療を先行実装する。
一つの自治体で、
未来の行政Serviceを試す。
一つの大学で、
新しい教育を始める。
一つの工場で、
次世代Manufacturingを実装する。
小さな範囲であっても、
Future Stateの一部がRealityになれば、
未来はすでに現在へ入っている。
⸻
この先行実装には、
大きな意味がある。
抽象的だった未来が、
観測可能になる。
費用が分かる。
問題が分かる。
利用者の反応が分かる。
必要な制度が分かる。
Technologyの限界も分かる。
つまり、
未来について議論するだけでは得られなかった情報が、
Realityから返ってくる。
⸻
そして、
その情報によって、
次の実装が速くなる。
一つの地域の経験を、
別の地域が利用する。
一つの病院の失敗を、
別の病院が繰り返さない。
一つの企業が開発した基盤を、
別の企業が利用する。
一つの制度実証を、
国の制度改正へつなげる。
未来実装には、
学習による加速
が存在する。
⸻
ここで、
Future Pullは、
単なる逆算ではなくなる。
最初の未来から、
現在へRequirementを引く。
現在で実装する。
Realityから学ぶ。
その学習によって、
次の未来までの距離が短くなる。
Future
→ Present
→ Implementation
→ Learning
→ Next Future
この循環が動き始める。
⸻
日本全体でこの循環が成立すれば、
一つの中央計画ですべてを動かす必要はない。
政府が試す。
自治体が試す。
企業が試す。
大学が試す。
病院が試す。
地域が試す。
それぞれの結果を共有する。
成功したものを広げる。
失敗したものから学ぶ。
すると、
日本全体が、
多数の未来を同時に試すことができる。
⸻
ここで、
Future Pullは、
国家の速度そのものを変える可能性を持つ。
それは、
すべての組織を高速化するという意味ではない。
政府には政府の時間がある。
医療には医療の時間がある。
科学には科学の時間がある。
文化には文化の時間がある。
重要なのは、
それぞれを無理に速くすることではなく、
互いの時間を待たせないこと
である。
⸻
研究には十年かかる。
ならば、
十年前から始める。
制度変更には三年かかる。
ならば、
必要時期の三年前から始める。
Softwareは半年でつくれる。
ならば、
前提条件が整う時期へ合わせる。
未来から逆算すれば、
異なる時間を持つ主体を、
同じ完成時点へ接続できる。
⸻
この構造が、
次章で扱う、
時間を設計する
という考え方につながる。
未来を早めるには、
Technologyだけを速くしても足りない。
制度時間。
技術時間。
投資時間。
研究時間。
人材育成時間。
社会受容時間。
それらを、
一つの実装Architectureとして見る必要がある。
⸻
第1章で明らかになったのは、
未来が遠い理由は、
必ずしも未来そのものにあるのではない、
ということである。
必要なものが、
現在に分散している。
主体が接続されていない。
開始時期が遅い。
Dependencyが整理されていない。
Bottleneckが放置されている。
そのために、
未来が遠く見えている場合がある。
⸻
ならば、
未来を現在へ近づける方法は明確になる。
未来を具体化する。
Requirementを引く。
現在にあるものを確認する。
不足を特定する。
主体を接続する。
時間を逆算する。
小さく実装する。
Realityから学ぶ。
そして、
もう一度未来を引く。
⸻
未来は、
ある日突然やって来るものではない。
現在の中で、
一つずつ成立していく。
研究として。
制度として。
投資として。
製品として。
Serviceとして。
地域として。
生活として。
未来の一部がRealityになるたびに、
未来と現在の境界は移動する。
⸻
だから、
Future Pullの最終的な目的は、
未来を現在へ一度だけ引き寄せることではない。
未来と現在の距離を、継続的に短縮できる社会をつくること
である。
未来を見る。
現在へ引く。
実装する。
学習する。
そして、
次の未来を見る。
この循環が続くとき、
未来は遠くで待つものではなくなる。
未来は、現在の中から継続的にRealityへ変わり始める。
そしてその瞬間から、
未来は現在へ近づいているのである。
第2章 時間を設計する
第1節 線形時間とは何だったのか
私たちは通常、時間を一本の線として理解している。
過去 → 現在 → 未来
昨日があり、今日があり、明日が来る。
2026年の次に2027年があり、その先に2030年、2040年、2050年がある。
この時間認識は、社会を運営するうえで極めて重要である。
歴史を記録する。
契約期間を定める。
予算年度を設定する。
選挙を行う。
学校教育を組み立てる。
企業が事業計画をつくる。
Infrastructureの更新時期を決める。
現代社会の多くは、この線形時間によって動いている。
⸻
線形時間そのものに問題があるわけではない。
問題は、
未来まで線形にしか考えなくなること
である。
現在から一年進めば、一年後。
十年進めば、十年後。
その間に少しずつTechnologyが進歩し、制度が変わり、社会が変化する。
この考え方では、
未来は現在の延長線上に置かれる。
すると、未来への問いも、
「現在からどこまで進めるか」
になりやすい。
⸻
たとえば、
現在の医療制度を見る。
現在の病院数。
医師数。
医療費。
Technology。
診療報酬。
そこから、
五年後の医療を考える。
これは合理的である。
しかし、この方法だけでは、
現在の制度構造そのものが前提になりやすい。
病院とは現在のようなもの。
診療とは現在のようなもの。
患者と医療機関の関係も現在の延長。
そのうえで、
少しずつDigital化する。
少しずつAIを導入する。
未来が、
現在の改良版になる。
⸻
行政でも同じである。
現在の手続きをDigital化する。
現在の組織へAIを入れる。
現在の申請書をOnline化する。
もちろん必要な改善である。
しかし、
Future Stateから見れば、
そもそもその手続きが必要なのか、
という問いも生まれる。
住民がすでに行政へ提供している情報を、
なぜ再び提出する必要があるのか。
行政機関同士が適切にDataを共有できれば、
申請そのものを減らせないか。
未来から見ることで、
現在の仕組みを前提にしない問いが生まれる。
⸻
つまり、
線形時間には一つの特徴がある。
現在が未来の出発条件になる。
現在の制度。
現在の組織。
現在の産業。
現在の予算。
現在のTechnology。
そこから未来へ進む。
この方法は、
現実性が高い。
一方で、
現在の構造を未来まで持ち運びやすい。
⸻
特に、
大きなSystemではこの傾向が強くなる。
政府。
大企業。
大学。
病院。
金融機関。
Infrastructure。
長い歴史を持つ組織ほど、
既存の制度や資産を大量に抱えている。
だから、
未来を考えるときも、
現在の構造から出発する。
その結果、
未来計画が、
現在の延長として設計されやすくなる。
⸻
もう一つ、
線形時間には、
順番に進める
という感覚がある。
研究する。
その後に実証する。
その後に制度を考える。
その後に事業化する。
その後に全国展開する。
一つが終わってから、
次を始める。
この方法は分かりやすい。
しかし、
すべてを直列にすると、
時間は積み上がる。
三年。
二年。
二年。
三年。
それぞれ必要な時間が足され、
実装まで十年かかる。
⸻
しかし実際には、
並行できる工程がある。
研究をしながら、
制度上の論点を整理する。
Technologyを開発しながら、
利用者調査を行う。
実証しながら、
人材育成を始める。
設備計画を進めながら、
Financeを準備する。
未来実装では、
時間を単純に足す必要がない場合がある。
ここに、
時間設計の余地がある。
⸻
線形時間には、
もう一つ大きな特徴がある。
未来の日付が、
未来そのものに見えやすいことである。
2030年Vision。
2040年構想。
2050年目標。
日付を置くことで、
長期方向を共有できる。
これは重要である。
しかし、
2050年になれば、
2050年の社会が自動的に実現するわけではない。
準備を始めなければ、
日付だけが進む。
⸻
たとえば、
2050年に必要な人材を、
2049年から育成することはできない。
Infrastructureも同じである。
基礎研究も。
Energy Systemも。
都市も。
森林も。
社会保障制度も。
長い時間を必要とするものは、
未来の日付よりはるか前から動かさなければならない。
つまり、
重要なのは、
未来の日付ではなく、現在の開始時点
である。
⸻
ここで、
Future Pullが線形時間へ別の方向を加える。
通常は、
現在 → 未来
で考える。
Future Pullでは、
未来 → 現在
も使う。
2035年に何が必要か。
そこから、
2030年に必要な状態を引く。
さらに、
2028年。
2027年。
2026年。
と戻る。
すると、
未来の日付が、
現在の開始条件へ変わる。
⸻
これは、
時間を逆転させるという意味ではない。
現実の時間は、
これまで通り前へ進む。
過去から現在へ。
現在から未来へ。
変わるのは、
設計の方向
である。
実行は、
現在から未来へ進む。
設計は、
未来から現在へ戻る。
この二つを組み合わせる。
⸻
最小に書けば、
次のようになる。
設計
Future State
↓
Requirement
↓
Current Action
そして、
実行
Current Action
↓
Implementation
↓
Future Reality
未来から設計し、
現在から実行する。
これが、
本書の時間Architectureの基本になる。
⸻
この方法を使うと、
現在は単なる通過点ではなくなる。
未来と過去の間にある一点ではない。
現在は、
未来を変えることのできる実行点になる。
何を今日始めるかによって、
十年後の選択肢が変わる。
何へ投資するか。
何を研究するか。
誰を育てるか。
どの制度を試すか。
その選択によって、
Potential Spaceの中から、
異なる未来がRealityになる。
⸻
だから、
本書は線形時間を否定しない。
むしろ、
線形時間を実装に使う。
期限。
工程。
Milestone。
予算年度。
研究期間。
建設期間。
Training期間。
これらはすべて必要である。
ただし、
それらを現在から積み上げるだけではなく、
Future Stateから配置し直す。
⸻
さらに、
社会には一本の線形時間だけが存在するわけではない。
TechnologyにはTechnologyの時間がある。
制度には制度の時間がある。
金融には金融の時間がある。
産業には産業の時間がある。
医療には生命と安全の時間がある。
大学には研究と教育の時間がある。
文化にはさらに長い時間がある。
つまり、
社会とは、
異なる速度の線形時間が重なっている場所
でもある。
⸻
AIが数か月で進歩しても、
医療制度が数か月で全面変更されるわけではない。
金融市場が一日で変化しても、
Infrastructureは一日では変わらない。
政権が変わっても、
大学で人材を育てるには数年かかる。
Technologyの速度だけを基準にすると、
社会の他の時間とのずれが大きくなる。
だから、
未来実装には、
複数時間の調整が必要になる。
⸻
この意味で、
線形時間の問題は、
時間が直線であることではない。
一本の時間ですべてを説明しようとすること
にある。
社会には、
複数の時間がある。
それぞれを認識し、
必要なFuture Stateへ向けて配置する。
それが、
時間を設計するということである。
⸻
これまで、
未来は時間の先にあると考えてきた。
だから、
未来へ行くには、
時間が経過する必要があると思ってきた。
しかし、
実装という視点から見ると、
未来までの距離は、
年数だけでは決まらない。
必要条件。
開始時期。
Dependency。
Bottleneck。
並行実装。
それらによって変わる。
⸻
線形時間は、
文明を運営するための強力な仕組みであった。
過去を記録し、
現在を整理し、
未来を計画する。
その機能はこれからも必要である。
しかし、
未来実装を早めるには、
もう一本の設計線を加える必要がある。
過去 → 現在 → 未来
という実行時間に、
未来 → 現在
という設計方向を重ねる。
すると、
未来は単なる「後」ではなくなる。
未来は、
現在の行動を決めるための参照点になる。
線形時間を捨てるのではない。
線形時間を、未来から設計し直す。
そこから、
時間Architectureが始まるのである。
第2節 予測時間
未来を考えるために、
社会は予測を使う。
人口予測。
経済見通し。
物価見通し。
需要予測。
Technology予測。
医療需要。
Energy需要。
災害Risk。
予測は、
不確実な未来に備えるための重要な方法である。
本書では、
現在の情報から将来を見通すために使われる時間を、
予測時間
として考える。
⸻
予測時間の基本方向は、
現在から未来である。
現在のDataを集める。
過去の変化を見る。
Trendを推定する。
条件を設定する。
そして、
将来の状態を計算する。
Past Data
→ Current State
→ Forecast
この方法によって、
まだ起きていない未来を、
現在の意思決定へ取り込むことができる。
⸻
政府にとって、
予測時間は不可欠である。
将来人口が分からなければ、
社会保障制度を設計できない。
税収や歳出の見通しがなければ、
財政運営も難しい。
将来の電力需要が分からなければ、
Energy Infrastructureへの投資判断もできない。
予測は、
未来を当てるためだけではなく、
現在の準備を可能にするため
に使われている。
⸻
日本銀行にも、
予測時間がある。
物価。
賃金。
景気。
金融環境。
海外経済。
現在の指標だけではなく、
数か月後、数年後にどのような影響が現れるかを考えて政策を判断する。
金融政策には、
判断から効果が現れるまで時間差がある。
だから、
現在だけを見ていては遅い。
未来を先に見ながら、
現在の政策を決める必要がある。
⸻
企業も同じである。
需要が増えてから工場を建て始めたのでは、
市場へ間に合わないことがある。
将来需要を予測し、
設備投資する。
人材を採用する。
研究開発する。
在庫を調整する。
海外へ進出する。
つまり、
企業経営とは、
未来需要を現在の投資へ変換する行為でもある。
⸻
医療にも、
予測時間がある。
高齢者人口。
疾病構造。
医療従事者。
病床需要。
医薬品需要。
地域人口。
これらを予測しなければ、
必要な医療体制を準備できない。
教育も同じである。
十年後に必要な人材を、
十年後から育て始めることはできない。
未来を予測することで、
社会は時間差を埋めている。
⸻
つまり、
予測時間には、
大きな価値がある。
未来の変化を、未来になる前に現在へ伝える。
人口減少が予測される。
ならば、
制度を準備する。
災害Riskが高まる。
ならば、
Infrastructureを強化する。
Technologyが変わる。
ならば、
研究や人材育成を始める。
予測によって、
未来のSignalを現在で受け取ることができる。
⸻
しかし、
予測には限界もある。
第一に、
予測は現在の構造を前提にしやすい。
現在の制度。
現在の行動。
現在の産業構造。
それらが大きく変わらないという前提で、
未来を計算する場合が多い。
しかし、
Technologyや制度そのものが変われば、
過去のTrendから外れることがある。
⸻
たとえば、
人口減少から労働力不足を予測する。
これは合理的である。
しかし、
AIやAutomationによって、
一人あたりの生産能力が大きく変化すれば、
労働力不足が経済へ与える影響も変わる。
遠隔医療が普及すれば、
医療人材の地域配置の意味も変わるかもしれない。
つまり、
構造が変わると、予測の前提も変わる。
⸻
第二に、
予測精度は、
未来へ行くほど一般に低下する。
一年後。
五年後。
二十年後。
時間が長くなるほど、
Technology。
政治。
国際環境。
社会行動。
自然災害。
など、
予測できない変数が増える。
だから、
長期予測を一つの数字として扱いすぎると危険である。
重要なのは、
一点予測だけではなく、
複数Scenarioを見ることである。
⸻
第三に、
予測された未来が、
そのまま望ましい未来とは限らない。
人口が減ると予測された。
財政負担が増えると予測された。
地域交通が維持できなくなると予測された。
そこで必要なのは、
予測に従うことではない。
その未来をどこまで変えられるかを考えること
である。
ここで、
ForecastとFuture Pullが分かれる。
⸻
Forecastは、
何が起こりそうか
を示す。
Future Pullは、
どの状態を実現したいか
を置く。
そして、
二つを比較する。
たとえば、
予測では、
ある地域の公共交通が縮小する。
しかしFuture Stateでは、
高齢者を含む住民が、
必要な移動手段へアクセスできる状態を置く。
その差が、
新しい交通Serviceや制度設計のRequirementになる。
⸻
つまり、
予測時間は、
Future Pullによって不要になるのではない。
むしろ、
Future Pullの重要な入力になる。
Forecast Future
と、
Desired Future State
を比較する。
そのGapを、
政策や投資へ変える。
予測された未来を知るからこそ、
何を変える必要があるかが分かる。
⸻
ここで、
予測時間と設計時間の違いが明確になる。
予測時間は、
現在から未来へ進む。
設計時間は、
未来から現在へ戻る。
Current State
→ Forecast Future
と、
Future State
→ Current Requirement
である。
この二つを重ねる。
すると、
未来に対する社会の姿勢が変わる。
⸻
たとえば、
2040年に医療人材が不足すると予測される。
予測だけなら、
不足人数を計算する。
Future Pullでは、
その条件でも医療Serviceを維持できるFuture Stateを置く。
そこから、
人材育成。
業務分担。
AI。
Automation。
遠隔医療。
予防。
地域連携。
を現在へ引く。
つまり、
予測が、
問題の通知
から、
設計の入力
へ変わる。
⸻
これは、
経済予測にも当てはまる。
低成長が予測される。
そこで、
低成長を前提として支出を削減するだけではなく、
どの産業で新しい成長をつくれるかを見る。
生産性をどう高めるか。
人材をどこへ移すか。
研究投資をどこへ配分するか。
Forecastが現在の制約を示し、
Future Stateが行動方向を示す。
両方を持つことで、
政策はより立体的になる。
⸻
また、
予測そのものも更新する必要がある。
Technologyが変われば、
予測を変える。
政策を実施すれば、
将来推計も変わる。
人々の行動が変われば、
需要予測も変わる。
つまり、
Forecastは固定された未来ではない。
Current Realityに応じて更新される仮説
である。
⸻
この点は、
Future Pullとよく似ている。
Future Stateも仮説である。
Forecastも仮説である。
一方は、
起こりそうな未来。
もう一方は、
実現したい未来。
Realityが変化すれば、
どちらも更新する。
つまり、
未来設計には、
二つの仮説を同時に持つこと
が重要になる。
⸻
第一の仮説。
このまま進めば、
どこへ行くのか。
第二の仮説。
どこへ行きたいのか。
そして、
その差を埋めるために、
現在何をするのか。
Forecast
→ Gap ← Future State
↓
Present Action
ここに、
予測時間とFuture Pullの接続がある。
⸻
予測時間を正しく使えば、
未来を待つ必要はなくなる。
将来の問題を、
現在へ早く知らせることができる。
一方、
Future Pullを加えれば、
知らせるだけでなく、
現在から未来へ介入できる。
だから、
未来を早める社会に必要なのは、
予測能力を捨てることではない。
予測を、実装へつなぐこと
である。
⸻
AIによって、
予測時間も変化する。
大量のDataを分析する。
複数Scenarioを計算する。
変化をより早く検知する。
予測を頻繁に更新する。
こうした能力が高まれば、
社会は未来の変化をより早く認識できる。
しかし、
どれだけ予測精度が高まっても、
何を目指すべきかまでは自動的に決まらない。
PredictionとDecisionは、
別の問題である。
⸻
したがって、
未来社会に必要なのは、
「最も正確な予測に従うこと」ではない。
予測を見る。
Riskを理解する。
複数Scenarioを比較する。
そして、
社会としてFuture Stateを選ぶ。
予測は、
選択を助ける。
しかし、
選択そのものではない。
⸻
本書における予測時間とは、
未来を固定する時間ではない。
未来の変化を早く現在へ知らせる時間
である。
そして、
その情報を受け取った現在から、
Future Pullを始める。
予測する。
未来状態を置く。
Gapを見る。
現在から実装する。
結果によって予測を更新する。
この循環が動く。
⸻
線形時間では、
現在から未来へ進んだ。
予測時間では、
未来のSignalを現在へ先取りする。
そしてFuture Pullでは、
未来のRequirementを現在へ引く。
時間は、
一本の矢印だけではなくなり始める。
未来を見る。
現在へ戻す。
そして、
現在から実行する。
予測時間は、
その往復を可能にする最初の橋なのである。
第3節 制度時間
Technologyが完成しても、社会はすぐには変わらない。
新しい医療技術が生まれる。
AIが高度化する。
新しい金融Serviceが可能になる。
自動運転が実用段階へ入る。
それでも、それらが社会で利用されるまでには時間がかかる。
法律。
規制。
予算。
行政手続き。
安全基準。
責任分担。
社会的合意。
Technologyとは異なる時間で動くものがある。
それが、
制度時間
である。
⸻
制度には、社会を安定させる役割がある。
新しいものが登場するたびに、社会全体が即座に変われば、予測可能性を保つことができない。
法律は権利を守る。
規制は安全を守る。
予算制度は公共資源の使い方を管理する。
許認可は一定の基準を保証する。
制度が慎重に変化することには理由がある。
したがって、
制度時間がTechnologyより遅いこと自体を、単純に問題と考えるべきではない。
⸻
しかし、
制度時間が未来実装のBottleneckになることはある。
Technologyはすでに存在する。
利用者もいる。
企業も実装できる。
資本もある。
それでも、
制度が対応していないため利用できない。
この状態では、
未来生成ポテンシャルが存在していても、
Realityへ移ることができない。
⸻
AIを考えてみる。
AIの性能は短期間で変化する。
しかし、
行政や医療、金融で利用する場合には、
性能だけでは判断できない。
個人情報をどう扱うのか。
誤った判断が出た場合に誰が責任を持つのか。
人間による確認をどこまで必要とするのか。
どのDataを利用できるのか。
監査できるのか。
Securityをどう確保するのか。
こうした制度条件が必要になる。
つまり、
Technology TimeとInstitutional Timeは、
同じ速度では進まない。
⸻
医療では、
その違いがさらに明確になる。
新しい薬や医療機器が開発されても、
安全性と有効性を確認する必要がある。
臨床試験。
審査。
承認。
保険適用。
医療機関への導入。
医療者へのTraining。
患者への説明。
ここには、
短縮してはいけない時間が含まれている。
生命と安全に関わるからである。
未来を早めるとは、
この時間を無条件に削ることではない。
⸻
重要なのは、
必要な制度時間と、不要な待ち時間を区別すること
である。
安全性確認に三年必要なら、
三年は必要である。
しかし、
安全性確認が終わってから制度検討を始める必要があるとは限らない。
研究開発の段階から、
将来必要になる制度論点を整理できる。
Technology開発と並行して、
Data利用。
責任。
認証。
保険。
倫理。
などを検討する。
すると、
安全性を犠牲にせず、
実装までの総時間を短縮できる。
⸻
ここに、
制度時間を設計するという考え方が生まれる。
従来は、
Technologyが生まれる。
社会へ広がる。
問題が起きる。
その後、
制度が対応する。
という順序になりやすかった。
しかし、
Future Stateから逆算すれば、
将来必要になる制度を先に考えられる。
Future State
→ Institutional Requirement
→ Policy Design
→ Trial
→ Implementation
制度を、
未来への後追いではなく、
未来実装の準備として扱う。
⸻
これは、
制度を未来予測だけで先に固定することとは違う。
Technologyの未来は不確実である。
早く制度を固定しすぎれば、
Innovationを阻害する可能性がある。
だから、
制度にも段階を持たせる。
Guideline。
限定的な実証。
Regulatory Sandbox。
暫定Rule。
評価。
正式制度。
一度に完成制度をつくらず、
Realityから学びながら制度を更新する。
⸻
つまり、
制度にもPrototypeが必要になる。
新しい制度を、
最初から全国へ適用する必要はない。
特定地域。
特定産業。
特定医療機関。
一定期間。
限定された条件で試す。
その結果を見る。
問題があれば修正する。
有効なら拡大する。
制度も実装しながら学習できる。
⸻
この考え方は、
自治体にも重要である。
日本全国で制度が完全に統一されるまで待つのではなく、
自治体の権限内で実施できることを試す。
地域交通。
Healthcare。
行政Digital化。
Energy。
防災。
教育。
地域ごとに異なる条件の中で実証する。
その成果を、
国の制度設計へ返す。
すると、
制度時間は、
中央から地方への一方向ではなくなる。
地域実装 → 学習 → 国家制度
という流れも生まれる。
⸻
制度時間には、
政治時間も含まれる。
法律を変えるには、
議論が必要である。
利害調整。
国会審議。
予算。
選挙。
世論。
民主主義社会では、
意思決定に時間がかかる。
これも、
単純な非効率ではない。
多様な意見を調整し、
社会的正当性を形成する時間だからである。
⸻
だから、
未来実装を早めるために、
民主的な手続きを省略すればよいわけではない。
むしろ、
Future Stateを早く共有する。
必要な論点を早く提示する。
選択肢を比較する。
実証Dataを公開する。
社会的議論を早い段階から始める。
意思決定の開始時点を前へ移す。
これによって、
必要な政治時間を保持しながら、
未来への到達を早めることができる。
⸻
予算制度にも時間がある。
政策が必要だと分かっても、
すぐに大規模な公共支出ができるとは限らない。
予算要求。
査定。
国会審議。
執行。
評価。
年度という単位で動く。
Future Stateから必要時期を逆算すれば、
予算要求そのものを早く始めることができる。
つまり、
制度時間を短縮する方法の一つは、
制度を速く動かすことではなく、早く動かし始めること
である。
⸻
これは人材制度でも同じである。
新しいTechnologyを導入してから、
人材育成を始めるのでは遅い。
未来に必要な職種や能力が見えているなら、
教育制度。
資格制度。
大学Curriculum。
企業Training。
を先に準備する。
未来の制度Requirementを、
現在へ引く。
すると、
Technologyが社会へ入る時点で、
人材側も準備できる。
⸻
制度時間を考えるとき、
もう一つ重要なのが、
制度間のDependency
である。
一つの法律だけを変えても、
未来が実装できないことがある。
個人情報。
医療。
金融。
労働。
税制。
地方自治。
複数制度が同時に関係する。
未来のServiceは、
既存の行政区分を横断することが多い。
だから、
一つの省庁だけで制度設計すると、
別の制度がBottleneckになることがある。
⸻
Future Pullでは、
Future Stateから必要な制度を横断的に見る。
どの法律が関係するのか。
どの省庁が関係するのか。
自治体の権限はどこまでか。
民間Ruleで対応できる部分は何か。
法律変更が必要な部分は何か。
これを先に整理する。
すると、
制度変更のDependencyを解くことができる。
⸻
制度には、
変えない価値もある。
すべての制度を未来へ合わせて変更する必要はない。
法の支配。
基本的人権。
財産権。
Privacy。
安全。
公平性。
民主的手続き。
こうした原則は、
Technologyが変化しても重要である。
未来設計とは、
古い制度をすべて壊すことではない。
守るべき原則と、変更可能な実装方法を分けること
である。
⸻
この区別ができれば、
制度はTechnologyに追い回されなくなる。
原則は保持する。
実装Ruleは更新する。
新しいRealityが現れれば、
また検証する。
制度そのものが、
継続的に学習できるようになる。
⸻
制度時間を最小に整理すると、
三つに分けられる。
守る時間。
安全性、権利、公平性、民主的正当性を確保するために必要な時間。
準備する時間。
将来必要になる制度を、Technologyの実装前から検討する時間。
そして、
学習する時間。
実証とRealityから制度を更新する時間。
未来実装を早めるとは、
第一の時間を消すことではない。
第二と第三を早く開始することである。
⸻
ここで、
時間Architectureがさらに明確になる。
Technologyが完成してから制度を考えるのではない。
Future Stateから、
Technology RequirementとInstitutional Requirementを同時に引く。
そして、
可能な範囲で並行して進める。
Future State
↓
Technology
＋
Institution
＋
Finance
＋
Human Resources
未来から複数の時間を同時に開始する。
⸻
日本にとって、
この転換は重要である。
制度が遅いから未来が遅れる、
と考えるだけでは不十分である。
問うべきなのは、
制度時間をいつ開始したのか
である。
Technologyが完成してから始めれば、
制度時間は未来を遅らせる。
Future Stateが見えた段階から始めれば、
制度時間はTechnologyと並行して進む。
同じ三年間でも、
未来実装時期は変わる。
⸻
制度は、
未来の障害である必要はない。
正しく設計されれば、
未来を安全に社会へ入れるためのInterfaceになる。
Technologyの可能性を、
社会の権利、安全、公平性と接続する。
Innovationを、
Realityへ移す。
その役割を担う。
⸻
だから、
制度時間をゼロにする必要はない。
必要な時間は残す。
不要な待ち時間をなくす。
未来から早くRequirementを引く。
実証と制度設計を接続する。
Realityから学び、
制度を更新する。
制度を遅くする時間から、未来を準備する時間へ。
この転換が起きたとき、
制度は未来の後を追うものではなくなる。
制度そのものが、
未来を現在へ引くためのArchitectureの一部になるのである。
第4節 技術時間
Technologyには、
制度とは異なる時間がある。
研究室で生まれた技術が、
Prototypeになる。
製品になる。
市場へ出る。
価格が下がる。
性能が上がる。
他のTechnologyと接続され、
社会Infrastructureの一部になる。
この一連の変化には、
技術時間
が存在する。
⸻
技術時間は、
一定ではない。
橋や発電所の技術は、
長い研究開発と建設期間を必要とする。
医薬品も、
基礎研究から臨床まで長い時間がかかる。
一方、
Softwareは、
数週間や数か月で大きく変わることがある。
AIはさらに、
Model。
Chip。
Data。
Cloud。
Application。
が相互に進歩することで、
短期間に利用可能性が変化する。
つまり、
「Technology」という一語の中にも、
異なる速度が存在する。
⸻
この違いを無視すると、
未来設計を誤る。
十年かかるTechnologyを、
二年後の政策目標へ入れても実装できない。
逆に、
すでに利用可能なTechnologyを、
十年後の構想へ置けば、
現在から使える未来まで先送りしてしまう。
だから、
Future Pullでは、
Technologyごとに、
現在どの段階にあるのか
を見る必要がある。
⸻
基礎研究なのか。
実験段階なのか。
Prototypeなのか。
商用化されているのか。
大量導入できるのか。
価格は十分下がっているのか。
必要なInfrastructureは存在するのか。
運用人材はいるのか。
技術時間とは、
発明から完成までの時間だけではない。
社会で安定して使える状態になるまでの時間
である。
⸻
たとえばAIでは、
Modelの性能向上だけを見ても十分ではない。
企業や行政で利用するには、
Data。
Security。
API。
既存Systemとの接続。
業務設計。
人材。
費用。
Governance。
が必要になる。
AI Modelが一週間で更新されても、
企業System全体を一週間で変更できるわけではない。
つまり、
技術時間には、
Technologyそのものの時間と、Technologyを利用可能にする時間
がある。
⸻
この二つを分ける必要がある。
技術が存在する。
しかし、
社会実装にはまだ時間がかかる。
この状態は珍しくない。
自動運転。
再生医療。
Robot。
次世代Energy。
量子技術。
高度なAI。
多くのTechnologyが、
研究、実証、商用化、普及という異なる段階を持っている。
だから、
「いつ実現するか」という問いだけでは粗すぎる。
何が、どのScaleで、いつ利用可能になるのか
を見る。
⸻
技術時間には、
Scaleの問題もある。
一台動くことと、
全国で使えることは違う。
研究室で動く。
一企業で使える。
一地域で使える。
全国で利用できる。
世界規模で供給できる。
必要な時間は異なる。
たとえば新しいEnergy Technologyが実証に成功しても、
発電設備。
送電網。
Supply Chain。
保守人材。
資金。
まで整えなければ、
社会全体のEnergy Systemにはならない。
つまり、
技術時間は、
Scale-up Time
も含んでいる。
⸻
さらに、
価格も技術時間を決める。
技術的には可能でも、
非常に高価なら、
利用できる場所は限られる。
量産される。
競争が起きる。
部品価格が下がる。
運用効率が上がる。
すると、
以前は研究機関や大企業だけが使えたTechnologyが、
中小企業や個人にも広がる。
つまり、
Technologyが社会へ到達する時期は、
性能だけではなく、
Cost Curve
にも左右される。
⸻
だから、
未来設計では、
「いつTechnologyが完成するか」だけでなく、
「いつ社会が使える価格になるか」を見る必要がある。
これは、
AI。
Battery。
Robot。
Sensor。
医療機器。
半導体。
多くの分野に当てはまる。
Future Stateに必要なTechnologyが、
技術的には存在していても、
Costが高すぎるなら、
価格低下までの時間もRequirementになる。
⸻
技術時間には、
標準化の時間もある。
新しいTechnologyが複数企業から登場しても、
互いに接続できなければ普及しにくい。
Data Format。
通信規格。
API。
安全基準。
認証。
標準化によって、
異なる製品や企業が接続できるようになる。
すると、
市場が大きくなる。
つまり、
Standardizationも技術時間を短縮するInfrastructure
である。
⸻
ここで、
日本のTechnologyについて重要な視点が生まれる。
日本には、
高い技術力が存在していても、
社会実装や事業化まで時間がかかる場合がある。
その原因を、
「Technologyが弱い」
だけで説明することはできない。
研究から事業へ。
Prototypeから量産へ。
大企業からStartupへ。
大学から産業へ。
Technologyから制度へ。
この接続時間を見る必要がある。
⸻
つまり、
技術時間を短縮する方法の一つは、
研究速度を上げることだけではない。
研究から次工程への移行時間を短縮すること
である。
研究成果が出る前から、
将来の事業化可能性を検討する。
大学と企業を早く接続する。
Prototypeの段階から製造工程を考える。
制度上の論点も並行して確認する。
Financeも準備する。
すると、
研究期間そのものは同じでも、
社会実装までの総時間を短縮できる。
⸻
また、
Technologyをすべて国内で開発する必要はない。
未来実装時間という観点では、
BuildかBuyか
という判断も重要になる。
日本独自に開発すべきTechnology。
海外から導入したほうが早いTechnology。
共同開発すべきもの。
Open Sourceを利用できるもの。
国内に保持すべき中核技術。
これらを分ける。
すべてをゼロから開発すれば、
技術主権は高まるかもしれないが、
時間も費用も大きくなる。
逆に、
すべてを外部依存すれば、
将来の選択肢を失う可能性がある。
だから、
速度と自律性の両方を見る。
⸻
Future Pullでは、
この判断もFuture Stateから行う。
将来、
日本が自ら保持すべき能力は何か。
どこは世界と接続すればよいのか。
どこにSupply Chain Riskがあるのか。
その未来から、
現在の研究開発と調達を設計する。
つまり、
技術政策も、
現在の技術一覧からではなく、
未来に必要な能力Portfolio
から考える。
⸻
技術時間には、
人材時間も重なる。
新しいTechnologyが登場しても、
利用できる人間がいなければ普及しない。
Engineer。
研究者。
医師。
Operator。
経営者。
行政官。
利用者。
それぞれに新しい能力が必要になる。
Technologyが一年で進歩しても、
人材育成には数年かかる場合がある。
だから、
Technology Roadmapと、
Human Resource Roadmapを分けてはいけない。
⸻
特にAIでは、
この問題が大きい。
AI自体の性能が急速に変化するため、
固定されたSkillだけを教育しても追いつかない。
必要なのは、
特定Toolの操作だけではない。
AIを使って、
問題を定義する。
結果を検証する。
業務を再設計する。
責任を持って判断する。
こうした能力である。
技術時間が速いほど、
教育は、
Technologyそのものではなく、
変化へ対応できる能力を育てる必要がある。
⸻
一方、
技術時間を速めることだけを目的にしてはいけない。
新しいTechnologyには、
Riskがある。
安全性。
Cybersecurity。
Privacy。
Environment。
雇用。
社会的影響。
すべてを早く市場へ出せばよいわけではない。
制度時間と同じように、
Technologyにも、
慎重に検証すべき段階がある。
⸻
だから、
未来を早めるとは、
研究から市場までのすべての時間を短縮することではない。
必要な検証時間を残す。
不要な待ち時間を減らす。
並行できる工程を並行する。
既存Technologyを再利用する。
外部Technologyも活用する。
Scale-upを早く準備する。
この組み合わせによって、
技術時間を設計する。
⸻
そして、
Technologyは完成して終わらない。
Versionが更新される。
新しいTechnologyが登場する。
価格が変わる。
利用方法が変わる。
だから、
未来設計も、
一つのTechnologyへ固定してはいけない。
Future Stateを保持し、
Technologyは更新可能にする。
目的は安定させ、手段は更新する。
この原則が重要になる。
⸻
たとえば、
Future Stateが、
「人口減少地域でも持続可能な移動手段を確保する」
であるなら、
現在はOn-demand Busを使う。
将来は自動運転へ移る。
さらに別のTechnologyが登場すれば、
そこへ移行する。
Future Stateを特定Technologyと同一化しなければ、
技術進歩を取り込める。
⸻
ここに、
Future Pullと技術時間の接続がある。
Future Stateを置く。
必要な機能を明らかにする。
現在利用可能なTechnologyを見る。
足りなければ研究開発を始める。
既存Technologyで先行実装できる部分は先に実装する。
新しいTechnologyが成熟すれば置き換える。
つまり、
未来をTechnologyの完成まで待たない。
現在利用できる技術で、未来の一部を先に実装する。
⸻
最小に整理すれば、
技術時間には、
四つの時間がある。
研究する時間。
実用化する時間。
普及させる時間。
そして、
更新する時間。
Future Pullは、
これらをFuture Stateから逆算する。
何を今研究するか。
何を今実装するか。
何をScale-upするか。
何を将来置き換えるか。
その時間を配置する。
⸻
Technologyは、
未来を早める最も強力な力の一つである。
しかし、
Technologyが速いだけでは、
社会の未来は速くならない。
制度。
資本。
人材。
Infrastructure。
社会。
それらと接続されて初めて、
TechnologyはRealityになる。
だから、
技術時間を設計するとは、
新しい技術を最速で生み出すことだけではない。
Technologyが社会で価値として機能するまでの全時間を設計すること
なのである。
第5節 文明時間
社会には、
制度時間よりも、
技術時間よりも、
さらに長い時間がある。
言語。
文化。
価値観。
宗教。
慣習。
家族。
共同体。
自然との関係。
国家への感覚。
働くことへの考え方。
生きることと死ぬことへの理解。
これらは、
数年の政策によって成立したものではない。
何世代にもわたって形成され、
社会の深い部分に蓄積されてきた。
本書では、
この長い時間を、
文明時間
と呼ぶ。
⸻
Technologyは、
数年で変わることがある。
制度も、
法律を改正すれば変えることができる。
しかし、
人々の行動や価値観は、
法律を変えた翌日に変わるわけではない。
新しい制度ができても、
利用されないことがある。
新しいTechnologyが導入されても、
社会へ定着しないことがある。
そこには、
文明時間とのずれがある。
⸻
たとえば、
働き方を変える制度をつくる。
制度上は可能になった。
しかし、
長時間働くことを評価する文化。
組織への帰属意識。
上司と部下の関係。
職業に対する社会的評価。
こうしたものが変わらなければ、
実際の働き方は大きく変わらない場合がある。
制度時間が進んでも、
文明時間が同じ場所に残っている。
⸻
医療でも同じである。
Technologyによって、
予防。
Remote Healthcare。
Personalized Medicine。
AI診療支援。
などが可能になる。
しかし、
人々が医療を、
「病気になってから病院へ行くもの」
として理解しているなら、
Technologyだけでは予防中心のHealthcareへ移行しない。
健康に対する考え方そのものが変わる必要がある。
ここでは、
技術時間と文明時間が接続されなければならない。
⸻
Energyも同じである。
新しいEnergy Technologyがあっても、
土地利用。
景観。
地域共同体。
自然との関係。
費用負担。
世代間の考え方。
が関係する。
Technologyとして正しいことが、
そのまま社会的に受け入れられるとは限らない。
社会実装には、
人々が納得し、
自分たちの生活との関係を理解する時間が必要になる。
⸻
だから、
未来実装時間を短縮するとき、
文明時間を無視してはいけない。
制度を変える。
Technologyを導入する。
予算を付ける。
それだけで社会が変わると考えれば、
実装段階で大きな抵抗が生まれることがある。
未来は、
Systemの中だけではなく、
人々の日常へ入ったときに初めて社会になる。
⸻
文明時間には、
変化を遅くする側面がある。
しかし、
それだけではない。
文明時間は、
未来を支える資産にもなる。
長い時間をかけて形成された、
信頼。
知識。
慣習。
技術。
共同体。
文化。
自然との関係。
これらを使えば、
未来をゼロからつくる必要がなくなる。
⸻
日本を考えると、
この視点は特に重要である。
日本には、
長い時間を持つ主体が存在する。
地域共同体。
神社。
寺院。
祭り。
伝統産業。
老舗企業。
大学。
自治体。
農村。
漁村。
都市。
そして、
日本語。
それぞれが、
異なる形で長期のMemoryを保持している。
⸻
このMemoryを、
単に過去として保存するだけなら、
文明時間は後ろ向きの時間になる。
しかし、
未来へ翻訳すれば、
新しい意味を持つ。
伝統建築の知識を、
現代の環境設計へ接続する。
地域共同体のNetworkを、
防災へ利用する。
寺院や神社を、
地域文化や交流の拠点として再評価する。
伝統工芸を、
DesignやTechnologyと接続する。
長い時間を、
未来の資源へ変える。
⸻
つまり、
文明時間とは、
過去から現在へ流れてきた時間であると同時に、
未来へ利用できる蓄積時間
でもある。
⸻
Future Pullでは、
Future Stateから現在を見る。
そのとき、
新しいTechnologyだけを見るのではない。
未来に必要なものが、
過去からすでに存在していないかを見る。
地域の信頼関係。
自然管理の知識。
長期経営。
文化的な多様性。
共同体の支え合い。
こうしたものが、
未来社会のRequirementになる可能性がある。
⸻
ここで、
未来と伝統は対立しなくなる。
伝統を残すか。
未来へ進むか。
その二択ではない。
問うべきなのは、
何を継承し、何を変更し、何を未来へ再実装するか
である。
⸻
文明には、
変えてはいけないものがあるわけではない。
逆に、
すべて変える必要もない。
重要なのは、
機能を見ることである。
なぜその慣習が残ったのか。
何を守っていたのか。
どのような社会的役割を持っていたのか。
その機能が現在も必要なら、
新しい形へ翻訳できる。
機能を失っているなら、
変更することもできる。
⸻
この意味で、
文明時間にも、
Future Stateが必要になる。
未来の日本で、
何を残したいのか。
何を変えたいのか。
何を世界へ開くのか。
何を次世代へ渡すのか。
これを考える。
未来から見ることで、
過去のすべてを保存する必要も、
過去のすべてを否定する必要もなくなる。
⸻
文明時間には、
世代という単位もある。
政策は数年。
企業戦略は数年から十年。
Infrastructureは数十年。
しかし、
教育。
文化。
森林。
都市。
人口構造。
社会的価値観。
は、
一世代を越えて変化する。
だから、
未来設計には、
選挙周期や事業年度より長い視点が必要になる。
⸻
たとえば、
2050年の社会をつくる人々の一部は、
現在すでに学校で学んでいる。
さらにその先の社会を担う人々は、
これから生まれる。
現在の教育。
現在のEnvironment。
現在の公共投資。
現在の財政。
これらは、
まだ意思決定に参加できない世代の未来にも影響する。
文明時間とは、
現在世代だけでは完結しない時間
でもある。
⸻
ここで、
国家の役割も変わる。
国家は、
現在の国民だけを管理するSystemではない。
過去から受け取った資産を保持し、
現在の社会を運営し、
次世代へ条件を渡す。
Infrastructure。
財政。
自然環境。
文化財。
制度。
Knowledge。
これらは、
世代間で継承される。
つまり、
国家政策には、
短期政策と同時に、
文明時間を扱う視点が必要になる。
⸻
企業にも文明時間は存在する。
特に、
長く続く企業には、
技術。
取引関係。
信用。
Brand。
人材育成。
組織文化。
が蓄積されている。
短期利益だけを見れば、
不要に見えるものもある。
しかし、
長期的には競争力の源泉になっている場合がある。
未来設計では、
企業のMemoryも、
Future Potentialとして見る必要がある。
⸻
一方で、
文明時間が長いほど、
変化が難しくなることもある。
過去に成功した方法。
組織慣行。
社会的常識。
既存の役割分担。
それらが、
新しいRealityと合わなくなることがある。
だから、
文明時間を尊重することと、
過去を固定することは違う。
継承には、
更新が必要である。
⸻
ここで、
文明時間の設計原則が見えてくる。
継承する。
翻訳する。
更新する。
過去から受け取る。
現在の言葉へ翻訳する。
未来に必要な形へ更新する。
この三つを循環させる。
⸻
これは、
神社や寺院にも当てはまる。
宗教施設としての役割。
地域共同体としての役割。
文化財としての役割。
観光資源としての役割。
災害時の拠点としての可能性。
未来では、
複数の機能が重なるかもしれない。
長い歴史を保持したまま、
新しい社会機能を持つことは可能である。
⸻
芸術や音楽も、
文明時間を動かす。
法律より早く、
社会の感覚を変えることがある。
新しい価値観。
新しい身体感覚。
新しい生活像。
新しい人間関係。
それらを、
芸術は制度になる前に表現する。
つまり、
文明時間は必ずしも遅いだけではない。
文化の一部は、
未来を先に感じる時間
でもある。
⸻
ここに、
文明時間の特徴がある。
過去を最も長く保持しながら、
未来を最も早く感じることもある。
伝統と創造。
MemoryとInnovation。
この二つが同時に存在する。
⸻
だから、
日本の未来実装を考えるとき、
文明を最後に付け加える要素として扱ってはいけない。
政治。
金融。
産業。
医療。
Technology。
教育。
それらの実装が、
日本社会へどのように受け入れられるのか。
その深い条件として、
文明時間が存在している。
⸻
Future Pullは、
この長い時間にも適用できる。
未来の日本を置く。
そこから、
何を継承する必要があるかを見る。
何を更新する必要があるかを見る。
何を今から次世代へ渡す必要があるかを見る。
すると、
未来から現在へ、
数十年、
数百年の時間を引くことができる。
⸻
技術時間は速い。
制度時間はそれより長い。
文明時間は、
さらに長い。
しかし、
それらを同じ速度にする必要はない。
重要なのは、
同じFuture Stateへ接続すること
である。
TechnologyはTechnologyの速度で進む。
制度は安全と正当性を保ちながら進む。
文明は継承と更新を続ける。
それぞれの時間を保持したまま、
未来で交差させる。
⸻
未来を早めるとは、
文明を急がせることではない。
文明時間の中にすでに存在する資産を発見し、
未来へ接続することである。
新しいものだけで未来をつくらない。
過去から継承されたものも使う。
すると、
未来までの距離は短くなる。
⸻
日本の未来は、
未来から突然やって来るのではない。
最新Technologyだけから生まれるのでもない。
何世代にもわたって蓄積されたものと、
現在生まれているものが接続されたとき、
新しいRealityになる。
文明時間とは、過去を保存する時間ではない。
過去を現在へ渡し、
現在から未来へ渡す、
長期の実装時間である。
そして、
その時間までFuture Pullへ接続したとき、
日本の未来設計は、
数年の政策計画を越えて、
文明そのものの設計へ広がるのである。
第6節 Implementation Time
未来には、予測された時期がある。
Technologyが実用化される時期がある。
制度が整う時期がある。
社会が受け入れるまでの時間がある。
しかし、本書が最も重視するのは、それらとは少し異なる。
未来が実際にRealityとして動き始めるまで、どれだけ時間が必要なのか。
この時間を、
Implementation Time
と呼ぶ。
⸻
あるTechnologyが完成した日と、
社会で使われ始める日は、
同じではない。
研究成果が発表される。
Prototypeが完成する。
制度が整う。
資金が付く。
人材が集まる。
Systemが導入される。
利用者が使う。
運用が安定する。
ここまで到達して、
初めて未来はRealityになる。
Implementation Timeとは、
可能性が実装へ変わるまでの総時間
である。
⸻
たとえば、
AIによる行政支援が技術的に可能になったとする。
それでも、
すぐ全国の行政で利用できるわけではない。
利用目的を決める。
Dataを整備する。
Securityを確認する。
調達する。
既存Systemと接続する。
職員をTrainingする。
運用Ruleを決める。
評価する。
必要なら改善する。
Technologyが存在してから、
社会的な実装が完了するまで、
複数の工程が存在する。
⸻
医療なら、
さらに多くの時間が重なる。
研究時間。
臨床時間。
承認時間。
制度時間。
医療者のTraining。
病院への導入。
患者への普及。
医療では、
Technologyが成立した時点と、
患者がその恩恵を受ける時点の間に、
長いImplementation Timeが存在することがある。
⸻
だから、
未来を早めるためには、
Technologyの進歩速度だけを見てはいけない。
重要なのは、
End-to-Endの時間
である。
未来の可能性が生まれてから、
社会の中で価値として機能するまで。
その全体を見る。
⸻
Implementation Timeは、
複数の時間から構成される。
研究する時間。
Technologyを実用化する時間。
制度を整える時間。
資本を準備する時間。
Infrastructureを構築する時間。
人材を育てる時間。
社会へ導入する時間。
利用者が適応する時間。
これらが、
一つの未来実装の中に重なっている。
⸻
ここで重要になるのが、
直列と並列
である。
すべての工程を直列に進めれば、
時間は足し算になる。
研究に五年。
制度に三年。
設備に二年。
人材育成に三年。
単純に順番に行えば、
実装まで非常に長い時間がかかる。
しかし、
実際には並行できる工程がある。
研究を進めながら、
制度論点を整理する。
Technologyを開発しながら、
人材を育てる。
実証しながら、
Financeを準備する。
Infrastructureを整備しながら、
運用設計を行う。
すると、
必要な時間を削らなくても、
総Implementation Timeは短くなる。
⸻
これは、
「急ぐ」こととは違う。
安全確認を省略しない。
研究精度を下げない。
民主的手続きを飛ばさない。
人材育成を雑にしない。
必要な時間は保持する。
その代わり、
工程間に存在する不要な待ち時間を減らす。
ここに、
未来実装時間短縮の基本がある。
⸻
Implementation Timeを考えると、
Bottleneckも見える。
全工程の中で、
最も時間がかかるものは何か。
あるいは、
他の工程がすべて完了しても、
最後まで実装を止めているものは何か。
それを特定する。
未来実装速度は、
最も速いTechnologyではなく、
最も遅い必要条件
によって決まる場合がある。
⸻
たとえば、
AIは完成している。
Dataもある。
利用者もいる。
しかし、
調達手続きに二年かかる。
ならば、
その二年がImplementation Timeを決める。
逆に、
制度は整っている。
資金もある。
しかし、
必要な専門人材を育てるのに五年かかる。
ならば、
人材時間を今すぐ開始する必要がある。
Future Pullによって、
このBottleneckを未来側から発見する。
⸻
もう一つ重要なのが、
Start Time
である。
未来が遅い理由は、
工程そのものが長いからとは限らない。
開始が遅い場合がある。
2035年に必要になるInfrastructureを、
2032年から検討する。
それでは間に合わないかもしれない。
2035年から逆算し、
十年必要なら、
2025年頃から準備を始める必要がある。
つまり、
未来実装を早める最も単純な方法の一つは、
必要な仕事を早く開始すること
である。
⸻
Future Pullは、
この開始時点を見つける。
Future Stateを置く。
Requirementを分解する。
各Requirementの所要時間を見る。
Dependencyを確認する。
完成時点から逆算する。
すると、
現在何を始めるべきかが分かる。
未来の日付が、
現在のStart Timeへ変換される。
⸻
Implementation Timeには、
Scaleも関係する。
一つの病院で実装する時間。
一つの自治体で実装する時間。
全国へ展開する時間。
これは同じではない。
だから、
未来を最初から全国規模で完成させようとすると、
Implementation Timeが長くなる。
⸻
そこで、
先行実装
という方法が有効になる。
一つの病院。
一つの自治体。
一つの大学。
一つの企業。
限定された範囲でFuture Stateの一部を実装する。
そこで、
Realityを見る。
成功すれば、
次へ展開する。
問題があれば、
小さい段階で修正する。
これによって、
未来を全国展開まで待つ必要がなくなる。
⸻
つまり、
未来には複数の実装時点がある。
Prototypeとしての未来。
地域としての未来。
産業としての未来。
国家としての未来。
「未来がいつ来るか」を、
一つの日付で答える必要はない。
未来は、
Scaleごとに段階的に現在へ入ってくる。
⸻
Implementation Timeを短縮するうえで、
既存資産の再利用も重要である。
すべてを新設する必要はない。
既存のCloud。
既存の病院。
既存の大学。
既存の工場。
既存の金融機関。
既存の行政組織。
既存の通信Infrastructure。
未来に必要な機能を、
現在の資産へ追加できるなら、
新規建設より早い。
⸻
だから、
Future Pullでは、
「未来に何を新しくつくるか」
だけを問わない。
現在の何を未来へ転用できるか
も問う。
これによって、
Costだけでなく、
Implementation Timeも短縮できる。
⸻
また、
共通基盤をつくることで、
複数の未来を同時に早めることができる。
Digital Identity。
Data Infrastructure。
Cybersecurity。
Cloud。
AI基盤。
Payment。
通信。
こうした共通Infrastructureを、
各Projectが個別につくれば、
同じ時間が何度も必要になる。
共通化できれば、
次の実装は速くなる。
⸻
ここで、
Implementation Timeには、
学習時間
も含まれる。
最初の実装は時間がかかる。
二回目は速くなる。
三回目はさらに速くなる。
手順が分かる。
標準ができる。
人材が育つ。
失敗例が共有される。
Templateができる。
つまり、
社会には、
実装するほど実装能力が高まるという効果がある。
⸻
この意味で、
未来実装を早める最も重要な方法の一つは、
実装経験を蓄積すること
である。
議論だけでは、
Implementation Timeは短くならない。
一度Realityへ出す。
検証する。
改善する。
再利用する。
この循環によって、
社会そのものが実装に習熟する。
⸻
そして、
Implementation Timeは、
分野によって異なる。
AI Serviceなら、
数か月で実装できるものがある。
新しい医薬品なら、
長期間を必要とする。
Energy Infrastructureなら、
十年以上かかることもある。
教育改革なら、
効果が社会へ現れるまで一世代かかる場合もある。
文明Memoryの更新には、
さらに長い時間が必要になる。
⸻
だから、
日本全体の未来を、
一つの時間表で管理することはできない。
必要なのは、
複数のImplementation Timeを並列に持つこと
である。
短期で実装できるものは、
今すぐRealityへ出す。
中期のものは、
制度と投資を始める。
長期のものは、
研究と人材育成を開始する。
文明時間に属するものは、
次世代への継承を始める。
⸻
すると、
日本の未来は、
「2050年に完成する一つの計画」
ではなくなる。
2026年に始まる未来がある。
2028年にRealityになる未来がある。
2030年代にScaleする未来がある。
2040年代に成熟する未来がある。
さらにその先へ継承されるものがある。
未来は、
複数の時間軸で現在へ入ってくる。
⸻
ここで、
本章で扱ってきた時間が一つにつながる。
予測時間は、
未来の変化を知らせる。
制度時間は、
未来を社会的に成立させる。
技術時間は、
未来の機能を可能にする。
文明時間は、
未来を社会の長期的な継承へ接続する。
そして、
Implementation Timeは、
それらすべてをRealityへ到達させる総時間
である。
⸻
したがって、
未来を早めるとは、
単純に速度を上げることではない。
どの時間が必要なのかを知る。
どの時間を並行できるかを見る。
どこにBottleneckがあるかを知る。
開始時点を前へ移す。
小さく先行実装する。
既存資産を再利用する。
実装経験を共有する。
それによって、
総時間を短縮する。
⸻
未来は、
予測された瞬間にはRealityではない。
発明された瞬間でもない。
法律が成立した瞬間でもない。
資金が付いた瞬間でもない。
それらが接続され、
人々の生活、企業、地域、社会の中で実際に機能し始めたとき、
初めてRealityになる。
その地点までの距離を、
時間として測る。
それが、
Implementation Timeである。
そして、
その時間を未来側から設計できるようになったとき、
「未来はいつ来るのか」という問いは、
次の問いへ変わる。
未来を、いつから実装するのか。
第7節 未来実装時間を短縮する
未来を早めるとは、
未来の日付を変えることではない。
2030年は2030年に来る。
2040年も2050年も同じである。
変えることができるのは、
あるFuture StateがRealityとして機能し始めるまでの時間
である。
その時間を短縮する。
これが、本章の結論である。
⸻
ここまで、
複数の時間を見てきた。
予測時間。
制度時間。
技術時間。
文明時間。
Implementation Time。
それぞれは、
異なる速度で動いている。
問題は、
どれか一つが遅いことではない。
それぞれが接続されず、順番に待っていること
である。
⸻
Technologyが完成するまで、
制度が待つ。
制度が完成するまで、
企業が待つ。
企業の実証が終わるまで、
人材育成が待つ。
全国制度が整うまで、
地域が待つ。
このように、
複数の時間が直列に並べば、
未来までの距離は長くなる。
だから、
未来実装時間を短縮する第一の方法は、
時間を並列化すること
である。
⸻
未来に必要なTechnologyが見えているなら、
研究と同時に制度論点を整理する。
将来必要になる人材が分かっているなら、
Technology完成前から育成する。
大規模投資が必要になるなら、
事業化前からFinanceを準備する。
社会的合意が必要なら、
実装直前ではなく早い段階から議論する。
未来からRequirementを引くことで、
複数の時間を同時に開始できる。
⸻
第二の方法は、
開始時点を前へ移すこと
である。
十年必要なものを、
九年後から始めれば間に合わない。
制度改革に三年必要なら、
三年前から動く。
Infrastructureに十五年必要なら、
Future Stateから十五年以上戻って準備を始める。
Future Pullの重要な役割は、
未来の完成日から、
現在の開始日を発見することにある。
⸻
第三は、
Bottleneckを先に解くこと
である。
すべての領域へ均等に資源を投入する必要はない。
未来実装を止めているものは何か。
Dataか。
制度か。
人材か。
資本か。
Technologyか。
Infrastructureか。
社会的合意か。
最も大きなBottleneckへ先に対応する。
それだけで、
全体が動き始めることがある。
⸻
第四は、
小さく先行実装すること
である。
全国で完成するまで待たない。
一自治体。
一病院。
一大学。
一企業。
一地域。
実装可能な場所から始める。
Future Stateの一部分でもRealityにする。
そこで、
費用。
安全性。
利用者反応。
制度課題。
運用課題。
を確認する。
未来を議論する時間を、
未来から学ぶ時間へ変える。
⸻
第五は、
既存資産を使うこと
である。
未来をつくるたびに、
すべてを新設する必要はない。
既存の企業。
既存の病院。
既存の大学。
既存の行政組織。
既存の金融機関。
既存のInfrastructure。
既存の文化施設。
現在にあるものを、
Future Stateへ向けて再接続する。
新設より再利用が速い場合には、
それ自体が時間短縮になる。
⸻
第六は、
共通基盤をつくること
である。
Digital Identity。
Data連携。
Cybersecurity。
Cloud。
通信。
決済。
AI利用環境。
こうした基盤を、
行政、医療、産業、教育が個別につくれば、
同じ時間と費用を繰り返す。
共通化できる部分を整えれば、
次のProjectは速く始められる。
一つの基盤投資が、
複数の未来実装時間を同時に短縮する。
⸻
そして第七は、
実装経験を循環させること
である。
未来実装は、
最初が最も難しい。
法律の解釈。
調達方法。
System構成。
人材。
費用。
Risk。
すべてを初めて確認するからである。
しかし、
一度実装すれば、
次は速くなる。
Templateができる。
標準ができる。
人材が育つ。
失敗例が残る。
導入手順が分かる。
社会全体に実装能力が蓄積される。
⸻
ここに、
未来実装時間の加速構造がある。
Implementation
→ Learning
→ Standardization
→ Reuse
→ Faster Implementation
一度の実装が、
次の実装時間を短縮する。
つまり、
未来を早める最も確実な方法の一つは、
未来について長く議論することではなく、
安全に実装できるものを早くRealityへ出すこと
である。
⸻
ただし、
速度だけを評価してはいけない。
早く導入したが、
安全でなかった。
利用されなかった。
費用が持続しなかった。
社会的な信頼を失った。
それでは、
Implementation Timeを短くした意味がない。
重要なのは、
持続可能なRealityへ到達するまでの時間
である。
⸻
だから、
未来実装時間には、
Verificationが含まれる。
実装する。
測定する。
問題を見る。
修正する。
再実装する。
ここまでを一つの時間として考える。
Fast Deployment
ではなく、
Fast Learning
を目指す。
失敗を隠さず、
早く発見し、
早く修正する。
そのほうが、
長期的には未来へ早く到達できる。
⸻
日本では、
完全な計画をつくってから実施しようとするほど、
開始まで時間がかかることがある。
しかし、
未来の不確実性が高い時代には、
実装前にすべてを確定することは難しい。
だから、
設計精度だけではなく、
修正速度
が重要になる。
小さく始める。
検証する。
直す。
広げる。
この循環を速くする。
⸻
ここで、
制度時間と技術時間も接続できる。
Technologyを試す。
制度上の問題が見える。
限定Ruleをつくる。
再び試す。
Dataを取る。
正式制度へ反映する。
つまり、
制度がTechnologyを待つのでも、
Technologyが制度を待つのでもない。
実装を通じて、双方が同時に学習する。
⸻
文明時間についても同じである。
文化や社会的価値観は、
命令によって短期間に変えることはできない。
だからこそ、
未来の社会像について、
早く対話を始める。
教育。
芸術。
音楽。
Media。
地域活動。
宗教。
さまざまな場所で、
新しいTechnologyや社会変化の意味を考える。
文明時間は短縮するのではなく、
早く動き始める。
⸻
これが、
本章で最も重要な時間設計原則である。
すべてを高速化しない。
時間が必要なものには時間を与える。
しかし、
開始を遅らせない。
並行できるものは並行する。
待つ必要のないものは待たない。
小さく実装する。
結果を共有する。
次へ使う。
⸻
この方法によって、
2035年のFuture Stateの一部を、
2030年より前に実装できるかもしれない。
2050年に必要な研究を、
現在から始められる。
将来必要になる制度を、
Technologyが完成する前から検討できる。
未来そのものの日付は変わらなくても、
未来の構成要素が現在へ到達する時期は変えられる。
⸻
そして、
この構成要素が増えるほど、
未来までの距離は短くなる。
最初は、
Future Stateが遠く見える。
しかし、
一つのRequirementが満たされる。
もう一つが満たされる。
Prototypeが動く。
制度が整う。
人材が育つ。
投資が始まる。
未来の一部分がRealityになる。
未来は、
一度に来るのではない。
段階的に現在へ移動してくる。
⸻
だから、
未来実装時間を短縮するとは、
未来を急いで完成させることではない。
未来を構成する条件を、
できるところから現在へ移すことである。
Future Stateを置く。
時間を分解する。
開始時点を逆算する。
Bottleneckを解く。
並行して進める。
小さく実装する。
学習を共有する。
そして、
次の実装をさらに速くする。
⸻
この循環が社会に定着すれば、
日本の未来実装能力そのものが変わる。
一つの未来を早く実現するだけではない。
未来を実装するたびに、次の未来をより速く実装できる社会
になる。
ここに、
単なるProject単位の効率化を越えた意味がある。
⸻
第2章で見てきたのは、
時間を短くする技術ではない。
時間を見分ける方法である。
予測する時間。
制度を整える時間。
Technologyを育てる時間。
文明を継承し更新する時間。
Realityへ実装する時間。
それぞれを理解し、
未来から適切な位置へ配置する。
⸻
最小にまとめれば、
未来実装時間を短縮する方法は、
一つの原則へ収束する。
必要な時間は削らない。
不要な待ち時間を削る。
そして、
もう一つ。
時間のかかるものほど、未来から早く現在へ引く。
この二つが成立したとき、
時間はただ流れるものではなくなる。
時間そのものが、
設計対象になる。
そして日本は、
未来を待つ社会から、
未来までの時間を自ら設計する社会
へ移ることができるのである。
愛と敬意を込めてmandala
