「生活者」の視点がなければDXは進まない

コロナ禍を契機として、私たちの生活はDXしたのか？

日本のDX（デジタルトランスフォーメーション）については、新型コロナウイルス感染症の全国的・世界的な拡大（以下コロナ禍と表記）をきっかけに進んだと語られるものを見聞きします。しかしコロナ禍はあくまでその流れをブーストしただけで、以前からその流れはありました。たとえば経済産業省が2018年9月に発表した『DXレポート』には、当時でもDXを進めるべき背景・理由と、指針やガイドラインが記されています。ここで興味深いのが、レポートが改訂されるに伴い、だんだんと「セルフマネジメント」と「パートナーとの関係性を新しいものにしていく」ことの重要性が取り上げられるようになったことです。「システムは外注するもの」という認識から、「自分たちで主導権をもって取り組むもの」に代わり、それを実現するうえで他企業との新たなパートナーシップが求められはじめている。そういう変化が国のレポートからも読み取れます。

実際、2020年に発表された『DXレポート2（中間とりまとめ）』（2020）には、中長期でDXを捉えることの重要性が説かれています。ここでいう中長期のDXとは、「自社の基幹ビジネスそのもののデジタル化」を指します。自社の中核となるサービスに、自発的なかたちでデジタルを組み込んだ状態が、「DX化が実践されている」ことだと策定されているわけですね。それを実現するためのキーワードが、「内製アジャイル開発体制」です。SIerに丸投げするのではなく、セルフマネジメントの領域を増やしながら、IT企業とデジタルサービスをつくっていく必要があると、国としても認識しているわけです。

では、そもそもなぜこういった話になっているのでしょうか？2020年4月、緊急事態宣言に入って1ヶ月ほど、それぞれの企業に対してDXの現状を聞いて回ったデータがあります。それによると、テレワークのためのリモートアクセスや、SlackやTeamsなどのコミュニケーションツール、つまり企業内部の業務を改善するためのIT化は非常に進んだ傾向にありました。その一方で、顧客向けの非接触オンラインサービスにどれぐらい投資がされたかというと、社内向けのIT化に比べて3割程度にとどまっています。ここから読み取れるのは、「社内体制を立て直すのに手一杯で、消費者の利便性を追求できていなかった」という状態ではないでしょうか。

出典: 株式会社アイ・ティー・アール「コロナ禍の企業 IT 動向に関する影響調査」（2020年 5 月）

実際、一人の生活者としてよく利用していてDX化されたサービスを思い浮かべたとき、まっさきに出てくるのが宅配サービスなのですが、主要サービスは海外企業ですよね。また、非接触のペイメントサービスも増えてはいますが、店舗レベルのところまでサービスがしっかり落とし込まれていたかというと、オペレーションがむしろ煩雑になってしまった面が目立つ声も聞こえており、本当に生活者のためのデジタルサービスを考え抜くことはできたのか、問いが残ります。

外資系コンサルティング企業が2020年に、各国でオンラインサービスがどれぐらい使われるようになったかを調査したのですが、そのサーベイからは日本ではオンライン化があらゆる分野であまり進んでいなかったことがわかりました。一方で、たとえばインドやイタリアでは、Netflixのようなオンラインストリーミング分野が非常に増えました。中国も進化していますし、興味深いところだとドイツでウェルネス分野が発達しています。一方で日本はどうかというと、ほとんどのカテゴリーで活発化が見られなかった。つまり新規ユーザーと利用回数が増えたユーザーの数が少ないわけです。まるで「もう一度元の状態に戻れるのではないか」と思っているかのように。

こうなった理由は2つあると考えます。1つは最初に話した「そもそも企業がオンラインサービスを提供できていない」ということ。そしてもう1つは「不便であることを受け入れてしまう」という国民性です。これはある意味で、日本がモノに恵まれているがゆえに起きる現象かもしれません。国によっては、あるサービスが受けられないと生き死に関わることがあります。一例として、海外に出稼ぎに来ている労働者が実家に送金したいとき、物理での手続きしかないと、ご家族にお金が送れないという問題が起こります。そういうクリティカルな問題が発生する国では、生活のデジタル化の進みが早かったと言えます。日本はもともとクオリティ・オブ・ライフが相対的に高いので、切迫感が足りないという事情はありそうです。

