活用・機能解説・事例

「個人の経験」を「組織の筋肉」に変える:3D可視化から考える、設計事務所の5つの組織課題への対策

公開日

設計事務所の成長は、単純に人数を増やすことでは測れませんよね。

スタッフが5人から10人になっても、重要な判断が代表者一人に集中し、若手が過去案件を探すたびに先輩へ質問し、設計変更が口頭やチャットの中に埋もれているなら、組織としてできることはそれほど増えていないからです。

むしろ人数が増えた分だけ、説明、確認、修正に必要な時間が膨らんでいるかもしれません。

「若手がなかなか育たない」

「営業と設計で話が噛み合わない」

「現場に設計意図が伝わらない」

「以前も同じ失敗をした気がする」

「過去案件はあるのに、参考にできる資料が見つからない」

こうした問題は、担当者の能力や注意力だけでは説明できません。

根底にあるのは、設計者の頭の中にある判断や、打ち合わせの中で交わされた認識が、ほかの人から見える形、後から呼び出せる形になっていないという「組織学習」のことです。

3D可視化は、設計事務所が抱えるすべての問題を解決する道具ではありません。しかし、図面、言葉、経験年数の違いを越えて、同じ空間を見ながら話すための共通言語にはなり得ます。

その共通言語を、コメント、判断理由、変更履歴、過去事例と結びつけられれば、個人の経験は、初めて組織が使える資産に変わります。


1.設計事務所の成長を止める5つの「認識のずれ」

1-1.職種が違えば、同じ図面を見ても注目する場所が違う

意匠は空間の連続性を、構造は部材の成立性を、設備は配管の経路を、施工はそれが現場で作れるかを見ている。同じ図面を見ていても、同じものを見ているとは限りませんよね。

問題はどの視点が正しいかではなく、違う前提から話していることに気づかないまま、言葉だけで合意したつもりになること。「天井をすっきり見せたい」が、設備側には天井懐を削る話として聞こえる。3Dの意味は専門知識の差をなくすことではなく、各職種が見ている問題を同じ空間の上に持ち寄れる状態をつくることです。

1-2.情報は「伝えた瞬間」より、「後から確認するとき」に失われる

口頭の説明、長いメールスレッド、個人チャット、図面上の手書き、そして記憶。その場では全員が理解したように見えても、数日後には、誰が何を理由にどこまで決めたのかが分からなくなります。

顧客の「もう少し落ち着いた雰囲気に」を、設計者は床材の話と受け取り、営業は照明の話だと理解し、顧客本人は家具の密度を想像している。この違いが記録されないまま資料だけ修正されれば、次の打ち合わせで「前回と違う」が起きますよね。

残すべきなのは完成図面ではなく、どの案を比較し、何を理由に選んだのかという文脈です。それがなければ、ファイルはあっても知識は残っていない。

1-3.情報が増えるほど、探す時間も増える

図面も写真も仕様書も膨大に蓄積されているのに、若手が類似案件を聞けば「たしか3年前のあの住宅」「誰かのローカルにあると思う」という会話になる。

足りないのは情報ではなく、そこへ到達する入口です。完成図面は残っていても、その案件で何が問題になったのかは検索できない。これでは案件が増えても知識は増えず、検索対象が増えるだけですよね。

1-4.若手は完成図面から、「なぜそうしたか」までは学べない

完成図面を見れば寸法や納まりは分かります。でも、何案を比べ、どの条件を優先し、何を諦めたのかまでは分からない。だから形は模倣できても、条件が変わると応用できないんですよね。

3D上で複数案を並べ、利点と制約と不採用理由を残せれば、若手は結果ではなく考え方を追体験できます。ただし、モデルを見せるだけでは教育になりません。どこを見てほしいのか、何を比較したのか。そこまで言語化して、ようやく伝わります。

1-5.成功も失敗も、個人の記憶に戻ってしまう

案件が終われば、チームはすぐ次へ移ります。振り返る余裕は、正直ほとんどないですよね。結果として、失敗は個人の反省として残り、成功は「あの人だからできた」と評価される。退職すれば、経験ごと抜けていきます。

組織学習とは、資料を大量に保存することではありません。ある案件で得た判断を、別の案件で、別の人が使える形に変換することです。3Dはその手段になりますが、分類と振り返りの運用がなければ、やはり眠ったままです。


2.3D可視化は、組織課題をどう変えられるのか

5つをすべて「3Dモデルがないから」と説明するのは正確ではありません。情報の抜け落ちには議事録と承認フローの、効率低下にはファイル管理の、人材育成には教育設計の問題がある。3D可視化にできるのは、それらを解決しやすい土台をつくることです。

