近年、少しずつ広がりを見せているヘッドレスCMS。これまで代表的なCMSとしてWordPressなどが用いられてきましたが、それらとヘッドレスCMSはどのように違うのでしょうか。また、ヘッドレスCMSにはどのようなメリットがあるのでしょうか。
この記事では、ヘッドレスCMSの仕組みや従来のCMSとの違い、メリット・デメリットなどについて紹介します

ヘッドレスCMSとは何か

以下ではまず、ヘッドレスCMSの概要や仕組みについて紹介します。

そもそもCMSとは

CMS（Content Management System）はWebサイトのコンテンツを管理・公開するためのシステムです。CMSはコーポレートサイトやオウンドメディア、ブログ、自社の商品紹介ページなど幅広い目的で利用されています。
代表的な CMS として、WordPressが知られています。全Webサイト中 43.1% が WordPress で構築されているという調査結果※もあり、WordPressをはじめとした CMS はWebサイトを構築する一般的な方法として定着しています。

※参考：W3Techs『Usage statistics of content management systems』（新しいタブで開きます）

ヘッドレスCMSの概要

ヘッドレスCMS とは、フロントエンド、つまりユーザー側に見えるページを表示する機能を持たない CMS のことです。ヘッドレスCMS における「ヘッドレス」とは「ユーザー側に表示するヘッド部分がない」という意味で用いられています。
ヘッドレスCMS はフロントエンドの機能を持たない代わりに、バックエンドのコンテンツ管理機能に特化しています。また、ヘッドレスCMS の外部で構築したフロントエンドへコンテンツを提供する機能を備えています。

ヘッドレスCMS の仕組み

ヘッドレスCMS による Webページの配信では、事前に Webページを生成して CDN に配置されます。CDN(Contents Delivery Network)とは、世界中に分散配置された数多くのキャッシュサーバーなどで構成されるデータ配信のためのネットワークです。ユーザーがWebページにアクセスすると、CDN にある Webページがユーザーに送られ、ページを閲覧できる仕組みとなっています。CDN は世界中に分散配置されているため、ユーザーがアクセスすると、CDN に置かれているページを迅速にユーザーに届けられる利点を持ちます。
ヘッドレスCMS を用いて Webサイトを構築する場合、ユーザー側に見えるページはヘッドレスCMS の外部に構築する必要があります。この時、ヘッドレスCMS と外部の Webページ間は、API という仕組みを用いて連携されます。
API（Application Programming Interface）とは、個別に構築されたアプリケーション間を連携するために用意される機能のことです。API を利用することで、各システムは連携先が内部でどのような処理をしているか意識する必要がなくなり、定義されたAPIのみ意識すれば容易に連携できます。
このように、コンテンツを管理するヘッドレスCMS 側と、実際にコンテンツを表示するWebページ側を分離し、個別に開発・管理を行うことができるのがヘッドレスCMS の大きな特徴といえるでしょう。

従来のCMSとの比較

上述のとおり、従来のCMSにはフロントエンドのWebページ表示機能とバックエンドのコンテンツ管理機能の双方が用意されています。一見、ヘッドレスCMSは機能が不十分な仕組みにも見えますが、従来のCMSとはどのような違いがあるのでしょうか。

作業範囲の分離

従来の CMS においては、単一の仕組みで Webサイトを構築するための全機能が用意できるというメリットもありますが、フロントエンドとバックエンドの作業がかち合いやすいというデメリットも生じます。
多くの場合、フロントエンドはデザイナーやエンジニアが対応し、バックエンドはマーケターなどのコンテンツ管理者が対応します。対応するメンバーが異なることもあり、お互いの責任範囲が不明確となりやすいという問題があります。ヘッドレスCMS であれば、双方の作業を分離して、効率的に進めることができます。

多様な媒体への対応

従来の CMS では多様な媒体に対応しづらい点が課題となります。一般的な CMS では、PC やスマートフォン向けのページ表示には対応しますが、たとえばデジタルサイネージへの対応や、自社ECサイト内への部分的なコンテンツ表示は難しいといえます。これらに対応するためには、各媒体に個別にコンテンツを登録し、表示させる必要があります。
ヘッドレスCMSであれば、コンテンツ管理はヘッドレスCMSで一元化しつつ、CDN および API連携によって多様な媒体へコンテンツを連携させることができます。各媒体でコンテンツ表示を切り替えることで、媒体に合わせた最適な表示方法でコンテンツを見せることができます。

表示速度

従来の CMS ではリクエストごとにサーバーへアクセスしているため、レスポンスが遅くなるという課題があります。ヘッドレスCMS では、あらかじめ CDN に配置されているページを返すだけなのでレスポンスが早く、高速な表示が期待できます。
とくに ECサイトにおいては、表示速度は CV率や解約率などにも影響するため、速度改善は必須要件です。Google が行ったある調査では、表示速度が 1～3秒であった場合は 32% であった離脱率が、1～5秒となった場合は 90% にまで上昇するという結果も明らかとなっています。

※参考：Find out how you stack up to new industry benchmarks for mobile page speed（新しいタブで開きます）

セキュリティ

従来の CMS はページ表示部とコンテンツ管理部が 1つになっているため、外部からの攻撃を受けると Webサイト全体に影響が出ます。一方でヘッドレスCMS は、ページ表示部とコンテンツ管理部が分かれているので、仮に攻撃を受けても影響範囲を少なくできるという特徴があります。

ヘッドレスCMSのメリット・デメリット

これまで紹介してきたヘッドレスCMS の特徴を踏まえて、ヘッドレスCMS のメリット・デメリットを整理します。

メリット

フロントエンドの開発しやすさ

フロントエンドとバックエンドが明確に分離されるため、フロントエンドの開発や修正がしやすい点にメリットがあります。
従来の CMS では、フロントエンドを改修する際にはバックエンドの影響を考慮しながら進める必要がありました。一方で、ヘッドレスCMS であれば、両者は API で連携されお互いの内部状況を考慮する必要はなく、影響範囲が限定されます。
両者の責任範囲は明確に分離されるため、役割分担がしやすいという点もメリットです。ヘッドレスCMS側のバージョンアップがあったとしても、フロントエンドに影響を及ぼすことはありません。また、フロントエンドで改修などのアップデートを行ったとしても、バックエンドのヘッドレスCMS には影響は生じません。

多様な媒体へのコンテンツ表示

ヘッドレスCMS では、フロントエンドを自由に開発できるため、柔軟な対応が可能となります。上述の通り、PC やスマートフォン向けに作成したコンテンツを、デジタルサイネージなどに転用することもできます。
また、自社のコーポレートサイトやECサイトなどへ、ヘッドレスCMS からコンテンツを提供することも可能です。この時、自社のコーポレートサイトが別の仕組みで構築されていたとしても、その一部分のみにヘッドレスCMS から連携されたコンテンツを表示するようなことも実現できます。
このように、部分的な CMS化も実現できるという点もヘッドレスCMS のメリットといえるでしょう。

デメリット

フロントエンドを個別開発する必要性

フロントエンドが分離できるということは、メリットでもありデメリットにもなりえます。
従来の CMS であれば、フロントエンドもバックエンドも一体となって提供されるため、個別にフロントエンドを開発する必要はありません。一方で、ヘッドレスCMS を利用する場合は、必ず個別にフロントエンドを用意する必要があります。
API連携などの個別開発を行うためには、エンジニアのリソースも必要です。

技術的な難しさ

従来の CMS と比較して、ヘッドレスCMSの導入・運用は技術的な難易度が高いといえます。従来の CMS であればコンテンツの管理からページの表示まで、比較的容易に実現することができます。一方で、ヘッドレスCMS を利用する場合は、API設計や API を利用したフロントエンドの開発などの知見が必要です。
また運用面においても、一般的にヘッドレスCMS側にはプレビュー機能が用意されないため、コンテンツの内容を確認しにくいという面もあります。

代表的なヘッドレスCMS

以下では、代表的なヘッドレスCMSパッケージについて紹介します。

Contentful

Contentful はドイツの Contentful社が提供するヘッドレスCMS です。2013年という早い段階からヘッドレスCMS の提供を続けており、ヘッドレスCMS の分野では最も歴史のある企業といえます。30,000以上の Webサイトに導入されている CMS であり、導入実績も豊富です。資生堂など日本企業の導入実績もあります。

※参考：Contentful（新しいタブで開きます）

microCMS

microCMS は日本企業である株式会社microCMS が提供するヘッドレスCMS であり、5,000社以上の導入実績があります。日本企業が開発していることもあり、日本語の情報が豊富でサポートも受けやすいのが特徴です。また管理画面なども馴染みやすいものとなっています。

※参考：microCMS（新しいタブで開きます）

Strapi

Strapi はオープンソースとして開発されているヘッドレスCMS です。動作環境を個別に用意すれば、無償で利用できます。また、有償で SaaS として利用することも可能です。その他、企業向けの機能が利用できる有償プランも用意されています。
日本語のドキュメントが少ないといった面もありますが、比較的低いハードルでヘッドレスCMS を利用できる選択肢といえるでしょう。
※参考：Strapi（新しいタブで開きます）

ヘッドレスCMS でより良いサイト運営を

この記事では、ヘッドレスCMS の概要に加え、従来の CMS との違いやメリット・デメリットなどをご紹介しました。さまざまなメリットがあるヘッドレスCMS ですが、フロントエンドの開発が必要となる分、従来のCMS より導入難易度は高いといえます。ヘッドレスCMS は比較的新しい技術ですが、スパイスファクトリーでは開発実績もございます。ヘッドレスCMS の導入をご検討されている方、もしくはヘッドレスCMS について詳細に知りたい方は、ぜひ（新しいタブで開きます）下さい。

弊社のホームページ制作サービスに関しましては以下URL からご確認いただけます。

https://spice-factory.co.jp/service/web-corporate/

 

（新しいタブで開きます）
海外にシステム開発を委託するオフショア開発に注目が集まっています。かつてオフショア開発はコスト削減を主目的に行われましたが、最近は事情が少し変わっています。
この記事ではオフショア開発の基本的なメリットや課題、日本における最新の市場動向を解説します。
当社、スパイスファクトリーでもオフショア開発を提供しています。オフショア開発に関するお悩みがある方はぜひ（新しいタブで開きます）ください。

オフショア開発とは

オフショア開発とは、システムの開発業務における一部もしくは全部の工程を海外の業者に対して委託することを意味します。
正式名称はオフショアリング開発（Offshoring Development）であり、Offshoringは「海外移転」を意味する英単語です。
かつて、オフショア開発は人件費の安い国に発注できる「価格面」と国外に人材を拡張できる「リソース確保面」がメリットと認識されてきました。
今もそのメリットが失われているわけではありませんが、近年においては内外価格差が減少していることもあり、少し違った視点を持つ必要があります。以下で詳しく紹介していきます。

オフショア開発のメリット・デメリット

近年の市場・経済環境を踏まえると、オフショア開発のメリット・デメリットはどのような点にあるのでしょうか。

オフショア開発のメリット

コスト

オフショア開発について聞いたことのある方は、コストメリットのイメージが強いのではないでしょうか。
実際に、Resorz社が公表している『オフショア開発白書（2022年版）』※によれば、オフショア開発を採用することで平均28.4％のコストダウンにつながるという結果が明らかとなっています。
しかしながら、近年ではオフショア開発の拠点として検討されることの多い中国や東南アジアなど他国の経済発展も進んでおり、人件費も上昇しています。
また、高い技術力を持ったオフショア人材を大手 IT企業が高給で囲い込むなど、人材獲得難易度も向上しています。このような背景から、オフショア開発によるコストメリットは縮小傾向にあるといえます。

※ 出典：『オフショア開発白書（2022年版）』（オフショア開発. com）（新しいタブで開きます）

技術力

近年、インドや中国、東南アジアなどの技術者のレベルは大きく上がっています。
たとえば、Google社の現CEO ピチャイ氏はインド出身です。場合によっては日本のエンジニア以上の技術力を活用できると考えてよい状況です。
オフショア開発のコストメリットが縮小する一方で、このような技術力のメリットが意識されつつあります。

リソースの確保

日本は IT人材不足の状況が続いています。独立行政法人情報処理推進機構の発行した「IT人材白書2020(※1)」によれば、89%の企業がIT人材の量について「大幅に不足している」と「やや不足している」と回答しています。
また、日本国内エンジニアの採用にかかる年間コストは574万円であり、他業種も含めた平均484万円(※2)を大きく上回っています。労働人口も減っていく日本国内で IT人材のリソースを確保する難易度は上がっているといえるでしょう。
不足するリソースを補う観点で、オフショア開発は大きなメリットをもたらすと考えられます。

※1 参考：独立行政法人情報処理推進機構「IT人材白書2020」（新しいタブで開きます）

※2 参考：株式会社マイナビ「中途採用状況調査2022年版」（新しいタブで開きます）

スピードの担保

リソース不足は開発スケジュールに影響します。もちろん人材が多ければ開発が早く進むわけではありませんが、そもそもリソースが不足している状況では開発できる規模にも制約がかかります。
現代は Volatility（変動性）、Uncertainty（不確実性）、Complexity（複雑性）、Ambiguity（曖昧性）の4つの影響が大きいとされる「VUCA」の時代といわれています。
新型コロナウイルスの蔓延や大きな災害、AI をはじめとする急速な技術の進歩など、これまでの常識では予想できないような出来事に対して素早く対応し、ビジネスのあり方を適切に変革させる必要があります。
変化に対応する際に、素早く対応できるリソースが確保できることは大きなメリットとなるでしょう。

グローバル展開を優位に

海外向けサービス開発においては、文化的親和性などの観点からオフショア開発のメリットを発揮できる場合があります。
たとえばベトナム市場をターゲットとしたサービスをベトナム人が開発するのであれば、日本人では気づかない文化的な差異などに柔軟に対応できることは容易に想像できるでしょう。
また、ベトナムに次いでオフショア拠点として人気のフィリピンは、アジアで数少ない英語公用語国です。
欧米圏からの情報やカルチャーの影響が色濃いため、日本より欧米圏文化に精通している点に優位性があります。フィリピンでのオフショア開発は欧米圏をターゲットとするようなプロダクトの開発にメリットを発揮するでしょう。
将来的にアジア・欧米市場などのグローバル展開を想定したサービスにとって、オフショア開発は相性が良いと考えられます。

オフショア開発のデメリット・課題

一方で、オフショア開発のデメリットや課題はどのような点にあるのでしょうか。
先に紹介したオフショア開発白書では、オフショア開発企業の課題として「品質管理」と「コミュニケーション力」が挙げられています。
自社で直接オフショア開発拠点を管理しない場合であっても、システム開発の委託先が直面する課題についてどんな対応をしているか押さえておくことは重要です。

品質管理が難しい

オフショア開発では言語、文化、地理的な違いから品質管理・プロジェクト管理にコストがかかりやすいといえます。
日本語・英語・現地語など、使用する言語にもよりますが、細かなニュアンスの違いで想定していた仕様との齟齬が発生しやすくなります。
また、日本では曖昧な仕様や業務範囲であっても比較的柔軟に対応できますが、海外は「決められていないことはやらない」というスタンスが一般的です。
加えて、そもそも物理的な距離があることから対面でのやり取りが難しく、コミュニケーションが取りにくいという点も挙げられます。
時差によって突発的なトラブル発生時の対応ができなかったり、昼夜逆転によりタスクマネジメントが難しかったりといった点にも注意しなければなりません。

コミュニケーション課題が発生しやすい

品質管理についてでも触れたとおり、コミュニケーションの課題はオフショア開発において留意しなければならない点です。
先述した言語・文化・地理などの違いからコミュニケーションにすれ違いが起こりやすく、注意しなければなりません。
日本以上に仕事に対してはドライな価値観の国は多く、無理を言って残業を依頼するとすぐに辞められてしまう、といったことも多発します。
オフショア開発のメリットを知ってどんな会社に依頼すべきか気になった方は以下の記事もどうぞ！
参考記事：オフショア開発会社の選び方とは？確認すべきポイントを解説（新しいタブで開きます）

オフショア開発のよくある失敗については以下の記事で詳しく解説しています！あわせてご参照ください！
オフショア開発は失敗しやすい？よくある失敗パターンの原因と対策を解説（新しいタブで開きます）

オフショア開発の市場動向

オフショア開発の主要な拠点国

上述した『オフショア開発白書（2022年版）』によれば、オフショア開発委託検討先割合の上位3か国はベトナム（48%）、フィリピン（19%）、インド（12%）となっています。
ここでは、これら各国の国民性や技術力など各国の特徴や動向を解説していきます。

ベトナム

ベトナムは近年注目されているオフショア開発拠点です。
国家的に IT人材の育成に力を入れおり、高度なスキルを持つ人材が豊富に存在します。
IT コミュニケーター（Information Technology Communicator）やブリッジSE（新しいタブで開きます） の職種に人気があり、比較的コミュニケーションがとりやすいため、多くの企業がベトナムをオフショア開発先に採用しています。

フィリピン

フィリピンは近年シェアを拡大しつつあるオフショア開発拠点です。
公用語が英語であることからコミュニケーションがとりやすいというメリットがあります。
また、価格についても成長が著しい東南アジア各国で人件費が高騰している中、比較的落ち着きを見せています。
日本とフィリピンの時差は1時間であり、時差の影響を受けづらいこともメリットでしょう。加えて、物理的な距離としても飛行機で4時間ほどで現地に行けるという点も魅力です。

フィリピンでのオフショア開発については以下の記事で詳細を解説していますので合わせてご参照ください。
参考記事：フィリピンのオフショア開発の特徴を紹介｜メリット・デメリットを解説します（新しいタブで開きます）

インド

インドも同様にシェアを拡大しているオフショア開発拠点です。
フィリピンと同様英語力が高い点がメリットです。
高度な IT人材は多く存在するものの、ベトナムやフィリピンと比較すると高単価です。
欧米の市場へ向けたビジネスをしている企業が多く、欧米からの需要が拡大しているため価格も高騰している状況にあります。

オフショア開発が利用される案件

あくまで傾向ではありますが、同じオフショア開発であっても国によって得意とする案件にも違いが見られます。

ベトナムの案件

以前は下流工程の下請けという役割が多かったベトナムですが、オフショア開発の増加によりノウハウ獲得が進み、より AI やブロックチェーン、基幹システムの開発などより高度な案件も受注するようになっています。

フィリピンの案件

比較的オフショア開発の歴史が浅いことから、対応できる案件の幅が限られがちです。
大型案件の委託は難しい場合も多く、コーディングやアプリ開発、BPO業務といった案件に向いています。
上流過程よりは開発やテストをメインとした委託が得意といえるでしょう。

インドの案件

技術力の高さから、ERP 導入など基幹システムの構築にも対応しやすいといえます。
比較的コストが高いことから、技術力が求められる案件において採用されやすい国といえます。

オフショア開発における一般的な予算

以下では、『オフショア開発白書（2022年版）』を参考に各国の価格相場を紹介します。
なお、以下で紹介する単価はあくまで平均値であり、案件規模・内容によってコストは変わることにご留意ください。

ベトナムの価格相場

ベトナムの価格相場は以下のとおりです。
前年に比べて単価が減少に転じましたが、これはホーチミンやハノイなどの主要都市に加えて、近年はダナンやフエといった新興都市が台頭しており、割安な単価で利用できるようになった点が影響しています。

