建築ドメインのキャッチアップについて

こんにちは。DDDDbox事業部で日々開発をしている鈴木です。

弊社では自社サービスとして建築設計SaaSの DDDDbox を開発しており、DXソリューション事業でも、建築ドメインを中心にしたプロジェクトを推進しています。

ddddbox.app

www.amd-lab.com

私はDDDDboxで、Webや3D（three.js / react-three-fiber）まわりの開発を中心に行なっていることが多く、前回まではその内容について記事を執筆いたしました。

今回は少し毛色を変えて、建築ドメインのキャッチアップの方法について語りたいと思います。

この記事は「建築バックグラウンドがないエンジニアが、建築ドメインの知識をどうキャッチアップするか」というテーマについて、私の実体験ベースで効果的な方法をまとめたものです。

だれのための記事？

建築系のドメイン知識を身につけたいソフトウェアエンジニアの方
建築に限らずドメイン知識の効果的なキャッチアップ方法が知りたい方
弊社AMDlabに興味はあるが、建築のドメイン知識がないため、選考に進むか悩んでいる方

ステップ1：建築の法規を学ぶ

建築では、建築基準法・都市計画法・消防法など様々な建築法規が、建築物の制約条件の体系となっています。

これらの法規による制約はソフトウェアエンジニアリングのベストプラクティスなどとは異なり、絶対に守らなければならない強い制約となります。

これらの建築法規を学ぶことは、建築ドメインの考え方のベースになってきます。

構造化して理解できる

建築をゼロから理解しようとすると、「平面図」「日影規制」「構造計算」「確認申請」「BIM」などの無数の用語や概念があります。一つ一つの用語の意味はその度に調べれば理解できますが、ある用語の説明にまた別の専門用語が登場してきたり、用語同士の関連をつかむことが難しいです。

これは、まるでプログラミング初心者にオニオンアーキテクチャのアプリケーションをいきなりコードリーディングさせるようなものです。 if文やfor文、プログラミング言語の種類、Webサーバーとは何なのか、そもそもVS Codeとは、などいろんなレイヤーで疑問が浮かぶはずです。

しかし、法規をベースに学ぶと、それぞれの概念がなぜ存在するのか、どう関連しているのかが構造化して理解できます。その法規に準拠していることを示すために、様々な数値や計算式や図面が必要であることがわかります。いわば、全体のドメインモデルが頭の中にできる感じです。

例を挙げてみると、「第1種低層住居専用地域」「商業地域」「準工業地域」などの用途地域は、ドメイン知識のない状態だとただのEnum値にしか見えませんよね。

しかし、法規をベースに学ぶと、これらの用途地域はそれぞれ異なるルールを持っていることがわかります。建蔽率・容積率の上限、建築制限のルールである斜線制限（道路斜線、隣地斜線、北側斜線）のルール、さらにこれらにはルールの緩和や例外があることなども理解できます。

つまり、「用途地域というのは単なる分類ではなく、建築のビジネスロジックを決定する重要なパラメータである」ということがわかります。

またそもそも用途地域は日本全国すべての地域に割り当てられているのではなく、原則として都市計画区域内のさらに市街化区域にのみ割り当てられることなど、上位の概念も押さえることができます。

誰とでも対等に議論できるツールになる

もう一つの大きなメリットとして、建築法規をベースにすることで、顧客を含むドメインエキスパートと対等に質問・議論することができます。

例えばソフトウェアの世界で、アーキテクチャ設計や複雑なドメインロジックについての会議をするときには、幅広いソフトウェアエンジニアリングの知識が必要になってしまい、新人がすぐに議論に参加するのは難しいと考えます。意見の根拠をなかなか出しづらいためです。もちろん有名書籍などを根拠に議論することはできますが、書籍に書いてある内容も銀の弾丸ではないので、結局ケースバイケースということが多いためです。

しかし、ソフトウェアの世界でもセキュリティ関連や著作権関連、個人情報保護法やGDPRなどの分野であれば、法規をベースに新人とベテランが対等に議論することができますよね。ケースバイケースなどではなく該当する法規には準拠しなくてはならないためです。

