柔軟な開発を実現しやすく、サービスインまでの期間を短縮しやすいアジャイル開発は、新規サービス開発や DX推進などにおいて有効な手法です。
アジャイル開発を実施する上では、アジャイル開発手法の一つであるスクラム開発を採用するケースも多いですが、アジャイル開発とスクラム開発にはどのような違いがあるのでしょうか。
この記事では、スクラム開発を得意とする当社、スパイスファクトリーが、スクラム開発の概要やそのメリット・デメリット、アジャイル開発との違い、主な事例などについて解説します。
また、弊社スパイスファクトリーではアジャイル開発において豊富な実績があります。
弊社の概要やサービスプラン、過去の導入実績などをまとめた資料をご用意しました。気になる方はこちらからダウンロードしてください。
アジャイル開発とは？
アジャイル開発とは、ビジネス価値の最大化に向けて、顧客に価値のあるソフトウェアを早く、継続的に提供するためのアプローチのことです。
アジャイル開発では、一度に全ての機能を開発するのではなく、各工程を繰り返しながら徐々に開発を進めていきます。「アジャイル＝機敏に」という言葉のとおり、必要に応じて方針を修正していけるのがアジャイル開発の大きなメリットです。
アジャイル開発については以下の記事でも詳細を解説していますので、よろしければご参照ください。
https://spice-factory.co.jp/development/agile-software-development/
ウォーターフォール開発との違い
過去、一般的なシステム開発においてはウォーターフォール開発と呼ばれる手法が利用されてきました。
従来広く利用されてきたウォーターフォール開発では、要件定義からリリースまで上流から下流に流れる形で進み、前の工程に戻ることはありません。
一方でアジャイル開発では各工程を繰り返すことで、一度に 100点を取るのではなく、進みながら方針を修正することができます。
両者にはメリット、デメリットがありますが、変化に対する柔軟性が高く、また早い段階で実際にシステムに触ることができるというメリットがあるアジャイル開発は、変化の激しい現代において有効なシステム開発手法といえるでしょう。
アジャイル開発とウォーターフォール開発の違いについては、以下の記事でも詳しく解説しております。併せてご覧ください。
https://spice-factory.co.jp/development/difference-agile-waterfall/
アジャイル開発の一つ「スクラム開発」とは？
スクラム開発は、アジャイル開発の一手法という位置づけのものです。以下では、スクラム開発についてご紹介します。
スクラム開発の概要
スクラム開発とは、少人数のチームで「スプリント」と呼ばれる1～4週間程度の開発期間を繰り返すことで、システムを作り上げていく手法のことです。
スクラム開発という言葉は、ラグビーのスクラムに由来しています。ラグビーのスクラムでは、チームメンバーが肩を組んでチームワークを発揮しますが、スクラム開発でも同様にチームが一丸となって開発を進める行うことが特徴です。
スクラム開発はアジャイル開発手法の一つであり、その中でも代表的なものといえます。
スクラム開発の流れや役割、イベントに関しては以下の記事で詳細に解説していますのでぜひ参照してください。
https://spice-factory.co.jp/development/about-scrum-event/
スクラム開発の特徴
スクラム開発では「経験主義」と「リーン思考」という思想をベースとしています。経験主義として経験を重要視し、観察に基づき意思決定を行います。また、リーン思考としてムダを省き、本質に集中することを大切にします。
このような思想の下、スクラム開発は以下の要素を三本柱としています。
〇透明性
スクラム開発において、プロセスや作業は実行する人とその作業を受け取る人が把握できるようにします。透明性の低い成果物は、リスクを高める意思決定につながる可能性があります。透明性を高めることで、作成したプロダクトの価値を明確に確認できます。
〇検査
スクラム開発で作成された成果物とゴールに向けた進捗状況のチェックを重視します。これは、望ましくない状況や発生した問題を素早く検知するためであり、スクラム開発では検査のためのイベントが用意されています。
〇適応
開発プロセスに課題があったり、成果となるプロダクトが受け入れられなかったりした場合は、プロジェクトの進め方や成果物を素早く調整します。前述した検査を通して課題や問題を検知したら、正しい目標に向けて瞬時に適応することが求められます。
スクラムガイドとは
スクラム開発を理解する上で押さえておきたいのがスクラムガイドです。スクラムガイドは、スクラム開発のフレームワークを説明するドキュメントであり、スクラムの原理原則や価値観、基本的なルール、役割、イベントなどについて解説されています。
スクラムガイドは、スクラムの創設者であるジェフ・サザーランドとケン・シュウェーバーによって作成されたものであり、現在でも継続的に更新されています。
無料で公開されており、誰でも閲覧可能です。スクラムガイドの内容は非常にシンプルで文章量も多くありませんが、実際のスクラム運用において有用な情報が詰まっています。
スクラム開発について学びたい方は、まずスクラムガイドを一読することをおすすめします。
スクラム開発に必要な体制
前述した通り、スクラム開発には「プロダクトオーナー」「スクラムマスター」「開発者」という3つの役割が存在します。以下では、それぞれの役割についてご紹介します。
プロダクトオーナー（PO）
プロダクトオーナーとは、プロダクトの要求管理、機能の優先順位付け、品質チェックを行い、プロダクトの価値最大化を目指す責任者です。
プロダクトオーナーはプロダクトの成果に責任を持ち、プロダクトの方向性を決めます。方向性を明確にするためにも、一つのプロダクトにつきプロダクトオーナーを担当するのは一人です。プロダクトオーナーは、スクラムチームから生み出されるプロダクトの価値を最大化することを目指します。
プロダクトオーナーの役割や必要なスキルなどについては以下の記事にて詳しく解説しておりますので、よろしければご覧ください。
https://spice-factory.co.jp/development/what-is-productowner/
スクラムマスター（SM）
スクラムマスターは名前の通り、スクラム開発の専門家として活動し、スクラムの理論と実践をチームメンバーに理解させるための支援や、問題解決を担当します。
スクラムマスターは「スクラムを確立させる責任者」と表現できます。ウォーターフォール開発ではプロジェクトの責任者はプロジェクトマネージャーが担いますが、プロジェクトマネージャーとスクラムマスターの役割は少し異なります。
スクラムマスターはプロジェクトがスムーズに進むようサーバントリーダーとして奉仕します。従って、プロジェクトマネージャーが行うようなタスクの割り当てや進捗管理などのマネジメント作業は行いません。
スクラムマスターについてさらに詳しく知りたい方は、次の記事をご覧ください。
https://spice-factory.co.jp/development/what-is-scrum-master/
開発チーム（DEV）
開発チームはシステムの開発を担当し、スプリントでプロダクトを改善する専門家です。開発チームはプロダクトの品質に責任を持ちます。
スクラムにおける開発チームは3～9人が適切とされます。少人数だと属人化しやすく、大人数だとコミュニケーションコストが増えます。
スクラム開発においては、ウォーターフォール開発でよくみられる「特定作業のみを行うサブチーム」は設置しません。全員が機能横断的に設計からドキュメント作成まで多様な作業を担当することが求められます。各担当者に明確な役割分担はなく、「自己組織化」によりチームで合意形成を図りながら進めます。
スクラムを採用するメリット
以下では、主にビジネス側においてスクラム開発を採用することでどのようなメリットを得ることができるのかをご紹介します。
メリット①：優先度やサービスの方向性の柔軟な変更
一度に全機能の要件定義を実施するウォーターフォール開発と比較して、スクラムでは開発単位（スプリント）で要件の変更ができます。実際に開発されたシステムを見て、機能面やデザイン面の改善も可能です。
現代のビジネスはスピードが重要であり、また環境の変化に追従するために方向性を修正していかなければなりません。このような環境においては、変化に強いスクラム開発が有効な手段となります。
メリット②：早期リリース
スクラム開発では継続的な機能拡張を前提としているため、早期にリリースしたうえで、段階的に機能を追加していくというアプローチが可能となります。
これにより、新規事業開発において MVP（Minimum Viable Product：顧客のニーズを満たす最小限のプロダクト）を構築し、想定ユーザーに評価してもらうような取り組みもしやすくなります。評価結果を受け、機能の修正や追加などを行っていく際にも、スクラムであれば対応しやすくなります。
メリット③：チームのモチベーションアップ
スクラム開発の採用は、チームのモチベーションアップという観点でも効果があります。
スクラム開発では、おのおのが自律的・主体的に作業を担当し、チームに貢献することが求められるため、メンバーの自主性と責任感が向上します。また、定期的なミーティングにより継続的なフィードバックを受けることで、コミュニケーションも促進されます。スクラム開発は、チーム全体の一体感とモチベーションが向上し、結果として組織全体のパフォーマンスが向上する仕組みであるといえるでしょう。
スクラムを採用するデメリット
一方で、スクラムにはデメリットもあります。
デメリット①：メンバーにスキルが必要
スクラム開発では、ウォーターフォール開発のように正確に定められた設計書に沿って機能を開発するわけではなく、エンジニアの柔軟性が重要となります。また、少人数でプロジェクトを進めることから全員が主役になる必要もあります。
このような理由から、チームメンバーには一定レベル以上のスキルが必要です。十分にスキルを持ったメンバーでチームを構成することが求められます。
近年では、IT人材の不足状況もあり、人材確保が難しい状況にあります。スキルのあるベンダーの選定や活用もスクラムでシステムを構築していく上では重要といえるでしょう。
https://spice-factory.co.jp/development/insufficient-development-resources/
デメリット②：開発着手時点でスコープ・スケジュール・予算が確定しない
ウォーターフォール開発では、要件定義工程にて開発のスケジュールと工数を確定させます。
一般的には開発工程は請負契約となり、スコープとなる機能を実現するためのスケジュール・コストに対する責任はベンダー側にあります。
また、仕様書に定められた要件の範囲内であれば、コストは一定となります。
一方で、スクラムにおいてはスプリント単位での短期的なスケジュールや工数は確定させるものの、全機能のスコープ・スケジュール・コストは事前に確定させません。契約形態としても準委任契約が一般的であり、成果物に対する責任はベンダー側にはありません。
スクラム開発においてはスコープ・スケジュール・コストを柔軟に変更できるメリットはあるものの、契約面でこれらが担保されているわけではないので注意が必要です。
このような理由から、スクラム開発を行う際には信頼できるパートナーを見つけたうえで、協力できる体制を構築することが重要といえます。
デメリット③：チーム内のコミュニケーションが重要となる
スクラム開発において、チーム内のコミュニケーションは非常に重要です。
スプリントごとに柔軟にスコープやスケジュールを変更できる点がメリットである反面、全体のスコープやコストが事前に確定しないため、常にチームメンバー間での密な連携と信頼関係が求められます。
チーム内のコミュニケーションが不十分であれば、スクラム開発の強みが生かされないどころか、プロダクト開発に支障が生じる事態ともなりかねません。
よって、スクラム開発を成功させるためには、メンバー同士が適切にコミュニケーションをとる必要があります。
スクラム開発の流れ
具体的に、スクラム開発はどのような流れで進めていくものなのでしょうか。以下では、スクラム開発の具体的な流れは以下のとおりです。
スクラムチームの体制構築
まず初めに、スクラム開発を実施していくうえでのチームを構築します。前述のとおり、スクラム開発では以下の3つのロールが存在します。
・プロダクトオーナー
・スクラムマスター
・開発チーム
まずこれらの役割を誰が担当するのか決定し、スクラム開発プロジェクトの立ち上げを行います。
プロダクトゴールおよびプロダクトバックログの作成
スクラムでは、チームの目標はプロダクトゴールとして定めたうえで、ゴールを実現するために必要となる機能をプロダクトバックログとしてまとめます。プロダクトバックログの要求項目は優先順位をつけ、各スプリントで優先順位の高いものから開発します。
プロダクトゴールやプロダクトバックログの作成はプロダクトオーナーが行いますが、必要に応じてスクラムマスターが支援します。
スプリントプランニング
スクラム開発では、一定の期間である「スプリント」を繰り返し、計画・設計・開発・テストを行います。スプリントは通常1週間から1カ月程度で設定され、チームの成熟度や人数、ビジネス状況によって決まります。
スプリント開始時にはスプリントプランニングを行い、開発する機能とゴールを定義します。各スプリントでは、チームのリソースと見積もりを基に、実現可能な範囲で開発を進めます。
スプリントの完成条件はプロダクトオーナーと開発チームが合意を行います。
スプリントの実施
各スプリントでは、スプリントプランニングで定義した開発範囲を目標とし、コーディングとテストを進めます。スプリントの完了時までに、実際に利用できる形でシステムを構築します。スプリント期間中は毎日デイリースクラムを行い、本日の作業や進捗をチームで報告します。デイリースクラムは15分程度で同じ場所・時間に実施することが一般的です。
通常は開発チーム内のみでデイリースクラムを行いますが、スクラムマスターやプロダクトオーナーも参加する場合があります。
スプリントレビューの実施
スプリント終了時には、主要なステークホルダーを招き、今回開発した機能のデモを行うスプリントレビューを実施します。
スプリントレビューでは、要求通りに開発が進んでいるか、改善点が無いかを検討します。そして、この結果を元に、プロダクトゴールに向けてプロダクトオーナーはプロダクトバックログの内容や優先順位を見直します。
スプリントレトロスペクティブによる振り返り
スプリント終了後にはスプリントレトロスペクティブと呼ばれる振り返りを行います。
スプリントレトロスペクティブでは、スプリント実施中における課題の特定や改良案をチームで検討します。
改善策を次のスプリントに取り入れることで、次回以降のスプリントの質を高めつつ、チーム全体の成長も目指します。
ここでは簡単にスクラム開発の流れについてご紹介しました。より詳しくスクラム開発の流れについて知りたい方は、以下の記事もご覧ください。
https://spice-factory.co.jp/development/about-scrum-event/
また、スクラム開発の中でも、特にスプリントについて知りたいという方は、以下の記事も参考になるはずです。併せてご覧ください。
https://spice-factory.co.jp/development/what-is-sprint/
アジャイル開発・スクラム開発を採用した主な事例
当社、スパイスファクトリーでは、アジャイル開発やスクラム開発を採用した多数の開発事例があります。ここでは、そのうち 3つの事例をご紹介します。
東京都デジタルサービス局 | アジャイル型方式によるプロトタイプ開発委託
東京都は、デジタル技術を活用した行政の革新を目指し、都政のQOS（Quality of Service）向上を図るために、2021年にデジタルサービス局を発足させました。
同局では、国際的な競争力の強化や、都民生活の質と利便性の向上を目指し、新たな価値を迅速かつ柔軟に生み出すためにアジャイル開発手法を積極的に採用しています。
当社は、このたび、その取り組みの一環として企画された4つのアジャイル型プロトタイプ開発プロジェクトを担当いたしました。
https://spice-factory.co.jp/works/14765/
株式会社トムス・エンタテインメント｜ProGrace開発によるアニメーション制作DX
株式会社トムス・エンタテインメントは、日本のアニメーション制作業界が抱える制作面、ビジネス面、そして人材育成に関するさまざまな課題を踏まえ、「アニメSDGs -2030年までに持続可能な日本アニメ産業の未来を創る-」というビジョンを掲げています。
当社では、アニメ業界のDXを推進する「ProGrace（プログレース）」の開発を継続的に支援しております。
本記事では、同社のプロジェクトご担当者様に、プロジェクトの背景や今後の展望について詳しくお話を伺いました。
https://spice-factory.co.jp/works/17700/
株式会社ネクスウェイ | 薬局向けDI (薬剤情報) ポータルサービス「アスヤク薬局ポータル」の開発
株式会社ネクスウェイ様では、薬剤情報（DI）を統合して閲覧・管理できる「アスヤク薬局ポータル」を提供しております。当社は、同サービスをアジャイル型で開発するにあたり、サポートを行いました。
同サービスは、デジタル化とアナログの共存が求められるDX過渡期に対応するため、Web閲覧やメール配信に加え、郵送にも対応しています。また、メールの到達や開封、クリックの計測、および郵送の配送、不達の計測も行い、施策の効率性を測定できます。
開発にあたっては、宛先情報をまとめて管理するため、表記揺れのある住所や薬局情報のマッチング処理の開発も行いました。マッチング精度を高めるため、レーベンシュタイン距離と呼ばれる文字列間の近似度を測る手法を採用しています。
https://spice-factory.co.jp/works/14733/
変化の激しい現代にあった開発手法がスクラム開発
この記事では、スクラム開発の概要やそのメリット・デメリットなどについてご紹介しました。
ビジネスの速度が向上している現代において、柔軟に開発内容を変更できるスクラム開発の有効性は高いといえます。
一方で、スクラム開発を成功させるためには高いスキルを持ったエンジニアが必要となります。
スパイスファクトリーでは「Form a scrum」という企業文化に基づき、スクラムをはじめとしたアジャイル開発によってこれまで多くのお客さまのシステム開発を支援してまいりました。アジャイル開発でプロジェクトを実施したいという方は、ぜひお声がけください。
また、弊社は豊富な実績を持ち、これらのプロセスを効率的に進めるためのサポートを提供いたします。
詳細を知りたい方は、こちらからサービス紹介資料をダウンロードしてください。
当社は【2025年最新版】アジャイル開発おすすめ企業4選（新しいタブで開きます）に掲載されています。
近年の日本では少子高齢化による人手不足が叫ばれています。日本も例外ではなく2022年時点で、IT人材の量的不足を感じる企業が全体の 83.5% に達したという調査もあります。
そこで注目されているのがオフショア開発（新しいタブで開きます）です。
ブリッジSE と呼ばれるオフショア先とのやり取りを専属で行う SE（システムエンジニア）を配置すれば、各種対応がスムーズになるといわれていますが、ただ配置すればいいというものではありません。
この記事ではブリッジSE のオフショア開発での役割と必要性、注意点などをお伝えしていきます。
ブリッジSEとは
ブリッジSE とは、オフショア開発など他国と協業するプロジェクトの橋渡し役となるシステムエンジニア（以下 SE）のことです。
オフショア先への各種情報連携や成果物のチェック、日本側への進捗報告などを実施します。
ブリッジSE の業務遂行にあたっては、一般的な SE に求められる知識に加え、オフショア拠点の文化や言語などの知識も求められます。
ブリッジSEと通常のSEの違い
ここではブリッジSEと通常のSEについて、業務の違いを紹介していきます。
通常のSE
通常のSE（システムエンジニア）は、システムの開発や運用をはじめ、システム開発の業務そのものに関わることが一般的です。
ドキュメント作成や顧客との折衝など、システムに関わる業務内容全般を担当していきます。
ブリッジSE
ブリッジSE は先述の通常の SE業務に加えて、慣習の異なるオフショアメンバーに対し、システムの仕様や設計について正確に伝え、プロジェクトを円滑に進める役割を担います。
システム開発に関しての知見が必要であることはもちろんですが、日本語ではない現地の言語を活用したコミュニケーションとオフショアメンバーのマネジメント業務のウェイトが大きくなります。
ブリッジSEが求められる背景
続いて、ブリッジSE が求められる背景についてみていきましょう。
語学や外国の文化に精通したSEは少ない
オフショア開発では、残念ながらプロジェクトが破綻してしまうといった事例が多く聞かれます。
オフショア開発を含むプロジェクトでは、言語の違いや文化の違いからプロジェクト推進にあたって様々な齟齬が生じやすい点が国内での開発とは大きく異なります。この違いに対応できないことが失敗の原因としては大きいです。
※参考記事：オフショア開発は失敗しやすい？よくある失敗パターンの原因と対策を解説（新しいタブで開きます）
このような事態を防ぐためには、オフショア拠点がある国の語学や外国の文化に精通したブリッジSE の配置が有効になるでしょう。
オフショア拠点側からみても、常に自国の言語で相談できる人員がいることは安心感がありますし、コミュニケーションの速度・質も上がります。また、自国の文化を理解し味方になってくれる人がいることで、オフショア先の勤務モチベーションも保たれます。
通常の SE の場合、技術的な会話も含めて多言語に対応できる人材は少ないです。また、オフショア開発拠点国の文化的な理解まで含むと一層希少ですので、ブリッジSE という専属のポジションの必要性が存在します。
オフショア先を管理する人材が必要
オフショア開発においてよくある課題として、オフショア拠点が発注元会社の複数の異なる人からリクエストや指示を受けてしまうといったこともあります。
結果として情報が錯綜してしまい、オフショア拠点側が優先度や対応要否などを判断できず、混乱してしまうことも。
そのような事態を避けるために、ブリッジSE に連絡先を一本化しておくことが有効です。
言語や文化差におけるニュアンスの齟齬も減らせるほか、発注側のメンバーも、オフショア拠点側のメンバーも要望を誰に相談すればいいか、情報を誰に確認すればいいかが明確になることで混乱を避けることができます。
ブリッジSE という情報の交通整理ができるメンバーがいることでプロジェクトを円滑に進めることができるでしょう。
海外で作成される成果物品質への懸念
海外で制作された成果物が必要な質を担保しているかということも、オフショア開発において挙がる懸念事項の一つです。
そこで言語や文化への理解と技術的な知見の両方を持ち合わせるブリッジSE が参画することで、現地エンジニアへの依頼内容とクリアすべき品質の基準が伝わりやすくなります。
ブリッジSE が存在することで、現地チームの各種ルール整備やコードレビューなどの品質担保の取り組みについても主導権をとって推進していけるでしょう。
ブリッジSEの役割
ブリッジSEは、システムの設計スキルを持ち合わせた上でクライアントと開発チームの橋渡しをします。ここではその役割の詳細を解説します。
オフショア拠点にプロジェクトの説明をする
オフショア拠点国の文化によって仕事の進め方は大きく異なります。
最初にプロジェクトの説明をし、出てきた疑問や問題点に対する細かい調整は必須です。
この細かい調整にあたってブリッジSE がその真価を発揮します。
仕様についてや要求される機能とその品質、対応スケジュールなど現地メンバーのスキルセットや現地の商習慣、祝日などを考慮して整理する役割を果たします。
設計書の翻訳や補足をする
オフショア開発に限定した話ではありませんが、設計書の意味を取り違えると取り返しのつかないことになります。
そのため、日本とオフショア先の両方の言語を理解したブリッジSE が設計書の翻訳・捕捉をしていく必要があるのです。
日本側（発注側）とオフショア側で共通した認識を持てるように、ドキュメントの整理などの対応する場合もあります。
納品物の品質の担保
納品物の品質担保のため、ブリッジSE によるコミュニケーションは不可欠です。
納品物に不備がある際は、信頼関係を壊さないよう誠実に、一方で要求する水準を満たしてもらえるように丁寧な対応が対応が必要になります。
場合によっては、一緒にソースコードを確認したり、参考にすべき記述方法の情報共有やディスカッション、アドバイスなどを行うこともあります。
現地の言葉を用いてのコミュニケーションも重要ですが、前提として SE としての技術的な知見を持ち、チームに還元することも求められます。
プロジェクトの管理や調整・報告
プロジェクトの体制にもよりますが、いわゆるプロジェクトマネジメントもブリッジSE の役割に含まれます。
納期までに決められた品質の成果物が納品できるように、スケジュールのコントロールや各種課題への対応、社内外を含めたステークホルダーへの相談や報告も重要な役割です。
プロジェクト成功のためにブリッジSEに求められるスキル
上記にて紹介した通り、ブリッジSE に求められる役割は多岐にわたります。
それに伴い、必要となるスキルの幅や質も高くなります。
ここではブリッジSE に求められるスキルの中で、代表的な5つのスキルを紹介します。
語学力
ベトナムやフィリピンなどオフショア開発の拠点国として人気の国では、最低限英語が話せる必要があります。
オフショア先の現場で使われる言語をマスターしていることはプロジェクト推進の前提となるため最も重要なスキルと言ってよいでしょう。
コミュニケーションスキル
コミュニケーションが取れないと認識に齟齬がでてしまい、望んでいた結果が得られない可能性があるため、異文化を理解したうえでのコミュニケーションスキルは必須です。
オフショア拠点国の言語、日本語、両方でコミュニケーションが取れることが重要です。
口頭でのコミュニケーションに加え、メールやチャットツール、必要な情報をドキュメントにまとめるといったテキストでのコミュニケーションもスムーズに行える必要があります。
異文化理解
オフショア開発を実施するうえで、現地の文化を理解して適切なアプローチ方法を考えることは欠かせません。
連携先の国の商習慣やパーソナリティの理解は、プロジェクトを進める上で非常に重要なファクターです。
現実的な差としては、たとえば祝日や長期休暇のタイミング、時差により稼働時間が日本と違っていたり、転職に対する考え方が日本よりもフランクなケースが多いなど、チームマネジメント、プロジェクトマネジメントの両面から考慮すべき事項は多く存在します。
前提となる常識や考え方ズレてしまうと、後々大きな問題となって表出することが多くあります。
英語でいう TOEIC などのように、定量的に測ることが難しいスキルではありますが、非常に重要なスキルです。
システム開発に関する技術的知見
当然ながら、システム開発を進めるうえで必要になる「設計スキル」「プログラミング言語・フレームワーク知識」「コーディングスキル」「セキュリティ対策」など、一般的にプロジェクトで使用される技術に対して理解を深めていることも必要です。
自社が使用する技術については精通していることが望ましいでしょう。
プロジェクトマネジメントスキル
日本国内とオフショア拠点の橋渡しをしつつ、品質や納期も守るためにオフショア先のエンジニアに対して的確に指示を出し、パフォーマンスを発揮できるようアシストする必要があります。
各ステークホルダーとの折衝や、オフショアチームのピープルマネジメント、進捗の管理やフォローの指示、スケジュールの調整など日本国内でのプロジェクトにおいても重要なスキルです。
さらに、多言語かつ、時差や祝日、文化差など考慮が必要な変数が多いことから、ブリッジSE にはより丁寧で緻密な管理が求められます。
ブリッジSEを参画させる場合の注意点
最後にブリッジSE を参画させる場合の注意点を一つずつみていきましょう。
ブリッジSEに求めるスキルを明確にする
ブリッジSE に通常の SE のような動きを期待するのか、コミュニケーション能力を期待するのか、それともプロジェクトマネジメントの能力を期待するのかで、ブリッジSE に求められるスキルが異なってきます。
もちろん、すべてのスキルを持っていればベストですが、その場合アサインには大きな費用を要することが多いでしょう。
そのためブリッジSE の職務定義を明確にし、ブリッジSE に求められる能力をはっきりさせておくことが無駄なコスト削減のためにも重要です。
オフショア開発を外注する場合には、依頼する会社側でブリッジSE のアサインが可能か相談をしてみるのが良いでしょう。
ブリッジSE のスキルレベルを会社独自の試験制度で視覚化しているオフショア開発企業もあるので、そのようなところを選択できるとベターでしょう。
事務員をブリッジSEにしない
やり取りの煩雑さから事務員をブリッジSE にしたがる企業やチームがあります。
率直に言っておすすめしません。
事務員では日々のやり取りが文字通り事務的になり、また SE としてのスキルも不足していることが多いため、オフショアチームの能力を引き出しきれません。
技術的な相談にも対応できないため、即座に対応すれば解決することが翌日に持ち越しになるといったことも往々にしてあるでしょう。
その場合、作業もスムーズに進まず、オフショアチームの効率も落ちてしまいます。
ブリッジSE には必ず システムエンジニア職務に従事・精通している人員を割り当てましょう。
連絡は必ずブリッジSEを通す
自社の複数の人員からリクエストを出すようにしてしまうと、オフショア先ではどの依頼を優先すべきかわからずに、その判断に時間が割かれてしまいます。
基本的に連絡事項は必ずブリッジSE に集約し、ブリッジSE が調整したうえでオフショア先に展開しましょう。
逆にオフショア先からのリクエストがある場合も、ブリッジSE を通して伝えるようにし、自社内での意思決定をスムーズにできることが望ましいでしょう。
最初はブリッジSEをオフショア先に張り付かせる
最初はコミュニケーションがうまくいかなかったり、オフショア先の文化を理解するのに苦労したりといったトラブルが発生することもあります。
そのため、特にオフショア開発の開始当初は、ブリッジSE がオフショア先に付きっ切りで手取り足取り業務を教える体制とした方が、後々の開発もうまくいきやすくなります。
ブリッジSEにオフショア先とのやり取りを任せ過ぎない
コミュニケーションはブリッジSE を経由した方がよいと前述しましたが、すべてをブリッジSE に任せきりにしてしまうのもデメリットがあります。
ブリッジSE だけで仕事をすると、成果物がブリッジSE のスキルに依存しやすくなるのです。
そのため、成果物についてはブリッジSE 以外のメンバーでも確認し、指摘点や不明点、改善点などはチーム全体で洗い出す体制がよいでしょう。
オフショアメンバー・国内メンバーどちらでもよいですが、プロジェクトのブリッジSE よりも開発スキルがあるメンバーがいれば、レビュアーとして参画してもらうことなどは有効です。
役割分担を明確にしてブリッジSEに把握させる
オフショア開発以外にも当てはまる話ですが、自社とオフショア拠点で何をするか役割分担を明確にしておきましょう。
各メンバーが範囲外のことまで取り組もうとした場合は、その範囲を明示して制することも必要です。
オフショア先と明確に会話するブリッジSE は、特に役割分担については明確に把握しておかなくてはなりません。
業務についての責任の所在を明確にすることで、齟齬やトラブルのリスクを軽減するとともに、成果物に不足や不具合があった際にどちらが悪いといった不毛な議論に時間を使わずに済むようになります。
ブリッジSEからオフショア先への指示は定型文で伝える
指示は省略せずに、いつも同じ表現を用いて伝えましょう。
特に日本語は表現が豊富なため、海外の人材から指示がわかりにくいという声があがることもあります。
ドキュメントに記載のある表現をベースにして、指示はいつも同じ表現で伝えるようにしましょう。
たとえば、具体的には「～してください」と「～してくれませんか？」が異なるだけで意味を取り違えられてしまうこともあります。
仕事の進め方を可能な限り文書化する
非常に基本的な内容から、社内でのルールを洗い出して文書化しておきましょう。
日本人なら何となくわかりそうなルールでも、海外のメンバーにはくみ取れないことがよくあります。
仕事のルールのなかには、何となく定着した「暗黙のルール」もあるはずです。
この機会にルールを振り返って文書化しておきましょう。
また、必要な資料やデータの探し方については、文書化するだけでなく、画面越しにレクチャーすることも大事です。
オフショア先が資料を探すのに時間がかかっては効率が落ちるため、最初にレクチャーしておくことをおすすめします。
業務で使用する単語と外国語の対応表を作成する
日本語と英語、オフショア先の母国語で業務に使用する単語表を作っておきましょう。
特に自社で開発の際に頻出する単語については掲載しておくべきです。
オフショア先のエンジニアが、自社で頻繁に使われる業務用語を知らないため、必要な仕事を与えることができない場面も想定されます。
また、連絡のたびにいちいち単語の意味を説明していては時間がかかりすぎます。
共通認識を持つ意味でもプロジェクトの初期段階で用意し、随時追加しながら運用していくのが良いでしょう。
依頼企業選定時に優秀なブリッジSEのいる会社か見極めるには？
自社でブリッジSE を採用する場合は、前述した求められるスキルを満たしている人材かを確認して採用しましょう。
採用にあたっては、過去にオフショア開発チームとどのようなコミュニケーションを取ったのかを評価するべきです。
指示書等での簡潔な連携がメインであれば、品質を保つのは困難かもしれません。
オフショア開発を外部の会社に依頼する場合には、契約前の商談の時点で、ブリッジSE の有無の確認ならびに誰がブリッジSE として参画するのかを聞いておき、必要に応じて求めるスキルレベルを伝えておくとその後の対応がスムーズです。
可能なら商談時に営業だけでなく参画予定のブリッジSE とも会話をし、コミュニケーションに問題がないか、実績や経験は申し分ないかなどを確認するなどして自社の案件との相性を確認しておきましょう。
オフショア開発の依頼先選定については以下の記事もぜひ参考にしてください。
※参考記事：オフショア開発会社の選び方とは？確認すべきポイントを解説（新しいタブで開きます）
まとめ：ブリッジSEのアサインでオフショア開発の成功確率を上げる
これまでの内容で説明した通り、オフショア開発プロジェクトを成功に導くためには、ブリッジSE は非常に大きな役割を果たします。
ブリッジSE を採用する場合は前述したスキルを保持しているかを確認し、オフショア先でブリッジSE をアサインしてもらう場合は、プロジェクト開始前に一度会話の場を設けて問題なくコミュニケーションが取れることを確認できるとベストでしょう。
当社、スパイスファクトリーではフィリピンを拠点としたオフショア開発のサービス（新しいタブで開きます）を提供しています。
優秀なブリッジSE が参画し、高いレベルでのプロジェクト推進体制を構築していますので、これまでオフショア開発の経験がないお客様にも安心してご利用いただいております。
オフショア開発やブリッジSE のアサインにお悩みの場合は、ぜひ一度スパイスファクトリーにお問い合わせください。
参考文献
- 吉山 慎二 著.『ゼロからわかるオフショア開発入門』（2020）.幻冬舎
- S-openオフショア開発研究会 著.『ソフトウエア開発 オフショアリング完全ガイド』.日経BP
スクラムマスターとは、スクラムチームの有効性に責任を持つ役割のことです。スクラムガイドでは「スクラムチームと組織に奉仕する真のリーダー」と定義され、スクラムの理論とプラクティスをチームと組織に定着させ、チームが自己管理しながら成果を出せるように支援します。
プロジェクトのリーダーというと「プロジェクトマネージャー」を思い浮かべる方も多いのではないでしょうか。
一方で、スクラム開発におけるスクラムマスターの役割は、プロジェクトマネージャーとは少し異なります。
この記事では、スクラム開発をはじめとしたアジャイル開発を得意とする当社が、スクラム開発におけるスクラムマスターの役割や必要なスキル、資格、当社の現場で実践している工夫についてご紹介します。
スクラムマスターとは
スクラム開発におけるスクラムマスターとは、どのような位置づけの存在なのでしょうか。
スクラムマスターはスクラムを確立させる「責任者」
スクラムマスターの位置づけを一言で説明すると、スクラムを確立させる「責任者」といえます。
スクラムマスターは、スクラム開発の実施においてスクラムの理論と実践方法を全員に理解してもらえるように手助けをします。
その名前の通り、スクラムマスターはスクラム開発に精通した有識者として、スクラムを成功させるために活動します。
また、スクラムマスターは「スクラムチームと組織に奉仕する真のリーダー」と呼ばれるように、スクラム開発を推進していく上でチームをまとめていく役割を担います。
そのために、スクラムチームがスクラムのフレームワークに沿ってうまく活動できるように、コーチングやファシリテートを行っていきます。
スクラムマスターはプロジェクトマネージャーではない
よくある誤解として、スクラムマスターをプロジェクトマネージャーの位置づけのポジションととらえてしまうことがあります。
ウォーターフォール型のプロジェクトにおいては、プロジェクトを取りまとめ管理を行っていくプロジェクトマネージャーの役割が存在します。
プロジェクトマネージャーは、プロジェクトのリーダーとして、トップダウンでの意思決定やスケジュール・リソースの管理などを行います。
一方で、スクラム開発においてはプロジェクトマネージャーと同様の役割は存在しません。スクラムマスターはあくまで奉仕型のリーダーであり、トップダウンで意思決定を行うことはありません。
スクラム開発という枠組みの中でプロジェクトを円滑に推進し、課題があればそれを解決できるようにサポートしていくという役割を担います。
スクラムマスターと他の役割との違いと関係性
スクラム開発においては、スクラムマスター以外に「プロダクトオーナー」と「開発者」という役割も存在します。以下では、スクラムマスターと他の役割との違いと関係性について整理します。
プロダクトオーナーとスクラムマスター
プロダクトオーナーの役割を一言で表すと「スクラムチームから⽣み出されるプロダクトの価値を最⼤化すること」です。
プロダクトオーナーは開発するプロダクトの結果に責任を持ち、プロダクトの方向性を決める責任者となります。
プロダクトオーナーは、どちらかといえばビジネスサイドの方が担うことが多い役割といえます。
そのため、必ずしも IT やスクラム開発に精通していないことも多くなります。このような場合、スクラムマスターはプロダクトオーナーをサポートしつつ、プロダクトオーナーとスクラムチームの架け橋となり、スクラム開発を成功に導いていく必要があります。
スクラム開発におけるプロダクトオーナーの役割については、プロダクトオーナーの解説記事で詳しくご紹介しておりますので、よろしければ併せてご覧ください。
開発者とスクラムマスター
開発者は、スクラム開発においてプロダクトの開発を担当するメンバーのことです。
少人数で実施するスクラム開発においては、開発者があらゆる作業を担当することになります。スクラム開発に対する理解はもちろんのこと、設計・コーディング・テストなど一連の開発スキルを有していることが求められます。
上述のとおり、スクラムマスターは開発者を統括して管理していく役割ではありません。
開発者がスクラムの枠組みの中で力を発揮できるように、奉仕者として支援していく役割を担います。
デイリースクラムやスプリントプランニングなどの会議体においては、進行役として会議を円滑に進行していくことも必要です。
また、プロジェクトに問題が発生した場合には、その問題の解決方法ついて検討することも必要でしょう。
スクラムマスター・プロダクトオーナー・プロジェクトマネージャーの比較表
ここまでの内容を踏まえて、スクラムマスター・プロダクトオーナー・プロジェクトマネージャーという3つの役割の違いを表に整理します。なお、前述のとおりスクラム開発にプロジェクトマネージャーという役割は存在しないため、ウォーターフォール型プロジェクトにおける一般的な位置づけとの比較となります。
| 項目 | スクラムマスター | プロダクトオーナー | プロジェクトマネージャー |
|---|---|---|---|
| 主な責任 | スクラムの確立とスクラムチームの有効性 | プロダクトの価値の最大化 | プロジェクトの計画と完遂（スケジュール・コスト・品質の管理） |
| 焦点 | チームとプロセス | プロダクトとビジネス価値 | 計画とリソース |
| 意思決定のスタイル | 奉仕型リーダーとして支援し、チームの自己管理を促す | プロダクトバックログの内容と優先順位を決定する | トップダウンで意思決定し、メンバーに指示する |
| 成功の定義 | チームが自己管理し、継続的に改善できている状態 | プロダクトがユーザーとビジネスに価値をもたらしている状態 | 計画どおり（納期・予算・品質）にプロジェクトが完了した状態 |
スクラムマスターの役割や責任
スクラムマスターの位置づけはスクラムを確立させる「責任者」であると紹介しましたが、ここではより具体的にスクラムマスターの役割や責任についてご紹介します。
スクラム開発におけるバイブルといえる「スクラムガイド※」によれば、スクラムマスターの役割は大きく以下の3つとなります。
- スクラムチームのサポート
- プロダクトオーナーのサポート
- 組織全体のサポート
※参考：スクラムガイド（日本語訳版）（新しいタブで開きます）
スクラムチームのサポート
スクラムマスターは、さまざまな形でスクラムチームをサポートしていきます。
具体的には、以下のような取り組みを行っていきます。
〇コーチング
スクラム開発に対する知識や経験が少ない開発者に対して、コーチングによりスキルやノウハウを伝達していく。
〇課題の解決
スクラムチームの進捗を妨げるような課題や障害物が発生した場合、それらを解決・排除できるように動く。
〇スクラムイベントの進行と順守
デイリースクラムやスプリントプランニング、スプリントレトロスペクティブなどの各種スクラムイベントの開催やタイムキーピングなどのファシリテートに加え、各種イベントがポジティブかつ⽣産的なものとなるように動く。
〇作業へ集中できる環境の提供
その他、スクラムチームが品質の高い成果物を作成し、プロダクトの完成という目標に進んでいく作業に集中できるように様々な支援を行う。
プロダクトオーナーのサポート
同様に、スクラムマスターはプロダクトオーナーのサポートを行います。具体的には、以下のような取り組みを行っていきます。
〇プロダクトゴール・プロダクトバックログに関するサポート
プロダクトオーナーがビジネス目標を達成するために作成するプロダクトゴールやプロダクトバックログについて、助言やサポートを行うことで作成や管理をサポートする。
〇プロダクトバックログアイテムの理解浸透
プロダクトバックログアイテムがなぜ必要であり、具体的にどのようなものなのかを開発者に理解してもらえるように、プロダクトオーナーの考えを踏まえて伝達を行う。
〇専門的な知見の提供
プロダクト開発においてインフラ環境や利用するソフトウェア、SaaS など、専門的な知見を踏まえてプロダクトオーナーをサポートする。
〇ステークホルダーとのコミュニケーション支援
プロジェクトを進めていく上で必要となるプロダクトオーナーとステークホルダーとのコミュニケーションについて、支援を行う。
組織全体のサポート
スクラムマスターの役割は、スクラムチームやプロダクトオーナーのサポートにとどまりません。プロダクトを開発する組織全体に対しての支援もスクラムマスターの役割のひとつです。
〇組織へのコーチング
スクラムチーム内だけではなく、組織全体へスクラム開発について指導・トレーニング・コーチする。
〇スクラム開発の進め方についての助言
組織がどのようにスクラム開発を活用していけばよいか、その実施⽅法を計画したり、助⾔したりする。
〇スクラム開発のノウハウ提供
たとえばスクラム開発におけるコストの妥当性など、スクラム開発に関する経験・知見を基に社員やステークホルダーの理解を高める。
スクラムマスターに求められるスキル
スクラムマスターとしてスクラム開発に携わっていくためには、どのようなスキルが必要なのでしょうか。
以下では、スクラムマスターの認定試験であるCSM（Certified ScrumMaster）認定スクラムマスターの取得時に受講するカリキュラムを踏まえてご紹介します。
※参考：Scrum Alliance「SCRUM ALLIANCE CERTIFIED SCRUMMASTER (CSM) Learning Objectives」（新しいタブで開きます）
スクラム開発に関する知見・経験
当然ながら、スクラム開発に関する知見や経験を有していることはスクラムマスターに求められる必須のスキルです。
これまでにご紹介した通り、スクラムマスターはスクラム開発をスクラムチームや組織にインストールするために、スクラムの有識者としてサポートを行うことが求められます。
そのためには、スクラム開発に関する知識が必要です。
スプリントプランニングやスプリントレビューの実施方法や実施時のポイント、プロダクトバックログの作成方法や取りまとめ方など、スクラム開発を進める上でのイベントや作成物に関する知見を基に、他のメンバーへの助言やサポートを行っていくことが求められます。
ファシリテーション力
スクラムマスターは奉仕型のリーダーであり、自身がプロジェクトを取りまとめて意思決定をしていくのではなく、メンバーの意見を引き出し、取りまとめていく力が求められます。
このようなファシリテーション能力はスクラムマスターの役割を担う上で重要なものとなります。
たとえばスプリントプランニングにおいては、プロダクトオーナーの要望や開発者の作業能力などを踏まえ、現実的かつプロダクトゴールに向けて効果的である計画を立てる必要があります。
それぞれの意見が異なる場合には、うまく意見を整理していく必要もあります。
調整力
一般的に、プロジェクトを実施していく上では多数のステークホルダーが存在します。
たとえば経営層はプロジェクトの成否とプロジェクトの成功がもたらす利益について関心があります。
またシステム連携を行う場合は、連携先システムの担当者などもステークホルダーとなるでしょう。
このようなステークホルダーは、多様な意見を持ち、また利害関係も存在します。
一義的にはプロダクトオーナーがステークホルダーとの調整を行うことになりますが、プロダクトオーナーを支援し、調整をサポートしていく力がスクラムマスターには求められます。
コーチング・ティーチング能力
スクラムマスターには、スクラム開発がうまくいくようにメンバーへコーチングやチーティングを行っていく役割があります。
たとえば、プロダクトオーナーがスクラム開発に精通していない場合、スクラムマスターはスクラム開発の進め方やプロダクトバックログの取りまとめ方などについて助言を行い、知識を伝えてしていきます。
単に知見を持っているだけでは、このようないわゆる教育に関する取り組みはうまくいきません。自身が持つ知見を分かりやすく、かつ相手のスキルに合わせて伝えていく能力が求められます。
スクラムマスターの資格
スクラムマスターになるために必須の資格はありませんが、スクラムを体系的に学び、スキルを客観的に示す手段として認定資格が広く活用されています。ここでは代表的な2つの資格をご紹介します。
CSM（Certified ScrumMaster / 認定スクラムマスター）
CSM は、アジャイルコミュニティの国際的な非営利組織である Scrum Alliance が認定する資格です。認定スクラムトレーナーが実施する公式研修を受講したうえで、テストに合格することで取得できます。
研修では演習やディスカッションを交えながらスクラムを体系的に学ぶことができ、日本国内でも研修が開催されています。なお、資格を維持するためには定期的な更新が必要です。
PSM（Professional Scrum Master）
PSM は、スクラムの考案者の一人であるケン・シュエイバー（Ken Schwaber）氏が設立した Scrum.org が認定する資格です。
研修の受講は必須ではなく、オンラインの試験に合格することで取得できます。習熟度に応じて PSM I・PSM II・PSM III というレベルが用意されており、取得した認定に有効期限はありません。
資格の取得自体がゴールではありませんが、スクラムガイドの内容を体系的に理解し、チームや組織と共通言語で対話できるようになるという点で、これからスクラムマスターを目指す方にとって有効な学習の道筋となります。
スパイスファクトリーの現場で実践しているスクラムマスターの工夫
スパイスファクトリーには認定スクラムマスター資格を持つメンバーが複数在籍しており、スクラム開発支援サービスとしてお客さまのプロダクト開発を支援しています。ここでは、当社の現場でスクラムマスターが実践している代表的な工夫をご紹介します。
デイリースクラムを「報告会」にしない
デイリースクラムは毎日開催されるため、続けるうちに「昨日やったことを報告するだけの場」になりがちです。形骸化が進むと、スプリントのゴールに向けた検査と適応の場として機能しなくなってしまいます。
当社の現場では、「昨日何をしたか」ではなく「スプリントゴールに近づくために今日何をするか」「ゴールを妨げるものはないか」を中心に話すよう問いかけを変えたり、タスクボードを見ながらアイテム単位で状況を確認したりと、目的に立ち返るファシリテートを行っています。
また、発言がスクラムマスターへの報告にならないように、開発者同士が互いに向けて話す形を促すことも意識しています。
障害物リストの見える化
デイリースクラムなどで挙がったチームの障害物（インペディメント）は、その場で聞き流さずにリストとして見える化します。タスクボードと並べて障害物リストを管理し、誰が解消に動いているのか、解消されたのかをチームの誰もが確認できる状態にしておくことで、課題の放置を防ぎます。
障害物が解消された事実をチームに共有することも重要です。「挙げれば解決に向かう」という実感が積み重なることで、チームは課題を早い段階で口に出せるようになります。
チームの成熟に合わせて関わり方を変える
スクラムマスターの支援は、常に同じ濃さである必要はありません。スクラム開発に慣れていない立ち上げ期には、ティーチングやファシリテーションを手厚く行い、スクラムイベントの目的や進め方をチームに定着させます。
チームがスクラムに慣れてきたら、答えを教えるのではなく、問いかけによって気づきを促すコーチング中心の関わりに移行します。レトロスペクティブでチーム自身が課題を発見し、改善策を実行できるようになってきたら、スクラムマスターは一歩引き、チームの自己管理に委ねる範囲を広げていきます。
このように関わり方を段階的に変えていくことが、「スクラムマスターがいなくても回るチーム」、すなわち自己管理するチームの育成につながります。
スクラムマスターの知識でスクラム開発を成功させよう
この記事では、スクラムマスターの役割や必要なスキルについてご紹介しました。
スクラム開発がうまくいくかどうかは、スクラムマスターのスキルによるところも大きいといえます。
特に、メンバーがスクラム開発に慣れていない場合、スキルや経験を備えたスクラムマスターが活躍します。
自社にエンジニアリソースが存在しない場合は、アジャイル開発やスクラム開発に精通した外部メンバーにスクラムマスターの役割を依頼することも有効です。
高いスキルを持ったスクラムマスターがチームに存在することで、スクラム開発を成功に導くことができます。
スパイスファクトリーでは、アジャイル開発・スクラム開発によりこれまで多数のお客さまのシステム開発を支援してまいりました。
アジャイル開発でプロジェクトを実施したいという方は、ぜひお声がけください。
IT人材の不足やコストメリットから、海外に業務を委託するオフショア開発に目を向ける企業は少なくありません。しかし、期待した効果を得られず、結果的に失敗してしまうケースがあります。この記事では、オフショア開発初心者の方や一度失敗したことがある方に向けて、失敗例をもとに原因と対策を紹介します。
スパイスファクトリーはフィリピンにオフショア拠点を持ち、徹底した品質管理と円滑なコミュニケーションで「ハイクオリティオフショア開発」を提供してきました。オフショア開発に関する具体的な相談がある方は、お問い合わせください。
以下の記事も参考にどうぞ。
オフショア開発会社の選び方とは？確認すべきポイントを解説（新しいタブで開きます）
オフショア開発のよくある失敗例
オフショア開発（新しいタブで開きます）を進める中で「これなら日本国内で開発した方が良かったかも……」という結果になってしまうことは残念ながらよくあります。この章では、オフショア開発のよくある失敗例を紹介します。
成果物が低品質
納品されたプロダクトやサイトの品質が想定以上に低いのは、オフショア開発でよくある失敗のひとつです。
たとえば、以下のようなケースが考えられます。
-
- 正常に動かない
- 表示崩れがある
- 必要な機能がない
- 想像していたデザインと違う
成果物が低品質なのは、エンジニアの質が低いという原因だけではありません。
事前に明確な仕様を伝えていなかったり、依頼側としてはよしなにやってくれると思っていたが、期待と違っていたりといったケースもあります。
オフショア開発のメリットとして比較的コストを抑えられると知られています。しかし、上記の通り品質に関わる失敗例が多いため、オフショア開発に安かろう悪かろうのイメージを持っている人も少なからず存在するのが現状です。
納期が守られない
スケジュール通りにプロジェクトが進まず、納期が遅れるのもオフショア開発でよく聞く失敗のパターンです。
納期遅れの理由としては、初期のスケジュール設計の際に要件が整理されておらず、後から追加の開発が必要だと判明する、という国内でもよくあるケースが挙げられます。
また、残業してまで納期に間に合わせようという感覚がないといった、納期にややルーズな文化がある国も存在するため、管理がうまくいかず遅延につながる場合もあります。
予算をオーバーしてしまう
日本国内での開発でも同様ですが、請負契約の場合は基本的にプロジェクト期間中の仕様変更ができません。
追加機能など後から必要な開発が増えると、想定以上に費用がかかってしまうでしょう。
オフショア開発では、言葉や文化の壁による品質低下や納期遅れをカバーするために、追加費用が必要となることも考えられます。さらに、経済・為替の状況で単価が高騰するといった外部環境に影響を受けて予算を超えてしまうケースもあります。
また、オフショア開発ではプロジェクトの立ち上げ時にイニシャルコストがかかります。
メンバーの構成やルールの明文化などの体制構築やコミュニケーションに時間がかかるためです。
上記から、短期間のプロジェクトではオフショア開発のコストメリットを享受できないこともあります。
なぜオフショア開発は失敗するのか
前の章で紹介した通り、オフショア開発にはよくある失敗パターンがあります。なぜそのような失敗が起きてしまうのでしょうか。ここではその原因を解説します。
コミュニケーションの行き違い
コミュニケーションの行き違いはオフショア開発において最もよく起こる、かつ根深い問題の1つです。
言語が違うだけでなく、文化や商習慣にもギャップがあり日本の常識が通用しません。
お互いの「普通」の感覚がズレているため、行き違いが生じてしまいます。
さらに、コミュニケーション齟齬の内訳として 3点ご紹介します。
言語の違いから起きる行き違い
母国語を使わない会話では、どうしても細かい部分を伝えられません。
相手の言葉を間違って理解してしまうこともあるでしょう。
オフショア開発では、要件定義書を用意して開発先に渡し、現地でブリッジSE（新しいタブで開きます） や PM などが現地語または英語に翻訳して作業するといった形がとられます。その翻訳時に、誤訳や誤読があると、依頼側の意図とは異なる仕様で開発が進むというミスが発生します。
文化の違いから起きる行き違い
生活習慣や商習慣など、文化の違いからも行き違いが発生します。
日本人には「よしなにやる」「阿吽の呼吸」に代表されるように、相手の意図を汲み取って柔軟に仕事を進めることがよくあります。しかし、基本的に外国籍のメンバーには「そのあたり、うまくやっといてください」などの曖昧な指示は通用しないと考えておくべきでしょう。「そのあたり」とは何か、「うまくやる」とは具体的にどういうことか、「いつまでに」するのかを具体的に伝える必要があります。
他にも、仕事に対する価値観や年中行事の違いにも注意が必要です。
たとえば、フィリピンではクリスマスなどのイベント近くでは「家族」の優先順位が仕事を圧倒的に上回り、ベトナムではとりわけテト（旧正月）を大事にします。当然ながら国民の祝日も日本とは異なりますので、スケジュールを決める際には注意が必要です。
物理的な距離から生じる行き違い
物理的な距離から生じる行き違いも存在します。
拠点としている国と日本との時差によっては、必要なタイミングでのクイックな連携は難しいでしょう。
対面コミュニケーションには細かなニュアンスを伝えやすかったり、気軽にコミュニケーションが取れたり、雰囲気などの非言語情報を得やすいなどのメリットがあります。
海外にチームがある場合、どうしてもこのメリットを受けにくい体制となるためコミュニケーションに行き違いが発生しやすくなります。
管理体制の未整備
言語や文化差・距離によるコミュニケーション齟齬は、どれだけ配慮しても完全になくすことが難しい問題といえるでしょう。
オフショア開発ではそうした違いを前提としたうえで、品質を担保するための管理体制の構築が重要となります。
この管理体制がうまく機能しない場合も、失敗を引き起こしてしまいます。
以下に管理体制の構築がとくに必要な領域をご紹介します。
コード品質の管理
オフショア開発においては、依頼側が認識しているレベルのコード品質が担保できるように、レビューやテストなどの体制整備が欠かせません。
エラーが出ないか、といった一般的なシステムテストの実施はもちろん、単に動くだけでなくメンテナンス性を考慮したコード品質の管理体制が重要です。
コード品質の管理体制が機能していない場合、仕様書通りの動作はするもののパフォーマンスが悪かったり、リリース後に多くのバグが発生したりといったことが懸念されます。
プロジェクトマネジメントの体制不備
先述の理由からコミュニケーションの行き違いが起こりやすいオフショア開発においては、国内での開発以上にプロジェクトマネジメントが重要といえるでしょう。
言語や文化の違いを踏まえて、余裕を持ったスケジューリングや突発的なトラブルへの柔軟な対応が求められます。
たとえばベトナムでは「就社」ではなく「就職」の意識が強いといわれています。
今の会社でスキルを身につけ、成果を出して早く次の会社に転職して給料を上げたいと考えているため、プロジェクトの途中で担当エンジニアが変わるといったことはめずらしくありません。
そのような場合でもプロジェクト自体の遅延等が発生しないようにあらかじめ引き継ぎがしやすいような体制やチームメンバーがフォローしあえるようなルール・仕組み作りが大切です。
この点が体制として担保されていない場合、体制維持が難しくなりプロジェクト進捗や品質に影響を及ぼします。
失敗しないための対策
ここまで、オフショア開発のよくある失敗とその原因について確認してきました。
この章では、失敗を避けるために取るべき対策について解説します。
請負契約で自社がオフショア開発拠点をマネジメントする必要がない場合もプロジェクト成功のために協力は必須です。どういった点で協力できるのかを確認しておきましょう。
また、ベンダー選定の軸として、以下で紹介する内容ができている会社か確認をすることをおすすめします。
ラボ型の場合
ラボ型オフショア開発（新しいタブで開きます）の場合、オフショアメンバーが依頼する企業側のチームに参画するため、依頼企業側が直接マネジメントに入るケースが多いでしょう。
マネジメントにあたり、以下のような対策が必要です。
文化差の理解
基本として、文化差への理解と対応が必要です。
言語の違いはもちろん、日本の働き方の常識は通用しないことを前提としたうえで、協力して業務を進められる体制を構築します。
また、時差に関しては修正ができないため、気になる場合はフィリピンなど日本との時差の少ない（フィリピンは時差1時間）オフショア拠点を持っている企業に依頼することを検討しても良いでしょう。
ドキュメント化の徹底
コード規約や各種ルール、決定した仕様、その他技術的なナレッジも含め明確にドキュメント化して共有しましょう。
仕様や決定事項が明文化されれば、認識の行き違いを小さくできます。
仕様や技術的知見を蓄積しておくことで、万が一引き継ぎが発生した場合も柔軟な対応がしやすくなります。
ブリッジSE ・ QAエンジニアなどの参画でコードレビュー・機能テストを実施
オフショアメンバーに必要なコードの品質を理解してもらうことも重要です。
先述したドキュメント化でルールや共通認識を定めるのに加え、QAエンジニア（新しいタブで開きます）によるテスト・機能チェックやブリッジSE（新しいタブで開きます） によるコードレビューで品質の担保と基準レベルの共有を行えます。
※参考記事①：ブリッジSEとは？オフショア開発での役割と必要性、注意点も解説
※参考記事②：QAエンジニアの重要性とは？システム品質を保つプロが求められる背景や役割を解説（新しいタブで開きます）
可能な限り仕様の具体化
曖昧な情報から忖度して仕事を進めるのは、日本人ならよくあることです。しかし、これまでにお伝えしたとおり、オフショア開発においてこういった仕事の進め方は通じません。
そのため、日本側のメンバーで可能な限り仕様を具体的にしたうえで着手してもらうといった、依頼者側の工夫も必要です。
請負型の場合
請負型の場合、開発を依頼された側の企業がオフショア拠点を管理します。
実際の対策については基本的にラボ型の場合と共通です。加えて、直接管理を行わない依頼企業として、失敗を引き起こさないために協力できる点を以下で紹介します。
要件の具体化・明確化
曖昧な仕様が伝わらないのは先述のとおりです。
依頼側としても要件を明確にして提示することで認識の行き違いを減らせます。
直接的な管理をしないからと任せきりにならず、具体的にしてドキュメントなどで行き違いがないように伝えましょう。
企業選定時に実績等を確認しておく
日本国内でも同様ですが、依頼するシステムや制作物の類似案件を手掛けているなど、実績を把握しておくことで品質レベルが推し量れます。
依頼しようとしているシステムの類似案件の実績がある企業を選べば、失敗のリスクを下げられるでしょう。
どのような対策をしているか確認する
本記事で紹介してきた課題に対し、どのような対策を講じているのか聞いてみることをおすすめします。
何らかの対策ができている企業であれば、快く対策内容を教えてくれるでしょう。
何の対策もされていない場合は、依頼を考え直すことも必要です。
体制に不安が残る企業への依頼を避ければ、オフショア開発で失敗するリスクを減らせるでしょう。
課題はどの会社も抱えている
オフショア開発を実施する場合、大小の差はあれど、どの企業も今回ご紹介したような課題を抱えているでしょう。
重要なのは課題がないことではなく、課題に対して適切な対策を講じることができているかどうかです。
当社スパイスファクトリーでは、社内QAエンジニアによる「機能レベルの外部品質担保」とブリッジエンジニア／エンジニアリングマネージャーの 2重レビューによる「コードレベルの内部品質担保」、現地駐在責任者によるマネジメント体制構築や CTO による直接の技術指導、などを実施してオフショア開発の課題解消に取り組んでいます。
オフショア開発の依頼を検討している方はお問い合わせください。
本記事の内容が皆様のお役に立てれば幸いです。
https://spice-factory.co.jp/service/offshore-development/
海外にシステム開発を委託するオフショア開発に注目が集まっています。かつてオフショア開発はコスト削減を主目的に行われましたが、最近は事情が少し変わっています。
この記事ではオフショア開発の基本的なメリットや課題、日本における最新の市場動向を解説します。
当社、スパイスファクトリーでもオフショア開発を提供しています。オフショア開発に関するお悩みがある方はぜひお問い合わせください。
オフショア開発とは
オフショア開発とは、システムの開発業務における一部もしくは全部の工程を海外の業者に対して委託することを意味します。
正式名称はオフショアリング開発（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/
企業がスマートフォンアプリの提供を行う際に、PWA（Progressive Web Apps） の活用は一つの有効な選択肢となります。PWA はネイティブアプリと Webアプリの良いところを併せ持っており、かつアプリ開発におけるコストを抑えやすいというメリットがあります。一方で、ユーザーの認知度が低いことや機能に制約があるなど、使いどころの見極めも重要となる技術です。
この記事では、PWA の概要やその仕組み、他の開発手法との比較などの解説を通して、PWA がどのようなものなのか、またどのようにビジネスに活用していくべきなのかをご紹介します。
当社、スパイスファクトリーでは、アジャイル開発の受託開発サービスやWebアプリ・サービス開発支援を提供しております。
スマホアプリやWebアプリケーションについてのご相談がある方は、Webサービス開発のページをご覧のうえ、是非お問い合わせください。
まず、PWA の要点を1枚にまとめると次のとおりです。
| 項目 | PWAの要点 |
|---|---|
| PWAとは | Webサイトをネイティブアプリのように端末へインストールして利用できる仕組み（Progressive Web Apps） |
| アプリストア | App Store・Google Play を経由せず、Webサイトから直接インストールできる |
| 主なメリット | 開発・保守コストを抑えやすい／インストール障壁が低い／検索（Web）からの流入が見込める |
| 主な制約 | 一部のネイティブ機能・センサー類の利用に制約がある／アプリストア経由の露出は得にくい |
| iOS対応（2026年現在） | iOS 16.4（2023年3月）以降、ホーム画面に追加したPWAでプッシュ通知が利用可能 |
| 向いているケース | 既存の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 より発表されています。
※2026年追記：このプッシュ通知対応は、2023年3月公開の iOS 16.4 で実現済みです。最新の状況は後述の「PWAのiOS対応はどこまで進んだか【2026年最新動向】」で解説しています。
iPhoneにおいても2023年中にプッシュ通知が可能に
2022年6月6日 の Apple WWDC（世界開発者会議）にて、2023年に iOS が Webプッシュ通知に対応すると発表されました。
従来、iOS では PWA によるプッシュ通知は実現できませんでしたが、この対応により PWA でもプッシュ通知が可能となります。
プッシュ通知はユーザーにアプリへのアクセスを促す効果的な方法であり、マーケティングなどの用途において活用したいニーズが高い機能といえます。
これまで、iOS でプッシュ通知が実現できない点は、PWA によるアプリ提供のひとつのネックとなっていました。
Apple のこの対応により、ビジネスにおいて PWA を活用する価値がさらに高まっていくと思われます。
PWAのiOS対応はどこまで進んだか【2026年最新動向】
前章は本記事の公開当時（2023年2月）の情報です。その後、PWA の iOS対応は実際に大きく前進しました。2026年現在の状況を整理します。
iOS 16.4でホーム画面のPWAからのプッシュ通知に対応（2023年）
Apple は、2023年3月公開の iOS/iPadOS 16.4 で、ホーム画面に追加した Webアプリ（PWA）からの Webプッシュ通知に正式対応しました。
これにより、「iOS ではプッシュ通知が使えない」という PWA の最大のネックは解消され、iPhone・Android の両方でプッシュ通知を前提としたコミュニケーション設計が可能となっています。
ただし、iOS でプッシュ通知が利用できるのはホーム画面に追加された PWA のみで、Safari で Webサイトを閲覧しているだけの状態では通知を送れない点には注意が必要です。
参考：Web Push for Web Apps on iOS and iPadOS | WebKit（新しいタブで開きます）
EU圏でのサポート縮小予告と撤回（2024年）
2024年には、EU のデジタル市場法（DMA）への対応をめぐり、Apple が EU圏でのホーム画面Webアプリのサポート縮小を予告し、大きな議論となりました。
開発者やユーザーからの強い反発を受けて Apple は最終的にこの方針を撤回し、ホーム画面Webアプリの提供は EU圏を含めて継続されています。
宣言型Webプッシュなど、機能拡充は現在も継続（2025年〜）
2025年公開の iOS/iPadOS 18.4 では、Service Worker の実装を必要とせずにプッシュ通知を送れる「宣言型Webプッシュ（Declarative Web Push）」がホーム画面のWebアプリ向けに追加されるなど、PWA関連機能の拡充は現在も続いています。
参考：WebKit Features in Safari 18.4 | WebKit（新しいタブで開きます）
それでも残るiOSの制約
一方で、iOS ではプッシュ通知の利用がホーム画面に追加された PWA に限られるほか、バックグラウンド動作や一部のネイティブ機能・センサー類へのアクセスに制約が残るなど、ネイティブアプリとの機能差は依然として存在します。
とはいえ、「iPhone ではプッシュ通知ができないため PWA は選びにくい」という状況はすでに過去のものとなっており、2026年現在、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」や、Adobe社が提供する「PhoneGap」など、個別企業が提供しているものが多く、フレームワークの継続性という観点でリスクがある点には注意が必要です。
※2026年追記：「PhoneGap」は2020年に提供終了となりました。現在は「Capacitor」などの後継フレームワークや、「React Native」「Flutter」といったクロスプラットフォーム開発技術が広く利用されています。
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%増加しました。
Spotify社
音楽のストリーミングサービスを提供する Spotify社では、ネイティブアプリの提供に加えて、自社サイトの PWA化も実施しています。
PWAアプリではネイティブアプリと同様の機能を提供しつつ、より操作感に優れるネイティブアプリへの導線も用意。
エントリーユーザーには PWAアプリという選択肢を提供しつつ、ネイティブアプリの利用も促進しています。
PWAアプリの提供により、60日以内のユーザーのリテンション率が 14%増加するなどの成果を挙げています。また、Web版ユーザーの 30%がネイティブアプリのダウンロードを行うなど「ヘビーユーザー化」へのステップとしても効果を発揮しています。
なお、Spotify社では PC のデスクトップで PWAアプリを利用できるデスクトップPWA についても併せて提供しています。
参考：Spotify PWA: Why People Love It – Tigren（新しいタブで開きます）
なお、ここで紹介した各社の数値は、いずれも PWA導入当時（2016〜2018年前後）に公表されたものです。日経電子版をはじめ、PWA化から年数を経た現在もWebアプリとしての提供を続けているサービスは多く、PWA は一過性の流行ではなく、Web の体験を高める標準的な選択肢のひとつとして定着しています。
これらの事例が示すように、PWA化により自社の既存Webサイト資産を生かしつつ、ユーザーのアクセス頻度やコンバージョン率などを向上させることができるといえます。
開発会社の現場から見たPWAの使いどころ
スパイスファクトリーは、Webサービス・スマートフォンアプリの受託開発を数多く手がけてきました。その経験から、PWA を検討する際に現場でお伝えしているポイントを紹介します。
- 「まずネイティブアプリありき」で考えない（ご相談の内容を整理すると、実現したい体験は PWA やレスポンシブWebサイトで十分に実現できるケースが少なくありません。要件から逆算して開発手法を選ぶことで、初期投資を大きく抑えられます）
- ストア審査・OSアップデート追従まで含めた総コストで比較する（ネイティブアプリは開発費だけでなく、ストア審査への対応や OSバージョンアップへの追従といった継続的な運用コストが発生します。数年単位の総コストで比較すると、PWA の優位性が明確になる場合があります）
- 既存WebサイトのUI/UX改善とセットで検討する（PWA は既存のWebサイトを土台とする仕組みのため、Webサイト自体の使いやすさがそのままアプリの体験になります。PWA対応と UI/UX改善を同時に行うことで、投資対効果を高めやすくなります）
こうした開発手法の選定を含むWebサービス開発の支援内容は、Webサービス開発のページで紹介しています。
PWAに関するよくある質問（FAQ）
PWAとネイティブアプリはどちらを選ぶべきですか？
機能性や操作性を最重視する場合や、スマートフォンの機能をフルに使いたい場合はネイティブアプリが適しています。既存のWebサイト資産を生かしたい場合や、開発コスト・インストール障壁を抑えたい場合は PWA が有力です。ライトユーザー向けに PWA、ヘビーユーザー向けにネイティブアプリと併用する方法もあります。
iPhone（iOS）でもPWAのプッシュ通知は使えますか？
使えます。2023年3月公開の iOS 16.4 以降、ホーム画面に追加した PWA からプッシュ通知を送れるようになりました。ただし、Safari で Webサイトを閲覧しているだけの状態では通知を送れないため、ユーザーにホーム画面への追加を促す導線設計が重要です。
PWAをApp StoreやGoogle Playで配信することはできますか？
Google Play では、Trusted Web Activity（TWA）という仕組みを使って PWA をストアアプリとして配信できます。App Store については、Webサイトを単純にアプリ化しただけのものは審査基準上認められにくいため、ストア配信を重視する場合はネイティブアプリやハイブリッドアプリの検討が必要です。
既存のWebサイトをPWA化するには何が必要ですか？
基本要件は、サイト全体のHTTPS化、アプリとしての表示方法を定義する Web App Manifest の用意、オフライン動作やキャッシュを担う Service Worker の実装の3点です。既存サイトの構成によっては段階的な対応も可能なため、まずは現状のサイトを診断することをおすすめします。
PWAの開発費用はネイティブアプリより安くなりますか？
一般的には、iOS・Android・Web を1つのコードベースで提供できるため、個別に開発するよりもコストを抑えやすくなります。ただし、要件や既存サイトの状態によって工数は大きく変わるため、実現したい体験を整理したうえで開発会社に相談することをおすすめします。
PWAはユーザーの体験価値を高めるための選択肢
この記事では、PWA の概要や仕組み、他の開発手法との比較などを行いました。
PWA は使いどころを意識して利用することで、ビジネス面でのメリットを得ることができる手法といえます。
スパイスファクトリーでは、この記事で紹介した PWA の開発も含め、スマートフォンアプリの開発をアジャイル型により実現します。
スマートフォンアプリの導入にあたっては、目的に合わせて適切なユーザー体験を提供できる開発方法の選択が必要です。
スマートフォンアプリの導入を検討されている方は、Webサービス開発のページをご覧のうえ、ぜひ一度お問い合わせからご相談ください。
また、当社ではLINEミニアプリによるアプリ提供についても対応可能です。詳細については、こちらの記事（新しいタブで開きます）をご覧ください。
https://spice-factory.co.jp/tips/line-mini-app-individual-development/
