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

ビジネスにおける国際化と IT人材不足が増える中で、オフショア開発の重要性は日増しに高まっています。アジアの中でもフィリピンは、オフショア開発の先進国として成長し、そのスキルやコストパフォーマンスを高く評価されています。さらに英語が公用語で、高品質なサービスを低コストで提供できる能力があることから、多くの企業がフィリピンをオフショア開発先として選んでいます。本記事では、フィリピンのオフショア開発のメリットとデメリットを掘り下げて解説します。

フィリピンの概要

まずはフィリピンはどのような国なのか、人口や国民性など概要を説明します。日本とは違う文化で、異なる価値観が生み出すオフショア開発の利便性をみていきましょう。

フィリピンはどんな国？

オフショア開発を得意とするフィリピンは、どんな国でどのような価値観をもっているのか、そのバックグラウンドを解説します。

人口・国民性

フィリピンの人口は、2020年フィリピン国勢調査によると、約1億903万人です。
主にマレー系が大多数を占めており、ほかに中国系、スペイン系、その他少数民族もいます。

マレー系のフィリピン人は、一見物静かですが顔見知りになるととてもフレンドリーな人が多く、細かいことはあまり気にしない大雑把な性格の傾向にあります。

一方で中国系のフィリピン人は、礼儀正しく勤勉な人が多く、仕事にも真摯に向き合う人が多いといわれています。日本人にも友好的な人が多く、時間を守る傾向にあるので、オフショア開発ではかかせない人材として重宝されています。

宗教

フィリピン人は、東南アジアで唯一のキリスト教国で、国民の約9割がキリスト教を信仰しています。
宗教に対する考え方は、国や信仰する宗教によっても違うため、オフショア開発を進めるうえで、キリスト教および一部その他の宗教も理解して受け入れていく必要があります。

また、一般的に日本人よりも宗教が深く浸透している傾向にあるため、たとえば働く日時や宗教に関する祝日などは、より理解が求められるでしょう。

主要言語

フィリピンの公用語は、第一言語がフィリピノ語で、第二言語は英語です。公的な場や教育現場でも英語が使用されているため、フィリピン人の英語力は高く評価されています。

フィリピン人の英語力は、スウェーデンの EF が提供する英語能力指数（新しいタブで開きます）によると、アジア内では2位（世界では22位）で、世界的にも非常に高い水準であることがわかります。

フィリピンでのオフショア開発の将来性

オフショア開発拠点として人気のフィリピンですが、この先さらに需要が増すのでしょうか。コストパフォーマンスや人材育成など、複数の目線でフィリピンでのオフショア開発の将来性について解説します。

豊富な労働人口

前述の通り、フィリピンの人口は、2020年フィリピン国勢調査によると約1.1億人です。2030年頃になると1.25億人となり、2050年ごろまで増加すると予測されています。

また、2020年時点でフィリピンの平均年齢は25.3歳※です。このことからも若年層が多いことがわかります。そのため、これから経験値が増えスキルアップが見込まれることから、中・長期的に見てもフィリピンの貴重な人材には将来性があるといえるでしょう。
※参考：WCL Solutions（Phil.） Corp..『平均年齢、2020年25.3歳に(15年24.3歳)』（新しいタブで開きます）

戦略的投資優先計画（SIPP）

フィリピン政府が発表した2022年版の「戦略的投資優先計画（SIPP）」によると、デジタルやテクノロジーの分野も税制優遇等を受けられる産業として位置付けられています。

そのため、多くのテクノロジーや IT分野の企業が、国から税制優遇を受けながら事業を拡大させていくと考えられ、オフショア開発を含めた今後の IT領域の発展が見込まれています。

※戦略的投資優先計画（SIPP）
記載された業種・事業は各種優遇措置が受けられる。2022年版 SIPPは、2022年5月24日に承認されました。

フィリピンでのオフショア開発のメリット

次にフィリピンでのオフショア開発のメリットを、以下の3つの観点から解説します。

• IT人材育成
• 地理的距離
• コストパフォーマンス

IT人材

フィリピンでは、教育現場でも英語が使われており英語が公用語であることと、地域差はあるものの IT教育を受けて育った人が多いのが特徴です。
2020年の調査によるとフィリピンの IT技術者は約18万人です。
絶対数は同時期の日本より少ないものの、国が全面的に IT技術の支援を行っている背景や IT分野の教育の充実を考えると、今後のフィリピンの IT技術者は増え、期待以上の成果も見込まれます。
日系企業も含む、多くの外資系企業が進出しており、フィリピン人にとっては外資系企業で働く事は珍しいことではありません。グローバルな環境の中で育ち、明るく前向きな性格が多いことから、多国籍企業に適していると考えられます。

また、フィリピンの平均年齢が25.3歳ということもあり、進歩や変革が早い IT分野への適応能力や成長が見込まれる将来性という意味でも期待値が高いといえるでしょう。

地理的距離

日本とフィリピンは物理的距離も近く、日本からは4時間程度で現地に到着するため、定期的に赴くハードルは比較的低いでしょう。

また、時差が一時間しかないのもメリットで、日本国内のメンバーとオンラインミーティングをするのもチャットでやりとりするのもさほど調整は必要ありません。ほぼリアルタイムで進行できるので、ストレスなく仕事を進められるでしょう。

コストパフォーマンス

フィリピンにおける人件費は近年上昇中ですが、それでもまだ日本国内に比べればコストパフォーマンスは良いといえるでしょう。
フィリピンの一般的なエンジニアコストに関しては以下の記事にて紹介していますのでぜひご参照ください。
参考：「オフショア開発とは？簡単にわかるメリットや最新の市場動向」（新しいタブで開きます）

また、アジアトップクラスの英語力や英語圏のカルチャーへの親和性も大きな魅力です。
多国籍チームでの開発体制においても英語が使えるため連携が比較的容易ですし、アメリカなど英語圏向けプロダクトなど海外進出を見据えた開発する拠点としても魅力的です。

フィリピンでのオフショア開発のデメリット

フィリピンでのオフショア開発のメリットを解説してきましたが、残念ながらデメリットも存在します。次はフィリピンでのオフショア開発をする際のデメリットを解説します。

日本語人材の不足

英語が公用語とはいえ、日本人としてはやはり日本語でコミュニケーションが取れるのがベストです。しかし、フィリピン人の日本語レベルは必ずしも高いとは言えないため、コミュニケーションに問題を感じる人も多いでしょう。

加えて 2020年3月以降、新型コロナウイルス対策でフィリピンでは2年以上にわたり対面授業が行われない状況が続いたことで、日本語の教育機関や学習者の数が大きく減少したことはネガティブな事実といえるでしょう。

独立行政法人国際交流基金（JF）の調査※によると、学校での日本語教育では、機関数は37機関（前回調査比24.8％）、学習者数は7,096人（前回調査比27.1％）減少しています。
教育省が策定するガイドラインに基づいて2020年3月以降 2年以上にわたり対面授業が実施されておらず、出勤抑制も厳格に運用されてきた影響によるものです。一方で、学校以外での日本語教育では、減少した機関数は53機関（前回調査比26.6％）、学習者数は23人（前回調査比0.1％）の増加と、ほぼ横ばいです。
日本語への興味関心は一定数あるものの、事実上教育機関が減少していることから、今後は日本語が話せる人材がさらに不足していくことも懸念されます。

※参考：国際交流基金（2022）.『2021年度 海外日本語教育機関調査』（新しいタブで開きます）

文化差・常識の違い

日本で一般的といわれる常識がフィリピンも同じではありません。文化も違えばバックグラウンドも異なるため、その違いを理解することは必須です。

たとえば日本の会社で「報・連・相」は当たり前ですが、フィリピンではこまめな相談をすることはあまりなく最初と最後の報告程度ということが一般的です。この点を日本のやり方を押し付ける形で対応してしまうと反感を持たれてしまうことも。一方で、進行の遅延や成果物の品質担保をするためにはある程度の「報・連・相」は譲れないというのが日本人の感覚でしょう。こうした違いに折り合いをつけるためには、「なぜそれが必要なのか」丁寧に説明して理解してもらう必要があります。

また、フィリピン人は仕事より「家族」の優先度が高く、キリスト教徒が多いことからクリスマス周辺は仕事の優先度が大きく下がります。そのため、スケジュールを決める際には注意が必要です。日本とは異なる文化・常識であることを意識しておく必要があるでしょう。

労働人材の流動性

フィリピンは、日本よりも離職率が高く、仕事を流動的に変える文化があります。
弊社の経験上ではありますが、日本と比較すると離職率は体感で3倍ほどでしょうか。仕事を覚えても 3〜4年で離職するといったことは珍しくありません。
特定の人材に依存した業務の体制はリスクが伴うことを心得ておくと良いでしょう。

メンバーの意見を尊重しスキルアップの機会を与え、責任のある仕事を任せてみるなど離職したくない環境を作ることが大事です。

ネットワーク通信環境

​​フィリピンのインターネット普及率は高く約 91% といわれてます。しかし、通信速度が 78.33Mbps と日本より 50Mbps 以上遅いのが一般的なため、日本で快適な速度で動く Wi-Fi を使用されているとストレスを感じるかもしれません。通信速度は仕事の効率化や生産性の向上にもつながるため、早いに越したことはありません。

とくにフィリピンで開発業務を行う場合は、まず安定した回線環境を整える必要があるでしょう。

フィリピンでのオフショア開発のデメリットに対する対応策

次に、オフショア開発のデメリットに対する対応策を説明します。

• 日本語人材の不足に対する解決策
• 文化差・常識の違いに対する解決策
• 労働人材の流動性に対する解決策
• ネットワーク通信環境に対する解決

これらのデメリットを解決または許容できればオフショア開発を検討すると良いでしょう。

日本語人材の不足に対する解決策

日本語が話せる人材不足に対する問題は、日本語と英語が堪能な「ブリッジSE（新しいタブで開きます）」をアサインすることにより解決します。
英語や現地語がわからず意思疎通できないといった悩みを、日本語を理解できるエンジニアが言葉の橋渡しをしてくれるので、解釈の違いやニュアンスの違いといった細かな部分まで指示することが可能です。

開発業務においては、言葉の理解だけでなく事業の背景やプロジェクトの課題や問題を即座に理解する必要があります。特にプロジェクト立ち上げの初期段階は、スピード感をもって動く必要があり、言葉の理解とコミュニケーションは必須のため、ブリッジSE は重要な役割を担います。
※参考記事：ブリッジSEとは？オフショア開発での役割と必要性、注意点も解説（新しいタブで開きます）

文化差・常識の違いに対する解決策

国が違えば文化が違い、常識は通用しないということを理解する必要があります。
これを実現するには、まずお互いがどのような考えを持ち、どのようなことに価値観を持っているのか等話を聞くこと、そしてお互いの文化や考え方を知り、理解することが大事です。

特に初期段階はトラブル発生はある程度は覚悟する必要があります。価値観の違いは大きなトラブルを生みかねないので、理解できないことがあれば都度充分に話し合い、お互いを理解する努力が必要になるでしょう。
また、理解するためのコミュニケーション機会を創出する仕組みも重要です。後述する離職率の高さへの対応にも共通しますが、社内コミュニケーションが柔軟にとれるような体制や仕組み・制度を整えることも必要です。

労働人材の流動性に対する解決策

大前提として文化の違いも大きく、日本人と比較して転職に対するハードルがそもそも低いことは理解しておく必要があるでしょう。
客観的に会社に大きな問題がないとしても離職は発生します。
一方で、離職の要因の一つには企業側の問題もあると考えることが重要です。これはオフショア開発企業に限ったことではありませんが、離職率を下げるためには企業側の改善は必須です。
いわゆるブラックな労働環境を提供していないかといったことはもちろん、働くメンバーが気持ちよく働ける環境や適切な待遇を与える仕組みを整えていく必要があります。

たとえば当社、スパイスファクトリーのオフショア拠点では具体的に以下のような対策を行っています。

• • 社内コミュニケーションの促進
  • 月次イベントの開催
  • インセンティブ制度等の福利厚生を充実化する
  • 細かな人事評価制度を整える

スキルアップのための研修やインセンティブ制度等の充実といった、メンバーにとっても会社にとってもメリットのある制度から整えていくと良いでしょう。
ほかにも福利厚生を充実させたり、社内コミュニケーションの風通しを良くしたりなど、目に見えない企業カルチャーに至るまで働きやすさを追求することが離職率を低下させることに繋がります。

ネットワーク通信環境に対する解決策

フィリピンで通信回線を引く多くの企業は、2社以上のインターネットプロバイダーと契約することで対策を講じています。
仮にどちらか 1回線でトラブルが起きても、もう片方の回線を利用できるため、この方法が一般的な通信環境の対策となっています。

オフショア開発の成功は国と文化・メンバーの特徴を相互理解することが鍵

この記事では、フィリピンのオフショア開発の特徴についてご紹介しました。
魅力的なメリットを豊富に有する一方で、日本の開発環境と比較した際にデメリットもあります。これはフィリピンに限らず、どの地域におけるオフショア開発でも同様です。
オフショア開発を成功させるためには、そのメリット、デメリットの両方を理解し、現地のメンバーと信頼関係を築いていくことが重要です。

スパイスファクトリーでは、フィリピンでのオフショア開発の相談も可能です。フィリピンでのオフショア開発についてお悩みがありましたら、ぜひお気軽にお問い合わせください。

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

参考文献

WCL Solutions（Phil.） Corp..『平均年齢、2020年25.3歳に(15年24.3歳)』.https://pheconomist.com/topics_detail8/id=77020（新しいタブで開きます）,（参照 2023‐7‐4）.
ヒューマンリソシア（2020）.『第1回：世界各国のIT技術者数～アジア・オセアニア編～』.https://corporate.resocia.jp/ja/info/investigation/case/global_report01（新しいタブで開きます）,（参照 2023‐7‐4）.
国際交流基金（2022）.『2021年度 海外日本語教育機関調査』.https://www.jpf.go.jp/j/project/japanese/survey/result/dl/survey2021/s_east_asia.pdf（新しいタブで開きます）,（参照 2023‐7‐5）.
Primer Media, Inc..「フィリピンのIT ソリューション業界」.Philippine Primer （フィリピンプライマー）.https://primer.ph/guide/living-life/it-solution/（新しいタブで開きます）,（参照 2023‐7‐4）.

スパイスファクトリーの（新しいタブで開きます）を見る。
継続的な改善を目指すアジャイル開発においては、スプリントの完了時に今後の改善につなげるために「レトロスペクティブ」として振り返りを行います。

なぜアジャイル開発においてはレトロスペクティブを行うのでしょうか。また、レトロスペクティブはどのように進める必要があるのでしょうか。

この記事では、アジャイル開発を得意とする当社が、レトロスペクティブの概要やポイント、注意点についてご紹介します。

弊社スパイスファクトリーではアジャイル開発において豊富な実績があります。弊社の概要やサービスプラン、過去の導入実績などをまとめた資料をご用意しました。

気になる方はこちらからダウンロードしてください。

レトロスペクティブとは

レトロスペクティブとはどのような取り組みであり、なぜ重要なのでしょうか。まず初めに、その概要についてご紹介します。

スプリントにおける「振り返り」であるレトロスペクティブ

レトロスペクティブとは「過去にさかのぼる」「過去を懐かしむ」という意味の英単語ですが、とくにアジャイルの文脈においてはスプリント終了時に実施される「振り返り」のためのミーティングのことを指します。

通常、スクラム開発においては数週間～ 1 ヶ月程度のスプリントを繰り返すことで開発を進めていきますが、スプリント完了時に今回のスプリントを振り返るためにレトロスペクティブを行います。レトロスペクティブを通して課題の洗い出しや改良案の提案を行うことで、次回以降のスプリントをより良いものにします。

スプリント期間中は開発作業に時間を取られ、改善の取り組みまで手がつかないケースも多いといえます。

レトロスペクティブの時間をとることで、チームメンバーから有益な意見を引き出して改善を進めることで、スクラム開発の理念でありメリットでもある「継続的な改善」を実現することができます。

レトロスペクティブの目的と必要性

スクラム開発の実践におけるバイブルである『スクラムガイド』によれば、レトロスペクティブの目的は「品質と効果を⾼める⽅法を計画すること」とされています。