言葉だけだと「ここ」「もう少し広く」が各自の頭の中で違う空間を指しますが、同じ3D空間を見ながらなら、少なくとも「ここ」は一致する。評価は分かれても、何について意見が違うのかは明確になりますよね。

コメントを空間の特定位置と結びつければ、「梁に注意」が、どの梁で誰がいつまでに何をするのかという行動に変わる。初期案、変更案、最終案を並べて判断理由を残せば、後から参加したメンバーも流れを追えます。ただし、この役割を担うツールは一種類ではありません。


3.3Dツールは、目的によって三つに分けて考える

三つを機能で比べても、たぶん選べません。見るべきなのは、そのツールにどの種類の知識が残るのかです。

思考の途中が残るのか。設計と施工の問題の処理履歴が残るのか。顧客との合意過程が残るのか。残したいものが違えば、答えも変わります。


3-1.MEs|思考の途中を残す3Dコラボレーション空間

MEsは、3D空間の中にWebページ、動画、テキスト、画像などを配置し、チームで共有できるバーチャルコラボレーションツールです。

完成した建築モデルを精密に検証するというより、アイデア、参考資料、議論の途中経過を一つの空間に集める用途に特徴があります。開発者への取材では、建築家が考えていることを3D空間上に展開し、プロジェクトルームのように共有する考え方が紹介されています。

たとえば、コンセプト模型、参考建築、素材写真、検討中のスケッチ、クライアントの要望を同じ空間に配置すれば、完成案だけでは見えない思考のつながりを残せます。

これは、若手が先輩の思考過程を理解したり、途中参加したメンバーが検討の流れを把握したりする際に役立ちます。

一方で、MEsは実施設計の図面整合や、高品質な顧客提案パースを主目的とするツールではありません。自由度が高い分、何をどの形式で残すかをチーム内で決めなければ、情報が散らかった空間になる可能性もあります。

向くのは、コンセプトと参考資料の共有、設計プロセスのアーカイブ、チーム内のアイデア発散、そして過去案件を学習空間として残すこと。逆に、詳細な図面整合、構造・設備の干渉確認、短時間での住宅提案パース作成には向きません。

3-2.BIMビューア|設計と施工の問題をモデル上で管理する

Autodesk Construction CloudなどのBIM系クラウド環境では、ブラウザ上でモデルを閲覧し、各専門モデルを重ね、指摘事項をモデルの位置と結びつけて管理できます。

BIMビューアの強みは、見栄えのよいプレゼンテーションを作ることではなく、問題の場所、担当者、対応状況を設計・施工情報と結びつけることです。

意匠・構造・設備を統合し、干渉や検討事項を課題として残せば、「会議では指摘したのに誰も対応していなかった」を抑えられます。

ただし、BIMビューアを使うには、閲覧するモデル自体が適切に作成・更新されている必要があります。

モデルの座標、命名、権限、更新時期が統一されていなければ、「同じモデルを見る」以前に、どれが正しいモデルか分からなくなります。また、大規模モデルではブラウザ上の表示や操作が重くなる場合もあり、データの構成と運用設計が欠かせません。

向くのは、意匠・構造・設備モデルの統合確認、干渉や設計課題の位置管理、担当者と期限と対応状況の記録、そして設計から施工への情報引き継ぎ。逆に、CADに不慣れな顧客との初期商談、素材や家具をその場で何案も比較する提案、モデルがまだ存在しない初期段階の検討には向きません。

3-3.Coohom|提案と合意形成を速くする

Coohomは、住宅やインテリアを中心としたクラウド型3Dデザインプラットフォームです。

2D間取りの取り込み、家具や建材の配置、素材変更、クラウドレンダリング、360度パノラマなどを一つの環境で行えることが特徴です。本来の強みは、頭の中にあった案を早く見える形にして、チーム内の判断と顧客との対話を表面化させることにあります。そのため、初期提案、素材と家具の比較、営業を含めた社内共有、方向性を決める工程に向いています。


4.Coohomが変えられる四つの組織プロセス

4-1.案を早く見せて、説明の出発点をそろえる

従来は、設計者が2D図面を作り、必要に応じて別の担当者が3Dやパースを作ります。この間に時間が空くと、設計者が考えていた案と3D担当が表現した案の間にもずれが生まれる。完成パースを見て初めて家具の密度や素材の組み合わせに違和感が出ることもありますよね。

間取りを取り込み、ライブラリから家具や建材を配置して早い段階で空間を確認できれば、この順番が変わります。大事なのは「3日が必ず1日になる」という一律の数字ではありません。効果は、完成度の高い案を一度で出すことではなく、検討の早い段階でチームが同じ空間を見られることです。