これからは「伴走」するパートナーが必要だ

では日本にとってDXが重要ではないのかというと、そういうわけではありません。グローバル経済と対峙する大企業、地域経済を回す中小企業のどちらにとっても、DXは重要です。とりわけ大企業は海外も巻き込んで国力を高めていくべく、ITの活用が急がれます。ここでは大企業に絞ってお話していきます。

日本の大企業がこれまでどうITに携わってきたかといえば、大手SIerに基幹システムを発注し、そのうえでお仕事をするというのが一般的でした。システムは大別すると、システムオブレコード（以下、SoR）とシステムオブエンゲージメント（以下、SoE）の2つに分かれます。

SoRは記録のためのシステムで、たとえば勘定システムのようなものを指します。一方でSoEは、ユーザーのエンゲージを高めることを目的としており、オンラインストアや公式アプリ、完全な新規事業などが該当します。

SoRの場合、ユーザーがほとんど決まっています。勤怠報告システムを構築するなら、誰が使うか事前にわかっていますし、社員と一緒に要件定義をすればいい。どんな要件や課題があるのかも対話を通してわかりますし、どういう流れでボタンを押していくのかというワークフロー定義も、目の前にユーザーがいるのでちゃんと定義できます。なにより勤怠報告はいろいろな会社がやっているので、基本的な「型」があります。

耐用年数についても、会計上の減価償却は5年なので、そのタイミングで入れ替えるタイミングがきます。これがSoRのサイクルです。そのためSoRでは、計画や見通しが重要になってきます。そういう意味でいうと、SoRとはミスが許されないシステムです。だからこそ開発計画書や提案依頼書を作成し、大規模なSIerに発注するというウォーターフォール型のやり方が採用されます。今でもそれは有効な手法だと考えます。

対してSoEは、消費者や生活者と接点となるサービスが主です。アナログなサービスをデジタルと組み合わせることで生活者との接点をつくったり、それを支えたりするサービスですね。SoRと比べると、SoEのユーザーは不確定です。ペルソナ（仮想ユーザー）は最初に決めますが、ターゲットにしたユーザーが実際使ってくれるかどうかは、仮説を検証しなければわかりません。結果として、幅広いレンジのペルソナを作成することになります。

ワークフローも、SoEとSoRでは異なります。SoRでは、積年の業務ノウハウをもとにした「型」があり、ある種の正解があります。一方でSoEの場合、ワークフローはいわゆるUX/UIという言葉に置き換えられます。何が最適なUX/UIなのかは、時代によって変わります。たとえばスマートフォンのUIは、GoogleやAppleによるガイドラインがあり、一定期間で更新されていきます。また、ユーザーのボリュームゾーンが最も使うサービスによって、UIのスタンダードは変わっていきます。トレンドがどんどん変わるため、何が最良なUIなのかは、そのときによって異なってきます。絶対的な正解はないのです。

また、SoEも減価償却の影響は受けますが、SoEは「できるだけ長く保ってほしい」というのが基本姿勢にあります。ユーザーも変わっていくので、システム自体の拡張や変更も求められます。つまりSoEの場合、「長期でシステムやサービスと向き合い、チューニングし続ける」という動き方が求められます。これはかっちりと仕様を決め、ウォーターフォール型でやっていくSoRとは真逆の考え方です。

「受託開発」と一般的に言われているのは、ウォーターフォール型の発注〜納品の形式を指すケースです。これはSoRでは有効ですが、SoEには適していません。SoEでは常に伴走・支援する、長期的な運営をやっていけるパートナーを探す必要があります。日本がDX化を進める以上、SoEの発展は不可欠であり、だからこそ「内製アジャイル開発体制」や、DXを対等な立場で推進できるベンダー企業を国も推進しているわけです。