• プログラマー31.73万円（昨年度比96.7％）
• シニアエンジニア39.88万円（昨年度比92.8％）
• ブリッジSE 51.34万円（昨年比105.6%）
• PM（プロジェクトマネージャー）57.94万円（昨年比92.5％）

フィリピンの価格相場

注目度が上がっているフィリピンでは、全体的に単価が向上する傾向がみられます。

• プログラマー 36.25万円（昨年度比106.9％）
• シニアエンジニア 49.63万円（昨年度比103.7％）
• ブリッジSE 71.07万円（106.6%）
• PM 65.83万円（89%）

インドの価格相場

欧米からの需要拡大を受け、インドでも単価の上昇傾向がみられます。

• プログラマー 34.72万円（昨年度比104.1％）
• シニアエンジニア 51.56万円（昨年度比107.8％）
• ブリッジSE 67.97万円（123.8%）
• PM 83.90万円（108.9%）

※参考記事：ブリッジSEとは？オフショア開発での役割と必要性、注意点も解説（新しいタブで開きます）

オフショア開発のサービス形態

以下では、一般的にオフショア開発に開発を依頼する場合のサービス形態について紹介します。

請負型開発

請負契約により、定義した要件に基づき、期日までに成果物を完成・納品する方式です。
あらかじめ契約で決められたこと以上のことは基本的に受け付けないため、要件の追加や仕様変更を行う場合は、変更契約により予算・スケジュールの変更が必要となります。

ラボ型開発

準委任契約により社外に開発チームを作り、一定期間人材リソースを確保して開発業務を行う方法です。
一般的には単価に応じて人数と期間により費用が決定します。
契約した時間内であればプロジェクトの進捗状況に応じて柔軟に開発内容を変更することも可能ですが、準委任契約の特性上、委託先にシステムの完成責任がないというリスクを意識しなければなりません。
以下の記事で詳細な解説をしておりますのでよろしければご参照ください。
ラボ型オフショア開発とは？メリットや請負型との違いも説明（新しいタブで開きます）

タイムチャージ型というサービスも

当社、スパイスファクトリーでは、タイムチャージ型というサービスを提供しています。
ラボ型同様に準委任契約で業務を受託しますが、「人数 × 期間」ではなく時間単位での契約が可能な点が特徴です。
契約された時間内でエンジニアやブリッジSE の他、プロジェクトの進捗に応じてデザイナーやマーケターなどを柔軟にアサインします。
タイムチャージ型はラボ型をより柔軟にしたサービスといえます。
詳細な特徴の解説はこちら（新しいタブで開きます）からご覧ください。

スパイスファクトリーのタイムチャージ型オフショア開発について、ご興味があればください。

日本でオフショア開発は重要な選択肢になりつつある

この記事では、オフショア開発の市場動向やメリット、主な委託先の特徴などについて紹介しました。
日本において、IT人材不足は深刻な状況にあります。中堅・大企業においてもリソースの逼迫や単価高騰が進行しています。
オフショア開発は従来のコスト削減目的だけでなく、リソース確保の選択肢としても重要となってきており、英語圏での開発によりグローバル展開を目指す企業にとってもメリットがあるなど、ニーズが多様化していることもお伝えしてきました。
スパイスファクトリーではフィリピンにオフショア開発拠点を設け、国外のリソースも活用したアジャイル開発を展開しています。
システム・Webサービス開発やオフショア開発に関する相談があれば、ぜひ（新しいタブで開きます）ください。
弊社の関連サービスに関しましては以下URL からご確認いただけます。
（新しいタブで開きます）

 

スパイスファクトリーの（新しいタブで開きます）

これまで日本企業の多くは ITシステムをコストセンターととらえ、ビジネスのノンコアとしてシステム構築を外注化してきました。しかし、近年では DX（デジタル・トランスフォーメーション）に象徴されるように、IT がビジネスのコアとして認識されつつある傾向にあります。このような流れの中で、自社の競争力の源泉としてシステム開発の内製化に取り組む企業も少しずつ現れています。
一方で、内製化は簡単ではなく、失敗事例が多々あるのも事実です。その難しさを念頭に、どのようにシステムの内製化を進めていくべきなのでしょうか。この記事では、内製化の難しさや、取り組みのロードマップ例をご紹介します。

システムの内製化とは

システムを自社の人員で開発することをシステムの内製化といいますが、近年、内製化に注目が集まっています。この背景はどこにあるのでしょうか。また、企業における内製化の取組状況はどうでしょうか。統計情報なども踏まえてご紹介します。

内製化が注目される背景

内製化が注目されている背景としては、いくつかの理由を挙げることができます。
まず、DX の推進という観点です。経済産業省「DXレポート2」（新しいタブで開きます）では、DX の進展においては内製化の取り組みが必要であるとしています。上述したとおり、IT がビジネスのコアとして認識されるようになると、ITシステムやシステムを生み出すためのスキルを持った人的リソース、企業として ITシステムの開発経験の蓄積などが企業の競争力の源泉となります。DX を進めていく上では、このような IT に関する知的財産を確保していかなければなりません。
これら知的財産の内部化を進めるためにも外部委託から内製化へ移行する必要があります。
参考：システム開発リソース不足の原因と解決法とは？できること総まとめ（新しいタブで開きます）

また、ビジネス速度の向上も内製化が必要とされる理由の一つといえます。特にウォーターフォール型でのシステム開発のデメリットとして、臨機応変な対応が難しい点が挙げられますが、このようなデメリットを解消するために、内製化・アジャイル開発を取り入れる企業が現れています。
参考：アジャイル開発とは？ – システム開発を発注する時に知っておきたい開発手法の話（新しいタブで開きます）

内製化のひとつのメリットはスピード感です。
もちろん、自社に十分なリソースがあることが前提となりますが、外注先との調整や発注手続きなどが不要となり、システム開発を高速化することができます。

企業におけるシステム内製化への取り組み状況

日本企業における内製化の取り組み状況はどうでしょうか。
多くのユーザー企業が所属する日本情報システム・ユーザー協会の年次調査「企業IT動向調査報告書」の 2022年度調査（新しいタブで開きます）では、主に DX を推進している企業において内製化への取り組みが進んでいる状況が明らかとなっています。
具体的には「貴社は DX を推進できていると思うか」との質問に対して「非常にそう思う」と回答した企業の約 48% が今後内製化率を増やしていくと回答しています。
DX に前向きである、つまりシステムを競争力として活用していこうという意識の高い企業において、内製化を進める傾向がみられる状況にあります。

日本企業の DX の現状と課題については以下の記事で解説しておりますのでぜひ参考にご覧ください。
参考：DXが失敗する理由は？リスクを下げ成功確率を上げる「FastDX」という選択肢

システムの内製化は失敗も多く簡単な道のりではない

内製化への道のりは決して簡単なものではありません。従来 ITシステムの開発を外注していた企業においては、自社にスキルを持った人材やノウハウが存在しないため、特に難しい取り組みとなります。上述した経済産業省「DXレポート2」でも、「内製化する過程で必要となるアジャイル開発の考え方や、クラウドネイティブな開発技術等について、ユーザー企業の内部人材ではすぐに対応できないことが多い」と指摘されています。
実際に、内製化の取り組みに着手したものの失敗してしまったという企業の事例も多く聞きます。これはなぜでしょうか。
様々な理由がありますが、ここでは主なものをとりあげて紹介します。

ひとつは、十分なスキルのあるエンジニアを確保することが難しいという点です。
IT人材の不足が叫ばれる中、エンジニアを確保するためには十分な待遇やエンジニアが働きやすい環境整備・社内文化などが必要となります。
その一方で、内製化の旗手となる IT部門だけで社内人事制度や社内ルールの整備は難しいのが実情です。また、たとえエンジニアを確保したとしても、十分に活用できない、定着しないといった状況になるケースも考えられます。

加えて、リスク面の問題も挙げられます。
システム開発には QCD の観点でリスクが存在しますが、内製化をするとこれまで外出ししていたリスクも内部化します。たとえば、請負契約においてはシステムの品質についてはベンダー側に責任があり、それらが不十分であれば瑕疵担保責任もしくは損害賠償請求という形で保証がされます。つまり、品質が不十分であればベンダー側の費用・人員で対応することになります。
しかしながら内製化の場合、システムの品質に問題があっても自社で解決せざるを得ず、その対応にかかる費用・人員コストはすべて自社の持ち出しとなります。

このように、内製化を成功させるためには様々な課題があります。
一足飛びに実現できるものでは決してなく、会社として戦略的な取り組みが必要といえるでしょう。

システム内製化ロードマップの例

内製化の取り組みを進めていくためには、長期的な視点に立って、ロードマップを作成し段階的に進めていくことが重要です。
一例をご紹介します。

「なぜ内製化をするか」の徹底的な議論と経営層を含めた合意

システムの内製化を進めることはすべての企業にとって必須というわけではありません。
内製化を進めるということは、IT を自社のコア・コンピタンス（＝他社に真似できない競争力を生み出す能力）としてみなすということになります。自社にとって IT が競争力となるかどうかは、ビジネス環境や自社が持つ既存の経営資源などにより異なります。
たとえば、アパレル業界においてはもはや EC化は避けて通れず、IT をコア・コンピタンスとする経営戦略は現実的なものかもしれません。
教育業界においてはどうでしょうか。IT の力で教育を普及させることを目的に、オンライン教育サービスやアプリ開発などを進めるため内製化を進める戦略も検討できます。
一方で、自社のリソースを教育コンテンツの作成に集中し、アプリやシステムについては既存のプラットフォームを活用するといった選択肢も考えられます。
このように、内製化は企業の経営戦略と密接に紐づくものであり、IT 組織内でのみ検討するというよりも、経営層含めて全社的な決断が必要となるものです。
なぜシステムの内製化をするのか、本当に必要なのかを徹底的に精査・議論し、経営層を含めて全社方針として合意する必要があります。
この論点は企業の DX推進をどう行うのかにも密接に関係します。ぜひ以下の記事も参考にしてください。
参考：DX戦略の立て方とは？立案方法や成功のポイントを事例も交えて徹底的に解説！ リーダーシップにおける注意点 より（新しいタブで開きます）

最低限のリソース確保

内製化をするためには、当然ながらエンジニアリソースが必要となります。しかし、これまでシステムを外注してきた企業においては、社内にエンジニアが存在しないケースも多いでしょう。
まず、内製化を進めるための最低限のリソース確保が必要です。とはいえ、いきなりエンジニアを採用したとしても、自社にシステム開発ノウハウがなければ十分に活躍してもらえない状況となりかねません。
そこで、まずはスキル・ノウハウの社内蓄積が必要です。
そのためのひとつの方法は、アジャイル型開発手法や DevOps（新しいタブで開きます） といった取り組みに精通しているベンダーに併走してもらい、開発ノウハウやエンジニアリング手法を学ぶことです。
これは上述した「DXレポート2」においても移行期のアプローチとして示されているものであり、有効な選択肢となりえます。

また、他社との人的交流によりエンジニアを受け入れるという案も考えられます。
スキルを持った方に自社メンバーとともに働いてもらうことで、より深い形でスキルの共有や文化面の理解などを進めることができます。このような対応に協力してくれる取引先があれば、検討してみるとよいでしょう。
当社、スパイスファクトリーもアジャイル開発を得意とする企業ですのでもしご興味があれば（新しいタブで開きます）ください。

スパイスファクトリーの（新しいタブで開きます）

内製化ターゲットの見定め

システム内製化に着手した当初は、当然ながら自社のエンジニアリソースも十分ではなく、また社内のノウハウも蓄積されていない状況にあります。このような状況においては、内製化の対象とする領域を見定め、内製化に向くシステムから着手することが一つの選択肢となります。
たとえば、ひとつの方法は既存システムの外部に、システムの機能を拡張するような機能を構築する方法です。
システム本体を直接更新しない、もしくは API などを通して最低限の更新処理を行うような機能は、比較的開発ハードルが低くなります。
また、近年では Google社の提供する Appsheet（新しいタブで開きます） に代表されるような、プログラミングを行うことなく開発ができるノーコードやローコードの技術も発達しています。
必要に応じて活用することで、プログラミングに関する知見が少ない方でも内製化に着手できる可能性があります。

成功パターンの確立

システム内製化ロードマップの最初の目標は、どのようなシステムなら内製化を行うことができるのか、内製化の成功パターンを示すことです。
内製化の本格的な拡大を進めるにあたって、社内の機運醸成の観点からも成功例が必要となります。一度成功例ができれば、類似する案件に手を広げやすくもなります。
成功事例ができれば、次の開発に必要な投資や人的リソースの確保についても、Go が出やすくなるでしょう。

人材確保

本格的に内製化領域を拡大していくためには、人材確保が必要です。
この段階では、可能であれば社内人事制度にもメスをいれ、エンジニアは既存の人材と別の処遇制度を設けるなど、全社的な優先度も変更して内製化を進められるとよいでしょう。
新入社員採用などにおいても、エンジニア枠を設けるなどの対応を検討します。
国内では IT人材の確保は困難な状況が続いており、当面解消される見込みはありません。
優れた IT人材を確保するためには、報酬面・環境面に加え、エンジニアが好む文化などを含めて検討が必要です。

内製化領域の拡大

人材確保を進めながら、段階的に内製化領域を拡大していきます。
内製化のメリットを生かすため、自社のビジネスにおいて中核となる事業や、成長事業、機動力が求められる事業などを対象としていきます。ここまでくれば、内製化はひとつの社内文化として定着します。
また、自社で獲得したシステム開発ノウハウを活用することで、ビジネス面における選択肢も多様化していきます。
たとえば、獲得したシステム開発ノウハウを活用して外販を進めていくことも一つの選択肢になり得るでしょう。自社向けに開発したツールをパッケージや SaaS の形で販売していくことも検討できます。
新規事業開発においても、システム開発スキルを活かしてスピード感を持った検討を行えるようになっていきます。

エンジニアに選ばれる会社になるために

システム開発の内製化を進めていく上で最も難しいポイントが、人材の確保といえます。
上述のとおりエンジニア人材の不足状況は深刻であり、各社がその確保に奔走している状況にあります。
エンジニアに選ばれる会社になるためには、どのような観点が重要となるのでしょうか。

エンジニアリングへの理解

いかにエンジニアを集めても、エンジニアが動きやすい仕事の進め方ができなければ、すぐにエンジニアは去っていきます。
内製化をすすめる上で、システム開発の進め方を理解し、洗練させていくことは重要です。一方で、従来システム開発を外注してきた企業においては、エンジニアリングの理解は簡単ではありません。
発注者視点でのベンダー管理スキルは蓄積されていたとしても、開発者視点でのプロジェクト運営ノウハウについては持っていないためです。開発者視点でのノウハウは新たに身に付けていく必要があります。
このような状況を解決するための方法として、外部人材の一次的な活用が有効です。たとえば、並走型支援を実施してくれるベンダーなどを活用することも一案です。
このようなベンダーも活用し、自社にノウハウを蓄積していきます。

社内文化の醸成

エンジニアに選ばれる会社になるためには、カルチャー面もポイントとなります。
旧来型の会社に対してエンジニアが抱くイメージは「書類や社内調整が大変そう」「上下関係が重要で自分の意見が通らないのでは」といったネガティブイメージだと想定されます。
自由で失敗を恐れない文化は、エンジニアが働きやすい環境を提供する上で重要となります。
このような文化を醸成していき、かつ対外的にそれを発信していくことで、エンジニアに選ばれる会社となることができるでしょう。

人事制度の見直しや働きやすい環境の提供

特に事務職としてゼネラリストが多い企業においては、人事や報酬体系がゼネラリスト向けとなっており、エンジニアの受け入れに不向きなものとなっているケースが多いといえます。
エンジニアを受け入れやすいように、ジョブ型人事制度の導入や年次・資格等での給与制度の見直しなどを検討します。
加えて、労働環境面においてもエンジニアが働きやすいことは重要となります。たとえば、PC や机・椅子、ディスプレイ、テレワーク環境などを整備することはその一つでしょう。

開発の内製化はノウハウを貯めながらじっくりすすめよう

この記事では、内製化の進め方やエンジニアに選ばれる会社になるために必要なことについてご紹介しました。
内製化の取り組みは困難な面も多く、企業として覚悟を持って取り組んでいかなければならないものとなります。
長期的な視点でとらえ、自社にスキルやノウハウを蓄積していくプロセスが必要です。
スパイスファクトリーでは、これまで多くのお客さまに併走型で支援を実施してまいりました。当社では「Form a scrum」としてチームで最大の成果を挙げることをコアバリューとし、アジャイル型でのシステム開発を支援いたします。内製化を見据えた取り組みについても、柔軟に対応させていただきますので、ぜひお声がけいただければ幸いです。

 

https://spice-factory.co.jp/service/agile_software_development/

（新しいタブで開きます）
DX（デジタルトランスフォーメーション）という言葉がビジネスシーンで頻繁に飛び交うようになり、実際に DX で成功した企業も出てきました。自社でも変革を図るべく DX に着手していこうとお考えの方も多いのではないでしょうか。
しかし DX戦略には正解がなく、自社や市場の状況を分析して最適な戦略を立てなくてはなりません。
今回は、これから DX に着手していこうとお考えの方に向けて、DX戦略の立て方について事例も交えて丁寧に解説していきます。
当社のサービスにご興味をお持ちいただけた方はぜひください。

DX戦略はどのように立てればよいか

DX というと AI（人工知能）やIoT、ビッグデータなどの活用がよく挙げられますが、これらは手段であって戦略ではありません。自社のあるべき姿（ビジョン）を策定して、どのように達成するかを計画するのが DX戦略です。
冒頭で述べた通り DX戦略の立て方に正解はありませんが、一定のフローは存在します。そのフローは下記のようなものです。

1. DX戦略立案の前に前提整理
2. DX戦略のビジョン（自社のあるべき姿）策定
3. DX戦略における取組領域の策定
4. DX戦略推進プロセスの策定と成果評価

内容を順番にみていきましょう。

DX戦略立案の前に前提整理

「DX戦略を立てよう」と考えても、すぐに戦略の中身について考え始めるのは得策ではありません。戦略立案に取り掛かる前に、準備として下記の項目を整理した方がいいでしょう。

• 自社の課題・強みの明確化とアセット整理
• 外部環境の変化による自社ビジネス影響評価
• 自社が DX のプロセスのどの段階にいるかチェック
• DX戦略策定のチームは企業トップを含めて構成

前提項目の内容を一つずつみていきます。

自社の課題・強みの明確化とアセット整理

まず、自社の課題・強みの明確化とアセットの整理に取り組みましょう。この段階では DX やデジタル化を意識しすぎる必要はまだありません。市場や競合と比較したときに自社ビジネスが強みにできるポイント、あるいは弱みになり得る所を整理します。
自社の課題・強みの明確化にあたっては有名な手法がいくつかあり、その一つが SWOT分析です。

• • Strength（強み）：自社や自社商品の長所、得意分野
  • Weakness（弱み）：自社や自社商品の短所、苦手分野
  • Opportunity（機会）：社会や市場の変化による自社や自社商品のプラス要素
  • Threat（脅威）：社会や市場の変化による自社や自社商品のマイナス要素

   

上記に合わせて整理を行います。
SWOT分析を実施する前には、分析対象・目標・顧客属性・競合企業の4つについて情報を集めておくとスムーズです。
SWOT分析に続いて、アセット（経営資源）を整理していきます。アセットはヒト・モノ・カネ・情報・時間・知的財産から構成されます。それぞれの項目について、自社にどのようなアセットが存在するかを整理しましょう。

