BlueMeme、デジタルレイバーを成長戦略にIT人材不足の課題解決に挑む 2026年以降急成長の見込み

BlueMemeは何をやっている会社なのか?

國分淳平氏（以下、國分）：本日のゲストは株式会社BlueMeme代表取締役社長の松岡さんです。よろしくお願いします。

松岡真功氏（以下、松岡）：松岡です。よろしくお願いします。

國分：御社の取り組み内容は、社名からはなかなかイメージすることができません。資料を見るとなんとなくわかりますが、コアな部分はやはりよくわかりません。おそらく投資家のみなさまも同じ気持ちなのではないかと思い、本日は御社のビジネスモデルを、投資家を代表して聞いていきたいと思います。

まずは「何をやっている会社なのか？」を教えてください。　

松岡：当社は、業務システムを新しい開発手法を使って、サービスを提供する会社です。簡単に言うと、業務システムの開発を行っています。シンプルに表すと、どこにでもある会社のように見えます。ただ、他社と業務システムの領域は同じですが、作り方が違うことと、提供するサービスに特徴があります。

事業会社の業務システムとは?

國分：スライドには業務フローに含まれる、あらゆるものがあります。現在、これらのほとんどが、SaaS、要はクラウドサービスに置き換わっています。したがって、これは私の本当に勝手なイメージですが、これから開発していくというニーズはないように思ってしまいます。

松岡：確かにスライドに記載されている業務内容は、どの会社にもあります。例えば、物流や金融などは業界独自ですが、経理・財務、販売・営業、人事・労務はだいたいどこの会社にもあります。

ローコード開発は「高付加価値」を実現できる領域で需要拡大

松岡：ただ、システムの領域は3種類ぐらいあって、スライドの三角形の一番下が「省力化」と呼ばれています。スライドには「バックオフィス業務」と書いてあります。

間接部門は実際にお金を稼ぐ部門ではなく、人事・労務などがこの間接部門に含まれます。ここは大半の会社が同じようなことを行っているため、財務諸表もほぼ同じで、SaaSなどのパッケージが使用できます。

一方で、スライドの三角形の上を見ると「デジタルビジネス」と書いています。ここは差別化の領域になります。要はデジタルでお金を稼ぐ領域です。したがって、顧客ニーズに合わせ、さまざまな技術を使って差別化していきます。例えば、SaaSベンダーなどはこの領域を使っているため、自らが提供するSaaSベンダーは当然、SaaSを使えません。

國分：確かにそのとおりですね。

松岡：我々はその高付加価値の領域で、この三角形でいう赤い部分の開発を行うことが非常に多くなっています。そのため、人事・労務に関しても、特別なタレントマネジメントを行うであるとか、当社のみ評価内容が違うという場合はこの高付加価値の領域に入ってくるため、人事の開発なども行うことがあります。したがって、企業が「どこに価値を感じるか」「どこに独自性や差別化を持たせるか」というところで変わってくると思います。

國分：3ページには、業務システムが数多く挙げられていますが、正直にいうと複雑で、その中にはピンとくるものとこないものがあります。松岡さんからわかりやすく解説していただいてもよろしいでしょうか？

松岡：業務システムを作る時は、業務プロセスの分析などをかなり行います。

國分：各プロセスに人がたくさん関わるからでしょうか？

松岡：おっしゃるとおりです。基本的には業務フローを変えることなどを検討します。ただ、例えば明日レストランをオープンする場合には別の方法で取り組みます。

國分：明日オープンですか？　それはかなり急ですね。

松岡：明日オープンしたいが、システムがないという場合です。

國分：なにもシステムがない状態ですか？　

松岡：そうです。そのような状態で「予約管理をしてほしい」と言われたら、何をしますか？

國分：とりあえず、無料で使える予約管理システムを必死で探すかもしれません。

松岡：今どきの回答ですね。おそらく「Microsoft Excel」などを開いて、連絡があればそこに書き留めていくと思います。もし「Microsoft Excel」がなければ、予約管理台帳だと思います。

國分：究極のところ、紙でも問題ないですよね。