社内にエンジニア集団を抱えるのは現実的ではない

ここまでは、サービスをデジタルで実現していくシステムをどう構築するかという話をしてきました。しかしなぜそれを「内製化」というキーワードをもとに、セルフマネジメントしていかなければならないのでしょうか？答えはひとつ、これからの事業会社のサービスは、デジタルを伴ったものが基幹事業になるからです。

これがすでに始まっている領域でいうと、IoT（モノのインターネット）が挙げられます。もう7年ほど前から、インターネットを経由した「見守り」という市場が生まれたり、節電具合の可視化がスマホでできたりと、これまでなかったサービスが当たり前になってきました。複合機のトナーがインク切れを起こしたり故障したりしたら、それをインターネットから検知して代理店や販売店に情報を伝え、すぐにサポートが来れるようにもなりました。こうしたサービスはサブスクリプションとして売れるので、継続的な利益になるという強みもあります。モノを通して関係性を築く好例と言えるでしょう。

このようなデジタルと既存のサービスを組み合わせる方法は、今後ますますスタンダードになってくるはずです。そしてこれを実現するには、デジタルだけではなく既存のサービスに対する深い理解が不可欠です。だからこそ外部のSlerに発注するだけではなく、「内製化」が重要になってきます。いまDX推進室やデジタルプラットフォーム開発部と呼ばれるような部署が増えているのも、そうした背景があるのではないでしょうか。

では何をもって「内製化」とするべきか。1つのゴールは、「セルフマネジメント」するところにあると思います。これは、かならずしも自社内でプログラマー集団を揃えるということを意味しません。自分たちの事業方針を理解し、自分たちのリソースをしっかり見極めつつ、社外のサービスやチームとどうコラボレーションしていくかを判断することも、重要なセルフマネジメントのひとつだといえます。というのも現実的に考えて、プログラミングやコーディング、テストをしていくようなプログラマー軍団を、社内で抱えるのは日本だと難しい場合が多いからです。プログラマーは市場のなかで少ないですし、そもそもエンジニアの本懐は、さまざまなサービスにテクノロジーを使う場面を体験しながらスキルを上げていくことにあります。ひとつの事業に集中している会社に、高度なエンジニアとして入るというのはキャリアビジョンとして考えにくく、定着しにくい。さらに言えば、自社でエンジニア軍団を抱えるということは、評価制度を自社で確立しなければならないということでもあります。正しく評価しなければ、人は根付きません。こうした理由から、事業会社がエンジニア軍団をつくるのは難しいのです。

もちろん例外もあります。ひとつの事例ですが、2015年にアクセンチュアとファーストリテイリングが合弁会社ウェアレクスを立ち上げました。このように、デジタルとストラテジーを強みとする会社と合弁し、DX人材をつくっていくという方向性は考えられます。しかし単純に「CTOやCIOを設ければDXの内製化ができる」ということにはならないでしょう。DXの推進については、計画段階からパートナー企業と一緒にやっていったり、インターネットサービスをつくれる会社と良好な関係を築いていったりするのが重要なアクションだと思いますし、国もそのように推奨しています。社外との協業を通じたスキル向上というところに、話が戻ってくるわけです。

日本の大企業は今後、よりデジタルな力を使っていきながら、サービス開発や運営をしていくことになるでしょう。旧態依然な仕事のやり方とはまったく異なります。これからは大企業も、スタートアップ的な発想をもって事業開発に取り組まなければならなくなってきているのです。

スタートアップ支援を通じて日本のDXを促す

ここからは、いわゆるスタートアップと言われている新興ベンチャー企業が、成長する過程でどういう問題にぶつかり、どうやって解決していくのかという話に移りたいと思います。なぜゆめみがスタートアップに着目するのか。それには2つの理由があります。