レトロスペクティブで整理された改善策を計画し、今後のスプリントに反映させていくことを繰り返すことで、チームを発展的に高めていくことができます。

レトロスペクティブを通して、チームの非効率な作業やコミュニケーション不足、タスクの整理などを行うことで、開発効率の向上、ひいては開発するプロダクトの品質向上につながります。

※参考：Ken Schwaber & Jeff Sutherland「スクラムガイド」（新しいタブで開きます）

効果的なレトロスペクティブの進め方とヒント

以下では、効果的なレトロスペクティブの進め方と、レトロスペクティブを実施するうえでのポイントをご紹介します。

事前準備

レトロスペクティブを実施する前に、ルールや進め方を整理します。

実施時間（タイムボックス）

まず、実施時間（タイムボックス）を検討します。スクラムガイドによれば、スプリント期間が 1 ヶ月の場合、スプリントレトロスペクティブは最⼤ 3 時間程度とすることが推奨されています。

スプリントの期間が短ければ、スプリントレトロスペクティブの時間も短くします。たとえば 2 週間スプリントの場合は 1 時間 30 分とするなど、調整を行います。

参加者

基本的に、スクラムチームを構成するプロダクトオーナー、スクラムマスター、開発者の全員が参加します。お互いに意見を出せるように、全員が発言権を持つようにします。

手法の検討

詳細は後述しますが、レトロスペクティブを効果的に進めるために、KPT や FDL などのいくつかの手法（フレームワーク）が利用できます。

今回のレトロスペクティブはどのような手法により実施するか、事前に検討します。

実施時

レトロスペクティブにおいては、スプリント中に何がうまくいったか、どのような問題が発⽣したか、それらをどのように解決したか、または解決できていないかを話し合います。この際のポイントは、洗い出した意見を集約しつつ、次のスプリントで実施するアクションとして整理することです。

チームとして、スプリントを改善するために有効と思われる変更を整理したうえで、効果が高いと思われるものから優先的に実施します。内容にもよりますが、改善策は次のスプリントにおけるスプリントバックログに追加することで具体化できます。

レトロスペクティブの代表的なフレームワーク

レトロスペクティブの実施においては、いくつかのフレームワークが利用できます。以下では、代表的な 4 つのフレームワークをご紹介します。

KPT（KPTA）

レトロスペクティブにおいて比較的良く利用されるフレームワークとして、KPT が挙げられます。KPT は「Keep（継続）」「Problem（課題）」「Try（今後の挑戦）」の 3 つの視点で現状を分析する手法です。これらに「Action（取り組み）」を加えて KPTA として整理することもあります。

レトロスペクティブのミーティングにおいて KPT を利用する場合、まず良かった点と悪かった点を全員で上げていき、Keep と Problem として整理します。この際、ホワイトボードや付箋などを利用して全員が参加しやすいように環境を整えるとよいでしょう。また、この時良かった点を先に洗い出すようにすることで、発言しやすいような空気感をつくることも進め方のコツです。

次に、Keep と Problem に対して、それらを維持するため、もしくは改善するために挑戦することを Try としてまとめます。Action まで整理する場合は、Try に対して具体的な行動を記載していきます。この際、Try のうち重要度や効果を踏まえて優先的に取り組むべき点を Action としてまとめることがポイントです。

KPT はレトロスペクティブだけでなく、人事考査における面談やプロジェクト完了時の振り返りなど、さまざまな場面で利用できるフレームワークです。

FDL

KPT と類似する手法として FDL が挙げられます。FDL は「Fun（楽しかったこと）」「Done（やったこと）」「Learn（学んだこと）」という 3 つの観点で振り返りを行うフレームワークです。シンプルな手法であり、ネガティブな要素がないためにモチベーションを高めやすい整理方法といえます。

場合により、F・D・L の各観点は重複します。たとえば、実際にやってみて楽しかったことは Done と Fun の両方に位置します。さらに学びがあった場合には、FDL すべての領域に位置することになります。やったことが楽しく、また学びがあるのであれば、それは継続すべき要素といえます。この領域に含まれる要素を増やしていくことを目指します。

TimeLine

TimeLine では、X 軸に時系列を、Y 軸に感情の上下をプロットすることで、現状を分析する方法です。まず初めに、スプリント中に実施したことや発生したこと、思ったことなどを付箋に書き出します。次に、ホワイトボードに作成した時系列と感情のグラフに、これらを張り出します。

次に、それぞれの出来事や思ったことに対して、関連性を見つけたり改善案を検討したりします。グラフ上に感情面の情報が含まれているため、たとえば良い感情を生み出したできごとは継続できるようにアクションを検討したり、悪い感情を生み出した出来事は改善策を検討したりといった取り組みがしやすくなります。

3匹の子ぶた

最後に、少し変わったフレームワークとして『3 匹の子ぶた』を紹介します。童話として知られている 3 匹の子ぶたをモチーフにした振り返り手法であり、少し視点を変えたレトロスペクティブを実施したい場合などに有効です。

3 匹の子ぶたの童話と同じく、このフレームワークでは「わらの家」「木の家」「レンガの家」という3つの観点に分けて現状を整理します。わらの家には課題やうまくいっていないことを、木の家には部分的にうまくいっているものの改善の余地があることを、レンガの家にはうまくいっていることを整理します。3 つの観点に現状を整理できたら、それぞれの観点ごとにチームで議論を行い、改善策や課題の解決方法を検討します。

継続的に 3 匹の子ぶたフレームワークでレトロスペクティブを行うことで、最初はわらの家に置かれていた内容も、だんだんと木の家、レンガの家へと移動していく様子が可視化できます。これにより、チームの成長や改善状況を把握しやすくなります。

レトロスペクティブのよくある失敗と注意点

以下では、レトロスペクティブにおけるよくある失敗や注意点をご紹介します。

意見がでない・発言者が偏る

よくあるのが、レトロスペクティブにおいて意見がでなかったり、いつも同じ人が発言してしまったりというケースです。とくに、チームの課題や改善点などは発言しにくいと感じる方も多いといえます。
誰でも発言しやすい環境をつくるためには、第一にチームの雰囲気を良い状態に保つ点が重要となります。

開発がうまくいっているケースは良いものの、そうでない場合はともすれば犯人探しやダメだしの場ともなりかねません。スクラムマスターなどが中心となり、心理的な障壁を減らすためのファシリテーションを行うことがポイントです。

チームの範囲外への問題への対応

システムの開発において、課題の発生源はスクラムチーム内だけとは限りません。ステークホルダーや組織など、さまざまな外的要因が存在します。

たとえば、ステークホルダーが急に無理な仕様変更を依頼し、プロジェクトを成功させるためには対応せざるを得なくなってしまったり、プロダクトオーナーが別の案件の兼務を指示され、開発に割けるリソースが減ってしまったりといったケースもあります。

このような問題は、スクラムチーム内で対処することが難しいことも多いといえます。一方で、注意しなければならないのが、レトロスペクティブの場を「愚痴の言い合い」にしないことです。外的要因を改善できる可能性があるのであればその可能性を検討する、もしくは改善できないのであれば、それを前提として最善策を検討するといったように、前向きな視点が重要です。

悪い状況の時こそレトロスペクティブが必要

スケジュールが厳しいプロジェクトやリソースが限られているプロジェクトなど、難しい状況にある場合に、レトロスペクティブは軽視されがちです。このような場合、スクラム開発のプロセスに存在するからと事務的に実施されたり、場合によっては省略されてしまったりということも往々にしてあります。

一方で、このような状況の時こそレトロスペクティブが必要といえます。時間がない状態で作業以外のことをやるのはモチベーションが湧かないこともありますが、レトロスペクティブに時間を使い改善を進めることで、長期的に見ればチームに余裕を生むことにつながります。

レトロスペクティブで効果的な改善を

この記事では、アジャイル開発において実施されるレトロスペクティブについて、その概要や主なフレームワークなどについて紹介しました。

レトロスペクティブを含めたスクラム開発の取り組みをうまく進めるためには、アジャイル開発やスクラム開発の経験や知識が必要です。

スパイスファクトリーでは、アジャイル開発・スクラム開発によりこれまで多数のお客さまのシステム開発を支援してまいりました。

アジャイル開発でプロダクトやサービスの開発を検討されている方は、ぜひお声がけください。

スパイスファクトリーのシステム開発サービスを見る（新しいタブで開きます）

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

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

スパイスファクトリーの（新しいタブで開きます）を見る。
スクラムマスターは、スクラム開発を成功させるために奉仕型のリーダーとして活躍します。

プロジェクトのリーダーというと「プロジェクトマネージャー」を思い浮かべる方も多いのではないでしょうか。

一方で、スクラム開発におけるスクラムマスターの役割は、プロジェクトマネージャーとは少し異なります。

この記事では、スクラム開発をはじめとしたアジャイル開発を得意とする当社が、スクラム開発におけるスクラムマスターの役割や必要なスキルについてご紹介します。

https://spice-factory.co.jp/service/scrum-development/

スクラムマスターとは

スクラム開発におけるスクラムマスターとは、どのような位置づけの存在なのでしょうか。

スクラムマスターはスクラムを確立させる「責任者」

スクラムマスターの位置づけを一言で説明すると、スクラムを確立させる「責任者」といえます。

スクラムマスターは、スクラム開発の実施においてスクラムの理論と実践方法を全員に理解してもらえるように手助けをします。
その名前の通り、スクラムマスターはスクラム開発に精通した有識者として、スクラムを成功させるために活動します。

また、スクラムマスターは「スクラムチームと組織に奉仕する真のリーダー」と呼ばれるように、スクラム開発を推進していく上でチームをまとめていく役割を担います。

そのために、スクラムチームがスクラムのフレームワークに沿ってうまく活動できるように、コーチングやファシリテートを行っていきます。

スクラムマスターはプロジェクトマネージャーではない

よくある誤解として、スクラムマスターをプロジェクトマネージャーの位置づけのポジションととらえてしまうことがあります。

ウォーターフォール型のプロジェクトにおいては、プロジェクトを取りまとめ管理を行っていくプロジェクトマネージャーの役割が存在します。

プロジェクトマネージャーは、プロジェクトのリーダーとして、トップダウンでの意思決定やスケジュール・リソースの管理などを行います。

一方で、スクラム開発においてはプロジェクトマネージャーと同様の役割は存在しません。スクラムマスターはあくまで奉仕型のリーダーであり、トップダウンで意思決定を行うことはありません。
スクラム開発という枠組みの中でプロジェクトを円滑に推進し、課題があればそれを解決できるようにサポートしていくという役割を担います。

スクラムマスターと他の役割との違いと関係性

スクラム開発においては、スクラムマスター以外に「プロダクトオーナー」と「開発者」という役割も存在します。以下では、スクラムマスターと他の役割との違いと関係性について整理します。

プロダクトオーナーとスクラムマスター

プロダクトオーナーの役割を一言で表すと「スクラムチームから⽣み出されるプロダクトの価値を最⼤化すること」です。
プロダクトオーナーは開発するプロダクトの結果に責任を持ち、プロダクトの方向性を決める責任者となります。

プロダクトオーナーは、どちらかといえばビジネスサイドの方が担うことが多い役割といえます。

そのため、必ずしも IT やスクラム開発に精通していないことも多くなります。このような場合、スクラムマスターはプロダクトオーナーをサポートしつつ、プロダクトオーナーとスクラムチームの架け橋となり、スクラム開発を成功に導いていく必要があります。

スクラム開発におけるプロダクトオーナーの役割など、詳細については以下の記事でご紹介しておりますので、よろしければ併せてご覧ください。

https://spice-factory.co.jp/development/what-is-productowner/

開発者とスクラムマスター

開発者は、スクラム開発においてプロダクトの開発を担当するメンバーのことです。

少人数で実施するスクラム開発においては、開発者があらゆる作業を担当することになります。スクラム開発に対する理解はもちろんのこと、設計・コーディング・テストなど一連の開発スキルを有していることが求められます。

上述のとおり、スクラムマスターは開発者を統括して管理していく役割ではありません。
開発者がスクラムの枠組みの中で力を発揮できるように、奉仕者として支援していく役割を担います。

デイリースクラムやスプリントプランニングなどの会議体においては、進行役として会議を円滑に進行していくことも必要です。

また、プロジェクトに問題が発生した場合には、その問題の解決方法ついて検討することも必要でしょう。

スクラムマスターの役割や責任

スクラムマスターの位置づけはスクラムを確立させる「責任者」であると紹介しましたが、ここではより具体的にスクラムマスターの役割や責任についてご紹介します。

スクラム開発におけるバイブルといえる「スクラムガイド※」によれば、スクラムマスターの役割は大きく以下の3つとなります。

• スクラムチームのサポート
• プロダクトオーナーのサポート
• 組織全体のサポート

※参考：スクラムガイド（日本語訳版）（新しいタブで開きます）

スクラムチームのサポート

スクラムマスターは、さまざまな形でスクラムチームをサポートしていきます。
具体的には、以下のような取り組みを行っていきます。

〇コーチング

スクラム開発に対する知識や経験が少ない開発者に対して、コーチングによりスキルやノウハウを伝達していく。

〇課題の解決

スクラムチームの進捗を妨げるような課題や障害物が発生した場合、それらを解決・排除できるように動く。

〇スクラムイベントの進行と順守

デイリースクラムやスプリントプランニング、スプリントレトロスペクティブなどの各種スクラムイベントの開催やタイムキーピングなどのファシリテートに加え、各種イベントがポジティブかつ⽣産的なものとなるように動く。

〇作業へ集中できる環境の提供

その他、スクラムチームが品質の高い成果物を作成し、プロダクトの完成という目標に進んでいく作業に集中できるように様々な支援を行う。

プロダクトオーナーのサポート

同様に、スクラムマスターはプロダクトオーナーのサポートを行います。具体的には、以下のような取り組みを行っていきます。

〇プロダクトゴール・プロダクトバックログに関するサポート

プロダクトオーナーがビジネス目標を達成するために作成するプロダクトゴールやプロダクトバックログについて、助言やサポートを行うことで作成や管理をサポートする。

〇プロダクトバックログアイテムの理解浸透

プロダクトバックログアイテムがなぜ必要であり、具体的にどのようなものなのかを開発者に理解してもらえるように、プロダクトオーナーの考えを踏まえて伝達を行う。

〇専門的な知見の提供

プロダクト開発においてインフラ環境や利用するソフトウェア、SaaS など、専門的な知見を踏まえてプロダクトオーナーをサポートする。

〇ステークホルダーとのコミュニケーション支援

プロジェクトを進めていく上で必要となるプロダクトオーナーとステークホルダーとのコミュニケーションについて、支援を行う。

組織全体のサポート

スクラムマスターの役割は、スクラムチームやプロダクトオーナーのサポートにとどまりません。プロダクトを開発する組織全体に対しての支援もスクラムマスターの役割のひとつです。

〇組織へのコーチング

スクラムチーム内だけではなく、組織全体へスクラム開発について指導・トレーニング・コーチする。

〇スクラム開発の進め方についての助言

組織がどのようにスクラム開発を活用していけばよいか、その実施⽅法を計画したり、助⾔したりする。

〇スクラム開発のノウハウ提供

たとえばスクラム開発におけるコストの妥当性など、スクラム開発に関する経験・知見を基に社員やステークホルダーの理解を高める。

スクラムマスターに求められるスキル

スクラムマスターとしてスクラム開発に携わっていくためには、どのようなスキルが必要なのでしょうか。
以下では、スクラムマスターの認定試験であるCSM（Certified ScrumMaster）認定スクラムマスターの取得時に受講するカリキュラムを踏まえてご紹介します。

※参考：Scrum Alliance「SCRUM ALLIANCE CERTIFIED SCRUMMASTER (CSM) Learning Objectives」（新しいタブで開きます）

スクラム開発に関する知見・経験

当然ながら、スクラム開発に関する知見や経験を有していることはスクラムマスターに求められる必須のスキルです。

これまでにご紹介した通り、スクラムマスターはスクラム開発をスクラムチームや組織にインストールするために、スクラムの有識者としてサポートを行うことが求められます。
そのためには、スクラム開発に関する知識が必要です。

