AMDlabってどんな開発してるの？

はじめまして。株式会社AMDlabのCTO、松原です。

AMDlabは、2019年に立ち上げた建築テックの会社です。
「建築をつくる人を、笑顔にする」
をミッションに、建築系のアプリケーション開発や建築設計、教育活動などを通して建築業界のDXを推進しています。

まだまだ無名な会社ですが、起業から今日に至るまで、実は結構な数のプロダクトを開発してきています。どこかの会社とのミーティングで「あの会社がこんなシステム作ったらしいねっ！」と言われ「おぉ、そうなんですね…！（その開発ウチがやってるんだよなぁ）」と知らないフリをすることも多々あります。
最近は、協業・共同開発という形で名前を出してもらえる機会も増えており、「AMDlabとコラボレーションすることが広告となる」、そんな位置に少しずつ近づけているのではないかと思っています。

業務

AMDlabの開発業務は3つに分けられます。（建築の設計業務もしてますが、開発の業務に絞った話をします）

受託開発
共同開発・共同研究
自社プロダクト開発

弊社は、ファイナンスは行っておらず自社のキャッシュだけでまわしている会社です。受託で得た利益を自社プロダクト開発に充てています。いずれは調達も選択肢の一つとして考えていますが、半端な状態ではなく、自社内でプロダクトをある程度固めてた上で加速・拡大していきたいと考えています。

AMDlabでは、社員は全員「2つのプロジェクトに関わる」という方針をとっています。「自社プロダクトと受託開発」「自社プロダクトと共同開発」というように、自社プロダクト半分、外のプロジェクト半分という形で仕事をするようにしています。
何故そのような方針をとっているかというと、1つのことしかやれない状況では、技術も思考も偏ってしまいますし、複数に関われるのであれば「こっちでやった内容をあっちでも用いる」「あっちの失敗をこっちでは起こさない」というような、プロジェクト間でのフィードバック環境ができると考えているからです。（それと、1つだけだと飽きます←こっちが本音かもしれない）

受託開発

AMDlabは、建築設計のノウハウとテクノロジーを掛け合わせて新しい価値を提供している会社です。そのため顧客も大半が建築関係の会社さんです。顧客側でつくりたいものが明確に決まっていないことも多いので、コンサルから入り開発まで一貫して行うことがほとんどです。

依頼の内容は様々ですが、大きく分けると2つ。

BIM
シミュレーション・自動化

BIMとは、Building Information Modelingの略称で、属性情報をもった3Dモデルの部品を組み立てて建物の設計を行う手法、または、それが行えるソフトウェアのことを指しています。組み立てていくだけでいいのか！？と聞こえますが、実際はそう楽できる仕組みではないんです、これが。CAD時代にブラックボックスにされていた内容が見えてしまうから作業が増えたりする一面もあったり…

近年、設計・施工でつくったBIMのデータをもっと活用できないか？というのが建築業界のもっぱらの課題となっています。
施工の墨出しのロボットに用いたり、建物の維持管理に使えるようにしたり、各社がアイディアを様々な形でリリースしています。そんなアイディアを形にする時に相談されているのがAMDlabです。
BIMを用いたビルの管理システムが作れないか（某警備会社さん）、建物にセンサーを付けてBIMのモデルとつなげられないか（某ゼネコンさん）、BIMのデータを用いて施工の調達管理ができる仕組みが欲しい（某ゼネコンさん）などなど、そんな思いをこれまで具体化してきました。

そんなアイディア競争の一方で、BIMが一般的になるにつれて膨れあがる作業が各社でてきており、それらを自動化したいという話がでてくるようになりました。また、BIMだからこそもっとやらなければと、様々なデザインパターンを生成させたり、立体的なシミュレーションを行いたいという話もでてくるようになりました。事例が増えたからですかね…？そういった時にも相談されているのがAMDlabです。

▼駐車場の設計の自動化

そのアウトプットも様々です。Webのシステムとして提供したり、BIMのソフトのプラグインとして提供したり、機械学習させたモデルを提供したり、VR・MRのコンテンツとして提供したり、依頼内容に適したソリューションを毎度お届けししています。そのおかげかそのせいか、会社には多岐にわたる知見が蓄積されていっています。

