SPIDERPLUSは建設現場で愛されていることを軸にグロースしている稀有なプロダクト

2021年に上場前後の頃だと思いますが、SaaS企業をARR別に順番に等々して並べてみたことがありました。
その中にスパイダープラスがあり、「知らない会社があるぞ」と検索したら建設DX事業をしていることを知りました。
エンジニアの世界でも、建設DXに関する認知の機会はあるのですが、スパイダープラスはそういうところで名前を聞くことがなかったのです。
そこで関心を惹かれました。
ちょうどその頃に、共通の知人を介して経営陣とお話することができました。

現場で愛されていることでグロースしてきたプロダクトである点にとても魅力を感じました。
日本のバーティカルな領域でのBtoBのプロダクトはどちらかというと、トップダウン型の導入が多い傾向があります。
一方でSPIDERPLUSは開発当初から建設現場のメリットにフォーカスしていて、そのメリットが建設現場で連鎖していくことが大きな特徴です。
建設現場で働いている人が今度は別のお客様を呼んできてくれるように、です。
こうした連鎖はプロダクトの力を作っていくし、テクノロジー組織の充実もそういうものを支えていきます。
実際に使う人の方を向き続けることは、簡単に聞こえるかもしれませんが、難しいことです。
スパイダープラス経営陣の言葉遣いからも、お客様の価値からブレることがない姿勢の人たちだという印象を受け、気持ちのよいコミュニケーションができました。

テック分野での認知の低さが挙げられます。
面白いことをしてはいるのに、外向きの活動によるコミュニティへの貢献がまだ出来ていなかったのです。
特に建設系のバーティカルな領域は、取り組み自体が面白くともエンジニアに知られていなければ彼らに「ここで働きたい」と思ってもらうことは難しいです。

それから、日本はこれから人口が減少していく社会で、その分を機械に働かせていくことが重要です。働く人の数が減り、労働改革が必要で、DXの波も来ている。
そうした最前線に建設やテクノロジーのディープな領域に、優秀なエンジニアがたくさん加わることで、社会全体として生産性を高くすることができれば、GDPの底上げにも繋がります。

こうしたことからエンジニアの認知を得ることはとても重要だと考えています。
エンジニアがソフトウェアを作る時に、何によって社会貢献度合いを感じるでしょう。
例えば地図に残ったり、窓から見えることが考えられます。

プロダクトを作るという観点では「建設業の働き方」はエンジニアにとってあまり身近なテーマとは言えません。自分自身が普段使うサービスと比べると距離のあることです。
社会を動かす領域で価値貢献するところにエンジニアが流れてくることは重要だと考えていて、コミュニティ貢献を重ねていくことによって、その距離を埋めたい、と思うのです。

100点中30点ほどです。
30点というのはこれまでの課題解決に向かい始めたからでもあります。

顕在化した課題に対して立ち向かうには力が必要です。
社外取締役として関わる立場としては、都度組織として向くべき方向を根気強く経営陣に説いていくのが自身の役割だと感じています。

SPIDERPLUSは14年に渡ってお客様に価値を提供し続けてきたプロダクトでもあります。

私たち自身が再び価値に対して真正面から向き合いながら、自分たちが誇りを持って連続的な課題を解決していくことが必要です。
自分たちが熱量を持って日々開発している姿勢は目に見えないソフトウェアサービスであっても、お客様には自然と伝わるものだと思います。

だからこそ、価値提供している方々がどのような課題と向き合って、プロダクトを活用して何を感じているのか、開発組織がもっと具体的にイメージしていけるように仕組みや情報の流れを強化してきたいのです。

仕事をしていると、どうしても日々追われるものがあります。そうであっても、毎日の様々な作業の先には常にお客様に提供できている価値が必ずあります。

大変なときほど、目線が下がって短期的に物事を捉えがちになるものではありますが、スパイダープラスでプロダクト開発をしていることによって世の中を良くしていると感じられること、街中のあらゆる建物が、SPIDERPLUSと共に建てられて、その建設現場で働いた人たちを自分たちの仕事によって輝かせたのだということを自分たちこそが認識することが必要です。

抱えている課題があるからこそ、一緒に解決しませんか、と言える会社はとても魅力的に見えるし、だからこそ「一緒に解決していきましょう」という言葉も引き出せます。

こういうところを大事にしていきたいのです。

問題をどう解いたかをシンプルに発表したり、そのために使った技術を公開していくことの連鎖だと思います。色々なことに取り組むと、初めて出会うことが沢山あります。

場合によってはブログの記事にしたり、オープンウェアのソフトウェアにしたり、その形は様々です。
僕自身も常に誰かに助けられて仕事をしている一人です。

こうした活動を続けていくうちに、スパイダープラスの存在もそうした文脈の中に位置づいていき、いつしか助ける側にもなると、今度は「この人たち」と一緒に働いてみたいという思いも生まれます。

エンジニアの世界で情報をシェアすることは、吸引力を作ることなのです。

現場感覚、ということです。

お客様のニーズをお聞きするにあたっては営業の接点はとても重要です。
毎日様々なお客様とお会いしながら、場合によっては実際に使っているところを拝見したりもするわけですが、営業の接点があってのことです。