松岡：紙でもいいと思いますが、それを作る理由は結局のところ、将来行わなければならない残の管理を行うためです。つまり、「将来、どの程度取り組まなければならないものがあるか」のデータを管理していくものが業務システムになります。

例えば、販売管理の場合は、見積もりを行い、受注した後、最後の納品まで取り組まなければならないことが続いていきます。しかも、これが1回で終わりません。いろいろなやり取りを行う流れの中で、「次はこれをやる、その次はこれをやる」ということを考えなければなりません。そして、考えることが多ければ多いほど、当然頭の中のみでの管理は無理です。これは紙のメモでも難しいことです。

ただ、明日オープンするレストランであれば、一度に1万件の予約が入る可能性は低く、多くとも数十件だと思います。ただ、その連絡が電話で入るか、「LINE」で入るかはわかりません。反対に「誰が、いつ、何名で、何時に来るか」といった情報がわかれば、予約管理は可能です。そのデータを記録して管理するものが業務システムになります。

「明日やれ」と言われたらそのような発想が出てきますが、実際のところ、このような業務システムの開発期間は長期にわたり、1年、2年とかかります。

國分：確かにそうですよね。

松岡：そのため、「業務プロセスから作りましょう」という話がよく出てきます。「まずは予約する人のプロセスを考えてみよう」「そういえば電話で連絡する人もいますね」「『LINE』や『Messenger』からの予約もありますね」「もしかすると『WeChat』からの予約もあるかもしれない」となります。可能性はたくさんあるため、このようなことを言い始めると収拾がつかなくなります。

その中で本当に必要なものは、先ほど言った台帳に書くデータです。このデータを確実に見つけ、記録していくことに、最初は取り組む必要があります。しかし、なかなかその発想には至りません。業務の流れで考えると、その過程で立ち止まるポイントがあり、そこで必要なデータを記録していくことになります。

國分：これまでの業務システムの開発では、大人がたくさん集まって「『WeChat』はどうだ」といった話ばかりしていますよね。

松岡：おっしゃるとおりです。スマートフォンならまずは「iPhone」や「Android」に発想が飛びますが、その議論の前に「企業が本当に必要としているデータは何か」というところにフォーカスすべきだと思います。しかし、なかなかそこに至るまでが遠い状況です。それよりも、実際の業務やデータの構造から考え始めることが重要になります。

國分：そのあたりをシンプルに考えるアプローチが御社の特徴ですね。

松岡：おっしゃるとおりです。まずはそこを押さえることに取り組んでいます。

開発後のシステムの保守及び運用費用のインパクト

國分：一口に業務プロセスといっても、売上に関わるコアな部分なのか、そのような部分ではないのかでいうと、御社は完全にコアな部分のみに絞って取り組んでいるかと思います。

松岡：後ほどお話ししますが、その背景にはレガシーシステムの問題があります。実はシステム開発においては、システムを維持するコストが非常に高く、全費用の7割から8割を占めます。つまり、費用の大半は保守・運用のコストで、初期の開発コストはそこまで高くありません。

スライドでは、グレーの部分に「初期費用」と書いていますが、1年間の保守・運用費用はこの初期費用の42パーセント程度になります。これは、システムを作る期間よりも、当然使う期間のほうが長いためです。

國分：確かに、システムは数十年スパンで使われますね。

松岡：短くとも5年ぐらいは使います。そして、5年ぐらい使うと、保守・運用費用は初期費用の3倍ぐらいに、膨れ上がっていきます。

KTLOジレンマの発生:保守・運用費用の増加によるIT予算の非効率化

松岡：保守・運用費用の増加の何が問題かというと、こちらのスライドのように、最初のシステム自体がない段階では、IT開発予算に余裕があります。しかしシステムを作り出すと、作ったものの保守・運用費用が積み重なっていきます。その結果、IT予算を徐々に増やしていったとしても、保守・運用費用で予算が埋まるようになっていきます。

つまり、長い歴史のある大きな会社であればあるほど、システム開発の予算の大部分を保守・運用費用が占めるということです。したがって、我々のお客さまの8割は、IT予算のうち8割が保守・運用費用に割り振られている状態と言えます。

國分：昔作ったシステムのコストをまだ支払い続けている状態ですね。

