2021/10/30
参加者：安藤正雄、平野吉信、小笠原正豊、蟹澤宏剛、志手一哉
日時：10月30日（土）16時00分〜
オンライン開催

Progressive Design - Buildについて簡単にお話します。プログレッシブデザインビルドというアメリカで流行している調達方式の話で、発注者と一緒に少しずつで設計を進めていこうというタイプのデザインビルドで、これまでのものとは全く異なっています。設計ができない段階で契約をするということでは日本の設計施工一貫とも似ており、5年か7年ぐらい前に見たときに何か関係があるのかなということで興味を引かれました。IPDとほとんど同様の位置づけです。BIM IPDというのが特にデザインビルドに近いものがあり、そういう意味でIPDと PDBは非常に似ているということでその辺りをお話したいと思っています。デザインビルドの位置づけも当然変わるが、対立から協調へということで、これは早いところで言うと1990年代ぐらいからはっきりしてきたことだと思いますが、一種のパラダイムシフトで、不可逆的にこうした発注方式の方が生産的であって前向きだというふうに徐々に理解されているように思われます。それはIPDも一緒で、BIMとも深く関連していて、PDBもそういうものの一つだという風に理解できることもあるかと思います。最後には、日本型DBとPDBの何が違うのか、これについてもお話したいと思っています。

まず、変わるDB、揺らぐDBBへの信認ということで、デザインビルドというのはもはや不確実性の少ない定型的なプロジェクト、小規模のプロジェクトにのみ適用されるものではないということ。これははっきりしたと思います。より複雑で難しいプロジェクトにDBが適用されているということです。それからDB方式における設計行為はもはやデザインビルダーの専権事項ではないということであり、Bridging DB、Novated DB、Progressive DBこれらのコラボレーションとなります。なので、DBBは一番リスクが高いというふうにみなされるようになってきているということです。これは、特に日本の設計業界の人とかはまったく気づいてなかったと思います。そのような共通理解が成立していると、これは対立的よりもコラボラティブの方がはるかに多くのことをもたらすというふうにみんなが理解しているということになると思います。

調達方式の歴史的発展と受発注者のリスク負担を図２のように書いてみました。古い形の大きな建築は直営で行われていました。クライアントとアーキテクト/CMの分離はしていなく、Muster BuilderあるいはGreat Surveyorです。それは発注者に変わって数量を出して、その資材を調達する。数量を知るということは、設計しなきゃいけないということです。これは同一者で、棟梁と直営の形をしています（赤枠部分）。それが歴史的に見ると請負のような形も出てきます。しかしこれがある時期、これは19世紀前半にイギリス次いでアメリカ等では、近代的建築家が成立しまし。そして設計と施工の分離ということが図られて、これはDBBである。なので、このような歴史的系をたどりながら来て、その近代の制度としてはここから始まります。1970年60年代、Pure CMというのが出てきて、直営がクライアントの責任においてなし難いときにはCMという専門家を雇い、そして建築家も雇ってこのような形で、リスクの所在をはっきりさせるという方式に変わっていく。一方、近代的デザインビルドというのは、建築家協会が了解するという意味では 民間で行われているけれども、もう少し新しくて1990年くらいから始まっていくようなデザインビルドに変化してきているという認識です。これは発注者の責任やリスクは左側が大きく、逆に請負側の責任が大きいというのはこういう絵柄になっています。後に説明するが、図３のような整理をしておきます。 

パラダイムシフト以前の了解としては、デザインビルド、Pure CM、リスク分担は対極的であり図３のような並びをしています。 DBは受注者リスクが高く、Pure CMは、発注者リスクが高い。ただ日本のDB（設計施工一貫）は、そういうものとは無関係に成立してきたと今までの研究で強調してきました。（図４） イギリスに限って話すと、パートナリングからBIMへと向かうという施策が一貫しています。（図５）

DBは盛んになっていると言われていますが、その統計はDesign - Build Utilization – Combined Market Study, FMI/DBIA, 2018/06という報告書があります。これは、DBIAがFMIというコンサルタント会社に発注をして、DBのシェアがどうなっているかということに関する報告書です。

