見出し画像

建築プロジェクトはどこへ向かうのか(3)実施設計図について

はじめに

こんにちは。押山です。
建築プロジェクトはどこへ向かうのかと書いてはいるのですが、私自身も良くわからず、むしろどこへ向かうのだろう?という感覚を持ちながら書いています。こんなことを書くと肩透かしされたような気もしますが、それでも自問自答しながら建設業がよりよい方向を目指していけたらなと思っています。建築プロジェクトは分業化が進んできた中で、本当にたくさんの業種が関わります。そのためか、自分の業務の前の業務や後ろの業務を把握することが困難な場合もあります。設計側から見たらあのコンサルは何をしているだろうとか、コンサルからみたらこちらでここまで整備しないとプロジェクトが成立しないとかそれぞれの立場から見えている問題は違うことでしょう。私も日々業務を行っていく中で、ステークホルダーとしては名前を連ねていますが、いったい何の業務を担当しているのかわからない業者もいます。ただそれはこちらまで情報が届いていないだけなのかもしれません。そのようなところを少しずつでもクリアにしていきたいなと思う今日この頃です。 

実施設計図をちゃんと書けばいい

入札前で整合性が取れないために、積算が正当性をもってできないのであれば、実施設計図をちゃんと書けばいいじゃないかと言う人はいます。それが出来るのであれば、それが一番いい解決方法かもしれません。しかし、それは現実的にはかなり難しいと言わざるを得ません。まず建築物そのものはとても複雑化かつ高度化しており、完璧な図面というもの自体を目指すこと自体が現実的ではありませんし、これを現状設計事務所のみでまとめることも現状では難しいと思います。また日本の建築生産プロセスの成り立ちが諸外国とは異なり、施工者側(ゼネコン)が全部を引き受けて施工図(建築物を実際に建てるための図面)を描くため、実際に建築物として成立させる調達や調整も施工者側に集中しています。これは世界的に見ると珍しい業態であることを前提に置かなければなりません。そのため、設計側が施工までを加味しながら図面を描くこと自体が難しく、その後には必ず調整が入ることになります。もちろん、施工に詳しくそれらを加味した設計図面を描く事務所もありますが、あくまで大多数がそこまで考えながら図面を描くのは時間的にも技術的にも難しいと言わざるを得ないと思います。
それを踏まえ、実施設計図をちゃんと書けばいいという話ですが、実際に知り合いの設計従事者に話を聞くと、返答される回答は時間が足りないというのがほとんどです。それは膨大な申請業務や調整業務に忙殺されながらも設計検討をする必要があるからです、建築の検討をしている時間は私の聞いたところによると設計期間全体の2割くらいを費やせればいい方だそうです。それ以外は調整業務、書類申請業務でだそうです。
正直設計のプロに調整業務や、書類申請業務に時間を費やすのは大変もったいないような気もするので、何かしらそのあたりの設計フローなりを確立していく必要はあるのかもしれません。

社内でも自由度を持ちながらも、よりよい建築プロジェクトの工程を考える上で、実施設計図を完成させるまでに必要な業務を、わかる範囲ではありますが、書き出しこれに付随したデータの作成手法を考察しています。

画像1

これだけでも、相当な調整業務が発生していることがわかりますし、出戻りがある場合にはさらに大変かと思われます。

LOD(Level Of Development)