松岡：OSを含め、いろいろなものが変わっていくため、少しずつ改修していかなければなりません。

國分：その都度、改修が必要となるのでしょうか？　

松岡：おっしゃるとおりです。その費用がかなり膨らんだ結果、新しくシステムを作るための新規投資が次第に減っていきます。

國分：スライドを見ると、確かに年々少なくなっていっていますね。

松岡：この保守・運用費用が費やされているシステムについて、なんとか保守・運用費用を下げて作り直さなければ、新しい投資はできません。これが我々のお客さまが抱えている問題です。

我々はそのような古いシステム、つまり多くの保守コストがかかっているレガシーシステムを、ローコードで作り直していこうと考えています。そして、これは今後伸びていく領域だと思います。

國分：私のような外部の素人目線で見ると、企業はそのようなレガシーシステムに機能を継ぎ足しながら今後もなんとか使い続けていくのではないかと思います。企業側にも、それをやめたいという考えはあるのでしょうか？　

松岡：あります。例えば、今まではA社が開発したシステムに、スマートフォン対応を新たに追加しようとする場合、開発したA社でなければ仕組みがわからない状態でした。もしA社にスマートフォンの技術がなければ、新たな開発は実現できないという課題があります。古いシステムと新しいシステムの融合は非常に難しく、結局のところ一から作り直さなければ、なかなかうまくいきません。

我が国の問題：GDP（国内総生産）の低迷

松岡：GDPと日本のIT投資額の差です。ご覧のとおり、米国はIT投資額の上昇に伴い、GDPも上がっています。一方、日本はIT投資額が上がっておらず、古いシステムをなかなか置き換えられていません。したがって、GDPも上がらない状態です。

レガシーシステムが成長の足かせに

松岡：外部のアンケートによると、67パーセントの企業が「レガシーシステムが足かせだ」と感じています。

このレガシーシステムは、主に1970年代から1980年代に作られたものです。これらのシステムに改修や機能追加を行い、10年、20年と使い続けている企業はいまだ数多くあります。現在直面している問題は、これらのシステムを20年前、30年前に開発した方々が定年退職を迎える、あるいはすでに退職していることです。

國分：1970年代、1980年代の人だと、退職時期を迎えていますよね。

松岡：結果として、古いシステムの構造を理解できる技術者がいなくなり、新しい拡張ができません。そのため、もう一気に作り変えないといけないという課題を抱えながらも、古いものを延命して使っているという状態が長く続いています。

國分：なぜ、抜本的に作り変えられないのでしょうか？　

松岡：作り変えることはできますが、非常に時間とお金がかかるためです。20年、30年にわたってパッチワークのように継ぎ足していったものを、いったん解析してきれいにする必要があります。そのためには多くの人と時間がかかります。

今はIT人材不足もあり、それだけの人を集められないということと、業界がかなり変化しているため、10年かけてシステムを作っても、おそらく業界が変わっている可能性があります。IT投資が無駄になる可能性があり、コストメリットがないわけです。

そのため今は、それを細かく砕いて、ローコードで少しずつ切り離して作っていくという方法で進めている状況です。

國分：それは御社だけではなく、業界的にそのような提案が増えているのでしょうか？　それとも、御社にだけ依頼が集中しているということでしょうか？　

松岡：先ほどお話ししたように、だいたいローコードは、レガシーマイグレーションのために使うというよりも、新しい領域で使うとか、試験的に小さく作ってみるというところに、多くの企業は使っています。

ただ、我々は大規模なレガシーシステムを置き換えるために提案していることもあり、同じローコードを扱っているベンダーでいえば、当社がかなりレガシーシステムにフォーカスしているということは言えます。

なぜシステム開発にローコードを使うのか？

國分：ご覧になっている方は、もしかしたらピンとこないかもしれません。ローコードというのは、どのような提案になりますか？

松岡：まず、「ローコードとはそもそも何か」というお話をします。スライドに示すとおり、システム開発というものは、基本的にはエンジニアとプログラマーが行っていきます。