要約すると、2010年代には既に伝統的なDBBは主要な調達方式の座を失い、代わってDBが首位、CMGC/CMARが第２位に浮上し、そのシェアを伸ばしている。セグメント別に見た場合、DBによる投資額が多いのは工場16％、教育施設15%、道路14%、商業施設13%、オフィス12%の順。プロジェクト規模が大きくなればなるほどDBが採用される割合が高くなるとも書かれています。パーセンテージについては、住宅除かれています。推定方法に関しては、まず、U.S. Census等の実績値、および各地域の人口推計、成長率等の経済指標の予測値を用いてQuantitative Market Modelが作成されます。それからヒアリングなどで集めた情報を修正して図７を提案しています。 どういうタイプのものにDBが適用されているかということに関して図８のようなグラフがあります。

DBの中でのProgressive Design – Buildということについて、出現したのは2010年代前半に上下水道事業セクターで採用されました。それから2016年以降トランスポーテーションセクターが続いて建築分野の実施例も多く出てきたということですが、出現はインフラ関係でした。上下水道セクターでこれが採用された第一の理由は協働の高いレベルであってこれによって発注者はインプットとコントロールを最大化できます。一方、DBr、SC、ベンダーにはイノベーションを生み出したのに最適な環境が保証され、これでより良い結果が達成できるということです。なぜ上下水道だったかということに関しては、上下水道のプロジェクトは比較的複雑であると同時に道路や高層建築などのプロジェクトにみられるような繰り返し性もないとされます。このことから、PDBはより複雑でリスクの高いプロジェクトに適当な方式として確立されたことがわかるということです。そういう意味でPDBは、予言可能な建築に適用されるのではなく、より複雑でリスクの高いプロジェクトに適切だとみなされたということです。前者は、日本型のDBと類似しています。
PDBのプロセスに関して、オーナーとデザインビルダーは、選定された後、QBSプロジェクトのお金ではなく、能力資質だけの評価で選定されたPDBrは、次にオーナーと一緒になってターゲットプライスの設定に着手するということです。ここが、ランプサムによる競争入札との決定的な違いであり、日本型のDBに類似しています。

フェーズⅠは、Preliminary/Preconstruction Serviceというような呼ばれ方をしており、モノとしての設計を行い、数量を出して、プレコンストラクションサービスをしながら、GMPの設定のネゴをこのフェーズⅠで行うということです。フェーズⅡはファイナルデザインと実際の建設をやるということなので、実施設計と施工をします。これはアメリカのDBIAというデザインビルダーの協会が出しているPDBの解説書から引用しているのですが、オーナー側はここではRFQを行う。要するにクオリフィケーションの提出を求めるという作業をやって審査して選定します。選定されたらフェーズⅠになり、DBまで終わると次に実施設計となってきます。DBrの仕事は戦略をつくったりあるいはその応札の準備をするというのがフェーズⅠ以前の仕事になります。（図９） もう１つ別の文献からどういうプロセスかというのをみたもので、似ておりオーナーも含めて設定があるということですが、PDBrはオーナーへの協力、スコープの決定をこれフェーズ1で行って次は実施設計と施工を行います。チームの中のPricing/Buyoutの部分でサブコン、サプライヤー等を決めて値段を設定します。チームの中に主要な専門業者がBuyoutされて入ってきます。設計が30%、これはSDが終わる段階だということだと思います。SDが終わるまでにサブコンとかを決めて、DBを行います。そして、60%に達したらGMPを設定して合意したのちに、フェーズ２の契約に進むということを図10で表しています。

今回の文献では60%でDBを終えるまででしたが、もう少し後で行うと書いてある文献もあります。図11は、縦軸に発注方式、横軸に長所、短所をまとめたものです。ある文献から抽出し、それをAppendix A（図12）にまとめた。比較するとほとんどの調達方式は、利点もあれば欠点もあるのですが、DBBは欠点が多いとみなされています。一方で、PDBは、利点が多いと書かれています。

