｢商売｣をWebサービスに起こすDXの本質 デジタル窓口の設計が顧客満足に直結する理由
｢DX｣を通り越した業界、
今まさに｢DX｣に立ち向かう業界
――コロナ禍の後押しもあり、ビジネスの世界では「DX（デジタルトランスフォーメーション）」が声高に叫ばれています。ゆめみは、日本マクドナルドや大阪ガス、高島屋、RIZAPなど、数々の一般ユーザー向けWebサービス、スマホアプリの企画開発・システム設計を経験していますが、最近の企業の動向はいかがでしょうか。
工藤 元気氏（以下、工藤）：われわれが数多くアプリ開発に携わってきた小売業界は、オフラインとオンラインの境目がコロナ禍でさらに曖昧になってきています。これは、どういう段階かというと「デジタライゼーションはいったん終えて、本質的なユーザー体験の最大化を考えるとオフラインとオンラインの境界は意味がなく、あらゆる顧客接点を複合的に考えていこう」というフェーズ。
小売業界は従来からO2O（Online to Offline）やオムニチャネル、OMO（オンラインとオフラインの融合）とトレンドが速いテンポで移り変わってきており、経済界では最もデジタル投資が行われてきた業界だと思います。
一方で、金融業界や不動産業界では、証券や通販保険といった領域で比較的デジタル化が進んでいますが、デジタルでサービスが変革されるまでには至っていないと考察しています。つまり、サービス全体がシステム開発を通じてデジタル統合された顧客接点とはなってはいない。
ただ、2020年は「対面での契約」「対面重要事項説明」といった慣習やルールに関しては、金融庁や国土交通省などの行政主導で急速に見直しが進んでいます。ですから、ユーザーの利便性向上のためには、まずはサービス全体をデジタル統合し、アプリを企業の窓口として据える必要があるでしょう。
「組織の構造」と「サービスの構造」は似る？
――実際に金融業界や不動産業界からの引き合いは増えているのでしょうか。
工藤：既存のサービスをデジタル化するというより、デジタル上の新サービスを顧客企業と一緒に開発するケースが増えています。企業そのものやサービス全体を「Webサービスに体現」することになります。
その際、「開発するアプリの機能が決まっていて、仕様書をもらってそのとおりに開発する」のではなく、われわれ開発側が「前工程」に入る必要があります。具体的には、顧客企業の元々持っている契約者情報・取引履歴等が入っている基幹システムや取引システムの担当とも連携し、ビジネス部門ニーズも同時に満たす必要があります。
アプリとしてのデザイン性やユーザビリティが優れていることも重要ですが、いわばお客様の“商売”をアプリにまるごと持ってくるわけなので、最初にどのようなアプリを作っていくかを考えるのが肝心です。
――そうすると顧客企業の多岐にわたる部門とのコミュニケーションが大事になりそうですが、企業によっては縦割りでなかなか進まない……ということはないのでしょうか。実際にプロジェクトマネージャーとして日々顧客に向き合っている海保さん、いかがでしょうか。
海保 研氏（以下、海保）：プロジェクト開始の際は、お客様のチームビルディングから携わって、IT・情シス部門、ビジネス部門、経営企画部門など、プロジェクトに関わるすべての部門の方を集め、まず壁を取っ払うところから進めるようにしています。そして、「受発注の関係ではなく一緒になって考えていく」というスタンスのもと、サービスデザインやコンセプト設定から丁寧に行うことでお客様の当事者意識を引き出すように努めます。
例えば、ある銀行様で、当社がその「前段階」の支援をしました。先方の残高照会アプリのリニューアルに際し、現状課題の抽出をはじめ、ユーザーのリアルな声やニーズ分析、顧客企業内の意見把握や合意形成を丁寧に行い、コンセプト策定を支援しました。ターゲットユーザーである若年層の、銀行やお金に関するリアルなイメージや考え方をすべてのプロジェクト関係者間で共有することで、より具体的なユーザー像をイメージしながら、リニューアルの目的や指針、今後の取り組みを明示できました。
工藤：アプリ開発でまずチームビルディング？と思われるかもしれませんが、これは本当に大切。ソフトウェア業界では、「コンウェイの法則」が唱えられています。これはコンピュータ科学者、メルヴィン・コンウェイによる、「ソフトウェア自体の構造とソフトウェアを作り上げる組織の構造が似てしまう」というもの。想像していただきたいのは、ソフトウェアを作るときのシチュエーション。もし3つのチームで分かれて作った場合、自然とソフトウェアの構造も3つに分かれて開発されますよね。
ひるがえって、アプリ（＝ソフトウェア）を開発する際に、もし組織が部門ごとで分断されているとアプリも機能ごとに連携が取れていない、というようなことが起きてしまいます。ゆえに、私たちは社内外問わず、プロジェクトチーム内でスムーズに連携が取れる組織づくりを重要視しているのです。
海保：またチームビルディングに基づき、顧客のメンバーを含めたチャットサービスによる情報交換、週1回の長時間の定例を排して毎日の朝会、タスクごとに分けた課題管理、情報の集中管理など、プロジェクトチームにおいてなるべくコミュニケーションを円滑にし、顧客と一緒に無駄なく仕事を進めていくように努めています。
アジャイルでないと世間についていけない怖さ
――しっかりとチームビルディングから入っていくことで、「受発注」の関係から「パートナー」として信頼を獲得していくということですね。では、アプリを開発するうえで企業側はどういったことを意識する必要があるでしょうか。
工藤：まずは「be Agile.（アジャイルであれ)」ということです。一般ユーザー向けアプリは、年代も属性もバラバラの幅広いペルソナに向けて作られます。また、スマホのデバイス仕様は毎年変化しますし、ユーザーのニーズも時々刻々と変化します。いわゆるVUCA※状態ですね。そのため、じっくり仕様書を作って、長い開発期間の後にようやく「完成品」を納品するのでは、とても変化についていけません。スモールで始めて素早く作り、逐次フィードバックをもらって改良し、日々の変化に対応できるようにする。私たちもこの「アジャイル開発」を基本としています。
海保：「完成品」をお客様が実際に触った際に、仕様どおりにもかかわらずユーザー体験に納得できず仕様変更となり、余計に時間とコストがかかってしまう場合もあります。ですので、ゆめみのエンジニアは自らお客様と進んで会話してヒアリングし、すぐに見本となる画面のプロトタイプを作って「こんなのどうでしょうか」と提案することも多く、お客様には「あれ、もう作ってたの」と驚かれることもあります（笑）
工藤：お客様の社内で、「隣の部署、仕様書が多く上がるわけではないのになぜかアプリ画面がどんどん上がって進捗の具合がすごいらしい」と口コミが広がって、別部門の方からお声がけをいただく、というようなこともありましたね（笑）。まずはわかりやすいアプリ画面イメージありき、で進めるのでお客様もフィードバックをしやすく、制作側としても軌道修正をしやすくなる。そこが、アジャイルのよさですよね。
――最後に、お二人のビジョンをお聞かせください。
海保：受注者・発注者という関係を新しくしていきたいと考えています。従来のシステム開発の方法論をアプリに当てはめて進めると、クライアント側は成果物が最後まで上がってこないし、それが満足いくものかどうかはわからない。これを埋めるため仕様変更が連続で発生しますが、弊社のようなよりエンドユーザーに近い部分を担当している場合、仕様変更の影響を受けやすく、現場も疲弊してしまいます。これは両者ともにマイナスです。そうではなくて、一緒に組織から変革を遂げることで、お互いに効率よくスピーディーに、確実にエンドユーザーの満足につながるアプリをこれからも作っていきたいです。
工藤：お客様企業とともに“先端”でありながら使いやすいアプリを作ることで、最終的にはエンドユーザーが「無意識にテクノロジーを使っていた」という状況にゆめみが貢献できれば、とてもうれしいです。今はアプリをダウンロードして使うことにまだ抵抗感がある方もいらっしゃるでしょうが、少しでも身近に感じてもらえるようになりたいと思います。エンドユーザーに寄り添ったものづくりができるよう、これからも「生活者視点」を大事にしつつ、お客様と伴走できるよきパートナーでありたいです。