従来型では、まず「どのようなシステムを作りたいか」という要件が書かれた要件定義書を、コンサルティング会社やSIerの上流エンジニアが作り、それを見て設計書を書きます。その設計書をプログラマーが見て、ソースコードを作ってソフトウェアを作っていきます。

そこに1つ問題があって、設計書はシステムの設計内容が書いてあるはずですが、設計書を見ても、同じシステムというのは出来上がらないということです。なぜかと言うと、間に人が入っているため、設計書をどう解釈して作るかはプログラマーの能力次第だからです。そのため不可逆なものになっており、ブラックボックスになってしまうわけです。

國分：結果、振り返った時に「なぜこう作ったのかわからない」というわけですね？

松岡：最初の設計は満たしているのですが、設計書とシステムの間のギャップが大きすぎて問題があるわけです。

一方でローコードは、要件定義までは一緒ですが、設計書を書いたら、設計書から自動で全部コンピューターがシステムを作ります。

國分：全部自動ですか？　

松岡：全部自動です。つまりプログラマーが入らないため、設計書とシステムの内容が一致しています。そのため設計情報があれば、いくつでもシステムが再現できます。従来型では、同じプログラマーが同じ思考で作らないと再現できません。そのためブラックボックスなのです。作った人でしか改修できないという、けっこう大きな問題になってしまうわけです。

國分：聞いている話では明らかにローコードのほうが良いと思うのですが、そう簡単にうまく物事はいかないという感じでしょうか？　

松岡：これは業界の問題ですが、結局IT会社というのは、エンジニアとプログラマーを抱えてビジネスが成り立っています。そのため、そもそもプログラマーが要らないということは、産業構造が違うということです。

國分：自分たちを否定してしまうわけですね。

IT業界の問題：IT人材の不足

松岡：おっしゃるとおりです。やはり今は、IT人材不足で技術者の平均年齢も上がっているにもかかわらず、ITニーズはかなり高まっています。

IT業界の問題：システムインテグレーターの存在

松岡：今のシステムインテグレーターという業界では、エンジニアとプログラマーを共有して、お客さまが交互に使っていきます。

例えばA社が使って、その3年後にB社が使い、また3年後にC社が使うというかたちです。そしてちょうど4社、5社が終わった頃に、また最初のA社のシステムの切り替えが発生します。このようにエンジニアを共有することで、エンジニア教育もスマートにでき、企業も自社でエンジニアを抱えなくていいというコストメリットもありました。

これが今、DXやデジタル化の流れで全社同時に「システムを作りたい」という要望が出てきているため、結局人材不足が起きて、供給が追いつかないという状況です。

一方で、システムインテグレーターがローコードを使うかというと、今まで培ってきたノウハウがあり、おそらくそれを捨てることになるため、なかなか難しいと思います。

國分：それは勇気が要りますね。

松岡：そうですね。そこが非常に難しい領域かと思っています。

企業の問題：IT人材の育成ができない

國分：そのような意味で言うと、これまで長らく続いてきた業界の通念的、慣例的なものに対してかなり切り込んでいっておられますね。否定するまではいかないものの、まったく新しいものを提案している感じです。

松岡：そうですね。まったく新しいものを提案しています。ローコードは、システムインテグレーターも使っています。使っているのですが、1つ問題があります。これは実際にアンケートにも出ているのですが、「新しい技術を学んでも使う場がない」「評価されない」という問題が現実にあります。

システムインテグレーターのような会社では、手際良くプログラムを組めるのはすごいことです。しかしながら、ローコードを使うとそこは自動的に作られるため、あまり評価されません。また使う機会もあまりないというのが、アンケートの結果に出ています。さらに「学びが評価につながらない」という回答が一番多くなっています。

したがって、人材の育成が難しいという問題はあります。これは企業の中もそうですし、従来のIT会社もこの問題を抱えていると思います。

大規模システム向けローコード開発のリーディングカンパニー

松岡：したがって、我々はローコードの専業として最初から手掛けています。特に当社では「OutSystems」というローコードを使用しています。

我々は2009年からローコードを手掛けており、今から12年前の2012年にOutSystemsという会社と提携しました。その翌年から独占権を持って日本で開発を行ってきました。この頃は、ローコードという言葉もありませんでした。