スプリントプランニングやスプリントレビューの実施方法や実施時のポイント、プロダクトバックログの作成方法や取りまとめ方など、スクラム開発を進める上でのイベントや作成物に関する知見を基に、他のメンバーへの助言やサポートを行っていくことが求められます。

ファシリテーション力

スクラムマスターは奉仕型のリーダーであり、自身がプロジェクトを取りまとめて意思決定をしていくのではなく、メンバーの意見を引き出し、取りまとめていく力が求められます。
このようなファシリテーション能力はスクラムマスターの役割を担う上で重要なものとなります。

たとえばスプリントプランニングにおいては、プロダクトオーナーの要望や開発者の作業能力などを踏まえ、現実的かつプロダクトゴールに向けて効果的である計画を立てる必要があります。
それぞれの意見が異なる場合には、うまく意見を整理していく必要もあります。

調整力

一般的に、プロジェクトを実施していく上では多数のステークホルダーが存在します。

たとえば経営層はプロジェクトの成否とプロジェクトの成功がもたらす利益について関心があります。

またシステム連携を行う場合は、連携先システムの担当者などもステークホルダーとなるでしょう。

このようなステークホルダーは、多様な意見を持ち、また利害関係も存在します。
一義的にはプロダクトオーナーがステークホルダーとの調整を行うことになりますが、プロダクトオーナーを支援し、調整をサポートしていく力がスクラムマスターには求められます。

コーチング・ティーチング能力

スクラムマスターには、スクラム開発がうまくいくようにメンバーへコーチングやチーティングを行っていく役割があります。

たとえば、プロダクトオーナーがスクラム開発に精通していない場合、スクラムマスターはスクラム開発の進め方やプロダクトバックログの取りまとめ方などについて助言を行い、知識を伝えてしていきます。

単に知見を持っているだけでは、このようないわゆる教育に関する取り組みはうまくいきません。自身が持つ知見を分かりやすく、かつ相手のスキルに合わせて伝えていく能力が求められます。

スクラムマスターの知識でスクラム開発を成功させよう

この記事では、スクラムマスターの役割や必要なスキルについてご紹介しました。

スクラム開発がうまくいくかどうかは、スクラムマスターのスキルによるところも大きいといえます。
特に、メンバーがスクラム開発に慣れていない場合、スキルや経験を備えたスクラムマスターが活躍します。

自社にエンジニアリソースが存在しない場合は、アジャイル開発やスクラム開発に精通した外部メンバーにスクラムマスターの役割を依頼することも有効です。
高いスキルを持ったスクラムマスターがチームに存在することで、スクラム開発を成功に導くことができます。

スパイスファクトリーでは、アジャイル開発・スクラム開発によりこれまで多数のお客さまのシステム開発を支援してまいりました。
アジャイル開発でプロジェクトを実施したいという方は、ぜひお声がけください。

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

スクラム開発によりプロダクト開発を行う際には、その具体的な流れや実施すべきイベントについて理解しておくことが重要です。

スクラムのイベントにはプロダクトバックログの作成やスプリントレトロスペクティブの実施など、様々なものがあります。これらはどのような概念のものであり、どのように進めるべきなのでしょうか。

この記事では、スクラム開発の流れとスクラムイベントについて詳しく解説します。

弊社スパイスファクトリーではスクラム開発において豊富な実績があります。弊社の概要やサービスプラン、過去の導入実績などをまとめた資料をご用意しました。

気になる方はこちらからダウンロードしてください。

スクラム開発について簡単に整理

まずはじめに、スクラム開発の概要について簡単に整理します。
スクラム開発とは、少人数のチームで「スプリント（新しいタブで開きます）」と呼ばれる一定の開発期間を繰り返し、システムを作り上げていくシステム開発の手法のことです。

スクラム開発はアジャイル開発手法の一つであり、アジャイル開発の理念を実現するための一つの手段となります。スクラム開発以外にも XP（エクストリームプログラミング）や FDD（ユーザー機能駆動開発）など様々なアジャイル開発手法が存在しますが、スクラム開発は中でも代表的なものといえます。
スクラム開発の詳細については以下の記事も併せてご覧ください。

参考記事：アジャイル開発におけるスクラム開発とは？メリットやプロジェクトの進め方を解説

スクラム開発の流れとスクラムイベント

以下では、スクラム開発の具体的な流れについて詳しく解説していきます。以下の内容は、スクラム開発のバイブルである「スクラムガイド※」に沿ったものとなります。
スクラム開発は 5つのイベントと 3つのロール（役割）で構成されています。
※参考：Ken Schwaber & Jeff Sutherland「スクラムガイド」（新しいタブで開きます）

スクラムチームの体制構築

まず、スクラム開発を実施していく上では体制の構築が必要です。スクラム開発では、実際に開発を進めていくロール（役割）を以下の3つに分けています。

• プロダクトオーナー
• スクラムマスター
• 開発チーム

上記の 3つの役割のメンバーたちをあわせて「スクラムチーム」と呼んでいます。
以下で、それぞれの役割について解説していきます。

プロダクトオーナー（PO）

プロダクトオーナーとは、プロダクトに求める要求に責任を持つメンバーであり、プロダクトに実装する機能の洗い出しや優先順位付けを行います。また、完成したシステムの品質が要望通りとなっているかをチェックします。

プロダクトオーナーの役割を一言で表すと「スクラムチームから⽣み出されるプロダクトの価値を最⼤化すること」となります。
プロダクトオーナーは開発するプロダクトの結果に責任を持ち、プロダクトの方向性を決める責任者です。また、プロダクトオーナーは 1プロダクトにつき 1人であり、合議制の委員会のような組織にはしません。

プロダクトオーナーについては以下の記事にて詳しく解説しておりますので、よろしければご覧ください。
参考記事：スクラム開発のプロダクトオーナーとは？スクラムマスターとの違いや役割・必要なスキルを解説（新しいタブで開きます）

スクラムマスター（SM）

スクラムマスターはチームにおいてスクラムの手法を有効に機能させるべく活動するメンバーです。
スクラムマスターの位置づけを一言で説明すると、「スクラムを確立させる責任者」といえます。

スクラムマスターは、スクラム開発においてスクラムの理論と実践方法をメンバー全員に理解してもらえるよう、支援します。もしくは、スクラムの実施においてチームが上手くいかないことを抱えている場合にはその障壁を取り除くこともあります。
その名前の通り、スクラムマスターはスクラム開発に関する有識者として、スクラムを成功させるために活動します。

スクラムマスターはいわゆるプロジェクトマネージャーや管理者としてチームを統括するというよりかは、スクラムのスタイルでプロジェクトを円滑に実施できるよう、陰になり日向になり組織に奉仕するサーバントリーダーとなることが望ましいといえます。そのため、基本的にはタスクのアサインや進捗管理も実施しません。

スクラムマスターについては以下の記事でも詳細に解説していますのでぜひ参考にしてみてください。
参考記事：スクラムマスターとは？役割やスキル、責任について分かりやすく解説（新しいタブで開きます）

開発チーム（DEV）

開発チームは、システムの開発を担当するメンバーのことです。
開発チームの位置づけを一言で説明すると、スプリントにおいてプロダクトを改善していくためのあらゆる作業を担う「専門家」であるといえます。

スクラムにおける開発チームは3～9人の間が適切とされています。3人未満ではお互いの開発作用が少なかったり、属人化しやすくなり、10人以上の場合はコミュニケーションコストが上昇し、開発の効率が悪くなるためです。

テストチームや要件定義チームといったように、特定のことしか実施しないサブチームは作りません。このようなことから、スクラムにおける開発チームは「機能横断的」といわれます。
そのため、開発チームの各メンバーに必要とされるスキルは実に多様です。設計・コーディング・サーバー構築・テスト・完成品のデモやドキュメントの作成に至るまで、幅広いスキルが求められます。

さらに、スクラムの開発チーム内では肩書や役割はありません。
開発チームでの仕事の進め方はチームメンバーの合意の下で決められ、外部から（プロダクトオーナーやスクラムマスターであっても）仕事の進め方を指示されることはありません。あくまで開発チーム全体で責任をもって作業を進める、「自己組織化」が特徴です。
開発チームはシステム開発に関する専門家として、プロダクトの品質に対する責任を持つことが求められます。

プロダクトゴールおよびプロダクトバックログの作成

体制の構築が出来たら、いよいよ実際のスクラム開発の流れに入ります。
スクラム開発においては、チームが達成すべき目標はプロダクトゴールとして、また具体的に作り上げていくプロダクトの機能はプロダクトバックログというリストとして整理を行います。
たとえば、新規事業開発において ECサイトの MVP（Minimum Viable Product）（新しいタブで開きます）を構築する場合、プロダクトゴールは MVP の構築となり、プロダクトバックログはユーザー管理機能や商品検索機能、決済機能などとなります。
プロダクトバックログで整理した要求項目は、ビジネス上の必要性や機能の価値・効果などから優先度をつけます。
各スプリントにおいては、優先度の高いものから開発を行っていきます。
そのため、プロダクトバックログの上位の項目ほど内容が具体的で詳細になります。
また、プロダクトバックログは一度作って整理をしたら終わりではありません。要求が変わったら項目や順序を変えますし、新しい要求が追加されることもあります。
プロダクトを作っている間は、絶えず更新をし続け、最新の状態に保たなくてはなりません。

プロダクトゴールやプロダクトバックログの作成は、プロダクトオーナーが責任をもって実施します。一方で、スクラム開発の進め方に慣れていない場合は、必要に応じてスクラムマスターがプロダクトオーナーを支援します。

スプリントプランニング

スクラム開発においては、一定の固定期間の「スプリント」（新しいタブで開きます）を繰り返すことで開発を行っていきます。開発チームは、1つのスプリントの中で計画・設計・開発・テストなどのプロダクトバックログの項目を完成させるために必要な作業を全て行います。
プロジェクトにもよりますが、スプリントの期間は 1週間から最大でも 1か月程度の期間で設定されます。
スプリントの期間は、チームの成熟度や開発チームの人数、ビジネスの状況などによって決定されることが一般的です。

スプリントを始めるにあたっては、スプリントの実施計画を立てます。これをスプリントプランニングと呼びます。スプリントプランニングでは、このスプリント内でどの機能を開発するか、また本スプリントのゴールをどうするかを定義します。
各スプリントにおいては、開発チームのリソースと各機能の見積を踏まえ、スプリント期間中に実現可能な範囲で開発を行います。
スプリント期間中に開発する機能について、開発チームは「スプリントバックログ」として開発内容を具体化します。スプリントバックログをうまく作成するためには、プロダクトバックログが開発に着手できるレベルで十分に記載されていることが必要です。プロダクトオーナーの意思がうまく開発チームに伝わっていない場合、必要に応じてスクラムマスター（新しいタブで開きます）が支援を行います。

スプリントの実施

各スプリントにおいては、コーディング作業だけではなくテストも実施し、スプリント完了時には最低限動作するシステムとすることを目指します。

スクラムにおいては、何度もコードを修正し、テストを実施していくことから、テストの自動化やリファクタリングによるコード品質の向上など、高い効率と品質で業務をこなすことが重要です。このような考え方は DevOps と呼ばれ、スクラム開発においては重要視されています。本記事では詳細な解説は控えますが、ご興味があれば以下の記事も参照ください。
参考記事：DevOpsとは？アジャイル開発との違いや導入方法を詳細に解説（新しいタブで開きます）

スクラム開発では、スプリント単位で評価可能な「インクリメント」を作ることが求められます。
インクリメントとは、過去に作ってきた成果物と今回のスプリントで完成したプロダクトバックログの項目を合わせたものです。多くの場合は動作するソフトウェアとして提供され、スプリント終了時点では完成して正常に動作しないといけません。
どんな条件を満たせば「完成」とするかはプロダクトオーナーと開発チームが完成の定義を明確に合意し、プロダクトゴールに向けてスプリント期間中にプロダクトのインクリメントの作成を進めていきます。
より詳細に知りたい方は以下の記事をご参照ください。
参考：アジャイル・スクラム開発の「スプリント」とは？意味とその特徴を解説（新しいタブで開きます）

デイリースクラムによるコミュニケーション

スプリント期間中は、デイリースクラムとして日々ミーティングを実施し、本日の実施作業やこれまでの進捗・達成状況をチーム内で報告します。
進め方に絶対的なルールは存在しませんが、具体的には以下の3点についてメンバーが共有していく形が一般的です。

• 「昨日実施したこと」
• 「本日実施すること」
• 「直面している問題、懸念点」

デイリースクラムは負荷を下げるために同じ場所・時間で、15分程度の時間で実施することが望ましいとされています。
基本的には開発チームによるミーティングとなりますが、スクラムマスターやプロダクトオーナーが開発に参加している場合は、これらの役割のメンバーもミーティングに参加します。
デイリーでメンバーの状況を把握し、課題があれば速やかに対応することが重要ですが、デイリースクラムは問題解決の場ではないことに注意が必要です。
問題が発生し、対応の検討が必要な場合はデイリースクラムの終了後に改めて時間を設けて、デイリースクラム自体は 15分で終了するようにします。

デイリースクラムを経て、開発チームは残りのスプリントの期間でどのように開発を進めるのかをプロダクトオーナーに報告できるようにしておきます。

スプリントレビューの実施

スプリントの終了時には、レビューを実施してスプリントの成果を確認します。スプリントレビューは主要なステークホルダーを含めて実施し、インクリメント（これまでのスプリントで作ってきた実際に動く成果物）をデモしながら行うことが特徴です。ステークホルダーに対して作業の結果を示し、プロダクトゴールに向けた進め方について話し合います。
要求通りにプロダクトの開発が進んでいるか、またできていなければどのような改善が必要なのかを検討します。
スプリントレビューの結果を踏まえ、プロダクトオーナーは必要に応じてプロダクトバックログを見直します。

スプリント期間が 1か月程度の場合、スプリントレビューの時間は最大で 4時間程度が望ましいとされています。

スプリントレビューについての詳細は以下の記事で詳細に解説しております。ぜひ参照してみてください。
参考：スプリントレビューとは？アジャイル・スクラム開発でのやり方や目的を徹底解説（新しいタブで開きます）

スプリントレトロスペクティブによる振り返り

スプリント完了時に、レトロスペクティブとしてそのスプリントの実施内容の振り返りを行います。レトロスペクティブを通してスプリントの進め方に関しての課題の洗い出しや改良の提案を行うことで、次回以降のスプリントをより良いものとすることができます。
レトロスペクティブで整理された改善策を計画し、今後のスプリントに反映させていくことを繰り返すことで、チームを発展的に高めていきます。このような継続的な改善は、アジャイル開発の本質といえるでしょう。

スプリントレトロスペクティブをスプリント完了時の振り返りと考えると、前項のスプリントレビューと同じでは？と感じる方もいらっしゃるかもしれません。
違いとしては、スプリントレビューではスプリントの「成果物」に、スプリントレトロスペクティブではスプリントの「プロセス・人との関係・ツールなど」にフォーカスします。

スプリントレトロスペクティブに使える時間は、1カ月のスプリントの場合は 3時間でスプリント期間が短くなればそれに応じて短縮するのが一般的です。
スプリントレトロスペクティブに関しての詳細な解説や効果的な進め方については以下の記事にて解説していますのでぜひご覧ください。
参考：アジャイル開発におけるレトロスペクティブって何？効果的な振り返りの方法（新しいタブで開きます）

スクラムイベントと流れをおさえてスクラムを成功させよう

この記事では、スクラム開発の全体的な流れについてご紹介しました。
スクラム開発に取り組む経験が少ない方にとっては、まず全体的な流れと各スクラムイベントの概要を抑えることが重要です。
実際にスクラム開発を進めていく際には、各イベントにおいてプロダクトオーナーや開発チームを支援するスクラムマスターの役割も重要です。スクラム開発がうまくいくかどうかは、スクラムマスターのスキルによるところも大きいといえます。
高いスキルを持ったスクラムマスターがチームに存在することで、スクラム開発を成功に導くことができます。

スパイスファクトリーでは、アジャイル開発・スクラム開発によりこれまで多数のお客さまのシステム開発を支援してまいりました。スクラムマスターやプロダクトオーナーの認定資格である「認定スクラムマスター/Certified ScrumMaster®」を保有しているメンバーも数多く在籍しています。スクラム開発でプロジェクトを実施したいものの、経験や知識が少ないという方は、当社へぜひお声がけください。

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

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