1つ目は、大企業がDXをしていく際、ベンチャー企業のような異質な存在と交わってアジャイルな発想法をインストールすることに意味があるから。2つ目は、なにか新しいものをつくるとき、1からプロトタイプをつくる必要はかならずしもないからです。たとえばSaaS（Software as a Service）をうまく使うのも、大企業にとってはDXの手段のひとつです。SoRについても、いまは何年もかけて自前でつくる必要はありません。その業種に特化した業務システムがSaaSやRPAとしてリリースされているので、それらをうまく使って業務を効率化し、企業リソースを別に割くのもDXのひとつです。そして、それを支えているのがスタートアップだと思っています。

つまり日本のDXを促進させるうえでは、大企業を直接支援するというルートと、スタートアップを支援することで間接的に大企業の成長につなげるという2つのルートがあるわけです。ゆめみがスタートアップのプロダクト開発支援をおこなっているのも、日本全体のDXを促すためです。そのうえで、これから話すスタートアップについての議論は、大企業の新規事業を検討するうえでも役に立つと思っています。

スタートアップの成長性というのは、大企業の目線で置き換えるとサービスの規模や売上、価値に置き換えられます。その価値は時間を追うごとに上がっていき、やがて衰退していくというライフサイクルを描きます。このライフサイクルを詳しく見ていくと、(1)立ち上げ、(2)成長、(3)成熟、(4)衰退、(5)転換という5つのフェイズに分けられます。

多くのスタートアップは、熱意のあるCEOが起業し、例えば大学やSNSで意気投合したエンジニアがCTOになるという出会いなどを礎に、プロジェクトが立ち上がります。それが市場で受けたり課題を解決できたりできると確信をもったら、どの市場でどのお客さんがお金払ってくれるのか、お金を払ってくれる人がどれぐらいいていくら稼げるのか、いくらまで売上のシェアをとれるのかをリサーチします。大企業もこうしたプロセスを踏み、そのうえで稟議をあげて投資するかどうかを決めますが、スタートアップの場合はよりシビアにこれを行い、資金調達します。これが立ち上げ期です。

この時点で先々のリスクをみてみると、CEOとCTOの二人で立ち上げた場合、「プロダクトが属人化されすぎる」ということが起こります。しかもそういう人たちは情熱的に、本当に過労死してしまうのではないかというほど働きます。なので資金調達したら、エンジニアやUIデザイナーの確保に移るわけですが、立ち上げメンバーの情熱をそのまま引き継がせるのは困難です。属人的なものを組織的な課題に転換すること、つまりチームビルディングが必要になってきます。これは大企業も同じです。立ち上げがうまくいっても、部門化したときにうまく回らなくなるというケースが往々にしてあります。いずれにせよ立ち上げ期はこういう課題があるわけです。

プロダクトができた瞬間に「技術負債」は始まる

その後、うまくプロジェクトが走り出すと、成長期が訪れます。資金調達で得たお金を使って人材獲得や広告投資に力を入れると、プロダクトの価値や売上が上がりますよね。そうなると今度は競合が生まれます。競合が出てくると採用競争が発生するので、他社との差別化やマーケティング、ポジショニング戦略を研究しなければならなくなり、エンジニアリングとマーケティングの両輪を回さないとその後の成長につながりません。

また、ニーズがあるとわかったら、機能追加やキャンペーンをしていくわけですが、これがリスクにつながります。機能追加やキャンペーンをしていくなかで、徐々に複雑になったコードが全体の整合性や秩序を崩していくーーいわゆる「技術負債」というものが、とだんだん蓄積していくーーこれが成長期におけるリスクです。この段階ではまだ顕在化しませんが、あとあと問題を引き起こします。大企業のシステムでも同じです。そもそもプロダクトは、できた瞬間に負債がはじまります。その価値が増えれば増えるほど、負債も増える状態になるわけです。

