2022/01/22
参加者:安藤正雄、平野吉信、小笠原正豊、蟹澤宏剛、志手一哉
日時:01月22日(土)10時00分〜
オンライン開催
2022/01/22
参加者:安藤正雄、平野吉信、小笠原正豊、蟹澤宏剛、志手一哉
日時:01月22日(土)10時00分〜
オンライン開催
建築BIM推進会議が2019年に立ち上がって、以下4つのような役割をもって設置されました。
・立場を超えて意見を交換するラウンドテーブルの提供
・各団体で行っている検討を共有するプラットフォームの設置
・国際標準を意識したBIMワークフローとその共通言語を提示
・BIMモデル事業実施内容や標準資料の一元的な公開による公共財化
初めから国際標準を意識したBIMワークフローとその共通言語を整備するということを念頭に置きながらやってきています。
現時点の体制は、図 のようになっています。
従来の取り組みと異なる点として、住宅局が主導してやっているということです。また、民間団体(建設業に関わるような)がほとんどで議論しています。これは、今まで日本であまりなかったことではないかと思っています。ビジョンは、「いいものが、無駄なく、速く、建物にも、データにも価値が」というキャッチフレーズでやっていますが、要するにスマートシティ等にもBIMが絡んでいくということを見据えたものになっています。現在は、図 の緑色の部分をディスカッションしている段階です。
それを複数の団体に分かれ、課題を分担して民間主体で検討するようにしています。(図3)分類体系を検討しているのが部会4です。部会4に限らずいろいろなところで検討している内容を吸収していこうとしているのが建築BIM推進会議のスタンスです。検討内容は、ワークフロー、属性情報項目、建設分類体系の3つに大きく分けることができます。例えば、確認申請の話は属性情報項目の議論している内容に近いこともあるので部会2、部会3、部会5やbuildingSMART Japanなどでも属性情報項目に関して検討しています。(図4参照)
ワークフローのガイドラインの中でも、2020年3月に公開したもの(図5)で、今年度末に第2版を後悔するために改訂作業中です。このガイドラインで一番の重要なポイントは、ステージを決めたということだと思っています。日本では設計の段階が1つ少なく、グローバルなものに合わせるために設計の段階を1つ増やしました。実施設計の部分を前半と後半の2つに分けました。これに関しては、いろいろな取り方ができますが、例えば、デザインビルド的な考え方やアットCMの考え方でいくと、実施設計1の前半の状態で確認申請まで通し、その後、生産設計を行い、設計精度を上げて設計を完成させていくという考え方もできます。各々の発注方式によって実施設計1と実施設計2にどういう役割を与えていくのかというのが柔軟に考えることができるのではないかと思っています。
引き渡しのフェーズでは、建物を引き渡すというよりは建物情報のデータを引き渡すステージになっていますので、ここでの業務もきちんと決めて対価をもらえるような契約をしていくことに将来は繋げていこうと話していたりもします。Plan of Workと同じようにステージ分けをしたことがこのガイドラインの一番のポイントだと思っています。
図6は、ワークフローがいろんなパターンがありますということをガイドラインでは書かれています。パターンが1~5まであり、1と2は設計施工分離、3はECI、4はデザインビルド、5はアメリカ的なアットリスクCMに近いような考え方でプレコンストラクションなどが入ってくるようなやり方だと捉えることもできますが、国土交通省が発行しているものなので少しぼやかした書き方をしていると捉えた方が分かりやすいと思います。
それぞれのパターンで、図5のステージにおいて誰がどこで入ってくるのか、どのような責任になるのかということを決めていくことが本来のやり方だと思います。
ただ、現状のワークフローではそこまでは言い切っていない感じだと思います。
安藤:CIMとのすりあわせもしていますか。
志手:していないです。CIMは公共工事のみでの考え方ですので、この辺りは全く調整していないと思います。
安藤:いずれはしてほしいと思います。
志手:国土交通省の中では、将来的にそのような雰囲気はあるように思います。
ワークフローを実践していくためのモデル事業を2020年度と2021年度で合計41件選定してやりました。先導事業者型(7件)は予算が付いて採択されたものです。パートナー事業者型(5件)ではそれぞれの企業で予算を用意するがBIM推進会議の冠の下で行ったものです。それから、中小事業者BIM試行型(9件)という枠を作り、地方の方が取り組んだものです。
このようなものが41件動いていたり、完了したものがあります。これらの内容や取り組みや報告書が全てホームページで公開されています。これは日本にとって重要なことではないかと思っています。
去年のプロジェクトを見るとワークフローの中でどこかに偏っているわけではなく、全般的に分かれて取り組んでいただき、ワークフローを部分的に各々の立場でやっていただいたという状態になっています。それらの効果がどのようにあったのか報告書に書かれています。
次に、ガイドライン第2版に向けて、以下のことを反映するように改定しています。
今回の改訂で議論を行い反映するもの(案)
1.発注者メリットと発注者の役割
2.データの受け渡しの方法
3.BEP/EIR
4.各ステージの業務内容と成果物
5.標準ワークフローのパターン
6.維持管理BIMの作成方法
7.ライフサイクルコスティング
8.各部会等の取組
先ほどから話しているガイドラインが図7の1つ目の黄色の枠の部分で、国土交通省が出しているものです。これに対して、サポートするようなそれぞれの立場のガイドラインのようなものが次から次へと出てきています。これが揃ってくると日本でも誰がBIMを実行しようとする時に参考すべき資料が整備される状況になっていくと思います。それを2年後にできるようBIM推進会議では動いている状態です。
分類体系とコストマネジメント
その中で分類体系とコストマネジメントをどのように考えていくのかということがあります。図8のようなデータを設計から施工にどのように繋いでいくのかということが非常に重要な論点になってくるのかというこれからの話をします。EIRのEの部分についてEmployer Information Requirementの発注者要求条件とExchange Information Requirementのデータ交換要求条件と2つの呼び方があります。ISOではExchange Information Requirementと呼んでいます。イギリスのガイドラインPASの中では、Employer Information Requirementと呼んでいます。おそらく、EmployerからExchangeへとEの意味が変わってきたのは、建物を運営していくことに対してデジタルトランスフォーメーションのような中でどのようなデータがどのような状態で必要なのかということが要求すべきです。それに対して、実行契約は受注者側である設計事務所やゼネコンは自分たちの業務が効率化されるためにBIMを使用し、その中から発注者から要求されているデータを抽出していくことがこれからのBIMのデータの流れになるのではないかと気がしています。
その中で、発注者が何を考えていくのかというとホールライフコスティングの話で、建物に関するデータなどがあちこちに入ってきます。それらの情報を設計や施工のところから引っ張ってこれるものは、要求していく。運営段階に入らないと出てこないデータもありますが、少なくともライフサイクルコストの部分で建物に関するデータを引っ張ってこれるところはいくつかあります。
現在、積算協会で取り組んでいるのは、基本設計と実施設計の間の概算のあたりです(図10)。
例えば、基本計画においてのBIMのモデルはどの程度のものなのかというとボリュームがあるくらいです。(図11)基本設計になると、Elementを置いていきますので、それなりに形にはなりますが、あくまで壁や床ありますといった情報程度です。(図12)実施設計になると、図面の中にタグが配置され、タグを配置するためにはいろいろなパラメータが必要となりますのでいろいろな属性情報を入れていきながら図面化していきます。(図13)さらに、確定してくる仕様の情報などが入ってきてデータが埋まってきた状態をS4(実施設計の後半)で建物情報を作っていくという立ち位置になるのではないかと思っています。(図14)なので、積算協会で行っているのはS2、S3のあたりのレベルのデータでどのように概算をするかといったことがメインフレームでそこに分類体系をどのようにあてがっていくか検討していると理解しています。
図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のようなものに属性情報を入れていくのか、あるいはそれとリンクしたデータベースの中に入れていくのかこのような点も考え所です。また、共通化して共有したい情報というのは、1つのファイルに入れない方がいいかもしれないです。1つのファイルに入れてしまうと、この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の緑の枠の部分の話と勘違いされることがあります。材料の1つ1つに番号をつけていると思われますが、そこは対象ではなく、あくまで分類をする部分です。材料や部位などが対象であると説明するためにこのスライドを入れています。
ただ、分類をどのように設定するかということは重要であり、先ほどの防水工事の場合ある材料分類のセット(図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とかを使って自動的にシステムレベルまでデータベースを作れないかという研究です。3次元のビューと分類体系を使ったデータベースのビューと両方で見せることができないかということを検討しています。このようなものが揃ってくるとようやく分類体系を使ってコストマネジメントしていくことやそのデータをいろいろなところに応用していくことができるのではないかとやっています。
議論
田澤:SSからPRにブレークダウンしてきたときにPRで何をつけたら良いのかわからないなどということが起こってくると思いますが、そのようなことは起きていますか。
志手:日本で整理されている単価情報とBIMから持ってくることができるデータベースのものが合わないです。例えば、工種別の単価があったとしてもBIMの中には工種といったまとまりはないので結局オブジェクトベースになっていきます。そこで単価に付けられるものは何かというと、最終的なプロダクトであれば単価があります。そこまでいくと単価を結び付けられるので、コストとして出すことができます。けれど、それをシステムレベルの合成単価にしようとした時には、対応する単価がないので現段階でできることはプロダクトで単価を付けておいて、それをシステムに合成した時にいくらになるかという形で今はやっていくしかないと思います。これで本当にできるとなれば、そういうまとまりで単価をこれから残していくようにしましょうということをしなければいけないです。
安藤:RSMeansもそのようにできているのですか。
志手:Uniformat、Masterformatを使ってそういう風にやっていると思います。
岩松:AssembliesというR.S. Meansのコストブックがありますけど、これは下位のレベルの労務費や材料費を一定程度精密に調べて、歩掛を用いてアグリゲートしているだけです。こうして機械的に作った価格情報をまとめて毎年出版しているものです。
安藤:要するにデータベースですよね。システムとプロダクトの話で志手先生がお話されたものはジェネリックなもので、プロダクトはいろいろなレベルのプロダクトがあり、DfMAでいうと新しいプロダクトが作られていくけれど、それは今日お話されたプロダクトではないと思います。そういうプロダクトが一般的に使われるようになってくると、それはジェネリックなプロダクトになるということではないですか。
志手:NBSも年4回改訂しているので、それくらいのペースでジェネリックなプッロダクトが増えるということです。
小笠原:実際に積算協会とかでイギリスとかアメリカでどう使われているのか具体事例を何件か精査していますか。
志手:それはやらないといけないという話で止まっています。NBSとは、積算協会と情報交換できる状態にはなっています。
小笠原:どう使っているのかかなり学べるとこが多いと思っていて、NBSなど推進している機関というよりは実際の設計者や発注者など利用している人たちが上手く使えているところもあれば、全部インテグレイトすると大変なのでバラバラにしてこういう形でデータを使っていますというようなものがわかると目指す方向性が定まると思いました。BIM推進会議で中小企業や地方の事例が出てきているという話は良いと思っていて、BIMとかは大きなプロジェクトや発注者に限定される場合が多く、いくらその部分を変えようとしてもサブコンとか下請の人たちまでデジタル化、BIMの恩恵を必ずしも受けられない状況があると、プロダクトとシステムで切れている話と重なる部分があると気がしています。本当にやらなければならないことは、BIMのソフトを使うことよりも下請の人たちが明確なデータベースの使える環境を提供することが一番重要なことではないかと思いました。
安藤:小笠原先生のお話の前半部分のどのように使っているのかという話で、特に川上の方で、EFとかUniformat的な部分でいうのは、DBとかIPDを前提とすればそこが必要となるのではないでしょうか。DBBのようなものであればシステムから設計すると思います。なので、UniformatやBIM IPDみたいなことが出てきたということで、発注者がそれを先行しているという前提でないと上流側のEIRも含めて使われ方がイメージできないのではないかと思います。
小笠原:日本の環境の中でこのようなものをどのように拡げていくのかということが推進会議の中で重要なことだと思います。発注者に新しい使い方があるということを示していくトップダウンの方向は大切だと思いますが、同時に下流の方にどう流れていくのかわからないと上流だけの話で終わってしまうと気がしました。
志手:分類体系の話にフォーカスするとUniclassの場合、通り考え方があります。1つは、図22、23のようなマネジメントの話です。もう1つは、デジタルデータベースとしてみたときの考え方もあります。例えば、図18のようなモデルを組んだとき、屋根の屋上のオブジェクトは実際には床を使いそのままデータを出すと床として出てくるので、屋上であるとハッシュタグ的に付けないとデータがきちんと流れていかないです。そういう意味でエレメントファンクションはそういう使い方をしていかないと実際には下流までデータが流れていかないという面もあります。マネジメントという観点とデータをどのように下流まで流すのかという二面性があるように思っています。
安藤:一般材料をいろいろなシステムと繋ぐということは一筋縄ではいかないです。もう少し、原則、定石などを理解していくべきだと思いました。
志手:図24の右下のセットをたくさん作っていかないといけないと思っています。
安藤:BELCAのところの話で設備の部分はどうなるのか話を今後聞いてみたいです。
志手:そこまではまだ手がつけられていない状態です。
安藤:この話もシステムプロダクトの分類の問題だと思います。