外部環境の変化による自社ビジネス影響評価

続いて、「外部環境変化の分析」と「ビジネスへの影響評価」を整理していきます。
先述した SWOT分析の Opportunity（機会）と Threat（脅威）とも共通する内容です。
外部環境変化の具体例として記憶に新しいのは、コロナ禍の影響による働き方改革でしょう。
コロナ禍のように社会全体を巻き込むような大きな変化もあれば、自社の所属する業界に特化して影響が起きる場合（法改正や業界トレンド等）など環境変化と一口にいっても様々です。
外部環境変化を分析・整理する手法として、フレームワークを利用することも有効です。代表的には、PEST（Politics（政治）、Economy（経済）、Society（社会）、Technology（技術））分析や、業界内の状況を分析する5F（Force）分析、同じく業界内の自社の事業環境を分析する3C（Consumer、Competitor、Customer）分析などがあります。

自社がDXのどの段階にいるかチェック

実は、DX は一定のデジタル化が一定程度まで進んでいる企業でしか実施できません。
令和3年情報通信白書によれば DX（デジタルトランスフォーメーション）は以下のように定義されています。

「デジタル技術の活用による新たな商品・サービスの提供、新たなビジネスモデルの開発を通して、社会制度や組織文化なども変革していくような取組を指す概念である」

引用元：令和3年情報通信白書（新しいタブで開きます）

業務プロセスを単にデジタル化するにとどまらず、新たな商品やサービスがビジネスモデルや組織までも変化させることをゴールにしています。
読んでいただいてお分かりかと思いますが、難易度が高いことは明白です。
そのため、デジタル化がそこまで進んでいない企業は、DX の前に「デジタイゼーション」や「デジタライゼーション」といったプロセスを順番に実施していく必要があります。
以下に DX 実現に至るまでの各プロセスをご紹介します。

デジタイゼーション

アナログ情報をデジタルデータに変換する（例：紙で管理していた販売情報の電子化）

デジタライゼーション

業務プロセスをデジタル化する（例：システムを活用し、人が事務作業で入力していた販売情報登録を自動化）

デジタルトランスフォーメーション

デジタル化した業務プロセスを用いたビジネスモデルの変革（例：販売プラットフォームの構築）

記載した「デジタイゼーション」や「デジタライゼーション」が未実施である場合には、後述するビジョンの達成向けて必要な整備から順番に対応することを戦略に盛り込む必要があります。
逆に、自社が取り組む領域において基本的なデータのデジタル化が完了していたり、業務プロセスのデジタル化が概ねできていたりしている場合には、満を持して DX の実現に向けた戦略を描けるでしょう。

DX戦略策定のチームは企業トップを含めて構成するのがベスト

DX推進は企業全体に影響がある取り組みです。組織横断で進めなくてはならない場面も多いため、推進していくには経営層が積極的に DX推進に関与することが重要です。
できれば戦略の策定の段階から経営層を巻き込んでチームを組み、議論を進めることが望ましいでしょう。
チームメンバーだけでは知見や方針不安がある場合は、DXコンサルティングを提供している企業に支援を依頼するのも一つの手段です。

具体的な戦略を議論していく前に、この章でご紹介した整理をしておきましょう。

DX戦略のビジョン（自社のあるべき姿）策定

前提整理ができたら、いよいよ DX戦略の策定に入っていきます。まずは DX戦略のビジョンを策定する方法についてみていきましょう。

DX戦略のビジョンを考える際のポイント

すでに企業で何らかの DXビジョンが示されている場合は問題ありませんが、示されていない場合は、具体的なビジョンの案を複数策定し、経営層と合意をとる必要があります。
DX戦略のビジョンを考える際には、下記のポイントがあります。

• いままでのやり方に固執せず未来のテクノロジーや事業機会を予測する
• 自社の企業理念や存在意義（パーパス）、経営戦略に沿わせて強みを伸ばす形で検討する
• 社会の課題や顧客の課題に対して提供できる価値や解決法を考える
• デジタル技術を用いての変革を検討する

これらの内容を盛り込みながら、自社の DX戦略ビジョンを検討しましょう。

DX戦略ビジョンの事例

DX戦略ビジョンを策定する際に、他社の事例を知りたいという方もいらっしゃるのではないでしょうか。ここでは事例を２つ紹介します。

株式会社三菱ケミカルホールディングス

株式会社三菱ケミカルホールディングスは「ヒトとデジタルの協調による、持続可能な未来に向けた新しい価値創出への変革」というビジョンを掲げ、そのビジョンを支える7つの DX計画を定義し、各事業をこの DX計画と関連付けて DX に取り組んでいます。
参考：https://www.mcgc.com/ir/pdf/01031/01178.pdf（新しいタブで開きます）

旭鉄工株式会社

旭鉄工株式会社は「人には付加価値の高い仕事を」を合言葉に、機械やシステムができることは機械やシステムに任せ、人は人にしかできない創造的なことをやるべきとしています。
社長自ら頻繁に社内SNS を更新してビジョンを共有し、そのビジョンに基づくルールの一つとして「怪我以外は何をしてもいい」というルールのもと、闊達なチャレンジを生み出しています。
参考：https://www.istc.co.jp/about/dx（新しいタブで開きます）

DX戦略における取り組み領域の策定

DX戦略ビジョンが決まったら、続いて DX における取組領域を策定していきます。
自社の事業をベースにデジタル技術を掛け合わせて強みを活かせる領域を選定するのが基本ですが、どのような領域にどう取り組むべきかよくわからないという方も多いはずです。
そこで、ここではコロンビア大学の経営大学院で教鞭を執るデビッド・ロジャース氏が執筆した『The Digital Transformation Playbook』で取り組み領域の具体例の中から以下の3項目をご紹介します。

1. プラットフォームビジネス
2. データを企業の資産へ転換
3. 顧客体験のデジタル化

内容をひとつずつみていきます。

プラットフォームビジネス

プラットフォームビジネスとは、企業と顧客（BtoC）や、顧客同士（CtoC）をマッチングする場を提供するビジネスです。今日では、たとえば以下のようなプラットフォームビジネスが展開されています。

• • 小売り：Amazonマーケットプレイス、楽天市場、メルカリ
  • メディア：YouTube、Forbes.com
  • モバイルOS：iOS、Android
  • 宿泊：Airbnb、トリップアドバイザー

プラットフォームビジネスについて、内容を紐解いていきましょう。

プラットフォームのタイプは4つ

プラットフォームの主なタイプは以下の4つです。

• • • 交換場所：顧客同士が価値を交換（例：Amazonマーケットプレイス、Airbnb）
    • 取引システム：金融取引を促進（例：PayPal、Apple Pay）
    • 広告付きメディア：コンテンツ価値で読者を獲得（例：YouTube、Instagram）
    • ハードウェア/ソフトウェア：ビジネスの基礎を確立（例：iPhone、Windows OS）

プラットフォームビジネスを考えるうえでは、大部分が上記4つのいずれかに当てはまるでしょう。

既存のプラットフォームビジネスへの新規参入は難しい

プラットフォームが持つ大きな力は、主に以下の3点です。

• • • 資産が少なく済む：たとえば、Uberは配車サービスを提供しているが1台の車両も持っていないサービスです
    • 規模拡大が素早くできる：上記に関連して、低い営業経費とクラウドコンピューティングの力でサービス拡大が容易です
    • 一人勝ちできる：他社に先行して支配的地位を築ければ競合にとっての参入障壁も上がり、収益を上げやすくなります

基本的に、顧客をすでに多数集めている企業がいる既存のプラットフォームビジネスに後発で新規参入し、成功することは困難といわれています。
しかし、明確に顧客に差別化した価値が提供できる場合や、自社と顧客、競合他社などの相互作用によって新たな価値を提供できることもありますので、可能性があれば参入の検討をしても良いでしょう。

データを資産へ変換

DX戦略といわれて、「データ活用」を思い浮かべる方も多いのではないでしょうか？デジタルデータをうまく活用できれば、広告を打つタイミングの選択や、製品の製造量の決定、新サービス作成の意思決定など、イノベーションや戦略的優位性の源泉になります。
ここでは DX において、どのようにデータを資産へ変換していくかを事例と共に紹介します。

潜在項目（インサイト）の可視化

顧客心理や顧客行動は簡単には可視化できませんが、データの取得方法によっては、製品の使われ方や不正の有無まで明確化できます。
以下のような例があります。

• • • コロンビア大学の研究：特定ブランドに興味を持つ顧客層と競合ブランドの洗い出しを試みています
    • Gaylord Hotels： SNS に投稿された口コミから自社にとっての重要な顧客体験を5つに絞り込んでいます

ターゲットの明確化

データを活用して従来では不可能だった顧客セグメントの抽出が可能となり、状況に合わせてリアルタイムにターゲットを変更していくこともできます。
以下のような例があります。

• • • Custora：顧客のサイト訪問時に、将来自社にもたらす利益について予測します
    • InterContinental Hotels Group：詳細な顧客セグメンテーションで集客率が35％アップしました

ニーズに合わせた個別最適化（パーソナライゼーション）

データから顧客ニーズを得ることで、顧客ごとに最適化した製品やサービスの提供ができます。
以下のような例があります。

• • • Kimberly-Clark：子どもの生育状況をおむつ購買状況から判断して商品提案をしています
    • British Airways：他部門のデータをカスタマー部門の責任者が閲覧して、顧客データ分析をしています

データ比較の基準構築

特定の顧客の心理や行動について、顧客全体の平均との相違度合が掴めるようになります。
以下のような例があります。

• • • Nike：靴のセンサーで取得した今日の運動パフォーマンスを顧客が過去の自分やコミュニティ平均と比較でき、運動のモチベーションに繋げています
    • Bill Guard：過去に問題となったクレジットカード取引データを分析して他の問題がある取引の発見に活用しています

データを活用方法を検討する際に、ぜひ参考にしてください。

顧客体験のデジタル化

顧客体験をデジタル化することにより、企業と顧客、あるいは顧客同士のコミュニケーションが促進され、企業の売上拡大につながります。デジタルトランスフォーメーションの本丸とも捉えられる領域です。
どのように顧客体験をデジタル化するのか、その手法についてみていきましょう。

顧客のデジタル体験におけるステップ

企業が顧客に新たなデジタル体験を提供するには、次の5つのステップがあります。

1. 1. 接続：簡単にいつでもどこでも接続してもらえるようにする
   2. 参加：顧客にとって価値のあるコンテンツの供給源になる
   3. 適応：提供物を顧客ニーズに適応させたものにする
   4. 結合：顧客の会話、話題の一部になる
   5. 協働：顧客に事業構築の一端を担ってもらう

顧客にこのステップを経てもらうために戦略を立てていく必要があります。
以下で詳細を解説します。

顧客のデジタル体験を促進する戦略

前述した各ステップでのデジタル体験を促進するには、後述するポイントがあります。これらのポイントをふまえて、自社のビジネスではどんな切り口から顧客にアプローチできるかを考えましょう。

「接続」における戦略検討ポイント

• • • • どのように顧客の興味を誘発するか
      • 顧客の体験をどのようにして早く、簡単にできるか
      • 顧客がサービスをより利用しやすくするにはどうするか
      • 顧客がサービスをセルフ化するにはどうするか

「参加」における戦略検討ポイント

• • • • 顧客の関心を得るにはどうするか
      • このサービスによって解決できる顧客の課題は何か
      • このサービスは顧客が自分の知り合いに勧められるものか

「適応」における戦略検討ポイント

• • • • 顧客のニーズや関心は、どの領域で最も大きいと予想されるか
      • 顧客が選択肢の多さに惑わされずに自分に合った選択をするにはどうするか

「結合」における戦略検討ポイント

• • • • 企業が関与せずに顧客同士の会話や推奨を促進するにはどうするか
      • 会話を通じて顧客に価値をもたらすにはどうするか

「協働」における戦略検討ポイント

• • • • 顧客が持つスキルは何か
      • 顧客が持つスキルの限界はどこか
      • 顧客が行動する動機はなにか。ブランドか、金銭的報酬か、承認の欲求やその組み合わせなど
      • 顧客が自分の行動が認められたと感じるにはどうすればよいか

これらの内容を検討することで、効果的な各ステップの戦略を立案します。

DX戦略推進プロセスの策定と成果評価・ガバナンス

取り組む領域の選定が完了したら、次は DX推進のプロセス策定と成果評価の手法検討に進みましょう。
前章までで決定した取り組み領域ごとに、事前整理の章でもご紹介した「デジタイゼーション」「デジタライゼーション」「デジタルトランスフォーメーション」のうちどのレベルの取り組みからするべきかを意識しつつやるべき施策・タスクと取り組みのスケジュールなどを整理していきます。

この段階では実行にあたり調整や協力が必要となる社内の事業部や部署とも議論が必要です。
システムの導入や刷新、データの管理などではシステム部門が、新サービス検討などは企画部門や営業部門とのアイデア出しや TODO 整理が欠かせません。
自社のリソースで対応できるか、外部のナレッジやリソースを取り入れる必要があるかを含めた判断が求められます。
自社内で開発の内製化を目指す場合には中長期的な視点が必要な場合もありますので以下の記事を参照ください。
進むシステムの内製化 メリットや難しさを踏まえどう取り組むべきか（新しいタブで開きます）
以下では DX の戦略推進プロセス策定と実行時に重要となる考え方、実行後の施策の評価時のポイントについて解説します。

DX戦略推進におけるアジャイルという考え方の必要性

DX においては、「アジャイル」を意識した推進プロセスが欠かせません。アジャイル（agile）は、「敏捷」や「機敏」という意味で、方針の変更やニーズの変化などに機敏に対応することを示します。
もともとアジャイル開発というシステム開発の手法が存在しており、近年ではそこから開発業務以外のビジネスプロセスや組織論においても「アジャイル」の考え方を取り入れる機運が高まっています。
アジャイル開発については以下の記事で詳しく解説しておりますのでぜひ参考にしてください。
アジャイル開発とは？ – システム開発を発注する時に知っておきたい開発手法の話（新しいタブで開きます）

デジタル技術の発達によって、ビジネスをテストするコストは各段に下がりました。たとえば、ある製品の販促方法を複数試す場合、従来では複数の店舗が必要でした。しかし昨今ではインターネットでプロモーションができるため、少ないコストで複数の販促方法を試せます。
時代の流れに合わせて素早く・低コストで試行をすることで、仮に失敗したとしてもリスクを低減することができます。
市場や社会の変化が早い現代では、入念な準備をして一回で成功を掴み取るのは非常に困難です。それよりも試行回数を増やし、改善を重ねていくことで最終的な成功に近づく方がリスクも低く効率的です。

素早く試行を繰り返す際の5つのポイント

アジャイルの適用においては、以下の5つの考え方がポイントになります。

• • 素早く学び、反復的に進める
  • 解決策ではなく課題を重視する
  • 顧客から意見をもらう
  • 前提を検証する
  • 失敗を恐れない

一つずつ説明していきます。

素早く学び、反復的に進める

早い段階で対象の製品やサービス・プロセスの実験を繰り返し、多くの学びを得ることが重要です。この実験の繰り返しが遅くなると、失敗によるコストが大きくなってしまいます。制度や社内文化も含めてすぐ検証ができるような環境づくりも必要です。

解決策ではなく課題を重視する

解決策、つまり手段を最初に考えるのではなく顧客の課題を把握することに努めましょう。顧客の課題を適切に解決できるサービスでないとビジネスを成長させるのは難しくなります。
DX のよくある失敗として、顧客ニーズを無視して「とりあえず」デジタルのサービスを立ち上げるという手段ありきの取り組みをしてビジネスがスケールせずに撤退してしまうケースが挙げられます。
そのようなことにならないために、課題にフォーカスすることが重要です。

顧客から意見をもらう

社内の同僚や幹部社員、役員などではなく、実際の顧客や見込み客から直接製品やサービスに関しての意見をもらいましょう。
たとえば、食べ物を提供するなら実店舗に立って試食してもらう、プロダクトやサービスなら実際に使ってもらう、という対応を取り、なるべく多くの顧客や見込み客から意見をもらうことです。
顧客や想定のユーザー層に対価を支払って、インタビューさせてもらうのも良い方法でしょう。一方で、その意見はあくまで一顧客の意見ですので、一人の意見にすべてを委ねてしまうといったことのないようにバランスをとることが重要です。
また、必ず製品やサービス、もしくはプロトタイプ（新しいタブで開きます）を作ってから意見をもらうことがポイントです。具体的な製品やサービスを作らずに意見だけ求めると、実際に使ったときの感想とはずれた内容を答えられてしまうことが多いためです。
当社でも提供していますが、開発を伴わないプロトタイプ制作や最小限の開発で初期プロダクトを作る MVP開発とユーザーインタビューを含む検証を支援している企業も存在します。
自社のみでの実行に不安がある場合はこうしたサービスの活用を検討するのも良いでしょう。
（新しいタブで開きます）

前提を検証する

アイデアをテストする際、その前提条件は自分の思い込みであることがよくあります。そのため、実際にテストしてその前提が通用するかを確認することが必要です。
たとえば、アイデアの協力者として想定していた人物が、実は利益背反の立場にあり協力が得られなかったなどの場合です。自分たちが正しいという思い込みは捨てましょう。

失敗を恐れない

特に日本の企業は、失敗による評価の低下や降格などを恐れてチャレンジしない傾向がありますが、その風土では残念ながらアジャイルとは程遠いといえます。
もしあなたが組織を動かせる立場にいるなら、この失敗を恐れない風土づくりにも取り組まなくてはなりません。この失敗の仕方にはポイントがあります。

• 失敗を検証し、戦略変更やサービスの向上に活用したか
• 可能な限り初期段階で失敗したか
• 失敗から得た学びを共有したか

たとえば上記を守った上での失敗であれば咎めない、というルールを作ってしまうなど、チームがチャレンジをしやすい仕組みや雰囲気をつくることからはじめるとよいでしょう。

アジャイルによる推進の評価・ガバナンス

取り組み後の評価にあたっては、以下2点のポイントに注力して進めましょう。

• • 顧客体験向上の KPI を設定して、評価結果に基づきアセットの配分を改善
  • 失敗を人事考課のマイナスとするなど、失敗からの学習を阻害しないよう配慮

またガバナンスについては、以下3点のポイントに注力することが必要です。

• • 自社の DX推進状況を KPI などで客観的に把握
  • 場合によっては DX が進んでいないと認識すること
  • 株主など企業の外側から DX推進状況を評価すること

DX戦略の修正頻度は米国においては、「毎月」が26.3％と最も多くなっています。外部からの評価も交えて高頻度の見直しを実施しましょう。

※引用：DX白書2021_第2部_DX戦略の策定と推進p69より（新しいタブで開きます）

DX戦略推進にあたっての注意点

DX戦略の策定プロセスは以上ですが、DX戦略を策定・推進していくうえでは、いくつか失敗しやすい注意点があります。
戦略の策定段階で認識しておくことで、実行時の失敗を避けられる場合もあると考えます。
ここでは、その注意点についてみていきましょう。

組織変革における注意点

冒頭でも述べた通り、DX を実施するうえでは大きな組織変革に臨まなくてはなりません。その内容は大きく以下3つです。

