従来の取り組みと異なる点として、住宅局が主導してやっているということです。また、民間団体（建設業に関わるような）がほとんどで議論しています。これは、今まで日本であまりなかったことではないかと思っています。ビジョンは、「いいものが、無駄なく、速く、建物にも、データにも価値が」というキャッチフレーズでやっていますが、要するにスマートシティ等にもBIMが絡んでいくということを見据えたものになっています。現在は、図　の緑色の部分をディスカッションしている段階です。

ワークフローのガイドラインの中でも、2020年3月に公開したもの（図5）で、今年度末に第2版を後悔するために改訂作業中です。このガイドラインで一番の重要なポイントは、ステージを決めたということだと思っています。日本では設計の段階が１つ少なく、グローバルなものに合わせるために設計の段階を１つ増やしました。実施設計の部分を前半と後半の２つに分けました。これに関しては、いろいろな取り方ができますが、例えば、デザインビルド的な考え方やアットCMの考え方でいくと、実施設計1の前半の状態で確認申請まで通し、その後、生産設計を行い、設計精度を上げて設計を完成させていくという考え方もできます。各々の発注方式によって実施設計1と実施設計2にどういう役割を与えていくのかというのが柔軟に考えることができるのではないかと思っています。

引き渡しのフェーズでは、建物を引き渡すというよりは建物情報のデータを引き渡すステージになっていますので、ここでの業務もきちんと決めて対価をもらえるような契約をしていくことに将来は繋げていこうと話していたりもします。Plan of Workと同じようにステージ分けをしたことがこのガイドラインの一番のポイントだと思っています。

図6は、ワークフローがいろんなパターンがありますということをガイドラインでは書かれています。パターンが1~5まであり、1と2は設計施工分離、３はECI、4はデザインビルド、5はアメリカ的なアットリスクCMに近いような考え方でプレコンストラクションなどが入ってくるようなやり方だと捉えることもできますが、国土交通省が発行しているものなので少しぼやかした書き方をしていると捉えた方が分かりやすいと思います。

それぞれのパターンで、図5のステージにおいて誰がどこで入ってくるのか、どのような責任になるのかということを決めていくことが本来のやり方だと思います。

ただ、現状のワークフローではそこまでは言い切っていない感じだと思います。

ワークフローを実践していくためのモデル事業を2020年度と2021年度で合計41件選定してやりました。先導事業者型（７件）は予算が付いて採択されたものです。パートナー事業者型（5件）ではそれぞれの企業で予算を用意するがBIM推進会議の冠の下で行ったものです。それから、中小事業者BIM試行型（9件）という枠を作り、地方の方が取り組んだものです。

このようなものが41件動いていたり、完了したものがあります。これらの内容や取り組みや報告書が全てホームページで公開されています。これは日本にとって重要なことではないかと思っています。

去年のプロジェクトを見るとワークフローの中でどこかに偏っているわけではなく、全般的に分かれて取り組んでいただき、ワークフローを部分的に各々の立場でやっていただいたという状態になっています。それらの効果がどのようにあったのか報告書に書かれています。

次に、ガイドライン第2版に向けて、以下のことを反映するように改定しています。

今回の改訂で議論を行い反映するもの（案）

1.発注者メリットと発注者の役割

2.データの受け渡しの方法

3.BEP/EIR

4.各ステージの業務内容と成果物

5.標準ワークフローのパターン

6.維持管理BIMの作成方法

7.ライフサイクルコスティング

8.各部会等の取組

先ほどから話しているガイドラインが図7の１つ目の黄色の枠の部分で、国土交通省が出しているものです。これに対して、サポートするようなそれぞれの立場のガイドラインのようなものが次から次へと出てきています。これが揃ってくると日本でも誰がBIMを実行しようとする時に参考すべき資料が整備される状況になっていくと思います。それを2年後にできるようBIM推進会議では動いている状態です。

分類体系とコストマネジメント

その中で分類体系とコストマネジメントをどのように考えていくのかということがあります。図8のようなデータを設計から施工にどのように繋いでいくのかということが非常に重要な論点になってくるのかというこれからの話をします。EIRのEの部分についてEmployer Information Requirementの発注者要求条件とExchange Information Requirementのデータ交換要求条件と２つの呼び方があります。ISOではExchange Information Requirementと呼んでいます。イギリスのガイドラインPASの中では、Employer Information Requirementと呼んでいます。おそらく、EmployerからExchangeへとEの意味が変わってきたのは、建物を運営していくことに対してデジタルトランスフォーメーションのような中でどのようなデータがどのような状態で必要なのかということが要求すべきです。それに対して、実行契約は受注者側である設計事務所やゼネコンは自分たちの業務が効率化されるためにBIMを使用し、その中から発注者から要求されているデータを抽出していくことがこれからのBIMのデータの流れになるのではないかと気がしています。