少し専門的に話になりますが、LOD(Level Of Development)と呼ばれる段階的に情報量が付加されていく手法があります。これはAIA(アメリカ建築家協会)等のメンバーから構成されるBIM Forumが策定するものであり、LODを100/200/300/350/400の五段階に分類し、建築物の各部材ごとに付加すべき情報量を規定しています。しかし実際の業務内容で考える場合には、ただ単に段階的に情報が付与されていくかというとそういうわけにもいかないということがあります。例えばですが、設計情報の確定度が低い基本設計段階では、建築物の部分を詳細(ディテール)に表現することは少ないですが、矩計図などの建物全体の構成に関連する詳細図や、基本設計時の概算に必要な部材のディテールなどは、ある程度詳細に作図されることがあります。この場合は、建築のデータ(設計図書全体)としては情報量が小さいが、ある部分に関しては情報量が多く密度が高いという状態がおきます。
ここで私が大事だと思っていることは、建築の情報とかたちに関するデータは文脈依存であり、かつそのデータ同士にも依存関係があることです。この部分を流動的な建築プロジェクトに対応する必要があります。(この手法は後程紹介)
これらを実現させるためには、具体的にどんなソフト、プログラムを使うかの考察や、建築の情報とかたちを作るための情報とを分けて考えていく必要があります。ここには当然、前回言ったような設計変更や契約変更、多様な発注方法への対応も含まれます。

設計期間が短くなる理由

実施設計図を作成する上で時間的にも難しいという話をしましたが、これは設計期間が短縮されているという実態があります。発注者としては設計期間を短くすることで、金額的にコストを下げることに成功していると感じているかもしれませんが、私の実感としては結局のところ調整業務が増えるだけなので、後工程でコストがかかっているだけだと思っています。ただ日本の場合、施工工程は総価一式請負契約(工事で要した費用が契約額を超えた場合でも発注者から追加の支払いが発生しない。)によって進むため、施工側が赤字を前提として請けている可能性はありますが、それでも建築プロジェクトの品質やリスクという面では問題があるのは確かだと思います。話を戻しますが、設計期間が短くなる理由としては、設計期間を発注者と設計者間で決める際に、まず同様の規模や用途の建築物を参照します。そこには建築が建つまでの期間が載っていますので、仮に20ヶ月で完成したとあれば、そしたら今回頑張れば19か月でいけるのでは?ということになり、それらを繰り返していくことで設計期間が常にギリギリまで短くなっているようです。これは公共施設などの予算取りの問題と似ているかもしれません。本来であればなぜ減額できたのかや、なぜその期間で完成することができたかなどの履歴があって然るべきですが、最終的な数字のみこの金額できた、この期間で出来たということだけが取り上げられ、来年の予算は減額されるというパターンに陥ています。だったら効率化とか目指さない方がいいのでは?となってしまいます。これと同様に設計側が設計期間の根拠となる資料などを明示できないいまま(過去の経験則はあるかもしれないが)、結果そのまま請けてしまうパターンが繰り替えされて現在に至るということだと思われます。

結局のところ私の考えでは、発注者はさほどコストは変わらず、出来上がる建築物の品質的なリスクが高くなり、設計者は設計期間が短い中長時間労働を強いられ、施工者は調整業務が肥大化し工期までの予定を想定しきれずリスクを負う。ということになっているので、実際みんな苦しいという構造になっている気がしています。
この構図を解消する体制としても前回書いた建築プロジェクトの体制を提示しています。抽象度を少しずつ上げながら建築データを管理・調整する組織が企画または設計初期段階からいた方が、発注者(建築主)としてはも建築データの透明性が確保でき見積もりも正当性をもって判断できるようになりますし、設計者も施工者も事前に整合性が取れていないこと早い段階で気が付け、かつ何が問題かがわかるので、建築としての品質を確保しながら、工期までに長時間労働せずに建築プロジェクトを完遂できるのではないかと思っています。
ただこの辺りはいくら言葉にしても、実態は掴めないので今後は実践の場を設けていきたいなと思います。
※業務フローでの品質管理組織の役割

画像2


タイトル画像:WokandapixによるPixabayからの画像 

--------------------------------------------------------------------------------------

お仕事に関するお問い合わせはこちらからお願いします。

-建築Tシャツ-をお買い求めの方はこちらからご購入いただけます。

Rhinoceros7をご購入される方はこちらかたご購入いただけます。

--------------------------------------------------------------------------------------