新たなスキルとの入れ替え

DX には推進デジタル関連スキルの習得が必要ということはみなさまも認識されているかと思います。
とくに社内でのデータ分析の分野においては以下2点のスキルが必要です

• • • 統計学や機械学習の理解
    • 意思決定者へ伝わるプレゼンテーションスキル

不足するスキルは採用や外注で補う必要がありますが、中長期的には社内で育成できることが望ましいでしょう。人事部と連携して教育体制を整えることも検討しましょう。

縦割り組織を横断するような対応をする

DX推進は最終的には全社プロジェクトとなります。各部門の文化や予算などを超えた協働が必要な場面も多くなります。予算や、人員のアサインなど、部門間の利害関係を調整する必要が出てきます。大企業ほど、この共同体制をつくる点に苦心するケースは多いようです。
部門間調整を担当する専任ポジションや推進部署の新設が対策としては挙げられます。
ただし、名ばかりで権限を持たない部署やポジションを作ってしまうと結局推進体制の構築に失敗するということに繋がります。
経営陣を新設部門長にするなど、相応の権限の付与がセットでなされるべきです。

企業文化変革

すでに述べてきたように、DX を推進するためには企業文化や風土の変革も必要です。
DX推進においてとくに重要な風土は下記2点です。

• • • 業務プロセスにアジャイルの5つのポイントを採用
    • 失敗も許容できる文化の醸成

すでに社風として浸透していれば対応する必要はありません。まだの場合は「DX戦略推進プロセスの策定と成果評価・ガバナンス」で紹介したような制度や取り組みが必要です。

リーダーシップにおける注意点

企業トップのリーダーシップはもとより、社員一人ひとりが DX に対するリーダーシップを持ち、自分事として取り組むことが重要です。

企業トップのコミット

とくに重要なのが、経営のトップが DXビジョンを示してリーダーシップを持って進めることです。
新たな取り組みを実施する際には、社内から反発の声が出ることもあるでしょう。
実際、これまでの自社ビジネスを大きくすることに貢献してきた社員からの意見は、一理あると感じることもあると思います。
ですが、DX が目指すのは既存ビジネスの改善ではなく「変革」です。
社内調整が難航した場合、最終的にはトップから方向性を強く示して推進することが重要になります。

組織全体で取り組む必要性

もちろん、経営トップだけが大事なのではでなく、組織のメンバのー一人ひとりが DX の必要性を認識し、自分事として取り組む姿勢も大事です。
DX推進部といった新設部署を設けた場合に起こりがちなのが、既存の部署の社員が DX の取り組みを他人事だと感じて非協力的になってしまうことです。
そのような場合には前述したトップからのメッセージも重要ですが、自社にとって、自部署にとって、ひいては顧客にとって、DX することにどんな意味があるのかを地道に伝え続けることが必要となるでしょう。
また、小さくてもいいので社内での成功事例をつくり、共感してもらえる社内の仲間を増やしていくなど、泥臭く草の根的な活動も現場レベルでは求められます。

データ活用と分析における注意点

本記事でも注目の領域としてご紹介した、テーマであるデータ活用と分析。
DX における取り組み領域としてよく取り上げられることが多いです。
こちらにも取り組む際の注意点があります。その内容をみていきましょう。

AI・データに関わる作業の注意点と過信

「AI は人の仕事を奪う」などといわれて久しいですが、魔法のツールというわけではありません。以下に挙げるようなポイントを適切に理解しておく必要があります。

• • • AI の学習前には、ほとんどの場合、学習用データ前処理対応の人員が必要
    • データ解析には経験豊富な分析者が必要
    • データの質と精度（収集過程、誤差など）が重要
    • AI は万能ではなく、特定の問題に特化した AI構築が必要
    • AI の答えをみて最後は人間の判断が必要

セキュリティやプライバシーの問題

世界的にも顧客が企業からのプライバシー侵害を受けないようなデータに関する規制等が進んでいます。日本でも個人情報の扱いは年々厳しくなってきていると感じられている方も多いでしょう。
加えて、フィッシング詐欺や不正アクセスといったサイバー攻撃も年々激化しています。この点に関していえば、実践に関わらず企業として対策が必須です。
また、企業にデータを収集されることについて懸念を感じている顧客も存在します。提携先や顧客とデータ共有する前に契約書でデータの取り扱いを定めることは当然ですが、データの取り扱いや利用目的について単に定めるだけでなく、顧客にわかりやすく公表、説明するといった対応が求められます。

データの入手手段

「データ活用」というけれど、どこから手を付けるべきかわからない。そもそも自社に活用できるデータは存在しているのか不明な場合もあるでしょう。
データを手に入れるポイントについては、5つの提案があります。

• • • 顧客：報酬やロイヤリティ向上などでデータ共有を促す
    • ロイヤリティの高い顧客：コミュニティ形成やボランティア依頼など
    • 提携企業：相互に利益が出ると想定される関連企業との連携で顧客行動を把握
    • 公開データセット：政府やインターネット上で公開されているデータ、SNS投稿など
    • 販売データ：顧客の個人情報が伏せられた非特定化データなど

上記のいずれかですでに社内にデータがあれば、それを活用していきます。ない場合は戦略の中にデータ収集の方法や顧客接点のポイントをつくることを盛り込む検討してもよいかもしれません。

リソースの調達についての注意点

社内でデジタル人材が不足していたり、戦略の策定や実行にあたってリソースが不足するといったことが DXプロジェクトではよくみられます。
この章の最後にリソース不足に陥った際の対象方法について紹介します。

パートナーシップ・アライアンスなど外部の力を活用

社内からスキルのある人材の抜擢や、採用などで対応することができればシンプルですが、デジタル人材はどの企業も喉から手が出るほど欲している状況です。思うように採用が進まないケースも想定しておくべきでしょう。
社内での調達が難しい場合は、外部の力を上手く使うと効率的です。
システム開発を受託開発の企業に依頼する場合や、戦略策定支援をコンサルティング会社に依頼するケースなどが考えられます。
一社員としての意思決定は難しいとは思いますが、M&A で企業ごと買収して調達する方法も考えられます。
一方で、外注にもコストが発生する点、外部の力に頼りすぎると内部にノウハウが蓄積されないといったデメリットになり得る点は念頭におく必要があります。

適切な領域に人とカネを投資

戦略の策定・実行には自社の現状を把握し、適切な領域に人とカネを投資する必要があります。当たり前のことのように聞こえるかもしれませんが、判断を見誤り、無駄な取り組みに不要なコストや人的リソースを投下してしまっている企業は少なくありません。
とくに日本企業は、業務効率化や生産性の向上などのいわゆる「守りのDX」に投資が偏重しており、顧客に新しい価値を提供したり、市場に新しいサービスをつくる等の「攻めのDX」への投資ができていないという傾向がみられます。
長期的にビジョンを達成するために、何に投資するべきか、かけるコストは適切か、定期的に見直し続けることが大事です。

迅速なDXのニーズに応える『FastDX』

スパイスファクトリーでは、DX推進戦略において「極力開発しないDX」をテーマに『FastDX®』を提唱しています。
最近では、多くの企業にとって共通的に必要となる仕組みは、SaaS などの形でサービスとして提供されるようになりました。たとえば、営業やマーケティング領域で DX を実現しようとした場合、SFAや MA などの利用が有効です。これらは SaaS の形態でさまざまな製品が提供されており、手軽に利用することができます。
当社では、先述したアジャイル開発の思想やノウハウに加えて、SaaS や CMS など既存の最新プラットフォームを最大限活用した開発を行うことで、素早いデジタル変革を実現する手法を FastDX® と定義して実践しています。（FastDX® はスパイスファクトリー株式会社の商標登録です。）
FastDX を実行することで、企業はより素早く、より低リスク・低コストに DX にチャレンジできると考えています。
詳細は以下の記事もご参照ください。
【2023年版】DXが失敗する理由は？リスクを下げ成功確率を上げる「FastDX」という選択肢（新しいタブで開きます）

当社は、FastDX の他に、戦略策定からスクラッチ開発も含めて、企業の DX を一気通貫で支援できることを強みとしています。
自社内のみでの DX推進に課題を感じている方はぜひお気軽にご相談ください。

自社のビジョンに基づいたDXの推進を

この記事では、DX戦略の立て方や推進の際に注意すべきことについて解説してきました。
まとめです。DX戦略の立て方は次の通りです。

1. 自社のあるべき姿（ビジョン）の策定
2. 取り組み領域の策定
3. 推進プロセスの策定
4. 成果評価とガバナンス

プロジェクト推進にあたっては以下の領域で躓きやすかったり、配慮が必要な場合があるので意識しましょう。

• 組織変革
• リーダーシップ
• データの利活用
• リソースの確保

自社のあるべき姿（ビジョン）に基づいて、DX を進めていきましょう。

DX の推進でお困りの方は、ぜひ一度スパイスファクトリーへご相談ください。
スパイスファクトリーでは、アジャイル開発や FastDX により皆様の新規事業開発や DX を支援いたします。ご興味のある方は（新しいタブで開きます）下さい。
（新しいタブで開きます）

参考文献

＜書籍＞

The Digital Transformation Playbook「DX戦略立案書」：デビッド・ロジャース 著、笠原栄一 訳.2021/1/8
デジタル人材がいない中小企業のためのDX入門：長尾一洋 著. 2022/10/20
DX経営戦略～成熟したデジタル組織を目指して～：ジェラルド・C・ケイン他 著、三谷慶一郎他 訳.2020/10/31

＜サイト＞

DX白書2021：IPA 独立行政法人 情報処理推進機構.2023/2/24
あるべき姿をどう描くか：『ビジネス2.0』の視点：オルタナティブ・ブログ.2023/2/24
DX戦略とは？立て方のポイントなどを先進企業の事例を交えて基礎から解説.2023/2/24
成功につながるDX戦略の立て方と事前準備のアプローチ方法とは？.2023/2/24
DX戦略の立て方とは？失敗例と推進事例から探る成功のパターン.2023/2/24
5つの事例から学ぶ「DX戦略」の立て方と、成功のための3つのコツ.2023/2/24
DX戦略の立て方とは？成功のポイントやビジョンの設定事例も紹介.2023/2/24

 

企業がスマートフォンアプリの提供を行う際に、PWA（Progressive Web Apps） の活用は一つの有効な選択肢となります。PWA はネイティブアプリと Webアプリの良いところを併せ持っており、かつアプリ開発におけるコストを抑えやすいというメリットがあります。一方で、ユーザーの認知度が低いことや機能に制約があるなど、使いどころの見極めも重要となる技術です。
この記事では、PWA の概要やその仕組み、他の開発手法との比較などの解説を通して、PWA がどのようなものなのか、またどのようにビジネスに活用していくべきなのかをご紹介します。

当社、スパイスファクトリーでは、アジャイル開発の受託開発サービスやWebアプリ・サービス開発支援を提供しております。
スマホアプリやWebアプリケーションについてのご相談がある方は是非（新しいタブで開きます）ください。

（新しいタブで開きます）

PWA（Progressive Web Apps）とは

PWA（Progressive Web Apps）とは、スマートフォン向け Webサイトを、ネイティブアプリのように端末にインストールして利用することができる仕組みのことです。
通常、アプリをインストールする際には、iPhone であれば App Store から、Android であれば Google Play からダウンロードしてインストールする必要があります。一方で PWA の場合、これらのアプリストアを経由せず、Webサイトから直接アプリをダウンロードし、インストールできます。
PWA は JavaScript や CSS などの Web技術により実現されますが、オフラインで動作したり プッシュ通知を実施できたりと、ネイティブアプリに近い形で動作させることができます。
PWA は主に Google が中心となって推進している方式でありますが、一部制約はあるものの iOS でも PWA によるアプリを提供することができます。

PWAで構築されたアプリの利用イメージ

PWA で構築されたアプリは、一般的なネイティブアプリとインストールされるまでのフローが異なります。
以下では、ユーザーが Webサイトを閲覧してから PWA で構築されたアプリをインストールし、利用するまでの流れについて紹介します。

Webサイトへのアクセス

ユーザーは、Google検索や SNS、もしくはオフライン・オンラインでの広告などから Webサイトへアクセスします。
スマートフォンのブラウザから PWA 対応を行った Webサイトへアクセスすると、通常の Webサイトと同様に、各種機能やサービスなどを利用することができます。
PWA化されたサイトに訪れたユーザーは、必ずしもアプリをインストールする必要はありません。そのままブラウザから Webサイトを表示する形で利用することも可能です。

アプリのインストール

Android の場合、PWA に対応した Webサイトへアクセスすると「Add xxxxx to Home screen」とポップアップ表示され、アプリをインストールするように促されます。ポップアップをタップすることでアプリがインストールされ、ホーム画面に追加されます。
なお、iPhone の場合ではポップアップ表示はされませんが、Safari から「ホーム画面へ追加」を選択することで、同様にアプリをインストールすることができます。

ホーム画面からのアクセス

ホーム画面に追加されたアプリアイコンをタップすることで、アプリとして動作します。
ブラウザで Webサイトを表示しているわけではないため、ブラウザのナビゲーターなどは表示されず全体にアプリ画面だけが表示されます。よって、ユーザーはアプリとして自然に利用することができます。
また、インターネットに接続していないオフライン状態でも動作できたり、インストールされているためアプリの起動が早かったりというメリットもあります。
加えて、カメラやマイク、GPS、Bluetooth、生体認証、支払いなどの様々な機能を利用することも可能です。ただし、iPhone においては一部ネイティブ機能の利用ができないので注意が必要です。

バックグラウンド動作

PWA はアプリとしてバックグラウンドでの動作にも対応しています。
バックグラウンドでのデータ同期もできるため、ユーザーがアプリを開く前にあらかじめ情報を取得しておき、すぐに確認することもできるようになります。
ただし、PWA はバックグラウンド動作時の GPS やセンサー類の利用に制約があります。
ネイティブアプリと全く同じようにバックグラウンド動作はできない点に留意が必要です。

プッシュ通知

ネイティブアプリと同様に、ユーザーへの通知を行うことができる点も PWA のメリットです。アプリが非アクティブとなっている間も、バックグラウンドでプッシュ通知を行うことができます。
これにより、キャンペーンの案内や商品発送の連絡など、ユーザーとのコミュニケーションが可能となります。
なお、iPhone においては、プッシュ通知は不可となっています。ただし、後述のとおり 2023年度をめどに対応を行う旨が Apple より発表されています。

iPhoneにおいても2023年中にプッシュ通知が可能に

2022年6月6日 の Apple WWDC（世界開発者会議）にて、2023年に iOS が Webプッシュ通知に対応すると発表されました。
従来、iOS では PWA によるプッシュ通知は実現できませんでしたが、この対応により PWA でもプッシュ通知が可能となります。
プッシュ通知はユーザーにアプリへのアクセスを促す効果的な方法であり、マーケティングなどの用途において活用したいニーズが高い機能といえます。
これまで、iOS でプッシュ通知が実現できない点は、PWA によるアプリ提供のひとつのネックとなっていました。
Apple のこの対応により、ビジネスにおいて PWA を活用する価値がさらに高まっていくと思われます。

PWAを採用するビジネス上のメリット

PWA を採用することで、ビジネス面においてはどのようなメリットを得ることができるのでしょうか。以下で紹介します。

アプリインストール障壁の低下

スマートフォンユーザーはアプリを厳選する傾向にあります。
実際に、MMD研究所の「2022年版：スマートフォン利用者実態調査　第2弾」（新しいタブで開きます）ではスマートフォンユーザーが端末にインストールするアプリの数は平均で19.3個であるという結果が明らかとなっています。
この数字には SNS やニュースアプリなど、多くのユーザーがインストールするアプリも含まれるため、端末内にインストールされるアプリはかなり限定されるといえるでしょう。
マーケティングや販売促進活動、データ分析など様々な観点でアプリの活用は効果的です。しかしながら、その前にどうやってユーザーにアプリを届けるかが難しいポイントとなります。
そこで、PWA の活用が有効です。
通常、アプリをインストールするためにはアプリストア経由でアクセスする必要がありますが、アプリのインストールまでにステップ数が多いことから手間となりがちであり、離脱も発生します。
PWA であれば、Webサイトにアクセスした際にそのままアプリをインストールすることができるため、ステップ数を抑えることができます。
PWA を採用することで、アプリのインストール障壁を下げ、ユーザーにアプリを届けやすくなります。

Webからの流入

PWA で構築したWebサイトは、当然ながらそのコンテンツも含めて Google や Yahoo などの検索に表示されることになります。これにより、検索での流入が期待できます。
たとえば、自社で販売している商品のコンテンツを PWA で構築したアプリ内に用意しておけば、商品名などで検索したユーザーが商品の Webサイトにアクセスし、そこからアプリのインストールへの導線がつながることになります。
上述したアプリのインストールに至るまでの難しさも踏まえると、Web からの流入が期待できる点は PWA の大きなメリットといえるでしょう。

既存Web資産の活用

Webサイトを PWA 対応させることで、自社の Webサイト資産を活用しつつ、アプリとしても提供することができるようになります。
特にこれまで一定期間 Webサイトを運用してきた場合は、獲得してきたドメインパワーなども有効活用することができます。

Web技術による効率的な開発

ネイティブアプリとして開発する場合は iPhone、Android の両者に個別対応する必要があります。
一方で、PWA は Web技術をベースとしているため、OS を問わず共通で開発が可能となります。PWA を採用することで、開発コストの削減が可能です。
加えて、将来的なメンテナンスを踏まえても PWA には優位性があります。
スマートフォンOS のアップデート対応や、機能変更などにおいても、Webサイト・iPhone・Android アプリを個別に修正する必要がなく、低コストかつスピーディに対応できるようになります。
また、Web技術を利用して開発を行うため、技術者が確保しやすいという点もメリットといえるでしょう。

（新しいタブで開きます）

PWAと他の手法の比較

スマートフォンユーザーにサービスを提供する方法として、PWA 以外にも以下の 3つの方法があります。それぞれの手法にはどのような特徴があるのでしょうか。以下では、各手法について PWA との比較を行います。

• ネイティブアプリ
• ハイブリッドアプリ
• Webアプリ

ネイティブアプリとの比較

ネイティブアプリは iPhone や Androidスマートフォン上でアプリを提供するための一般的な方法です。
当然ながら、ネイティブアプリの形態でアプリ開発を行う場合、スマートフォンが持つすべての性能を引き出すことができます。
PWA は高速に動作する仕組みではありますが、やはり速度面ではネイティブアプリにメリットがあります。また、PWA には一部機能制約があるため、機能面でもネイティブアプリが優れます。
一方で、ネイティブアプリは OS に依存するため、iOS と Android のクロスプラットフォーム対応や、OS のバージョンアップへの追従も行っていく必要があります。
アプリとは別に Webアプリの形態でサービスを提供する場合は、そちらのメンテナンスも継続的に実施していかなければなりません。
また、ネイティブアプリを公開する際には、Apple や Google 等のプラットフォーマーの審査を受けなければなりません。
審査基準は定められているものの実務上はあいまいな判断がされたり、審査にかかる時間が発生したりといった問題点もあります。

ハイブリッドアプリとの比較