その中で、発注者が何を考えていくのかというとホールライフコスティングの話で、建物に関するデータなどがあちこちに入ってきます。それらの情報を設計や施工のところから引っ張ってこれるものは、要求していく。運営段階に入らないと出てこないデータもありますが、少なくともライフサイクルコストの部分で建物に関するデータを引っ張ってこれるところはいくつかあります。

図15の三角形の部分は設計から施工段階での情報が溜まっていき、運営段階にいくと電力や人の流れなど動的なデータが溜まっていきます。プロジェクトをやっていくときは、Project Information Modelling、運用段階ではAsset Information ModellingとISOの中では区切って話がされています。

図16の話は重要だと思っているのですが、BIMの話はデジタル情報だけでなくアナログ情報も含まれています。ステージが上がるにつれてデジタル情報が増え、それがデータベース化していくことが一番重要なポイントだと思います。ただ、この中にも図面や文章など情報化されない情報も残るので、それを排除するのではなくそれも含めてデータのマネジメントをすべきであるということがISOの主張しているところではないかと思います。

そう考えていくと、改めてBIMって何かというとCADかBIMか、CADからBIMへ移るのかといった話ではなく、CADも含めてBIMと考えた方がいいと思います。

例えば、納まり図などディテールとなる部分をBIMでは作れないのでCADで別に書いてもいいと思います。ただ、それがきちんとリンクされている情報をマネジメントしていくことが重要だと考えています。あるいは、BIMがデータベースだとしたらそれをどのようなビューで見せるのか、ビューで表現するという考え方が重要だと思います。データベース化されたものを3次元のビューで見せるのか、それとも2次元のビューで見せるのか、あるいは集計表のビューで見せるのかといった考え方になった方が良いと思っています。3次元のモデルに属性情報が付加されているからBIMという考え方が少し違うのではないかと思っています。ですが、建物の情報をどこかに入力しないといけませんので、BIMオーサリングツールというRevitのようなものに属性情報を入れていくのか、あるいはそれとリンクしたデータベースの中に入れていくのかこのような点も考え所です。また、共通化して共有したい情報というのは、１つのファイルに入れない方がいいかもしれないです。１つのファイルに入れてしまうと、このRevitファイルで設計から施工者に渡り、施工者はそのRevitファイルを開けないとできないというようなことになってしまう可能性があります。情報の相互運用性を考えた時にファイルベースよりデータベースの方に移っていくべきだと思います。

形状と属性情報は一体である必要があるのかといった話がだんだん分類体系の話に近づいてくるのですが、オブジェクトに付与できる属性情報は多くはないと思っています。IFCで決まっている属性情報や分類体系の番号を入れたとしても、結局仕様を定義していこうと思うとテキスト情報だけでそれはできないと思います。オーサリングツールで囲っている部分（図18）とそれとリンクするような形でクラウド上に情報をマネジメントする環境が必要になってくるのではないかと思います。IFCなど見ていると、そういう動きはありそうだと思っています。

図19は、フリーのIFCビューアというものです。IFCがRevitからArchiCADなど別のソフトにデータを受け渡すというようなフォーマットではなく、IFCそのものを活用するようなアドオンのプログラムがついているものがあります。Revit、ArchiCAD、Teklaなど様々なツールで入力した情報を全てIFCとして出して、統合していくと建物の情報を一元化することもおそらく可能になってくると思います。

属性項目の標準が決められています。例えばドアだと遮音などの情報が決められています。図20は、窓で国際標準として決められている項目があります。日本でも性能を考えていくときに有用なものが多く、ある意味で一部の確認申請をカバーできたり、要求水準を考えていく際にある程度カバーできると思います。これをベースとして不足分を考えていく方が本来は良いと思います。

プロパティセットでどういうものがあるのかというと、建築要素だけで24分類に分かれていて、設備や施工管理などさまざまなものがあります。（図21）24項目では足りなく、カテゴリをマッピングできても、中身までは変更できません。

カテゴリの不足しているものをどうすればいいのかという時に、分類体系が必要になってくると思います。(図22参照)

図23は、Plan of workとUniclass2015の関係を整理したものです。

システムとそのプロダクトの関係はどのように考えていくかというと、例えば、Uniclassを用いて国土交通省の交通公共表紙に書かれている防水工事の仕様をUniclassの番号で表現したものです。（図24）