若手の案を上司が3Dで確認すれば、動線は成立しているか、家具のスケールは適切か、収納が圧迫感を生んでいないかを、図面上の抽象的な赤入れではなく、空間との関係で伝えられます。

4-2.比較を見せて、設計者の判断を言葉にする

AIの自動レイアウトが熟練者の「コツ」をそのまま抽出してくれると考えるのは危険です。生成された配置はあくまで検討案で、敷地条件、顧客の生活、法規、施工性まで理解した最終判断ではありません。

ただ、複数案を短時間で作れること自体は教育の材料になります。若手が三つの家具配置を作り、先輩と同じ画面を見ながら「この案は入口からリビングへの視線が家具で止まる」「こちらは通路幅は取れるが、ダイニングとキッチンが遠い」「顧客が重視していた収納量を考えると、この案が妥当」と話す。この瞬間に、暗黙的だった判断基準が言葉になります。

教育効果を生むのはAIの出力ではありません。複数案を比較し、採用・不採用の理由を残す運用のほうです。

4-3.営業、設計、顧客のあいだの翻訳を減らす

営業が聞いた要望を設計者に伝え、設計者が案を作り、再び営業が顧客へ説明する。人を経由するたびに、情報は少しずつ変わりますよね。

3D空間を共通の確認対象にすれば、営業が設計意図を自分の言葉だけで再現する必要はなくなり、顧客も図面の読み方を覚えてから意見を言う必要がなくなります。素材や家具を変えながら確認できるので、「ナチュラル」「高級感」といった曖昧な言葉も具体的な選択肢に変わっていく。

ただし、操作が直感的であることと、誰でも設計提案ができることは別です。営業がその場で変更しすぎると、条件やコストを確認しないまま実現可能な案として顧客に受け取られる危険がある。営業が変更できる範囲、設計者の確認が必要な項目、参考イメージと確定仕様の違いは、先に決めておく必要があります。

4-4.「誰かのPCにしかない案」を減らす

個人の経験を組織資産に変えるには、担当者以外がデータへ到達できることが前提です。リンク共有やチーム内での編集・管理の仕組みはありますが、共有範囲や編集権限は契約プランやワークスペース設定で変わるため、閲覧リンクの共有と共同編集は分けて考える必要があります。

よく使う家具や建材を共通ライブラリとして整備すれば、毎回ゼロから探す作業も減ります。CAGUUUの公開事例では、3,000点以上の商品を3D化し社内ライブラリとして利用できる環境を構築したことが紹介されています。設計事務所の標準部材とは目的が異なりますが、商品データを個人所有から共通資産へ変えた例として参考になります。

ただ、クラウドに置けば自動的に知識資産になるわけではありません。プロジェクト名の付け方、完成案と検討案の区別、標準として再利用する案を誰が選ぶか、退職者のデータをどう引き継ぐか。こうしたルールがあって初めて、クラウドは「最新版を置く場所」から「学べる場所」へ変わります。


5.5つの組織課題と、ツールの対応関係



6.「個人経験」を組織資産に変える実務フロー

いきなり全案件を3D化するのは現実的ではありません。まず一つの案件で、この流れを試すのがいいと思います。

Step 1.学びたい問題を一つ決める。「若手育成を速めたい」では広すぎます。家具配置のレビューに時間がかかる、顧客との素材決定が長引く、といった観察できる問題まで絞ります。

Step 2.3D化する範囲を限定する。建物全体を作り込む必要はありません。問題がLDKの提案ならLDKだけ。3Dを作ること自体が新たな負担になれば、目的を失いますよね。

Step 3.比較案と判断理由を残す。最終案だけでなく比較案を残し、各案に利点と問題、顧客の反応、採用・不採用の理由を短く添えます。

Step 4.チームレビューに使う。若手の3Dを上司が直して完成させるだけでは、個人作業の代行で終わります。まず本人に、何を意図し、何を迷い、どの案を推すかを説明してもらい、上司はその後に判断の観点を補います。

Step 5.終了後に、再利用できる知識を抜き出す。案件を丸ごと「成功事例」として保存しても、別案件では使いにくい。狭いLDKでの家具配置、収納扉とベッドの干渉確認といった単位まで分けて、チェックリストやテンプレート、教育教材へ反映します。

ここまで行って初めて、案件経験が組織の筋肉になります。


7.導入効果は、「きれいなパースの枚数」では測らない

レンダリング枚数やモデル数で評価すると、本来の組織課題から離れてしまいます。見るべきなのは、仕事の流れがどう変わったかです。