DBB方式の利点、欠点をみると、オーナー・サイドによる設計のインプット、建築を代理人と考えたコントロールが大きいが、価格の不透明性、オーナーがリスクの多くを負ってしまい、コントラクターの設計を利用できない、チェンジ・オーダーと工期遅延の問題があります。それから最も対立的な関係であり、それが多くの阻害の要因となっています。また、設計に際して設計者と施工者の協働は皆無であり対立的で、コラボラティブではないです。一方、PDBは設計未着手時のQBRによるPDBrの選定ということが欠点ではあります。その結果として最終コストの不確定性があるはずだが、GMPとオープンブックにより、それは克服可能とされ、最も協調的な様々なメリットがもたらされると書いてあります。その良し悪しというようなものを他の調達方式にも敷衍して、IPDと日本型DBを加えて比較したものが、Appendix B（図13）です。
オーナーによる設計インプット大小は、Pure CM＞DBB＞DB Bridging ＞CM at Risk＞ DBとなっています。
コストおよびSpearin Doctrine Liabilityに関するオーナー・リスクの大小も設計インプットの大小に比例しています。これに対して、発注者要求の満足に関するリスクは、オーナーの設計インプットが小さいほど大きいです。PDBおよびIPDでは、オーナーの設計インプットが大きいにもかかわらず、オーナーリスクは最小に保たれます。GC、SCのインプットも大きく、リスクは小さいです。Liabilityに関するオーナー・リスクの大小も設計インプットの大小に比例しています。
日本型DB（設計施工一貫方式）は、見かけ上はDBと同じであるが、対象プロジェクトの規模、難度が大きく、転嫁されたリスクが顕在しないという違いがあります。

この評価をするときには、オーナーの設計へのインプットを重視してGC選定、SC選定など様々あるが、ここでは設計に限定すると、およそ30%、60%、100%はそれぞれSD、DD、CDに概ね相当するところで、どのあたりでどの程度オーナーからのインプットがあり得るのかということです。コントロールについては、プロジェクト・プロセスへの関与の度合いを総合的に判定となります。リスクについては、いろいろあるがここではコスト、発注サイドが負う設計瑕疵(Spearin Doctrine Liabilities)、発注者要求の実現に絞り、それぞれC、SD、OSと表記してAppendix Bでは評価しています。Spearin Doctrine Liabilitiesというのは、簡単にいうと発注者側が設計者に頼めばいいが、用意した設計図書、仕様書に書かれている通りにコントラクターが施工した場合には設計に由来する瑕疵は、発注者側にあり施工者が問われることはないという判例に基づいた原則です。そしてそれは、瑕疵や工期遅延に結びつくような訴訟やdisputeの原因になり、これが大きく欧米では対立的ということで問題になっています。それをSpearin Doctrine Liabilitiesを特に注意して表現しています。

“対立(adversarial)”から”協調(collaborative)”へということが既にAppendix Bからは示唆されています。Pure CMは直営の現代版です。DBBは、設計施工分離で伝統型とされているが、近代制度の中での伝統という意味合いです。DBはもともとアーキテクトとコントラクターのコラボラティブです。PDBやIPDは、発注者も含めたコラボレーションの形になっており、アライアンス型です。一方、DBBのみに着目し、DB Bridgingでは、A1はSDを行う建築家、A2は実施設計行う建築家です。A2の建築家はGCとデザインビルドしておりコラボラティブであるが、A1とGCは全くコラボレーションがないので不完全です。CM at Riskは、PCS Design Assistという形で設計、施工間でコラボレーションするという新しい形です。要するに、DBBがなくなり、CM at Riskか発展系のDB（PDB、IPD）を含み、旧来のもののみでの説明は不可能となってきています。一例になりますが、SD、DD、CDにほぼ対応していて、PDBやIPDはSDで主に発注者側が用意するといった形です。 Validation Study (VS)は、請負というよりは橙色で行っていることを示しています。VSをして、ターゲットプライスを設定しない限り、チームに関しても目標戦略が持てないということです。PDBとIPDはほとんど一緒の価値あるいは、形を持っているということを図13のPDBとIPDの部分で表しています。CM at RiskもGMPを設定するので、ある段階からはDesign to Budgetが保証されているが、PDBやIPDのように当初からターゲットプライスがある形ではないです。そういう意味で、CM at RiskもIPD,ishであり、一般にアライアンス型の受発注方式とはIPD,ishと総称して良いと思います。日本型のDBとPDBの違いですが、発注者は自分の詳細な要求や介入することはなく、PDBとは違う形になっています。（発注者のインプットが日本型DBでは存在しない。）

