CADで測れるのに、なぜ手計算でチェックするのか
CADで作図した配筋図を、あえて紙と手計算で別系統照査する理由。社員がGeminiを使って三角関数のExcelを作り、技術教育と小さな業務改善につなげた実体験を紹介します。
今の時代、配筋図も当然CADで作っています。
鉄筋加工図を作るときも、CAD上で鉄筋の形状を確認し、必要な長さを計測できます。それなら、チェックするときもCADでもう一度測ればよい。一見すると、それで十分なようにも思えます。
しかし、うちではあえて同じ方法だけでチェックしないようにしています。
理由は単純です。同じ方法で2回確認しても、元の考え方や図面そのものが間違っていれば、同じ間違いを2回なぞる可能性があるからです。
これは配筋図に限った話ではありません。数量計算などでも、できるだけ作成時とは別の方法、別の系統で確認することを基本にしています。同じ原因による見落としを減らすためです。
配筋図では、あえて紙図面で確認する
配筋図のチェックでは、CADで作図したものを印刷し、紙図面を見ながら手計算でも確認します。昔、CADを使わずに図面を描いていた頃に近い考え方です。
特にコンクリート構造物では、斜めの部分が出てくると少し厄介です。
鉄筋は、コンクリートの外面から所定のかぶりを確保して配置します。例えば構造物の外形が45度で折れている場合、その内側に配置される鉄筋も外形からオフセットされるため、構造物の折れ点と鉄筋の折れ点は同じ位置にはなりません。水平方向にも鉛直方向にも、ずれが生じます。
CAD上で鉄筋を描いてしまえば、その加工長を計測すること自体は簡単です。しかし紙図面から手計算で確認しようとすると、
- 構造物の折れ点から、鉄筋の折れ点はいくらずれるのか
- この斜め部分の長さを求めるには、どの寸法が必要なのか
を理解していなければ計算できません。ここに、手計算で確認する意味があります。
別系統のチェックであり、技術教育でもある
CADはとても便利です。便利すぎる、と言ってもよいのかもしれません。図形を描けば、長さも角度もCADが計測してくれます。
そのため経験の浅い人の場合、「なぜこの寸法が図面に必要なのか」を十分に理解しないまま作図できてしまうことがあります。
紙図面で手計算しようとすると、そうはいきません。必要な寸法がなければ、計算が止まります。
「この角度を求めるには、この寸法が必要だ」
「この鉄筋長を確認するには、この位置関係が分からなければならない」
と、自分で考えなければなりません。
つまり紙図面による手計算チェックは、CADとは別系統で照査するための品質管理であると同時に、図面に記載する寸法の意味を理解するための技術教育でもあります。
だから、CADが便利になったからといって、この考え方までなくしてよいとは思っていません。
ただし、手計算は大変だった
意味のあるチェックではあります。ただ、実際に作業する社員からすれば、なかなか大変です。
斜めの部分が増えれば、三角関数を使う場面も増えます。SIN、COS、TAN。さらにExcelで計算できるようにするには、単純に三角関数を書けば終わりではありません。ExcelのSIN関数は角度をラジアンで指定するため、角度とラジアンの扱いも理解する必要があります。
三角関数が得意ではない。Excel関数も得意ではない。でも紙図面による独立チェックは必要。楽にするためにExcelを作ろうとしても、そのExcelを自力で作ること自体が大変です。
必要な作業ではあるのですが、社員にとっては「しんどいこと」が重なっていました。
そこで数か月前、私から社員に、
「AIを使って、この計算を少し楽にできないか試してみたら」
と声をかけました。
社員たちは、当社のGoogle Workspaceで利用しているGeminiへ相談しながら、計算用のExcelファイルを作りました。
必要な寸法や角度を入力すると、三角関数を使って確認したい寸法を計算する。技術的には、「三角関数をExcel関数にしただけ」と言ってしまえば、それまでです。
でも、私が意味を感じたのは、高度なプログラムを作ったことではありません。
自分たちの仕事で困っていたことを、AIを使いながら自分たちで改善したことです。
きっかけを出したのは私ですが、実際の業務に合わせて形にし、自分たちが使えるところまで持っていったのは社員たちでした。
最初から完成していたわけではない
もちろん、最初から何にでも使えるものができたわけではありません。
最初に対象にしたのは、構造物の折れ点が鈍角になるケースでした。かぶりによって生じる構造物と鉄筋の折れ点のずれを考慮し、鉄筋の加工長を確認するためのものです。
まず、そのケースで使えるものを作りました。ところが実際の配筋図には、鈍角だけではなく鋭角になる部分もあります。
そこで次の段階として、「入力値をマイナスとして扱えば、同じ考え方で鋭角側にも対応できないか」と考え、AIへ相談しながらもう一度修正しました。
最初から完璧なツールを作ろうとしたわけではありません。
作る → 使う → 気づく → 改善するまず一つの条件で作り、実際の仕事に当てはめ、足りないものに気づいたら、もう一度考える。この小さなサイクルを回しました。
振り返ると、この過程そのものがAIを実務で使う練習になっていたように思います。
AIに設計判断を任せたわけではない
今回、AIに配筋図の良し悪しを判断させたわけではありません。
必要な寸法を理解する。どの条件から何を求めるのかを考える。紙図面を使ってCADとは別系統でチェックする。この部分は残しています。
そのうえで、
- 三角関数の計算式を組む
- Excelで使える形にする
- 繰り返し行う計算を楽にする
といった、負担の大きかった部分をAIで軽くしました。
考えるべき部分は残し、面倒な部分だけをデジタルで軽くする。そういう使い方です。
社員にとっては、AIを実務で使う一連の経験にもなりました。
- 何を確認したいのかを理解する
- 必要な入力条件を整理する
- 計算式の実装をAIに手伝わせる
- 出てきた結果を自分たちで確認する
- 足りない条件があれば改善する
AIに仕事を丸投げするのではなく、分かっている仕事を、AIを使って少し楽にする。実務でAIを使い始めるには、こういう経験の方が大切なのかもしれません。
数か月たって、少し違って見えてきた
このExcelを作ったのは、つい最近ではなく数か月前のことです。
そのときは、「手計算が少し楽になった」「AIを使ってExcelを作れた」くらいに考えていました。でも今振り返ると、もう少し意味があったように感じています。
うちはDX認定事業者として、AIやデジタル技術を使いながら、土木設計の仕事を少しずつ変えていこうとしています。
ただ、代表者だけがAIを使い、いろいろな仕組みを作っていても、会社全体には広がりません。社員側でも、
- この仕事を、もう少し楽にできないか
- この作業は変えられないか
- AIを使えば何かできないか
と考え、実際に試す経験が必要です。
今回は、こちらからきっかけを出しました。それでも、社員たちがAIを使い、自分たちの仕事に合った道具を作り、さらに条件を広げながら改善した。その経験が一つできたこと自体が、うちにとっては小さなDXの実績だったのかもしれません。
次はVBAや3次元へ
管理する側としては、もちろんここで終わりとは考えていません。
近い将来には、VBAを使ったもう少し踏み込んだ自動化にも挑戦してほしいと思っています。3次元データの活用も、もっとできるようになってほしい。
ただ、いきなり「VBAを覚えなさい」「3次元を使いなさい」と言うだけでは、なかなか仕事には定着しません。
その前に、自分の仕事の中から困りごとを見つけ、AIに相談し、自分たちで少し改善してみる。そして、「自分でも仕事を変えられた」という経験を一つ持つ。
そういう小さな成功体験が、次へ進むきっかけになるのではないかと思っています。
DXは、全部を新しくすることではない
今回の例では、紙図面で手計算するという、一見すると古いやり方を残しています。
でも、それには理由があります。
- CADとは別系統で確認するため
- 必要な寸法の意味を理解するため
- 技術者として考える部分を残すため
古い方法だから捨てる、新しい技術だから使う、という話ではありません。
残す意味があるものは残す。負担になっている部分はデジタルで軽くする。そして、改善する力そのものを社員にも身につけてもらう。
今回作ったのは、三角関数を使った小さなExcelツールです。大規模なシステムでも、高度なAIでもありません。
それでも、社員が自分たちの仕事を見直し、AIを使いながら形にして、実務で使えるところまで持っていきました。会社のDXは、案外こういう小さなところから広がっていくのかもしれません。
しかも、ピンク系の色だけではなく、私にはどうやって出したのか分からないような、可愛い絵文字やマークまで入っていました。
機能だけを満たせばよいのではなく、自分たちが毎日使う道具を、自分たちなりに使いやすく、少し楽しくしている。
数か月たった今になって、あの少し派手で可愛いExcelが、うちのDXの小さな一歩として、前より頼もしく見えてきました。