若手が一人で初期案を作れるまでの期間と、上司の手直し時間。最新案を探すのにかかった時間と、認識違いによる再説明の回数。初回提案から方向性決定までの日数と、持ち帰り修正の回数。そして、同じ失敗の再発件数。これらを導入前後の数案件で比べます。


8.ROIは、先に数字を作るのではなく、実測する

「3か月で回収できる」といった数字は魅力的です。でも、人件費も案件数も利用プランも事務所ごとに違いますから、回収期間を断言するより、自社の実測値から計算するほうが安全ですよね。

年間効果=削減できた作業時間×社内時間単価 + 削減できた外注費 + 追加受注や追加請求による粗利 − 新しく増えた入力・管理時間のコスト

年間投資=ライセンス費用+初期設定時間+教育時間+ライブラリ整備時間+運用管理時間

ROI =(年間効果−年間投資)÷年間投資×100

たとえば月4案件で持ち帰り修正が平均2時間減ったなら、年間96時間。社内時間単価5,000円で48万円です。ここから、ライセンス費や教育、ライブラリ整備に使った時間を差し引く。3D作成に従来より時間を使ったり、比較案が増えて修正時間が伸びたりした場合は、それもコストとして入れます。

ROIの目的は、導入を正当化する数字を作ることではありません。どの工程では効果があり、どこで新しい負担が生まれたかを見つけることです。


9.導入しても、組織が学ばないケース

完成パースしか残していない。提案実績にはなりますが、判断過程の教材にはなりません。比較案と不採用理由が要ります。

上司が若手のモデルを直接直している。修正後のモデルだけ返しても、判断基準は伝わりません。まず本人に説明させ、上司は判断の観点を言葉にする。

誰でも自由に変更できる。閲覧、編集、承認の権限を分け、どの状態を正式案とするかを決めておく必要があります。

3Dが図面より正しいと思われている。提案用3Dは寸法や施工条件を保証しません。検討用イメージと確定図面の違いは、顧客にも営業にも明確に伝える。

データだけが増え、検索できない。案件名だけで保存すると、別案件から知識を探せません。案件種別、空間、問題といったタグが要ります。


結び:知識とは、保存されたファイルではなく、次の人が使える判断のこと

設計事務所には、すでに多くの知識があります。代表が経験から身につけた判断、若手が失敗から学んだこと、営業が顧客との対話でつかんだ感覚、施工担当が現場で見つけた納まりの問題。

問題は、知識がないことではありません。それらが個人の記憶や口頭の会話、完成図面の奥に隠れていて、必要なときに呼び出せないことです。

MEsのような3Dコラボレーション空間は、思考の途中や参考情報を一つの場所に集める。BIMビューアは、設計と施工の問題をモデル上の位置、担当者、対応状況と結びつける。Coohomのような3D可視化ツールは、案を早く形にして、営業と設計と顧客が同じ空間を見ながら判断する土台をつくる。三つは競合するというより、残したい知識の種類が違うんですよね。

そして、どれを使う場合でも必要なことは同じです。比較した案を残し、判断理由を言葉にし、最新版と検討案を区別し、案件が終わったら振り返って、次の案件で使える形に分解する。

個人の経験は、ファイルをクラウドへ移しただけでは組織資産になりません。別の人が見つけ、理解し、自分の案件で使い、さらに改善できる状態になって、初めて「組織の筋肉」になります。

まずは進行中の一案件で、すべてを変えようとしないことです。顧客との認識がずれやすい空間を一つ選び、3Dで比較案を作る。チームで判断理由を話し、採用・不採用の理由を残す。案件が終わったら、次に使える知識を一つだけ抜き出す。

小さな運用ですが、この繰り返しが、担当者が変わっても学び続けられる事務所をつくります。

次回:事業の取捨選択とDXロードマップ——蓄積した知識を、どの事業に集中させるか


参考資料

• MEs紹介(Build App News):https://news.build-app.jp/article/33058/

• Autodesk Construction Cloud / Model Coordination:https://static.au-uw2-prd.autodesk.com/Class_Handout_CS500123_Walker-AU2021.pdf

• Autodesk Support:https://www.autodesk.com/support/technical/article/caas/sfdcarticles/sfdcarticles/Model-Coordination-crashes-when-viewing-all-models-at-once-in-ACC.html

• Coohom日本公式:https://www.coohom.com/jp

• Coohomヘルプセンター:https://www.coohom.com/jp/helpcenter/3FO4K4WCN9E8

• CAGUUU導入事例(PR TIMES):https://prtimes.jp/main/html/rd/p/000000006.000174166.html