技術負債が生じる主要因は、開発における「ブランチ」です。ブランチとは、たとえば開発体制をAチーム、Bチーム、Cチームの3つにして、ソースコードを分けて担当し、最後に合流させるというやり方を指します。ブランチが増加すればするほど、「参照先のライブラリはこれで正しかったっけ？」とか「ソースコードが古い時点のままマージしようとしている」ということが起き、それが技術負債やバグを生みやすくしてしまいます。

「依存性の複雑化」という現象もあります。3チームそれぞれが別の機能をつくっているとしましょう。その根幹の技術ライブラリが似ているという話になったとき、それをマージ（統合）することになると思います。そのとき、もしAチームのバグが発生して機能を下げたいとなっても、他のチームに影響が出てしまう……ということも起きます。これは成長期に特によく起こる現象です。

スタートアップや新規事業は、成長スピードを緩めてしまうとシェアが取れなくなります。だから何か問題が起きたとしても、根本的なところを見直していくというよりは、ソースを書き足すことで解決を図ることも許容していく必要がある。それも対処方法としてはひとつの選択肢ではあるんですが、後で負債が顕在化するリスクに立ち向かわなければなりません。

さて、機能追加をしていく成長期を超えると、今度は成熟期にいったん入ります。競合が複数いて、市場におけるリーダー、チャレンジャー、フォロワーがおおむね決まっており、それぞれの関係性が拮抗した状態ですね。こうなると一番恐ろしいのは何か？そう、解約なんです。いま取引しているお客様を他社は奪いにくるわけで、守りに入らなければなりません。

加えて、成熟期はプロダクトを安定させなければならない時期でもあります。これまで積み重なってきた技術負債が顕在化するタイミングだからです。Aの機能を変更したらBにまで影響が及んでしまったり、顧客のニーズに合わせて一部の機能を改修した際に新しくコードを書き直したら、他の人にはソースコードがわからなくなったりということが起こります。これはまさに技術負債の顕在化です。この状態になると、変化のスピードが明らかに鈍化します。なにかを触るとバグとか不具合が発生するので、プロダクトの品質が低下しますし、プロダクトに新しい手を加えることに開発チームが乗り気じゃなくなってきてしまいます。心理的なハードルが高くなり、投資に対して得られるアウトカムが何なのかが見えにくくなってくるからです。そうやって足踏みしていると、競合会社がどんどんお客様を奪っていきます。

このように、成熟期はやることが多いです。市場にあった機能を提供しなければならないし、マイナスな不具合があったら直さなければいけないし、既存でやっている品質自体も安定させなければならない。潜在的なバグや不具合が見えているなら、それも先手で直していかなければならない。どう優先順位をつけていくかによって、成熟期の行く末が決まってきます。

そのうち市場に新しいプロダクトが生まれたり、トレンドがすぎたりすると、衰退期に移ります。成長期や成熟期は必要に応じて投資していきますが、衰退期になるとコストの削減やプロダクトのスリム化が主になります。衰退期以降については、今回はあまり触れません。そして転換期になり、組織を縮小するのか買収するのか、あるいは事業自体をピボットするのか、ふたたび価値を上げていくための意思決定をすることになります。

デザインリードが組織の「属人化」を防ぐ

こうしたライフサイクル上のリスクは、スタートアップにも大企業にも共通しています。アジリティが高いと、それに応じたリスクが生じます。それに対してどう補えば、リスクが最小化されるのか。これがゆめみのサービスにつながっていきます。

先にも述べたように、立ち上げ期の課題は、少ない情熱のある人数でプロダクトをつくっていることによる属人化でした。これをチームとしてやっていくためには、CxOやキーマンの頭の中にあるUXや戦術、戦略、妄想、想像、仮説を、チーム全員にわかるように可視化していく必要があります。あるいは、そのプロダクトで達成したいパーパスやミッションを可視化していくことで、強いチームをつくっていく。これを早期にやらなければいけません。大企業でも同じです。というのも大企業には往々にして人事異動があるからです。人事異動があると、せっかく来月から成長期に入るというタイミングで、異動の連絡が入ることもあります。そうなると引き継ぎ資料が急に必要になってくるので、可視化は常に求められます。