この「OutSystems」は、従来と比べて10分の1くらいの人数でシステムを作れます。

OutSystemsはポルトガルの会社です。ポルトガルは西の端で、私たちは東の端ということで「東の端で手掛けるから」ということで総代理店契約を結びました。

実はシステムインテグレーター会社に、「OutSystems」を「今まで10人で手掛けていたことが2人くらいでできますよ」と勧めに行きました。60数社の日本の大手システムインテグレーターに持っていったのですが、全部断られました。

國分：彼らからすると、稼働率があってこそということもありますか？

松岡：稼働率もそうですが、やはり「自動で作るものは手で作るものよりも劣る」というイメージがあるようです。それもあって、当時はまったく響きませんでした。そこで我々は直接お客さんに持っていこうと考えました。実は当社は、85パーセントくらいは直接取引です。

國分：直接取引ですか？　すごいですね。

松岡：大手企業と直接取引しています。直接お客さまに見せる時も、IT部門ではなかなか響きません。やはり今までの慣習もあり、「今お願いしているところにお願いしたい」と言われてしまいます。

しかし業務部門や経営企画、あるいは経営者の方に見せると、「このようなものがあるのなら、これを使おう」となるのです。そこから積極的に広げていったのが、今から10年くらい前です。

2006年のAWSのリリースがクラウド化とスマホ化を加速

國分：本当に、業界の当たり前を壊しにいっていますね。お客さまはそのような大企業が中心だと思いますが、未だにコンサルと大手システム会社がガチッと組んで作っているイメージがあります。そこについては、現場は変わっていっていますか？

松岡：システムの作り方はかなり変わってきています。スライドのチャートを見ると、今では当たり前になっている「AWS（Amazon Web Services）」が出てきたのが2006年と、意外と最近です。

クラウドができた2006年以降、「iPhone」や「Google Android」ができたり、「Uber」が出てきたりと、たくさん出てきました。これらは実は、クラウド化とスマホ化です。この流れが2006年から一気に加速します。

クラウドとスマートフォンはシステム開発のスタイルを大きく変化

松岡：そしてデジタルトランスフォーメーション（DX）という流れが出てきます。これは何が起きたかと言うと、例えばタクシー配車アプリのようなものを作ろうとした時に、昔は地図を地図会社から権利を買っていたわけですが、今は「Google Map」を使えばすぐにできてしまいます。このように、インターネット上にあるクラウドのいろいろな機能を組み合わせることで、アプリを作ることができるわけです。

例えば決済ならば、スライドにある決済APIの「Adyen」を使うとか、通信や先ほどの「Google Map」、メールを送るサービスなど、いろいろなものを組み合わせるだけである程度システムができてしまいます。

つまり、今までシステムを一から作っていたところから、ネット上にあるものを組み合わせて作るというふうに、システムの作り方が大きく変わってきています。

インターネットのアクセスの68%はスマートフォン経由

松岡：さらに、スライドは2020年のデータですが、もうインターネットのアクセスは、ほぼスマートフォン経由になっています。昔はパソコンから見ていましたが、今はインターネットを見るためにパソコンを持っているという人はあまりいません。

今は本当にスマートフォンメインになっていて、スマートフォンの爆発的な普及とインターネット上のクラウド化のサービスの組み合わせでシステムを作ることによって何が起こったかというと、今まで業務システムの世界はパソコンが中心で、システムインテグレーターがノウハウをためていたわけですが、そのノウハウが陳腐化して使えなくなってしまいました。したがって、いくら従来型のシステムのノウハウを持った人たちが集まっても対応ができないということです。

スマートフォンの利用拡大が業務システム開発を変革

松岡：実はこれは海外でも同じです。スマートフォンへの急速な対応を迫られるため、世界中でローコードがブームになっています。ローコードを使用することによって、さまざまなサービスを組み合わせ、素早くアプリを作ることができるためです。

スマホ化とクラウド化が進んでいなければ、おそらくローコードは使用されていなかったと思われます。従来のノウハウが陳腐化したことで、新しいソリューションの必要性を感じたお客さまから、直接、当社にお声がけいただいています。

國分：直接、御社に依頼が来るということですね。