ハイブリットアプリとは、Web技術を利用してスマートフォン上で動作するアプリを開発する手法のことです。
HTML5 や JavaScript などの Web技術に加えて、ハイブリッドアプリを実現するために提供されているフレームワークを利用して開発を行います。
PWA と同様に Web技術自体は標準化団体である W3C により世界で共通化されているため、iOS・Android を問わず、同じプログラムで動作させることが可能となります。
ただし、ハイブリッドに利用されるフレームワーク自体は標準化されておらず、いくつかのフレームワークが並立している状態です。
日本のアシアル社が提供する「Monaca」や、Abobe社が提供する「PhoneGap」など、個別企業が提供しているものが多く、フレームワークの継続性という観点でリスクがある点には注意が必要です。
PWA とハイブリッドアプリは比較的共通要素が多いといえますが、その大きな違いとしてアプリのインストール経路が挙げられます。
ハイブリッドアプリはアプリストア経由でのインストールとなる一方で、PWA は Webサイト経由でのインストールとなります。

Webアプリとの比較

Web技術を活用して様々な機能やサービスを提供する Webアプリですが、選択肢として端末にインストールするアプリを導入せず、Webアプリのみでサービスを提供するという方法も検討できます。
Webアプリはブラウザ上で動作するため、ホーム画面から直接アクセスするのではなく、ブラウザを立ち上げて検索エンジンやブックマークなどからアクセスして利用することになります。
個別にアプリを開発しないためコスト面には優位性がありますが、ここまで紹介したアプリと比較するとプッシュ通知が不可能であるなど機能面に劣る点や、ユーザーのアクセス頻度を高める施策が難しい点などにデメリットがあります。
このような理由から、Amazon や楽天など多くのユーザーがブラウザ経由で利用するサービスでは、アプリへの誘導のためアプリ利用者はポイント還元率を高めるといったインセンティブ施策を実施している事例もあります。

比較表

ここまでを整理すると、それぞれの開発手法の特徴は下表のとおり整理できます。

コストをかけてでも機能性に優れるアプリを提供したい場合は、ネイティブアプリの採用が優れています。
その一方で、Webサイトとの共通化によりコストを削減しつつ、アプリのインストール障壁を下げる取り組みを行いたい場合は、PWA の採用がおすすめとなります。
また、PWA のインストール障壁の低さを活用するため、ライトユーザー向けに PWA を構築しつつ、ヘビーユーザー向けにはネイティブアプリを用意するといった使い分けも検討できるでしょう。

このように、PWA やネイティブアプリなど、それぞれのアプリ開発手法にはメリット・デメリットがあります。
自社が所有する既存 Web資産や実現するサービスの特性、提供したいユーザー体験によって最適な開発手法を選択することが重要となります。

PWAの開発事例

以下では、主要な PWA の開発事例について紹介します。

日本経済新聞社「日経電子版」

PWA の事例で最も有名といえるのが、日本経済新聞社の「日経電子版」の事例といえるのではないでしょうか。
同社では、2017年という早い段階で自社サイトの PWA化を実施。大手企業の中では先進的な取り組みを進めています。
PWA化の効果として、表示速度の改善が挙げられます。同社では、Webサイトの表示スピードがそのままユーザーのコンバージョン率低下につながることに着目し、自社のWeb媒体サービス「日経電子版」の表示高速化に取り組んでいました。
様々な取り組みの一環として PWA化に注目。事前キャッシュによる記事の高速表示や、オフラインでのアクセスなどを実現するほか、速報のプッシュ通知などを可能としています。
PWA化を含めた様々な取り組みにより、日経電子版のアクティブユーザー数は 49%増加し、またコンバージョンについても 58%増加するという成果を出すことができました。

参考：リニューアルで表示を高速化させた「日経電子版のページ高速化とPWA対応」プロジェクトの舞台裏 | リクナビNEXTジャーナル（新しいタブで開きます）

Forbes社

アメリカの経済雑誌である Forbes社でも、PWA化によりページ表示速度の向上などの成果を挙げています。
2017年に同社では自社サイトの PWA化を実施し、ページ表示にかかる平均時間を 6.5秒から 2.5秒に短縮することができました。
同社の調査によれば、PWA利用者のセッションあたりの表示ページ数は、旧サイト利用者と比較して 10％向上しているとのことです。
また、PWA利用者はセッションあたりの閲覧時間が 40％程度長くなっているという結果も報告されています。

参考：Forbesが改心、PWA対応モバイルサイトでUXを改善：セッションあたりの閲覧数が10％向上 | DIGIDAY［日本版］（新しいタブで開きます）

Lancome社

化粧品会社として知られる Lancome社でも、PWA の導入を実施。
同社では、2016年時点で自社ECサイトへのアクセス数がPCよりもモバイルの方が上回りました。一方で、PCからアクセスしたユーザーの38%が商品を購入していたのに対して、モバイルでの商品購入率は 15%にとどまっていました。
このような状況を踏まえ、モバイルでアクセスするユーザーの体験を重視するために PWA化を実施。
結果として、ユーザーの直帰率が 15%改善され、また商品の購入率も 17%増加しました。
また、PWA のプッシュ通知により、カートに商品を登録した後離脱したユーザーの商品購入率を 8%増加させることができました。

参考：Lancôme rebuilds their mobile website as a PWA, increases conversions 17%（新しいタブで開きます）

アリババ社

世界最大級の B2Bトレーディングプラットフォームであるアリババ社では、PWA化によりコンバージョン率を 76%向上させることができました。
また、iOS の月間アクティブユーザー率は 14%増加、プッシュ通知などの再エンゲージメント機能が有効になっている Androidデバイスでは、アクティブユーザー率が 30%増加しました。

参考：Alibaba（新しいタブで開きます）

Spotify社

音楽のストリーミングサービスを提供する Spotify社では、ネイティブアプリの提供に加えて、自社サイトの PWA化も実施しています。
PWAアプリではネイティブアプリと同様の機能を提供しつつ、より操作感に優れるネイティブアプリへの導線も用意。
エントリーユーザーには PWAアプリという選択肢を提供しつつ、ネイティブアプリの利用も促進しています。
PWAアプリの提供により、60日以内のユーザーのリテンション率が 14%増加するなどの成果を挙げています。また、Web版ユーザーの 30%がネイティブアプリのダウンロードを行うなど「ヘビーユーザー化」へのステップとしても効果を発揮しています。
なお、Spotify社では PC のデスクトップで PWAアプリを利用できるデスクトップPWA についても併せて提供しています。

参考：Spotify PWA: Why People Love It – Tigren（新しいタブで開きます）

これらの事例が示すように、PWA化により自社の既存Webサイト資産を生かしつつ、ユーザーのアクセス頻度やコンバージョン率などを向上させることができるといえます。

PWAはユーザーの体験価値を高めるための選択肢

この記事では、PWA の概要や仕組み、他の開発手法との比較などを行いました。
PWA は使いどころを意識して利用することで、ビジネス面でのメリットを得ることができる手法といえます。
スパイスファクトリーでは、この記事で紹介した PWA の開発も含め、スマートフォンアプリの開発をアジャイル型により実現します。
スマートフォンアプリの導入にあたっては、目的に合わせて適切なユーザー体験を提供できる開発方法の選択が必要です。
スマートフォンアプリの導入を検討されている方は、ぜひ一度ご相談ください。

また、当社ではLINEミニアプリによるアプリ提供についても対応可能です。詳細については、こちらの記事（新しいタブで開きます）をご覧ください。

https://spice-factory.co.jp/design/line-mini-app-individual-development/

 

（新しいタブで開きます）

なぜアジャイル開発は失敗するのでしょうか。

アジャイルという言葉はビジネスシーンにおいて十分に一般化したといえるのではないでしょうか。DX推進の潮流なども背景として、近年ではアジャイル開発に取り組む企業も増えています。

実際に、プロジェクトマネジメントの代表的なベストプラクティス集である PMBOK のとりまとめ元として有名な PMI日本支部が実施したアジャイル研究会「2022年度 アジャイルプロジェクトの実態に関するアンケート」（新しいタブで開きます）では、調査の対象とした組織のうち約 4割でアジャイル開発を導入しているという結果が明らかとなっています。

一方で、期待とは裏腹にアジャイル開発は必ずしもうまくいかないのも事実です。

同調査ではアジャイル開発の満足度を NPS スコアにて調査していますが、特にはじめてアジャイル開発に取り組んだ方の約48%が「批判者」つまり「アジャイル開発を他人にすすめない」という回答をしている結果に。

この記事では、その原因と成功のために取り組むべきことを紹介します。

当社、スパイスファクトリーでは、アジャイル開発の受託開発サービスやプロトタイプ開発のサービスを提供しており、豊富な実績があります。

アジャイル開発・スクラム開発の進め方に不安がある方は是非お気軽にご相談ください。
スパイスファクトリーの（新しいタブで開きます）

弊社の概要やサービスプラン、過去の導入実績などをまとめた資料をご用意しました。気になる方はこちらからダウンロードしてください。

アジャイル開発は万能薬ではない

アジャイル開発を理解する上で、まず意識しなければならないのは、アジャイル開発は決して万能薬ではないという点です。これはどういうことなのでしょうか。

「アジャイルだからうまくいく」は間違い

「アジャイルでやれば必ずうまくいく」というのは誤解です。特に、アジャイル開発に初めて取り組むケースにおいては、その期待度も相まって「アジャイルでやればこれまでのやり方よりも必ず成果があがる」と考えてしまうこともあるでしょう。
しかしながら、あくまでアジャイルはひとつの考え方であり、他の手法と比較して採用を検討するべきものです。アジャイルで開発を行えば必ずうまくいくのではなく「アジャイルが向くプロジェクトにおいて」「適切にアジャイルの考え方を取り入れれば」「プロジェクトの成功率が上がる」というものだと捉えるべきです。
上司など社内の権限者に説明を行う際にも、この観点をインプットしておくことは重要といえます。

メリットの多いアジャイル開発

もちろん、アジャイル開発は優れた手法であり、様々なメリットを得ることができます。アメリカのコンサルティング企業である McKinsey&Company の調査「Enterprise agility: Buzz or business impact?」（新しいタブで開きます）によれば、アジャイル開発により以下のような効果があると報告されています。

• 従業員のエンゲージメント：20～30%上昇
• 顧客満足度：10～30％上昇
• 運用効率性：30～50%上昇
• 経済的な価値：20～30%上昇

引用元：「Enterprise agility: Buzz or business impact?」（新しいタブで開きます）

このように、アジャイル開発は正しく活用すれば効果につながる手法であるといえます。

アジャイル開発が失敗する主な原因

アジャイル開発の効果を最大限発揮できるようにするためには、アジャイルが失敗する原因を理解し、アンチパターン（＝典型的な失敗例）に陥らないことが重要です。そこで以下では、アジャイル開発が失敗する主な原因を紹介します。

①アジャイル開発への理解不足

よくあるのが、発注者側の現場担当者はアジャイルに対して理解があるものの、上層部がその理解に乏しいケースです。
アジャイル開発でプロジェクトを進める以上、スケジュールやコストは柔軟に変更していくことになります。しかし、上層部に理解がなければ、これらの変更は難しいといえます。
特に、旧来型の日本企業においてよく見られるのが「当初の予定を変更することを失敗ととらえてしまう」という文化です。アジャイル開発で進める以上、スケジュールやコスト、開発スコープなどに変動があることは理解しつつも、頭のどこかで「当初想定と違う結果となっており、このプロジェクトはうまくいっていないのでは？」という意識が働きます。結果として「アジャイルでのプロジェクトは失敗した」「コストがかかりすぎる」という認識を持たれてしまうことも。
企業にとって予算や計画の遵守は運営上重要な観点ではありますが、アジャイル開発では現時点での状況を踏まえて常に最適な選択を行うため、当初の想定とは違う結果となる可能性があるという認識が必要です。

②プロダクトオーナーの機能不全

要件定義フェーズですべての要件を確定させるウォーターフォール型開発とは異なり、アジャイル開発では必要な部分のみ要件を確定させます。これはプロジェクトに柔軟性を与えるという効果がありますが、一方で仕様の決定権を持っている方（プロダクトオーナー）がプロジェクトに深く参画しないと失敗の原因ともなります。
アジャイル開発の手法であるスクラムにおいては、ビジネスニーズを整理し、開発するプロダクトの要件を整理・決定するプロダクトオーナーの役割が必要です。このプロダクトオーナーが十分にプロジェクトに参加しないと、実用性の低いシステムが作られることになります。
また、プロダクトオーナーに十分な決定権を与えることも重要です。決定権がない方がプロダクトオーナーの役割を担ってしまうと、持ち帰り事項の多発などによりどうしても判断のスピードが遅くなります。
プロダクトオーナー側の十分な参画なくして、アジャイルが持つ柔軟性や俊敏性といったメリットを活かすことはできません。

③目的を理解しない形だけの運用

単にアジャイル開発の形式をなぞっただけでは、効果は薄いといえます。アジャイル開発はその考え方や取り組み姿勢が重要であり、その結果としてプロセスやプラクティスが存在するものです。
たとえば、スクラムにおいてデイリースクラムが推奨されているからと言って、単に毎日ミーティングを行っても効果は上がりません。なぜデイリースクラムを実施する必要があるのか本質的な理解をしなければ、意味がない時間となってしまいます。

④アジャイルに向かないプロジェクトへの適用

アジャイル開発には向き不向きが存在します。何が何でもアジャイルでプロジェクトを運営するという考え方ではなく、適したプロジェクトへアジャイルを適用するという考え方が必要です。
たとえば、既存システムのリプレイスなど、作るべきものが全て明確に決まっている場合には、アジャイル開発ではなくウォーターフォール型の開発の方が適している場合も多いでしょう。

⑤心理的安全性の不足

アジャイルで開発を進める際にはチーム内のコミュニケーションが重要です。うまくチーム内でコミュニケーションが活性化されないことも失敗の原因となります。
自社内でのコミュニケーションはもちろん、開発を外部の企業に委託している場合はパートナーとなる企業のメンバーとのコミュニケーションも含みます。
コミュニケーションがうまくいかない原因は様々考えられますが、ひとつには心理的安全性の不足が挙げられるでしょう。
心理的安全性とは、チームの中で自分の考えを安心して発言できる状態のことです。たとえば何に対しても否定するメンバーがいたり、失敗を過剰に攻めるリーダーがいたりすれば、チームの心理的安全性は確保されません。
アジャイル開発を成功させるために、発注側も受注側も、また上司も部下もひとつになってチームとして開発を行える状態になる状態を目指すべきです。

アジャイルのアンチパターンに陥らないために気を付けるべきポイント

これらの「アジャイルのアンチパターン」に陥らないように、アジャイル開発を行う上ではどのような点に気を付けるべきなのでしょうか。以下では、それぞれの観点ごとにポイントをご紹介します。

ポイント①：アジャイルの留意点をステークホルダーにインプットする

アジャイル開発を実施する際に、上層部や関係者などのステークホルダーに対してスケジュールの遅延や予算の追加、スコープの見直しなどが発生する可能性を十分にインプットしておくべきです。
アジャイル開発においては、開発内容を柔軟に見直した結果、スケジュールやコストが変動する可能性があります。また、スケジュールが必達である場合は、開発する機能を調整してスケジュール内に収める場合もあります。
当初想定していた QCD を見直す可能性がある点を、あらかじめステークホルダーにインプットとしておくことで、ハレーションを避けることができます。

ポイント②：プロジェクト担当者の時間を十分に確保する

ウォーターフォール型でも同様ですが、特にアジャイル開発においてはプロダクトオーナーをはじめとしたプロジェクト担当者の十分なプロジェクト参加が必要です。
よくあるのが「他のプロジェクトにもアサインされた」「イレギュラー対応で業務量が増えた」など、他の仕事が忙しいといった理由でプロジェクトの参加度合いが低下してしまうケースです。このような状況を避けるために、アジャイル開発でプロジェクトを進める際には、可能な限り専任で担当者を配置することが望ましいといえます。また、専任でプロジェクトに参加できないとしても、積極的なプロジェクト参加がプロジェクトの成功に資するという意識のもと、可能な限り時間を確保できるように組織として意識することが重要です。

ポイント③：アジャイルの各プロセスの目的を理解する

アジャイルでプロジェクトを推進する際には、そのプロセスが持つ目的を十分に理解する必要があります。
アジャイル開発における基本原則であるアジャイルソフトウェア開発宣言（新しいタブで開きます）では、以下のようにアジャイルの考え方を定義しています。

プロセスやツールよりも個人と対話を、
包括的なドキュメントよりも動くソフトウェアを、
契約交渉よりも顧客との協調を、
計画に従うことよりも変化への対応を、価値とする。

引用元：アジャイルソフトウェア開発宣言（新しいタブで開きます）

アジャイルソフトウェア開発宣言で示されているそれぞれの原則を単に読むだけでは、どのような意味があるのかわかりにくいかもしれません。独立行政法人情報処理推進機構ではアジャイルソフトウェア開発宣言の読みとき方（新しいタブで開きます）として、アジャイルソフトウェア開発宣言を理解しやすい形で紹介していますので、こちらを一読してみることもおすすめです。

たとえば、アジャイルソフトウェア開発宣言に示されている原則のひとつである「全員で共通の目標に向かおう」という項目について、具体的に求められる行動規範として以下のような内容が紹介されています。

• ビジネス側の人と開発者は、全員一緒の場所で働くことを理想としましょう。
• 一緒の場所で働けない場合は、工夫して、方向性を共有しましょう。
• ビジネス側の人と開発者は、一緒にビジネスを成功に導くという共通目標を、日々確認しましょう。
• ビジネス側の人と開発者は、全員で双方向のコミュニケーションが図れるようにしましょう。
• ビジネス側の人は、要求の出しっぱなしはやめましょう。
• 開発者は、フィードバックをもらうために、頻繁にリリースをすることから始めましょう。
• ビジネス側の人と開発者は、全員が共通認識を持つために、必要最低限のドキュメントを書きましょう。

引用元：アジャイルソフトウェア開発宣言（新しいタブで開きます）

ポイント④：アジャイルは選択肢のひとつという意識を持つ

ソフトウェア開発手法には向き不向きがあり、ウォーターフォール型・アジャイル型のそれぞれに使いどころがあります。失敗を回避するにはアジャイルが流行しているからといって安易に利用するのではなく、用途に合わせて採用するという意識が必要です。
具体的には、以下のような観点を踏まえ、アジャイルで実施するべきか、その他の選択肢をとるべきか判断します。

• 要件が事前に確定しているか。また、その要件が変更となる可能性はあるか。
• プロダクトオーナーの役割を担う担当者のリソースは十分に確保できるか。また、アジャイル開発の理解があるか。
• アジャイル開発の手法だけでなく、プロセスの目的やマインドセットも含めて理解している委託先がいるか。

ポイント⑤：一体化したチームを作り上げる

プロジェクトを推進していく上では共通的な観点ではありますが、特にアジャイル開発においては心理的安全性に欠けるチームでは成果は上がりません。アジャイル開発を進める上では、チームを一体化させることが重要となります。心理的安全性を確保できるようにチーム内でお互いに尊重しあい、人格を否定しない意識を持つべきでしょう。
プロダクトオーナーと開発者は、ともすれば利害関係者ともなりかねません。プロダクトオーナーはなるべく多くの機能を作ってもらいたいですが、開発者は時間をかけて余裕をもって機能を開発したいという意識が働きます。
このような状況に陥らないために、アジャイル開発においてはチームメンバーの誠実さが求められます。チームメンバーが気持ちよく仕事ができるように、お互いを思いやり良い空気間の中で仕事ができるように心がけます。このような状況を作り出すことで、結果としてシステムの品質向上につながります。