共同開発・共同研究

経路は受託開発と似ていますが、その企業と一緒にやる、というプロジェクトが増えてきています。大変ありがたい。創造系不動産と運営をしている「建築家住宅手帖」、LIXILと開発を進めている「A-SPEC」、リリースはしていないですが現在進行形で進んでいるプロジェクトもちらほら。
産学連携にも重きを置いており、大学とも進めているプロジェクトも今いくつか抱えています。

また、このあたりの詳細は別のストーリーにて。

自社プロダクト

私と代表の藤井は、大学で建築を勉強し、建築の設計事務所に就職し、建築の設計を実際にやってきた人間です。だからこそ、学術においても産業においても、建築という分野で「もっとこうだったらよかったのにな」という後悔もあれば、「あれはこうすることもできるよな」という可能性も知っていたりします。「ITの技術者」ではなく、「建築の設計者」としての人脈もあります。
中に居る時は実現できない、外から来ても実現できない、そんなことを私達は実現しうる力を今持っています。

その力を使って、AMDlabは自社のプロダクト開発を鋭意進めています。

開発しているプロダクトは、3つあります。

AMDhaus（エーエムディーハウス）

「AMDhaus」は、AMDlabが提供するオンラインの建築学校です。様々な分野の第一線で活躍されている方から建築の知識や技術を学ぶことができるプロダクトです。β版ですが、すでにリリースしてサービスの提供を開始しているプロダクトです。どう運用していくのか、どんな機能がいるのか、どうマネタイズするのか、まだまだ詰めなければならないことばかりですが、ユーザーも増えてきており徐々に価値が見え始めているプロダクトです。

建築家DB（ケンチクカデータベース）

「建築家DB」は、ほぼ名前の通りですが、建築家と建築物の情報を集めたWiki的なプロダクトです。まだリリースはしていません。プロダクトの開発を進めると同時に、「建築家DB」というプロジェクトとして、建築家の情報収集を某大学と協力して行っています。それ以外にも、隔月に建築家の方を招待してセミナー（第三回 → https://peatix.com/event/3079819/view）を開催するなど、建築家に関する情報発信も「建築家DB」というプロジェクトとして行っています。

DDDDbox（フォーディーボックス）

イラスト: イスナデザイン

「DDDDbox」は、建築設計業務の為のプロダクトです。こちらもまだリリースはしていません。絶賛開発中です。AMDlabが思う「建築の設計業務がこうなるべき」をシステムとして落とし込んだらどうなるか、それを形にしていっているプロダクトです。まだ詳細を語れないのですが、3Dモデルをガンガンに用いるプロダクトになる予定です。

技術スタック

様々な業務に対し、AMDlabはどんな技術を用いているのでしょうか？

答えは…使う技術も様々です。適材適所、その時にそのプロジェクトに合うと思われるものを採用していいます。なので、たまに特異な技術が入ることがありますが、基本的には以下の通りです。

【プログラミング言語/ライブラリ/フレームワーク等】

フロントエンド

HTML, CSS, JavaScript, TypeScript, React, Gatsby, Next.js, Vue.js, Nuxt, Rust（Web Assembly）

自社サービスではReact、Next.jsをメインに使っています。

バックエンド

Go, Gin, Echo, ent, GORM, Rust, PHP, Laravel, Python, Django, Ruby, Rails, TypeScript, Node.js, NestJS

自社サービスではGoが主要言語ですが、3Dまわりの実装で最近Rustが活躍し始めています。

デスクトップ

C#, .Net framework

BIMのプラグインなどはC#を使って開発しています。

その他

gRPC, GraphQL

【インフラ】

GCP, AWS, OCI

自社サービスではGCPを主に使っています。

【ミドルウェア等】

Redis, NGINX, Apache Spark, Cloud Pub/Sub, Cloud Functions, AWS Lambda, Cloud Tasks

【データベース・ストレージ】

Cloud Spanner, Cloud SQL, AWS Aurora, AWS Neptune, Dgraph, BigTable, Google Cloud Storage, Amazon S3

