ひとつの大きなシステムを作らない建設業DXにおける「業務統合化」の、現時点での最適解
SUMMARYコンシェルジュ型の事業から建設業特化に至った経緯を振り返り（2006年1月設立で第21期）、建設DXが統合で止まる二つの理由を整理。バレーナクラウドを背骨に専門アプリを並べ、統合後も定額でカスタマイズできる設計と、BPO・コミュニオンの役割を解説する。
株式会社Office Concierge
代表取締役CEO 小松延顕
私たちは何をしている会社か
株式会社Office Conciergeは、建設業に特化して基幹業務のクラウド化・DX化を支援する会社です。2006年1月の設立から数えて第21期。
ただし、最初から建設業特化の会社だったわけでも、システム会社だったわけでもありません。社名のとおり、私たちはもともと「オフィスのコンシェルジュ」として始まりました。建設業に絞ると決めたのは2014年頃のことで、そこから今日までが「バレーナ」の歴史です。
現在、提供しているものは三つあります。
バレーナクラウド 見積から入金までを扱う基幹業務統合クラウド。会社の数字の正本になるシステム
バレーナBPO システムだけでは埋まらない部分を、人が代行して埋める建設業務代行サービス
バレーナコミュニオン バレーナを使う会社同士がつながる建設業界コミュニティ
この三つは別々の商品ではなく、ひとつの考え方から派生したものです。その考え方と、そこに至るまでの経緯を説明することが、この文章の目的です。
Office Concierge ─ コンセプトが先にあった
三つのスタンス
私たちの事業の原型は、1990年代末から2000年代初頭にかけてのOA機器営業の現場にあります。そこで見えてきたのは、お客様が本当に困っているのは「商品が足りないこと」ではなく、「誰に何を頼めばいいのか分からないこと」だという事実でした。
コピー機はA社、電話はB社、パソコンはC社、ネットワークはD社。それぞれに担当者がいて、それぞれが自社商品の話をする。困りごとが複数にまたがった瞬間、お客様は各社に同じ説明を繰り返し、責任の所在が曖昧なまま宙に浮きます。
そこで私たちは、ホテルのコンシェルジュを事業の型に据えました。株式会社Office Conciergeという社名は、事業の飾りではなく、ビジネスモデルそのものの定義です。 具体的には三つのスタンスからできています。
第一に、一人の担当コンシェルジュが窓口を一本化する。
お客様は「誰に言えばいいか」を考えなくていい。何であれ担当者一人に言えば、その先の切り分けと手配はこちらが引き受ける。困りごとが複数の領域にまたがるほど、この形の価値は上がります。
第二に、NOと言わない。「できません」ではなく「やってみます」。
これは無責任な安請け合いではありません。お客様が本当に困っている案件ほど、前例がなく、教科書に答えが載っていません。そこで「できません」と答えた瞬間、コンシェルジュとしての存在意義は消えます。だから、まずやってみる。やってみて分かったことを持ち帰り、また相談する。この往復そのものが提供価値だと考えています。
第三に、商品を売ることを第一の目的としない。
私たちが売っているのは課題解決であり、商品やサービスはその手段です。手段として最適なら他社製品を勧めますし、そもそも買わないほうがいいと判断すれば、そう申し上げます。目的と手段を取り違えないこと。これが、窓口を一本化しても信用が保たれる条件です。
たまたま出会った、一社の建設会社
このスタンスで仕事をしていた2010年、あるお客様からご相談がありました。建設業の会社で、使っていたパッケージソフトがちょうどリプレース時期を迎えていました。
そこで挙がった困りごとは、次の四つです。
場所の制約 オフィスに行かないと業務ができない。現場からも自宅からも触れない
同時利用の制約 複数人が同時にアクセスできない。誰かが開いていると待たされる
変更の制約 カスタマイズができない。自社のやり方に合わせられず、逆にソフトに合わせている
横のつながりの欠如 見積・原価・工事・請求とソフトがバラバラで、横軸の繋がりがない
この四つは、いま読み返しても示唆的です。2010年に一社の建設会社が語ったこの四点が、その後16年にわたる私たちの事業テーマそのものになりました。 現在のバレーナクラウドが「ブラウザだけで完結する」「同時に使える」「定額でカスタマイズし放題」「アプリが工事を軸につながる」という形をしているのは、この四つへの回答が積み上がった結果です。
このとき私たちが取った手段は、Claris FileMaker（当時のFileMaker Pro）による受託開発でした。パッケージを買ってきて当てはめるのではなく、そのお客様の業務に合わせて作る。商品を売るのではなく課題を解決する、という第三のスタンスの帰結として、たまたま自分たちで作るという手段を選んだというのが正確なところです。これがバレーナ事業のきっかけになりました。
なお、この時点では業種を絞っていません。建設業だから受けたのではなく、目の前のお客様が困っていたから受けた。結果として、それが建設業だったというだけです。
「要件定義は完成しない」という発見
受託開発を数年続けるなかで、確信に変わったことがあります。
お客様は導入前、「これができればいい」と要件を語ります。ところが実際に使い始めると、必ず「思っていたのと違う」「ここを直したい」が出てくる。担当者が不誠実だったわけでも、要件定義が雑だったわけでもありません。人は、使ってみるまで自分が本当に何を必要としているかを言語化できないからです。
これは能力の問題ではなく構造の問題です。であれば、「完璧な要件定義を最初に取ってから作る」という前提そのものが間違っている。取るべきは、使い始めたあとに変え続けられる関係のほうです。
そしてこの発見は、そのまま三つのスタンスと結びつきます。窓口が一本化されていて、NOと言わない相手がいるからこそ、お客様は使い始めたあとの「ここを変えたい」を言える。逆に言えば、こうです。
変更のたびに見積書が飛んでくるなら、お客様は「言わない」ほうを選びます。
言わなければシステムは現場から乖離し、やがて使われなくなる。
ここから、私たちの料金の考え方が決まりました。カスタマイズを、その都度の見積の対象から外し、定額の中に入れる。 要望を言うことにコストがかからない状態を作らなければ、システムは育たないからです。
2014年 ─ 四つを組み合わせる
受託開発は、一社ごとに深く応えられる代わりに、積み上がりません。同じような業務を、毎回ゼロから作ることになります。一方、パッケージソフトは積み上がる代わりに、お客様のやり方に合わせられない。まさに2010年のあの会社が抱えていた「変更の制約」です。
2014年頃、私たちはこの二択から抜ける道を決めました。業種を建設業に絞るという判断と、次の四つを同時に成立させるという判断です。
パッケージ ＋ カスタマイズ ＋ 業種特化 ＋ 定額制
四つの要素は、それぞれ単独では珍しくありません。組み合わせたところに意味があります。
パッケージ。 ゼロから作らない。建設業の共通部分は、最初から入っている状態で渡す。
カスタマイズ。 しかし、そこから先は各社のやり方に合わせて変える。「使ってみるまで分からない」に応えられる。
業種特化。 業種を絞るからこそ、パッケージ部分の完成度が上がり、カスタマイズの量が現実的な範囲に収まる。あらゆる業種を相手にしたままでは、この方程式は成立しません。
定額制。 カスタマイズを従量課金にしないから、お客様は要望を言える。要望が集まるから、パッケージ部分がさらに育つ。
四つは循環しています。業種を絞ることが定額カスタマイズを可能にし、定額カスタマイズが要望を呼び込み、要望がパッケージを鍛え、パッケージの完成度がさらに次の一社の導入を軽くする。 建設業に絞るという決定と、定額カスタマイズという料金設計は、切り離せない一つの判断でした。
こうして2015年1月、建設業専用のパッケージとして「バレーナ」を正式にリリースしました。
年表
1990年代末〜2000年代初頭 OA機器営業の現場で、「窓口一本化」「NOと言わない」「商品を売ることを目的としない」というコンシェルジュの型が形になる
2006年1月 株式会社Office Concierge 設立（2026年で第21期）
2010年 建設会社のパッケージソフトリプレース案件を、FileMakerによる受託開発として引き受ける。これがバレーナ事業のきっかけとなる
2014年頃 業種を建設業に絞る決定。同時に「パッケージ＋カスタマイズ＋業種特化＋定額制」の組み合わせを編み出す
2015年1月 建設業専用パッケージ「バレーナ」正式リリース
現在 累計納品社数500社以上・4,000ライセンス以上。後継となる「バレーナクラウド」を提供開始
建設業のIT化がたどる三つの段階
建設業に絞って11年、500社を超える導入現場を見てきて分かったことがあります。IT化の悩みは会社ごとにバラバラに見えて、実はほぼ全社が同じ順番で同じ壁にぶつかっているということです。しかもその壁は、2010年にあの一社が語った四つの課題の、そのまま延長線上にありました。
第1段階：業務ごとに、個別にIT化される
最初に起きるのは個別最適です。見積はExcel、原価もExcel、勤怠は打刻機、請求は会計ソフト、現場の連絡はLINE、図面はメール添付、名刺は担当者の引き出しの中。それぞれの担当者が、それぞれ一番手近な道具を選びます。
これは正しい進化です。一つひとつは安く、覚えることも少なく、明日から使えます。この段階を経ずにいきなり全社システムへ進むことは、実務上の難易度が高いです。
第2段階：個別IT化が一通り済むと、次のニーズは「統合」になる
個別のIT化が行き渡ると、必ず次の不満が出ます。
「見積の数字を、もう一度原価表に打ち直している」
「現場のLINEの写真が、どの工事のものか分からなくなる」
「勤怠の集計を、また別のExcelに転記して工事原価に乗せている」
「あの会社と付き合いがある社員が誰なのか、社内の誰も分からない」
道具が増えたぶん、道具と道具のあいだを人間が手作業でつないでいる状態です。個別IT化の効果は、この転記作業で相殺されていきます。2010年の四つの課題でいえば「横軸の繋がりがない」に該当し、これが最も根が深い。ここで初めて「統合したい」というニーズが生まれます。
第3段階：統合しようとすると、二つの袋小路に入る
そして、ここが本当の壁です。統合には二つの道がありますが、どちらも袋小路になりやすい。
袋小路A：既存の個別システムを、そのままつなごうとする
「今使っているものを活かして連携させたい」というのは自然な発想です。しかしこれは、その会社だけのための個別開発になります。連携の仕様は会社ごとに違い、片方のシステムがバージョンアップすればまた作り直しになる。統合の瞬間に、必ず個社カスタマイズが必要になるのです。費用も期間も読めず、多くの案件がここで止まります。
袋小路B：最初から統合された大規模パッケージを導入する
もう一つの道は、すべてが最初から入っている大きなシステムを買うことです。連携の心配はありません。しかし別の負担が発生します。
自社に不要な機能をどう無効化するか、逆に不足している機能をどう補うか。この取捨選択の判断に、膨大な労力がかかります。判断できるのは業務を分かっている人だけなので、社内で最も忙しい人の時間が何ヶ月も奪われます。しかも判断材料は導入前には揃っていません。先に述べたとおり、人は使ってみるまで分からないからです。結果として、機能の大半を使わないまま高い料金を払い続ける、あるいは導入プロジェクト自体が頓挫する、という事態が起こります。
個別IT化の先に統合ニーズが生まれるのに、統合の入口が二つとも詰まっている。 これが、建設業DXが「もう一歩」で止まり続けてきた理由です。
私たちの解 ─ ひとつの大きなシステムを作らない
BALENAは、この構造への回答として設計されています。
背骨と、そのまわりの専門アプリ
建設業の困りごとは、見積・原価・工事・現場・協力会社・職人・請求と、関わる人も使う場所もバラバラです。これを1本の巨大なシステムにすると、誰にとっても重く、覚えることが多く、結局使われません。
BALENAは逆の作り方をしています。バレーナクラウドを「会社の背骨」に据え、まわりに専門アプリを並べる形です。
現場監督は、現場のアプリ（バレーナルーム）。職人は、勤怠のアプリ（バレーナクルー）。営業は、商談のアプリ（バレーナセールス）と名刺のアプリ（バレーナカード）。購買は、協力会社とのアプリ（バレーナコネクト）。経理は、請求のアプリ（バレーナビルボックス）。
それぞれが自分の仕事の画面だけを使います。そして、そこで生まれた数字と事実は、自動的にバレーナクラウドの工事台帳へ集まります。
ひとことで言えば、「入力させて集める」のではなく、それぞれが自分の仕事をすると、数字が勝手に集まる。 これがBALENAプラットフォームの設計思想です。
なぜこの形が二つの袋小路を回避できるのか
袋小路B（取捨選択の労力）への回答。 各アプリは、ひとつの業務領域に絞ってシンプルに作られています。現場のアプリは現場のことしかしません。だから導入判断は「現場の情報共有をクラウド化するか、しないか」だけで済みます。全社の全業務を一度に棚卸しする必要がない。取捨選択の単位が、機能の一つひとつではなく、アプリという業務のかたまりになるため、判断が現場の実感で下せます。
費用面も同じです。必要なアプリだけを契約するので、使わない機能に払う分が発生しません。運用面でも、覚えるのは自分の仕事の画面だけです。導入のハードルが、費用・判断・教育のすべてで下がります。
袋小路A（統合時の個社カスタマイズ）への回答。 アプリ同士は、最初からバレーナクラウドを中心に接続されるように作られています。個社ごとの連携開発は発生しません。工事台帳で「Roomを作成」を押せばその工事のチャットルームができ、名刺から作られた会社・人物はそのまま商談に紐づき、勤怠から集計した労務費はボタン一つで工事原価に反映される。必要な機能だけを、あとから、必要になった順に接続できます。
そして、統合したあとに自由に変えられる
ここが最も重要な部分です。
一般に、統合が済んだ後のシステムほど変更しにくくなります。全体が絡み合っているため、一箇所直すと影響範囲が読めないからです。だから多くの会社は、統合と引き換えに柔軟性を失います。
BALENAは、統合後のシステム全体を、定額でカスタマイズし放題にしています。先に述べた四つの組み合わせを、一つのシステムではなくプラットフォーム全体に適用したということです。この仕組みが「カスタマイズフリー」で、月額または年額の定額を払っていただければ、回数にも規模にも上限を設けません（料金は後述します）。
使い始めてから出てきた「ここを変えたい」を、都度の見積なしで言える。帳票の体裁、入力項目、画面の並び、独自の集計。御社の仕事のやり方に合わせて変える。何回言っても金額が変わらないので、要望を出すことをためらわなくて済む。
各アプリの画面には「カスタマイズ相談」の入口を常に置いてあります。思いついた瞬間に送れるようにするためです。窓口はコンシェルジュ一本のまま変わりません。
また、カスタマイズを依頼するまでもない範囲は、お客様自身が設定画面から変えられるようにしてあります。たとえばバレーナセールスでは、営業のステージ名と並び順、確度（％）、会社・人物・商談それぞれのカスタム項目、メールの定型文を、管理者が自分で追加・変更できます。「自分で変えられる範囲」と「言えば変えてもらえる範囲」の両方を用意することが、システムを現場から乖離させないための仕組みです。
まとめ ─ 現時点での最適解
私たちの主張を一文にすると、こうなります。
機能ごとにシンプルで洗練された個別のパッケージクラウドを、必要な順に導入し、バレーナクラウドを中心に容易に統合し、統合されたあとの全体を定額でカスタマイズし放題にする。
個別IT化の身軽さと、統合システムの一貫性と、フルスクラッチの柔軟性。この三つは従来トレードオフの関係にありましたが、「大きなシステムを作らない」という選択によって同時に成立させることができます。これが、私たちが考える業務統合化の現時点での最適解です。
プラットフォームの構造
アプリは分かれ、ログインは1つ
アプリは分かれていますが、ログインは1回だけです。バレーナクラウドにログインしていれば、他のアプリはパスワードなしで開きます。各アプリの画面上部には他アプリへの導線が常に出ており、たとえばバレーナカードで開いている人物から、そのままセールスの商談へ移動できます。
バレーナクラウド 見積・工事台帳・実行予算・注文・請求・入金・原価。会社の数字の正本（内勤／積算・工務・経理）
バレーナAI 自社のデータにそのまま質問する。見積の下書きも作れる。標準搭載（全員）
バレーナルーム 現場ごとのチャットと写真台帳。協力業者と共有する（現場・協力業者）
バレーナコネクト 協力会社への見積依頼〜比較・採用〜注文〜出来高査定（工務・購買）
バレーナビルボックス 受け取った請求書の処理と支払明細（経理）
バレーナクルー 勤怠・日報・経費・休暇・給与・労務（全員／総務）
バレーナセールス リード〜商談〜受注の管理、予定・タスク、売上予測（営業）
バレーナカード 名刺の取り込みと、会社全体の人脈データベース（営業・全員）
バレーナボード 人員配置・段取りの調整（工務・現場）
バレーナワークフロー 稟議・承認の申請と回付（全員／管理）
これら10のアプリは、バレーナクラウドと同時にリリースします。 順次追加していく形ではなく、初日からすべて揃った状態でお選びいただけます。
工事を軸に、データがつながる
アプリを行き来しても同じ工事・同じ相手の話が続くように、工事（案件）と取引先を軸にデータがつながっています。2010年の「横軸の繋がりがない」への回答が、これです。
クラウド → ルーム 工事台帳の「Roomを作成」で、その工事のチャットルームができる
クラウド → コネクト 実行予算を発注先へ振り分けて、そのまま注文書になる
ビルボックス → クラウド 受け取った請求書を処理すると、工事ごとに合算して原価へ反映される
クルー → クラウド 勤怠から算出した労務費を工事の原価へ渡せる
カード → セールス 名刺から作られた会社・人物が、そのまま商談の相手として選べる
セールス → クラウド 受注した商談が、工事台帳へつながる
正本は必ずバレーナクラウド
工事の情報の正本は、必ずバレーナクラウドです。ルームやコネクトの側で工事名や工期を書き換えることはできません。クラウドで直せば各アプリに反映されます。
この一方向のルールが、統合を単純に保っています。「どこの数字が正しいのか分からない」という、統合システムで最も起こりやすい事故を、構造で防いでいます。
現場を止めない設計
PCとスマートフォンで同じURL。 現場ではスマホ、事務所ではPC。名刺の取り込みも、パイプラインのステージ変更も、どちらの端末でも同じ操作でできます。
協力業者はURL1本で招待。 メールアドレスを聞き出す必要がない。LINEでそのまま送れる。ただし承認しない限り誰も入れない。
AIは標準搭載。 「今月の未入金は？」「この工事の粗利は？」と日本語で聞ける。見積の下書きも作れる（ただしAIが作るのは下書きであり、確定はしません）。
操作ログと履歴。 誰がいつ何を変えたかがすべて残る。
「営業」という、もう一つの入口
先に述べた個別IT化は、工事が始まってからの話だけではありません。工事が始まる前、つまり営業の段階でも、まったく同じことが起きています。名刺は担当者の引き出しの中にあり、案件の進み具合は担当者の頭の中にあり、「いま何件動いていて、いくら見込めるのか」は誰も答えられない。この領域を担うのが、バレーナカードとバレーナセールスです。
この二つを説明することは、ここまで述べてきた設計思想を具体的に示すことでもあります。
バレーナカード ─ 個人の引き出しを、会社の人脈データベースにする
名刺をカメラで撮るか、保存済みの画像を選ぶだけで取り込めます。複数枚をまとめて入れられ、展示会などで続けて登録する場合は共通情報を先に決めておくこともできます。会社名・氏名・部署・電話・メールなどはAIが自動で読み取り、読み取りに自信がない項目だけ色で知らせます。全項目を目視で確認する必要はなく、色のついたところだけ見れば確認が済みます。
取り込まれた名刺は、会社と人物という二つの単位に整理されます。ここが、名刺アプリと人脈データベースの分かれ目です。
会社を開く。 その会社の人物、名刺、社内の誰がつながっているか、そしてその会社との商談（セールス側）と接点の履歴が、一画面にまとまって見えます。
人物を開く。 連絡先と、いつ誰が名刺交換したか、その後どうなったかが時系列で並びます。担当者が変わっても履歴が残るのは、名刺ではなく人物を単位にしているからです。
社内の人脈。 「この会社に強いのは誰か」を探せます。担当替えのとき、紹介を頼みたいときに使う画面です。
重複の整理。 同じ人・同じ会社が二重に登録されたときにまとめられます。まとめても名刺の履歴は失われません。
検索は、項目で絞り込む従来型の検索に加えて、話し言葉でそのまま探せます。「去年東京の展示会で会った大阪の防水会社の社長」「最近3ヶ月以内に会った原価管理に興味がある人」といった聞き方が、そのまま条件になります。
バレーナセールス ─ 「いま何件動いていて、いくら見込めるのか」を全員で共有する
セールスは、問い合わせ（リード）を商談に育て、ステージを進めながら受注まで持っていくためのアプリです。
リードを取りこぼさない。 問い合わせや展示会で会った相手をリードとして登録しておきます。ポータルからの通知メールは、本文をそのまま貼り付けるとAIが読み取ってリードの形にします。脈がありそうなら商談へ変換し、それまでのやり取りはそのまま引き継がれます。
商談を進める。 商談には会社・担当者・金額・受注予定日を入れます。会社と担当者はバレーナカードから選べるので、二重に打ち込む必要がありません。パイプライン画面ではステージごとにカードが並び、ドラッグするとステージが変わります（スマホ・タブレットではカードを開いてステージから変更します）。列の見出しには件数と金額が出ます。
次の一手を残す。 商談を開くと訪問・電話・メールの活動を記録でき、次にやることをタスクとして残しておくとTOP画面に出てきます。訪問や打合せの予定はカレンダーに入れ、商談と紐づけられます。
止まっているものを可視化する。 これがセールスの中心的な思想です。TOP（今日）には、今日の予定・未完了タスク・期限を過ぎたタスク・次回アクションが未設定の商談が並びます。商談一覧では「3週間動きなし」「次回未設定」「受注日超過」で絞り込めます。全体（管理）画面には「止まっている案件」の一覧が独立した枠として置かれています。
つまりこのアプリが管理しているのは、進んでいる案件よりも、止まっている案件です。営業で失われるものの大半は、失注ではなく放置だからです。
数字を見る。 予測・ノルマ画面では、ステージごとの確度をかけた見込み金額と、目標に対する進捗が出ます。受注済みに進行中の確度加重分を足した「着地予測」と、進行中をすべて満額で見た「上振れ上限」が並びます。担当者別画面では、メンバーごとの件数・金額・ステージ分布・停滞件数を比べられます。
この二つが示していること
バレーナカードとセールスはデータを共有しています。名刺から作られた会社・人物は、そのままセールスの商談に紐づきます。一方で、カードだけを使うこともできます。人脈のデータベース化だけをしたい会社に、営業管理まで買ってもらう必要はありません。
これが先に述べた構造の実例です。二つのアプリは別々に導入判断でき、別々に使えて、しかし使えば最初からつながっている。そして、営業のステージ名も、商談・会社・人物の入力項目も、メールの定型文も、御社の営業のやり方に合わせて変えられます。
料金の考え方
料金体系も、「パッケージ＋カスタマイズ＋業種特化＋定額制」をそのまま反映しています。構成は、基本ライセンス・オプションアプリ・カスタマイズフリーの三つです。なお、システム全体の初期費用はカスタマイズフリーへの加入状況で決まります（後述）。
基本ライセンス（バレーナクラウド本体）
フラットプラン 年額180,000円／1名（税別） 基幹業務を日常的に扱う方
フレキシブルプラン 年額24,000円／1名（税別） 閲覧・部分利用が中心の方（工事台帳等は従量課金）
PC・iPhone・iPad・Androidをすべて含みます。2プランは混在可能です。全員をフラットにする必要はありません（1社あたりフラット契約が最低1契約必要）。
オプションアプリ
各アプリは初期費用100,000円（税別・1オプションにつき）、年額は利用人数に関わらず定額です。
バレーナコネクト（受発注EDI） 年額360,000円（税別）
バレーナルーム／ビルボックス／クルー／セールス／ボード／ワークフロー／カード 各年額240,000円（税別）
人数課金にしていない点が重要です。 現場や協力業者に使ってもらうアプリを人数課金にすると、「使わせる人を絞る」という判断が働き、情報が集まらなくなります。バレーナカードも同じです。全社員が名刺を入れて初めて「社内の人脈」が意味を持つのに、人数で課金すれば入れる人を絞ることになる。それでは設計思想そのものが壊れます。だから定額にしました。
カスタマイズフリー
ここまで述べてきた「定額でカスタマイズし放題」を、料金として形にしたものです。
1ヶ月契約 100,000円（税別）
1年契約 600,000円（税別）
対象は、契約中のバレーナクラウドとオプションアプリの全体です。特定のアプリだけを対象にするのではなく、統合されたシステム全体を一つの単位として扱います。回数や規模による追加請求はありません。
この料金設計の意味は、金額そのものよりも「言うたびに費用が発生しない」という一点にあります。従量課金にした瞬間、お客様は要望を選別しはじめ、小さな違和感は口に出されないまま残ります。それがシステムと現場の乖離を生みます。定額にしているのは、その乖離を防ぐためです。
1年契約は月換算で50,000円となり、継続的に育てていく前提のお客様に向いています。1ヶ月契約は、導入直後の集中的な作り込み期間や、業務変更・組織改編の時期にだけ利用する使い方を想定しています。
加入は任意です。ただし、導入初月だけは実質的に必ず入っていただく形にしています。
カスタマイズフリーに加入する場合、初期費用は免除。 契約期間中、無制限にカスタマイズできます。
加入しない場合、初期費用100,000円（税別）。 この中に1ヶ月分のカスタマイズフリーの権利を含みます。
つまり、加入してもしなくても、最初の1ヶ月はカスタマイズし放題の状態から始まります。金額も同額なので、「入らないことで安くなる」という選択肢は存在しません。
こういう設計にしている理由は、「要件定義は完成しない」の項で述べたことに尽きます。「思っていたのと違う」が最も多く出るのは、導入直後の1ヶ月です。 ここで費用を理由に要望が止まると、その会社のシステムは初期設定のまま固まり、以後ずっと現場と噛み合わないまま使われることになります。私たちが最も避けたい事態がそれなので、最初の1ヶ月だけは選択の余地を残さないことにしました。2ヶ月目以降、続けるかどうかはお客様が決めてください。
既存バレーナDXユーザーのリプレース
初期費用300,000円（税別）。この中に、カスタマイズで後から実装された機能を含む同等機能の実装と、データ移行作業をすべて含みます。長年かけて御社仕様に育てたシステムを、そのままブラウザへ持っていくということです。
バレーナDXからバレーナクラウドへ
バレーナクラウドは、2015年の「バレーナ」以来、Claris FileMakerをベースに育ててきたバレーナDXの後継です。累計納品社数500社以上・4,000ライセンス以上の導入と運用で蓄積した業務知識を、ブラウザで完結するアーキテクチャに載せ替えました。
バレーナDXは、専用アプリのインストールを前提とした構造でした。堅牢で高速でしたが、協力会社や職人にまで広げるには摩擦がありました。バレーナクラウドではURLを開くだけで使えます。元請・協力会社の双方が、Webブラウザの中だけで取引を完結できるようになったことが、この移行の最大の意味です。
ここは強調しておきたい点です。先に述べた「統合の壁」は、実は一社の中だけの話ではありません。建設業の仕事は会社をまたいで流れます。見積依頼も、注文も、出来高も、請求も、相手の会社があって初めて成立します。社内だけをどれだけきれいに統合しても、会社の境界で紙とFAXと電話に戻るなら、DXは途中で切れます。バレーナコネクトとバレーナビルボックスは、この会社の境界をブラウザの中でつなぐために作られました。
2010年に聞いた「オフィスに行かないと業務ができない」という課題は、いま「会社の外の人とも、ブラウザだけで取引できる」というところまで来ています。同じ問いを16年かけて広げてきたことになります。
なお、インフラは自社管理のデータセンターと世界最大手クラウドへの二重バックアップで運用しており、データ消失事故は10年以上ゼロです。
システムの外側 ─ BPOとコミュニオン
システムを入れれば全部解決する、とは考えていません。実際に残る問題は二つあります。そして、この二つに手を出すこと自体が、冒頭に述べた「商品を売ることを第一の目的としない」というスタンスの帰結です。システムでは解けない課題に対して「うちの商品の範囲外です」と答えるなら、コンシェルジュを名乗る意味がありません。
バレーナBPO ─ 「人がいない」への回答
どれだけシステムが良くても、入力する人・処理する人が社内にいなければ回りません。人手不足はDXでは解決しない領域です。
バレーナBPOは、積算・原価入力・請求処理・書類作成といった建設業の内勤業務を、そのまま代行するサービスです。バレーナクラウドを共通の作業台にしているため、代行と自社作業の境界を自由に動かせます。 繁忙期だけ任せる、経理担当の退職までの半年だけ任せる、といった使い方ができます。
バレーナコミュニオン ─ 「つながりがない」への回答
もう一つは、会社の外側の問題です。工事の受発注、職人の融通、余剰資材、採用、補助金の情報。建設業の多くはいまだに人のつながりで動いています。そのつながりを持たない会社は、システムの良し悪し以前のところで機会を失います。
バレーナコミュニオンは、バレーナを使う会社同士のコミュニティです。工事マッチング、人材マッチング、在庫融通、資材共同購買、士業紹介、補助金情報などを提供していきます。デジタルの処理はAIが担い、人と人の関係は人が担うという役割分担で運営しています。
システム（バレーナクラウド）、実務（バレーナBPO）、関係（バレーナコミュニオン）。この三層が揃って初めて、建設業の会社は本当に前へ進めると考えています。
現時点での最適解、そしてその先
私たちは「現時点での最適解」という言い方を意識的に使っています。
先に述べたとおり、正解は使ってみるまで分かりません。それは私たち自身にも当てはまります。2010年にあの一社の相談を受けたとき、建設業に絞ることは考えていませんでした。2015年に「バレーナ」を出したときには、それがブラウザで完結する形になるとは見えていませんでした。今日ベストだと考えている構造も、500社を超える現場で使われるなかで必ず変わっていきます。
だから、変わり続けられるように作ってあります。カスタマイズフリーという定額の約束は、お客様のためであると同時に、私たち自身が現場から学び続けるための仕組みでもあります。「できません」ではなく「やってみます」と答え続けるためには、やってみたことが積み上がる構造が要る。バレーナは、そのために作られた器でもあります。
建設業は日本のGDPの約1割を占め、社会インフラのすべてを作り、維持しています。その現場が、紙と転記と電話に時間を奪われている状態を、私たちは変えたいと考えています。
大きなシステムを作らないこと。それは、志が小さいということではありません。現場が実際に使えるものだけが、社会を変えられるという判断です。
会社概要
商号 株式会社Office Concierge
代表者 代表取締役 小松 延顕
設立 2006年1月23日（2026年で第21期）
所在地 東京都渋谷区渋谷2-19-15 宮益坂ビルディング5F
事業内容 建設業向け基幹業務統合システム「バレーナクラウド」の開発・提供、建設業務代行「バレーナBPO」、建設業界コミュニティ「バレーナコミュニオン」の運営
沿革 2010年 FileMakerによる受託開発を開始／2014年頃 建設業への特化と定額カスタマイズ型パッケージへの転換を決定／2015年1月 建設業専用「バレーナ」正式リリース
提携 Claris／Apple SBAパートナー
Web https://office-concierge.co.jp/
記載の仕様・料金は2026年9月時点のものであり、予告なく変更する場合があります。