参考文献

Ken Schwaber & Jeff Sutherland（2020）.『スクラムガイド』.https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Japanese.pdf,（参照 2023‐6‐19）.
西村 直人 永瀬 美穂 吉羽 龍太郎（2020）.『SCRUM BOOT CAMP THE BOOK』.翔泳社

システム開発リソースとは、開発に必要な「ヒト」「モノ」「カネ」のことを表しますが、近年は中でも「ヒト」、すなわち IT人材の不足は深刻です。開発プロジェクトを進めたいと考えていても人的リソースが十分に確保できずスムーズに進行できないといった経験がある方も多いのではないでしょうか？
本記事では、システム開発リソース不足の原因と解消するための対処法を網羅的に解説していきます。

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

システム開発リソースとは

本題に入る前に「システム開発リソース」とは何を指すのか、整理をします。
ビジネスにおける「リソース」は、一般的には経営資源のことを指します。
経営資源はビジネスを安定的に運営するために必要な要素のことで、経営資源とみなされるものは主に以下の 6つが挙げられます。

• 人
• モノ（物理的資源）
• 金
• 情報
• 時間
• 知的財産

「システム開発リソース」という場合には、システム開発を行うのに必要な要素を表します。
システム開発では、工業製品のように原材料や大規模な工場設備などはなくても成り立ちます。

重要になってくるのはエンジニアや PM といったプロジェクトを推進する人材です。
経営資源の6つの要素に照らし合わせると、システム開発におけるリソースとは特に「人」と「時間」が大きなウエイトを占めるでしょう。
開発リソースの不足とは、開発したい内容に対して開発を担当するエンジニアや PM の人数が足りない、あるいは時間が足りないといった状況であるといえます。

システム開発リソース不足の原因

日本国内全体で IT人材不足が深刻なのは、各社で人材の争奪戦が繰り広げられているためといえるでしょう。
IPA（情報処理推進機構）が発行している「DX白書2023（新しいタブで開きます）」では、アンケートを取得した事業会社 1,046 社のうち、量の面で「大幅に不足している」が 35.2%、「やや不足している」が 38.3% となり、質の面では「大幅に不足している」が 35.7%、「やや不足している」が 38.7% となっています。
IT人材の量・質それぞれで何らかの不足を感じている企業は、実に全体の 7割以上にも及んでいるのです。
一方で「DX白書2023」には、日本の情報処理・通信に携わる人材の人数について、2015年国勢調査の 104万5200人 に対して2020年国勢調査では 125万3930人 と、およそ 5年で 20万人増加したというデータもあります。しかし、多くの企業から IT人材不足の声が上がっている現状を踏まえれば、企業が求める量、質ともにまだまだ不足しているということになるでしょう。

このような状況を反映してか、IT人材の人件費は高くなっています。とあるフリーランスエンジニアのサイトでは、アプリケーションエンジニアの平均単価は 77万円/月でした。令和４年賃金構造基本統計調査において、日本国内における一般労働者の平均年収が 311.8万円 であることを考えると、この平均単価は高いといえます。

今すぐ取り組めるシステム開発リソース不足のおすすめ対処法

それでは、エンジニアや PM などの IT人材のリソース不足に対応するにはどのような方法があるのでしょうか。
今すぐ取り組める リソース不足の対処法としては、下記のような内容がおすすめです。一つずつみていきましょう。

• IT人材の採用
• 人材の育成
• 外部にチームを構築
• オフショア開発

IT人材の採用

IT人材不足を解決するためにどうしよう…と考えたときにまずは採用を検討する方は多いでしょう。特に即戦力の人材を採用すると、システム開発リソース不足に最も早く対処できます。
採用の形式としては、主に「正社員」「派遣」「請負」「SES」「業務委託（フリーランス）」「インターン」の6つがあります。
以下でそれぞれの雇用形態について簡単に確認しましょう。

正社員

正社員とは、期間を定めずに就業場所において正規に雇用される人材です。
他の形式に比べて福利厚生や一定の雇用保証など労働者側にはメリットが多いため、優秀な人材を確保しやすく、社内で契約範囲内での柔軟な運用もできます。反面、簡単には解雇できないため、採用ミスマッチが起きた際のリスクや人員を増やしすぎることによって人員がだぶつく恐れもあるため注意が必要です。

派遣

派遣とは、派遣会社から紹介された人材を雇う雇用形態です。
派遣社員については各種保険・労務対応が不要なため、正社員に比べてコストが低く、さらに業務状況に応じた流動的な採用も可能です。しかし、自社内にノウハウが蓄積されにくい、重要な業務を任せにくい、といったデメリットもあります。
また、2015年の派遣法改正で派遣には3年の期限が設定され、3年以上同じ事業所で働くには正社員として雇用が必須となったことも注意点です。

請負

請負とは、決められた納期までの成果物完成を目的とした契約形態です。
派遣のメリットに加えて業務に使用する設備は請負先で準備してもらえます。しかし、派遣と同様のデメリットを持ち、さらに自社に指揮命令権はないことがデメリットです。

SES

SES とは System Engineering Service の略で、システムの開発や保守などの業務において業務期間や人数に対して支払いをする形式です。請負と同様のメリット・デメリットがあります。

業務委託（フリーランス）

業務委託とは、注文者から受けた仕事の成果物・役務を提供することに対して報酬が支払われる形態です。
詳細な業務内容は契約によって異なりますが、メリット・デメリットは先述した請負や SES と同様です。

インターン

インターンとは、興味を持った企業への訪問・勤務を実施する職業体験のことです。
通常のインターンであれば業務上の成果物や技術提供は求めにくいですが、「有給インターン」という形式ならば、契約形態に応じてシステム開発への参画をしてもらえる場合もあるでしょう。

場合によって雇用の形式を使い分けることで、システム開発における IT人材の不足を補えます。
形式ごとの特徴を下記表に整理しましたので、ご覧ください。

IT人材の育成

時間をかけられる場合は、社内に在籍している人材を育成することもできます。
自社に必要なスキルを持った人材を育成できる点は大きなメリットでしょう。
ただし、多くの場合育成は中長期に渡って行う必要があり、短期的なリソース不足解消は難しいことが多いです。また、能力に見合った報酬や待遇が与えられないと、退職・転職されてしまうなどのリスクもあります。

外部に開発チームを構築

先述した IT人材の採用にも関わる内容ですが、外部の ITベンダーやフリーランスチームなどで自社向けのチームを構築できると、必要に応じて仕事をスムーズに依頼できるようになります。
いわゆる「受託開発」サービスを提供している企業などに依頼をする形が一般的でしょう。
外部チームといえど、仕事を重ねることによって自社の特色や社内事情にも精通していきます。
上手くいけば中長期でお付き合いができるパートナーになるでしょう。また、依頼の規模を調整できるので、必要な時に必要な規模の仕事を依頼することで社内で人員を用意するよりもコストを抑えられる可能性があることもメリットです。
反面、自社内に開発ノウハウが蓄積されにくいというデメリットもあるため、自社内のカルチャー醸成や仕組み化にも寄与するような外部パートナーを見つけることが大事です。
余談ですが、当社、スパイスファクトリーでも受託開発サービスを提供していますので、ご検討されている方はお気軽にご相談ください。

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

オフショア開発

オフショア開発（新しいタブで開きます）は、海外に拠点を持つ ITベンダーやフリーランスチームなどにシステム開発を発注することです。厳密には前述した「外部にチームを構築」の1つの種類となります。
一般的にオフショア開発の拠点国の人件費は日本国内の人件費に比較して安いことから、国内での開発に比べてコストを削減できる可能性があることがメリットです。
近年はオフショア開発の拠点国として人気である東南アジア諸国のスキルレベルも高くなってきており、AI やブロックチェーンといった先端技術に対応できるケースもかなり増えてきています。
日本国内の IT人材不足と人件費の高騰は本記事の冒頭でも触れたとおりですが、不足するリソースを海外の人材で補うというのは非常に合理的といえるでしょう。
オフショア開発に関してもスパイスファクトリーにてサービスを展開しておりますので、ご興味があればお気軽にお問い合わせください。
（新しいタブで開きます）
参考記事：オフショア開発会社の選び方とは？確認すべきポイントを解説（新しいタブで開きます）

対処法ごとのメリット・デメリットと難易度を下記の通り整理しましたので、ご覧ください。

※難易度に関しては当社の経験から独自に判定をして記載しております。あらかじめご了承ください。

システム開発リソース不足に外注で対処する場合の注意点

社内でシステム開発をするのではなく、外部へシステム開発を依頼する際には、いくつか注意点があります。
採用や育成で開発リソースを確保するのはどうしても一定以上の時間を要しますが、外注であれば短期的に解決が可能ですので、システム開発を検討する際には現実的選択肢として選ばれることの多い方法です。
ここでは、その注意点をみていきましょう。

システム開発のコンセプトは必ず作成する

コンセプトとは「なぜシステムを作るのか？」という内容です。
誰のどんな課題を解決するために必要なシステムなのか、プロジェクトに携わるメンバーみんなが理解していることが重要です。
システム開発すること自体が目的となってしまい、コンセプトがないと、必要な機能を考える際の基準が作れなくなるため、現場からの意見を取捨選択できずにコストが膨れ上がってしまいます。

システム開発の目的認識をメンバー間で揃える

前述したコンセプトが共有できていないと、メンバーごとにコンセプトの考え方が異なり、全員の行動指針が一致しません。
コンセプトは必ずメンバー間で同じものを共有しましょう。

システム開発のすべてを丸投げしない

ベンダーに開発のすべてを丸投げしてしまい、依頼企業側がシステム開発に関わらない状態になっていると、システム開発プロジェクトは失敗に終わることが多い傾向にあります。
丸投げをしてしまうと開発プロセスや内容がブラックボックス化し、適切な投資が行われているか、改善点はないのかといった健全な振り返りができなくなるリスクが高まります。
伝統的にシステム開発をベンダーへの受託開発で実施していることが多い日本企業において DX が失敗する要因の１つにも挙げられます。
参考記事：【2023年版】DXが失敗する理由は？リスクを下げ成功確率を上げる「FastDX」という選択肢（新しいタブで開きます）
システム開発は経営にも大きく関わるため、コンセプトに沿ったシステムを作るには現場の業務に精通した人物はもちろんのこと、経営層の関与も重要です。

ITベンダーを選ぶときはできるだけリスクを抑える

特に技術に詳しくない人が ITベンダーを選ぶのは至難の業です。
選定の際には、実績や見積、得意分野などから判断するしかありませんが、それでも自社と相性が良いかはわからないでしょう。
短期間でも依頼できる ITベンダーがあれば、試しに依頼してみるということもできるため、技術分野に不慣れな場合でも安心でしょう。
また、要件定義のみ、本開発の前のプロトタイプ制作のみといった形でシステム開発プロセスの一部を切り出して依頼し、信頼できる会社であれば継続、難しそうであれば他社を検討するといった方法もおすすめです。

プロジェクトの体制やスケジュールを明確にしておく

プロジェクトを立ち上げる際に、プロジェクト体制やマスタースケジュールは最低でも明確にしておきましょう。
誰が関わるのか、そして何をいつまでに実施するのかを明確にしておかないと外部のチームをコントロールできません。
プロジェクト体制には、必要に応じて意思決定者である経営層やシステムを導入した後に実務で利用する業務部門のメンバーも含めておきましょう。

システム開発リソース不足を解消するスパイスファクトリーの受託開発サービス

スパイスファクトリーの受託開発サービスは「伴走型支援」という形態をとります。
伴走型支援とは、近年の DX をはじめとするお客様が取り組むビジネス変革を、一丸となって支援していく形態です。
ここからは手前味噌ではありますが、システム開発のリソース不足をスムーズにカバーできるスパイスファクトリーのサービスを紹介していきます。

参考記事：アジャイル開発とは？ – システム開発を発注する時に知っておきたい開発手法の話（新しいタブで開きます）
参考記事：新規事業担当者必見。“アジャイル開発”で小さく始めるシステム開発（新しいタブで開きます）

高品質オフショア開発

スパイスファクトリーのオフショア開発は、人材のスキル、品質管理、コミュニケーションなどのよくあるオフショア開発の不安を払拭しています。
当社はアジャイル開発を強みとして成長してきており、スキルの高い技術者の採用には強いこだわりを持っているため、オフショア開発のスタッフについても同様のこだわりを持って採用しています。
さらに高度な品質担保のため、社内QAエンジニアによる「機能レベルの外部品質担保」と、ブリッジエンジニア／エンジニアリングマネージャーの2重レビューによる「コードレベルの内部品質担保」を実施しています。窓口となるブリッジエンジニアは、もちろん日本語でのコミュニケーションが可能です。
さらに当社では、現地駐在責任者によるマネジメント体制構築や CTO による直接の技術指導、海外拠点現地研修などを実施しています。
詳細は以下のページからもご確認ください。
（新しいタブで開きます）

当社の実績

参考までに当社の受託開発サービスの実績の一部をご紹介します。
後述するシステム開発の内製化にもつながるように、クライアント企業様のエンジニアやデザイナーと共同のチームを組むといった体制を作っている場合もあります。

株式会社Belong | コーポレートサイトリニューアルおよび法人向けサービスサイトとの統合

先方のデザイナー様と協働体制で進行したプロジェクトです。約3カ月の期間でサイトのローンチまで進行いたしました。

株式会社Belong | コーポレートサイトリニューアルおよび法人向けサービスサイトとの統合 事例詳細はこちら（新しいタブで開きます）

東京都デジタルサービス局 | アジャイル型方式によるプロトタイプ開発委託

東京都様の初となるアジャイル開発プロジェクトを受託、支援いたしました。
4つの開発プロジェクトをアジャイル開発方式にて支援しています。

東京都デジタルサービス局 | アジャイル型方式によるプロトタイプ開発委託 事例詳細はこちら（新しいタブで開きます）

株式会社ネクスウェイ | 薬剤師向け研修ポータルサイト「アスヤクLIFE 研修」の開発

受託開発として、ネクスウェイ様の薬剤師向け研修ポータルサイト「アスヤクLIFE 研修」を開発したプロジェクトです。
エンジニアはもちろんですが、当社のデザイナーも参画し、クライアント様と共創する形でプロダクトを開発しました。
サービスの初期リリース後も、改善や追加機能など継続的に開発を支援しています。

株式会社ネクスウェイ | 薬剤師向け研修ポータルサイト「アスヤクLIFE 研修」の開発 事例詳細はこちら（新しいタブで開きます）

アジャイル開発やオフショア開発に興味がある方は、ぜひ一度スパイスファクトリーに（新しいタブで開きます）ください。

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

システム開発リソース不足を内製化で解消する

前章までは開発リソースの不足を外部リソースの活用で解決する方法を中心に解説してきました。
もう一つの手段として、システム開発の内製化があります。
この章では開発リソースに対応するソリューションとしての内製化について紹介します。

開発リソースの内製化とは

内製化は自社内のリソースで開発プロジェクトを推進できる体制を構築することを目指すものです。
既に開発組織がある企業は、採用等によるキャパシティ拡大を検討することが一般的でしょう。
開発組織がない企業は採用や育成、場合によっては経営判断で M&A（企業買収）を行うなど、より中長期目線での取り組みが必要となります。
一気にゴールまでたどり着くことは難しいので、短期的には前述の受託開発などを利用しながら、完全な内製化までの道のりをいくつかのフェーズに分けて段階的なロードマップとして取り組んでいく必要があるでしょう。

詳細な内製化の進め方や成功のためのポイントは以下の記事にて詳しく解説していますのでよろしければご参照ください。
※参考記事：進むシステムの内製化 メリットや難しさを踏まえどう取り組むべきか（新しいタブで開きます）

ノーコード・ローコードツールの活用促進

開発機能の内製化を検討するうえで近年注目度を増しているのが「ノーコード」や「ローコード」と呼ばれるツールです。
Google が提供している Appsheet（新しいタブで開きます） や、Microsoft のPowerApps などが代表例ですが、専門的なプログラミングの知識を必要としない、あるいは最小限の知識でWebサービスやアプリケーションを開発することができるツールです。