ここからは補足となります。ワン・チームは、成長市場でないと日本では成立しなくて、縮小市場ではチームが分解する方向にしか向かないと問題視しています。補足資料図1の横軸は、伝統的（直営及びDBB）と比較的新しいDB型を分ける意図に従ったものです。しかし、配列は、adversarialからcollaborativeへというパラダイムシフト以前のオーナー・リスクの大小(Pure CM>DBB>DB)に対応していることから、「オーナー・リスクのマグニチュード」を表す軸と解釈することもできます。
本プレゼンテーションでは、オーナーの設計へのインプットから、コントロール、リスク負担という観点から各種プロジェクト方式を比較評価しました。設計へのインプットに関しては、受発注者のインプット比率の計量的評価が有効であることは示し得たが、今後はunilateral（一方的/片務的）な関係を超えたcollateralな関係の評価が必要となると考えます。コントロールについてはより厳密な定義が必要であるが、同様にcollateralな関係の評価が不可欠です。また、Collateralな関係は「アカウンタビィティ」という新たな評価の観点につながると思われます。

専門工事業者の果たす役割が非常に多くなってきたということを念頭に置いて、特にSCまたはSPなど専門工事業者の能力を活かしたプロジェクト運営がどうなのか、設計プロセスにサブコン、専門工事業者のノウハウを入れる仕組みがどうすればうまくできるようになるのかという視点で整理しました。

目的
・建築プロジェクト運営の合理化（効果率（時間、費用等）、質の向上、対立関係の軽減等）に資するため
具体的には、、、
① 施工性、調達市場の動向等も反映させた、より適切な設計及び施工計画の早期確立（及び工事を含めたプロジェクト費用の確定性のUP）
② プロジェクトの質（機能の実現、顧客満足の増大等を含む）、時間、費用等の合理化に資する、サブシステム（部位・部品等）レベルの設計の最適化
③ その他・・設計・工事計画等の早期確立による、工事段階の手戻り（RFI、再設計、契約変更等）の発生の低減

なぜ、DBBがアメリカやイギリスで非常に効率が悪いのかと言うと、工事段階でRFI、設計のところでわからない部分をクリアにして欲しいということなど、明確化要求が出てくる。それに応えていると、設計をやり直す必要性や契約変更に繋がりプラスのお金がかかる。それが、アメリカ、イギリスの伝統的なDBBの欠点であり、日本でもそうであるのかというとそうとも言い切れないので、その辺りをどう解釈するのかが今後の課題となってくると思います。

検討内容
・我が国における「設計プロセスへの施工関係主体の協働的参画」は、工事契約段階又は契約後の施工者によるVEの提供や詳細設計の提供。また、設計プロセスにおける設計チームへの関係情報の提供について。
・それ故、社会制度や産業構造、実務慣行等の差異は念頭に置いたうえで、英・米等において先行して提案され実践され始めている。”フォーマル”なしくみのメカニズムを抽出し、将来的な我が国でのしくみ構築の”参考情報”として抽出・検討。

社会的システムが違うので必ずしもアメリカでやっていることが日本ですぐやるとはなりませんが、今後の日本での良いやり方あるいは日本の伝統的なやり方の隠れたいい部分を見つけていく上で参考になればと思い、整理しているところです。

