たまには真面目な話。
長い事、【IT】と【住宅】・【建設】を生業としていると、時間とともに、自ずとプロ化する。
勿論、なんでもシステムが解決すると思うと間違う。業務や運用ルールが不整備なケースが多々ある。ここをきちんと説明して提案できることが重要。建物の設計は、デザインは誰（建築家や設計事務所）と決まっているが、システムにはない。企業単位だ。これが問題。プロ化を阻害している。
このシステムデザインは誰。バイネームにすべきである。
これがないがために、付加価値が低くなっている、工数（費用）は【人月単価＊期間】という、能力と比例しない費用が登場してしまう。労働型なので、早くて良いものを作ると儲からないのだ（契約種別は未考慮）。このことも手伝って、無責任な部分が存在してしまう。
実際、住宅や建設の自動設計を長く手掛けていると、ヒトとシステムの関係で気が付くことがいくつもある。お互いの良いところの発見とあるべき処理の姿と言い換えてもいいだろう。それは世の中の原理にも似ている。性質の異なる素材をつなぐ方法とか、くっ付けてもヒビ割れしないとか、そういうようなものだ。なるべくプリミティブな上流で加工して成立できるプロトコルをつくる。これが肝心。データをいじると目的から外れ意味を失うことがある。そうなると泥沼。複雑よりシンプル、ここが大切。
さて、建設のこと。
敷地を読んで、即座にイメージが湧くのが人間の良いところだ。法規の詳細は横に置いて、頭のなかで複数のイメージが出来上がる。同じ用途地域なら近隣の建物をみると建物の制限が理解できるし、周辺環境や予算などを読んで日当たりや防火などのイメージも湧く。柔らかいゾーニング部分だ。
ゾーニングのような、このボワーッとした部分、実際、このようなことが、システムは苦手。真面目過ぎるのだ、ボワーッとできない。直ぐに白黒をつけたがり、断片化したがる、システムの悪いところだ。自動設計でも方位や道路付、斜線や面積などの法規、近隣との関係、施主の要件、予算と考えて、サッと配置案を出すヒト。システムは手順を示さないと動いてくれない。
加えて、システムは工程や業務間の双方向行き来が苦手。
意匠、構造、設備、施工、積算、外構などの要素があって、ちょっと、予算を減らしたいとかクライアントが言っても、システムはどこを直せばいいのか、最適解を外部の決め事で定義しないと動いてくれない。エレベータをもう一基ふやすとか、口で言うのは簡単だか、最適な処理は当初から予定していないとできないのだ。
行き来、この部分でもう少し書くと、データ構造が解決の術となり得るのだが、残念ながら、現在は上手なデータ設計が乏しい時代だ。メモリが高かった時代の方が上手だったように思える。効率を考えなくともフンダンに使える時代のデメリットだ。もちろん、オブジェクト型で一元管理が容易な技術進展のデータ構造もある。メタ化や仮想化も進展した。だが、オールドスタイルが大半なことを考えると、苦言を呈したい。
このデザインで、構造的に正しく、法律的に問題なく、予算とスケジュールを遵守して建設する。
言葉で言うのは簡単だが、これをシステムで最適に処理するのは難しい。このルール化出来ないところに、AIテクノロジーなどの実績データを積み重ねて解を導くフィードバック系（数理モデル）が意味をもつ。
「ボワーッ」とした部分と「行き来」、これを上手に提案（設計）するのがITと業務に精通しているわが社のミッション（プロの技）、そう考えている。