アジャイル開発のアンチパターンを避けて成功を目指そう

この記事では、アジャイル開発に失敗する原因となる主なアンチパターンと、アンチパターンに陥らないために意識すべきポイントについてご紹介しました。アジャイル開発をうまく活用できれば、企業にとって大きな武器となります。ビジネスの高速化が求められる昨今において、新規事業開発やビジネスモデルの変化へ対応するために、アジャイル開発の活用が必要です。
当社は 2016年にエンジニア 4名が創業し、アジャイル開発・スクラム開発を大きな強みとして成長してきた企業です。エンジニア・ディレクターなどを中心に社内の多くのメンバーがスクラムマスターに必要なスキルを保持していることを証明する「Certified ScrumMaster®（CSM®）」の資格を取得しております。豊富な知見と経験、そして参画メンバーが密なコミュニケーションをとることでアジャイル開発のアンチパターンにはまらないプロジェクトの進行が可能です。
アジャイル・スクラム開発に関してお悩みやご質問がある方は、ぜひ下さい。

スパイスファクトリーのシステム開発実績

在宅医療支援機構株式会社 | 訪問看護専門総合転職支援サービス「NsPace Career」の開発

求人ポータルシステム開発

弊社スパイスファクトリーは豊富な実績を持ち、これらのプロセスを効率的に進めるためのサポートを提供いたします。

詳細を知りたい方は、こちらからサービス紹介資料をダウンロードしてください。

（新しいタブで開きます）

（新しいタブで開きます）
PoC（Proof of Concept：概念実証）としてアイデアを検証する取り組みは、多くの企業において定着化しつつあるのではないでしょうか。一方で、PoC をともに実施する会社をどのように選ぶべきか、悩まれている方もいらっしゃると思います。
そこでこの記事では、PoC の依頼先を検討されている方に向けて、会社選びのポイントや事前にやるべきことについてご紹介します。

当社では、経験豊富なエンジニアとデザイナーがワンチームとなってサービス企画のアイデア出しからプロトタイプ開発、検証後の本開発までを一気通貫でご支援しております。
詳しいサービスについては（新しいタブで開きます）からご確認ください。

PoCの概要

まず、PoC とは具体的にどのようなものなのか、改めて整理します。

PoCとは

PoC とはビジネスアイデアなどの実証を目的とした、試作開発や検証のことを指します。アイデアを具体化するためには一定の投資が必要となるため、できる限り失敗は避けなければなりません。そこで、PoC により想定している仮説の正しさや、技術的な実現可否を検証します。これにより、アイデアの妥当性を低リスク・低コストで確認できます。
PoC の詳細については、こちらの記事（新しいタブで開きます）もご覧ください。

https://spice-factory.co.jp/design/what_is_poc/

PoCの種類

PoCには大きく分けて2つの種類が存在します。

①既存のサービスの課題を改善するためのPoC

ひとつは、既存サービスの課題を改善するための PoC です。たとえば「ユーザビリティを向上させる」ことを目的として PoC を実施するようなケースがこれに該当します。
この場合、まずヒアリングなどにより現状のサービス課題を分析し、その結果に基づき本番に近い形でプロトタイプ（新しいタブで開きます）を構築します。プロトタイプを評価することで、想定している方針で課題の改善ができるかを検証できます。

②0→1でサービスを開発するにあたり、アイデアを検証するためのPoC

もうひとつは、新サービスの開発を行うケースです。PoC により正式な事業化判断の前に市場ニーズや技術的な実現性を測ることで、事前にサービスの成否やリスクを予測できます。
このケースでは、事業化の成否やリスク測定がPoCの目的となります。よって、具体的な機能要件まで踏み込まない形でプロトタイプを構築することも多いです。

PoCの費用

サービス内容や開発期間にもよりますが、一般的にPoCの予算相場は数百万円程度となります。すでに構築しているものをカスタマイズして開発する場合は、費用が安くなる場合もありますし、0から開発を行う場合は、これより高くなる場合もあります。
一般的なPoC費用についてはこちらの記事（新しいタブで開きます）もご覧ください。

https://spice-factory.co.jp/design/poc_planning/

PoC費用の変動要素となるポイントは以下の2つです。

成果物の種類

ひとつは成果物の種類です。ペーパーレベルで成果物を作る方法、デザインツールを利用して動作するプロトタイプを作る方法、システムとしてプロトタイプを実装する方法など、プロトタイプにはいくつかの種類があります。
PoC の目的によってどのレベルまでの成果物を作るべきかは異なります。たとえば、手戻りを避けるためにもアイデアの初期検証段階ではペーパープロトタイプを、アイデアが固まってきたらサービスの機能やニーズの検証としてデザインツールを用いてプロトタイプを制作。リアルな挙動や動作により実現可能性を図る必要性がある場合はシステムで実装するプロトタイプを選択するなど、目的から落とし込んで適切な成果物を決定していきます。

成果物のスコープ

もうひとつは成果物のスコープです。当然ながら、多くの機能を対象とした PoC を行う場合は費用が上がります。
また、検証規模も費用の変動要素です。インタビューの対象者を増やして多くの情報を収集したり、検証回数を増やしたりすると、その分費用がかかります。

PoC実施を外部に依頼すべきケースとは

PoC の実施に当たり、外部リソースを活用するか社内で対応すべきか悩まれる方は多いのではないでしょうか。ここでは、外部リソースへの依頼可否を判断する観点をご紹介します。

本当にPoCを外部に依頼すべき？

PoC は自社で行うことも可能です。たとえば、業務フローを再検討したうえで、実際に業務に適用してみて検証を行うような PoC であれば、自社のみで十分実施できます。
このように、自社リソースだけで PoC のサイクルを回せる場合は、必ずしも他社リソースを利用する必要はありません。

外部に依頼すべきケース

一方で、PoC の対象がシステムやアプリである場合は、外部リソースの活用も検討すべきです。特に、自社にエンジニアやデザイナーがいない場合は、プロトタイプ制作フェーズでは専門知識のあるプロに作ってもらった方がベターです。
また、第三者視点で課題の発見をしたい場合、外部の視点を入れるという選択肢もあります。新規サービス開発など、0→1 で検証する際などは、多様な視点を取り入れることが重要です。
その他、以下のようなケースに当てはまる場合は、社外への依頼を検討すべきといえるでしょう。

• アイデアはあるがシステム実装も含めて詳細化の方法が整理できていない
• 投資判断がつきにくく、外部の意見を入れたい
• システムの機能追加が適切か分からない
• 機能を追加した際にうまくユーザーが利用できるか不安がある

（新しいタブで開きます）

会社選びの前に整理すべきポイント

PoC の成否は会社選びの時点でほぼ決まるといっても過言ではありません。「とりあえず会社を選ぶ」というスタンスは非常に危険です。
まずは、自社でプロジェクトに関する理解度を上げ、会社に求める要件を洗い出すべきです。具体的には以下を整理します。

課題の整理

課題の整理は最初に着手すべきポイントです。通常、PoCの目的や目標は課題から導かれます。担当者の意見はもちろん、なるべく多くのステークホルダーにヒアリングすることで多角的に情報を集めることができます。
洗い出した課題から、重要度・緊急度などの観点で優先度を定め、どの課題が最も解決すべきものかを整理します。

目的・目標の決定

課題を踏まえ、PoC の目的や目標を定義します。たとえば、PoCの目的がビジネスコンセプトの定義か、実装を通したサービスのニーズ検証なのかで PoC の方向性は大きく異なります。目的や目標はプロジェクトの大方針となるので、社内で十分に議論したうえで決定すべきポイントです。

期限・予算の整理

これらの目標を達成するため、いつまでにどれくらいのコストをかけられるか、期限や予算を決定します。これらは会社の選定にあたって候補先の各社から必ず聞かれるポイントです。また、期限・予算により検証できる範囲も変わります。

本番開発を見通した会社選定

PoC に成功した場合、PoC を実施した会社にそのまま本番開発も依頼することで、コスト削減やスピード感を持った対応ができます。よって、PoC の依頼を行う際には本番開発の可否まで見通したうえで依頼すべきです。本番開発を実施するためには、十分なエンジニアが在籍していることや開発経験の豊富さなどが選定条件となります。
加えて、PoCフェーズからエンジニアが参加することで、実現可能性を考慮したプロトタイプの制作や検証が可能です。これにより、その後の円滑な開発につなげやすくなります。

役割分担の明確化

役割分担の整理は、PoC に限らず外部リソースを利用する際の必須事項です。役割分担により、PoC 実施にかかる費用や体制が変わってきます。
たとえば、自社にエンジニアが在籍しているものの、デザイナーはいない場合、デザイナーリソースのみ外部に委託することも検討できます。この場合、エンジニアリソース分の外部委託費用が削減できますが、社内でアサインすべきメンバー調整など体制の構築も必要です。

PoC実施を依頼する会社を選ぶポイント

次に、自社にマッチしたパートナー企業の選定に必要なポイントを紹介します。

料金・期間

想定する予算内に収まるかは選定の大きな軸となります。委託先候補に対する最初のヒアリングで予算感を相談してみることをおすすめします。
また、事前に想定していた実施期間についても、現実的なものであるか委託先候補に確認してみるとよいでしょう。特に、システムの実装には想定していたよりも長い期間が必要となるケースもあります。

実績と業界・業務知識

実績は各社の力量を測る大きなポイントとなります。特に、自社と同じ業界や類似するサービスに関する実績の有無が重要です。委託先に事業やサービスへの理解があれば、プロジェクトはスムーズに進みやすくなります。
PoC は単にモノづくりを行うのではなく、ビジネスの成長や成功を目的として行われるものです。ビジネスに資するPoCを実現するためには、業界やサービス、ターゲットなどの理解度が重要となるでしょう。

対応可能範囲

各社がどこまでの作業範囲に対応できるかも確認すべきポイントです。たとえば、デザイナーは一般的にデザインツールを用いて動作するプロトタイプの作成は可能ですが、実際にシステムとして動作する実装済みのプロトタイプの制作は難しくなります。実際の動きをプロトタイプで検証したい場合や、その後の実装までサポートしてほしい場合には、エンジニアリング力を持った会社を選ぶべきでしょう。
弊社では、PoC の目的に応じてデザイナー・エンジニア・マーケターなどからチームを構成します。これにより、たとえば figma などのデザインツールベースでプロトタイプを作成しつつ、動作を確認したい箇所については一部 html や CSS を使用して実装するような対応も可能です。
また、各社のスキルがプロジェクト目的に合っているかも確認します。たとえばユーザーニーズの把握が重要となるプロジェクトの場合、UX知見を活かしたユーザーインタビュー、ユーザビリティテストなどの経験がある会社を選定します。

弊社の実績

以下では、PoCプロジェクトのイメージをお伝えするために、弊社の事例を2つご紹介します。

本田技研工業株式会社様の事例

まず紹介するのは、本田技研工業株式会社様の事例です。当社では、同社の新規事業の構想段階における市場ニーズの把握を目的とした PoCプロジェクトを支援しました。本事例では、プロトタイプ開発とリサーチまでトータル2ヵ月で進行。ユーザーの導線まで作りこんだプロトタイプにより、想定ターゲットから具体的なフィードバックを収集するなど、検証精度の向上に寄与する取り組みを行いました。
本事例の詳細については以下をご覧ください。

事例：本田技研工業株式会社様｜PoC支援（新しいタブで開きます）

株式会社NTTデータ関西様の事例

もうひとつ紹介するのは、株式会社NTTデータ関西様の事例です。同社では、マイナンバーカードの交付予約・管理サービスである「e-TUMO MYNUM」を展開されていますが、本サービスは比較的古くに開発されたものであることから、UI/UX 面に課題がありました。
そこで当社では、UI/UX改善策の提案とプロトタイプの構築を実施。同社内での評価会などを通してプロトタイプを紹介し UI/UX改善の価値を伝えるなど課題解決に向けたアクションを実践しました。
本事例の詳細については以下をご覧ください。

事例：株式会社NTTデータ関西| 個人番号カード 交付予約・管理サービス「e-TUMO MYNUM」のUI・UX改善（新しいタブで開きます）

自社での対応が難しければPoCのプロから支援を受ける検討を

この記事では、PoC の依頼前の整理事項や、依頼先となる会社選びのポイントなどについてご紹介しました。
スパイスファクトリーでは、PoC から本開発までの一気通貫支援や、最短2か月での PoC 実施が可能です。弊社の詳しいサービス内容は（新しいタブで開きます）をご覧ください。
PoCやシステム開発、新規ソフトウェアの開発についてお悩みがありましたら、ぜひ（新しいタブで開きます）ください。

https://spice-factory.co.jp/service/prototype/

 

DX（デジタルトランスフォーメーション）に取り組む企業は増えていますが、思うように進まず導入フェーズで止まってしまう例が後を絶ちません。

特に日本ではシステムだけを先行導入し、現場の混乱や活用定着の失敗に直面するケースが目立ちます。

DXの失敗が事業継続を左右するリスクになることも少なくありません。「現場に浸透しない」「思ったような成果が出ない」「どこから見直せばよいか分からない」と悩む企業にとって、対応の遅れは深刻な課題です。

本記事では、「FastDX」という独自のアプローチで、スピードと実行性を両立したDX推進を提案するスパイスファクトリーが、DXが失敗に陥る理由とそこから脱却するための実践的な戦略を解説します。

DXの2025年の現状

社会全体のデジタル化は現在でも急速に進んでいます。スマートフォンの普及、オンラインサービスの浸透、キャッシュレス決済や宅配インフラの高度化など、消費者の“当たり前”はすでに大きく変化しています。

一方、企業の業務やサービス提供の現場では、いまだに紙やExcelベースの手作業が残り、顧客接点や業務プロセスのデジタル化が追いついていないケースが少なくありません。このギャップが、顧客満足度の低下や人材流出、さらには競争力の低下につながっていきます。

多くの企業が「DX（デジタルトランスフォーメーション）」という言葉を掲げていますが、実際にはPoC（実証実験）や単発的なツール導入にとどまることも少なくなく、全社的な構造改革には至っていないことも多くあります。

こうした状況に対し、経済産業省は早くから「2025年の崖」として警鐘を鳴らしてきました。2018年に発表された「DXレポート」では、老朽化した基幹システムが刷新されないまま2025年を迎えると、年間で最大12兆円の経済損失が発生する可能性があると試算されています。

システムの老朽化・複雑化だけでなく、それを担う人材の高齢化や属人化も深刻です。また、昨今のAI技術の急速な進化や民主化により、ビジネスにおけるテクノロジーの活用と定着がより重要視されてきています。

DXの取り組みがうまくいっている企業はごくわずか

日本企業においては、デジタル化や業務効率化に取り組む企業は増えていますが、DXの本質である新たな製品・サービスの創出や企業文化・ビジネスモデルの変革にまで踏み込んでいる企業は多くありません。

IPAの「DX動向2025」によると、2024年時点で新規製品・サービスの創出と企業文化や組織マインドの変革においてすでに十分成果が出ていると回答した企業の割合は、日本・アメリカ・ドイツで大きく異なります。

	日本	アメリカ	ドイツ
新規製品・サービスの創出	4.1%	26.8%	19.1%
企業文化や組織マインドの根本的な改革	4.7%	27.4%	16.7%

日本において、DXの本質的な取り組みがうまくいっている企業は5％以下とごくわずかです。これらの理由として、日本ではコスト削減や効率化といった「守りのDX」への偏重や、全社的な変革ではなく部分最適に偏る傾向が多いと指摘されています。

DXの成功に欠かせない戦略の立案方法については、関連記事をあわせてご覧ください。

参考：IPA「DX動向2025」（新しいタブで開きます）

関連記事：DX戦略の立て方とは？立案方法や成功のポイントを事例も交えて徹底的に解説！

DXが失敗する理由

DXに取り組む企業は増えていますが、なかなか思うような成果が出ていません。なぜDXは失敗してしまうのでしょうか。実はいくつかの共通点があります。

ここでは、「DX動向調査2025」を参考に、失敗の要因として挙げられることの多い5つのポイントを見ていきましょう。

経営陣のコミットメント不足

DXを推進するために欠かせないのが、経営層の明確な意思と継続的な関与です。しかし実際には、DXをIT部門や現場に任せきりにし、経営層が十分に関与していないケースが少なくありません。

DXに成功した企業は明確なビジョンを示すだけでなく、社内に浸透させるための行動指針まで示しています。現場任せの状態では、社内に根付かず形だけの取り組みで終わるリスクが高まります。

失敗を防ぐには、経営陣自らが方針を示し現場との対話が重要です。

DX化の目的が明確でない

DX推進が形だけで終わる背景には目的の不明確さがあります。社内で何を目指すのかが共有されていなければ、システムも施策も十分に活かせません。
IPAの調査でもDXの取り組みを業務効率化にとどめている企業が多く、価値創出やビジネスモデル変革には至っていないのが実情です。
DXを成功させるには、明確な目的を掲げ、組織全体で共通認識を持たなければなりません。

人材と資金不足

DXを進めるには、専門的なスキルを持つ人材の確保や継続的な投資が必要です。しかし、「DX動向調査2025」では52.7％の企業が「人材の確保・育成」を課題として挙げており、多くの企業が人材不足に悩んでいることがわかります。

社内にDXを推進できる人材がいなければITベンダー任せとなり、内製化や現場主導の改善が進みにくくなります。

DXは一度導入して終わりではなく、継続的な改善と見直しが必要です。中長期的にリソースを確保し、安定して推進できる体制づくりが求められます。

レガシーシステムが壁になっている

老朽化した基幹システムが足かせとなり、新たな仕組みやサービスの導入が進まないという声も少なくありません。とくに、長年使い続けたカスタマイズシステムを抱える企業は移行のハードルが高く、変革を後回しにしがちです。

レガシーシステムが複雑で全体像が把握できない場合や属人化していて誰も手をつけられない状況などが、DXを阻む要素となります。

刷新にあたっては、現場からの反発や一時的な業務停止というリスクが伴いますが、将来の成長や持続的な競争力のために乗り越えなければなりません。

データ活用ができていない

多くの業務がデジタル化される今、DXの要ともいえるのがデータ活用です。しかし、データを蓄積しても、分析や業務改善に活かせていない企業は少なくありません。

各部門でデータが分断されていたりリアルタイムでの活用が難しかったりと、基盤整備が追いついていない状況です。

DXで成功させるには、全社横断でデータ活用体制の構築が欠かせません。自治体のDX成功事例については、関連記事をあわせてご覧ください。

関連記事：自治体DXの事例紹介 成功につなげるポイントとは？

DX失敗から成功に導くポイント

DXが失敗に終わる企業が多い一方で、確実に成果を出している企業も存在します。両者を分けているのは、人材と資金力の差が大きいといわれていますがそれだけではありません。DXを進めるうえでの考え方や進め方にも、大きな違いがあります。

ここでは、DXを成功に導くための実践的なポイントを8つ紹介します。

アジャイルを採用する

DXを成功させるには試行錯誤が欠かせません。柔軟に改善を進めるためには、従来のウォーターフォール型ではなく小さく試しながら素早く見直すアジャイル開発が効果的です。

フィードバックをすばやく反映できるので、現場の意見や課題を取り入れやすくなります。

関連記事：アジャイル開発がこれからのDX推進に必要な理由とは？活用するメリット・デメリットを解説

