「プロダクトマネージャー」不在の建設サプライチェーン


ソフトウェア開発にたとえるなら、特注建設部材のものづくりは、プロダクトマネージャー(PdM)がいないまま開発が進んでいく状態に似ています。要件を整理し、関係者の判断をつなぎ、「何をつくるのか」を最後まで詰める役割が、構造上明確に置かれていないためです。

ソフトウェア開発と同じように、建設業界は、元請、一次請け、二次請け、三次請け、そして製作工場と、多くの関係者が関わります。関係者が増えるほど、情報の伝達や調整は複雑になります。

その結果、発注者である建設工事会社の要求が十分に整理されないまま、製作依頼や図面が工場へ渡ることがあります。工場は、図面や仕様だけでは判断できない情報を確認しながら製作図を作成し、製作を進めなければなりません。こうした要件の確認や手戻りが積み重なり、QCD(品質・コスト・納期)にも影響します。

ballas-deck-p15.png

これは、個々の建設会社や工場の進め方だけに起因する問題ではありません。要件を整理し、設計・製作まで一貫してつなぐ機能が分散している、サプライチェーン全体の構造的な課題だとBALLASは捉えています。

BALLASは、まず特注建設部材の製作を起点に、この構造を変えようとしています。個別案件で発生する要件や判断を整理し、データとして蓄積し、設計・製作のプロセスそのものを再現可能な仕組みへ変えていく。

その先に目指しているのは、一品一様になりやすい建設部材のものづくりを、より標準化・自動化されたプロセスへ変えていくことです。 特注部材の製作から建設業の工業化へ。BALLASは、その変革を前に進める「プロダクトマネージャー」のような役割を担おうとしています(YOUTRUST Studio・2026年5月)。

設計から施工までを、データでつなぐ


建設部材のものづくりをオーケストレーションするためには、発注者の要求を理解するだけでは足りません。「何をつくるのか」を定義し、設計・製作・施工のそれぞれで使える情報へ変換しながら、後工程までつないでいく必要があります。

建設では、工程ごとに異なる図面が使われます。設計段階では3Dモデルや意匠図、製作工場では製作図、施工段階では施工図。それぞれ目的も作成者も異なるため、工程をまたぐたびに情報の読み替えや補完が発生し、判断の経緯が失われることもあります。

意匠図・施工図・製作図。後工程ほど専門性が高くなり、作図者も目的も変わります(会社紹介資料より)。

意匠図・施工図・製作図。後工程ほど専門性が高くなり、作図者も目的も変わります(会社紹介資料より)。

こうした分断をなくすための情報基盤として、国を挙げて活用が進められているのがBIMです。BIMは、建物の3D形状だけでなく、部材の仕様や性能などの属性情報を持たせることができます。国土交通省も、BIMを通じて設計・施工・維持管理を横断したデータ活用を進めており、2026年4月にはBIM図面審査も始まりました。(国土交通省 建築BIM推進会議「BIM図面審査 申請・審査マニュアル」・2026年3月)。

BALLASも、BIMを設計から施工までの情報をつなぐHUBのひとつと捉えています。そのために、3Dモデルだけでなく、施工図や製作図まで自ら扱います。図面を書くこと自体が目的ではありません。上流で決まった要求や仕様を、製作・施工でそのまま使える情報へ変換し、工程をまたいでも情報が途切れない状態をつくるためです。

さらに、そこで扱われる寸法、仕様、製作条件、判断の履歴を構造化し、BIMをはじめとする3Dモデルと接続していく。人が図面を読み替え、判断しながらつないできた設計・製作・施工のプロセスを、データでオーケストレーションできる状態へ変えていく。 それがBALLASの目指していることです。

人のやりとりを、AIが扱えるデータへ