【モニタリング】

Sentry

【環境構築】

Terraform, Pulumi

【コンテナオーケストレーション】

Kubernetes（EKS）, ECS, OEK

【CI】

CIGitHub Actions, CircleCI

【機械学習】

scikit-learn, TensorFlow, PyTorch

【サーチエンジン】

Elasticsearch

【コード管理】

GitHub, Bitbucket

Goがメインの会社ですが、私自身はRustの虜です。

大事にしていること

プロダクト開発の仕方は、会社によって面白いぐらい色がでます。その中でたまに出会うのですが、色のない開発は、大抵酷いプロダクトになっている、というのは私の経験則です。
良い物をつくるためには、何かしらの思想が必要だと思っています。ですので私自身も思想を持つよう心がけているのですが（心がけるものなのか？）、今日はその一部をここに書いていこうかと。

1.会社として開発して、会社として運営していくこと

1人で開発するなら、「よしっ、今回はNimでも使って作ってみるか」なんてこともしかねない私ですが、頭に入れておかないといけないのが「会社として開発して、会社として運営していく」ということです。そのためには、可能な限り外部のサービスを使って、自分達でつくらないことを目指します。
何から何まで0から作ろうとする会社にも参画させてもらっていたことがあります。サービスがローンチされると、終わりの見えないエラーログ、鳴り止まない電話、直しても直しても生まれるバグの数々……生きながらにして地獄を味わいました。そんな経験もあって、簡単に「作ってみよう！」なんて判断はせず、会社として運営できる形を常に頭に描いて方針を決めています。
メール配信？それならSendGrid使おう。データを分析したい？Tableau使おう。管理画面？AdminBroでざっくり作ってしまおう。そんな感じです。

2.トレンドの採用

技術はすぐに陳腐化します。ここ数年のフロントエンドの変遷には少し辟易してはいますが、人は改善に向けて動いているはずなので、トレンドの先を掴むことはプロダクトとしても良いことが多いはずです。（先過ぎると自爆することもありますが）ライブラリ然り、言語然り、隙あらばリプレイスも検討事項に入れて常に新しいを取り込めるように判断しています。

3.技術によるコアコンピタンスを生み出すこと

他でもやれる技術を用いて作り上げたプロダクトは、プロダクト自体のコンセプトであったり、UI・UXであったりで他と差を付けることができるものの、最終的に「勝負所がエンジニアリングではないところ」で決まってしまうのでは…という恐怖を最近は感じています。
様々な便利なライブラリが生まれ、インフラも簡易的に立ち上げられるようになり、さらにはAIがコードを書いてくれるなんてこともできるようになり、開発のハードルが昔より下がって、多くの会社がプロダクトをつくれる社会になって来ているなと日々感じています。それ自体は善だとは思ってます。
ただ一方で、似たようなプロダクトを生み出しやすく、マーケティングやCSが決め手となるような社会にもなっていっているではないかと…
先日、某会社の某ARコンタクトレンズを見る機会がありました。あぁ、これはまさしく技術だなと。簡単にはリプレスできない技術だなと。
AMDlabの会社のバリューに「Challenging Geek」という言葉を掲げています。その言葉に込めた意味の通り、難易度の高いこと、時間がかかること、ニッチなことに挑戦するよう方針を決めるようにしています。この方針が、プロダクトの個性を産み、最終的にはそれが会社としてのコアコンピタンスになりうると思っているからです。技術が固ければサービスも自然と固くなると思っています。技術以外のところで勝負することも大事ですが、技術自体での勝負を避けてはいけないと…きっとそれが良いサービスに繋がると信じています。

3は、「いや時間がかかるので」…と嫌な顔をされがちで、また、1とも矛盾することもあるのですが、私が最も大事だと思っていることです。ですので、似たライブラリはあるけど、この要件を完全に満たすためには…なら…つくるぞっ！という判断をくだすことようにしています。もちろん3に寄りすぎれば崩壊するので、バランスはもちろん考えていますが。（要件を満たせるライブラリあるのにつくるなんてことも、もちろんしないですよっ）

こんなことを考えながら日々開発を進めております。