ダイレクトリンク vs IFC

OPEN BIMは非常に成功しているように感じます。一企業が、BIMに必要なソフトウェアをすべて提供するのではなく、複数の企業のBIMソフトウェアが連携するというコンセプトは、私たちがOPEN BIMに参画した2010年当時、奇妙なアイデアのようでもありました。揶揄されたり、よくても「いいアイデアですね、でもうまくいかないでしょう…」などと言われるくらいでした。

しかしそれも5年前のことです。それ以来、私たちはOPEN BIMがただのマーケティングスローガン以上のものであることを証明してきたと信じています。今では、「一企業でBIMが要求するすべてのソリューションを提供する」という考え方は以前に比べて影をひそめ、最大手の企業でさえ、BIMは一企業がまかなうには規模が大きく、重大すぎるものであると理解してきています。このため、buildingSMARTのビジョンや、IFCフォーマットの継続的な進化が不可欠でした。これこそがOPEN BIMの根幹であり、これなくしてはただの良いスローガンに過ぎなかったでしょう。

このことを私は嬉しく思います。素晴らしいことです。 しかし、最近「ダイレクトリンク」というものが、取り沙汰されています。

この「ダイレクトリンク」が時代に逆行しているということを理解していただくためには、IFCとダイレクトリンクという用語にあまりなじみがない方のために少し詳しく説明する必要があるでしょう。BIMソフトウェアはデータを格納するために、それぞれが異なる「言語」を持っています。もしあるソフトウェアから別のソフトウェアへデータを転送する場合には、データのフォーマットを変換する必要があります。これは英語から日本語、もしくはハンガリー語に翻訳するようなものです。この翻訳のためには特別なコードを書く必要があります。ここでは「翻訳コード」と呼ぶことにしましょう。例として、ソフトウェア「A」から、ソフトウェア「B」にデータを転送するプロセスは次の図のようになります。

もし、ソフトウェア「C」にデータを転送する場合は、別の翻訳コード、ソフトウェア「D」に転送するときもまた別の翻訳コードを書く必要があります。次の図のようなイメージです。

毎回一から翻訳コードを書き直さなければならず、またどちらかのソフトウェアがアップデートされれば、そのたびに書き直す必要があります。これはちょっとうんざりする仕事です…。そこでIFCですが、これはエスペラント語のようなアイデアで、誰もが理解することのできる普遍的な言語なのです。もしIFCを読み書きできれば、他のソフトウェアとの翻訳について気にする必要がなくなり、IFCだけに集中するだけでよいのです。例として次の図をご覧ください。

実際にはもう少し複雑で、それぞれのデータ出力処理に伴う作業もありますが、それは些細なものです。しかも作業の大部分は同じことなのです（重要！）。例えば次の図のようになります。

以前のやり方と比べてみると違いは顕著です。出力しなければいけないデータがたくさんある場合、ダイレクトリンクの代わりにIFCを使用することで作業量を大幅に削減することができます（どれだけ開発に力を注いだかにも比例しますが）。

これを理解すると、どちらがより新しい方法かは言うまでもありませんし、OPEN BIMの精神にも合っています。ではなぜ古い方法にもどりたいという人がいるのでしょうか？なぜならそこには罠があるからです。もしたった一つだけのコネクションを開発するのであれば、ダイレクトリンクを使用してより少ない作業量で間に合わせることはできます。IFCコネクションの開発には比較的大きな労力が必要となりますから。

ですので、大企業がOPEN BIMに関心がなく、特定のソフトウェアのデータ接続を行いたいだけであれば、リソースの少ない中小企業に対してIFCではなくダイレクトリンクで行うよう勧めるのも論理的です。ダイレクトリンクに投資した中小企業は、すぐにIFCへの関心をなくすでしょう。ダイレクトリンクの開発に投資したとしても、他のソフトウェアのデータ接続には利用できないからです。しかしこれは重要なポイントです。他のソフトウェアとの接続ができなくなり、特定のソフトウェアでのネットワークができれば、競合を排除し、ユーザーの選択肢はなくなります…。これが私たちの望む日本のBIM業界の未来の姿でしょうか？私はそうは思いません。

ダイレクトリンクを支持する人たちの主張には次のようなものもあります。おそらく耳にしたことがあると思いますが、「IFCが機能しない」というものです。繰り返しますが、これは事実ではありません。IFCは機能しており、年々よくなっています。構造設計の分野を別にすれば（この分野では実際に使用する前に現場に合わせた調整が必要となります）、IFC接続の品質というのは他に引けを取りません。もちろんデータのやり取りをする両者が必要な作業を行うことが前提です。もちろん、時には問題や、バグなどが出てきますが、それはダイレクトリンク接続でも起こり得ることです。問題は、バグにどのような傾向があり、いかに速く解決することができるかなのです。IFCのバグは以前に比べるとはるかに少なくなり、課題の多くは迅速に解決されています。少なくとも真のOPEN BIMの理想を信じている企業によって。

IFCにおいて、「解決できない」とされ、「ダイレクトリンク」の正当化のために、利用されてきた問題をより深く調査してみると、それは適切なIFCの出力で解決できるということが判明しました。例をあげましょう。下記の図を見ると、あるジオメトリがARCHICADと、よく知られたMEP BIMソフトウェアの間ではIFCを通じて完璧に動作しています。一方で別のBIMソフトウェアから出力されたデータとの間ではうまく動作せず、上記の2つのソフトウェア間で動作しているという事実は、IFCのバグではないということが誰の目にも明らかです。完璧なデータ転送には両方のソフトウェアのIFCアドオンが正しく動作する必要があります。この例で動作しないという問題の原因は別のBIMソフトウェアにあるようですね。

左がARCHICADから、人気のMEP BIMソフトウェアへのIFCデータの出力結果、右が別のBIMソフトウェアからのIFCデータの出力結果です。データは壁にいくつかの穴が開いているシンプルなものです。右の例は、本来であれば左の例と同じになるべきなのですが、結果を見るとジオメトリが壊れているのが明らかです。

全体としてみれば、IFCはほとんどのBIMデータ交換を処理するのに十分成熟していると言えます。私からするとダイレクトリンクを使用するというのは、IFCの入出力を高品質でできない（もしくはしたくない？）ことを上手に言い換えているように思えます。BIMソフトウェアのデータ接続の方法を以前の方法に戻すことに、お客様が関心があるとは思えません。そうではなく、私たちはIFCでの接続の調整をしていくことで、真にオープンな基準や公正な競争を確保していけるよう努力しなければならないと考えています。