顧客視点の強化

システムや仕組みの導入が目的化してしまうと、期待した効果にはつながりません。社内の業務効率化だけに目を向けるのではなく、顧客にどんな価値を届けられるかという視点が求められます。

サービスやプロダクトが実際にユーザーにどう使われ、どのような課題を解決しているのか見極めましょう。常に顧客視点で評価し改善を重ねていくと、本質的な価値を提供できます。

経営層がコミットする

DXを全社的に推進するには、経営層の積極的な関与が欠かせません。現場任せではなく、トップが方向性を示し具体的な指示を出すことで組織全体の動きが加速します。

さらに、経営層と現場が対話を重ね、課題や進捗を共有しながら進めることもDXを組織全体に根付かせるうえで重要です。

DXのビジョンをしっかり持つ

DXは単なるIT導入ではなく、企業の在り方そのものを見直すための取り組みです。実現するには、目先の業務改善にとどまらず、中長期的なビジョンが求められます。

企業の方向性やDXで実現すべき目的を明確にすると、現場の判断や行動にも一貫性が生まれます。

KPIの明確化

DXは具体的な成果や効果が見えにくいので、「結局どんな効果があったか分からない」と思われがちです。進捗や効果を客観的に把握するには、KPIの設定が欠かせません。

業務効率の向上、顧客満足度の改善、新たな事業の創出など、目的に応じた評価軸を定めておくと現状とのギャップが把握しやすくなります。設定したKPIは定期的に見直し、必要に応じて現場へフィードバックしましょう。

人材育成

DXを定着させるにはツールだけでなく、活用できる人材が欠かせません。専門性の高い領域や初期段階では、外部に依頼する方法もあります。しかし、現場ごとの課題に即した迅速な対応や社内文化の反映、継続的な運用には、自社での人材育成が大きな効果を発揮します。

ITスキルに加えて課題を見つけ改善する力や部門間の連携など、DX推進に必要なスキルを身につけた人材を育成しましょう。人材育成によってDXのノウハウを社内に蓄積できる点も大きなメリットです。

データ活用

DXは業務改善にとどまるものではありません。その本質は、蓄積されたデータを活かした新たな価値の創出や企業文化の根本的な変革です。しかし、多くの企業でデータが活用されず埋もれたままになっています。特に、部門間同士でデータをやりとりする仕組みが整備されていないため、活用が進まないケースも目立ちます。

データを最大限に活用するには、一元管理やリアルタイム性の確保に加え、部門をまたいだ利活用体制の構築が欠かせません。また、蓄積されたデータを分析・活用するには、データアナリストやデータサイエンティストなどの専門人材も求められます。

AI・生成AIの導入

近年注目を集めている生成AI技術の導入も、DX推進につながります。業務の自動化や分析の高度化、顧客対応の効率化など、さまざまな場面で活用可能です。

AI技術の活用には、セキュリティ対策に加えルールや運用体制の整備が必要です。意図した成果を得るには、明確なゴールを設定し検証しながら段階的に進めていきましょう。

DXを新規事業に取り入れる方法については、関連記事も参考にしてください。

関連記事：DXを新規事業に取り入れるには？事例に学ぶコストをおさえて小さくはじめる方法

成果につながる DX 『FastDX®』とは

それでは、成果につながる DX を実現するためにはどのような考え方が必要なのでしょうか。当社では結論として、上述した DX の失敗原因を避けるために、できるだけ「開発しない・小さく作る」DX を目指すべきだと考えています。

最近では、多くの企業にとって共通的に必要となる仕組みは、SaaS などの形でサービスとして提供されるようになりました。たとえば、営業 DX やマーケティング DX を実現しようとした場合、SFA や MA などの利用が有効です。

これらは SaaS の形態でさまざまな製品が提供されており、手軽に利用することができます。

また、データ活用を見据えて自社に ERP を導入するケースにおいても、すでに大企業向け・中小企業向け含めて、さまざまな製品が SaaS の形で提供されています。

このように、DX の活動を実施していくうえで必要となる仕組みの多くは、すでに存在するものが利用できます。これらを組み合わせ最大限活用することが、効率的な DX 実現につながります。

そして近年では、生成AI（ChatGPTやClaude、GeminiなどのLLM）を組み合わせることで、SaaSだけでは難しかった“人に依存した判断・思考業務”にもデジタル変革の波が広がり始めています。また、SaaSそのものにAI機能が導入されているケースも少なくありません。

当社では、このように SaaS や CMS など既存の最新プラットフォームを最大限活用した開発を行うことで、素早いデジタル変革を実現する手法をFastDX®（新しいタブで開きます） と定義しています。（FastDX® はスパイスファクトリー株式会社の商標登録です。）

FastDXのユースケース

まずは「FastDX」で具体的にはどんなことができるのか、イメージを深めていただくためにユースケースをご紹介します。

HubSpot × Shopify × LINE

たとえば、Hubspot×Shopify×LINEミニアプリによる OMO（Online Merges with Offline）（新しいタブで開きます）実現もその一つです。

HubSpot の CRM・MA 機能から得られる顧客データや、Shopify で構築した EC や ShopifyPOS から得られる購買データ、LINEミニアプリの会員証データなどを活用します。

Shopify で構築した EC 上の顧客の購買情報を CRMツールである HubSpot と連携します。これにより、EC上での購買データや会員情報を HubSpot で管理できるようになり、そのデータに基づいて条件を決めてメール等でパーソナルなオファーをしたり、MA の機能でそれらの送信を自動化することが可能になります。

さらに、HubSpot と LINE を連携することでよりできることが広がります。メール同様のキャンペーン連絡やオファーを顧客の LINE に送ることが可能になることはもちろん、LINEミニアプリで会員証機能などを使えば、リアル店舗での購買データも HubSpot CRM に統合することができます。

リアル店舗も含めた顧客の行動データに合わせた1to1のメッセージやオファーを、LINE やメールを使って自動化するような仕組みを構築することで、OMO の実現が可能となります。

ETLツール × Data Portal・BigQuery

HubSpot などの CRM情報や Shopify 等で構築した ECサイトの購買データ、LINEミニアプリで取得できる顧客の行動やコミュニケーションデータは、Google Data Portal および BigQuery を利用して統合・可視化が可能です。

ETLツールにより各ツールから BigQuery にデータを集約し、Data Portal でグラフ化や集計などを行って可視化します。

以上のように、FastDX では複数のツールを連携させることによって、それぞれのツールで得られる顧客の情報を統合して活用できます。

さらに統合したデータを分析することで事業やプロダクトの課題を把握したり、顧客により良い体験を提供するために必要な情報を得ることが可能になります。

FastDXの効果

FastDX の実践によりどのような効果が得られるのでしょうか。上述した「主な DX の失敗原因」を踏まえて解説します。

スクラッチ開発と比較して低コスト

とくにスクラッチで開発を行う場合、システムのコストは高くなりやすいといえます。FastDX の考え方に基づき、SaaS をはじめとした既存プラットフォームを利用することで、コストを低く抑えて DX の取り組みを進めることができます。

スクラッチでのシステム開発には時間と人手が必要ですが、FastDX により開発を最小化し期間を短縮することで、社内リソースが開発に拘束される期間も短くなり、プロジェクト推進に必要な業務負担も減らせます。

攻めのDXへのリソース投下

上述のように、FastDX はスクラッチ開発に比べてコストやリソースが少なく済むことが期待できます。結果として、開発や施策の実行スピードの上昇にも寄与します。

節約できたリソースやコスト、時間は、顧客体験の向上や新たなビジネス的な価値を生みだす「攻めのDX」の取り組みに投資できるようになります。

可能な限り多くPDCAサイクルを回し、サービスアイデアや施策の検証と改善を行えるかどうかが「攻めのDX」、ひいては企業の DX そのものの成否を分けるでしょう。

人材の流動的な活用と育成

FastDX は多くの企業が抱えるIT人材の不足に対しても効果的なソリューションになり得ます。FastDX で活用する SaaS ツールの多くはプログラミング等が不要なノーコード、または簡易な知識があれば使用可能なローコードのツールです。

システムの関係性やデータの扱い、各ツールの仕様や操作方法などの理解は必要ですが、プログラミングなどの専門知識やスキルは最小限で利用できる場合も多いでしょう。つまり、エンジニアの関与を少なくでき、マーケターや営業担当など、ビジネスサイドの社員でもプロジェクトを推進できる余地が大きくなります。

ビジネスサイドの社員でも運用が可能となれば、プロジェクトの参画メンバーの候補は大きく広がるでしょう。一方で、最小限とはいえ IT の専門知識に触れたり学んだりする機会も発生するため、FastDX プロジェクトを自社におけるデジタル人材の育成機会と捉えて活用することも考えられます。

失敗の影響を最小化

FastDX により、仮に取り組みに失敗したときにも影響を最小化できます。

SaaS などのツールでは月額料金など利用料の形で課金されることが一般的です。よって、スクラッチ開発と比較して初期コストが抑えられます。契約を開始すればすぐに多くの機能が使えるようになるため、取り組み実施までのスピードについてもスクラッチ開発より速くなる傾向があります。また、取り組みの中断も行いやすいというメリットも得ることができるでしょう。

上記の特徴は、仮に取り組みに失敗してしまったときの早期撤退を可能にします。初期コストを抑え、PoC 等の検証をスピーディーに行えることで、失敗のリスクを軽減できます。
リスクが小さくなることで、失敗を許容するハードルも下がります。社内における失敗を許容する文化の醸成を行いやすくすることが期待できます。

ベンダーへ依存しない取り組み

FastDX の手法により、各 SaaS プラットフォームを最大限活用することで、結果として特定のベンダーへの依存度は下がります。

基本的に、各種プラットフォームの活用にあたっては初期設定やデータ登録などの作業が中心です。機能カスタマイズも最低限に抑えることで、できるだけ開発しないようにします。

これにより、将来的なシステムのブラックボックス化やベンダーロックインを避けつつ、取り組みのスピード感向上や柔軟な対応につながります。

FastDXの実現に必要な要素

スパイスファクトリーでは、2021年より FastDX Division を設立し、FastDX の取り組みを進めてきました。この章では当社が考える FastDX でのプロジェクト成功に必要な要素をご紹介します。

アジャイル型のプロジェクト進行への理解と心構え

当社では、SaaSツールの活用だけではなくスクラッチ開発でも多数の実績があります。最初から大規模なシステムは作らずに、プロトタイプや MVP を活用してスモールに仮説の立案と検証を実施しながら進めていく「アジャイル開発」のプロジェクトを得意としており、この知見やマインドが FastDX の取り組みにも重要であると考えます。

本記事でご紹介してきたように、DX推進で成功をおさめている企業には「失敗を恐れない・許容する」文化が根底に必要です。表面的な取り組みだけではなく、実際に失敗しても、めげずに次の仮説検証に取り掛かる本質的な取り組み姿勢が求められます。

そのため当社では、クライアントと伴走してプロジェクトを進めることで、アジャイルな価値観やプロジェクト運営の方法をクライアント企業様にインストールすることも重視しています。

最新のプラットフォームに精通

当然ではありますが、FastDX 実現のために使用する最新のプラットフォームに精通していることも重要です。実現したいことや、仮説の実証に必要な最適なツールの選択肢を考える必要があります。

各種プラットフォームの導入にあたっては、業務やビジネスに最大限活用できるように、各サービスの特徴や効果的な使い方をおさえましょう。SaaSツールは日々アップデートされていきますので、これまでできなかったことが機能追加で急にできるようになったり、設定が容易になったりといったことも多く発生します。

また、FastDX の実現には使用するツール同士を連携させる必要があることも頻発します。既存機能として他ツールとの連携が容易になっている製品もありますが、そうでない場合は API による連携をする必要があり、API 連携を構築できる人材がいることも重要です。

社内に使用する各ツールや連携に詳しい人がいれば問題ないですが、すでに述べているように IT 人材の不足は多くの企業が抱える課題です。社内にいない場合はツールの運営元から最新の情報を得たり、当社のような複数のツールに精通している企業のサポートを受けることで、短期的にカバーをし、中期的に人材を育成し、社内に知見を貯めていくのも一つの方法です。

UI/UX・マーケティングなどIT以外の観点

FastDX がいかに有用であったとしても、ツールや仕組みを導入しただけでは DX が上手くいかないことはみなさんも同意いただけるのではないでしょうか。ビジネスの成功の鍵を握るのは、ITスキルやツールの理解だけではないからです。
そもそも、提供しようとしているサービスや商品が顧客にとって魅力的でなくてはどんなシステムも宝の持ち腐れです。

顧客が本当に価値を感じるものを検証するには UX（User Experience）リサーチやマーケティングリサーチのノウハウがあると優位ですし、実際に魅力を感じてもらうにはデザインやブランディングなどの要素も大きな影響を与えます。
MA や CRM を適切に使って価値を顧客に伝えるためには、マーケティングや営業の知見も必要です。

• 「失敗を恐れない」アジャイルなメンタリティ
• ITツールに関する知見やスキル
• ビジネスや顧客に対する解像度の高さ

上記が DX プロジェクトの成功には必要な要素だと考えています。

関連記事：UIとUXの違いとは？顧客体験が変わる設計と成功事例

DXの失敗要因を理解して成功確率を上げる選択をしよう

今回は、DX が失敗する原因を踏まえつつ、それらを解消することができる FastDX という考え方を紹介しました。

DX の取り組みを開始したものの、うまく成果につながらず失敗してしまった企業は多いのではないでしょうか。一方で、DX の実現は急務であり、今後もその重要性は変わりません。次こそ DX に成功したいと考えている企業において、FastDX は有効な選択肢であると自負しています。

FastDX による DX について、もう少し詳しく知りたい場合は無料で相談を受け付けております。DX の推進に悩まれている方は、ぜひ（新しいタブで開きます）ください。

（新しいタブで開きます）

アジャイルなシステム開発、デザイン、ブランディング、マーケティングを得意とし、全方位から企業のDXを支援するスパイスファクトリー株式会社です。
ユーザーにとって使い慣れた LINEアプリ上で利用できることから、インストールの障壁が低い LINEミニアプリ。
スマホアプリをゼロから開発するのに比べ、コストをおさえた導入が可能な場合もあり、店舗ビジネスを中心に様々な用途で活用できます。一方で、スマホアプリと比較してまだ情報が少なく、LINEミニアプリの開発方法や機能などについて知りたいという方も多いのではないでしょうか。
そこでこの記事では、LINEミニアプリで実現できることや、LINEミニアプリを使った DX の推進方法について紹介します。

LINEミニアプリ（LINE mini app）とは

LINEミニアプリとは LINE 社が提供するサービスのひとつで、LINE 内で店舗や企業のアプリを個別に提供できる仕組みのことです。
LINE のユーザー数は2022年6月末時点で月間9,200万人※であり、多くの方はスマートフォンの中に LINEアプリをインストールしている状況にあります。

一般に普及している LINE のプラットフォームを利用することで、自社や自店舗のアプリを多くのユーザーに届けやすくなるというメリットがあります。

LINE アプリは、メッセンジャー機能をはじめとして決済やショッピング、証券など複数の機能を統合したアプリです。このようなアプリのことをスーパーアプリと呼びます。
ミニアプリはスーパーアプリの中の1つの機能としてアプリケーションを提供することができるもので、LINEミニアプリはスーパーアプリである LINE アプリの中で動くWEBアプリの位置づけです。
スーパーアプリやミニアプリについては以下の記事で詳しく解説していますのでよろしければ参照ください。
スーパーアプリ・ミニアプリとは？企業が活用するメリット・最新事例をご紹介（新しいタブで開きます）

※参考：ユーザー数はLINE社「LINEBusiness Guide」2022年10月～2023年3月期版より

LINEミニアプリの機能

LINEミニアプリを導入することで、店舗向けを中心とした以下のようなサービスを提供できます。

• • デジタル会員証
    店舗や施設の会員証を LINEミニアプリ上で発行。店頭オペレーションの効率化やリピーター獲得施策などに活用できる。また、ポイントシステムの提供も可能。

 

• • デジタルクーポン
    利用者に対して LINEミニアプリ上でクーポンを発行することで、来店促進などのマーケティング活動に利用できる。

 

• • モバイルオーダー・テーブルオーダー
    店舗外や店舗内からオーダーを受け付け、同時に決済処理も実施。店舗オペレーションの効率化につなげる。

 

• • テイクアウト・デリバリー
    テイクアウトやデリバリーの注文や決済機能を提供。ユーザーの待ち時間の削減にも効果がある。

 

• • 順番待ち受付
    混雑時、LINEミニアプリから順番待ちを登録できるようにすることで、ユーザーの利便性提供とともにオペレーションの効率化を行う。

 

• • 来店予約
    美容室や飲食店などにおいて、来店予約を行う機能を LINEミニアプリ上で実現できる。

 

• • 商品カタログ
    自社の商品カタログを LINEミニアプリ上で提供。購買の促進につなげる。

 

LINEミニアプリでできること・解決できる課題

前述の通り、多くの機能を実装できる LINEミニアプリですが、導入することによりビジネスでどのような成果を得られるのでしょうか。
以下では、LINEミニアプリにより実現できることや、解決できる課題など、得られるメリットについて紹介します。

店内の混雑解消

LINEミニアプリにより来店予約や順番待ち受付を実現することで、店舗内でお客さまに待っていただく必要がなくなります。
これにより、お客さまへの利便性を提供し、店舗の混雑により待ち時間を嫌がったお客さまが離脱してしまうという課題の解決が見込めます。

フロアスタッフの業務負担軽減

LINEミニアプリでテーブルオーダーを実現することで、注文の聞き取りを効率化。聞き間違いによる注文のミスも減らせます。
また、来店予約や順番待ち受付を LINEミニアプリで提供すれば、電話予約対応業務も不要に。

店舗でのお客さまの整理や呼び出し業務も不要となるため、店舗オペレーションの効率化という観点でも効果的です。

ユーザーとのコミュニケーション実現

LINEミニアプリでは、LINEの登録情報を利用してデジタル会員証を作成できます。
これにより、会員証の作成時にもお客さまの手間を減らすことができます。

デジタル会員証を導線に、店舗に訪れたユーザーに ECサービスへの誘導を行うことも可能になります。反対に、ECユーザーには家の近くに実店舗が存在することをお知らせし、クーポンなどを配布することで実店舗に誘導することもできます。このように、オンラインとオフラインを融合して顧客へ新たな体験を提供する、いわゆる OMO（Online Merges with Offline）（新しいタブで開きます）施策としても活用可能です。

リピート率の向上と新規顧客の発掘

デジタル会員証やクーポンの配布などにより、リピート率の向上につなげることもできます。さらに、LINEミニアプリでは上述した OMO の視点により、実店舗で商品を購入したお客さまを ECへ誘導しリピーター化したり、その反対に EC から入ったお客さまを実店舗に誘導したりするようなことも期待できます。オンラインとオフラインの垣根を越えたシームレスな体験を実現可能です。
一般的に実店舗はオンライン上と比較して内装や照明、音響などでブランドイメージを伝えやすいため、顧客のロイヤルカスタマー化などを見据えた取り組みにつなげることも可能でしょう。
また、LINEミニアプリの「インストールしやすい（新規のアプリダウンロードが不要）」という特徴は、新規顧客の獲得にもつながるでしょう。

スマホアプリとの比較