松岡：そうです。システムインテグレーターやコンサル会社も、クラウド対応やスマホ対応に一生懸命取り組んでいますが、おそらく、これまでのノウハウがあまり活きてこないため、同じスタートラインに立っているというのが、我々の魅力かと思います。

國分：松岡さんからも、たびたび、アジャイルやローコードのお話が出てきますが、最近はアジャイルという言葉をよく耳にします。「うちはアジャイルで開発します」と言って、どの会社も開発している印象がありますが、それとはまた違うのでしょうか？

アジャイルとウォーターフォールの違いは投資リスク

松岡：当社もアジャイルにすごくフォーカスしています。アジャイルというと、よくウォーターフォールと比較されます。スライドはウォーターフォールとアジャイルを絵で比較したものです。

ウォーターフォールは、将来を予測し、大きな単位で注文するイメージです。スライドは牛乳を例にしていますが、1ガロンの牛乳のパックを2つ買えば一番安いわけです。つまり、ウォーターフォールは、将来がわかっていれば最もコストがかからない方法です。全部決めて注文するため、迷いもありません。

一方でアジャイルは、将来何を飲むのかわからないため、小さい単位で注文します。牛乳もグラス単位で発注するため、明らかにアジャイルのほうが単価は高くなります。しかしながら、変化に対応できるという違いがあります。

國分：急にオレンジジュースが欲しくなっても大丈夫ということですね。

松岡：そうです。コーヒーが欲しくなっても大丈夫です。途中にワインを挟むこともできます。新型コロナウイルスによる影響で、急激に変える必要が出てきたことで、アジャイルにフォーカスされるようになりました。ただし、コストが高いため、管理が非常に難しいということがあります。

なぜアジャイルは難しいのか？

松岡：考え方も経験則ではなく、「不確実性に立ち向かう確率的思考」が必要になります。要は将来がどうなるかわからないので、データに基づいて判断しなくてはならないということです。スライドにある経験と勘による因果的思考、つまり過去の経験からこうなるだろうと予測するのがこれまでの開発です。

國分：スライドのような人はいますよね。

松岡：そうです。とにかく長く働けということです。これからはデータに基づいて、実際にやってみて、その結果に基づいて意思決定していきます。これがアジャイルで、確率的に何がいいのかを探していきます。

アジャイルとは、不確実性が高い方法をさまざまな仮説を立てて検証し、うまくいったものを集めて、成功する可能性が高い方法を見つける手法というのが、当社の考えです。

アジャイルにおけるプロジェクト管理のイメージ

松岡：プロジェクト管理というのは、ガントチャートにしたがってタスクをこなしていくことが多いのですが、アジャイルは、実は工程を変えるため、非常に管理が難しく、なかなかうまくいきません。

國分：すごく複雑ですね。

松岡：しかしながら、リスクを回避できるのは、スライドの右のアジャイルです。リスクがある時は、違う道を通ることができます。

國分：確かに、いろいろな道がありますからね。

松岡：左のウォーターフォールは、リスクがあっても突き進むしかありません。つまりこれが、何年経ってでも作り上げるとか、予算をオーバーしても作り上げるという問題に行き着くことになります。

國分：ATMの話が頭によぎります。

松岡：アジャイルはリスクが高いとか、計画性がないと言われるのですが、実はリスクが高いのはウォーターフォールのほうだと考えます。何か問題が起きた時には避けられないからです。

システム開発の総工数は「計画」「製造」「リファクタリング」の合計

松岡：加えて、少し難しい話になりますが、コストの話があります。システムを作るコストというのは、「計画する」「作る」「改修する」の3つの総工数がシステムのコストになります。

ウォーターフォールとアジャイルで何が違うかというと、システムを作る工数は大きく変わらないのですが、それを計画するコストと改修するコストが違います。

目指すのは「適度な要件定義」と「適度なリファクタリング」による工数の最小化

松岡：スライドのグラフには要件定義の量と記載していますが、事前に調べて要件定義をたくさん行うと、当然、計画するコストは上がってきます。改修するコストは、理解せずに始めてしまうと、ぜんぜん違うものができてしまうので、要件定義をしていないとコストがたくさんかかります。逆に、要件定義をたくさん行うと工数が減っていくというイメージ図です。