また、お客様が抱えている課題にこちらから飛び込んでいくことも必要です。
目の前の課題もさることながら、そのさらに先にある課題を見据えて解決策を提示できるのはエンジニアチームならではです。

両者が一体となることに対して、現場感覚もより次元の高いものになっていくはずです。

イノベーションのためにはタスクダイバーシティが必要です。
タスクダイバーシティというのは、ある業種の中で持ち合わせた常識の違いが多いことです。
タスクダイバーシティの広さは、イノベーティブなものを生む上で重要です。

スパイダープラスを例に挙げると、建設現場の働き方とソフトウェア開発というのは、常識の距離があります。そこにSPIDERPLUSによる建設DXというイノベーションが生まれました。

一方で、常識の距離が遠い人間どうしの問題点はコミュニケーションが難しくなりがちなことです。
営業は今あるお客様の課題にマッチするものをすぐに売りたい。

一方で、エンジニアはバグのないものを提供したいのですぐ、というのは難しい。
ソフトウェア開発は長くずっと使っていくためのもので時間を要します。

こうしたことを考えると、組織の中で営業とエンジニアは、問題に対する起点からもうズレが生じています。
コミュニケーションを難しくする要因です。

ただし、こうした常識の違いを乗り越える「コミュニケーション能力」が機能することで異なる距離がある人たちと認識を揃えていきながら解決に向かっていくことができます。

コミュニケーション能力というのは、単に外向けに働いているかということではなく、小さな常識の違いを乗り越えながら共通のゴールを常に見定めて物事を解決に向かわせていくことです。

エンジニアと営業が一体となることはビジネスで価値を提供するためには欠かせません。

価値観の起点や常識の違いがあることを認識して受け入れて、乗り越える力をつけながら成果を出し続けることが重要なポイントだと思います。

面倒なことが、面倒でないことに置き換わることでラクになることです。

精緻に記録しなくてはならないことを、紙に手書きするのは面倒ですが、それに代わってデジタルにすることで面倒ではなしに精緻な記録を実現できます。
自身が仕事をしていく上で気にすべきことの量を減らしていくことができるのが、使い勝手のよいプロダクトだと思います。
例えば洗濯板で洗濯をするのはとても大変だと思いますが、今は洗濯機がありますから、「昔はとても大変だったらしい」と言うのみですよね。

業務それ自体の認知すべきこと自体が使う側からなくなっていき、大変だったことをいつしか忘れているようにさえできるのがSPIDERPLUSに限らず、プロダクトの価値にあると思います。

僕はSNS投稿やメールのメッセージ管理についてAIを活用しています。
返信すべきかどうかなどを朝一番に確認することがなくなりました。
ディスプレイに向かって人間が何かをするのは2011年から2024年までの世界観です。

AI agentの時代は「環境が人間に代わって目の前のことをどうにか」してくれます。
働き手が減少していく未来に向かっては僕たちも、そこまでを目指したいですし、それを実現できる開発チームづくりが重要です。
それに伴って事業開発も成熟していくと思います。

AIによって仕事が奪われていく、という表現がありますが、僕自身はそうは思いません。
何が人間にとってコアな業務として残るか、と考えた場合、新しい技術の登場で物事が便利になり、「奪われる」業務は「奪われた」のではないはずです。
本質的に残っていくのは構想する力や、クリエイティビティやイマジネーションなど、何かをやりたいとする意思だと思います。
そのために、テクノロジーが本当に必要なこと以外を「奪ってくれている」とさえ思っています。

テクノロジー自体が「何かをしよう」とは思いません。
これまで出来ないと思われていたことをテクノロジーが可能にすることで、個人をエンパワーメントしてくれます。
その代わり、技術を使っていくための課題の設計の能力は高度に必要になっていくのではないでしょうか。

エンジニアは構想を具体化する人たちです。
ソフトウェア開発のためには構想の持つ曖昧さを取り除いて明確にしていく必要があります。
そのために試行錯誤を通じて、最終的に機械を働かせるようにする。
機械を働かせる度合いが大きいほうがより良いはずです。

実現のための試行錯誤をするプロセスは残っていくと思いますし、エンジニアリングの本懐もそこにあります。
それを持ち続ければ例えば生成AIの登場に脅かされることはありません。

これまでも、ソフトウェアを作ること自体は時を経るごとに簡単になってきました。

世の中にある何かを実現するためには、不確実性が大きいほうがイノベーションも大きくなります。

その時に多くの人たちの間にある曖昧さを取り除いていくことでイノベーションが実現します。

身近なところにいる人の身近な課題だけではイノベーションとは言えません。

そして、エンジニアリングはサイエンス、科学でもあります。

科学は仮説検証と実験の歴史です。

実験して試したもの以外は信じないという前提に立つまでに人類はたくさんの失敗を重ねてきました。

エンジニアリングも同じ考えに立ったほうがよくて、実験して試すのと同じように、試行錯誤をした結果、例えばその中には誰かに試しに使っていただいたり、ステークホルダーにお見せしてフィードバックを頂く。

この部分が科学の実験と共通します。

アジャイルの根幹にもこういうものがあると思いますが、実験に立脚するという点でエンジニアリングはサイエンスだと思っているのです。