この段階で必要になるのが、サービスデザイナーという存在です。ただ、サービスデザイナーを最初から自社で抱えるのは、費用面から難しいという事情があります。だからスタートアップなら、CEOが自ら社内向け資料をつくったり、noteを書いたりすることで意志を伝えようとするわけですが、こういうことを組織的にやるならデザインリードを専門にしているパートナーと組むほうがいい。ゆめみはこの段階のスタートアップに対して、チームビルディングにを行うデザインリードを担当します。いわゆるプロダクトマネジメント支援ですね。

また、サービスの成長期においていち早く負債を見つけ出すためには、未来に対する予測が必要になるわけですが、予測するためには実績が求められます。スタートアップの立ち上げ期からいるCTOは、多くの場合20代でプログラムをたくさん書いているような方が多い反面、長期的に動くプロダクトを担当したことはあまりありません。そこでゆめみは、大規模なプロダクトの成長期を経験している会社に対して、「こういうパターンが後々考えられますよ」と寄り添って、「アーキテクチャ長期戦略」を考えていくべく、技術レベルでアドバイスしたり、実際に開発に携わったりしています。

さらに、成熟期の「技術的負債でスピードが低下する」という問題に対しても、ゆめみは解決をお手伝いしています。成熟期では優先順位をどうするのか、固定化したリソースをもとにどう順位付けするのかを考えなければなりません。そのためのひとつの選択肢に、いわゆる「スクラム伴走」という手法論があります。ゆめみはお客様の開発レベルにあわせて、ともに走りながら考えていく開発体制を進めています。国の資料でも、「一括で丸投げする従来の発注ではなく、伴走してもらえるパートナーを探そう」という趣旨のことが書かれています。プロダクトを立ち上げたキーマンに属人性があるのであれば、それをチームメンバーに伝えるというワークをゆめみがお手伝いすることも可能です。また、ファーストローンチの段階でシステムをつくる際、「数年後を考えるとこういった技術リスクが発生する」とアドバイスしたり、はじめからそれを防ぐためのアーキテクチャ長期戦略を提供したり、解約されないための工夫やバグの防ぎ方、一部機能追加やUIデザインのリニューアルを担当したりなど、長期に渡ってスクラムで伴走しながら開発するチーム体制を敷いて、お客様と一緒に成長させていきます。

ここで重要なのは、伴走していく過程で、私たちのアジャイル開発のやり方や長期的なシステムのビジョンの持ち方、キーマンの考えている発想やマーケティングの考えを、チームに伝えていく媒介になることです。そうすることで、大事なノウハウを全体に還元していきます。だから「一緒にやる」ということが大切で、その結果としてお客様が長期的にセルフマネジメントできるようになり、内製化のための大きなステップになると私たちは考えています。これをまとめたのがこちらの図です。

「生活者」の視点から問題を解決せよ

このようにゆめみは、お客様のセルフマネジメントを支援し、内製化を進めていくわけですが、「内製化したら、ゆめみはいらなくなるのではないか」と疑問を持たれる方もいらっしゃるかもしれません。

究極的に言えば1つのゴールとして、ゆめみからの「卒業」でいいと私たちは思っています。というのも、事業の成長ステータスによって必要なパートナーは変わってくると考えているからです。そのお客様が内製化、セルフマネジメントのところまで到達したら、今度は別のお客様を支援しにいく。国内の企業には、まだまだ困っているところが多い。ゆめみを「卒業」したからといって、自分たちのビジネスがなくなることは当面ないと思っています。