検討内容に関して、「施工主体の協働的参画」は色々な形態があるので本日は２つのパターンについて話します。１つ目は、工事段階前において、設計チームに対して、施工関係主体から、設計の合理性の向上に有益な情報を提供、支援することで設計の完成度、合理性を向上させることです。いわゆる、Design Assistについてです。Design Assistは、サブコンレベルのノウハウを設計チームに提供すると理解して頂ければ混乱が少ないと思います。2つ目は、大きな意味ではDesign Assistの中に含まれると思いますが、少しニュアンスが異なり、設計チームが全体設計や構造設計を行い、梁や柱など必要な性能を導きだし、その全体設計によって”割り当てられた”特定のサブシステムに対する要求事項に従って、施工関係主体が当該サブシステムについてDBベースでプロジェクトに参加し、詳細設計を担当して設計チームに提案するということです。これについても、以下の２通りがあります。
①工事段階でコントラクターやサブコンによって詳細設計が実施される場合。アメリカではDelegated Design、イギリスではContractor's Design Portion(CDP)と呼ばれるもの。
②プレコンストラクション段階でDelegated Designが行われている場合。
最近では、②のパターンが増えてきているようなので本日がこの辺りにもフィーチャーします。

CM at Riskは、必ずしもサブコンの参加を想定しているわけではないです。日本でいうと、ゼネコンレベルのノウハウを設計に活かすというのがあります。コントラクターがマネジメントに特化した能力を持っていることを前提になるので、例えば、Buildability Issuesやコスト見積もりや工程計画などサブコンの力を借りることになると思うが、こういうことが古典的なCM at Riskの契約形態です。（ここでは、必ずしも専門工事会社レベルがプレコンストラクションサービスをするという形にはなっていません。）それを明示的にやりましょうと行ったのがおそらくアメリカでは初めてのものだと思いますが、Consensus Doc（CD541）という文書です。サブコンレベルがCMを介して、プレコンストラクションサービスをやります。大事なことはDesign Assistを行うサブコンが2種類あり、ここではDesign - Assist SC、Design – Build SCという言い方をしています。今日の発表の中でこの2通りの役割、情報提供をするDesign - Assist SC（DA - SC）と詳細設計も補うDesign – Build  SC（DB - SC） があります。

本日は、CM at Risk型の２通りのサブコンがプレコンサービスを行うパターンを考えて、議論していきたいと思います。Mission Bayの実施例のデータを部分的に集めてきました 。（図15）ClarkがCM at Riskとしてプレコンサービスを行うサブコンを募集するという内容です。QBSとお金を合わせた総合評価方式で選定をしています。

CM at Risk体制の下での、サブコンによるDesign Assist等のプレコンストラクションサービスを組み込んだプロジェクト運営を「Design Assist型プロジェクト運営」と総称します。

Design Assist型プロジェクト運営の期待効用・目的として、まず原理は、プロジェクトの設計プロセスに、施工主体が持つ技術・知識・経験等をインプットすることによって、設計の早期の具体化を図り、それによってプロジェクト運営の質・費用・時間等の確保・向上を実現することです。具体的には、工事段階でのRFI、設計、契約変更等の低減、工事価格の早期把握、確立、要求適合性の向上等です。次に、Design Assistによる設計プロセスにインプットされる情報内容の例として以下が挙げられます。
・設計チームのレビュー
・バリューアナリシス、代替案提案
・特定の部分についての詳細設計の実施、提供（＊）
・施工可能性Constructabilityのレビュー、改善策提案
・設計の進展に応じた工事費見積もりの提供、最終価格の提案
・スケジュール、工期の提案
・関係する許認可の取得の支援
・資材等の選考調達
・BIM
・敷地条件に関する諸問題
・維持管理、ライフサイクル関係等
＊この機能を提供するSC=「Design - Build SC(DB-SC)」：プレコンストラクション段階で、担当サブシステムについてのDelegate Designを担当し、その後の工事も担当するSC。

Delegated Designとなる場合のトレードにどういうものがあるのかということについて、プレキャストコンクリートなどコンポーネント化されるものが多いです。オフサイトが増えてくるとより増えてくると思います。日本でも同じことが言えると思いますので、サブコンまたは製造側に蓄積されているノウハウをどのように設計に使用していくのか重要な話です。それをただの設計協力と言わずに良い仕組みを作る必要があると思います。