最小限の知識があればいいので、開発部門のエンジニアだけではなくマーケティングや営業部門などにいるビジネスサイドの社員でもアプリケーションが開発できるようになることがメリットです。
ノーコード・ローコードツールを活用すれば、これまで開発のリソースとしてカウントできなかった人材も開発者として考えることができるのです。
社内にノーコード・ローコードツールを導入、浸透させることで開発の裾野を拡大していくことも システム開発リソースが不足している現代の日本においては真剣に検討する必要があるといえるでしょう。
※参考記事：AppSheetとは？できることや活用例、料金までやさしく解説（新しいタブで開きます）

リソース不足を解消してスムーズなシステム開発を

システム開発の IT人材不足において、すぐに着手できる対処法としては、採用・育成、外部チーム構築、オフショア開発といったものがあります。ただし外部チーム構築やオフショア開発については、自社との相性を確かめるために、短期間でも依頼が可能な外部業者に試しに依頼してみることも必要になってくるでしょう。
また内製化については中長期的取り組みに位置づけ、少しずつ取り組んでいくことが必須です。

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

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

参考文献

白川克、濵本佳史（2021）.『システムを作らせる技術』.日本経済新聞出版.
佐藤大輔、畑中貴之、渡邉一夫（2018）.『システム開発のための見積りのすべてがわかる本』．翔泳社.
株式会社システムインテグレータ（2023）.「システム開発におけるリソース不足を解消するには? 原因や影響について解説​​」.株式会社システムインテグレータ.https://products.sint.co.jp/obpm/blog/lack-of-resources,（参照 2023‐5‐15）.

スクラム開発における役割のひとつであるプロダクトオーナーには「プロダクトの価値を最⼤化すること」が求められます。

一方で、スクラム開発に取り組んだ経験が少ない場合、プロダクトオーナーとして具体的にどのような役割を担えばよいか分からないケースも多いのではないでしょうか。

この記事では、スクラム開発をはじめとしたアジャイル開発を得意とする当社が、スクラム開発におけるプロダクトオーナーの役割や必要なスキル・資質について解説します。

スクラム開発とは

スクラム開発とは、少人数のチームで「スプリント」と呼ばれる一定の開発期間を繰り返すことでシステムを作り上げていく手法のことです。

ラグビーの「スクラム」に由来する言葉であり、チームメンバーが肩を組んでチームワークを発揮するラグビーのスクラムと同様に、スクラム開発でも同様にチームが一丸となって開発を行います。

スクラム開発はアジャイル開発手法の 1 つであり、そのなかでも代表的なものといえます。

スクラム開発についての詳細は以下の記事もご覧ください。
※関連記事：スクラム開発とは？アジャイル開発との違いやメリット・デメリット、プロジェクトの進め方例を解説（新しいタブで開きます）

プロダクトオーナーは「プロダクトの価値を最⼤化する責任者」

プロダクトオーナーは、スクラム開発における役割のひとつです。
スクラム開発におけるバイブルといえる「スクラムガイド」によれば、プロダクトオーナーの役割を一言で表すと「スクラムチームから⽣み出されるプロダクトの価値を最⼤化すること」となります。
プロダクトオーナーは開発するプロダクトの結果に責任を持ち、プロダクトの方向性を決める責任者といえるでしょう。

プロダクトオーナーの最大のミッションは、開発する機能を優先度順に整理した「プロダクトバックログ」を作成・更新することです。
ウォーターフォール型での開発と比較して柔軟性に優れるスクラム開発では、開発する機能を開発中に柔軟に変更できます。
このようなメリットを生かすためには、顧客やビジネスのニーズに合わせてプロダクトバックログを作成・更新していくプロダクトオーナーの役割が重要です。

プロダクトオーナーは必ず1⼈が担います。
プロダクトオーナーの役割を他の人に委任することもできますが、いずれにしても最終的な責任はプロダクトオーナーが担います。

よって、プロダクトオーナーは、プロダクトに関するステークホルダーのニーズをとりまとめ、プロダクトバックログで表さなければなりません。

※参考：スクラムガイド（日本語訳版）（新しいタブで開きます）

プロダクトオーナーと他の役割との違いや関係性

スクラム開発における役割には、プロダクトオーナー以外にも「スクラムマスター」や「開発者」という役割が存在します。

これらの役割とプロダクトオーナーの役割の違いや関係性を以下で整理します。

スクラムマスターとプロダクトオーナーの違いや関係性

スクラムマスターは、スクラム開発における指南役にあたり、チームメンバーに対してスクラム開発の手法やマインドを浸透させる役割を担います。

どちらかといえばビジネスサイドの方が担うことが多いプロダクトオーナーは、必ずしもスクラム開発に精通していないこともあります。

このような場合、スクラムマスターはプロダクトオーナーをサポートしつつプロダクトオーナーとチームの架け橋となり、スクラム開発を成功させることが求められます。
スクラムマスターについては以下の記事でも詳しく解説しています。ぜひご覧ください。
参考記事：スクラムマスターとは？役割やスキル、責任について分かりやすく解説（新しいタブで開きます）

開発者とプロダクトオーナーの違いや関係性

開発者は、スクラム開発においてプロダクトの開発を担当するメンバーのことです。

少人数で実施するスクラム開発においては、開発者があらゆる作業を担当することになるため、設計・コーディング・テストなど一連の開発スキルを有している必要があります。

プロダクトオーナーが示した要求に対して、実際に手を動かしてプロダクトを構築していくのが開発者の役割です。

プロダクトオーナーは、開発チームが十分に理解できるよう、また認識齟齬が生じないように、プロダクトバックログとして明確に要望を伝える必要があります。

プロダクトオーナーの役割や責任

プロダクトオーナーには、以下の役割や責任が求められます。

プロダクトゴールを策定し、明⽰的に伝える

プロダクトゴールとは、プロダクトの将来の状態を表したものです。
プロダクトバックログに含まれるものであり、スクラムチームの長期的な目標となります。

たとえば、ある製造業の事業者が新規ビジネスとして「D2C を実現するオンラインサイト」の構築を企画したとします。
この場合、短期的なプロダクトゴールは「オンラインサイトの MVP構築」となるかもしれません。
スクラムチームは、全員がこのプロダクトゴールを共有し、各スプリントではこのゴールを意識して活動を行う必要があります。
プロダクトオーナーは、プロダクトゴールを策定し、明確にチーム内に伝える責任があります。
プロダクトゴールは単一のものでなければなりません。
次のプロダクトゴールに移るためには、スクラムチームはひとつの⽬標を達成または放棄しなければなりません。

上記の例で言えば、「オンラインサイトの MVP構築」が達成されたのちに、「D2C を実現するオンラインサイトの本番リリース」をプロダクトゴールとして設定することになるでしょう。

プロダクトバックログアイテムの作成・管理を行う

プロダクトゴールに向けて、具体的な要望としてプロダクトバックログのアイテムを管理するのもプロダクトオーナーの役割です。

プロダクトバックログはスクラム開発においてチームが行う作業の唯一の情報源となります。
スクラムチームはプロダクトバックログを参照して開発内容を把握します。
開発者は、プロダクトバックログを基に各スプリントの計画（スプリントバックログ）を作成し、開発を行います。

よって、開発における認識齟齬がないように十分な説明がされており、またその大きさも十分に細分化されている必要があります。

たとえば、「D2C を実現するオンラインサイトの MVP構築」というプロダクトゴールに向けたプロダクトバックログは以下のようなものとなるでしょう。

• ユーザーがアクセスするフロント側サイトの構築
• 商品の追加や削除を行うための管理側サイトの構築
• カート機能の構築
• 決済機能の構築
• 在庫管理・発送管理機能の構築

などがあります。

プロダクトバックログの作成や管理にあたっては、必要に応じてスクラムマスターの支援を受けることもできます。

スプリントに関する情報提供や意思決定を行う

各スプリントを進めるうえで、プロダクトオーナーが情報提供や意思決定を行う場面もあります。

たとえばスプリントプランニングを行う際には、プロダクトオーナーが今回のスプリントでどのようにプロダクトの価値を高めていくかを説明し、認識合わせを行います。
スクラムチームは、プロダクトオーナーの意思を踏まえスプリントのゴールを設定し、プロダクトバックログから開発する対象を決定します。
もし、環境の変化やステークホルダーの意見変更などによってスプリントが価値を生まないものとなってしまった場合、プロダクトオーナーはスプリントを中止するという意思決定を行います。
この権限があるのはプロダクトオーナーのみです。

プロダクトオーナーに必要なスキルや資質

プロダクトオーナーに必要なスキルや資質は以下のとおりです。

ここでは、スクラムの理論における経験主義のスクラムの三本柱「透明性」「検査」「適応」を念頭に整理します。

透明性：明確に要求を整理する力

スクラム開発においては、スクラムチーム内での認識誤認を避けるためにも、透明性が重視されます。
とくに、プロダクトオーナーが作成するプロダクトバックログを明確に作成することは、チームが生み出す価値に直結するといってもよいでしょう。
よって、プロダクトオーナーには明確に要求を整理する力が求められます。

そもそものビジネスゴールを明確に認識し、そのゴールに向かってどのような機能を構築すればよいのか考えられる能力が必要です。
一方で、プロダクトオーナーを担う方は必ずしも IT の専門家ではないことも多いといえます。
このような場合、スクラムマスターをはじめとしたチーム内のメンバーの助言を聞き、意思決定を行うことも必要でしょう。

検査：プロダクトが明確にゴールに向かっているか判断する力

スクラム開発においては、デイリースクラムやスプリントレビューによって開発しているプロダクトが明確にゴールに向かっているか検査を行いながら取り組みを進めます。

このとき、プロダクトオーナーはプロダクトの開発方針がビジネス目標やステークホルダーの意見を踏まえて正しいものであるかを判断し、プロダクトバックログを更新していく必要があります。

適応：ステークホルダーと調整する力

スクラム開発において、成果となるプロダクトがステークホルダーに受け入れられなかった場合には、軌道修正を行うことが求められます。

開発中のプロダクトを確認し、自身の意見としてビジネス目標に向かって正しい道のりを歩んでいるか判断する力はもちろんのこと、ステークホルダーの意見を踏まえて軌道修正を行う力もプロダクトオーナーには求められます。

この際、プロダクトオーナーにはステークホルダーが求めているものの具体的な把握や、ステークホルダー間の意見調整を行う必要があります。

これらの取り組みには、コミュニケーションを行う能力が求められるでしょう。

まとめ

この記事では、スクラム開発におけるプロダクトオーナーの役割や、スクラムマスターなどの他の役割との違い、プロダクトオーナーに求められるスキルや資質についてご紹介しました。

スクラム開発でプロダクトを開発する場合、プロダクトオーナーは必ずしもアジャイル開発やスクラム開発に精通しているケースばかりではありません。
そのような場合には、スクラムマスターをはじめとしたスクラムチームメンバーの支援が重要となります。

とくに自社にエンジニアリソースが存在しない場合、アジャイル開発やスクラム開発に精通した外部メンバーにチームに参加してもらうことが有効です。
高いスキルを持ったスクラムマスターや開発者がチームに存在することで、プロダクトオーナーのサポートを行い、スクラム開発を成功に導くことができます。

スパイスファクトリーでは、アジャイル開発・スクラム開発によりこれまで多数のお客さまのシステム開発を支援してまいりました。
アジャイル開発でプロジェクトを実施したいという方は、ぜひお声がけください。

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

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

オフショア開発（新しいタブで開きます）はコストの削減や、近年の日本市場においてはエンジニア不足を解消するために、多くの企業が取り入れています。しかし、オフショア開発プロジェクトは納期の遅延や成果物品質の低さなど、上手くいかないケースも多く発生しています。
オフショア開発は、自社でオフショア拠点を保有していない場合、オフショア開発会社に委託をする場合がほとんどです。
つまりどの企業をパートナーとするかはオフショア開発プロジェクトの成否の大部分を占めているといっても過言ではありません。
そこで本記事では、オフショア開発プロジェクトを成功へ導くために重要なパートナー会社選びに焦点をあて、選定する際に押さえておくべきポイントについて解説します。

オフショア開発会社選定の流れ

まずはオフショア開発企業を選定する一般的な流れを説明します。

社内での前提整理

いきなり企業選びに着手するのではなく、まずは自社内で情報を整理するべきでしょう。
以下に整理のプロセスを紹介します。

目的・目標の整理

どんなものを、いつまでに、どのような状態で開発したいのか具体的に整理をします。
ビジネスとしてのゴールや、達成のために何が課題になっているのか、今回開発するシステムやサイトに期待している役割は何かを明確にしておきましょう。
ここがブレてしまうと、プロジェクトが開始された後に「やっぱり違った！」ということになりかねません。

手戻りがあれば当然スケジュールは遅れますし、費用もかさんでしまいますので注意が必要です。
予算なども決まっているようであればあらかじめ上限値等を確認しておきます。

依頼内容の具体化

目標などの前提整理が終わったら、可能であれば具体的な依頼内容を決定します。
具体的な機能要件や技術スタック、納期、品質、デザインのイメージなどを整理します。

依頼内容が明確であればあるほど、プロジェクト開始後の要件定義がスムーズになる他、選定したオフショア開発企業との認識齟齬や手戻りを避けることができるでしょう。
社内のシステム部門の方や技術的知見がある方と可能な範囲で整理しておくことをおすすめします。
不明な点などは商談や要件定義の際に開発の委託会社と相談して決めることも可能ですので、この段階ではわかる範囲までで問題ありません。

企業の情報収集

オフショア開発先として候補となる企業の情報収集をします。
多くの企業では、調査結果を踏まえて上長や決裁者の方に承認をもらうフローが必要になると考えられます。その観点からも複数の会社の情報を集めて比較検討できるようにすることが望ましいでしょう。
企業の情報は以下のような方法で集めることが一般的です。

• インターネット検索（「オフショア開発 会社」などで Google検索する）
• 相見積もりサイトの活用（『発注ナビ』など複数の企業から一括して見積をとれるサービスがあります。ほとんどの場合、見積を請求する側の会社は無料で利用できます。）
• 知見のある知り合いからの紹介

とはいえ、インターネットなどで入手できる情報には限界があります。
ある程度情報を集めたら、いくつか自社に合いそうな企業を絞り込んで、不足する情報については次に解説する商談で聞くようにします。

商談

候補となる企業を絞り込んだら、それぞれの企業と商談を行います。
サービスの詳細な提案や自社が依頼をする場合の正式な見積りを受けられる他、ネットなどではわからなかった点のヒアリングを行います。
また、ヒアリングを通じて企業との相性や信頼関係を構築できそうかといった数値に表れないような情報を確認することも重要です。

比較・検討

情報が大体集まったら、それぞれの企業を比較します。
比較検討するポイントとしては、以下のようなポイントが挙げられます。

• 企業規模（従業員数や資本金）
• 費用
• 技術力（対応言語・フレームワーク）
• 提案内容
• 過去の実績
• 納期への対応可否
• 品質管理体制
• コミュニケーション能力
• 保守・サポートの有無
• 契約条件
• その他特記事項

社内での承認や共有することを踏まえて、会社ごとに表の形式にまとめると比較がしやすくなりおすすめです。
上記はオフショア開発でなくとも必要になるであろう一般例ですが、これらのポイントと自社でとくに重要視したい点、オフショア開発企業の選定で重視すべき点を考慮して比較検討し、最終的に 1 社を選定します。
オフショア開発企業を選ぶ際にとくに注意するべき項目についてはこの後の章で詳しくご紹介します。

オフショア開発を依頼する会社選びのポイント

費用や企業規模など一般的なシステム開発で注目すべき項目はもちろん確認するべきですが、オフショア開発だからこそ注意するべき点が存在します。
この章ではオフショア開発を依頼する企業を選ぶ際にとくに着目すべきポイントをご紹介します。
企業選びの際に使える比較表テンプレートも作成しましたので、よろしければご利用ください。（以下のバナーより無料でダウンロード可能です）

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

契約形態

オフショア開発企業のサービスは、契約形態の違いにより、請負型とラボ型に大別できます。
ラボ型は、準委任契約として一定期間、人材の稼働に対して費用を支払います。
稼働人数 × 契約期間に対して対価を支払うイメージです。
契約期間内であれば仕様の変更などにも柔軟に対応できますが、成果物の完成に責任は発生しないので発注側企業も含めたプロジェクトマネジメントの意識が求められます。

