00:08
皆さん、こんにちは。ウェイポイントベンチャーパートナーの平塚です。
私は建設の斉藤です。
建設テックの定義
建設テックLABでは、これから企業を目指す方や、建設業の建設領域で事業に取り組むスタートアップの方に向けて、
初歩から明るい建設領域の解説と、建設関連のニュースやテクノロジー、スタートアップについて学びをしています。
今回は、そもそも建設テックとは何なのか、事業案の具体化はどう考えるかについてお届けしています。
今回、節目の第5回となりました。よろしくお願いします。
ありがとうございます。
普段、打ち合わせとかしている際に、この前聞きましたとかって方が、
本当ですか?
お声掛けいただくことがありまして、非常にポアな方だと思うんですが、聞いてくださっている方々ありがとうございます。
ありがとうございます。
めちゃめちゃディープな話も含めて出てきたりするので、そういう意味ではあの話面白かったとか、
建設系のスタートアップをやっている友達がいたりするんですけど、
そんなのやってるの聞いてみる、みたいなことを言っていただいたりとか、
割とちゃんと刺さるところには刺さるんだなと思いながらやらせていただいています。
今週だけで3人ぐらいに言っていただいて、こちらにやっています。
本当ですか?
お会いしている中の方の3人ですから。
ありがたいです。
大変ありがたいです。
今回なんですけど、そもそも建設テックラボという名前をつけておきながら、
今更このお題を扱うのはいかがなのかと思うんですが、
そもそも建設テックとは何なのか?みたいなところから、
改めて振り返っていけるといいのかなと思っております。
建設テックって聞くと、そもそもシンプルに建設領域×テクノロジーかな?
みたいなふうに素人目には映るんですけど、
実際建設テックってそういう理解で正しいんですかね?
すみません、その通りなのでこれ以上の説明ないんですけど。
分解していくと結構いろんなアプローチがあってですね、
統一された見解みたいなものはないんですが、
こうじゃないかという分解の仕方がありまして、
ちょっと簡単に紹介させていただければと思います。
先ほど平田さんがおっしゃった通り、建設×テクノロジーという掛け算で生まれるという話なんですが、
当然その課題に対してテクノロジーで解決していくという話において、
建設って漠然としてますよねって話を前回から前々回ぐらいにさせていただきました。
土木だとか建築だとか、建築の中にはどういった業務だとか作業があるのかというのは非常に多種多様になりますので、
そこを分解してあげてこのポイントに対してこのテクノロジーで何ができるかというそういった掛け算で出ていくと思います。
一つの切り口でいくと、これが一つの正解ではなくて一つの切り口にはなるんですが、
例えば建物を作るフェーズで考えていくと結構工事現場で工事をしているところだけが建設ではないというふうに話すことがあるんですが、
建設プロセスの多様性
例えばですけど建物を作る企画をするこの土地にどういった建物が建てられるのかそういった企画があって、
その後設計が入っていきますよね。実際にどういった建物ができるか構造の設計、衣装の設計、設備の設計というのをしていきます。
その後ですね、調達をしていきます。設計ができたら契約をして実際に鉄骨だとかを取引先と契約していったりだとか、
作業してくださる専門工事会社さんに調達をかけていくわけですね。調達があります。
その後施工があって、施工は本当にいろんなフェーズがあって、土工事って言われる土の工事、杭を打ったりとかする工事ですね。
あと、固体工事と言われるコンクリートだとか鉄骨だとかで、柱だとか梁とか床とか屋根を作っていく工事。
外装工事と言われるのが、カーテンボールだったらカーテンをつけるとか、内装工事は壁に壁紙を貼っていくのか電気で塗っていくのかとか、
内装の壁を間仕切り壁を作っていくとかですね、ありますし、設備も空調、衛生、衛生というのは水だとかですね、
給配のことになりますが、衛生工事、あと電気工事、通信工事、それぞれあります。
ですので、施工というのはちょっと分解すると結構いろいろあるんですが、施工のフェーズがあります。
そこまではおおむね一般的な建設プロセスという形で見ていくんですが、他の定義でいくとその後の維持管理をしていきますよね、フェーズも当然あります。
いろいろな運用をしていく上で、建設するプロセスの中で出てきたデータをどう使っていくかとか、そういった切り口が出てくると思います。
建物のライフサイクルは5、60年くらいは使っていく、もっと長く使っていくこともありますが、それが過ぎたら今度は解体のフェーズに入ってきますよね。
解体も当然建設プロセスの一つということで、それぞれのフェーズって結構、建設って幅広いという世界があって、それぞれのフェーズに特有の課題があったりします。
なので建設業の課題を漠然とテクノロジーで解決するぞと言っても、どこだろうというのはなかなか特定しづらいんですけど、
実は本当にサラチのところから解体まで幅広いフェーズがあって、その中で様々な工事だとか維持管理だとか設計なんかが行われている。
それぞれ非常に根深い課題があるので、そこを一個一個深掘りできると本質的な課題にリーチできるかなと思います。
テクノロジーの話は私より聞いてくださっている皆さんとかの方が詳しいとは思いますけど、先生AIだとかオープンデータを使ったりとか、AIとかディープランニングとかデータサイエンス、制御だとか、
その他クラウドソーシングみたいな技術とかを教えたらいいかもしれませんし、様々な切り口のテクノロジーで解決していく。
その組み合わせで建設テックって定義できるんじゃないかなというふうに思います。
建設テックみたいな言葉って多分今までもいろんな形でテックが、重機とかもテクノロジーといえばテクノロジーなのかもしれないですし、
そう考えると建設テックっていう言葉はなかったけど、一部やられてきたところってあるのかなと思いつつ、
一方で建設テックっていう言葉をよく聞くようになったのって比較的ここ5年とかそんなもんなのかなと勝手には思ってたんですけど、
そのあたりってそもそもどれぐらいのタイミングで建設テックというワードが生まれてきていて、その生まれた背景っていうのは何だったんですかね。
私自身、いつ誰が提唱したかっていうのは存じ上げないんですが、
おそらくおっしゃる通り5年よりもうちょっと前かなという気もしますけど、それぐらいで言われ始めたかなと思います。
建設テックだけじゃなくて、他にもアグリテックだとかフィンテックだとか丸々テックっていうラベリングが当然そのタイミングでされてきた中で、
うちの一つがコンテックだったという、そういった認識でおりますね。
多分なんかそのアグリテックとかコンテックとかなんちゃらテックっていうキーワードが出てきた時に、
ある程度なんちゃらテックって結合されたものって比較的そのスタートアップであまり取り組まれてこなかったテーマに対してなんちゃらテックってつくようになったような気もしていて、
フィンテックとかも多分いわゆる重たいシステムのところに対してなかなかスタートアップが入っていくの難しいよね。
今までだったらSI屋さんが作ったりみたいなことがあったところ。
それが少しずつそのスタートアップの手にも届くようになってきたというかスタートアップも解決する一つの人たちとして入れるようになってきたっていうところが、
建設テックっていう言葉とかなんちゃらテックみたいな言葉がなんかより広くなってきたのかなとも思いますし、
同時にいろんなベンチャーキャピタルが出てくる中で一つのその色を出していくみたいな文脈でなんちゃらテックっていう言葉が出てきたなって印象を持っているので、
いろんな背景が融合して出てきたんだろうなっていう感じはちょっとしますよね。
ベンチャーキャピタルさんも当然そういったラベルをつけた方が当然その分野を確立していって盛り上げていけるっていう側面もありますので、
当然そういったラベリングっていうのは一つの有効な手段かなというふうに思います。
さっきもチラッと本当の課題をどう捉えるかみたいな話がチラッとあったかなと思うんですけど、
実際に具体的に建設テックの領域でその事業を考えるにあたって、
その事業の具体化ってどういうふうなマトリックスで行っていくべきなのかというか、
どういう整理をしながらやっていくべきなのかみたいなところって、
斉藤さんの中で考えるその事業の具体化の考え方みたいなのって何か終わりだったりしますか?
これに関しては本当に全部カテゴライズして分類をして、
ここが自分たちがやるべきなんじゃないかみたいなアプローチってなかなか、
論理的に考えるとそういった考え方は当然あるんですけど、
実際は難しいかなと思います。
なぜならば設計の課題は本当に設計している人しか知らないですし、
施工現場の課題は施工現場でしか知らない。
施工現場の中でもいろんな職種の方がいらっしゃるというところですよね。
企画も課題も設計の人が施工の人も知らないということで、
全てを調べて知っている人ってほぼいないと思うんですけど、
設業の課題、全てのフェーズ、全ての報酬。
なのでそういったアプローチって非常に難しくて、
コンサルさんとかもしかしたらヒアリングだとかでそういった課題表みたいなのが作れるかもしれませんが、
実際には不可能じゃないかなと思います。
それよりもっと有効なのは、結局課題を深く知っているスタッフさんは、
やっぱり即広が非常に強いというのが私も非常に感じているところですので、
じゃあ彼らがどういうふうに深い課題にたどり着いたかというと、
自分が入り込みやすいというか、
友達がやっているだとか、あるいは全職で実はこういった仕事をしたとか、
あるいはうちのスタッフさんにそういった分野に詳しい方が入ってこられるみたいな、
そういった機会じゃないとなかなか深い課題って掘り起こせなかったりしますので、
自分がどこにアプローチしやすいかというところの方が重要なんじゃないかなというふうには思います。
これまで何回かに分けて建設業界の課題みたいなところを触れてきたかなと思っていて、
その中でも人手不足みたいなところがすごく何回も何回も出てきたなと思いつつも、
人手不足の背景
ある意味それって人手不足っていうのはすごい多分大きな課題ではありつつも、
多分人手不足という言葉だけで捉えると結構表面的になってしまいがちというか、
人手不足の中でも本質的な課題というか、本当はどういう背景があってそういう課題が生じているのか、
例えば人手不足も本当に人の総量が足りないみたいな話もあれば、
もしかすると季節制みたいなところでボラティリティがあってピークの時の人が足りないみたいなところもあれば、
あとはあんまり起きてないかもしれないですけど、スケジュールの管理ミスって本来いなくていいところに人が滞留してしまって、
本来いるべきところに人が足りないみたいなことが起きているかもしれないし、
みたいな中でその課題をどう捉えられるかで解き方というか、多分どういうテクノロジーを入れていくのかであったりとか、
提供価値はどういう風に出していくべきなのかっていうのはなんか変わるなと思っていて、
なんかその中でおっしゃられていた通りで自分の前職がこうだったからとか、
あと僕の友達ですごい面白いなと思ったのが、建設領域のスタートアップをやるって決めた時に実際に現場に働きに行った友達がいて、
一番すごいですね。
一旦働いたんだよねみたいな話を聞いた時はなんか凄まじいなと思いながら、
なんかそういう形でやっぱり多分大きな課題としては存在するので、多分いろんなデスクトップサーチできっと調べられちゃうんだろうとは思うんですけど、
なんか本質的にじゃあ実際それ事業で解きに行こうとするとやっぱり本当の課題みたいなのを探しに行くのって非常に大事なんだろうなっていうのはすごい思う業界ですね。
実際の業務の影響
そうですね、多分外からだとわからない課題でまだ取り残されている部分っていうのが一番重要かつソリューション提案ができる部分なので、
本当に難しいことではあるんですけど、そういった機会を重視するっていうのが一つのやり方かなと思います。
なんかその今のさっきのお話の中で言うと自分が入りやすいところを探すっていうお話があったと思うんですけど、
一方でそのいわゆるテックでいろんなサービスを作ってきた側の人たちが、じゃあ今度建設業界すごく面白い業界だよね、
なんかそこに対して新たな提供価値を作れないかみたいなのを考えるときって、
なんかあまりそう簡単に入りやすいところを探すのって結構ハードル高いのかなと思っていて、
なんかまあそこを探すための一つの方法が僕の友達みたいに実際に歩いてみるみたいなところは一つあるんだろうなと思いつつ、
なんかそういう方たちの場合って、なんかどうやってとっつきやすいところを見つけるのが良さそうなのかとか、
なんか逆に実際にご存知の中でこういうケースあったなーみたいなのってなんかあられたりしますか?
まあやっぱりこうアルバイトで入るとかも当然すごく有力なプローチですよね。
確かなんかこうスポットアルバイトのタイミーさんとか、
なんか競合の人たちはみんな自分たちで使うだとかされてますよね。
Uber Eatsとかもそうですよね。
まさにUber Eatsは僕もやったことが。
やりますか?
はい、ドライバーでやりましたっす。
どういうビジネスなんだろうっていうのを理解するにはやっぱり自分が環境に一回入らないとわからない部分があったりとかするので、
やっぱりそういったアプローチが有効かなと思います。
あと私が知ってる中だと、その大手の会社にいらっしゃって、
お客の回想を高めたいので出放という形で、
建設会社さんに働きに行くようなケースもあったりしますし、
あと特定の建設会社さんだとかと仲がいいのであれば、
もうちょっと現場に1週間いさせてくださいだとか、
半日一緒に回らせてくださいってそういった方がいらっしゃれば、
そういうルートって非常に近道かなと思います。
なんかITの業界とかがたまに誰々のカバン持ちやるみたいな形で、
その場合は働き方を知るみたいな感じですけどっていうケースもありますし、
あと個人的にもUber Eatsやった時はすごい、
Uberがあれだけ多くのドライバーさんを確保できる裏側のオペレーションの強さみたいなのを
すごい見せつけられたなと思ったりしたんで、
実際にやってみるっていうのはすごい感じる部分が多いなと思います。
じゃあその課題が見えてきたぞみたいな話になった時に、
じゃあその課題をどうやって解きにいきますかみたいなのが、
多分次のアクションであるのかなと思うんですけど、
そこに関してはさっきお話に出てきていたのは、
どういう技術を入れていくかみたいな話があると思っていて、
ただその技術を適用するみたいなことを考えると、
割と今流行りの技術を入れていくみたいな発想になりがち。
流行りの技術をどう入れるかみたいな話になりがちなのかなと思いつつも、
一方で建設業界の場合って、実はこれ別に建設にも限らないような気もするんですけど、
必ずしも流行りの技術じゃなかったとしても、極論言うとローティックだったとしても、
提供価値しっかり出るよねみたいなケースも多くあるような印象を持ってるんですけど、
そのあたりってどう感じられますか?
印象ですけど私も同感でして、
最先端のテクノロジーを使ったご提案いただくこともあるんですけど、
やっぱり建設業界に果たしてフィットするのかっていう、
あるいは何の課題に対してどれだけのインパクトがあるのかっていうところがやっぱり弱かったりする。
テクノロジープッシュのアプローチですよね。
それはやっぱりあまりうまくフィットしない事例が散見されるなというふうに思います。
一方で建設業界に残ってる課題って本当に今のローティック、
一昔前だと快適だったかもしれないですけど、
そういったもので解決できる可能性も十分にまだ余地が残っていますし、
業界の特性としてやっぱりある程度確立されたものを行う傾向も当然あるので、
あまり最先端のテクノロジーというところにフォーカスをせずに、
課題に対して適切なアプローチをするという方法の方が業界的な受けは良いです。
確立されたものが好まれるっていうのは、
いわゆる安定してその品質を出し続けることができるよねと、
ある意味証明されているからみたいな感じなんですか?
そうですね。実装を目指すのであればやっぱりそっちの方が良くて。
一時期あったのがヘッドマウントスプレーとかVRだとかもあったかと思うんですけど、
やっぱりそれが流行った時にそれを建設業界で利用できないかっていう話のご相談とかはいくつかいただいて、
実際に現場で使ってみても何に使えるのかみたいなディスカッションをするんですけど、
そこにやっぱり課題があまりなかったみたいな。
あるいはVRだとかXRなんかを使って、
当時の品質の中でできそうなことはなくてということはありましたので、
そのアプローチは絶対ダメだって話はなくて、
当然それがフィットする組み合わせもあるんですけど、
確率的には低いような気がしているというところでございます。
実は僕らも投資をさせていただいたりする時に、
実際にターゲットになりそうな建設会社さんにヒアリングしたりすることがあるんですけど、
今どういうふうな行動をされているのかみたいなのを伺ってみると、
いまだに印象がすごく強く残っているのが、
ホワイトボードを使って管理してますみたいな話が結構出てきていて、
ホワイトボードなんてスペースも限られてるし非動機だし、
なんでそんなものがいまだにと思われてしまうんですけど、
意外と現場ではそれを使うことがめちゃめちゃ最適化されていて、
むしろ他のツールを新たに入れて、
効率化されている風で使うよりも全然ホワイトボードの方が使いやすいみたいなのが
平気で起きることがあるよなと思ったりするので、
意外とテックとかそっちの領域に強い方だと、
なんでそんな非効率だって思われるようなことでも、
実は現場はめちゃめちゃ最適化していて、
新しい技術を使えば提供価値が出るっていう問題でもないなと思わされることはすごく多くあるような気がします。
建設業に限らずだと思いますね。
心理的負荷の重要性
結局そのDXを目的にしちゃうと、
なんかデジタルにして結局なんかコース増えてるじゃんって事例も、
正直私感じる部分あるんですよ。
何のためのDXだっけっていうところがわからなくなっているようなものも、
中にはやっぱりあるので、
そこをやっぱり失わないようにしないと、
実装に向けてはなかなかハードルがあるんじゃないかなと思います。
やっぱり課題。
最初の方の回でも申し上げましたけど、
なんかクオリティが上がるとかっていうアプローチよりも、
今の建設業の世の中は、
どれだけ工数が減るとか、人が減らせると楽になるとか、
それがないと少し時間をかけると、
ちょっと品質が上がるとか、あるいは少しクオリティが高まるよっていうアプローチより圧倒的に減る方が好まれますので、
そこの課題、減らせられる課題を見つけていくということが重要かなと思います。
ここまで来ると多分どういう課題を狙うのか、
そこに対してどういうテックでその課題を解決しに行くのか、
結果的に出る提供価値が何なのかみたいなところに多分行き着くのかなと思うんですけど、
さっきおっしゃっていただいた通り、
何をどう減らせるのかみたいな議論が、
ある意味提供価値のうちの一つだと思うんですけど、
その提供価値として、
あくまでも一番最初たぶん授業を作るとき、
仮設からスタートされるものだと思ってるんですけど、
その仮設段階で、
どれぐらいの改善インパクトが出ると、
そんなのケースバイケースでやって話だと思うんですけど、
どれぐらいの改善インパクトが出ると、
既存のものから乗り換えてもらいやすいというのもあれなんですけど、
選ばれやすくなっていくのかとか、
あとはここを提供価値として入れることができなければ、
基本的には結構ハードルが高いんじゃないか、
みたいな肌感とかってお持ちだったりします。
これも一律には言えない部分だと思います。
ケースバイケースです。
当然シミュレーションをしてですね、
どれぐらい個数が下がるから、
これぐらいの金額で入れても全然お土産が出ますよね、
シミュレーションだとか試算はするんですけど、
それもそれで重要なんですけど、
もう一つ必要な視点っていうのが、
使われるユーザーさんが普段から煩わしく思っている業務で、
おそらく同じ10分の業務でも、
20分30分ぐらいにも感じるわけですよね、
負担としては心理的な負荷です。
そこいう視点も結構あるかなと思っていて、
賞味時間だけじゃなくて、
本当1日10分しかないんだけど、
本当に面倒くさいと思っているサブの業務を減らすとかでも、
全然アリだと思います。
心理的にマインドリソースを実際に使っている時間以上に取られている、
みたいなところってインパクトありますよね。
ありますね。
以前ちょっと私も調査をしたことがありまして、
現場で施工を管理をしている人たちの業務が、
何にどれくらいの時間をかけているのかっていうのを
精緻に調査して、論文にまとめた事例があるんですけど、
その際にですね、
圧倒的に時間を取っていたのは、
ルーティンの業務だったんですね。
毎日やる。
毎日5分だけど、
それが毎日あるっていうものです。
実体的負荷と心理的負荷
以前も申し上げた通り、
工事の中では変わっていくので、
例えば鉄筋の工事の検査っていうのは、
鉄筋の工事をしている期間しか派生しない業務なので、
すごくその期間は大きな時間を取られるんですけど、
でもそれは数ヶ月間だけ、
全体の工事の期間の3割とか4割とかの期間である。
例えばそういった状況において、
毎日している、
当たり前だと思っている業務って、
あんまり負担に思ってなかったりするんですけど、
積み上げていくと、
総量として大きくなって入るという実感がありました。
逆に言うと、
安全管理とかって結構大変なんですよね。
仕事として書類で全部安全ちゃんとやってますよ、
っていうのをやらなきゃいけないんですけど、
現場で施工管理している方って、
プロジェクトを進めることとか、
計画を立てて、
ちゃんとできて管理するっていうのは、
すごく大きな仕事ではあるんですけど、
やらされ感が結構強いと。
法律だったりでやらなきゃいけなかったりする部分と、
やれば工事が進む仕事と、
やっても工事の進捗に関係ないものも当然あるわけですよね。
安全管理は非常に重要な仕事で、
しっかりやらなきゃいけない部分なんですが、
やっぱり安全管理の削られている時間間隔って、
すごく大きいというふうに負担を感じているんですけど、
調査をすると、
大きいんですけど、
確かに大きいんですけど、
言っているほど大きくもないっていうところですね。
面白い。
なので、2つの話があって、
実際にかかっている時間が大きなボリュームの、
業務って何なんだっていう話が1つと、
あと、実際はそんなにかかっていないかもしれないけど、
負担に感じている業務って何なんだっていう時間。
当然なんですけどね。
当然の話なんですけど、
その2つのアプローチっていうのは、
実際に現場でもあるんだなっていうのは感じた次第です。
意思決定者の視点
なんかすごい面白いですね。
実際にかかっている時間と、
本人が感じている感覚はちょっとズレがあるみたいなのは、
すごい面白いなと思いました。
そうですね。
なおかつ普段からやっぱりちょっとやらなきゃいけないからやってると思っている業務については、
当然現場の人はそれが楽になるっていうのは非常にポジティブだったりするので、
それを効率的にするサービスなんかっていうのは、
非常に貼着しやすいんじゃないかなっていう私の仮説があります。
そうなってくると、
これ割と使う人と導入意思決定をする人が分かれている場合に、
割とよく起きる、スタートアップとVCの中でたまに起きる議論だなと思っているのが、
現場の人たちにとってはめっちゃ欲しいんだけど、
意思決定権者にとっては、
それそんなにインパクトあるの?みたいに見えるケースって一定あるのかなと思っていて、
ありますね。
そこっていうのは、
やっぱり分けて、
ちゃんと意思決定権者の人にとっても価値があるものにしないといけないのかなというふうに思ったりするんですけど、
たぶん現場の方は自分が思っている業務がどこまで軽くなるかっていうのが非常に重要なんでしょうし、
逆に意思決定をする方からすると、
もしかすると現場で使われているコストが少しでも安くなるみたいなことが重要だから、
むしろツールを入れないといけないんだったら、
むしろコスト上がっちゃうじゃんみたいな見られ方をするのかなと思ったんですけど、
そのあたりって意思決定権者の方の思考って、
どういうふうな考え方になるんですかね?
すごく難しいです。
本当にケースオイケースの話だと思うんですけど、
昨今の建設業のトレンドでいうと、
やっぱり労働力を確保しなきゃいけない、
従業員のエンゲージメントも高めなきゃいけないという課題意識を皆さん持ってらっしゃるんですよね。
当然、投資した分の効果があるのかどうかという側面は、
変わらず重要ではあるんですけど、
それ以上にやっぱりユーザーとなる方が喜んでくれる、
変わったな、楽になったなって、
実際は時間そんな変わってなくても喜ばれるのであれば、
そういった視点も非常に重要になってきていると思います。
なかなかただそれで倫理を書いたりする際って結構書きづらかったりするんですけど、
そうですよね。
ですけど、やっぱり現場のあるいはユーザーの方はこれだけ評価してくれてるっていうのは一つの動向にはなりますので、
何かしらそういった視点でも導入が進む可能性は十分にあるなと思います。
逆に現場の人に刺さるかどうかは査定を聞いてやるとサービスとして使われるのかっていう話はあると思うんですけど、
そこを一旦査定を置いたときに、意思決定権者の方がより意思決定しやすいサービスの特徴というか、
こういうところでインパクトあるとより意思決定しやすくなっているケースが多いよねみたいなのがあったりするんですかね。
一番分かりやすいのはやっぱり費用対効果ですよね。
投資対効果、それに投資に見合った効果が得られるっていうエビデンスが欲しいというところです。
そのためにこうすることもあるんですけど、スタートアップさんとかサービスプロバイダーの方々とすると各社でそれをやっていくのは結構大変だと思うので、
もしかしたら提供される際にどれだけの効果の削減の効果が実際に他の現場でありましたとか、
そういったエビデンスをつけていただくと非常に社内で承認されやすくなるんじゃないかなと思います。
なのでそのサービスにお金を払ったら、例えば現場で使われるコストがこれだけ削減しましたよであったりとか、
分かりやすく残業時間が減ったよねみたいなところだったりとか、
極論複数人いないと回せなかった業務が一人で大丈夫になるよねみたいな、
そういう分かりやすいインパクトが見えていれば、それはいいよねってなりやすいっていうそんなイメージ。
あとちょっと私も今ちょうどこれからできるかどうかわからないですけどやろうとしているのが、
あるスタートアップさんがそこそこ効果のソリューションではあるんですけど、
それを普及させるためにやっぱり各社で検証していって納得して導入されるっていうような広がり方が予想されるんですけど、
それって非常に効率だったりするじゃないですか、
サービス導入の影響
同じことをやっぱりいろんな会社で試してやっぱいいよねっていう結果なんか、
そうじゃない現場ももしかしたらあるかもしれないですけど非常に非効率なので、
ただそこのスタートアップさんがこれだけ減りますよって言っても、
それはあなたが言ってるだけでしょっていうふうに。
いやそうなんですよね。
それは難しいところですよね。
かつ他の例えば建設会社の現場で使ってみたデータっていうのは別に他で使わないでくださいって言われる価値なこともあるので、
非常に難しいんですけど、今私は大学でちょっと研究もさせていただいているので、
そういった第三者的なところの機関による科学的な分析方法に基づいて、
これだけ減りましたよっていうデータを作っていくっていうのが一つのアプローチかなと思います。
大学の立場で言うとそれは新しいインサイトを世の中に提供できるので研究として有用ですし、
スタートアップさんからすると隅付きがある程度いただけると。
ゼネフォンからすると北区で同じ検証しなくてもですね、そういう結果が出てるんだったら採用しようという意思決定がしやすい。
みんなハッピーなのかなと。
それと一回事例作ってみたいなと思います。
なるほど。
確かにちゃんと公にできるデータがあると、スタートアップの場合だとPOCやって検証しようよって言われると、
多分そうしないと導入してもらえないからやるかっていうので、つどつどやっていっちゃうかなとは思いつつ、
それをやることによって、そうやってパブリックにデータが出てるんだったら問題ないよねっていう意思決定になるんだったら、
そっちの方がスタートアップ的には当然ありがたいなと思います。
そうですね。あとよくあるのがパンフレットとか書いていただいてるんですけど、40%削減されますって言ってもですね、
ある期間で考えて40%減ってるんですけど、その後の工程で実は見えないところで増えてないみたいな、他の作業が増えてないっていうパターンが結構あるんですよね。
そういったデータを見つけた際は、これ実は前処理が別のところでかかってるんじゃないですかみたいな話をさせていただいて、
実はちょっとこっちで追加の作業が改善後にかかってきてて、それは今回の削減、交換には含んでませんみたいな話がたまにあるじゃないですかね。
そうなってくるとその数値の信頼ができなくなってくるっていうところで、削減効果を使うことは重要ではあるんですが、
そのデータが果たして信頼できるかっていう見方も当然、顧客である建設関係の会社さんはそういう見方をする場合もある。
それをある程度しっかりしたプロセスで測って、しかも第三者がそういう結果を検証してるっていうアプローチの方がやっぱり
データの信頼性っていう意味では非常に重要なんじゃないかなというふうに思います。
もしそういった測定、効果測定なんか、自社で提供されているサービスなんかの興味ある先生とかがいらっしゃるのであれば、
そういったアプローチをすることも非常に有効じゃないかなと思います。
そうですね、新しいものを入れるからこそ発生してしまう新たな手間みたいなのも一定あるものはあるなと思いますし、
そうするとそれをプラマイした時に本当に有意性あるんだっけみたいな話は当然重要なんだろうなと思いますし、
あと一点すごく個人的に気になっているのが、例えば何十時間作業時間を減らせますとか、
人をこの作業でこれだけ減らせますっていう風な話が出てきた時に、
確かにそこだけ切り取ってみると減るんだろうけど、
でも実際問題、現場としては仮にそこの業務だけ減ったとしても別に人を減らすことはできないよねみたいなところも一定あるのかなと思った時に、
そこの改善インパクトって本当に現場で評価されるんだろうかみたいなところを若干気になったりもしてるんですけど、
その辺とかってどう思われますか?
おっしゃる通りな部分もある一方で、建設、特に建設現場だとか設計の現場でも一緒かもしれないですけど、
やるべきことって多分もっといっぱいあって、クリエイティブな部分だとか、
よりゆっくり考えてですね、計画を完璧にして利益を出す部分だとか、
生んだ時間で人が減らなかったとしても改善される他のインパクトが十分に予想されるので、
そこは建設業界においてあまり問題にならないんじゃないかなと思います。
建設業界の課題と計画の重要性
人それぞれですね、考え方によるんですけど、時間が生み出せるのはいいじゃないかと、
そのクリエイティブな時間にしていきましょうよっていうアプローチです。
そういう生まれた時間で削減できるのか、またはその生まれた時間によって今までやらないといけなかった、
本当にやるべき業務に対して時間が回せるのか、
そういう切り取られた時間がどう使われていくのかみたいなところが明確化されていれば、
ちゃんと評価してもらえるっていうそういうイメージですか?
そうですね、特に建設業の場合って、当然目の前の業務ばかりしていて、
中長期的に計画しなきゃいけないことがごてごてになっておよそかになることによって、
後方程でその分損失が発生すること、あるいはその獲得できた利益っていうのが減っちゃうパターンですね。
どれだけフロントの部分、その業務の上流の部分でしっかり計画をして、
お客様の期待に応えていくとか、利益をちゃんと作り込んでいくっていうことをしないと、
後々その分の輸出利益が出てくるので、
やっぱり時間を生み出すってことをそのもの価値って非常に大きいんじゃないかなっていう。
遅れていくみたいな、遅れていって損失が出るみたいな話は確かに聞きますもんね。
そういう意味でちゃんと安全にものが作られていって、
ちゃんとしっかり作られるべきものが作られているのであれば、
早いに越したことはないよねっていう感じですね。
そうですね、工事でいうと工程が遅れて、
その分余計に技能者に来ていただかなきゃいけないとなったときの
インパクトすごく大きいですよやっぱり。
もともと予定していなかった人を呼ぶってなると倍ぐらいの金額払って、
安くなってくるんですし、それも余計な人間費がかかってるんですよね。
そのインパクトは本当に大きいので、
やっぱり人が減らなかったとしても、ゆっくりちゃんと計画できたよねっていう効果は非常に大きい。
これは多分言うと建設業界の皆さんもそうだよねって伝わると思うので。
エンディングと次回の案内
なるほどね。よくわかりました。ありがとうございます。
じゃあ一旦本日はこれで以上にしようかなと思います。
聞いていただきありがとうございました。
ありがとうございました。
概要欄で話してほしいトークテーマであったりとか、
質問も受け付けておりますので、もしよろしければぜひご記入ください。
また本日の内容で気になったところがあれば概要欄のXのアカウントのフォローをお願いします。
それではまたお会いしましょう。