Design Assist型プロジェクト運営における弱点・課題として、①設計に関する役割・責任の”複雑さ”への対処、②法令上の設計責任とライセンス問題、③設計プロセスの高度なマネジメントの必要性、④参画主体の選定における”競争性”の希薄から「協働」のMindset獲得の必要性が挙げられます。２つ目の法令上の設計責任という問題があって、これは日本もアメリカもDBBをモデルとした責任体制で作っています。設計は設計者がやり、施工者は設計をしないということが前提になっていて各州のビルディングコードやライセンスができ、違う状態が出てきてそれをどうするのかという話です。 

Design Assist型プロジェクト運営の弱点・課題にどのように対処するのかということについて話していきます。図16はコラボラティブなデザインをしていく時に設計者とCM/GCと契約関係がなく、サブコンとも契約関係はない。役割分担などコントロールするために、参加者全員が入ったMulti Party Agreementを行うことです。これがIPDそのものです。ただ、直接これを行うのが難しい人が多くいるので、擬似的なMulti Party Agreementを作るためにオーナー、設計者、CM/GCの3者の関係を追加し、3者の合意をもとにサブコンをコントロールするためにAddendum（DC541）が必要となってきます。発注者と設計者の契約に付け加え、擬似的な3者契約的な効果をもたらしつつ、その合意をもってサブコンのコントロールができます。これをIPDishと呼んでいます。図16の解①aその2の青点線で囲んでいる部分に関して、オーナーの部分にデザインビルダーを入れるとデザインビルド組織になります。外にオーナーを出すと、デザインビルド組織の中で同じことができます。したがって、IPDishは、CM at Riskでもでき、DBでもできるという言い方をしています。あくまで、アメリカ、イギリスのDBで言えることだと思います。日本の産業構造では、もしかしたらできていることかもしれませんが透明性に欠けるので今後の課題だと思います。複雑さへの対処として、大きく分けて情報提供型と詳細設計型の2通りあります。設計チームは全体の設計をおこない各部分に付いている性能要求、必要な寸法などの設計条件を施工チーム側に出して、施工チームとしてサブコンが詳細設計をおこない、それを設計チームに返して全体の設計と整合することなどを確かめ、全体の設計図書として責任を持って提出し許可を得る仕組みです。どうすればそういう複雑な役割関係を規定できるのかが課題となってきます。これはResponsibility Matrixを作っていくしかないが、どういう様式でやればいいのかまだわかりません。
設計の役割分担の話と非常に似て非なるものが、BIM Element Model Table です。図17は、アメリカのBIM Forumが出しているパターンです。LODを決めて誰がモデルを作るかということを書いてきたという話ですが、モデルを作るという話と設計をやるという話は必ずしも一致しません。モデルを作るイコール設計ではなくて、あくまでもデザイナーが作った設計のモデルを忠実に施工者がつくるということもあり得るので、この辺りの違いをどうしたらいいのか志手先生に教えていただきたく、今後重要なテーマになると思います。私はあくまでも設計の役割分担、それはエレメントごとにいくのかタスクごとにいくのかわかりませんが考えていきたいです。

安藤：図20はモノになっていますか。

小笠原：そうです。ただ、SDと DBでどこまで詳細が異なるのか難しいところではあるかと思います。CDだと図21。より書き込みが細かくなっていて、ユニークなコンディションが説明されているなどといったことになるとは思いますが、何がモノになっていて、なっていないのか難しいなと思っていました。

志手：小笠原先生が共有してくださった図面を見ていて僕が担当していたプロジェクトでは、CDが実施設計のレベルに非常に近い書き込みの内容で、SDが基本設計に入る前くらいの書き込みでした。DDだと基本設計より少し進んだレベルだというイメージを持って見ていました。

小笠原：CDの場合、これらの図面は一般図なので非常に詳細図が増えると思います。

志手：そうです。部分詳細や日本で言うと矩計図など、日本の場合、これらの図面以上になると施工図、製作図になってしまうと思います。

