この【構造設計コラム】では、日々の業務での少しゆるめな経験談や課題意識を共有していきます。多くの方が共感していただけることを心がけて書いていきたいと思っています。少しでも構造設計を前向きに取り組むきっかけになればと思います。
今回のテーマは、多くの設計者が頭を悩ませ、社会的な課題にもなっている「設計図書の不整合」です。
意匠図と構造図の整合性、計算書と図面の整合性、一般図と詳細図の整合性…。設計プロセスが複雑化する中で、なぜ不整合は起きるのか、それによってどんな問題に繋がるのか、そしてどうすれば解消できるのか。私なりの考えを共有していきます。
①不整合が多いとどうなる？【確認申請・構造適判】
設計図書を実現するためには法的なお墨付きをもらう必要があります。そのためには確認検査機関や構造適判員の審査担当の方に設計図書を確認してもらいます。彼らは、図書に描かれた情報だけを頼りに、その建築物が法的及び構造的に安全かどうかを判断します。
ここで不整合が多いと、当然ですが審査期間が長くなります。質疑応答に多くの時間を費やすことになり、プロジェクトのスケジュールに遅延が生じます。
計算書と図面の些細な不整合が多いと、構造計算適合性判定で本来審査すべき「構造計算の妥当性」という本質的な論点がぼやけてしまいます。その結果不整合に関する指摘ばかりになってしまいます。
例えば、計算書ではOKの部材が、図面で異なる符号やサイズで記載されているケース。図面に合わせて計算モデルを修正すると計算結果が変わり、他の箇所に影響が派生して新たな不整合を生む…という悪循環に陥ることもあります。
さらに、不整合の多い図書は「品質の低い図書」という印象を与え、審査担当者からの信頼を失うことにも繋がります。信頼を失うと、本来ならスムーズに進むはずの項目まで、より詳細な説明を求められる「負のスパイラル」に陥ります。
結果として、作業量の増加が業務を圧迫し、さらなる品質低下を招きます。
多くの構造設計者は複数の業務を兼務していることもあり、品質の低下が連鎖します。
現在は確認申請と構造計算適合性判定の審査が同時審査可能になっているため、両審査機関から同様の指摘を受けることになり、それぞれに対して回答するとさらに時間が掛かります。不整合を減らすことは前提としても、構造計算適合性判定は先に審査を受けるといった対策もあります。
引用：構造計算適合性判定を要する物件に係る確認審査日数について（国土交通省）
参考：申請業務の進め方と心得
②不整合が多いとどうなる？【施工者（積算・現場）】
無事に確認申請が下りても、不整合の問題は終わりません。次に図書を受け取るのは、工事費を見積もり、実際に建物を建てる施工者です。近年ではプロジェクト期間が厳しくなってることも多く、確認申請が終わる前に発注図として出回ることがあります。
まず、積算段階での手戻りや誤った見積もりに繋がります。この不整合は、契約金額への影響や現場での増減調整といった、本来は不要な業務を発生させます。
また積算段階で図面ごとに書いてある内容が異なればそれは当然どれが正しいのかを確認するための質疑回答でのやり取りが発生します。ここでも回答書の作成や変更前後図の作成といった情報整理のための作業量が増えていきます。
そして、最も深刻な影響が出るのが工事現場です。現場では、図面が全てです。その図面に不整合があれば、作業は滞り、時には手戻り工事が発生します。躯体の作り直しは構造安全性としての品質、工期・コストへの影響が大きく簡単にできることではありません。
確認申請に提出している図面間での不整合は申請段階でほぼなくなっていると言えますが（ただし、審査が完了したからといって図書が完璧であるとは限りません。最終的な確認責任は、あくまでも設計者にあります。）、法適合に直接関係しない提出していない詳細図なども特に意匠図にはあります。それらとの不整合というのは増えています。またそれにより、計画変更に該当するような大きな変更が増えているのが事実です。
こうした問題が発生すると、工期の遅延はもちろん、予期せぬ追加コストが発生します。そして何より、設計者と施工者の間の信頼関係を大きく損ないます。「この設計者の図面は、いつも間違いが多い」という評価になり、その後の現場でのやり取りもギクシャクしたものになり、円滑なプロジェクト進行の大きな妨げとなります。人間関係の不協和音は、巡り巡って建築物そのものの品質に現れます。
参考：現場監理の基本動作～先回り力で品質と信頼を築く
参考：「計画変更」か「軽微な変更」か？知っておくべき現場変更の手続きと協議の心得
③不整合はどうしたらなくなる？
では、どうすればこの不整合をなくせるのでしょうか。精神論ではなく、具体的な改善策を考えてみます。
・消込チェックをする
設計の基本中の基本ですが、これが一番難しいのかもしれません。消込チェックは時間が掛かる上に、本当の最終成果品に対して行うことで最大の効果を発揮します。
しかし、現実には「半端な段階」でチェックせざるを得ず、その後の変更や調整で新たな不整合が生まれてしまう。まさに「モグラ叩き」のような状態です。意匠変更や設備ルートの変更といった、構造設計者のコントロール外で発生するものもありますが、そこは物件チームとしての成果の確認方法を工夫するなどで、他人事の課題から自分事の課題に転換することもできます。
実は、時間切れの理由は他部門に原因があるというよりも、主には単純に作業スピード、作業手順にあるのではないかと思っています。この詳細については以降の『完全でなくても計算書一式を作り切る』で詳しく述べます。
時間切れで最終チェックができない、というのも深刻な問題です。これを解決するには、個人の努力だけでなく、「最終チェックのための時間を設計スケジュールに予め組み込んでおく」といった、プロジェクト全体のマネジメントが不可欠になります。
設計者というか人間は、期限が延びても結局、期限間際でしか力を発揮しない性質があるので、適正な作業時間は確保しつつ、意味のある関所の設け方がポイントになってきます。
参考：「自分で考えたか？」思考の言語化で仕事は劇的に変わる
参考：デキる人が実践する段取り｜周囲から信頼される仕事の進め方
・ルールを明確にする／イレギュラーは作らない
構造設計に限らないことですが「考え方が明確でシンプルであれば、不整合は起こりにくい」。これは真理です。設計の初期段階で、部材符号の付け方や図面の表現方法といったルールを明確に定義し、チーム内で共有することが極めて重要です。
例えば、「柱はC1, C2…、大梁はG1, G2…」といった基本的なルールに加え、「階を跨いでも同じ断面なら符号は変えない」「断面が変わる場合は末尾にa, b, cを付ける」など、具体的な運用ルールまで決めておく。そして、何よりも大切なのは「安易にイレギュラーを作らない」ことです。
間違いを一つひとつ探す「減点法」のチェックではなく、ルールから外れたものが自然と目につくような、シンプルで強固なルール作りを目指すべきです。
部材符号に「C1a」のような小文字付きの符号が増殖し始めたら、それはもう危険信号です。ルールが複雑化し、設計者本人でさえ全体像を把握しきれていない証拠と言えるでしょう。
それは「電算主義」の設計に陥っている証拠かもしれません。最初に決めたルールから逸脱して符号を変更する場合、応力状態など誰もが納得できる明確な理由がなければ、計算結果そのものを疑うべきです。安易に電算のOK/NGに振り回されないようにしましょう。
参考：耐震性は耐力と硬さ（剛性）のバランスで考える
参考：計算プログラムに使われない付き合い方
参考：判断と決断を分ける技術～仮説思考で“判断”の質を上げる
・完全でなくても計算書一式を作り切る
品質管理の時間を確保するために最もポイントになることかと思っています。特に一貫計算ソフトを使い始めると、「ちょっとした修正変更」のたびに計算をやり直してしまいがちです。しかし、これが大きな罠です。一貫計算をいじっていたらいつの間にかものすごく時間が経っていた経験ありませんか？
断面算定や荷重の細かい数値を追いかけるあまり、何度も計算を流し、ようやくNGもなくし保有水平耐力も満足したと思ったら、補足計算や基礎の検討結果を反映したら、結局きわどかった部材が再びNGになったり、保有水平耐力も微妙に満足しない、、、。この繰り返しが、時間を奪っていきます。
そうではなく、まずは一度、荒削りでも良いので最後まで「計算書一式」を作り切ってみること。これにより、各種検討の関連性や安全率のバランスといった設計全体の大きな見通しを持って、判断を下せるようになります。
ざっくりな手順としては方針書⇒荷重表⇒二次部材⇒一貫計算⇒基礎の設計⇒補足計算のようになると思いますが、荒くてもいいから全体を一度通してみる。そうすることで、建物全体の力の流れや、どの部分が設計上のクリティカルになるのかといった「全体像」が把握できます。
これを実行するために課題になってくるのが、一貫計算外の補足計算を手早く作れる力を付けることです。一貫計算のような条件を伝えてほぼ自動で結果を出してくれることに慣れてしまうと、補足計算のように組み立て方から計算までを自分で行う計算書を作る能力がなかなか身に付かないといった状況に陥ります。
補足計算は言うものの重要な部分を個別の検討しているので決して簡単にできるわき役ではありません。無意識のうちに一貫計算主体の言葉遣いになっているということを本コラムを書いていて気付きました。
自らで補足計算を組み立てるには本質的な理解が不可欠になっていきます。少しでもそこの課題を解決に繋がる記事を引続き作っていきたいと思います。
コメント