このグラフを足すとスライドのような曲線になるのですが、右側のウォーターフォールは、計画するコストをたくさん使って改修工数を減らします。一方、アジャイルは計画する工数を減らしますが、改修するコストは上がります。我々はその真ん中ぐらいを行こうとしています。

國分：絶妙なところですね。

松岡：ある程度の計画と、ある程度の改修のバランスをとったのが、当社独自の方法です。これは差別化ポイントで、何時間でも話せてしまいます。

國分：差別化しているということは、そう簡単にここには行けないわけですね。

松岡：これまでの経験を捨てる必要があるため、非常に難しいと思います。

國分：アジャイルをやっていると言う会社も、簡単にここは狙えないということですね。

松岡：アジャイルをやっていると言う会社は、おそらくスライド左側で、あまり計画せずに、積極的に改修していきます。スピードがあればできるのですが、スピードも徐々に長続きしなくなっていくため、我々はそこを狙おうと考えています。

國分：そこが御社独自のポジショニングということですね。

本当の人材不足はこれから始まる

國分：今回はビジネスモデルの話が中心でしたが、今期以降の計画を見た時に、スライドに記載のように、2026年、2027年あたりでグッとフェーズが変わっていく印象がありますが、この裏側で何が起こるのかを教えてください。

松岡：これは社会の話ですが、労働人口というのは、実は2012年以降から増えていて、就業者数も増えています。

國分：増えているのですね。減っているイメージでした。

松岡：今まで働けるのに働いていなかった人が労働人口に参加しています。したがって、人口は減っているものの、労働人口は実は増えています。

ただし、飲食やインバウンド系の旅行業界などは人材が劇的に減っています。つまり、統計的に見ると、労働人口は増えていますが、将来、この就業者数と労働人口の差が段々となくなってきて、それが本格的な人材不足となるということです。

そうなると、デジタル化を進めて人の代わりに動いてくれるようなものを作らないと、本当に現場が回らなくなる世界がもうすぐやってくるというのが、このグラフです。

デジタルレイバーによって売上はどうなるのか？

松岡：おそらく、今後は少子化のインパクトもどんどん出てくると思われますが、我々は人の代わりになるような、デジタルレイバーというサービスを作っています。我々も技術者主体のビジネスでは急激に伸びることはなく、スライドの赤いグラフのイメージになるのですが、我々のエンジニアの代わりに働いてくれるソフトウェアロボットを製造することで、売上を上げていくイメージです。

誰がエンジニアの代わりにシステム開発を行うのか?

松岡：簡単に言うと、今まではシステムの利用者の要請により、エンジニアがローコードやクラウドを利用してシステムを作っていましたが、それがソフトウェアになり、24時間、命令するとシステムを作ってくれるというものです。

國分：そのような世界が来るのですか？　

松岡：生成AIとうまく組み合わせることで、実現可能になってきています。

國分：これまで人がやっていたことを、人ではない人がやるということですか？

松岡：そうです。そうすると、エンジニアの数に比例した売上ではなく、急激な売上が期待できます。

國分：24時間、365日稼働できるわけですね。

松岡：そうです。

既存システムの問題にどのように対応するのか?

松岡：人件費も安くなります。ソフトウェアはコピーが0円です。古いレガシーシステムをそのまま作り直すと膨大なコストがかかっていましたが、デジタルレイバーを使用して、解析や分析を行い、設計情報を作成すれば、あとはローコードに投げ込めばシステムを作ることができます。

このような作業を、人手ではなくデジタルレイバーでやるような新しいシステムの移行サービスを、計画しています。

國分：これも30年後という話ではないですよね。

松岡：近い未来に実現します。

國分：すごいですね。業界に大きな一石を投じるような切り口ですね。BlueMemeさまは業界にズバズバ切り込んでいっている会社だということがよくわかりました。投資家のみなさま、今後にぜひ注目して見ていただければと思います。

今日は松岡さんにお越しいただき、ビジネスモデルについてお聞きしました。どうもありがとうございました。

松岡：ありがとうございました。