安藤：CDに関していうと、平野先生の今日の発表の中のCDPのようなものが加わってくるので実際には設計事務所のCDでは済まない話ですか。

平野：そうです。基本的にはCDレベルのものをコントラクターに作ってもらうことがCDPです。ただし、日本でいう実施設計レベルを超えてしまい施工図レベルまでいってしまう可能性があります。そうするとショップドローイングとの区別がなかなかつかないです。

安藤：基本設計の概念を日本でもう少しきちんと整理しないと先に進まない気がしています。

志手先生：アメリカが変遷して辿ってきた部分は、既に日本は定着してしまっているものがあるのではないかと感じており、アメリカ、イギリスをみてきて定式化させようとしていますが、日本も定式化をしていく時期になったような気がしています。

安藤：そうだと思います。ただ、アカウンタブルな部分が決定的に違うと思います。

志手：そのあたりが問題になってくるのが公共工事です。公共工事でデザインビルドをやろうとする機運が数年で高まってはきています。しかし、県庁とかになると議会で承認を得ないといけなくなってきて、そこのアカウンタビリティをどうするのかという時にオープンブックにしないといけないなどの話が出ているみたいです。

安藤：公共のことに関しては２つのことがあると思います。１つが議会を通すための予算の妥当性の話だと、SDレベルでの積算ができるような、モノ化する前の積算の妥当性。それから発注者と受注者の両方にコストエンジニアがいるかどうかという社会システムの定着の度合いが問題だと思います。もう１つオープンブックの問題は、GMPみたいなものが日本でできるのかという話です。オープンブックがどういう意味を持っているのかという話をしないといけないことだと思います。

志手：その事例として、愛知県の中部国際空港にある国際展示場の事例ではGMPは設定したみたいです。議会の承認で、一回通した予算を変更するのが難しく、そこが問題だったみたいです。GMPの設定で、プロジェクトはデザインビルドだが、基本設計と実施設計以降を２回に分けて、２段階契約をしたみたいです。そうしないと基本設計は一度業務委託で出して、それをもって優先交渉権付きで実施設計の請負契約の入札をするということをして、その際にGMPの設定もすることで擬似的にランプサムと同じような状態にしたみたいです。

安藤：私はGMP、ランプサムみたいな時に不確実性の高いところをターゲットにして、部分的にでも良いので何かGMPみたいなものをするのなら良いと思います。

平野：GMP、先ほどの変更の話も含めて、GSAについて調べていたことがあり、変更はほとんどコストプラスのやり方でしかやれない。関係者が納得できる内訳を作れるかどうかという問題ではないですか。

安藤：特定のサブシステムみたいなものにGMPを設定することがリアリスティックだと思います。その分については、数量も確実でそこだけオープンブック的に扱っても不思議ではないと思います。

平野：それは適当な粒度で内訳をつくることができ、その根拠が添えられているのがオープンブックですよね。その中でサブコンは、内訳まで入ると大変なのでサブコンとの契約をコストとして扱いましょうという約束のもとで内訳書をつくります。

安藤：それは在来の工事ですか。難しい新規のプロジェクトとは分けて考えた方がいいと思います。

平野：いずれにしても内訳書がある程度信頼がある形で作れるかどうかだと思います。

志手：イノベーティブなものでなければある程度過程で概算みたいなものはできると思いますけど、難しいのはファサードとかになると思います。

平野：在工にプロフィットが隠れているので非常に難しいところになると思います。プロフィットを外出しできるような仕組みを考える必要があると思います。

安藤：例えば今の話は在来的なもののところをどうするかという話とユニークなモノをどう扱うかという話を分ける必要があると思います。

志手：そう思います。よくアメリカとかでもスペシャルコンサルタント、スペコン、トラディショナルサブコンとかそのような言い方をしませんか。

小笠原：あるかもしれないです。

小笠原：実際にゼネコンでオープンブックって可能ですか。

志手：ランプサムで請け負っていなければ可能です。オープンブックなので3社以上の入札をすることが前提になります。契約書と支払いの通帳まで全部オープンにするという話でした。