一方、請負型はその名の通り請負契約での契約です。
プロジェクト全体の予算と成果物をあらかじめ決めて契約します。
契約で定めた要件通りの成果物を納品することに責任が発生しますが、追加の要望や仕様の変更はできません。
どうしても必要な場合は別途契約となり費用が膨らむことを覚悟しなくてはなりません。

オフショア開発における契約形態の違いとそれぞれのメリット・デメリットについては以下の記事にて解説していますので、参考にしてください。
※参考記事：ラボ型オフショア開発とは？メリットや請負型との違いも説明（新しいタブで開きます）

オフショア開発国

オフショア開発の拠点国がどこなのかも重要な視点です。
国によって対応言語・法律・文化・祝日・時差・人件費相場・得意とする案件の種類などが異なります。
自社の要件を満たしていること、国の違いによってプロジェクトに生じるリスクを把握し、万が一の場合にも自社、もしくは選定企業でコントロール可能であることが重要となります。
拠点国として代表的なのは、ベトナム・フィリピンなど東南アジア圏の国です。
どの国なら OK という正解がある話ではありませんが、それぞれの国においてメリット・デメリットになり得る特徴があります。

わかりやすいのは言語の違い、国民の祝日の違い、時差などでしょう。
祝日や時差はトラブル時の緊急対応のしやすさや納期などに影響します。
他にもリスクになる可能性として政治情勢の観点もあります。
政治情勢が不安定な地域に拠点を置く企業は、ビジネス環境に影響を及ぼす可能性があります。
そのため、リスクマネジメント能力が必要であり、自然災害や感染症の流行なども考慮すべきです。
前提として適切な現地情報の収集とリスク評価ができている企業かは確認しておきましょう。
企業によっては異なる複数の国に拠点を持っていることもあります。

オフショア開発の代表的な国とその特徴については以下の記事で解説していますので参考にしてください。
※参考記事①：オフショア開発とは？簡単にわかるメリットや最新の市場動向（新しいタブで開きます）
※参考記事②：フィリピンのオフショア開発の特徴を紹介｜メリット・デメリットを解説します（新しいタブで開きます）

推進・社内体制

オフショア開発プロジェクトが失敗する原因としてよく挙げられるのが「コミュニケーション齟齬」と「品質管理体制」です。
言語・文化が異なるメンバーを含めてプロジェクトマネジメントをする必要があるため、国内で日本人のみのメンバーでのプロジェクト推進よりも難易度が上がる傾向があります。
以下に挙げるような体制があるかどうかは確認しておいた方が良いでしょう。

現地エンジニアのスキルレベル

国内の開発企業へ依頼する場合も重要ですが、人材のスキルとそのレベルがプロジェクトにマッチしているかは確認しましょう。
特にラボ型の場合は、中期的に同じチームの一員のような形でプロジェクトを進めていくことになります。

スキルだけでなくアサインメンバーの人柄なども含めて、自社のプロジェクトメンバーとの相性も確認をした方がいいでしょう。
また、現地人材のスキルアップのために企業としてどんな取り組みをしているかを聞くことで企業姿勢の判断材料にもなります。
集めた人材をきちんと育成するスタンスなのかどうかは人材の質に繋がるポイントでもあります。

ブリッジSEの有無とスキルレベル

ブリッジSE（新しいタブで開きます） は、オフショア開発において日本側の開発チームと海外の開発チームの間に立ち、双方の意思疎通をスムーズにすることが主な役割です。
具体的な業務としては、オフショア先への説明、仕様書・設計書の作成、日本側（クライアント）の要件や仕様を海外の開発チームに翻訳して伝える、海外の開発チームからの報告や進捗状況を管理、開発成果物の品質管理などを行い、現地語の語学力やマネジメントスキルが必要とされます。
企業やサービスによっては、そもそもブリッジSE がいなかったり、オプションとなっているケースもあります。

自社にこの役割を担える技術的知見と語学力、そしてプロジェクトマネジメントスキルを兼ね備えた人材がいる場合は別ですが、そうでない場合オフショア開発プロジェクトの成否のカギを握る人物となり得ます。
ブリッジSE がいるかどうか、プロジェクトにアサイン可能か否かは検討のポイントになるでしょう。
※参考記事：ブリッジSEとは？オフショア開発での役割と必要性、注意点も解説（新しいタブで開きます）

日本語コミュニケーション能力

上述したブリッジSE が担う場合もありますが、プロジェクトの窓口となるカウンターパートの人材が日本語で円滑なコミュニケーションがとれるかどうかは重要なポイントです。
ミーティング時の口頭コミュニケーションはもちろん、メールやチャット、仕様書などのドキュメント類にいたるまで、日本語でどの程度のコミュニケーションが可能なのか確認をしましょう。
営業の担当者は日本語堪能だったが、プロジェクトがはじまってみると担当者は日本語が得意ではなくコミュニケーションにおける誤解やミスが多いといったことの無いように注意が必要です。

品質管理体制

オフショア開発のよく聞く失敗例として成果物の品質が低いことが挙げられます。
要件の定義が甘かったり、コミュニケーション齟齬があったりすることで発生するケースが多いのですが、「ありがち」な失敗であるため、どんな対策で防止しようとしているかは確認しておいた方が良いでしょう。
具体的にはシステムテストの体制をどうしているか、コードの品質はどう担保しているかなどが挙げられます。
たとえば手前味噌ですが、当社、スパイスファクトリーの場合、QAエンジニアによるテストの実施で「機能レベルの外部品質担保」やブリッジSE による 2重レビューによる「コードレベルの内部品質担保」をしています。

それ以外にも、海外のエンジニアの特徴を理解してプロジェクトにアサインできるように、日本のブリッジエンジニアと海外エンジニア間での毎日のチームコミュニケーションや作業の連携フローを徹底しています。
当社の取り組みについては以下のページもぜひご参照ください。
（新しいタブで開きます）

プロジェクト体制の柔軟性

プロジェクト推進体制で気にしておくべき点として体制の柔軟性があります。
オフショア開発の拠点国に多い東南アジア諸国においては、文化的な違いとして転職へのハードルが日本に比べて低いということがあります。

プロジェクトの担当者やエンジニアが体調不良や退職でいなくなってしまうということはあらゆるプロジェクトで起き得ることですが、転職の頻度が高い東南アジアの国などがオフショア拠点国の場合、プロジェクト期間中にアサインメンバーが辞めてしまうといったことが起こりやすいといえます。
もちろん、退職などによるメンバーの離脱が起こらないに越したことはありませんが、そうなってしまったときに人材が十分におり、柔軟に別メンバーがフォローができる体制か、フォロー時にスムーズな引継ぎができるか（決定した仕様のドキュメント化や議事録の保管が出来ているかが重要になります）などは確認しておくと安心です。

得意領域

オフショア企業が得意とする領域も重要です。
どんな開発言語やフレームワークを使うことが多いのかや、サイト制作・アプリ開発・ Webサービス開発・ AI ・ IoT ・ゲーム開発など、得意とする案件の特徴も企業ごとに差が出るポイントでもあります。
企業が得意とする領域を把握することで、自社のニーズに合った企業を選定することができます。
また、企業が得意とする領域については、後述する実績と合わせて詳しく調べましょう。
過去案件での体制や開発手法、プロジェクト期間についても確認し、自社の開発との適合性を見極めます。

実績

自社が開発依頼しようとしている成果物の類似案件があるか、同業界の対応実績はあるかなどを確認します。
一概には言えませんが、自社の依頼内容に近しい事例がある方が安心でしょう。
開発会社から提供される実績資料などももちろん参考になりますが、少し踏み込んで、開発規模や期間、アサイン人数などを確認し、事例としてあまり積極的には出したくないであろうトラブル発生時の対応についても聞いた方がよいでしょう。
技術力や品質管理力、プロジェクトマネジメント力などを推し量る重要なポイントとなります。

提案力

オフショア開発企業は、その事業の成り立ちから国内の開発案件の下請けとして成長してきた背景があります。
そのため、指示された業務をこなすことは得意なものの、良いプロダクトにするために能動的な提案をする力は低い企業が比較的多いとされています。
実際、Resorz社が公表している『オフショア開発白書（2022年版）』（新しいタブで開きます）※ではアンケート調査の結果としてオフショア開発企業が弱みに感じているポイントとして「営業力（レスポンスの速さ/提案力）」「デザイン力（UI/UX）」という回答が TOP となっています。
自社においてデザインや作りたいシステムについて明確に要件を整理出来ていれば大きな問題にはなりませんが、現代のデジタルプロダクトにおいて、ユーザーにとっての使いやすさである UI/UX の視点は重要度を増しています。

より良いプロダクトを開発企業の専門的なアドバイスをもとに一緒につくる形を望むのであればチェック項目として設けるべきでしょう。
他にも以下の記事ではオフショア開発で失敗しやすいポイントを解説しておりますので参考にしていただき、企業選びに活かしていただければ幸いです。
参考記事：オフショア開発は失敗しやすい？よくある失敗パターンの原因と対策を解説（新しいタブで開きます）
※参考文献： 出典：『オフショア開発白書（2022年版）』（オフショア開発. com）（新しいタブで開きます）

高品質なオフショア開発が希望ならぜひスパイスファクトリーも候補に

この記事では、オフショア開発企業を選定する際に重要な観点について解説してきました。
国内でシステム開発を外部企業に依頼する際にも共通するポイントもありますが、海外拠点を活用するオフショア開発独自の注意点や確認点を事前に把握したうえで企業選定することが重要です。

当社、スパイスファクトリーではフィリピンにオフショア開発拠点を設け、国外のリソースも活用したアジャイル開発を展開しています。
ブリッジSE らによる、万全の品質管理体制を用意している他、国内の UI/UX デザイナーと協働しユーザーにとって使いやすいシステム・プロダクトとなるよう専門的な提案もさせていただきます。
システム・ Webサービス開発やオフショア開発に関する相談がある方は、お気軽にお問い合わせください。

https://spice-factory.co.jp/service/offshore-development/

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

IT人材の不足や DX推進の潮流において、システム開発を社内のリソースで行う内製化の取り組みが注目されています。

一方で、エンジニアリソースの確保の困難さなど内製化は簡単な取り組みではなく、一足飛びには難しいものでもあります。

このような課題がある中、内製化を実現する手法の一つとして、AppSheet を活用することが考えられます。ノーコード開発を実現する AppSheet により、これまで費用対効果の面やリソースの面などでシステム化が難しかった領域も含め、自社での開発を実現することができるでしょう。

この記事では、AppSheet の概要や特徴、活用例、料金などを紹介します。

弊社スパイスファクトリーには豊富な実績があります。

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

AppSheetとは？

AppSheet とは、Google Cloud のサービスの1つとして提供される、ノーコードでアプリを開発できるプラットフォームです。
ノーコードとは、プログラミングを行うことなく、画面上で各種設定や UI/UXデザインを実施することでアプリを開発する手法のことです。非エンジニアでもアプリを開発することができることもあり、IT人材不足が続く昨今においてノーコード開発の注目度は高まっています。

AppSheetの特徴

プログラミングをせずにアプリを開発

AppSheet を利用することで、画面上での設定や簡単な関数などの記載によりアプリを構築することができます。
自社でアプリ開発を行うメリットの一つは、スピード感です。従来、社外ベンダーに依頼して開発を行っていた場合は、見積や契約、発注手続きなどに時間がかかっていました。一方で、AppSheet により自分で開発や修正を行うことができれば、実際に手を動かす時間のみで対応が可能となります。
また、IT人材が不足する状況において、非エンジニアでもアプリ開発を行うことができる点は大きなメリットといえるでしょう。

Google Workspaceの機能を活用した開発を実現

AppSheet でのアプリ開発にあたっては、Google Workspace のスプレッドシートをはじめとして、業務で利用しているデータをそのまま利用することができます。また、Gmail との連携も可能です。dynamic email という仕組みを使うと、Gmail 画面上に AppSheet で作成したアプリを表示し、Gmail上で操作することができます。業務を Google Workspace で実施している企業であれば、とくにそのメリットを生かすことができるでしょう。
なお、AppSheet では Google関連サービスだけではなく、Microsoft Office の各種サービスや Dropbox、Salesforce などのサービスと連携し、データを利用することもできます。

Automationによる作業効率化も可能

AppSheet には、Automation としていわゆる RPA （Robotic Process Automation）機能が備わっています。Automation を利用することで、日常的に実施している定型作業を自動化できます。
たとえば、毎日何十件もスプレッドシートからドキュメントへ転記を行っているのであれば、Automation の利用が便利です。このような定型かつ繰り返しの多い作業は、自動化により業務効率を大きく上げることができます。

ノーコード・ローコード開発が有効な場面

AppSheet をはじめとして、近年ノーコード開発 および 最小限のプログラミングでアプリを開発できるローコード開発に注目が集まっています。この背景として、DX推進に伴い内製化を進める企業が増えている点が挙げられます。経済産業省「DXレポート2※」でも指摘されているとおり、DX の進展においては内製化を進めることが重要です。

一方で、これまで自社開発を行ってこなかった企業においては、一足飛びに大規模な開発を行うことは難しい状況にあります。そこで活用を検討したいのが、比較的スキルを必要せずにアプリ開発を行えるノーコード・ローコード開発という手法です。
ノーコード・ローコードでの開発は、自社の基幹システムのように大規模開発を行う際には向かないものの、これまで投資対効果が合わなかったような比較的小規模の業務領域をカバーする選択肢として有効です。近年では、ノーコード・ローコード開発を実現できるプラットフォームとして、AppSheet のようにクラウド上で簡単に利用できる aPaaS （アプリケーションPaaS）が提供されています。これらを活用することで、手軽に開発を行うことができるようになりました。

※参考①：経済産業省『DXレポート2』（中間取りまとめ）（新しいタブで開きます）
※参考②：進むシステムの内製化 メリットや難しさを踏まえどう取り組むべきか（新しいタブで開きます）

AppSheetで開発できるアプリの例

以下では、具体的なイメージを持ちやすくなるように、AppSheet で開発できる主なアプリの例を紹介します。

案件管理アプリ

営業活動やカスタマーサポートなど、案件の管理はさまざまな場面で必要です。
世の中には Hubspot（新しいタブで開きます） をはじめとしてさまざまなツールが用意されているものの、規模が大きくない組織・チームにおいてはスプレッドシートで案件を管理しているケースも多いのではないでしょうか。
AppSheet を利用することで、コストをかけることなく案件管理を実現することができます。スプレッドシートに登録されているデータを AppSheet で作成したアプリ上で表示しつつ、重要度や進捗状況で部員類したり、担当者のアサイン状況を把握したりすることができます。
案件の登録フォームを作成すれば、スプレッドシートを操作せずとも案件の追加が可能となります。担当者がフォーム上で必要事項を入力するようにすれば、必要事項の入力漏れチェックもできます。また、Looker Studio などの BIツールと連携すれば、データ分析や高度なグラフ作成まで行うことも可能です。

工数管理アプリ

稼動状況を把握するために行う工数管理ですが、入力の面倒さから挫折してしまうケースも多いでしょう。
そのような場合には、アプリ化することで入力効率を上げることができます。
アプリ上で入力フォームを作成することで、プロジェクトと稼働時間を選択するだけで工数登録ができるようになります。これにより、面倒な工数入力を最小限の労力で行えるようにできます。Automation も併用し、入力がないメンバーに対してメールなどでリマインダを送ることもできるでしょう。
登録された工数管理は、スプレッドシートとして出力することもできますし、アプリ内でグラフ化などを行うこともできます。

申込書の読み取り自動化

申込書を受領した際に、それをスプレッドシートに手で入力しているというケースは多いのではないでしょうか。
Automation により、これらの作業もコストをかけず効率化できます。
あらかじめ様式を定めた申込書を読み込ませることで、スプレッドシートにまとめる処理を自動化。その後の集計や可視化、受領メール連絡などを Automation で自動化することもできます。

AppSheetによるアプリ開発の流れ

以下では、AppSheet によるアプリ開発フローを具体的に紹介します。今回は、部署内での経費申請・承認を行うワークフローアプリを開発します。