防水工事の屋根保護防水密着断熱工法をシステムで定義します。そうするとアスファルト防水外断熱システムというのがあります。この中で出てくる工程をProductの番号で調べていくと、プライマー、ルーフィング、アスファルトや断熱シートがあったりしてUniclassの番号で置き換えることができます。図24の状態にすることでBIMから分類体系を使ってコストマネジメントできないだろうかと積算協会で行なっています。

分類体系だけでは全てできるわけではないので、仕様の部分が入っていないとコストに結びついていかないこともあります。（1:34:00）

例えば、窓（外壁の窓）にどのようなプロダクトが含まれているのか（図25青枠部分）に分かれています。これはあくまで部品の分類なので、どういう性能なのかIFCのデータ(図25赤枠部分)を引っ張ってこないとわからないです。この部分の話がなければ、ガラスが何ミリであるのかや単価などが結びついてこないので分類体系の番号だけでコストを出すというのは、難しいです。IFCのプロパティセットと分類体系の番号を組み合わせていかなければ単価を設定することはできないと考えています。

(図25)

IFCのプロパティセットと分類体系を組み合わせていかないとおそらく単価を設定することはできないと考えています。

さらに、このスライドで言いたいことで、「分類体系の番号を積算協会でしています」と話すと図26の緑の枠の部分の話と勘違いされることがあります。材料の１つ１つに番号をつけていると思われますが、そこは対象ではなく、あくまで分類をする部分です。材料や部位などが対象であると説明するためにこのスライドを入れています。

ただ、分類をどのように設定するかということは重要であり、先ほどの防水工事の場合ある材料分類のセット(図24)がこの防水断熱システムであるとか、セットの部分はきちんとしておかないといけないと思います。

セットは、図26の　枠の部分にあたると思います。複合単価から材料と労務に分かれる中で複合単価あたりの話というのはおそらくどのようなセットで構成されるかという部分に紐づいてくるかと思います。材料と労務に分かれた個々の情報、要するにプロダクトレベルの情報を各々の単価に紐づけられるかと思います。

単価が紐づけられるだけでは見積書として成立しません。成立させるために、部位別、工種別、部屋別ということに流れていくと思っています。

そのようなことを念頭に置きながら、積算協会では図28のような、あるモデルから出してきたデータに内訳書の構成をまずBIMのモデルに割り当て、そこにあてがうデータとして各オブジェクトに分類番号(Uniclassの番号)を入れてそれで出してきた項目と内訳書の項目をマッチングさせるような作業を通して、図29の表を整理していこうということが現在積算協会で行なっていることです。具体的には、図30のようなものです。

安藤先生：冒頭の部分で積算協会では、S2、S3を主に行なっているということでしたが、今話されている部分はちがいますよね。

志手先生：そうです。S2、S3を定義していくのに明細から逆流させないとよくわからないというのが現状です。段階的に上からやっていくよりは、もともとのUniclassの物事から考えて、それを上に逆流させていくことを行なっています。

安藤先生：それでもう少し抽象的なデータに還元できないかということですか。

志手先生：それができないかということが問題です。

安藤先生：S2、S3というのは要するに、システム以前のUniformat的な利用形態かと思いました。逆流というのは、先ほどのデータベースの話と関係してくると思いますが、それと一緒に整備をしながらS2、S3用のものを整備するが、それはシステム、プロダクトにならないといけないという感じですか。

志手先生：そうです。BIMのオブジェクト単位に単価がついていかないとBIMで見積もりするということにはならないと思います。今の積算の部分別、工種別ではそういう風にはなっておらず、部品に分解した状態から一度上にアグリーメントしていきながら、最終的にはそういうデータをどのように残していけば良いのかということに結びついてくるのではないかと思っています。また、内訳書やマネジメントできるよう再構成しないといけないと思いますが、masterformatやUniformat、日本の分類体系をマッピングさせるような形にしたら良いのかといった議論として出てきています。検討はまだできていません。イメージとしては、図31のような感じです。

ここからは研究室での話になりますが、プロダクトレベルに落としてきた情報にBELCAという修繕計画の分類のデータをマッピングして中長期修繕計画を作れるかどうかということを研究しています。それから図32は分類体系の状態でBIMのモデルを入れたものをforgeとかを使って自動的にシステムレベルまでデータベースを作れないかという研究です。３次元のビューと分類体系を使ったデータベースのビューと両方で見せることができないかということを検討しています。このようなものが揃ってくるとようやく分類体系を使ってコストマネジメントしていくことやそのデータをいろいろなところに応用していくことができるのではないかとやっています。