BtoCビジネスにおいて顧客との接点を確保し、様々な取り組みを実施する場合の選択肢としてまず思いつくのはスマホアプリの導入ではないでしょうか。スマートフォンアプリと LINEミニアプリを比較した場合、どのような違いがあるか、以下で解説します。

• • コスト・開発期間
    上述した通り、LINEミニアプリの大きなメリットとして開発工数の削減ができる場合があることが挙げられます。プラットフォームとしてよく使われる機能はパッケージで提供されているものもあるため、パッケージの利用であれば個別で開発する必要がありません。結果として、開発にかかるコストや開発期間をおさえることができるのです。一方で、個別開発と呼ばれるパッケージを使用せずに一から LINEミニアプリを開発し、導入する方法も存在します。この場合、実装したい機能要件にもよりますが WEBサービスを開発するのと同程度の費用と期間が発生します。

 

• • 機能
    機能面の自由度はスマホアプリに軍配が上がります。LINEミニアプリでは機能がプラットフォーム（LINE）に依存するため、たとえばヘッダーの UI は自動生成されたものがベースとなるなど、一部で制約があります。ただし、LINEミニアプリは HTML5 のほぼすべての仕様をサポートしているため、一般的な Webアプリの機能であれば LINEミニアプリでも実装できる場合がほとんどです。

 

• • ユーザーのアプリ導入障壁
    ユーザーがアプリを利用する際の障壁の低さは、LINEミニアプリの大きなメリットです。LINEミニアプリのユーザーはアプリを利用し始める際に、個別にアプリストアなどからダウンロードしインストールする必要がありません。（LINE アプリがインストールされていることが前提）また、多くのサービスの利用開始時に求められる名前や連絡先などの入力においても、「LINE Profile+」機能により、LINE に登録されている情報を流用できるというメリットがあります。

 

• プラットフォーム依存リスク
  LINEミニアプリ、スマホアプリいずれにおいても注意しなければならないのが、プラットフォームへ依存することにより発生するリスクです。プラットフォーム提供者の都合により、仕様の変更や機能のアップデートが行われるため、これらに都度対応していく必要があります。

ここまでの内容を整理すると、下表のようになります。

表で整理したとおり、ユーザーにとっては手軽に、かつ事業者にとっては比較的低コストから導入できるのが LINEミニアプリのメリットといえるでしょう。一方で、様々な独自機能を柔軟に構築したい場合は通常のスマホアプリとしての開発も検討できます。当社では、アプリ開発フレームワーク Flutter を活用したスマホアプリ開発を得意としておりますので、もしご興味があればこちらのリンクから詳細をご覧ください。

（新しいタブで開きます）

LINEミニアプリを使った事例

以下では、LINEミニアプリを活用した主な事例を紹介します。

東急株式会社

東急株式会社では、コロナ禍による通勤需要の減少を乗り越えるべく、DX を推進しています。その中で、LINEミニアプリを活用した取り組みを実施。通勤定期利用者を対象とした新しい働き方を支援するサービスや、渋谷の各店舗で利用できるモバイルオーダーシステムを提供しています。また、LINEミニアプリを通して様々な行動データを収集することで、新たな取り組みへの活用も進めています。

引用・参照：LINEミニアプリ公式の事例ページ

株式会社カネボウ化粧品

大手化粧品会社であるカネボウでは、ユーザーとのオンラインコミュニケーションを強化すべく LINEミニアプリを導入。ブランドごとにアプリを提供することで、ブランドや商品の世界観を共有しています。
各ブランドアプリの大きな特徴は、メッセージ開封率の高さです。高いもので70%の開封率を実現しており、同社が別途提供しているスマホアプリと比較して約2倍の効果があるとのことです。

引用・参照：LINEミニアプリ公式の事例ページ（新しいタブで開きます）

三井住友カード株式会社

三井住友カードではスマホアプリ「Vpass」を通してユーザーとのコミュニケーションを図っていますが、ライトユーザー向けにアプリのダウンロードや都度のログインが不要となるLINEミニアプリも併せて活用。わずか4か月という短期間で開発されたアプリにより、LINE公式アカウントとVpass IDとの連携数は従来の5倍となるなど、高い効果を挙げています。

引用・参照：LINEミニアプリ公式の事例ページ

これらの事例からも明らかなとおり、LINEミニアプリには「開発期間の短縮」「ライトなユーザーにもアプローチしやすい」「メッセージ開封率が高くコミュニケーションツールとして利用しやすい」といった特徴があるといえます。

LINEミニアプリの導入方法

LINEミニアプリを導入する方法には、大きく「パッケージプラン」と「個別開発」の2つの方法から選択することになります。以下では、それぞれの概要と特徴について紹介します。

パッケージプラン

パッケージプランでは、あらかじめ用意されたパッケージを利用することで、開発を行わない、もしくは最低限のカスタマイズで LINEミニアプリを利用することができます。
パッケージを提供している会社に個別に問い合わせをし、導入を進めることになります。
実現できる機能や利用金額にはバラつきがあるため、自社の実現したい要件を満たせるパッケージプランがあるか、まずは確認してみることをおすすめします。
利用できるパッケージと提供会社については、以下のリンクにまとまっていますのでご確認ください。

LINEミニアプリ 認定パッケージ一覧（新しいタブで開きます）

個別開発

パッケージの活用が難しい場合は、個別開発を実施することになります。上述の通り機能面での制約はありますが、Webアプリケーションとして作成できる一般的な機能であれば、大抵は実装できます。
LINEミニアプリの開発においては、POS や顧客管理データベースなど既存システムと連携するケースも多くなります。これらの連携機能は個々に開発が必要です。また、LINE ID によるシングルサインオン機能を構築する場合も、個別開発が必要となります。
LINEミニアプリの開発においては、LIFF（LINE Front-end Framework）と呼ばれるフレームワークを利用します。
委託先を選定する際には、LIFF の知見有無についても確認してみてください。

LINEミニアプリの導入にかかる費用と期間

以下では、LINEミニアプリの導入にかかる一般的な費用と期間をご紹介します。

導入にかかる費用

パッケージでアプリを導入する場合、基本的には初期費用と月額料金を支払うことになります。価格は無料で始められるものから 100万円程度の初期費用がかかるものまで様々ですが、初期費用が数万円、月額費用が1万円以内程度の製品が多い印象です。
具体的な金額については、製品によって異なりますので以下のリンクから確認してみてください。

LINEミニアプリ 認定パッケージ一覧（新しいタブで開きます）

一方で個別開発を行う際には、費用は都度見積となります。
規模にもよりますが、一般的な WEBサービスの開発費用と大きな乖離はないといえるでしょう。
あくまで参考ですが、当社でお受けする依頼では、数百万程度から1,000万円程度のケースが多く見受けられます。

導入にかかる期間

パッケージの場合、開発作業が不要となるため導入期間は短くなります。スピーディな導入を実現できるでしょう。
個別開発の場合、開発規模によるため一概には言えませんが、当社の事例では要件定義から一般公開まで半年程度で開発を行った実績がございます。

LINE・LINEミニアプリを使ったDXの実現

LINEミニアプリに多くのメリットがあることは前述の通りですが、当社では LINEミニアプリの活用は、企業の DX（デジタル・トランスフォーメーション）の実現にも有効であると考えています。
この記事の最後に、当社が LINE や LINEミニアプリを利用することで実現できると考えるビジネスの可能性についてご紹介します。

オンライン・オフライン両方でデータを取得する

LINEミニアプリを活用した DX 施策においては、LINE の強みを活かせる点がメリットです。LINE という社会に普及したプラットフォームを利用することで、スマホアプリでは顧客接点を作るために最も大きな障壁といっても過言ではないダウンロードのハードルを下げられるため、強固な顧客接点を比較的容易に作れます。また、LINE は企業や店舗から送ったメッセージの開封率が高いという特徴があります。
メッセージチャネルとして定番のメールマガジンの開封率は業界にもよりますが、一般的に15％～25％程度といわれています。一方で LINE の場合は70%近い人（69.9％）が「企業からのメッセージを読んだ」※と回答しています。同じメッセージ内容やタイミング等の条件を揃えての検証結果ではありませんので、単純な数値の比較はできませんが、企業からのメッセージがしっかりと届くチャネルであることは間違いないといえるでしょう。
※出典：LINE Business LINE Guide株式会社マーケティングソリューションカンパニー2021年1~6月期版（Summary）（新しいタブで開きます）
調査機関：マクロミル社・インターネット調査（2021年1月実施/全国15～69歳のLINEユーザーを対象サンプル数2,060）

加えて、オンライン・オフラインどちらの接点も作れることも重要です。
特に実店舗を構えるような、小売・飲食・医療などの業種においては、デジタルの力で顧客体験を高めていくためにオンライン・オフラインでユーザーに垣根を感じさせないアプローチが必要となります。
その実現ためのキモといえるのがデータ活用です。オンラインのデータは EC や WEBサイト上でも比較的取得しやすいのですが、リアル店舗などオフラインでの行動データを取得・活用することは難易度が高く、まだまだ進んでいない企業が多いのが現状です。しかし、LINEミニアプリによりデジタル会員証やポイントサービスなどを導入することで、ユーザーに紐づく来店履歴や購買履歴、興味関心などオフラインでの情報もデジタルデータとして収集できます。

取得したデータを統合し、マーケティングや顧客満足度向上に活かす

LINEミニアプリを通じて取得できるオフラインの情報とオンラインで取得した情報を組み合わせることにより、ターゲティングやセグメント分けを行い、効果的なマーケティング施策の実施やロイヤルカスタマー育成につなげられます。たとえば、来店回数が一定以上の顧客にシークレットセールの告知を送信する、店舗の創業記念日に該当の店舗に来店実績のある顧客に対して ECサイトで使える特別なクーポンコードを LINE で送るといった活用が考えられます。
また、HubSpot（新しいタブで開きます） に代表されるような CRM・MAツールと LINE を連携させれば、上記のようなメッセージ送信を条件に合致したタイミングで送るように自動化することも可能です。
参考記事：HubSpotとLINEの連携でできることとは？メリットや連携方法について解説（新しいタブで開きます）

近年ではカスタマーサクセスとして顧客の成功に貢献する取り組みも重要視されていますが、利用・閲覧頻度の高い LINE のメッセージング機能を利用した手厚い顧客サポートや、特定の商品を購入した顧客に一定のタイミングで商品の使い方を案内する取り組みのように、いわゆる「ハイタッチ」や「テックタッチ」のアプローチも実現できるでしょう。
このように、LINE というプラットフォームを活用し、リアル・デジタル両面での接点の構築とデータの活用をすることで DX の実現を目指せます。
当社、スパイスファクトリーでは LINEミニアプリの開発はもちろん、LINEミニアプリや LINE を使った DX 実現の伴走支援も行っておりますので、お気軽にご相談ください。

LINEミニアプリ開発のご相談はどうぞお気軽に

この記事では、LINEミニアプリの概要や導入効果、LINEミニアプリによる DX の実現可能性などについてご紹介しました。DX 実現のための手段として LINEミニアプリを利用するイメージはつきましたでしょうか？
当社、スパイスファクトリーではコアバリューとして「Form a Scrum」を掲げており、エンジニア・デザイナー・マーケター・ブランディングなど様々なスキルを持ったメンバーがチームで成果をあげられることを強みとしています。単なる外注先にとどまらず、お客さまと伴走し、ビジネスを成功させるための最適な課題解決へとつながるように支援を行います。
LINEミニアプリとスマホアプリ、どちらが自社に適しているのか悩まれている方は、検討段階からサポートを承っておりますので、どうぞお気軽にご相談ください。

他には以下の記事も良く見られています。

https://spice-factory.co.jp/web-marketing/why-dx-will-fail/

https://spice-factory.co.jp/hubspot/crm_function/

 

大きなコストが必要となる業務システム・基幹システムのリニューアルは難しい意思決定となります。結果として長期間リニューアルせずに既存システムを利用しており、管理画面のデザインが古く使いづらい、最低限の機能しかなく動作に制限がある、画面や導線が複雑になっている、といった課題を抱える企業は多いようです。
今回は、そのような課題を抱えた担当者様に向け、管理画面のデザインを改善する適切なタイミング、正しい改善の進め方、押さえておくべきポイントについて解説します。

業務システムの UI/UX に関するよくある課題

比較的長期間利用されることの多い業務システムにおいては、操作性やデザイン性などの UI/UX 面において様々な課題が発生します。具体的には、どのような課題が発生しやすいのでしょうか。

デザインが古めかしい

リリースして 5年、10年以上と期間が経過しているシステムにおいては、デザインが古くなっており操作性が悪いケースが散見されます。使っていて漠然とレガシーな印象を感じる場合は、改善が必要です。

最低限の機能しか備わっていない

システムに最小限の機能しかないことから、Excel などを併用して業務を運用しているケースもよくみられます。このような場合、運用性が悪く業務の負荷が高まります。会社規模の拡大や業務の変化にシステムが対応できていない場合によくあるパターンです。

度重なる機能追加により画面や導線が煩雑に

反対に、徐々に機能が追加されていき画面デザインなどが最適化されていない場合も。それぞれの改修においては操作性を考慮してきたものの、結果的に全体として使いにくいシステムとなっていることもよくあります。

使いやすさが十分に考慮されていない

過去、業務システムにおいては機能性が重視され、操作性に関する要件は最小限となっているケースがよくありました。直感的に使えないため十分な教育が必要となり、熟練社員の退社とともにノウハウが失われてしまい、業務効率が下がってしまった経験のある方も多いのではないでしょうか。

利便性を高めるデザイン改善、正しいステップとは

上述のような課題を解決し、業務システムの管理画面をより良いデザインへと改善するには、どのような進め方が望ましいのでしょうか。ここでは、業務システムのデザイン改善における一般的なステップをお伝えします。

ユーザーの利用環境、課題の明確化

デザイン改善は、ユーザーの利用環境や課題を知ることから始まります。システムによっては、ユーザーの利用環境が特殊であったり、何かしらの制限があったりすることも。前提条件として利用環境を押さえておくことは重要です。
行動観察・ユーザーインタビューなどの調査方法を通し、ユーザーが抱えている課題や不満などを把握することもひとつでしょう。

取り組みの最初にユーザーについて良く理解することで、取り組み全体の質が向上し、結果的に全体工数の削減も期待できます。

指標・KPI の設定

継続的な改善をしていくためには評価指標を設定することが重要です。指標を定義することで、取り組みの成果を定量的に振り返ることができ、PDCA の質を上げることができます。
たとえば、管理画面のデザイン改善においては、タスクの処理時間やエラー発生率などを指標とするとよいでしょう。また、ヒアリングによりユーザーが体感した操作性や満足度などを活用することも一案です。

改善案の検討

定義した指標の値を改善するためにはどのようにシステムを改善すればよいか、ユーザーの利用環境や課題を念頭に検討します。
ボタンの配置を見直すべきか、表示項目を最適化すべきか、機能を追加すべきかなど、様々な選択肢から有効な手段を精査します。

プロトタイプによるアイデア具現化

いわゆるプロトタイピングにより、時間やコストをできるだけかけずにアイデアを形にし、早期にテストできるようにします。
ユーザーのフィードバックを受けながら継続的な開発を行っていけるように、拡張性を意識した設計を行うことがポイントです。

プロトタイプを用いたユーザビリティテスト

ユーザビリティテストとして、プロトタイプを実際にユーザーに利用してもらいます。テストを通して、上述した評価指標に基づき改善効果を把握します。一方で、十分な効果が得られていないようであれば、テスト結果に基づき再度改善案を検討します。

継続的な取り組み

これらの流れは一度実施したら終わりではありません。何回もサイクルを回していくことが重要です。ユーザビリティテストにより発見された課題に対応できるよう、改善案の検討とプロトタイピングを実施します。もう一度ユーザビリティテストを行い、課題が改善されたかをチェックします。
このような流れを繰り返すことで、優れた UI/UX を持つシステムを作り上げることができます。

デザイン改善において押さえるべきポイント

業務システムの管理画面デザインの改善を行うにあたり、押さえておくべき重要なポイントをご紹介します。

現状の課題を正しく把握する

現状のシステムが抱えている課題を可能な限り洗い出すことで、改善の種を探すことができます。
たとえば、システムの利用者から意見をもらうのもひとつです。ユーザーインタビューやアンケート調査などを実施することで、課題が明らかとなります。
このとき気を付けなければならないのが、特定の声の大きいユーザーに引っ張られてしまわないようにすることです。平均的なユーザー像を念頭に置き、課題を平等に扱うことが多くのユーザーを満足させるためのポイントです。

繰り返しとなりますが、ユーザーの理解がデザイン改善の肝です。これらの作業をベンダーに依頼する場合は、ユーザーインタビューや行動観察などを実施するノウハウが蓄積されているか、実績や面談などを通してチェックしてみてください。

小さく始め、やり直せるように進める

検討した改善策は、必ずしも効果があるとは限りません。実際にシステムを改修してみたら「前の方がよかった」という声が挙がることはよくあります。特に、多くのユーザーが利用する業務システムにおいては、デザイン変更の影響は大きくなりがちです。

デザインの良し悪しは、実際に見て触ってみるまで分かりにくいという特徴があります。そのため、上述したとおりプロトタイプの構築により、まずは改善策を具体化できる物を作り、テストを通して効果や課題を確認することが重要です。

小さく始め、仮説の検証を繰り返しながら必要に応じて機能を追加。一歩ずつ成長させていき、併せて柔軟な対応ができるように進めます。

発注側・受注側で協力体制をとる

UI/UXデザインの改善においては、可能な限り依頼側とベンダー側がワンチームとなるべきです。その理由として、デザイン改善においては実際のユーザーの声が重要であることが挙げられます。
業務システムのデザイン改善は、業務をより良く進められるように実施するものです。ベンダーに丸投げしてしまうと、実際の業務ニーズに合った改善は難しいといえます。たとえばワークショップ形式の MTG を開催し、その場でデザインを作成しながら全員で考える機会を設けることで、より効果の高い改善が実現できるでしょう。

最近では、「ペアデザイン」と呼ばれる手法により、デザイナーがペアとなってデザインを実施する取り組みも注目されています。一般的なペアデザインは、デザイナー同士がペアとなる状態を指しますが、弊社ではクオリティを最大化させるために、デザイナーとエンジニア or クライアントがペアになり、両者の視点を取り入れながらプロダクトを製作しています。
詳しくは以下の記事をご参照ください。

https://spice-factory.co.jp/design/pairing_design_engineering-designer/

加えて、実際のユーザーも含めてデザインを実施することで、業務ニーズや具体的な利用シーンなどを踏まえたデザインを実現することもできます。

業務システム管理画面の UI/UX デザイン改善により、利便性を向上させよう

以上、業務システムの管理画面のデザインを改善する際の正しい進め方、押さえるべきポイントについて解説しました。
デザイン改善は正しいステップで、かつポイントを押さえて進めることが重要です。ノウハウのない状態で取り組むと、かえって操作性が悪化するなど、逆効果になることも。経験豊富なプロに依頼することをおすすめします。
弊社では、UIデザイナー、UXデザイナー、エンジニアによる本質的なデザイン改善、開発を強みとしています。業務システムの操作性に悩まれている方は、ぜひ（新しいタブで開きます）下さい。
弊社の関連サービスに関しましては以下URL からご確認いただけます。

https://spice-factory.co.jp/service/uiuxgrowth/