アプリの作成

アプリを作成したい場合、AppSheet にログイン後に Createボタンを押下し、App → Blank App を選択します。

アプリの名称とカテゴリを設定すると、アプリの作成が開始されます。今回は「部署内経費申請」という名称のアプリを作成します。

処理が完了すると、画面が遷移します。サンプルとしてタスク管理機能を持ったアプリが自動的に作成されます。

申請書の項目設定

続いて、デフォルトで生成されるテーブルを変更して、ワークフローを実現するために必要なデータを扱えるようにします。
左カラムの「Data」を選択後、デフォルトで作成された「Table 1」を選択すると、現在のデータ項目が表示されます。ここで「View data source」ボタンを押下すると、データ項目の編集を行うことができます。

既存のテーブルを修正し、「経費申請テーブル」として日付、申請者名、用途、摘要などワークフローに必要なデータを登録します。

AppSheet では、数値やテキスト、日付、リストなどさまざまなデータ形式から選択してテーブルを作成できます。たとえば、経費申請の「用途」の項目において、「物品購入」「セミナー参加費」「その他」という3つから選択させたい場合は「Enum型」を利用します。また、申請や承認のステータス管理を行う場合は、「Yes/No型」を利用するとフラグ管理ができます。

今回は、以下の図のとおり「経費申請テーブル」として各データ項目を設定しました。

テーブルを変更すると、自動的にアプリ画面も変化します。たとえばEnum型を利用した「用途」の項目については、画面上ではリストから選択できるようになります。

物品テーブル・ユーザーテーブルの作成

次に、複数のテーブルを結合して利用できるようにします。今回は、購入品目を設定する「物品テーブル」を作成します。
テーブルを追加したい場合、同様に左カラムから「Data」を選択後「Add new Data（プラスボタン）」から行います。以下のとおり、テーブル名称などを設定したうえで、「物品名」や「金額」などのデータ項目を設定していきます。


続いて、最初に作成した「経費申請テーブル」と物品テーブルを結合します。物品テーブルに Reference型の項目を追加し、参照先を経費申請テーブルとすることで、両者を紐づけられます。

関連付けを行うことで、アプリ画面にも反映されます。最初に作成した申請画面上で物品を登録したい場合、新たに追加された Addボタンを押すことで登録できます。これにより、複数の物品を一つの申請書に追加できるようになりました。

ユーザーテーブルの作成

申請や承認の状況を管理できるようになりましたが、現在では誰でも申請を承認できる状態となっています。そこで、次に承認権限者の管理を行うための「ユーザーテーブル」を作成します。
同様にテーブルを作成の上、名前、メールアドレスに加えて、このユーザーが承認者（＝部長かどうか）を設定できるようにします。

申請・承認ボタンの作成

次に、申請・承認ボタンを作成します。処理の設定は左カラムの「Actions」より行います。
「経費申請」の「Add Action（プラスボタン）」を押下すると、新しいアクションを登録できます。

アクション名称を「申請をする」としつつ、アクションとして「Data：set the values of some columns in this row」を選択。set these columns において「申請されたか」を対象とすれば、承認ボタンを押すことで「申請されたか」のフラグがYesとなります。

同様に、承認ボタンを作成し、ボタンを押すことで「承認したか」フラグを Yes とできるようにします。画面側にも「申請をする」ボタンと「承認をする」ボタンが表示されました。

承認できる条件を限定する

最後に、承認できる権限者を限定すれば、アプリは完成です。承認権限を持つユーザー（＝部長）のみに承認ボタンが表示されるように修正します。
「承認をする」アクションの「Behavior／Only if this condition is true」の欄を選択します。

ログインしているユーザーのメールアドレスを基に、ユーザーテーブルを参照して部長権限があるかをチェックします。以下のコードを入力することで、権限のチェックを行えるようにします。

これにより、権限がないユーザーには承認ボタンが表示されないようになりました。

同様に、条件を設定することで「申請済みでないものは承認ボタンを表示させない」「承認済みのものは承認ボタンを表示させない」といった制御も可能です。

アプリの共有

作成したアプリは、Shareボタンから共有することで他の人にアプリを使ってもらうことができます。

このように、AppSheet では画面上での設定や条件入力などを行うことで、簡単にアプリを構築することができます。

AppSheetの価格

AppSheet にはさまざまなプランが用意されています。
まず、作成したアプリを他のユーザーへ公開しない限り、Appsheet は無料で利用できます。最大10ユーザーまでは、試験的に作成したアプリを共有することもできますので、小規模な利用においては無料プランでも問題ありません。
それ以上の利用を行う場合は、Starterプラン、Coreプラン、Enterprise Standardプラン、Enterprise Plusプランから選択することになります。各プランの主な違いは以下のとおりです。

• Starterプラン：$5/ユーザー/月。基本的なアプリ開発と自動化が可能。
• Coreプラン：$10/ユーザー/月。NFCの利用やセキュリティ管理など高度な機能や、メールでのサポートが追加。
• Enterprise Standardプラン：都度見積。機械学習や外部API の利用なども可能に。
• Enterprise Plusプラン：都度見積。ガバナンスなどすべての機能が利用可能。

詳細については、以下の価格表もご参照ください。

※参考：Appsheet「Start building and testing apps」（新しいタブで開きます）

Appsheetで自社開発実現

この記事では、ノーコード開発を実現する AppSheet について、その概要や特徴、活用例などをご紹介しました。比較的小規模のアプリであれば、AppSheet を活用することで低コスト・ハイスピードに開発を実現することができます。業務の効率化はもちろんのこと、新規事業開発やPoC におけるプロトタイピングなどにも活用できるでしょう。
スパイスファクトリーでは、PoC におけるプロトタイピング構築や UXリサーチなどの支援を行っています。AppSheet を利用すべきか、開発を行うべきか悩まれている方や、デザイン面も含めた支援が必要である方は、ぜひ（新しいタブで開きます）ください。

当社の プロトタイプ開発支援サービスについては以下のページをご確認ください。

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

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

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

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

IT人材の不足やコストメリットから、海外に業務を委託するオフショア開発に目を向ける企業は少なくありません。しかし、期待した効果を得られず、結果的に失敗してしまうケースがあります。この記事では、オフショア開発初心者の方や一度失敗したことがある方に向けて、失敗例をもとに原因と対策を紹介します。
スパイスファクトリーはフィリピンにオフショア拠点を持ち、徹底した品質管理と円滑なコミュニケーションで「ハイクオリティオフショア開発」を提供してきました。オフショア開発に関する具体的な相談がある方は、（新しいタブで開きます）ください。
以下の記事も参考にどうぞ。
オフショア開発会社の選び方とは？確認すべきポイントを解説（新しいタブで開きます）

オフショア開発のよくある失敗例

オフショア開発（新しいタブで開きます）を進める中で「これなら日本国内で開発した方が良かったかも……」という結果になってしまうことは残念ながらよくあります。この章では、オフショア開発のよくある失敗例を紹介します。

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

成果物が低品質

納品されたプロダクトやサイトの品質が想定以上に低いのは、オフショア開発でよくある失敗のひとつです。
たとえば、以下のようなケースが考えられます。

• • 正常に動かない
  • 表示崩れがある
  • 必要な機能がない
  • 想像していたデザインと違う

成果物が低品質なのは、エンジニアの質が低いという原因だけではありません。
事前に明確な仕様を伝えていなかったり、依頼側としてはよしなにやってくれると思っていたが、期待と違っていたりといったケースもあります。
オフショア開発のメリットとして比較的コストを抑えられると知られています。しかし、上記の通り品質に関わる失敗例が多いため、オフショア開発に安かろう悪かろうのイメージを持っている人も少なからず存在するのが現状です。

納期が守られない

スケジュール通りにプロジェクトが進まず、納期が遅れるのもオフショア開発でよく聞く失敗のパターンです。
納期遅れの理由としては、初期のスケジュール設計の際に要件が整理されておらず、後から追加の開発が必要だと判明する、という国内でもよくあるケースが挙げられます。
また、残業してまで納期に間に合わせようという感覚がないといった、納期にややルーズな文化がある国も存在するため、管理がうまくいかず遅延につながる場合もあります。

予算をオーバーしてしまう

日本国内での開発でも同様ですが、請負契約の場合は基本的にプロジェクト期間中の仕様変更ができません。
追加機能など後から必要な開発が増えると、想定以上に費用がかかってしまうでしょう。
オフショア開発では、言葉や文化の壁による品質低下や納期遅れをカバーするために、追加費用が必要となることも考えられます。さらに、経済・為替の状況で単価が高騰するといった外部環境に影響を受けて予算を超えてしまうケースもあります。

また、オフショア開発ではプロジェクトの立ち上げ時にイニシャルコストがかかります。
メンバーの構成やルールの明文化などの体制構築やコミュニケーションに時間がかかるためです。
上記から、短期間のプロジェクトではオフショア開発のコストメリットを享受できないこともあります。

なぜオフショア開発は失敗するのか

前の章で紹介した通り、オフショア開発にはよくある失敗パターンがあります。なぜそのような失敗が起きてしまうのでしょうか。ここではその原因を解説します。

コミュニケーションの行き違い

コミュニケーションの行き違いはオフショア開発において最もよく起こる、かつ根深い問題の1つです。
言語が違うだけでなく、文化や商習慣にもギャップがあり日本の常識が通用しません。
お互いの「普通」の感覚がズレているため、行き違いが生じてしまいます。
さらに、コミュニケーション齟齬の内訳として 3点ご紹介します。

言語の違いから起きる行き違い

母国語を使わない会話では、どうしても細かい部分を伝えられません。
相手の言葉を間違って理解してしまうこともあるでしょう。
オフショア開発では、要件定義書を用意して開発先に渡し、現地でブリッジSE（新しいタブで開きます） や PM などが現地語または英語に翻訳して作業するといった形がとられます。その翻訳時に、誤訳や誤読があると、依頼側の意図とは異なる仕様で開発が進むというミスが発生します。

文化の違いから起きる行き違い

生活習慣や商習慣など、文化の違いからも行き違いが発生します。
日本人には「よしなにやる」「阿吽の呼吸」に代表されるように、相手の意図を汲み取って柔軟に仕事を進めることがよくあります。しかし、基本的に外国籍のメンバーには「そのあたり、うまくやっといてください」などの曖昧な指示は通用しないと考えておくべきでしょう。「そのあたり」とは何か、「うまくやる」とは具体的にどういうことか、「いつまでに」するのかを具体的に伝える必要があります。

他にも、仕事に対する価値観や年中行事の違いにも注意が必要です。
たとえば、フィリピンではクリスマスなどのイベント近くでは「家族」の優先順位が仕事を圧倒的に上回り、ベトナムではとりわけテト（旧正月）を大事にします。当然ながら国民の祝日も日本とは異なりますので、スケジュールを決める際には注意が必要です。

物理的な距離から生じる行き違い

物理的な距離から生じる行き違いも存在します。
拠点としている国と日本との時差によっては、必要なタイミングでのクイックな連携は難しいでしょう。
対面コミュニケーションには細かなニュアンスを伝えやすかったり、気軽にコミュニケーションが取れたり、雰囲気などの非言語情報を得やすいなどのメリットがあります。
海外にチームがある場合、どうしてもこのメリットを受けにくい体制となるためコミュニケーションに行き違いが発生しやすくなります。

管理体制の未整備

言語や文化差・距離によるコミュニケーション齟齬は、どれだけ配慮しても完全になくすことが難しい問題といえるでしょう。
オフショア開発ではそうした違いを前提としたうえで、品質を担保するための管理体制の構築が重要となります。
この管理体制がうまく機能しない場合も、失敗を引き起こしてしまいます。
以下に管理体制の構築がとくに必要な領域をご紹介します。

コード品質の管理

オフショア開発においては、依頼側が認識しているレベルのコード品質が担保できるように、レビューやテストなどの体制整備が欠かせません。
エラーが出ないか、といった一般的なシステムテストの実施はもちろん、単に動くだけでなくメンテナンス性を考慮したコード品質の管理体制が重要です。
コード品質の管理体制が機能していない場合、仕様書通りの動作はするもののパフォーマンスが悪かったり、リリース後に多くのバグが発生したりといったことが懸念されます。

プロジェクトマネジメントの体制不備

先述の理由からコミュニケーションの行き違いが起こりやすいオフショア開発においては、国内での開発以上にプロジェクトマネジメントが重要といえるでしょう。
言語や文化の違いを踏まえて、余裕を持ったスケジューリングや突発的なトラブルへの柔軟な対応が求められます。
たとえばベトナムでは「就社」ではなく「就職」の意識が強いといわれています。
今の会社でスキルを身につけ、成果を出して早く次の会社に転職して給料を上げたいと考えているため、プロジェクトの途中で担当エンジニアが変わるといったことはめずらしくありません。
そのような場合でもプロジェクト自体の遅延等が発生しないようにあらかじめ引き継ぎがしやすいような体制やチームメンバーがフォローしあえるようなルール・仕組み作りが大切です。
この点が体制として担保されていない場合、体制維持が難しくなりプロジェクト進捗や品質に影響を及ぼします。

失敗しないための対策

ここまで、オフショア開発のよくある失敗とその原因について確認してきました。
この章では、失敗を避けるために取るべき対策について解説します。
請負契約で自社がオフショア開発拠点をマネジメントする必要がない場合もプロジェクト成功のために協力は必須です。どういった点で協力できるのかを確認しておきましょう。
また、ベンダー選定の軸として、以下で紹介する内容ができている会社か確認をすることをおすすめします。

ラボ型の場合

ラボ型オフショア開発（新しいタブで開きます）の場合、オフショアメンバーが依頼する企業側のチームに参画するため、依頼企業側が直接マネジメントに入るケースが多いでしょう。
マネジメントにあたり、以下のような対策が必要です。

文化差の理解

基本として、文化差への理解と対応が必要です。
言語の違いはもちろん、日本の働き方の常識は通用しないことを前提としたうえで、協力して業務を進められる体制を構築します。

また、時差に関しては修正ができないため、気になる場合はフィリピンなど日本との時差の少ない（フィリピンは時差1時間）オフショア拠点を持っている企業に依頼することを検討しても良いでしょう。

ドキュメント化の徹底

コード規約や各種ルール、決定した仕様、その他技術的なナレッジも含め明確にドキュメント化して共有しましょう。
仕様や決定事項が明文化されれば、認識の行き違いを小さくできます。
仕様や技術的知見を蓄積しておくことで、万が一引き継ぎが発生した場合も柔軟な対応がしやすくなります。

ブリッジSE ・ QAエンジニアなどの参画でコードレビュー・機能テストを実施

オフショアメンバーに必要なコードの品質を理解してもらうことも重要です。
先述したドキュメント化でルールや共通認識を定めるのに加え、QAエンジニア（新しいタブで開きます）によるテスト・機能チェックやブリッジSE（新しいタブで開きます） によるコードレビューで品質の担保と基準レベルの共有を行えます。
※参考記事①：ブリッジSEとは？オフショア開発での役割と必要性、注意点も解説
※参考記事②：QAエンジニアの重要性とは？システム品質を保つプロが求められる背景や役割を解説（新しいタブで開きます）

可能な限り仕様の具体化

曖昧な情報から忖度して仕事を進めるのは、日本人ならよくあることです。しかし、これまでにお伝えしたとおり、オフショア開発においてこういった仕事の進め方は通じません。
そのため、日本側のメンバーで可能な限り仕様を具体的にしたうえで着手してもらうといった、依頼者側の工夫も必要です。

請負型の場合

請負型の場合、開発を依頼された側の企業がオフショア拠点を管理します。
実際の対策については基本的にラボ型の場合と共通です。加えて、直接管理を行わない依頼企業として、失敗を引き起こさないために協力できる点を以下で紹介します。

要件の具体化・明確化

曖昧な仕様が伝わらないのは先述のとおりです。
依頼側としても要件を明確にして提示することで認識の行き違いを減らせます。
直接的な管理をしないからと任せきりにならず、具体的にしてドキュメントなどで行き違いがないように伝えましょう。

企業選定時に実績等を確認しておく