建築の場合は、法規の内容が広範にわたるため、それが顕著です。プロジェクトに参画してまもない時期で、ほとんどドメイン知識がない状態でも、ある分野における法規を頭に入れておけば、プロダクトオーナーから提案された仕様について、法規をベースにドメインエキスパートと議論することができます。「この仕様は(建築基準法第52条の)容積率の規定に抵触しませんか？」「ここに建築する場合は特定行政庁の許可が必要ですよね？」といった質問ができるわけです。

建築士の資格を持っていなくても、法規は必ず守らなくてはいけないものなので、対等に議論ができます。

建築法規のキャッチアップ方法

私の場合は、まず法規の全体像をつかみたかったので、書店に行って1冊の建築法規本を選び、一通りざっと読んだ後はプロダクト開発に役立ちそうなところや関連する箇所を適宜読み直しています。または全てを読むのは時間がかかるので、必要なところだけを読むというのも効果的だと思います。

具体的には、建築基準法の総則、用途地域、建蔽率・容積率、斜線制限、日影規制あたりを重点的に読みました。

また、書籍に法律の条項が記載してあれば、原文を確認してみるとよいです。法律は改正されるので、書籍やWeb記事で紹介されている内容が古い場合もありますし、原文を読むことで書籍などの２次情報への理解度が高まります。 e-Gov法令検索（https://elaws.e-gov.go.jp/）で建築基準法や建築基準法施行令を検索すれば、最新の条文を確認できます。

このあたり、ブログ情報ではなく、公式ドキュメントやソースコードを読め！っていう感覚に近いですね。

なお、書籍であれば個人的には物理本をお勧めします。

ステップ2：成果物のフォーマットや位置付けを把握する

建築業務での成果物としては、成果図書と呼ばれる各種説明書や計画図、各種図面などがありますが、最終的に提出するフォーマットがおおよそ決まっています。エンジニア視点でいうと、出力されるJSONやYAMLの仕様がおおよそ決まっている状態です。

この成果物をつくるために様々な業務が必要になるので、このフォーマットを理解することで、「どんなデータが必要か」「どんな計算処理が必要か」「どんな表現が必要か」が自然と見えてきます。

メリット1：法規との紐付きが明確になる

建築の成果物に載せる情報には法規との紐付きがあるものが多くあります。

例えば、配置図に敷地境界線や道路境界線を記載するのは、建蔽率や容積率、斜線制限などの法規チェックに必要なためと考えられます。

日影図が必要なのは、建築基準法の日影規制をクリアしているか確認するためです。

成果物のフォーマットを見ることで、法規との紐付きが明確になり「この法規に準拠してることを示すためにこの資料が必要」という関連が理解できます。

メリット2：ユーザーが必要としているものを把握できる

建築設計の成果物は、誰が・いつ・どの工程で・何を伝えるために作るかという業務の意図と密接に結びついています。ソフトウェアがこの文脈を無視すると、ユーザからは「使えないツール」という印象になってしまうでしょう。

成果物のフォーマットや位置付けを押さえておくことで、ユーザーにとって業務上重要な情報が何なのかを把握することができます。

例えば、配置図では敷地境界線に道路境界線や隣地境界線といった境界の種類名を書き込んだり、真北の向きを示す記号、道路斜線の後退距離や、敷地と隣地との高低差などを書き込みます。部材種類や部屋割りなどはここには記載しないことが多いでしょう。

仮に配置図を丸ごと出力する機能をつくるとしたら、これらの項目を設定するUIやその項目自体のデータフローを考える必要があります。ただし部材種類や部屋割りの設定をする機能はこの段階では利用できなくてもよいということが判断できます。

つまり成果物から必要になるであろう機能やUIを逆算することができます。

また、機能仕様に迷っている場合でも、機能から離れて成果物のフォーマットを見ることで、必要な情報を再整理することもできますね。

フォーマットの差異について

自治体や会社によって成果物のフォーマットに差があることがあります。記載する項目は共通でも、レイアウトや表現方法が異なることがありますが、どう表現しているかが変わるだけで、示したい内容は同じであることがほとんどです。ソフトウェアで言えば、背後のロジックは同じだけど見せるUIが違う、というような感じです。