小笠原：例えば、海外のクライアントが日本のゼネコンに日本でのプロジェクトでオープンブックにしたいとなった場合、二重に作らないといけないという話を聞いたことがあるので、必ずしもクリアにできる体制が本当に可能なのかというのがわからないと思っています。

志手：手間さえかければ可能というのが答えになります。発注者もゼネコンも普通のやり方に比べると手間がかかります。

小笠原：事例が拡がってくれば何か変わってくる可能性もあるのですか。

志手：僕の希望にはなりますが、そういうのが拡まってきてようやくBIMが発展するのかなと思います。特にECとかやろうとしている方々の話はオープンブックが前提になって拡がる話だと思っています。

平野：それを日本的社会で共通に納得できる内訳の作り方ができれば可能になるのではないですか。

安藤：オープンブックがゼネコンにもメリットのある環境があり得るわけですよね。なので、Pure CMが出てきたときはそういう時で、ゼネコンが請けるにはあまりにもリスクが大きいので分離発注にするという話ですか。

平野：アメリカのやり方だと、サブコンの契約価格、ランプサムをパッケージの正当な価格としてみなしてゼネコンのアカウントをつくります。3社入札をしてあるサブコンに決めたらその価格をコストとしてみなして良いというどこで見切るのかという話になると思っています。

志手：ケーススタディが少ないことが要因の１つだと思います。それが増えてくると、こういう環境が必要だということやどのようなやり方が良いかという議論が出来てくると思います。

平野：ゼネコンの予算内でやることでサブコンに無理をさせてしまう状態の中ではなかなか難しいと思います。

志手：そこはランプサムを変えないといけないと思います。

安藤：PDBの文献を見ていると、スペシャルティコントラクターを先に指名して契約しますが、それは州法によって異なるのでどうするか検討するようなことが書いてあります。

志手：日本で再開発など大きいプロジェクトになると設計要件を決めていく段階でいかに大手の設計事務所やゼネコンが絡んでいくのか、どういう発注要件を出してもらうのかという点が勝負になっている気がします。

平野：設計要件とはどういう意味ですか。

志手：例えば、あるプロジェクト、再開発をやる時に事業制検討のところに既にゼネコンや設計事務所が入って事業制検討、企画の部分をおこいます。デザインを有名な建築家に発注し、全体契約を設計事務所に、実施設計はゼネコンにやってもらうというようなスキームを作ってから設計に入っていく。そういう意味で大きいプロジェクトには、デザインチームみたいなものができるというのがよくあるパターンではないかと思っています。

志手：日本のやり方も整理していかないといけないと思っています。

平野：志手先生、Responsibility MatrixとModel Element Tableの違いで何か提案はありませんか。詳細設計をコントラクターでする話とモデルをつくるという話はだいぶ違うと思います。

志手：あくまでModel Element Tableはモデルをつくる部分の話なので違う気もします。一方で、アメリカの設計事務所とかはAutoCADからRevitに切り替えているという話になってくると、それはエレメントテーブルが設計の分担表と言っても強ち間違いではないかと思っています。

平野：ライアビリティが絡む時に、特にアメリカでは多分大問題になると思います。イギリスでは設計の独占業務がないですが、アメリカでは厳しいと思います。

小笠原：アメリカの組織設計事務所の方の話を聞くと、Model Element Tableが分業の状況を示す１つの契約的なものになるのではないかと思います。それをスペシャリストコントラクターやサブコンが前乗りして情報を提供するのであれば、製造、制作の状況を見越した状態でライアビリティを持った形で情報を提供していると思います。そこで問題になるのが各パーツのすり合わせ、インターフェースの部分で誰が責任を持っているのかという部分がややこしいところになると思います。20年前、監理として分離発注のプロジェクトをやっていた時に、パッケージを作って必ず渡すことをエントリーレベルで手伝っていました。カーテンウォールなど様々なパッケージを作る中で、最後にジェネレラルコンストラクションという残り全部のようなパッケージを作らないといけなかったです。それが一番大変だったような気がします。モデュラーで漏れてしまう部分を拾っていかないといけない作業でした。