もうひとつの方向性としては、役割分担が挙げられます。ゆめみには「ITとサービスデザインの専門家」という自負がありますが、そうはいってもNFTやWeb3.0のような最近の概念については、初めは全員、素人なわけです。しかしすばやく理解することには自信があります。代わりにお客様には、自分たちのビジネスがデジタルと組み合わさることで生活者の問題を解決するのかを集中して考えてほしいと思っています。ゆめみとしても、新しい技術をどう応用したらサービスと接合するのかを考えていきますから。そうすることで、それぞれのコア領域をより明確にして役割分担し、それらを組み合わせていけるようになるはずです。つまりお客様には、ITのマネジメントのところまでは身につけていただきつつ、新しい領域の技術やアイデアについてはゆめみが先導してリサーチし、「こうやったら組み込めますよ」と新しい価値を提供していく。成熟期のスクラム伴走を続けるだけではなく、業界がどんどん変わってきたりムーブメントが起こってくるなかで、それにどう適応するのかを提案する。これも内製化のひとつのあり方ではないでしょうか。

ここまでスタートアップを念頭にお話してきましたが、こうしたヒントはこれからの大企業にもかならず役に立ちます。課題が共通しているからです。私たちゆめみであれば、きっとその課題解決のお手伝いができます。その理由ですが、ゆめみという会社はビジネスパーソンである以前に、「自分たちが生活者である」という感覚が強いんです。株式会社NTTドコモのiモードができたのが1999年なのですが、ゆめみは2000年1月に創業。その時点でモバイル領域でコンテンツ事業をおこなうほか、企業のデジタルサービス運営を担当していました。自分たちが豊かになるサービスは、自分たちでつくる。さらに他の企業も巻き込んでやっていけば、もっと豊かな社会になれる。そういう想いでここまで成長してきたという背景があります。

たとえば僕たちは、大手企業でいえばコーセーさんとパートナーシップを組んで、家からビューティーコンサルタントと面会し、次の季節の基礎化粧品を一緒に選んでいけるようなウェブサービスを開発しています。これは自分たちの生活がモバイルでどう変わるかを「生活者」視点で考えているからだと思います。ゆめみという会社は、もちろんエンジニアだったりデザイナーだったりと、ビジネスパーソンという側面もあるのですが、それ以上に「自分たちは生活者である」という意識がすごく強い。だからこそ、最初にお話したようにコロナ禍という異常事態を経ても、「生活者のサービスって、実はあまり変わっていないよね」というところに視点がいくわけです。

「自分たちも生活者である」という発想を、事業者の仕事を組み合わせることで、日本をテックな国にしたいというのが僕の想いです。そしてそれは、ゆめみのビジョンである「世界中の人々の生活の中で使われ続けるサービスを、顧客企業と共に創りあげる」につながっていきます。テクノロジーとアイデアを自分たちのものにすれば、生活や体験は新しくなるということをもっと伝えていきたい。コロナ禍になって、会議中にお子さんが入ってくるのも、Zoomだったら当たり前になりました。家にいるのだから当然ですよね。でもコロナ禍以前に出社していたときは、会議室があってスーツを着ている人たちがするというのが「仕事」でした。

いまは生活と仕事の境界線が曖昧になり、私たちの「当たり前」が変わってきています。仕事をしている自分たちも「生活者」であると気づいた大企業の人たちは、実は結構いるのではないでしょうか。今までだったら「仕事の時間は仕事だけ」でしたが、子供が泣いて部屋に入ってきたり、「ご飯どうしよう、お迎えどうしよう、時間がない」という悩みに直面したりして、「仕事と生活の違いってなんだろう」「自分だって生活者なんだ」ということに気づく。日常の中で「このサービス使いづらい」と疑問や課題を感じたとき、生活者という視点に立って、「では、自分の企業のサービスはどうだろう」という問いかけと、同じく生活者であるエンドユーザの事に、もう少し気持ちを傾けてみてほしいと思っています。

企業で働いている人たちが、「自分たちも生活者なんだ」として気づいた今だからこそ、生活者としてモバイルを事業化してきた僕たちと一緒に、生活者視点で日本の社会にデジタルをもっと取り入れて、スタンダードなものにしていきたい。これが内製化支援をする、僕たちゆめみの想いです。

（話者：工藤元気、文：石渡翔）