What we do
Nexadataは、建設DX事業とシステムインテグレーション（SI）事業の二つを並行して運営しています。
①建設DX事業：積算プラットフォーム「SAKUJI」
積算とは、図面を読み解き、必要な材料と数量を一つずつ拾い出して工事の見積をつくる業務です。受注の入口にあたる重要な工程でありながら、図面の描き方は会社ごと・案件ごとに異なり、凡例が省略されていることも珍しくありません。結果として、数十年の経験を積んだ人にしか任せられない仕事になっています。
SAKUJIは、この拾い出しをAIが担い、専門オペレーターが精度を担保するプラットフォームです。ソフトウェアを渡して終わりにしないのは、建設の図面が例外の集合体であり、現時点の技術ではソフト単体で実務に耐える精度に届かないからです。AIが処理できる範囲を毎週広げながら、届かない部分は人が引き受ける。この構成を意図的に選んでいます。
主な提供先は、地方のゼネコン・サブコン、そして一人親方です。大手ではなくここから始めているのは、より切実に困っているからです。大手には内製の積算部門がありますが、地方の中小企業では、社長や職長が現場を終えた後の夜に見積をつくっている、という状況が普通に存在します。
②SI事業：建設業・製造業を中心としたシステム開発とDX支援
もう一つの柱が、レガシー産業向けのシステム開発とDX支援です。この事業には二つの意味があります。一つは、外部資金の調達サイクルにプロダクトの意思決定を縛られないための収益基盤であること。もう一つは、実際の業務プロセスがどこで詰まっているのかを、顧客の内側から学べる場であることです。SAKUJIの仕様の多くは、この事業で見た現実から逆算されています。
二つの事業は分断していません。SI事業で得た知見はプロダクトに流れ、プロダクトで培った技術はSI事業のデリバリーを速くします。
積算は入口にすぎません。図面、原価、見積といった建設業の意思決定に必要なデータは、いまだに各社の紙とExcelの中に分散しています。私たちは積算を起点にそれらが集まる基盤をつくり、建設業のインフラになることを目指しています。
Why we do
日本の建設業就業者は、1997年のピーク時に685万人でした。現在はおよそ477万人で、約3割減っています。年齢構成を見ると、55歳以上が約36％を占める一方、29歳以下は約12％にとどまります。2024年4月からは、時間外労働の上限規制も適用されました。人は減り、働ける時間も制限され、それでも建てるべきものはなくなりません。（出典：国土交通省資料、総務省「労働力調査」）
ただ、私たちが本当の問題だと考えているのは、人手不足そのものではありません。経験を積んだ人にしかできない仕事が、あまりに多く残っていることです。
積算はその典型です。図面を読み、施工の順序を頭の中で組み立て、材料を拾う。この工程は、数十年かけて身につけた勘と経験に支えられています。裏を返せば、その仕事が一人の頭の中にある限り、その人が引退した瞬間に、会社の受注能力そのものが落ちます。地方の建設会社では、これが現実に起きています。
私たちのミッションは「建設の矜持を、次世代へ紡ぐ。」です。
矜持とは、職人が自らの技術に対して持つ誇りのことです。効率化はその誇りを奪う行為だと受け取られることがありますが、私たちはそう考えていません。誇りが宿るのは、どう納めるかを決める判断と、現場で手を動かす技術の側です。図面から数量を数え上げる作業に、誇りは宿りません。
だから私たちは、誇りの宿らない時間をAIに渡し、人にしかできない判断に時間を戻すことを選びました。技術を捨てさせるのではなく、技術に集中できるようにする。それが「矜持を次世代へ紡ぐ」ということです。
この考えが机上の空論にならないよう、代表は週末、電気工事の現場に職人見習いとして入っています。積算の一つのズレが現場に何時間の手戻りを生むのか、それを言葉ではなく体で確かめるためです。
How we do
①体制
代表取締役CEO、CTO、COOの三名を中心に、社員・業務委託・学生インターンが加わる少人数のチームで運営しています。全員が同じ時間に同じ場所にいることは前提にしていません。管理しているのは在席時間ではなく、任せた仕事が前に進んだかどうかです。ただし、顧客の現場に立つべき日は必ず立ちます。
②意思決定
定例は短く、頻度を高く保っています。完成品を持ち寄る場ではなく、叩き台を持ち寄って潰す場として設計しているためです。判断を仰ぐ側には、案・判断基準・論点・自分自身の仮説をセットで出すことを求めています。「どうしましょうか」という問いだけを投げることは、判断そのものを他人に預ける行為だと考えているからです。
③プロダクトのつくり方
PMFに到達するまでは、スプリント型で毎週リリースし、毎週顧客の声を集めます。品質基準を最初から高く置きすぎると、間違った仮説の上に丁寧な実装を積み上げることになるからです。仕様は営業と開発が同じ場で決めます。営業が持ち帰った要求は優先度をつけて可視化し、開発側が優先順位付けまで背負う状態にはしません。
④開発プロセス
要件定義・設計・実装の各段階にAIによるレビューを組み込み、人間のレビューは要件定義に集中させる進め方を標準化しています。AIで顧客の業務を変えようとしている以上、自社の開発プロセスが旧来のままでは説得力がないからです。ここで確立した方法は、SI事業のデリバリー標準にも展開していきます。
⑤これから加わる方へ
完成した仕組みを運用したい方にとって、Nexadataは居心地の良い会社ではありません。定例の設計も、優先順位の付け方も、まだつくっている途中です。逆に、仕組みそのものをつくる側に回りたい方にとっては、これ以上ない量の余白があります。