日本国内でも同様ですが、依頼するシステムや制作物の類似案件を手掛けているなど、実績を把握しておくことで品質レベルが推し量れます。
依頼しようとしているシステムの類似案件の実績がある企業を選べば、失敗のリスクを下げられるでしょう。

どのような対策をしているか確認する

本記事で紹介してきた課題に対し、どのような対策を講じているのか聞いてみることをおすすめします。
何らかの対策ができている企業であれば、快く対策内容を教えてくれるでしょう。
何の対策もされていない場合は、依頼を考え直すことも必要です。
体制に不安が残る企業への依頼を避ければ、オフショア開発で失敗するリスクを減らせるでしょう。

課題はどの会社も抱えている

オフショア開発を実施する場合、大小の差はあれど、どの企業も今回ご紹介したような課題を抱えているでしょう。
重要なのは課題がないことではなく、課題に対して適切な対策を講じることができているかどうかです。
当社スパイスファクトリーでは、社内QAエンジニアによる「機能レベルの外部品質担保」とブリッジエンジニア／エンジニアリングマネージャーの 2重レビューによる「コードレベルの内部品質担保」、現地駐在責任者によるマネジメント体制構築や CTO による直接の技術指導、などを実施してオフショア開発の課題解消に取り組んでいます。
オフショア開発の依頼を検討している方は（新しいタブで開きます）ください。
本記事の内容が皆様のお役に立てれば幸いです。

https://spice-factory.co.jp/service/offshore-development/

 

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

（新しいタブで開きます）
海外拠点へ開発業務をアウトソースするオフショア開発。コストメリット以外にも、国内で不足しているエンジニアなどのリソースを確保する手段として注目されています。
オフショア開発には、契約形態に応じてラボ型と請負型の2種類のサービス形態があることをご存知でしょうか？
オフショア開発を提供する企業に委託する場合には、各契約形態の特徴を理解したうえでどのような契約形態とするかを踏まえて依頼する必要があります。

この記事ではオフショア開発の代表的な契約形態であるラボ型と請負型の違いを解説しつつ、当社が提供する第三の選択肢もご紹介いたします。

ラボ型・請負型は契約形態の違い

オフショア開発のサービス形態は、その契約形態の違いからラボ型・請負型の2種類が存在します。この章では ２つの違いについて紹介します。
まずはオフショア開発について知りたいという方は以下の記事をご参照ください。
オフショア開発とは？簡単にわかるメリットや最新の市場動向（新しいタブで開きます）

ラボ型開発とは

準委任契約によるオフショア開発をラボ型開発と呼ぶことがあります。
準委任契約は取り決めた作業時間・拘束時間に対して報酬を払う契約であり、システムの完成責任や契約不適合責任としてバグ等の修正責任もありません。
その代わりに善管注意義務としてプロフェッショナルとして責任を持った対応が求められます。
ラボ型開発（準委任契約）の場合、稼働人数×契約期間に対して対価を支払うことが一般的です。

請負型開発とは

請負型開発は請負契約によるサービスです。
システム開発の請負契約では、開発するシステムの内容を契約で定めます。
受託者は、契約で定められたシステムを成果物として完成することに責任を負います。受託者にはシステムの完成責任や契約不適合責任がありますが、機能追加など契約で定められていない内容に対応する必要はありません。
請負型（請負契約）の場合、成果物の開発ボリュームによって事前に見積を行い、対価を決定することが一般的です。

続いて、各契約形態の特徴から発生するメリット・デメリットを解説します。

ラボ型開発・請負型開発のメリット・デメリット

ラボ型開発のメリット

まずは、ラボ型開発のメリット・デメリットです。

仕様の変更に柔軟に対応できる

準委任契約であるラボ型開発は、仕様変更に柔軟に対応できることがメリットです。
契約中に仕様変更や追加の要件が発生した場合でも、契約しているリソースの範囲であれば対応可能です。

優秀なエンジニアを長期間確保しやすい

ラボ型開発では、特定のエンジニアを自社の戦力として活用できます。
採用や育成のプロセスも必要なく、契約開始時から優秀なエンジニアのアサインが可能です。オフショア拠点として人気の東南アジア諸国のエンジニアは日本に比べ IT技術力が高いといわれており、優秀なエンジニアのリソース活用が期待できます。

ノウハウの蓄積と効率化が期待できる

比較的中長期で契約する場合、エンジニアからノウハウを獲得できる点もメリットです。
仕事の進め方やシステムに関する知見と経験が蓄積されることで、更なる品質向上や効率化が期待できます。
また、エンジニアに自社サービスやシステムの知見が貯まっていく点も同様にメリットとなります。ただし、属人化のリスクには注意が必要です。

ラボ型のデメリット

委託先への指揮命令権やメンバーの選任権はない

準委任契約で行うラボ型開発においては、発注者側に指揮命令権はありません。
万一、仕事場所や残業や休日出勤の指示などをした場合には、偽装請負に該当しますので注意が必要です。
業務委託契約で定義できるのは、あくまで業務の内容のみです。具体的な進め方については、委託先に任せる必要があります。
また、発注者側で特定のエンジニアの継続を指示することも NG です。プロジェクトに参加するメンバーの選定は受注側で行うものとなりますので、急な退職やメンバー変更の可能性は考慮が必要です。（あくまで要望として伝えることは可能です）

一定量の発注がない場合コストパフォーマンスが低くなる

プロジェクトが早期に終了した場合など、仕事はなくなっても拘束時間に対してはコストが発生します。よって、見積段階で業務内容と実施時間のバランスが取れているかを確認するとよいでしょう。

チームの立ち上げコストがかかる

ラボ型は契約するメンバーに対して、発注する側の企業がマネジメントを行う必要があります。
日本人同士のチームでも、業務が軌道に乗るまでは試行錯誤やルールの策定・見直しが必要でしょう。
言語や文化の違いでコミュニケーション齟齬が出やすいオフショア開発であればなおさらです。チームを育てる必要があるのは日本と同様。むしろそれ以上の手間がかかることは覚悟しておくべきでしょう。

人材の見極めが必要

自社の開発にマッチしたスキルを持っている人材をチームに加えてもらう必要があります。
契約の際に必要とするスキルのレベル感をしっかりと提示する必要があります。
要件を曖昧なまま契約が開始されてしまい、アサインされたメンバーが必要なスキルレベルに達していないという状況は避けたいはずです。
スキル面だけでなく、性格の面でもミスマッチが起こりがちです。円滑なチーム運営のためには依頼者側も現地メンバーの希望や文化の違いに一定の配慮が必要でしょう。

ラボ型に向いている案件

アジャイル開発案件

小規模な開発・テストを繰り返し行うような、いわゆるアジャイル型開発はラボ型とは相性が良いといえます。
※アジャイル開発については以下の記事にて詳しく解説しております。
アジャイル開発とは？ – システム開発を発注する時に知っておきたい開発手法の話（新しいタブで開きます）

請負型と異なり明確な仕様に基づき業務を発注しないため、作業途中の変更や改修においても契約の変更を行う必要がありません。そのため、スピード感のある開発が可能です。
参考記事：アジャイル開発 × オフショア開発の有効性 事例を通じて成功のためのポイントを解説！（新しいタブで開きます）

運用保守や継続・拡張開発など中長期の開発案件

委託先との調整が必要となりますが、ラボ型開発では中長期でリソースを確保することも可能です。
中長期でのリソース確保により、チームが軌道に乗れば業務の効率化やノウハウの蓄積が期待できます。
既存のプロダクトの運用保守や追加開発をラボ型チームに任せつつ、国内の別チームが新規サービスの開発に専念するといった活用方法も考えられるでしょう。

請負型のメリット

一方で、請負型にはどのようなメリットがあるのでしょうか。

成果物の品質が安定している

請負型では発注された仕様・要件に基づき開発し、契約時に定めた納期までに成果物を納品する必要があります。
上述した契約不適合責任があるため、原則として「不適合を知った時から1年」以内であれば委託先はシステムを修正しなければなりません※。
よって、委託側が契約書で定義した内容の成果物が納品されるというメリットがあります。

※ただし、契約不適合責任は契約にて内容を変更することが認められており、契約書上の定めが優先されます。

開発費用が事前に確定する

請負契約においては、開発内容とともに費用も定めます。
別途機能を追加するなど、仕様の変更をしなければシステム開発の費用が事前に確定するため、予算管理のしやすさなどについては企業にとってメリットとなり得ます。

請負型のデメリット

仕様変更が困難

請負型では基本的にウォーターフォール開発を採用することになります。
事前に要件定義フェーズとしてサービス開発範囲を定義してから、設計・実装・テスト・納品を進めるフローとなり、前の工程に戻る想定はされていません。
仕様の変更や修正には追加費用がかかる可能性もあり、また開発スケジュールによってはそもそも仕様変更が NG となるケースもあります。

開発ノウハウが蓄積されにくい

請負契約においては、委託先のプロジェクトマネージャーが業務を統括して開発を進めていきます。よって、要件定義で必要な要件のすり合わせが済んだ後は、開発の実務などに委託元企業が関与することは少なくなります。
委託元の企業に開発のノウハウは蓄積されにくいといえるでしょう。

請負型に向いている案件

要件が明確な場合

開発するシステムや成果物の要件が明確である場合、完成に向けて最短ルートで開発を行える請負型が向いています。
必要な機能が明確であれば、手戻りなく低コストでスピード感のある開発ができます。

予算に制約がある案件

予算に上限がある場合は、基本的に開発できる工数に制約が生じます。
少なくとも、請負契約であれば一定の費用で仕様に基づくシステムが開発できることは確定します。
準委任契約では必ずしも製品の完成を約束していないため、仕様の変更や進め方によっては完成までに費用がかさんでしまうこともあります。
ただし、請負契約において約束されるのは、あくまで事前に定めた仕様に基づいたシステムが開発されるというところまでです。
実際に業務適用できるのかや、環境変化による対応などは約束されません。

以下では、ここまでご紹介した内容を表形式でまとめています。

ラボ型契約が増えている背景

『オフショア開発白書2022※』によれば、2021年では 32% であったラボ型開発は 2022年の調査では 55％ になり、増加しています。
このような状況の背景には、オフショア開発に求められているニーズの変化があると考えられます。
従来のオフショア開発はコストダウンを主目的とすることが多く、プロジェクトベースで行われる案件において請負型で利用させることが多かったといえます。
一方で、近年は国内の深刻な IT人材不足の状況から継続したリソース確保のニーズが高まってきており、ラボ型の活用増加につながっています。
また、開発後の運用保守・追加開発に対してもオフショア利用を検討している企業が増えていることもラボ型の増加要因のひとつでしょう。
今後も日本国内のデジタル人材の不足は続くと思われます。コストだけではなく、安定した開発リソースの確保のためのラボ型でのオフショア開発需要は伸びていくと考えられます。
※参考：株式会社Resorz『オフショア開発白書2022』（新しいタブで開きます）

オフショア開発第3の選択肢「タイムチャージ型」

当社、スパイスファクトリーでもオフショア開発を提供しています。
当社では本記事でご紹介したラボ型でも請負型でもない「タイムチャージ型」というシステムを採用しています。
タイムチャージ型オフショア開発とは、ラボ型同様の準委任契約をベースに、ラボ型のデメリットだった「一定量の発注をし続けないと費用対効果が悪化する」といった点を解決する柔軟性を持たせたサービスです。
（新しいタブで開きます）

タイムチャージ型オフショア開発のメリット・デメリット

以下では、タイムチャージ型のメリット・デメリットを紹介します。

タイムチャージ型オフショア開発のメリット

最短1ヶ月単位での契約

タイムチャージ型の契約では最短で 1ヶ月から契約可能です。
一度契約が開始されたら、中長期で一定規模以上の発注をし続けないと採算が取れなくなってしまうラボ型と異なり、プロダクトやサービスのフェーズに応じて柔軟な契約を結ぶことができます。
たとえば、PoC（新しいタブで開きます） などの検証フェーズにおけるスモールスタートにも活用しやすい仕組みです。
もちろん長期契約もできますので、検証後の本格的な開発フェーズでは一気に契約時間を拡大して、本格リリースに向けた開発をするといった対応も可能です。

契約した時間の中でエンジニア以外のメンバーも柔軟にアサインできる

成功するシステムやサービスの開発に必要なのはエンジニアだけではありません。
UX を意識した画面デザイン、顧客の共感を生むためのブランディング、サービスのローンチ後にユーザーの集客や定着率を上げるためのマーケティングなどさまざまなスキルが求められます。
当社のタイムチャージ型サービスでは海外拠点での開発リソース確保に加えて、上記のようなさまざまな領域に専門性を持つ当社の日本メンバーをアサインすることもできます。
たとえば、サイト制作プロジェクトの初期では、サイトのコンセプト検討や提供価値の最大化のため、UX や UIなどデザイナーのスキルが必要となります。
企画フェーズではデザイナーに多めに工数を分配し、開発フェーズではオフショアエンジニアをメインに工数を分配できます。これにより、コストメリットと品質の両面を担保できます。
とくにオフショア開発企業はデザイン面を苦手としていることも多いため、ハイブリッドな体制構築によりデザイン面の価値も高めることができます。

品質担保の体制

従来のラボ型では、言語や文化の違いから成果物の品質管理などに課題がありました。
そのような課題に対応するため、当社ではお客さまと日本語でのコミュニケーションが可能なブリッジエンジニアをプロジェクトに参加させます。
また、社内QAエンジニア（新しいタブで開きます）による「機能レベルの外部品質担保」とブリッジエンジニア／エンジニアリングマネージャーの 2重レビューによる「コードレベルの内部品質担保」により、品質向上を目指しています。

タイムチャージ型オフショア開発のデメリット

アサインメンバーが完全固定ではない

当社が提供するタイムチャージ型では、一般的なラボ型とは異なり「人数 × 期間」で長期の固定のリソースを確保しません。よって、参画メンバーのリソースは専属で確保されるわけではありません。

品質担保のためブリッジSEのアサインが必須

品質担保のために、当社ではブリッジSE（新しいタブで開きます） や QAエンジニアの参画を必須としています。
ラボ型のサービスを提供する企業の中にはこれらを必須としないケースもありますが、当社では契約のリソースの中で最大の成果を出すためにブリッジSE や QAエンジニアは必須だと考えています。
そのため、とくに短期間のプロジェクトなどでは一般的なラボ型開発よりはコストが高くなる可能性があります。

成果物の完成が担保されない

ラボ型と同様に準委任契約であるため、仕様の変更や追加にも柔軟に対応できる一方で、成果物の完成については保証されません。
仕様の変更や方針転換があれば、必要な工数が増えてコストの増加に繋がってしまったり、完成までのスケジュールが想定より遅れてしまったりすることが考えられます。

タイムチャージ型オフショア開発に向いている案件

新規事業のサービスやプロダクト

タイムチャージ型は、アジャイル開発のような短い期間で機能開発を繰り返し、顧客の反応を見て方針を検討する必要があるような案件が向いています。
ラボ型とは異なりスモールスタートができることから、新規事業開発における PoC や、MVP構築などにも対応しやすいといえます。

デザインが重視されるサイト・プロダクト

タイムチャージ型は UX や UI などデザインが重視されるサービスやプロダクトとの相性が良いです。
請負型・ラボ型でもデザイナーとの連携は可能ですが、オフショア企業とは別の企業との契約が必要となるケースも多く、自社内や業務委託のデザイナーとの連携が必要となります。
コミュニケーションコストがかかるオフショアプロジェクトにおいて、自社デザイナーも含めた連携体制・品質管理体制が組めていることは、当社の大きなアドバンテージです。

以下では、上述したラボ型・請負型の比較に、タイムチャージ型も加えてそれぞれのメリット・デメリット・向いている案件を比較します。

タイムチャージ型で効率的な開発

この記事では、オフショア開発の代表的な契約形態であるラボ型と請負型の違いを解説しつつ、当社が提供するタイムチャージ型という第三の選択肢についてもご紹介しました。
エンジニアリングだけではなくデザイン面も含めて柔軟な対応ができるタイムチャージ型でのオフショア開発にはさまざまなメリットがあります。オフショア開発を検討されている方は、ぜひ一度検討してみてはいかがでしょうか。
タイムチャージ型についてより詳細な内容を知りたい場合は、当社までお問い合わせください。