少子高齢化・人口減少に伴う労働人口不足が顕在化するとされる「2030年問題」が話題となっています。

特に労働集約型産業の代名詞とも言える物流業界においては、2030年問題の影響を強く受ける可能性があります。

この記事では、2030年問題がどのように物流業界に影響を与えるのか、またその深刻さについて専門家の視点からわかりやすく解説します。

この記事をお読み頂くと、以下のような内容を理解することができます。

• 物流業界における2030年問題とは何か
• 2030年問題は物流業界にどのような影響を与えるのか
• 2030年問題に対してどの様な対策を行う必要があるのか

ぜひご覧ください。

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

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

2030年問題とは？

2030年問題とは、少子高齢化による労働力不足や社会保障費の増大などが2030年ごろに顕在化することを指します。内閣府が公表する「令和5年版高齢社会白書※1」によれば、2030年には65歳以上の高齢者が人口比率の30％を超えることが想定されています。

また、日本においては少子化も進んでいることから、加速度的に労働人口が減少していく状況にあります。

これにより、企業における人材不足や生産性の低下、社会保障費の増大による現役世代の負担増、地域社会の衰退といった事態が進む懸念があります。

※1参考：内閣府「令和5年版高齢社会白書」（新しいタブで開きます）

物流業界における2030年問題とは？

時間外労働に対して上限制限が設けられた、いわゆる「2024年問題」に引続き、ドライバー不足が深刻化すると予想されております。

特に地方部では深刻であり、野村総合研究所の推計※では2030年のドライバー数は2015年度と比較し、秋田県で46%に、青森県で48%に、高知県で49%にと、半数以下となると予想されています。全国で見ても、2030年のドライバー数は42.3万人と2025年度と比較して65%程度にまで減少すると推計されています。

結果、「個々の実質労働時間の短縮」に「ドライバー人数の慢性的減少」が重なる事で輸送能力(キャパ)の低下を招くこととなります。

上述した野村総合研究所の推計では、2030年には全国の約35%の荷物が運べなくなるといったシナリオが紹介されています。東北地方では約41%、四国地方では約40%と、ドライバー不足と同様に地方部で深刻な状況に陥ると予想されます。

また、物流倉庫内での荷役作業も未だ人手を中心とした運営が多く、慢性的な労働人口減少による影響を大きく受けております。物流倉庫が密集しているエリアでは相場時給を大幅に上回る人手争奪戦が生じたり、労働力不足を補うために作業熟練度の低い日雇い労働者を主な主戦力として採用せざるをえない状況下、作業生産性の低下・教育負荷の増加が生じております。
いわば、「モノを運べない」のみならず「モノを出せない」という状況に陥っております。

ECの一般化をはじめとして、物流インフラにかかる負荷が増える一方で、そのインフラの崩壊は経済活動にとって大きなインパクトを与えます。

輸送力不足は物流業界単体の課題を超えて、社会課題として重要な問題となります。

2※参考：野村総合研究所「トラックドライバー不足時代における輸配送のあり方」（新しいタブで開きます）

物流業界2030年問題が人々の生活に与える影響

商品価格の継続的値上げ

モノを運ぶ仕事量（需要）に対し担い手であるドライバー人数(供給)のバランスが崩れつつあり、供給力を増やすために物流会社は雇用コストを上げて人手を確保せざるを得ない状況となっております。

結果、あらゆる商品にて物流費高騰を一因とした価格の見直しが始まっております。

抜本的な課題が解決されていない状況下、商品価格の見直しが今後も継続する可能性がございます。

従来の輸送品質（リードタイム・日時指定etc.）が維持出来ない

ドライバー人数減少にて限られた輸送能力では、従来当たり前であった輸送サービスを提供する事が難しくなります。

近隣エリアであれば翌日納品可能であったリードタイムや曜日関係なく同一水準であったサービスが輸送能力の減少にてサービス変更・廃止を余儀なくされる事が予想されます。

また、昨今ニュースでも「不在時再配達」問題が取り上げられておりますが、限られた輸送能力を結果的に無駄に使ってしまっている状況を招いており、将来的には再配達の有料化も検討されております。

物流業界の労働環境について厳しいものであるという認識を持っている方も多く、たとえ賃上げを行ったとしても人材を確保できない可能性もあるでしょう。

2030年問題への対策

具体的に、物流業界においてはどのように2030年問題への対策を進めていくべきなのでしょうか。ここでは、いくつかの対策を取り上げてご紹介します。

物流DXによる生産性の向上

最も期待されているのが、物流DXによる生産性の向上です。あらゆる業界・業種において進むDXですが、物流業界においてもさまざまな領域において改善の余地が存在します。

国土交通省でも、国の物流政策の起点となる「総合物流施策大綱（2021年度～2025年度）※」の中で、「物流DXや物流標準化の推進によるサプライチェーン全体の徹底した最適化」を最初の方針として掲げるなど、国を挙げて物流DXの推進が進められているところです。

具体的には、以下のような取り組みが考えられます。

＜物流DXの例＞

●物流全体効率化システムの導入
物流業界の特性として、特定の事業者のみが単独でDXを進めることが難しいという点が挙げられます。よって、サプライチェーン全体を通して手続きの整備やデータ基盤の構築、システムの共有などを行う必要があります。

たとえば、サプライチェーンの上流から下流までが利用する物流全体効率化システムの導入はこのような施策の一つです。

●手続き書面の電子化
従来、FAXなどの書面や電話で行われることが多い民間事業者間の貨物集荷や防疫手続きなどを電子化するものです。

これにより、各所におけるデータの入力・出力の手間削減や入力ミスの防止による再入力の負荷軽減が期待できます。

●倉庫管理における機械化
先進的な倉庫で導入されつつあるピッキングロボットや無人フォークリフト、AGV（無人搬送車）などですが、このような自動化・機械化の技術をあらゆる工場へと広げていく取り組みも有効です。

一方で、中小規模の企業ではこれらの投資を行うことが難しいことも事実です。より安価な仕組みの開発が求められます。

●陸上輸送の効率化
トラックの隊列走行や自動運転トラックなど、近年では幹線輸送の効率化に関する取り組みも進んでいます。

幹線道路を利用するという関係上、企業単体での取り組みは難しいものも多いですが、これらが実用化されるとトラック輸送における人手不足問題に大きな効果をもたらすことができるでしょう。

●海運の効率化
内航船・外航船などの海運領域においては、AIや数理最適化アルゴリズムを利用した配船計画の最適化の取り組みや、船舶の自動監視による運航自動化、気象・海象などの情報を用いた航路の自動検討などの取り組みが考えられます。

船舶の自動運転の実用化により、人手不足への対策ともなります。

●配送の効率化
配送領域においては、自動運転カーやドローン物流などの検討が進んでいるところです。

現在、国や民間企業においてさまざまな実証実験が行われており、山間部や離島などの過疎地域における実用化の検討も進んでいます。

また、ソフト面ではAIによる配送経路最適化の検討も進んでいます。

このように、物流DXとして考えられる施策はさまざまです。2030年に向けてこれらの取り組みを進めることで、人手不足への対策を進めていく必要があると考えられます。

※5参考：国土交通省「総合物流施策大綱（2021年度～2025年度）」（新しいタブで開きます）

荷主主導による物流リソースの有効活用している企業事例

限られた輸送能力を効率的に活用すべく、複数荷主企業による共同輸配送化も積極的に検討が進んでおります。

トラックの積載効率は現状、非常に低い状況にあります。上述した「総合物流施策大綱」によれば、2016年度で39.9％であった積載効率は、2019 年度37.7％まで減少しています。

つまり、トラックの許容積載量のうち37.7%程度しか活用できていないという状況です。

積載効率が低い原因として、EC台頭によるケース小口化(店→個人宅)、多様化する輸送ニーズ対応(リードタイム・日時指定)が挙げられています。

たとえば、花王とライオンでは、それぞれの工場間での輸送を統合して行う取組みを進めています※。

また、ファッションEC大手のZOZO TOWNでは、ドライバーの負担軽減に関する協力を購入者に呼びかける「ゆっくり配送」を導入する取り組みも始まっております。

一般的に輸配送の条件を決めるのは荷主側であるため、物流会社単体での課題解決にも限界がありますが、2030年問題を踏まえると、トラックの積載効率向上・ドライバーの負荷軽減は重要なテーマであるため、垣根を超えた取組みの進展が期待されます。

※6参考：ライオン「花王・ライオンが協働してスマート物流への取り組みを開始」（新しいタブで開きます）

これからの物流DXについて

当社、スパイスファクトリーでは物流関連企業より依頼を受けたソリューション開発を数多く手掛けており、この度「物流2030年問題」の解決に向けた支援体制を強化すべく、「物流DX支援特化型チーム」をドライバーの日である2024年10月18日に立ち上げました。

https://spice-factory.co.jp/news/17958/

＜提供する物流DX支援の内容＞

• 物流DX実現に向けた既存プロセスのデジタル化や改善を推進するコンサルティング
• アジャイル開発を活用した物流DXプロジェクトの迅速な遂行支援
• データ活用による業務効率化や改善提案の提供
• DXツールの導入サポートおよび現場での最適化支援
• 独自のシステム開発から運用・保守に至るトータルサポート

物流DXには、IoT、ビッグデータ、AIのみならず物流業界ではあまり馴染みのない最新テクノロジー・ITツールも駆使したアプローチが業務プロセス変革の突破口になりうると当社は考えております。

当社では、実際にモノを運ぶという人手作業が残り続ける物流業界における「DX」に向けた一歩として、「今従事しているヒト」に焦点を当てた取組みが必要です。

▼今ある業務負荷をITの力で如何に削減・効率化していくか
▼データに不慣れな方でも如何にデータ活用できるようにするか
▼日々多忙の現場にて如何にデータ活用しやすい環境を構築するか

あらゆる高度なソリューション活用に当事者が時間を割けるよう、より使いこなせるよう
DXに向けた組織・環境作りが企業に求められます。

当社では創業当初より、UI・UXを意識した「ヒト」起点のシステム開発を手掛けており、物流関連企業様へのDX支援実績もございます。

▼データに不慣れな方でも如何にデータ活用できるようにするか
＜実績例：物流業務アプリの開発支援＞
日頃、物流業務で生じる分析や計算を機能として盛込み、手軽にデータ活用の一歩が踏み出せる業務アプリ。

▼日々多忙の状況下で如何にデータ活用しやすい環境を構築するか
＜実績例：物流センター内での作業配分最適化システムの開発支援＞
膨大な作業を「ロボット」でやるべきか「ヒト」でやるべきかを瞬時にデータ解析・選別し
作業管理者が日々Bestな運用を実現できるようにした支援システム。

まとめ

この記事では、2030年問題がどのように物流業界に影響を与えるのか、またその深刻さについて詳しくご紹介しました。2030年問題に対する解決策として、物流DXの推進は重要であると考えられます。

一方で、これまでデジタル技術を活用した事業変化という取り組みを経験されていないという方も多いのではないでしょうか。そのような方にとっては「そもそもどのように取り組みを進めたらよいのか」「誰に相談すればよいのか」という悩みを持たれていると思います。

当社、スパイスファクトリーでは「物流2030年問題」の解決を目指し、「物流DX支援特化型チーム」をドライバーの日である2024年10月18日に立ち上げました。物流DXには、IoT、ビッグデータ、AIのみならず物流業界ではあまり馴染みのない最新テクノロジー・ITツールも駆使した業務プロセスの変革が必要不可欠となります。当社では、これまでさまざまな社会問題をIT・DXのソリューションで解決してきました。

これらの知見・ノウハウを生かしつつ、私たちのパーパスである「1ピクセルずつ、世界をより良いものにする。」という理念を胸に、物流業界のDXを支援します。

物流DXについて悩まれている方、具体的な取り組みを進めたいものの進め方が分からないという方は、ぜひ一度当社までお問い合わせください。

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

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

記事の監修者

プロフィール
株式会社データ・シェフ　代表取締役
濵田 雅人（はまだ まさと）
業務改善コンサルティング会社の代表取締役として、業務フローの改善やデータ活用支援を提供。これまでに物流運営会社やシステム開発会社での物流関連システムの企画・設計・導入を担当し、効率化の推進に寄与。特に物流業界における業務改善やDX支援に注力し、豊富な現場経験に基づいた実践的なアドバイスが強み。物流センターの運営や経営に関するノウハウを持ち、理論だけでなく、システム開発等の知見を掛け合わせた具体的な現場改善策を提案できる点で高く評価されている。

こんにちは。企業のデジタル・トランスフォーメーションを全方位で支援するスパイスファクトリー株式会社です。

アジャイル開発は、迅速かつ柔軟にプロジェクトを進めるための手法として、多くの企業で採用されています。従来のウォーターフォール型開発とは異なり、アジャイル開発にはさまざまなメリットがある一方で、デメリットも存在します。

本記事では、これまで多くのお客さまのアジャイル開発プロジェクトを支援してきた当社の経験を踏まえ、アジャイル開発のメリットとデメリット、アジャイル開発手法の種類や活用事例について詳しく紹介します。

アジャイル開発とは？

アジャイル開発はソフトウェア開発の手法の一つであり、短期間の反復作業（イテレーション）を繰り返すことで、継続的なテストと改善を行いながら開発を進めます。

アジャイル開発の特徴は、機敏かつ柔軟にプロジェクトを進められるという点です。ソフトウェア開発でよく用いられるウォーターフォール型開発では、要件定義～設計～開発～テストと各フェーズが直線的に進むため、後工程での変更が難しいという特性があります。

一方で、イテレーション型で改善を繰り返すアジャイル開発では、計画や設計の段階で全てを決定するのではなく、プロジェクトの進行に伴って開発内容を調整できます。

アジャイル開発について詳しくは以下の記事でも解説しております。こちらの記事では具体的な事例を通してアジャイル開発の進め方について理解できますので、ぜひ本記事と併せてご覧ください。

https://spice-factory.co.jp/development/agile-development-case-studies/

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

それでは、アジャイル開発にはどのようなメリットがあるのでしょうか。以下では、5つの観点からアジャイル開発のメリットをご紹介します。

①変化に対する柔軟性

アジャイル開発のメリットのひとつは、変化に対する柔軟性です。

アジャイル開発では、イテレーションごとに小さな改善を繰り返し、最適なソフトウェアへと段階的に近づけていくアプローチをとります。よって、プロジェクト途中で新たな要件やニーズが発生しても、迅速に対応しやすいという特徴があります。

たとえば、競合他社が新機能を導入し、それがユーザーのニーズに合致している場合、自社のサービスにもその機能を追加したくなるはずです。もしくは、開発中のソフトウェアの機能に不満点が見つかった場合に、リリース前に改善をしたいと思うこともあります。

ウォーターフォール型開発では、同様の変更をする際に変更管理プロセスが必要となり、要件やスケジュールの見直しに時間がかかりオーバーヘッドも大きくなります。一方で、アジャイル開発であれば、比較的容易に仕様変更が可能です。

顧客の要求や市場の変化に素早く適応でき、最終的な成果物の品質を向上させることができる点は、アジャイル開発の大きなメリットといえるでしょう。

②早期フィードバックの実現

アジャイル開発では、各イテレーションにて最低限動作するソフトウェアを構築します。最小限の機能を持ったソフトウェアを実際のユーザーに利用してもらえれば、早期にソフトウェアに対する意見や満足度、ニーズの収集を行うことができます。

たとえば新規事業開発においては、市場調査やユーザー調査を行い、仮説を立てたうえでプロダクトを開発します。そのプロダクトが実際に市場やユーザーに適しているかどうかは、市場やユーザーの反応を見て確認することとなります。こうした「PMF（プロダクト・マーケット・フィット）」を評価するためにも、アジャイル開発で必要最小限の機能を備えたプロダクトを構築し、ローンチを目指すアプローチが有効です。

社内向けシステムであっても、早期フィードバックの重要性は変わりません。プロジェクトの終盤となって「思っていたシステムと違う」というのは、よくあるソフトウェア開発の失敗例です。

プロジェクトの初期段階で改善点を収集し、改善を行えば、コストや開発期間を抑えて利用者が必要とするソフトウェアを作り上げることができます。

③失敗リスクの軽減

「早期フィードバックの実現」というメリットは、失敗時のリスク軽減というメリットにもつながります。

早期フィードバックを実施した結果、開発中のソフトウェアに見込みがないと判断できれば、比較的開発コストがかからない段階で開発を終了させることもできます。もし、全ての機能を作りこんでユーザー反応を確認し、まったく評価を得られなかったとしたら悲惨です。

失敗時の開発費という出血を最小限に抑えられるのは、アジャイル開発のメリットといえます。

④チーム一体での開発

アジャイル開発の特徴として、チーム一体で開発を進めるという観点が挙げられます。プロジェクトメンバーは、誰も「お客さま」にならず、一丸となってプロジェクトを前に進めます。

ウォーターフォール型開発では、請負契約によって発注側と開発側が明確に分けられ、発注側は開発側のプロジェクトマネージャーのみを通してコミュニケーションすることとなります。このような体制は、場合により「発注側への丸投げ」や「受注側の無関心」という結果を生みかねないものです。

アジャイル開発では発注側と開発側は一つのチームとしてプロジェクトを運営します。この一体感は、問題が発生した際の迅速な解決にもつながります。チーム内のコミュニケーションが活発になることで、各メンバーの専門知識が最大限に活かされ、効率的な開発が可能になります。結果として、高品質なソフトウェアの開発につながります。

⑤チームメンバーのモチベーション向上

アジャイル開発の見逃せないメリットの一つとして、メンバーのモチベーション向上が挙げられます。

アジャイル開発では、チームメンバーが協力して目標を達成する文化を大切にします。各メンバーが自身の役割と責任を持ち、プロジェクトの進行状況を共有しながら進めることで、おのおのが主体的にプロジェクトに取り組むことができます。

このようなアジャイル開発の特性はメンバーの「やらされている感」を排除し、モチベーションアップにつながります。ソフトウェアを作り上げるのは人間です。モチベーションはソフトウェアの品質において非常に重要な観点といえるでしょう。

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

一方で、アジャイル開発にもデメリットが存在します。以下では、4つの観点からアジャイル開発のデメリットをご紹介します。

①「丸投げ」は不可能

ウォーターフォール型開発では、発注者は要件を決めるだけで、その後はベンダーに開発を任せることが可能です。

一方でアジャイル開発では、発注側と開発側は一体のチームとしてプロジェクトを進行するため、すべてを開発側に任せることはできません。発注側もプロジェクトに積極的に関与し、頻繁にチーム内でコミュニケーションを取る必要があります。これにはメリットがある一方で、発注側にとっては負担となります。アジャイル開発は、依頼側にも一定の負荷がかかる開発方法です。

ただし、システム開発は基本的には発注側が主体的にコントロールし、自身が求めるソフトウェアを開発するべきものです。そもそもウォーターフォール型開発においても「丸投げ」はすべきでないといえます。

発注側として積極的にプロジェクトに参加し、品質の高いソフトウェアを作り上げていくべきでしょう。

②開発スピードは早くならないことも

アジャイル開発は頻繁なフィードバックと継続的な改善を重視するため、一見するとスピードが速くなるように見えますが、実は必ずしもそうとは限りません。

事前に明確に要件が定まっていて変更の可能性が無い場合、要件定義から設計、開発、テストと流れるように開発を進めていくウォーターフォール型開発の方が素早く開発を行えるケースもあります。また、要件の変更が頻繁に発生する場合や、チームのコミュニケーションがうまくいかない場合、開発が遅れてしまうこともあるでしょう。

アジャイル開発はアジリティ（機敏さ）に優れた手法ですが、それは開発スピードの速さとは直結しません。ケース・バイ・ケースでうまく使い分けることが重要です。

③開発の方針がブレるリスク

柔軟性が高いというアジャイル開発のメリットは、方向性が定まりにくいというデメリットに化けるリスクがあります。プロジェクトのゴールが明確でない場合、チームが方向性を見失い、結果としてソフトウェアの品質低下や開発の遅延につながってしまいます。

一度開発した機能を何度も変更してしまえば、当然コストも開発期間も余分に発生します。「アジャイル開発だからと事前に要件を決めなくてよい」という考え方はせず、少なくともプロジェクトの開始時点では事前に開発すべきものを定めておくべきです。

アジャイル開発の柔軟性は、開発時点以降の市場・ニーズの変化に対応するために活用すべきでしょう。

④実行にはスキルが必要

アジャイル開発を成功させるためには、チームメンバー全員が高いスキルを持ち、自己管理できる能力が求められます。チーム内で円滑にコミュニケーションを行い、問題を解決していく能力も重要です。スキル不足や経験の浅いメンバーが多ければ、アジャイル開発のメリットを最大限に引き出すことは難しいといえます。

アジャイル開発に不慣れである場合、伴走型の支援を行う企業からサポートを受けるという方法もあります。取り組み当初は伴走支援を受けてアジャイルの考え方を組織内に取り込み、自律を目指していくというアプローチも有効です。

アジャイル開発の手法・種類

一口にアジャイル開発といっても、その手法はさまざまです。以下では、アジャイル開発の主な手法を簡単にご紹介します。

なお、各手法の詳細については以下の記事にて詳しく解説しております。併せてご覧いただけば幸いです。

https://spice-factory.co.jp/development/agile-development-type/

アジャイル開発が向いている条件を解説

具体的に、どのようなプロジェクトにおいてアジャイル開発を選択するべきなのでしょうか。以下では、アジャイル開発に向くプロジェクトの条件についてご紹介します。

変更可能性が高いプロジェクト

プロジェクトの要件が頻繁に変わる場合は、ウォーターフォール型開発での対応は難しくなります。

たとえば、製造業における業務改善活動においては、実際に開発したソフトウェアを製造現場に適用し、その効果を図っていく取り組みが必要です。このような取り組みをウォーターフォール型開発で実施すると、高いコストがかかります。
開発内容を柔軟に変更したいプロジェクトにおいては、アジャイル開発の採用が有効です。

ユーザーニーズを重要視するプロジェクト

ユーザーのフィードバックを頻繁に取り入れながら開発を進められるアジャイル開発は、成功のためにユーザーの意見が重要となるプロダクトの開発に適しています。

社内向けシステムにおいてはスプリントレビューなどを通して、社外向けシステムにおいては想定ペルソナのユーザーインタビューなどを通して、ユーザーからの直接的なフィードバックを収集できます。

ユーザー満足度の高いソフトウェアを素早く開発したい場合には、アジャイル開発の採用を検討すべきです。

新規事業開発プロジェクト

新規事業は一般的に不確実性が高く、市場のニーズや技術の変化に迅速に対応する必要があります。アジャイル開発の短いサイクルで頻繁にフィードバックを行えるという特性により、新規事業のアイデアを迅速に検証しつつ、必要に応じて柔軟な方向転換を実現できるようにします。ケースにもよりますが、新規事業開発においてはまずアジャイル開発を最初の選択肢と考えてもよいでしょう。

アジャイル開発の導入事例

アジャイル開発、スクラム開発支援を推進している当社の事例を3つご紹介いたします。

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

東京都は、デジタル技術を活用した行政の総合的な推進を図り、都政における QOS（クオリティ・オブ・サービス）の向上を目指し、2021年にデジタルサービス局を設立しました。同局では、国際的な競争力の向上や、都民生活の質や利便性を高めるため、新しい価値を迅速かつ柔軟に生み出すアジャイル開発手法を採用しています。

当社では、同局が手掛ける4件のアジャイル型プロトタイプ開発プロジェクトを受託しました。

https://spice-factory.co.jp/works/14765/

株式会社ネクスウェイ | 薬局向けDI (薬剤情報) ポータルサービス「アスヤク薬局ポータル」の開発

株式会社ネクスウェイ様が提供する薬局向けDI（薬剤情報）ポータルサービス「アスヤク薬局ポータル」の新規開発を担当いたしました。

このポータルは、分散して提供されていたDI（薬剤情報）を一元化し、効率的に閲覧・管理できるサービスです。これまでメールや郵送、FAX、Webなどで個別に発信されていた情報を一箇所に集約し、製薬会社によるDI配信機能等を有しています。

https://spice-factory.co.jp/works/14733/

株式会社トムス・エンタテインメント｜ProGrace開発によるアニメーション制作DX

株式会社トムス・エンタテインメントは、日本のアニメーション制作業界が直面する制作、ビジネス、そして人材育成におけるさまざまな課題を踏まえ、「アニメSDGs -2030年までに持続可能な日本アニメ産業の未来を築く-」というビジョンを掲げています。当社は、アニメ業界のデジタル変革（DX）を支援する取り組みの一環として、「ProGrace（プログレース）」の開発を継続的にサポートしています。

以下の記事では、同社のプロジェクト担当者様に、プロジェクトの背景や今後の展望について詳しくお話をお伺いしました。

https://spice-factory.co.jp/works/17700/

アジャイル開発はスキル・経験が求められる

この記事では、アジャイル開発のメリット・デメリットについて詳しくご紹介しました。
さまざまなメリットがあるアジャイル開発ですが、「丸投げはできない」「開発方針がブレるリスクがある」「一定のスキルが求められる」といった側面もあります。しかしながら、これらのデメリットは優れたスキルを持ったメンバーが一体となってプロジェクトを運営すれば解決できるものでもあります。

よって、アジャイル開発を行う際には、アジャイル開発のスキルや経験を保有したパートナーを選ぶことが重要です。当社では、これまで多くのアジャイル開発プロジェクトを実施してきました。その経験を活かし、プロジェクトの特性や目標に合わせたアプローチでお客さまのソフトウェア開発を支援いたします。アジャイル開発にご興味のある方は、ぜひお気軽にお問い合わせください。

近年、「アジャイル開発」や「デザイン思考」というキーワードを耳にすることが多くなったのではないでしょうか？
特に、DX推進や新規事業を担当されている方にとっては、あらゆる場面で聞かれている言葉だと思います。

一方で、アジャイル開発やデザイン思考の具体的な活用方法を理解することは難しいといえます。
これらのキーワードがなぜ注目されているのか、どのようなメリットがあるのか、どのように取り入れるべきかなどを正確に把握している方は意外と少ないのが実情です。

そこでこの記事では、アジャイル開発やデザイン思考が注目される背景、メリットなどの基本的な内容に加え、アジャイル開発とデザイン思考の掛け合わせがなぜ新規事業開発に有効であるのか、さらにアジャイル開発とデザイン思考を活用した新規事業開発のイメージまでご紹介します。

また、弊社スパイスファクトリーではアジャイル開発において豊富な実績があります。

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

アジャイル開発とは？

まず、アジャイル開発とはどのようなものか、その概要を解説します。

アジャイル開発の概要

アジャイル開発とは、プロダクト開発の進め方の一つです。「アジャイル(agile) = 機敏な」という意味であることからも分かるように、小さい開発期間を繰り返すことで迅速かつ機敏にシステムの開発を進めるのがアジャイル開発の特徴です。

具体的には、開発するシステム全体を2週間や1か月などで開発できる範囲に区分した上で、優先度が高いものから順に開発を行います。
アジャイル開発では、開発単位ごとに実際に動作するシステムを作りあげます。これにより、クライアントは実物を確認でき、システムに対する要望をブラッシュアップできます。次の開発単位では、ブラッシュアップされた要望をもとに、よりニーズに合ったシステムを作り上げていくのです。

不確実性が高まる現代においては、時間をかけて一回で完璧な成果物を作り上げることは難しいといえます。変化する状況に柔軟に対応できるアジャイル開発は、現代的なシステム開発手法といえるでしょう。
アジャイル開発については以下の記事も参考になりますのでご覧ください。

https://spice-factory.co.jp/development/agile-software-development/

アジャイル開発とウォーターフォール開発の比較

アジャイル開発の比較対象とされやすいのが、ウォーターフォール型の開発です。ウォーターフォール型開発とは、要件定義から設計・実装・テストという流れをまるで川の流れのように実施していく開発手法のことです。
ウォーターフォール開発では、アジャイルのようにサイクルを回して前のフェーズに戻るということはなく、原則として要件定義で決めた内容の通り開発します。プロダクトがすべて完成してリリースするまでには、数か月から数年という時間がかかり、システム全体が完成しないと実際に動いているシステムを確認することはできません。

このような特徴から、ウォーターフォール開発は要件が明確化できるシステムには向いているものの、柔軟な変更を行いたい場合には不向きとされています。ウォーターフォール開発と比較して、アジャイル開発は「変化に対する柔軟性」や「早い段階で実際のシステムで検証できる」といったメリットがあるといえるでしょう。

ただし、ウォーターフォール開発は「大規模開発に強い」「開発前に予算をある程度明確化できる」といったメリットもあり、現在でも広く利用されています。一概にどちらの手法が有効とは言えず、用途に応じて両者をうまく使い分けることが最も重要です。
詳しくはこちらの記事をご覧ください。

https://spice-factory.co.jp/development/new-business-agile-development/

デザイン思考とは？

続いて、デザイン思考についても概要をご紹介します。

デザイン思考の概要

デザイン思考とは、ユーザーの行動を観察することでユーザーニーズを深掘りつつ、その解決策を導き出す思考法のことです。
デザイン思考は、アメリカのデザインコンサルティングファームである IDEO社のノウハウから発展して生まれたと言われています。IDEOの CEO である Tim Brown氏によると「デザイン思考とは、デザイナーの感性と手法を用いつつ、人々のニーズと技術の力で顧客価値と市場機会の創出を図ること」とされています。

デザイン思考を用いることで、市場調査や分析などマーケティングでは拾いきれないようなニーズをくみ取ることができます。予測不可能な要素が多い現代においては、アジャイル開発と同様にデザイン思考を用いて、多角的にニーズを探ることが重要といえるでしょう。

デザイン思考のプロセス

デザイン思考には複数の手法が存在しますが、ここでは IDEOの手法である「①共感」→「②問題定義」→「③創造」→「④プロトタイピング」→「⑤テスト」という5つのプロセスに沿って、その内容を紹介します。

①共感

デザイン思考はユーザーに共感することから始まります。インタビュー、アンケート、行動観察などの手法を用いて「ユーザーが何を考えてどのように行動するのか」を深堀します。
このフェーズでの実施内容として以下記事が参考になります。

https://spice-factory.co.jp/design/usability-test/

②問題定義

共感で得られた情報を元に、ユーザーのニーズや課題を定義します。ユーザー自身も気づいていないニーズを分析することがポイントです。

③創造

ユーザーのニーズを満たすためのアイデアやアプローチを検討します。質よりも量を意識し、可能な限りアイデアを広げていきます。

④プロトタイピング

アイデアを元に、製品やサービスのプロトタイプを作ります。時間やコストをできるだけかけずにアイデアを形にして、早期にテストできるようにします。
プロトタイピングに関しての詳細は以下の記事が参考になります。

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

⑤テスト

プロトタイプをユーザーに触ってもらい、フィードバックをもらいます。フィードバックを踏まえてアイデアやプロトタイプを改善していきます。
プロトタイピング→テストというサイクルを繰り返すことで、ユーザーのニーズを満たす製品・サービスにつなげることができます。

アジャイル開発・デザイン思考が新規事業開発に必要とされる理由

ここまで、アジャイル開発とデザイン思考の概要についてご紹介しました。それでは、なぜこれらの手法が新規事業開発に必要とされているのでしょうか？

結論から申し上げると、アジャイル開発とデザイン思考との掛け合わせが、PDCAサイクルを素早く回し、より良いサービス開発に貢献することがその理由です。

現代的な新規事業開発においては「トライ＆エラー」が重要視されています。一度に大規模な投資を行うのではなく、PoC（Proof of Concept：概念実証）（新しいタブで開きます）などを通して事業の成功可否を段階的に判断していくのが一般的です。このような進め方をする際に向いているのが「継続的な改善」を前提とするアジャイル開発とデザイン思考なのです。

アジャイル開発とデザイン思考は、もちろん単体で活用しても有効な手法ですが、両者を組み合わせることで価値を高めることができます。「継続的な改善」を前提とするアジャイル開発とデザイン思考を組み合わせることで「ユーザーの声を元に解決策を考える」→「素早く形にする」→「検証する」というサイクルを実現しやすくなります。

デザイン思考では、前述した「①共感」「②問題提起」「③想像」のフェーズを踏まえ、「④プロトタイピング」と「⑤テスト」のサイクルを通してユーザーのニーズを探っていきます。一方で、アジャイル開発は、従前の通り「最低限動くものを作り」「継続的かつ柔軟に発展させていく」開発手法です。

デザイン思考で言うところのプロトタイプをアジャイル開発で実装することで、実際に動くものをスピーディーに作り上げつつ、テストを通して得た気付きをプロトタイプに反映させやすくなるのです。

【実践例】アジャイル開発とデザイン思考を活用した新規事業開発のイメージ

それでは、アジャイル開発とデザイン思考を組み合わせた新規事業開発とは具体的にどのようなものなのでしょうか？ここでは「IT専門求人ポータルの立ち上げ」という仮想事例をもとにご紹介します。

デザイン思考によるアイデアの具現化

まず、アイデアの具現化に有効であるデザイン思考を活用します。

「IT専門求人ポータルの立ち上げ」という事業テーマにおいて、「①共感」のフェーズにて観察対象とするべきメインターゲットが「IT業界で働く、20代～30代の方」となったとすると、これらの方を対象とするインタビューなどを実施しどのような課題やニーズを持っているのか確認します。

続いて「②問題提起」「③創造」のフェーズにて、ターゲットが持っている課題とその解決策を具現化します。たとえば、ターゲットは「ITの求人は多数あるものの、実際に勤務してみると思っていたような職場ではなかったことが多い」「求人に応募する前に仕事にフィットできるか分かればいいのに」という想いを持っていたとすると、この課題の解決策として「口コミ情報を活用した AI による合致性の高いマッチングサービスを提供する」といったことを企画に落とすこともできるでしょう。

このように、デザイン思考を用いることは、新規事業開発における差別化要素を定義することにつながります。

アジャイル開発によるプロトタイプ構築

一方で「口コミ情報を活用した AI による合致性の高いマッチングサービス」が実現可能なものであるかはその時点では分かりません。
そこで、アイデアの実現性を測るために有効なのがアジャイル開発によるプロトタイプ構築です。

アジャイル開発を活用して、ビジネスのコアとなるポイントに機能を限定して「④プロトタイピング」を構築します。このケースでは、ビジネスのコアは「口コミ情報から AI により十分精度の高いマッチングができるか」です。求人応募機能や検索機能など、IT専門求人ポータルを実現する上で必要な機能は様々ありますが、それらは現段階では不要となります。

アジャイル開発にて、最小限必要となる機能をスピーディに作り上げ、事業の実現性を早期にチェックします。

デザイン思考とアジャイル開発による改善

プロトタイプが完成したとして、それが新規事業として投資するに値するかどうかは、結局のところユーザーから支持されるかどうかとなります。よって、次に重要なのが「デザイン思考とアジャイル開発による改善」です。

デザイン思考のプロセスにのっとり、完成したプロトタイプを実際に「⑤テスト」します。想定されるユーザーに実際にプロトタイプを使ってもらうことで、様々な意見を収集できます。たとえば「このようなマッチング提案ではあまり参考にならない」「事業内容など以外にも、休暇の取得可否や残業時間なども重要な要素」など意見が出ることもあるでしょう。

これらの要素を踏まえ、アジャイル開発により機能を改善していきます。アジャイル開発はシステムの修正に強いという特徴があるため、機能変更も比較的容易です。改善したら、再びユーザーに利用してもらい、本当にユーザーの満足度が向上しているかを確認します。
このようなサイクルを回していき、十分にビジネスとして成立するレベルまで達したと判断できれば、いよいよ本格的にサービスリリースに向けて動き出していきます。

アジャイル開発×デザイン思考を適切に取り入れ、新規事業開発を成功へ

この記事では、アジャイル開発やデザイン思考の概要とともに、アジャイル開発とデザイン思考がなぜ新規事業開発に有効であるのかについて紹介しました。

アジャイル開発やデザイン思考を活用したプロジェクトを進める際には、密なコミュニケーションが鍵となります。そのため、社内の意思決定者を含んだメンバーと、委託先のデザイナー・エンジニアが小まめにコミュニケーションを取れる体制・環境が必要です。

当社では、アジャイル開発やデザイン思考の豊富な知見をベースとして、密なコミュニケーションを行いながらお客さまのビジネスを具現化していくことを強みとしています。
新規事業開発に関してお悩みやご質問がある方は、ぜひお気軽にご相談ください。

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

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

当社は【2025年最新版】アジャイル開発おすすめ企業4選（新しいタブで開きます）に掲載されています。

企業が新たなサービスを検討、もしくは既存サービスの改善・リニューアルを検討する際、「PoC（概念検証）」を行うことが重要です。

どれだけ良い企画であっても、実現できるか分からなければ新規事業を進めるべきか判断できません。事業投資を行う価値があるのか、その検討材料としてPoCを実施しましょう。

本記事でPoC の進め方や実際の検証方法についてご説明します。弊社スパイスファクトリーではPoCにおいて豊富な事例、実績があります。弊社の概要やサービスプラン、過去の導入実績などをまとめた資料をご用意しました。

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

PoCとは

PoCとは「Proof of Concept」の略で、概念実証のことを指します。これはビジネスアイデアや技術の実証を目的とした試作開発や検証のプロセスです。

このプロセスを通じて、ビジネスアイデアの実現可能性や成果の効果を評価することが可能です。

Webサービス開発においてよく見られる失敗例の一つに、多大なコストや時間をかけたにもかかわらず、実際のユーザーニーズや市場の要求と合致せず、結果を出せなかったケースがあります。PoCを実施することで、仮説が正しいかどうか、技術的に実現可能かをプロトタイプを使用して開発・検証し、低コストかつ低リスクでビジネスアイデアの検証を行うことができます。

PoCの基本については以下の記事をご参照ください。

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

PoCの進め方

PoCでは、理論だけでなく実際にプロトタイプを開発して検証するのも PoC の特徴です。それでは、PoC は具体的にどのように進めるのでしょうか。

PoC の進め方は以下の流れが一般的です。

1. ユーザーリサーチ
2. コアバリュー策定
3. プロトタイプ作成
4. プロトタイプ検証
5. 投資判断
6. 本番開発連携

詳細は以下の記事にて解説していますので参考にしてみてください。

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

どのようなプロトタイプを作成するかは「何を検証するか」で決まる

一般的に、PoC はプロトタイプ（新しいタブで開きます）を基にして、そのサービスや製品に実現性や有益性があるのかを検証していきます。

プロトタイプには複数の種類がありますが、どのようなプロトタイプを作成するかは「何を検証するか」を踏まえて決定します。

仮説立てた事業のアイディアがユーザーに価値やベネフィットをもたらすかを検証することが目的であれば、ユーザーシナリオやペーパープロトタイプなど、アイディアのイメージを伝えるための成果物を低コストに作成します。
技術的な実現可能性やユーザーにとっての使い勝手の良し悪しを検証することが目的であれば、プロトタイピングツールで作成する解像度の高いプロトタイプや、簡易的にコーディングされたプロトタイプを用いて検証を行います。

PoC で検証すべきポイントは、業界やプロジェクトによって異なりますが、大枠としては以下の3つの項目を検証することが多くなるでしょう。

• サービスに価値はあるか
• 技術的に実現可能か
• ユーザーに満足してもらえるか

また、実際に PoC を進めるうえでは、明確なKPIを設定します。その結果によって仮説が実証されるのかを確かめ、事業投資を行うかを決定することができます。
次項では、具体的にどのようなKPIを設定すべきかについてお伝えしていきます。

PoCにおいて設定すべきKPI

PoCで設定するKPIには大きく行動KPIと態度KPIの2種類があります。

行動KPI

行動KPI とは、サービス上でのユーザーの行動を数値で表したものです。目標を達成するための行動と結果の結びつきが大事であるため、ロジックを明確にして目標に落とし込む必要があります。

行動KPIを設定する際には、以下のポイントを考慮することが重要です。

• 具体性：KPIは具体的で測定可能なものである必要があります。抽象的な指標では評価が困難です。
• 関連性：設定するKPIは、PoCの目的や目標と直接関連するものであるべきです。
• 現実性：過度に高い目標を設定すると評価が偏ってしまうため、設定するKPIは達成可能なものでなければなりません。

具体例として、以下のような数値が考えられます。

• 利用率
• タスクの成功率
• タスクの処理時間
• コンバージョン率
• エラー率

会社の投資としての事業や業務改善のためのシステム導入など、PoCの目標はさまざまですが、それを実行するかしないかは、KPIの結果である程度判断できるでしょう。

態度KPI

態度KPI とは、検証するユーザーがサービスを利用する前、利用中、利用後にどのように感じているのかを数値で測定するものです。

サービスを使用して、使いづらさや不便さを感じれば、事業投資を行う前にプロトタイプの改善が必要と判断されるでしょう。逆にそのサービスを利用することで、効率アップや業績アップにつながるなら、そのサービスはユーザーに価値を与えると考えられます。

態度KPIも、行動KPIと同じく結果として測定できるものを設定することに加え、以下のポイントを考慮することが重要です。

• 顧客視点：顧客が何を重要視しているかを理解し、その視点に基づいて指標を設定します。
• 継続的な収集：定期的にフィードバックやデータを収集し、長期的な改善策を講じます。
• 多様なデータソース：アンケート調査だけでなく、インタビューやオンラインレビューなど、様々な方法でデータを収集します。

具体的な指標として、態度KPIには以下のようなものがあります。

• 顧客満足度（CSAT）・・・5段階評価や10段階評価を用いて顧客満足度を測定
• システムユーザビリティスケール（SUS）・・・製品やサービスに対する使いやすさ
• ユーザーエンゲージメント・・・製品やサービスに対する関心度
• ネットプロモータースコア（NPS）・・・顧客が製品やサービスを他人に薦める可能性
• リピート率・・・再度製品やサービスを利用する割合

会社が事業を持続するには、ユーザーの利便性アップや満足度をあげるサービスが必要です。その指標として、態度KPI の検証結果は一つの判断軸となるでしょう。

上記の行動KPI、態度KPI のどちらか片方を取り入れるのではなく、両方を組み合わせることで有効な測定が可能となります。

PoCでの検証方法

検証項目によって PoC の検証方法は異なります。

たとえば、システムなど技術的に実現可能かどうかを検証するには、実装のための技術仕様やシステム上の制限などを事前に確認する必要があります。エンジニアの技術レベルは十分であっても、実現するための設備がないといったケースも考えられます。

対して、システム設計には問題がなく、ユーザーのニーズや体験結果を検証する段階であれば、その業界や市場での必要性を見極めなければいけません。

以下それぞれのパターンで詳しく説明します。

技術的な実現可能性を検証する場合

検証したいサービスがシステムやソフトの開発など、技術的に実現可能かどうかを検証する場合は、エンジニアの協力が必須です。「こういうシステムが欲しい」というアイデアを出せても、エンジニアでなければどこまで実装可能か判断できません。

プロトタイプの作成段階から、実装を担当するエンジニアに協力してもらい、実現可能なシステム設計を進めていきましょう。プロトタイプ段階でエンジニアによるレビューが入ることで、本開発に進んだ際の手戻りを防ぐことができます。実現性やコスト面を見ながら費用対効果を検証することも重要です。

ユーザーニーズやユーザー体験を検証する場合

ユーザーニーズやユーザー体験の検証では、UXデザイナーによるユーザビリティテストやKPI計測が有効です。実際に、PoC で検証したいサービスやプロダクトの実ユーザーにプロトタイプを操作してもらいましょう。

このときに、ユーザビリティテストといった定性的な手法と、KPI測定といった定量的な手法を組み合わせると説得力のある検証ができます。

では、定性的な手法と定量的な手法とは具体的にどのようなことを指すのでしょうか。
以下で解説します。

定性的な手法

定性的とは、数値では表現できない性質のことです。たとえば、個人の感想などは、数値では表すことができません。しかし、システムやサービス開発においては、そういった定性的な情報が重要です。

定性的な手法のひとつに、「ユーザビリティテスト」があります。これは、実際の Webサイトやシステムのプロトタイプをユーザーに利用してもらい、その使用感のフィードバックを受けることです。

ユーザーの感想や操作の意図を深掘りすることで、サービスの価値や利益性に関する仮説が合っているかを確認できます。

また、想定していなかった課題を発見する場合もあり、さらなる仮説検証につながることも考えられます。ユーザビリティテストを繰り返し行い改善することで、ユーザーにとって利便性の高いサービスを提供できるようになります。

ユーザビリティテストの詳細については、以下の記事でも説明しています。

https://spice-factory.co.jp/design/usability-test/

定量的な手法

定量的な手法では、測定可能なKPIを用いて、実際にユーザーにプロトタイプを操作してもらうことで計測します。

たとえば、特定のタスクを実施してもらい、タスク完了までにかかる時間や完了率を計測します。ユーザーが実際に使用した結果がわかるので、事実の検証と改善につなげられます。

また、新しいビジネスやサービスではなく、既存プロダクトをリニューアルする際に PoC による検証を行うケースもあるでしょう。
その場合は、プロトタイプに対する計測と同様に、既存プロダクトに対しても同様の値を測定しておきます。そうすることで、リニューアル前後でKPIの値がどれだけ変化したかの比較が可能です。

検証後の流れ

検証結果次第で、製品やサービスの方向性が正しいと判断することもあれば、新たな課題が見つかり大きく軌道修正する場合もあります。

検証結果を踏まえて、次のステップを決めましょう。

• 本開発に進む
• 見つかった課題を改善し、再度検証を行う

たとえ課題が見つかったとしても、改善・検証を繰り返すことで、精度を高めた状態で本開発につなげられるでしょう。新たな機能を実装し、さらに大きなビジネスに発展する可能性もあります。

本開発の前であれば、ローンチ時期を変更したり新たな機能を実装したりといった対応も可能です。

本開発後のシステム追加やメンテナンスは、製品やサービスの稼働をとめて行う必要があるためユーザーへの影響を避けられません。事前に PoC で検証することで、本開発前に製品やサービスの完成度をより高められます。

当社のPoCプロジェクト事例

スパイスファクトリーでご支援させていただいたPoCのプロジェクト事例をご紹介します。

株式会社NTTデータ関西様_UI/UX改善の価値が伝わるプロトタイプ開発

株式会社NTTデータ関西様では、電子申請や各種予約サービスなどの国・地方公共団体向けの機能を備えるクラウドサービス「行政総合サービスモールe-TUMO」を開発・提供しています。

当社では「e-TUMO」シリーズの一つである、個人番号カード交付予約・管理サービス「e-TUMO MYNUM」のUI/UX改善支援の一環としてプロトタイプ開発を実施しました。

https://spice-factory.co.jp/works/13083/

本田技研工業株式会社様_解像度の高いプロトタイプによりユーザーの声を具体化

大手輸送機器メーカーの本田技研工業様のPoC支援を実施しました。

新規事業の構想段階における、市場ニーズの把握を目的としたプロジェクトであり、プロトタイプ開発とリサーチまでトータル2ヵ月で進行しました。

https://spice-factory.co.jp/works/9319/

検証精度を高める解像度の高いプロトタイプ

PoC の検証項目とは何か、その目的や手法についてお伝えしてきました。少しでも、あなたのビジネスのお役に立てましたら幸いです。

スパイスファクトリーが行ったPoC支援では、クライアント企業様との事前打ち合わせで詳細をすり合わせたため、解像度の高いプロトタイプを開発できました。その結果、フィードバックはより具体的になり、検証の精度は大きく向上しました。

スパイスファクトリーでは PoC の実施から、検証完了後の本開発まで支援しております。

新規サービスの開発やニーズ検証にお悩みがある方は、是非一度お気軽にお問い合わせください。

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

PoCとは概念実証のことを指します。新しいアイデアや技術、ビジネスモデルが技術的に実現可能か、また、市場やユーザーに受け入れられそうかを最小限のコストと期間で検証するプロセスです。

PoCで何を実現したいのかの目的を明確にし、その目的を達成するための正しいステップを踏むことが重要になってきます。

この記事では、PoCの概念からメリットや工程、成功のポイントまでをご紹介していきます。

弊社スパイスファクトリーではPoC活用において豊富な実績があります。弊社の概要やサービスプラン、過去の導入実績などをまとめた資料をご用意しました。気になる方はこちらからダウンロードしてください。

PoCとは

PoCとは「Proof of Concept」の略で、概念実証のことです。ビジネスアイデアなどの実証を目的とした、試作開発や検証のことを指します。
この検証により、ビジネスアイデアの実現可能性や成果効果を測ることができます。

Webサービス開発の失敗例として挙げられるのが、多くのコストや時間をかけたにも関わらず、ユーザーニーズや機能が実際のニーズと異なり、結果につながらなかったというケースです。PoC を行うことで、想定している仮説が正しいか・技術的に実現可能かを実際にプロトタイプを用いて開発・検証することができ、低コスト低リスクなビジネス検証を行えます。

PoCとプロトタイプ・MVP・実証実験の違い

PoCは、基本的な概念やアイデアが技術的に実現可能であるかどうかを初期段階で確認するために行われます。例えば、新しいアルゴリズムが理論的に機能するか、特定の技術が予定されたパフォーマンスを発揮できるかを検証します。これは主に小規模で短期間の実験です。

PoCとよく混在する用語としてプロトタイプ、MVP、実証実験があります。
PoCとそれぞれの用語の違いについて見ていきましょう。

PoCとプロトタイプの違い

PoCとプロトタイプは、どちらも新しいアイデアや技術の検証手段ですが、その目的とアプローチは異なります。

プロトタイプでは、実際の製品の初期バージョンを作成し、ユーザーからのフィードバックを収集することで、製品の改良に役立てることを目的としています。例えば、新しいアプリケーションのプロトタイプを作成し、ユーザーに実際に使ってもらうことで、使いやすさや機能性についての意見を収集します。

PoCでは特定の機能や技術の確認に焦点を当てますが、プロトタイプはユーザー視点で製品全体に対する評価を行うためのものです。

PoCとMVPの違い

MVP（Minimum Viable Product）は、製品やサービスの最小限の機能を持つバージョンを指し、実際の市場でのフィードバックを得るために使用されます。PoCが技術的な可能性を確認することに焦点を当てているのに対し、MVPは顧客からの反応を基に製品の改良を進めることを目的としています。

MVPは、製品のコア機能を迅速に市場に投入し、顧客のニーズや反応を早期に確認することで、開発の方向性を決定します。例えば、新しいソフトウェアアプリケーションのMVPをリリースし、ユーザーからのフィードバックを基に改良を加え、最終的な製品を完成させます。

PoCは技術的な実現可能性を確認するためのもの、MVPは最小限の機能で市場に投入しユーザーフィードバックを得るためのものとなります。

PoCと実証実験の違い

実証実験は、PoCで得られた結果を基に、実際の運用環境で技術やアイデアがどのように機能するかを検証します。

実証実験は、技術の実用性や効果を具体的な条件下で確認し、さらに改良や適応の必要があるかどうかを評価します。例えば、新しいシステムが既存のインフラに統合できるか、ユーザーにとって使いやすいかを確認するために実施されます。

実証実験は、通常実際の運用に近い環境実施されるためPoCよりも大規模で時間を要するものです。

以上をまとめると、各用語における目的は以下のようになります。

• PoC：簡易的な実証モデルにより特定の技術やアイデアの実現性を確認
• プロトタイプ：初期モデルを作成し、操作性や機能のフィードバックを得る
• MVP：最小限の機能を持った製品を市場に投入し、ユーザーフィードバックを収集する
• 実証実験：実際の運用環境で試験を行い、最終的な調整を行う

PoC を行うことのメリット

PoC のメリットをご紹介します。

新規ビジネスのリスク管理ができる

一つ目のメリットは、リスクを管理することができることです。
ただし、押さえるリスクは PoC の目的によって異なります。

たとえば、「ユーザビリティを向上させる」ことを目的とする PoC では、本番に近しい UI を持ったプロトタイプを利用することが適切であるため、「ここはユーザーにとって分かりづらく、リリース後に細かな修正が発生する可能性がある」、「ここは仕様が重いため実装遅延するリスクがある」のような予測ができます。そのため、いつどのような問題が起こるかを予測することが可能となり、プロジェクト進行後に迅速に対応することができます。

また、正式な事業化判断の前に市場ニーズを測ることが PoC の目的である場合、「本開発してみたが、いざリリースしてみたらニーズがなく採算が合わなかった」のようなリスクを予測することができます。ここでは、PoC の目的から逆算し、具体的な機能要件まで踏み込まないプロトタイプを利用することが多いです。そのため、具体的な機能についての問題を予測するのではなく、あくまでも事業化に対するリスクを測ることになります。

このように、自社の PoC の目的を明確にし、事前に検証項目を握ることが重要です。

投資効果を最大化できる

PoC を行うことで、どういった施策に対してどのくらいの効果が得られるかの予想が立てられます。成功率の高いものに対してコストを投入できるため、投資効果も最大化されるのです。
また、効果を予測することで、社内検討を行う際にも周囲からの賛同・信頼が得やすくなります。

プロジェクト開始後にスピード感をもって取り組める

PoC によって、プロジェクト開始前に必要な技術や参入方法など、最適なアプローチ方法がある程度把握できます。そのため、プロジェクトを開始した後も、設計や実装に多くの時間を割くことなく進められます。

このように、PoC を行うことで、作業時間を無駄にすることなく必要な施策により多くの時間を割けるようになるのです。

投資家から評価が得られる

PoCを成功させることで、投資家からの評価を得ることができます。
初期段階で市場に投入し、ユーザーの反応を得ている製品は、投資家にとって信頼性が高く、投資リスクが低いと判断されやすいです。これにより、追加の資金調達が容易になり、製品開発の次のステップに進むための資金を確保しやすくなります。

特に新興企業や新規事業において、投資家からの信頼を得ることは資金調達の鍵となります。PoCは、投資家に対して技術やビジネスモデルの実現可能性を証明する手段として非常に有効です。例えば、新しいIoTデバイスの開発においてPoCを実施し、その成功を投資家に示すことで、追加の資金調達がスムーズに進みます。

PoCを行うことのデメリット・注意点

PoCを行うことには以下のようなデメリットがあります。

検証の回数によってはコストが増える

PoCは、その性質上、複数回の検証を行うことが多く、その結果としてコストが増加する可能性があります。特に、比較的規模の大きいPoCや複雑な技術を伴う場合、検証に必要なコストや時間が大幅に増えることがあります。

コストの増加は、PoCの大きな課題の一つです。特に資金が限られているプロジェクトでは、検証の度にコストが増えることは避けたいところです。例えば、新しいソフトウェアのPoCを複数回実施する場合、その都度開発費用や人件費がかさむことがあります。このため、PoCの実施計画を緻密に立て、必要最小限のリソースで最大の成果を得る工夫が求められます。

情報漏洩のリスク

PoCの過程で、企業の機密情報や新しい技術に関する情報が外部に漏れるリスクがあります。情報漏洩を防ぐためには、適切なセキュリティ対策と契約管理が必要です。

情報漏洩のリスクは、特に技術革新を進める企業にとって重大な懸念事項です。PoCの過程で外部と協力する場合、セキュリティ対策が不十分だと機密情報が漏れる可能性があります。
そのような自体を防ぐために、厳格な情報管理体制と契約書の整備が不可欠です。

PoCプロジェクトの流れ

それでは実際のPoCプロジェクトの流れを順番にご説明します。

1. ユーザーリサーチ
2. コアバリュー策定
3. プロトタイピング検証
4. システム開発連携

ユーザーリサーチ

PoCプロジェクト初期にターゲットユーザーの解像度を上げるための調査を実施します。
たとえば、「ターゲットユーザーはどのような人か」「ユーザーはどのような課題を抱えているか」といったことです。

これにより、想定しているサービスの提供価値や機能が、ユーザーにとって本当にニーズのあるものなのか早い段階で確かめることができます。

コアバリュー策定

次に、「ユーザーリサーチの結果から得られたユーザーニーズ」と「クライアント企業の強みやアセット・提供できる価値」を掛け合わせ、サービスのコアバリューと最適な UX（ユーザーエクスペリエンス）を検討します。

調査結果をプロトタイピングへとつなげるフェーズをしっかり行うことで、検証時の判断軸を明確にするだけでなく、必要な機能に優先順位を付けて取り組むことができます。

プロトタイピング検証

サービスのコアバリューと UX の策定終了後は、プロトタイピング検証を行います。
プロトタイピングについては以下の記事もご参照ください。
参考：システム開発におけるプロトタイプ・モデルのメリットと注意点（新しいタブで開きます）

プロトタイピングとは

プロトタイピングとは、初期に作った試作モデル（デザインの作りこみや画面遷移などが設定されているデモ環境）に、ユーザーの要求や評価などを反映させ、軌道修正を行いながら本番のシステムを完成させていく開発手法です。

ユーザーリサーチとコアバリューで立てた仮説に対し「ユーザーニーズを満たすにはどのような機能が必要か」「どのような UI がユーザー体験を高めるのか」「立てた仮説は正しいか」をプロトタイプ作成と検証を繰り返しながら明らかにしていきます。

プロトタイプを作る目的

プロトタイプ作成は、主に以下の5つを検証することを目的に行われます。

• ユーザーニーズを満たすにはどのような機能が必要か
• どのような UI がユーザー体験を高めるのか
• 立てた仮説は本当に価値・ベネフィットをもたらすものか
• 技術的に実現可能か
• 仕様が適切か

プロトタイプ作成と検証を繰り返すことで、短期間・低コストで上記に対する検証を進めていきます。

プロトタイプのメリット

プロトタイプ作成で、より効率的なクオリティの高いサービス制作が可能になります。

プロトタイプを作成することで、試作モデルをユーザー目線で実際に使用してみることができます。完成してからユーザービリティテストを行うのではなく、プロトタイプの段階で機能やサービス価値を検証することで、より効率的に開発を進めることができます。

また、試作モデルがあることで、より具体的なサービス形態を見て案出しを行うことができます。文字や口頭からの説明だけでサービスをイメージするよりも、より具体的で良いアイデアを出せるようになるかもしれません。

具体的な PoC の検証方法については、こちらの記事で記載しております。

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

システム開発連携

プロトタイピング検証が終わると、いよいよシステム開発連携を行います。

スパイスファクトリーでは、デザイナーが開発チームに参加し、エンジニアとデザイナーが共同で案件を進行する開発案件が多くあります。PoC でも、検証が終わった時点でデザイナーはエンジニアと連携し、共に開発手順等を決めていきます。

PoCを成功させるためのポイント

PoCを成功させるためには、いくつかのポイントがあります。

ポイント① 明確な目的と範囲を設定する

PoCを成功させるためには、まず明確な目的と範囲を設定することが重要です。

PoCでは小規模なパイロットテストを実施します。小規模なテストにより柔軟且つ迅速な検証が可能となり、問題点の特定や改善策の検討がしやすくなります。また、小さい検証結果に基づいてプロジェクトのスケールアップを行うかどうかを判断でき、リスクを最小限に抑えることができるほか、より確実な進展につながります。

PoCの範囲が広すぎて目的があいまいになると、最終的に何を検証するために実施したかが分からなくなり、リソースの無駄遣いにつながる可能性があります。具体的な目標を設定し、その達成に必要なステップを明確にすることで、PoCの効果を最大限に引き出すことができます。

例えば、新しいデータ分析ツールのPoCを実施する場合、具体的な目標（例：データ処理速度の向上）とその範囲（例：特定のデータセットに限定）を明確に設定することで、検証結果を判断しやすくなるため、効率的に進めることができます。

ポイント② 適切なリソースを確保する

PoCを成功させるためには、適切なリソースを確保し、それを効果的に運用することが不可欠です。

まず、プロジェクトの規模や目標に応じた時間や予算の確保、そして必要なスキルセットを持つチームを編成して基盤を準備します。

また、確保したリソースを効果的に運用できるかが肝になります。限られたリソースを最大限に活用するためには、タスクの優先順位を明確にし、進捗状況を定期的に見直すことが求められます。

さらに、コミュニケーションの円滑化も効果的な運用には欠かせません。チーム全体が一丸となって目標に向かうためには、情報共有のプラットフォームを整備し、迅速な意思決定ができる環境を整えることが必要です。

リソースを適切に確保し、その運用を最適化することは、PoCの効果最大化につながります。

ポイント③ ステークホルダーとの連携

PoCのような初期段階で主要なステークホルダーの期待や懸念をキャッチアップすることが必要です。これにより、PoCの目標や成果をステークホルダーのニーズとリンクさせることができます。

彼らの意見を尊重し、新しいアイデアや懸念点が出てきた場合、必要に応じてそれを迅速に取り入れ、プロジェクトに反映させることで、チームの信頼性を高めるほか、期待以上のPoCの結果を出すことにもつながります。

また、定期的なコミュニケーションを築ける環境は、プロジェクトの透明性を高め、信頼を築くための基盤となります。週次のミーティングや進捗報告書を通じて進捗を共有し、ステークホルダーの意見やフィードバックを積極的に取り入れましょう。

PoC開発の事例紹介

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

大手輸送機器メーカーの本田技研工業様のPoCプロジェクトを支援しました。
同社新規事業の構想段階における、市場ニーズの把握を目的としたプロジェクトです。プロトタイプ開発とリサーチまでトータル2ヵ月で進行しました。

詳しくは以下をご覧ください。

https://spice-factory.co.jp/works/9319/

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

株式会社NTTデータ関西様では、電子申請や各種予約サービスなど、国・地方公共団体向けの機能を備えるクラウドサービス「行政総合サービスモールe-TUMO」を開発・提供しています。
当社では「e-TUMO」シリーズの一つである、個人番号カード交付予約・管理サービス「e-TUMO MYNUM」のUI/UX改善支援としてプロトタイプ開発を実施しました。

詳しくは以下をご覧ください。

https://spice-factory.co.jp/works/13083/

正しい PoC の実施でパフォーマンスの最大化へ

本記事では PoC についてご説明しました。
このように、PoC で何を実現したいのかの目的を明確にし、その目的を達成するための正しいステップを踏むことが重要です。
知識や経験が不足している状態で着手することは、検証が無意味となりお金が無駄になってしまう、いわゆる PoC死に陥る可能性があります。
PoC を成功させるためにも、専門性の高い会社、人とともにプロジェクトを進行することを推奨します。

スパイスファクトリーでは、PoC のサービスを展開しております。
ご質問やお悩みのある方は、ぜひお気軽にお問い合わせください。

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

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

「膨大のコストをかけて開発しても、プロダクト・サービスが使用されない」

プロダクト・サービス開発の成功に欠かせないのは、MVP（Minimum Viable Product）という考え方です。

必要最小限の機能のみでリリースし、ユーザーのフィードバックを得ながら細かく検証できるため、さまざまなメリットを得ることができます。

本記事では、MVP開発の特徴やメリット・注意点を解説していきます。

また、弊社スパイスファクトリーではMVP開発において豊富な実績があります。

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

MVP開発とは

MVPとは、必要最小限の製品（Minimum Viable Product）を略した言葉です。その名の通り必要最小限のプロダクト・サービスを開発したうえで、顧客の反応を検証しながら改善していきます。この手法をソフトウェア開発に適用したものが MVP開発です。

MVP開発の最大のメリットは、コストと時間を節約しながら、ユーザーのニーズに合った製品を迅速に提供できる点にあります。製品が市場でどのように受け入れられるかを早期に把握することで、大規模な失敗を避けることができます。さらに、ユーザーからのフィードバックを基に製品を進化させることで、より競争力のある製品を開発することが可能になります。

このアプローチは、特にスタートアップや新規事業において有効であり、リソースが限られている中でも最大限の効果を発揮します。MVP開発を通じて、製品の市場適合性を迅速に確認し、必要な調整を行うことで、成功への道筋を早期に見出すことができます。

DXとMVP開発の関係性とは

デジタルトランスフォーメーション（DX）は、企業がデジタル技術を活用してビジネスモデルやプロセスを革新し、競争力を向上させる取り組みです。

MVP開発は、DXを実現するための効果的な手法として注目されています。

DXのプロジェクトでは、技術革新のスピードが速く、変化に柔軟に対応することが求められます。MVP開発は、短期間で市場に製品を投入し、リアルタイムのデータを活用して改善を行うため、この要件に非常に適しています。

また、MVP開発を通じて得られるユーザーデータは、DX戦略の方向性を見極めるための重要な指針となります。企業は、MVPを繰り返すことで、失敗を最小限に抑えつつ、革新的なサービスや製品を迅速に市場に提供することができます。DXとMVP開発の組み合わせは、企業が競争力を高め、成功するための強力なツールとなります。

MVP開発はリーンスタートアップのプロセスの一部

リーンスタートアップとは、事業を効率よく開始・成長させられるマネジメント手法のことです。リーンスタートアップは、エリック・リースによって提唱されたビジネス方法論であり、特にスタートアップ企業や新規事業において、迅速かつ効率的に市場適応性を検証するために活用される手法になります。

MVP開発は、リーンスタートアップの核心となるプロセスの一部です。

リーンスタートアップのアプローチは、「構築」、「計測」、「学習」の3つのプロセスを繰り返すことにより、最小限のリソースで最大限の成果を得ることを目指しています。

「構築」プロセス

リーンスタートアップの最初のステップは「構築」です。

このプロセスでは、初期の仮説やビジネスアイデアをもとに、最小限の機能を備えたプロトタイプを迅速に開発します。ここでのポイントは、完全な製品を作るのではなく、開発しているプロダクトを最も求めていると考えられる顧客（アーリーアダプター）が求める機能だけを搭載することです。

「構築」プロセスでは、以下のような手順が含まれます：

• アイデアの具体化：製品やサービスのアイデアを明確にし、仮説を設定します。
• プロトタイプの作成：ユーザーが体験できる最低限の機能を持つプロトタイプを迅速に作成します。
• リリース：完成したプロトタイプを市場に投入し、実際のユーザーに使用してもらいます。

この段階では、機能の過不足がないことを前提として、顧客が本当に必要とする機能だけにフォーカスし、一切の無駄を省きます。完璧な製品を目指すのではなく、迅速な市場投入とユーザーの初期反応を得ることが重要です。

「計測」プロセス

次に、「計測」プロセスに進みます。

このプロセスでは、MVPを使用したユーザーの行動やフィードバックを詳細に計測し、データを収集します。計測の目的は、ユーザーがどのように製品を利用し、どの部分に価値を見出しているのかを明確にすることです。

計測プロセスの主要な要素は以下の通りです：

• データ収集：ユーザーの行動データやフィードバックを収集します。具体的なツールや方法を使用して、定量的・定性的なデータを集めます。
• 分析：収集したデータを分析し、仮説が正しかったかどうかを検証します。どの機能がユーザーにとって最も価値があるか、どの部分が改善が必要かを明確にします。
• 指標の評価：重要なKPI（重要業績評価指標）を設定し、これに基づいて製品の成功度を評価します。

この段階では、データに基づく客観的な評価が重要であり、感覚的な判断を避けるためにも、精緻な計測が求められます。

また、書籍『THE LEAN STARTUP』（エリック・リース 著）では、有効な分析方法として「コホート分析」が紹介されています。

コホート分析とは顧客を一定条件でグルーピングし、グループごとに時間経過に伴う行動変化（たとえばログイン回数や特定の機能の利用頻度など）を分析する手法です。

「学習」プロセス

最後に、「学習」プロセスに入ります。

この段階では、計測プロセスで得られたデータを基に、製品やサービスの改善点を特定し、次のステップに反映させます。学習の目的は、仮説を検証し、新たな知見を得ることです。プロセスのなかで顧客セグメントの反応をみながらプロダクトの方針転換（ピボット）をするかどうかも検討し、必要があれば構築したプロダクトを全て捨てることも考慮しなければなりません。

「学習」プロセスの重要な要素は以下の通りです：

• フィードバックの分析：ユーザーからのフィードバックを詳細に分析し、どの部分が期待に応えていないかを特定します。
• 改善点の特定：得られた知見を基に、製品やサービスの具体的な改善点を特定します。これには、機能の追加や改良、ユーザー体験の向上が含まれます。
• 次のステップの計画：改善点をもとに、次のバージョンのMVPを計画し、再び「構築」プロセスに戻ります。

プロセスのなかで顧客セグメントの反応をみながらプロダクトの方針転換（ピボット）をするかどうかも検討し、必要があれば構築したプロダクトを全て捨てることも考慮しなければなりません。

書籍『THE LEAN STARTUP』の事例においては、1つのプロダクトが完成するまでに6つものプロダクトを廃棄し、ピボットを繰り返した例もありました。新規事業・新規プロダクト開発の難易度の高さがうかがえます。

このようにリーンスタートアップの「構築」「計測」「学習」のサイクルを繰り返すことで、製品やサービスはユーザーのニーズにより適合した形へと進化していきます。

MVP開発とアジャイル開発の違い

MVP開発とアジャイル開発は、どちらも迅速な製品開発と市場適応を目指す手法ですが、アプローチや目的に違いがあります。

まず、MVP開発は最小限の機能を持つ製品を迅速に市場に投入し、ユーザーからのフィードバックを基に改善を繰り返す手法です。MVPの目的は、製品の市場適応性を早期に検証し、リソースを無駄にせずにユーザーのニーズに応える製品を開発することです。

一方、アジャイル開発は、ソフトウェア開発プロジェクトを小さなイテレーション（反復）に分割し、継続的に改良を加えながら進める手法です。アジャイル開発の主な目標は、柔軟性を保ちつつ、変化する要求に迅速に対応し、高品質なソフトウェアを提供することです。

これらの手法は、考え方として相性の良い点も多いことから互いに補完し合う手法としてMVP開発に開発手法としてアジャイル開発が活用されるケースも多くあります。組み合わせることで製品開発の効率と柔軟性をさらに高めることができます。

ただ、必ずしもアジャイル開発を採用しなくても MVP開発自体は可能となります。

MVP開発のメリット

MVP開発は、スタートアップや新規事業において、迅速かつ効率的に製品を市場に投入し、ユーザーのフィードバックを基に改良を重ねる手法です。MVP開発には、多くのメリットがあります。特に、開発費用を必要最小限に抑えることができ、方針転換がしやすくなる点が大きな魅力です。

開発費用を必要最小限に抑えられる

MVP開発の最大のメリットの一つは、開発費用を必要最小限に抑えられる点です。

従来の開発手法では、完全な製品を作り上げるまでに多くの時間とコストがかかります。開発期間が長引けば、その分だけ人件費や設備費などのコストも増大します。さらに、完成した製品が市場で受け入れられなかった場合、その投資は無駄になってしまいます。

しかし、MVP開発では、最小限の機能だけを持つ製品を迅速に市場に投入します。これにより、初期投資を大幅に削減でき、開発コストを抑えることができます。例えば、全ての機能を揃えた製品を開発するために半年から一年以上の時間と多額の費用が必要な場合でも、MVP開発ならば数ヶ月で市場に投入できるため、開発費用を大幅に削減できます。

また、MVP開発では、ユーザーからのフィードバックを基に改良を重ねるため、不要な機能の開発を避けることができます。これにより、リソースを効率的に配分し、最も価値のある機能に集中することができます。その結果、製品開発における無駄を最小限に抑え、コストパフォーマンスを向上させることができます。

早期に市場感とユーザー反応を確認できる

MVP開発では、製品を早期に市場に投入するため、市況感を迅速に把握し、ユーザーの反応を早期に確認することができます。これにより、市場のニーズやトレンドを素早くキャッチし、製品の方向性を調整することが可能です。

早期の市場投入は、競合他社よりも先に市場シェアを獲得するためにも有効であり、先行者利益を得ることができます。

失敗リスクの軽減

MVP開発は、製品開発におけるリスクを大幅に軽減する手法です。

最小限の機能を持つ製品を迅速に市場に投入し、ユーザーの反応を基に段階的に改良を加えるため、大規模な失敗のリスクを低減できます。問題が発覚した際にも、迅速に対応できるため、リスクを最小限に抑えることが可能です。

また、ユーザーからのフィードバックを基にしたデータ駆動型の意思決定が可能になるため、感覚的な判断を避け、客観的なデータに基づいて製品の方向性を調整することができます。これにより、製品の市場適応性を高め、成功の確率を大きく引き上げることができます。

資金調達のきっかけになる

MVP開発は、資金調達の観点でも大きなメリットがあります。

初期段階で市場に投入し、ユーザーの反応を得ている製品は、投資家にとって信頼性が高く、投資リスクが低いと判断されやすいです。これにより、追加の資金調達が容易になり、製品開発の次のステップに進むための資金を確保しやすくなります。

MVP開発を行う際の注意点

MVP開発は、最小限の機能を持つ製品を市場に投入し、ユーザーからのフィードバックを基に改良を繰り返す手法ですが、成功するためにはいくつかの重要な注意点があります。

以下に、MVP開発を行う際に特に留意すべきポイントを解説します。

目的（ビジョン）に応じた戦略まで明確に決めておく

MVP開発を開始する前に、まずは目的やビジョンを明確にすることが重要です。

開発の目的が曖昧だと、どの機能が最も重要であるかを判断するのが難しくなり、結果的に効果的なMVPを作ることができません。具体的な目標を設定し、その達成に向けた戦略を明確にすることが、成功の鍵となります。

例えば、「ユーザーの特定の問題を解決するための製品を作る」といった明確なビジョンを持つことで、MVPに実装すべき機能が絞り込まれ、効果的な開発が可能となります。このように、ビジョンを明確にしたうえで、方針となる戦略を明確にしておく必要があります。

また、ビジョンは、プロジェクトに関わる全てのメンバーが同じ方向を目指して作業を進めるための基盤となります。

機能は過不足なく実装する

「機能は不足があってもいけないし、過剰に搭載してもいけない」という点も非常に重要です。

ソフトウェア開発の際には、大抵はあれもこれもと機能をたくさん搭載する流れになりやすく、「過剰に機能を搭載しない」という行動については、非常に難しいものです。しかし、プロダクトの目的を達成するためには、避けては通れません。

MVP開発によるプロダクトの好例は、初代のiPhoneです。基本的なコピー & ペーストの機能もなければ、当時最新といわれていた 3G も使えませんでした。しかし、当時のアーリーアダプター（新しい技術、製品、またはシステムを早期に取り入れる消費者のグループのこと）はその iPhone を欲しがったのです。ご存知の通り、現在の iPhone には私たち消費者のニーズを満たす多様な機能が搭載されています。ただ、それは iPhone が幅広く市場に受け入れられた後のことです。

まだプロダクトが本当に顧客に受け入れられるのかもわかっていない開発の初期においては、フォーカスしたターゲットニーズに対して、本当に必要な機能に絞ることが望ましいでしょう。

方針転換は大胆に決定する

たとえば顧客からのフィードバックを求めた結果、戦略が著しく顧客のニーズから外れていたとしましょう。時には開発中のプロダクトを全て廃棄する必要があるかもしれませんが、方針転換が必要な場合、「迷わず・大胆に」実施する必要があります。

 

先述の通り6つものプロダクトを廃棄した例があります。1つのプロダクトを制作するためには2週間～4週間程度を要したそうですが、そのプロダクトを検証して廃棄することを繰り返し、最終的にヒットするプロダクトを生み出せていました。

MVP開発のプロセス

MVP開発のプロセスは大きくみると従来の開発手法通りで、開発機能を戦略に沿って決定し、開発機能を開発・テストしてプロダクトに実装し、ターゲットである顧客セグメントの反応を検証します。

MVP開発プロセスの最大の特徴は、最初に実施する「開発機能の選定」にあるといえるでしょう。「必要最小限の」開発機能を戦略に沿って決定すれば、あとの開発・テストは従来の手法で対応でき、手法によってはコーディングをせずにプロダクトを開発することも可能です。（その手法の種類は後述します。）

このプロセスは以下のステップに沿って進められます。

目標設定

まずは明確な目標を設定します。

何を達成したいのか、どのような問題を解決したいのかを具体的に定めます。この段階で、ターゲットユーザーや市場のニーズを徹底的に調査し、仮説を立てることが重要です。目標が明確であるほど、開発の方向性がブレず、効果的なMVPを作成することができます。

ユーザー調査と要件定義

次に、ターゲットユーザーのニーズや課題を詳しく調査します。

ユーザーインタビューやアンケートなどを通じて、ユーザーが本当に必要としている機能を洗い出します。この調査結果を基に、MVPに必要な最低限の機能を定義し、開発の要件を明確にします。

プロトタイプの構築

ユーザー調査に基づいて、最小限の機能を持つプロトタイプを迅速に構築します。

この段階では、完璧な製品を目指すのではなく、ユーザーが使用してフィードバックを提供できる最低限の実用的な製品を作ります。プロトタイプは、手作りのモックアップやシンプルなデジタルモデルなど、低コストで短期間に作成できるものが理想的です。

ユーザーテストと市場投入

完成したプロトタイプを実際のユーザーに使用してもらい、フィードバックを収集します。

ユーザーテストでは、製品の使い勝手や価値を評価し、どの機能が有用で、どの部分に改善が必要かを具体的に把握します。この段階で得られるフィードバックは、製品の方向性を決定する上で非常に重要です。

フィードバックの分析と改善

収集したフィードバックを詳細に分析し、次のステップに向けた改良点を洗い出します。

ここでは、定量的なデータと定性的なインサイトの両方を考慮し、ユーザーのニーズに最も効果的に応える方法を検討します。改善点を明確にしたら、再度プロトタイプを作成し、同様のテストとフィードバック収集のサイクルを繰り返します。

繰り返しとスケールアップ

MVP開発は、反復的なプロセスです。

フィードバックを基に改善を繰り返し、製品を徐々にスケールアップしていきます。最初は小さな市場でテストを行い、徐々に対象範囲を広げていくことで、リスクを最小限に抑えつつ、確実に市場に適応した製品を開発することができます。

このように、MVP開発はユーザーのニーズを中心に据えた反復的なプロセスです。迅速な市場投入と継続的な改善を通じて、製品の価値を最大化し、成功に導くことができます。

MVP開発の種類

MVP開発には、さまざまなアプローチがあります。アプローチは、目的やリソースに応じて使い分けることができ、どれもユーザーからのフィードバックを早期に得ることを重視しています。

以下に代表的なMVP開発の種類を紹介します。

スモークテスト

スモークテストは、最小限のリソースで製品の市場性をテストする手法です。

具体的には、製品やサービスの実際の機能を提供することなく、仮想的な製品ページや広告を作成し、ユーザーの関心度を測定します。これにより、製品のアイデアが市場で受け入れられるかどうかを早期に判断することができます。

スモークテストは、Webページやランディングページを作成し、広告キャンペーンを通じてトラフィックを誘導し、ユーザーの反応を確認する方法が一般的です。ユーザーが興味を示した場合には、将来的に製品を開発する価値があることが確認できます。

モックアップ

モックアップは、製品の外観や操作感を視覚的に示すための静的なデザインサンプルです。

実際の機能は持たないが、ユーザーが製品の使い方や特徴を理解できるように作られています。モックアップは、ユーザーフィードバックを得るための初期段階のプロトタイプとして利用され、デザインや機能の方向性を確認するために役立ちます。

例えば、アプリケーションのモックアップでは、画面レイアウトやナビゲーションを示す静的な画像を用意し、ユーザーがどのようにアプリを使用するかを視覚的に体験してもらいます。このフィードバックを基に、開発の次のステップを決定します。

オズの魔法使い

オズの魔法使いは、ユーザーには自動化されたシステムであるかのように見せながら、実際には人間がバックエンドで操作する手法です。童話『オズの魔法使い』にある、人々が恐れた魔法使いの正体が実はカーテンの後ろのおじいさんだった、というストーリーから名前がつけられた手法です。

この手法は、ユーザーにリアルな体験を提供しつつ、システムの開発前に実際の使用状況を観察できる点で有用です。

例えば、チャットボットのテストでは、ユーザーがボットと対話していると思っている間に、実際には人間がその対話をリアルタイムで行っている場合があります。これにより、システムの設計や自動化のためのニーズを正確に把握できます。

コンシェルジュ

コンシェルジュ手法は、ユーザー一人ひとりに対してパーソナライズされたサービスを提供し、そのフィードバックを集める方法です。

この手法では、製品やサービスの自動化やスケーラビリティに焦点を当てず、まずは手動で提供することでユーザーの反応を確認します。

例えば、新しいフィットネスプログラムを考えている場合、最初に少人数のユーザーに対してパーソナルなトレーニングセッションを提供し、その反応を基にプログラムを改善することができます。これにより、ユーザーの具体的なニーズを深く理解することができます。

コンビネーション

コンビネーションは、既に世に存在するサービスの組み合わせで新サービスを実現する MVP手法です。

この手法で開発した場合、非常に使い勝手が悪い UI になることが多いですが、実現したいことが叶えられれば一定の評価が得られます。今日では既存サービスの組み合わせをサポートするツールも複数リリースされています。

プロトタイプ

プロトタイプは、実際に動作する最小限の製品を開発し、ユーザーに提供する手法です。

この手法では、ユーザーが製品の基本的な機能を実際に使用し、その体験を基にフィードバックを提供します。プロトタイプは、製品の実用性やユーザー体験を検証するために非常に効果的です。

一方、実際に形を持った製品・サービスを指す場合が多く、コスト的には他の MVP に比較して大きくなる傾向にあります。

MVP開発のポイント

MVP（Minimum Viable Product）開発は、製品開発を迅速かつ効率的に進めるための重要な手法です。以下の3つのポイントを押さえることで、MVP開発の成功を確実にすることができます。

ポイント①検証内容や成果の定義

MVP開発の最初のプロセスである目標設定において、検証内容と期待する成果を具体的に定義することが重要です。これらの明確な定義により、開発の方向性がブレることなく、効果的なフィードバックを得ることができます。

以下のプロセスで各項目を検討できるとよいでしょう。

• ビジョンの具体化：何を達成したいのか、どのような問題を解決したいのかを明確にします。例えば、「特定のユーザーの課題を解決するための製品を作る」といった具体的なビジョンを持つことが重要です。
• 検証項目の明確化：ビジョン達成に関する検証に必要な項目を具体的に定義します。これにより、開発の各ステップで何を確認する必要があるかが明確になります。
• 成果の設定：期待する成果を定義し、これに基づいて製品の成功を評価します。例えば、ユーザー数の増加や特定の機能の利用頻度など、具体的なKPIを設定します。

ポイント②ユーザーへの価値提供とユーザー体験の重視

MVP開発において、プロセスの2つ目となる「ユーザー調査と要件定義」において、ユーザーへの価値提供とユーザー体験（UX）の視点は特に重要です。

ユーザーが本当に求める価値・機能を把握するためには、以下のような専門的なアプローチも必要となります。

• ユーザー調査：ターゲットユーザーのニーズや課題を徹底的に調査します。ユーザーインタビューやアンケートを通じて、ユーザーが本当に必要としているものを明らかにします。
• 価値の提供：ユーザーが直面している問題を解決するための機能を実装します。これにより、ユーザーは製品に価値を感じ、フィードバックもポジティブになります。
• ユーザー体験の向上：使いやすさや操作性を重視し、ユーザーが快適に製品を利用できるようにします。ユーザビリティテストを繰り返し行い、ユーザー満足度を高めることで、より良いフィードバックを得ることができます。

ユーザーへの価値提供と優れたユーザー体験を実現することで、製品の成功率を大幅に高めることができます。

ポイント③データ駆動型の意思決定

プロセスの5つ目に当たる「フィードバックの分析と改善」においてデータに基づいた意思決定をすることも重要なポイントです。

データ駆動型の意思決定により、感覚的な判断を避け、客観的な根拠に基づいた効果的な戦略を立てることができます。また、失敗から学びを得て、継続的に製品を改良することで、最終的には市場に適応した高品質な製品を提供することが可能となります。

一般的なサイクルではありますが、以下のようなプロセスを回すことが必要です。

• データ収集：ユーザーの行動データやフィードバックを定量的・定性的に収集します。具体的なツールや方法を用いて、必要なデータを集めます。
• データ分析：収集したデータを分析し、仮説が正しかったかどうかを検証します。ここで、前提した「検証項目や定義の決定」が活かされます。
• 改善サイクルの実施：分析結果に基づいて製品を改良し、次のサイクルに進みます。失敗を恐れず、改善点を見つけて次のステップに活かすことが重要です。

MVP開発の特性を知って効率のよいプロダクト開発を

MVP（Minimum Viable Product）開発は、最小限の機能を備えた製品を迅速に市場に投入し、ユーザーからのフィードバックを基に改良を重ねる手法です。これにより、初期投資を抑えながら実際の市場反応を確認し、効率的にリソースを配分できます。

MVP開発には高度な専門性が求められます。効果的な機能選定、迅速なプロトタイプ作成、ユーザーテストの実施、フィードバックの適切な分析と改良といった複雑なプロセスが関与するためです。

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

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

ChatGPTは便利なツールではありますが、有効な場面とそうでない場面は分かれます。
特に、社内での業務については社内ルールや業務プロセスなどを踏まえた対応が必要であり、ChatGPTが持つ一般的な知識だけでは難しいことも。

ChatGPTをうまく活用できない理由はどこにあるのでしょうか。社内で利用を促進していくためにはどのような取り組みが必要なのでしょうか。
この記事では、ChatGPTに関する当社の知見を踏まえ、このような課題に対して解説します。

ChatGPTとは

ChatGPTはOpenAI社が開発・提供している対話型のチャットサービスです。
2022年11月のリリース後からすぐにその有用性に注目が集まり、活用が進んでいます。

ChatGPTができること

以下では、ChatGPTが実現できることを簡単にご紹介します。

情報検索（検索エンジンを用いた検索の代わり）

文章の要約、校正

業務の自動化

アイディアの創出

データ分析

ChatGPTの具体的な活用事例については以下の記事でも紹介していますので、併せてご覧ください。

※関連記事：ChatGPTの国内・海外事例8選 ビジネス活用につなげるポイントとは（新しいタブで開きます）

ChatGPTの活用率

業務の効率化や改善に活用できるChatGPTですが、社内での利用については進んでいないのが現状です。

ある調査※では、ChatGPTを「本格的に活用している」と回答した企業は11.5%、「試験的に活用している」と答えた企業も23.5%にとどまっているという結果もあります。
※参考：パーソル株式会社「ChatGPT活用状況レポート」（新しいタブで開きます）より

また、ChatGPTを導入はしたものの、実際には利用していない、いわゆる「導入止まり」に陥っている企業も少なくないようです。

このように、まだまだ日本ではChatGPTの利用基盤が整っている企業が少ないほか、単にChatGPTを導入しても業務効率化といった目標を達成できるまでの十分な活用が出来ているケースが少ないのが実情です。

ChatGPTが社内で利用されない2つの理由

ChatGPTの社内利用が進んでいない背景にはどのような理由があるのでしょうか。
当社では、2つのChatGPTの性質が関係していると考えています。

①職種やタスクの性質がChatGPTとあっていない

そもそも、ChatGPTはあらゆる業務をカバーしてくれる魔法のツールではありません。

ChatGPTと相性がよい職種やタスクであるかどうかにより、うまく活用できるか変わってきます。
相性が良い職種やタスクを分けるポイントは、インターネット上に存在する一般的な情報で作業できるかどうかです。

たとえば、ITエンジニアであればコードの自動生成をお願いできます。
もしくは、データ分析をされる方であればエクセルやスプレッドシートでの集計・分析処理の提案をChatGPTにしてもらうことも可能です。
もちろん、ChatGPTが出力した内容が正しいとは限らないため、利用の際は出力結果を見極められるだけの技量は必要です。
それでも、業務を効率化できる余地は大きいといえます。

一方で、インターネット上に存在しない情報を基にする作業では、ChatGPTの活用は限定的なものとなります。
社内業務など社内のルールやプロセスに沿って仕事をしなければならない方にとっては、企画書の推敲やメール返信内容の原案など部分的にChatGPTを利用することはできますが、活用の幅は限定されます。

②ChatGPTが社内独自の業務に対応できない

ChatGPTは膨大なデータを学習していますが、それはあくまで公開されている一般情報のみです。

当然ながら、社内規程や業務ルール、ノウハウなどを学習しているわけではありません。
多くの仕事はインターネット上に存在する情報だけでは完結しないため、ChatGPTでの対応が難しいといえます。

一方で、社内のプロセスに沿った業務ほど業務効率化の改善余地があるのも事実です。
ChatGPTが社内のコンテキストを理解して対応してくれれば、このような業務も効率化できます。

しかし、このような社内独自の情報をChatGPTに習得させるには一定のエンジニアリングスキルが必要となります。
次項では、具体的にどのようなアクションが必要かを紹介していきます。

ChatGPTの活用率を上げるポイントは「RAG」

本項では、ChatGPTが利用されない理由の2つ目として上述した「②社内コンテキストを理解した対応をしてくれない」について深掘りしていきます。
ChatGPTに社内コンテキストを理解してもらうためには、具体的にどのような手法がとられるのでしょうか。

一般的に有効な手法として知られるのが検索拡張生成（Retrieval-Augmented Generation : RAG）です。

RAGを端的に言えば「ユーザーの質問と参照情報を一緒にChatGPTに与えて、参照情報を元にした回答を出力させる」という方法です。
具体的には、以下の流れで社内情報に基づく回答が可能となります。

ユーザーは、ChatGPTに教えてほしい内容をプロンプトとして入力する

入力内容に関連する社内情報を検索用データベースから取得する

ユーザーの入力内容と検索した社内情報をChatGPTに渡す

ChatGPTは社内情報を元にユーザーの入力に対する回答を生成する

たとえばChatGPT Plusプランで利用できるGPTsでは「Knowledge」機能として、社内ドキュメントファイルをアップロードし登録するだけで簡単にRAGを利用できます。
ChatGPTから社内情報を踏まえた出力を得られれば、活用の幅も広がります。

RAGの利用におけるポイント

ここまでの説明から、RAGによる社内情報の利用は簡単にできると感じられるかもしれません。
しかし、その利用においてはいくつかポイントがあります。

ポイント1：セキュリティ

社内情報をアップロードする際には、セキュリティの担保が求められます。

たとえばChatGPTでは、ChatGPT PlusプランもしくはTeamプランではアップロードした情報はOpenAIのサーバーに保持されることとなります。
もちろん、セキュリティ面に問題があるわけではありませんが、社内のセキュリティ規程によっては利用できないケースもあります。

ポイント2：精度

弊社の経験も踏まえると、単純にドキュメントを丸ごとアップロードするだけでは十分な精度がでない可能性があります。

たとえば、社内の問い合わせに対して回答を生成するケースを想定します。
このとき、社内ドキュメントには問い合わせに関係のない情報も含まれます。
また、同じ内容が複数のドキュメントに書かれているなど、情報が重複しているケースもよくあります。
結果として、ChatGPTが実際の回答根拠となる部分以外も参照してしまい誤った回答を生成する可能性が高くなります。

LLM（Large Language Model：大規模言語モデル）は「最初と最後の情報を重要視し、中間情報は忘れやすい」という特性があるため※、大量の文章を渡すと情報が抜け落ちやすくなるのです。

この対策として、ドキュメントを丸ごとではなく、ある程度の意味の塊に区切るなどの前処理が重要となりますが、たとえばChatGPT Plusプランでは対応できない（2024年4月時点）といった問題もあります。

※参考：Lost in the Middle: How Language Models Use Long Contexts（新しいタブで開きます）より

ポイント3：料金

OpenAIが提供するAPIを利用する場合には、文字数に比例したAPI利用料がかかります。

RAGにより大量にChatGPTにインプットを与えると、コストが高くなりがちです。
可能な限り余計な情報は送信しない方が費用を抑えられるため、上述した精度の問題と合わせて工夫が求められます。

参考：Fine-tuningについて

なお、本記事では社内情報などの独自情報を利用する方法としてRAGを紹介しましたが、同様の手法としてFine-tuningと呼ばれるものもあります。
Fine-tuningとは、簡単にまとめると、既にテキストデータを学習したモデルを基にして、特定のタスクや業界に合わせてさらに学習を進めることです。

ただ、弊社の経験と一般論※もふまえると、Fine-tuningでは気軽に独自情報に対する回答をさせることは難しいといえます。

RAGでは入力と独自情報を既存のLLMに渡しているだけで、既存のLLM自体には何も手を加えていませんが、Fine-tuningではLLM自体に追加でデータを学習させます。
学習データの準備、パラメータを調整しながら繰り返し学習データを用いた学習の実行、性能評価というサイクルを回す必要があり、かなりの時間とコストがかかります。

このような背景もあり、独自情報の検索においては広くRAGが利用されています。

※参考：Fine-Tuning or Retrieval? Comparing Knowledge Injection in LLMs（新しいタブで開きます）より

まとめ

以上、この記事では「なぜ社内導入したChatGPTが使われないのか？」についてご紹介しました。

インターネットの公開情報を大量に学習しているChatGPTなどのLLMは、特定の職種やタスクにおいてはそのままの状態でも非常に心強い相棒となりえます。
一方で、多くの仕事は社内情報を利用するものであり、社内コンテキストを理解してくれないChatGPTでは限定的な利用しかできません。

そのため、広く社内の業務効率化を進めていくためにはRAGなどの仕組みを導入する必要があります。
なお、今回はChatGPTを取り上げましたが、ClaudeやGeminiなど他のLLMについても同様となります。

弊社では生成AI/GPT導入支援サービスを提供しております。
AzureやAWSなどで社内独自のインフラ環境を用意し、カスタマイズ性の高い社内GPT導入支援サービスを提供しております。

様々なデータの前処理の知見を活かし、精度の高い社内GPTの構築や独自性の高い用途への対応も可能となっております。
ChatGPTの活用を検討されている方は、お気軽にお声がけください。

アジャイルの理念に沿って柔軟な開発を実現するためには、開発内容を整理したプロダクトバックログを定期的に修正・改善していく取り組みが必要です。
スクラム開発においては、このような活動は「バックログリファインメント」として位置づけられています。
バックログリファインメントは具体的にどのように進めていくべきものなのでしょうか。

この記事では、スクラム開発を得意とする当社、スパイスファクトリーが、スクラム開発におけるバックログリファインメントについて解説します。

バックログリファインメントとは

バックログリファインメントとはどのような取り組みなのでしょうか。まずはその概要をご紹介します。

バックログリファインメントとは

バックログリファインメントとはスクラム開発におけるイベントの一つであり、スクラムチームによって行われるプロダクトバックログのアイテムの見直し作業のことです。
スクラム開発のガイドラインである「スクラムガイド」によれば、バックログリファインメントは以下のように説明されています。

スプリント内でスクラムチームが完成できるプロダクトバックログアイテムは、スプリントプランニングのときには選択の準備ができている。スクラムチームは通常、リファインメントの活動を通じて、選択に必要な透明性を獲得する。プロダクトバックログアイテムがより⼩さく詳細になるように、分割および定義をする活動である。これは、説明・並び順・サイズなどの詳細を追加するための継続的な活動である。

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

少しわかりにくい文章ではありますが、ポイントとして押さえておくべきは「リファインメントの取り組みはスクラムチームが開発内容を決定しやすいように、プロダクトバックログアイテムを小さく・詳細に定義しなおしていく活動」であるという点です。

なお、そもそもスクラム開発とはどのようなものであり、プロダクトバックログとは何であるかについては以下の記事で詳しく解説しております。
よろしければ、本記事と合わせてご覧ください。

https://spice-factory.co.jp/development/about-scrum-event/

バックログリファインメントの目的

スクラム開発においては、なぜバックログリファインメントによってプロダクトバックログの見直しを行わなければならないのでしょうか。
端的に言うと、柔軟なプロダクト開発を実現するというアジャイルの思想を実現するための取り組みとして必要だからだと考えられます。

プロダクトバックログは、スクラムチームの唯一の情報源として開発すべき要件やその優先順位が記載されています。
開発のスタート時にはプロダクトバックログを作成しますが、その後開発が進むについて実際に動作するプロダクトの確認による気づきや、ユーザーからの意見、もしくはビジネスニーズの変化などにより、開発すべき機能は変化していきます。

アジャイル開発の強みは、このような変化に柔軟に対応できる点にあります。
プロダクトバックログを定期的に見直していくことで、今、スクラムチームが取り組むべき開発内容を再精査することができます。
このようなアジャイルの強みを体現するためにも、イベントとしてバックログリファインメントに取り組むことが必要とされます。

バックログリファインメントで実施すべき内容

具体的に、バックログリファインメントではどのようにプロダクトバックログの見直しを行うべきなのでしょうか。
上述したスクラムガイドによる定義を踏まえると、見直しにおいて実施すべきは以下の4つの観点であると捉えられます。

• プロダクトバックログアイテムの粒度調整
• プロダクトバックログアイテムの詳細化
• プロダクトバックログアイテムの優先度調整
• プロダクトバックログアイテムの追加

プロダクトバックログアイテムの粒度調整

ひとつは、プロダクトバックログアイテムの粒度を調整する作業です。
各スプリントにおける開発を円滑に進めるためには、プロダクトバックの粒度は小さいほうが望ましいといえます。
広い概念を含むプロダクトバックログアイテムがあれば、より細かい単位で分解してきます。スクラムにおいては、明確かつ簡潔にプロダクトバックログを整理することが重要です。

また、場合により開発中にプロダクトバックログアイテムがどんどん追加されていくことで、意図せず内容の重複が発生することもあります。
プロダクトバックログ全体を見直してみて、統合すべき内容があれば統合することも検討します。

プロダクトバックログアイテムの詳細化

各スプリントにおいてプロダクトバックログのアイテムを開発していくためには、各アイテムが十分に詳細化されている必要があります。
具体的には、プロダクトバックログのアイテムがどのようなものであるか十分に説明されており、また開発にどの程度の作業量が必要であるか見積されていることが必要です。

また、チーム内においてプロダクトバックログアイテムの価値が共有されており、開発者は何を作ればよいか理解できている状況である必要があります。
スプリントにおける開発を円滑に進めるためにも、プロダクトバックログアイテムを詳細化し、チームメンバーに伝わる形としていく必要があります。

プロダクトバックログアイテムの優先度調整

プロダクトバックログアイテム全体を改めて確認し、優先順位の調整を行います。
様々なニーズや要望により、開発の優先度は常に変化していきます。
粒度の調整や詳細化の結果を踏まえつつ、バックログリファインメントのタイミングで優先度の見直しを行うとよいでしょう。

優先度調整の作業においては、プロダクトゴールを常に意識する必要があります。
もし当初定めたプロダクトゴールから変更を検討すべきなのであれば、プロダクトバックログアイテムの優先度だけではなく、全体の方向性となるプロダクトゴールについても見直すべきです。

プロダクトバックログアイテムの追加

もちろん、プロダクトバックログアイテムの追加についても必要に応じてリファインメントのタイミングで実施します。
当初想定されていなかったものの、新たに対応が必要になった要素があれば、このタイミングで追加し、併せて他のアイテムと合わせて優先度の調整などを実施していきます。

バックログリファインメントの実施方法

バックログリファインメントはどのような取り組みとして行うべきなのでしょうか。
以下では、「いつ」「誰が」「どのように」進めるべきかという各観点で整理します。

いつやるか

スクラムガイドによれば、バックログリファインメントの実施タイミングは「スプリントプランニング時」とされています。
スプリントプランニングはスプリントの起点となる活動であり、本スプリントにおいて何を開発するかを決定する作業です。
スプリントにおいて開発する内容を決定する際には、最新の状況に基づき整理されたプロダクトバックログが必要となります。
よって、このタイミングでのバックログリファインメント実施が有効です。

スプリントプランニング
スプリントプランニングはスプリントの起点であり、ここではスプリントで実⾏する作業の計
画を⽴てる。
～中略～
開発者は、プロダクトオーナーとの話し合いを通じて、プロダクトバックログからアイテムを
選択し、今回のスプリントに含める。スクラムチームは、このプロセスの中でプロダクトバッ
クログアイテムのリファインメントをする場合がある。それによって、チームの理解と⾃信が
⾼まる。

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

誰が実施するべきか

スクラムガイドによれば、プロダクトバックログのリファインメントは「スクラムチーム」が実施することとされています。
リファインメントの活動はチーム全体で実施するべきものです。

一義的には、プロダクトバックログの管理はプロダクトオーナーの役割ですので、バックログリファインメントにおいてもプロダクトオーナーの意見・意思は重要なものとなります。

一方で、プロダクトオーナーはアジャイル・スクラムに精通しているとは限らず、適切な粒度でプロダクトバックログアイテムを整理することが難しいケースもあります。
そのような場合は、スクラムマスターや開発チームなどがサポートを行います。
また、開発規模の見積作業などは開発チームでなければできない作業です。

どのように実施すべきか

バックログリファインメントの進め方について、最新のスクラムガイドでは具体的な記載はありませんが、2017年版では「リファインメントは開発チームの作業の10%以下」を目安とするという記述があります。
たとえばスプリント期間が1週間の場合、2時間程度が一つの目安となるでしょう。
バックログリファインメントにかけるべき工数に悩まれる方は、ひとつの参考にするとよいでしょう。

また、スプリントプランニングを行う上では、開発対象となるプロダクトバックログアイテムがどのようなものであり、どのような価値を生むのかをチームが理解している必要があります。
バックログリファインメントの結果はチーム全体で共有していくことが重要です。

正しいバックログリファインメントで円滑なスクラム開発を

この記事では、スクラム開発におけるバックログリファインメントについて、その概要や実施内容、進め方についてご紹介しました。
スクラム開発を遠隔に進めていくためには、バックログリファインメントの活動が重要であることが伝われば幸いです。

スクラム開発を成功させるためには、バックログリファインメントをはじめとしてスクラムの考え方を十分に理解したスクラムマスター・エンジニアがチーム内にいることが重要となります。

日本国内における IT人材不足が叫ばれる中、コストやリソース確保の観点からオフショア開発の活用に目を向ける企業も増えています。
かつて、オフショア開発においてはウォーターフォール型で定められた仕様にもとづき開発を委託する形態も多かったですが、近年ではアジャイル開発でのプロジェクト事例も増えてきています。

この記事では、アジャイル開発に強みを持ち、オフショア開発サービスも提供している当社、スパイスファクトリーが、オフショア開発とアジャイル開発を組み合わせることの有効性についてご紹介します。

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

アジャイル開発とオフショア開発について

まず、アジャイル開発とオフショア開発それぞれの概要を簡単に整理します。

アジャイル開発とは

アジャイル開発とは、システムを機能ごとに小さく分割し、その小さな機能単位に開発・リリースを繰り返していく手法のことです。
アジャイル開発は開発の指針を示す方法論であり、アジャイル開発の中に更に「スクラム（新しいタブで開きます）」「XP（エクストリーム・プログラミング）」などの様々な開発手法が存在します。
これらに共通するのは、アジャイル(agile : 機敏な、素早い)という言葉がさすように、小さい開発スパンの繰り返しによって螺旋階段のようにシステムの開発を行っていくということです。
アジャイル開発の特徴の一つとして、最初の開発スパンが完了した時点で実際にある程度動くプロダクトを触ってみることができるという点が挙げられます。

アジャイル開発の主なメリットは以下のとおりです。

• 変化に対する柔軟性
• 早期にシステムを確認できる

アジャイル開発については以下の記事で詳しく解説しているので、ご興味のある方は併せてご覧ください。
関連記事：アジャイル開発とは？ – システム開発を発注する時に知っておきたい開発手法の話（新しいタブで開きます）

オフショア開発とは

オフショア開発とは、システムの開発業務における一部もしくは全部の工程を海外に委託することを指します。
かつて、オフショア開発は人件費の安い国に発注できる「コスト面」と国外に人材を拡張できる「リソース確保面」がメリットと認識されてきました。

近年は、オフショア開発の拠点国として人気のある東南アジア圏も経済成長してきており、人件費も高騰してきているため、コスト面のメリットは減少傾向です。
その一方で、高度な教育を受けた技術力の高い海外人材が増えてきていることもあり、単に人材リソースを確保するのみならず、技術力を活用するという観点でも注目が集まっています。

オフショア開発の主なメリットは以下のとおりです。

• コスト
• 技術力
• リソースの確保
• 開発スピード

オフショア開発については以下の記事で詳しく解説しているので、ご興味のある方は併せてご覧ください。
関連記事：オフショア開発とは？簡単にわかるメリットや最新の市場動向（新しいタブで開きます）

アジャイル開発とオフショア開発の組み合わせは有効なのか

双方メリットのあるアジャイル開発とオフショア開発ですが、オフショア開発をアジャイル型で実施することはできるのでしょうか。

結論から言うと、オフショア開発をアジャイル型で実施することで、上述した両方のメリットを享受できます。
一方で、アジャイル × オフショアでプロジェクトを推進する場合には、注意しなければならない点もあります。

もっとも難しいのは「コミュニケーション」です。
ウォーターフォール型の開発では、要件をドキュメントとして明確に定義し、請負でオフショア拠点へ依頼するため、コミュニケーションコストは比較的低くなります。

対して、開発する機能を調整しながら進めるアジャイル型では、オフショア拠点と密にコミュニケーションをとりながらプロジェクトを進めていく必要があります。

コミュニケーションの観点を意識し、チームが一体となってプロジェクトを進めることができれば、アジャイル開発・オフショア開発のメリットを最大限享受することができるでしょう。

関連記事：オフショア開発は失敗しやすい？よくある失敗パターンの原因と対策を解説（新しいタブで開きます）

アジャイル × オフショア開発の実践事例

それでは、過去の事例ではどのようにアジャイルとオフショアを組み合わせて開発を進めているのでしょうか。
以下では、いくつかのケースを取り上げ、ご紹介します。

中国オフショア体制におけるスクラム実践

アジャイル型で中国拠点へのオフショア開発を行ったある事例では、やはりコミュニケーションによるバグや手戻りが課題となりました。
本事例のオフショア拠点においてアジャイル型での開発は初めてで、経験値が低かったこともプロジェクトが難航した原因の 1つです。

本事例では、コミュニケーションを強化するために以下のような取り組みを実施しました。

プロジェクト序盤にオンサイト期間を設ける

1つのチームとして活動することが重要となるアジャイル開発ですが、国内・オフショア拠点の物理的な距離から、チームメンバーがお互いにチームの一員であることを認識しづらい環境にありました。
そこで、初回から第3スプリントまでオフショアの開発チームを日本に招き、日本側のメンバーとオフショア側のメンバーが同じ拠点で開発をする取り組みを実施。
その間にアジャイル開発に関する教育やチームビルディングを実施しました。

中国語と中国の文化が分かるスクラムマスター（ブリッジSE）の起用

オフショア側の中国人技術者には日本語が堪能な人材が多かったものの、もちろん全員日本語が話せるわけではありません。
そこで、中国出身かつアジャイルの経験が豊富な人材をスクラムマスター（新しいタブで開きます）に起用し、スクラムマスターの役割を担うと同時にブリッジSE（新しいタブで開きます） として通訳などコミュニケーションのフォローも担当しました。

イベントの追加とTV会議システムの常時接続

やはり遠隔で作業を進めなければならない関係上、コミュニケーションの機会と品質は対面には劣ります。
そこで、一般的なアジャイル開発よりもレビューやミーティングを増やしつつ、TV会議システムを常時稼働させ、いつでもコミュニケーションが取れる環境を整備しました。

これらの取り組みの結果として、ミスコミュニケーションによるバグや手戻りは減少。チームへのヒアリングにおいても、効果を実感できたという感想を得ることができました。

参考：杉浦 由季, 小堀 一雄, 柴山 洋徳, 中国オフショア体制におけるScrum実践手法の提案と検証, 情報処理学会論文誌デジタルプラクティス, 7 (3), 268-274, 2016-07-15（新しいタブで開きます）

アジャイル × オフショア開発におけるコミュニケーションコスト低減手法

次にご紹介するのは、オフショア開発におけるコミュニケーションコスト削減に関する研究です。
この研究では、中国およびベトナムへのオフショアを実施したある事例を対象に、コミュニケーションに関してどのような課題が発生しているのかを抽出しました。
結果として、以下のような点が課題であることが明らかとなりました。

言葉の統一が不十分であること

同じ意味の言葉が様々な表現で伝えられており、コミュニケーションコストを上げる一因となっていました。
特に日本語から中国語もしくはベトナム語に翻訳する際に、意図が誤って伝わるケースも多く、日本語およびオフショア先の言語での用語定義が重要であることが明らかとなりました。

判断基準のルール化が不十分であること

レビューに対する基準が明確に設けられておらず、レビューを実施するまで作成した設計やソースコードが適切か判断しにくいことも難しい点でした。
どのように開発を行えばよいか、オフショア拠点に対して明確に伝えることが重要です。

ブリッジSEの役割

中国へのオフショアは日本語で開発者と直接コミュニケーションがとれたものの、ベトナムへのオフショアにおいては開発者と日本語でコミュニケーションが取れないという課題がありました。
両者を仲介するブリッジSE が適切にコミュニケーションを行うことが重要となります。
この研究では、特に言葉の定義に注目して、用語集の定義によるコミュニケーションの円滑化が提案されています。

参考：上野 肇, 山本 修一郎, オフショアを活用したアジャイル開発における コミュニケーションコスト低減手法の提案, 人工知能学会 知識流通ネットワーク研究会, 2013 年 2013 巻 KSN-013 号 p. 03-（新しいタブで開きます）

アジャイル手法の導入でウォーターフォール × オフショア開発の問題点を解決

従来ウォーターフォール型でオフショア開発を行っていたある事例では「要求があいまいであり対応できない」「品質に対する考え方が異なる」「情報共有が難しい」「モチベーションを保つのが難しい」などの課題が顕在化していました。

これらを解決する方法として、ウォーターウォール型からアジャイル型へプロジェクトの進め方を変更。
結果として、上述した4つのすべての要素に一定の効果がありました。

特にモチベーション面では、オフショア側も含めてチームで良いものを作るにはどうしたらよいか検討を進めることで自律性が高いチームとなり、結果として離職率が一番低いチームとなるなど、高い効果を得ることができました。

一方で、やはりコミュニケーションについては課題もあり、ツールの利用などでカバーすることが推奨されています。

参考：オージス総研「オフショア開発の問題点をアジャイル開発で効果的に解決！」（新しいタブで開きます）

アジャイル × オフショア開発の成功に必要な要素

これまでご紹介してきた事例や、これまで当社が実施してきたオフショア開発プロジェクトの経験を踏まえると、アジャイル × オブショアのプロジェクトを成功させるために必要な要素は以下のとおりだと考えられます。

コミュニケーションの工夫

アジャイル開発においてはチームが一体となれるようにコミュニケーションを密にとっていく必要があります。
しかしながら、物理的距離、文化的距離のあるオフショア拠点と密にコミュニケーションするためには工夫が必要です。

コミュニケーションツール活用はその1つです。
ZOOM 等のオンラインミーティングツールや Slack などのチャットツールで、同期・非同期両面で密にコミュニケーションをとれる環境を用意します。

また、費用面などの懸念はありますが、一定期間は同一拠点で共に開発を行うなど、チームビルディングの観点から両者の心理的な距離を縮めるための工夫も必要でしょう。

多言語対応可能なスクラムマスター（ブリッジSE）の存在

オフショア拠点によっては、エンジニアと日本語でコミュニケーションをとることが難しい場合も多々あります。
そのような場合には、プロダクトオーナー（新しいタブで開きます）などの依頼者と開発者の仲介役としてブリッジSE の存在が重要となります。

ブリッジSE が国内とオフショア拠点双方の仲立ちを行い、ミスコミュニケーションが発生しないようにプロジェクトをサポートしていきます。しかし、複数の言語を理解し、またアジャイル開発に精通したブリッジSE を確保するのは難しいケースも。どのように優秀な人材を確保していくかがポイントです。

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

オフショア拠点メンバーのアジャイル開発への理解とコミット

もちろん、オフショア開発先のメンバーがアジャイル開発を理解し、適切に実践していなければプロジェクトはうまくいきません。特に重要となるのはプロジェクトへのコミットです。

委託された内容を仕様に沿って作ればよいウォーターフォール型の開発とは異なり、アジャイル開発ではメンバーが積極的にシステムの改善提案を行い、プロジェクトを前に進めていく必要があります。
ワンチームになれるように、各国の文化を理解しながらチームビルディングを進めていくことが重要となります。

アジャイル開発に適した契約形態

アジャイル型で開発を行う場合、請負契約ではなく準委任契約で契約を締結することが一般的です。
請負契約では事前に要件を明確に定める必要がありますが、準委任契約では柔軟な変更が可能となります。

特にオフショア開発においては、準委任契約にてプロジェクトを進めることを「ラボ型開発」と呼ぶこともあります。
ラボ型開発の概要やメリットについては以下の記事で詳しく解説しているため、併せてご覧ください。
参考：ラボ型オフショア開発とは？メリットや請負型との違いも説明（新しいタブで開きます）

弊社、スパイスファクトリーでは、ラボ型同様の準委任契約をベースに、ラボ型のデメリットだった「一定量の発注をし続けないと費用対効果が悪化する」といった点を解決する柔軟性を持たせたサービスとして「タイムチャージ型」（新しいタブで開きます）という形態のサービスも提供しています。
ご興味をお持ちいただけましたら是非お気軽にご相談ください。

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

アジャイル開発に適した案件を対象とする

案件によっては、ウォーターフォール型の開発が適しているケースもあります。
開発する内容や納期が明確である場合は、リスクヘッジやコストの面からあえてウォーターフォール型を採用することも検討できます。

一方で、ユーザー体験が重要であるシステムや、新規事業に伴い開発するシステムなど、明確な正解がないケースについては柔軟な要件変更が可能であるアジャイル型が適しています。
特にオフショア開発においては、新規開発するシステムの方がオンボーディングしやすいという特徴もあります。
新規開発案件においては、既存の設計書やソースコードを読み解く必要がなく、キャッチアップしやすいためです。

日本語で書かれた既存システムのドキュメントを理解するためには、言語の違いもありかなりの工数が必要となるため、注意が必要です。
参考記事：新規事業担当者必見。“アジャイル開発”で小さく始めるシステム開発（新しいタブで開きます）

オフショア開発においてもアジャイル開発の力を発揮することは可能

この記事では、アジャイル開発とオフショア開発の組み合わせについて、事例をご紹介しながら有効性や気を付けるべきポイントについてご紹介しました。

アジャイル × オフショアで開発を行う場合には、円滑なコミュニケーションを実現するための取り組みや、優秀なブリッジSE の確保が特に重要となります。

創業当初より、エンジニアの幅広い技術力を必要とするアジャイル開発を強みとして成長してきた当社では、オフショア開発においても「安い」だけでなく「高品質」なサービスを提供しています。
窓口となるブリッジSE は、もちろん日本語でのコミュニケーションが可能です。
また、現地駐在責任者によるマネジメント体制構築や CTO による直接の技術指導、海外拠点現地研修などを実施。ブリッジSE 以外の現地メンバーも含め円滑なコミュニケーション実現のための取り組みを行っています。

アジャイル × オフショアでの開発にご興味のある方は、ぜひ一度当社にお問い合わせください。

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

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

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

参考文献

• 杉浦 由季, 小堀 一雄, 柴山 洋徳, 中国オフショア体制におけるScrum実践手法の提案と検証, 情報処理学会論文誌デジタルプラクティス, 7 (3), 268-274, 2016-07-15
• 上野 肇, 山本 修一郎, オフショアを活用したアジャイル開発における コミュニケーションコスト低減手法の提案, 人工知能学会 知識流通ネットワーク研究会, 2013 年 2013 巻 KSN-013 号 p. 03-
• 株式会社オージス総研 技術部クラウドインテグレーションセンター茨木 良昭,アジャイル開発センター 張 嵐,「オフショア開発の問題点をアジャイル開発で効果的に解決！」,オブジェクトの広場,株式会社オージス総研,2012年10月4日,閲覧日 2023年10月2日,https://www.ogis-ri.co.jp/otc/hiroba/technical/CLIC/AgileOffshoreCaseStudy/casestudy.html

QAエンジニアは、システム開発において品質を担保する業務に従事するエンジニアのことです。
通常のシステム開発はもとより、システムの品質管理や品質保証に関わる内容をメインに対応していきます。
システム開発においては、QAエンジニアの存在が品質を大きく左右する場合もあるのです。

今回は QAエンジニアについて、システム開発やオフショア開発の品質管理の重要性も交えてお伝えしていきます。

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

QAエンジニアとは

QAエンジニアとは、主にシステムやソフトウェアの品質管理や品質保証に従事するエンジニアを指します。
頭についている QA とは Quality Assurance のことで、日本語に直訳すると「品質保証」です。

システムにおける品質とは、「システムに求められる要求事項が満たされている度合のこと」です。

システムの品質管理・品質保証については、要件定義や仕様確認、各種テスト計画など、複数冊の本がかけるほど多くの内容がありますが、それらの知識や経験にもとづきシステムやプロダクトの品質担保に貢献することが QAエンジニアの大きな役割です。

QAエンジニアが求められる背景

QAエンジニアは、なぜ求められるのでしょうか。その背景についてみていきましょう。

システムトラブルがビジネスにもたらすリスクの増大

システム開発においては、1つのミスが顧客に大きな障害・損害をもたらすこともあります。

近年、ビジネス環境は大きく変化しています。
たとえばクラウド環境が整備されたことなどを背景に、ネットワーク経由でデジタルサービスを提供する SaaS（Software as a Service）のビジネスモデルが一般的になりました。
SaaSビジネスでは、1つの不具合がインターネットを通じて広範なユーザーに影響を及ぼしてしまいます。
最悪の場合、サービス破綻や損害賠償などのリスクも孕みます。
そこまでいかずとも、システムエラーの多さが顧客満足度を著しく下げることになるのは体感的にもわかるのではないでしょうか。

SaaSビジネスの多くは、サブスクリプションモデルという一定期間ごとにユーザーに課金してもらい、お金を払ってもらっている期間はサービスの利用が可能になるといった課金モデルを採用していることが一般的です。
満足度が低ければ当然ユーザーに解約されてしまいますし、解約率の上昇は企業にとってそのまま収入減になります。システム品質の悪化がそのまま業績の悪化に直結してしまうのです。
昨今 DX の必要性が叫ばれていますが、デジタル化が進めば進むほど、システム品質の担保のビジネス上の重要度も大きくなっていくのです。
そうした背景からも、品質を確保する QAエンジニアの必要性が増しています。

アジャイル開発手法の採用などでシステム開発が高速化

先述した SaaSビジネスなどでは、日本でかねてから一般的なシステム開発手法として採用されてきた、開発したいシステムの全体像を決めて要件定義～開発～テスト～リリースといった開発プロセスを順番に進めるウォーターフォール開発ではなく、顧客の反応や市場動向を窺いながら柔軟かつ高速に方針転換ができるアジャイル開発を採用するケースが増えてきています。

現代ビジネスにおける顧客ニーズの変化は速く、新型コロナウイルスの蔓延のような予測が難しい外部環境の変化も起こり得ます。
このような環境においては、小さく速く仮説を検証し、ダメであればすぐに方向転換をしていくといった方針が相性が良いと考えられています。
その方針にマッチしている開発手法として採用されることが増えてきたのがアジャイル開発です。

アジャイル開発では、「ユーザーに早く価値を届ける」ことを重要視しており、機能単位で、高速に、かつ高頻度で要件定義～開発～テスト～リリースといった開発プロセスを行います。
機能ごとに高速で開発～リリースを進めるということは、テストの頻度も多くなり、不具合への対応にもスピードが要求されるようになります。
アジャイル開発に象徴される、プロダクト開発の高速化に対応するため、DevOps（新しいタブで開きます） などの仕組みづくりも盛んにおこなわれています。
システム品質の管理についてもそうした変化に耐えうる仕組み作りが必要です。
品質管理の仕組みづくりをリードする人物として、QAエンジニアが求められています。

システム品質の観点の多様化

近年のシステム開発では UX（ユーザーエクスペリエンス：システムのユーザーにとって快適な利用体験を提供すること）の視点の重要性が認識されてきています。
単に仕様書に記載されたシステム要件を満たしている、エラーが出ないというだけでなく、ユーザーにとって使いにくくなっていないか、といった観点からもテストが求められるのです。

ユーザー視点を持ち合わせた QAエンジニアの活躍により、ユーザーの満足度の確保も可能になります。

QAエンジニアの役割

QAエンジニアというと、テストだけに参画するイメージを持つ人もいるかもしれませんが、決してそうではありません。

もちろんテスト業務を行う場合もありますが、場合によって QAエンジニアはシステムの上流工程から参画し、品質を保証できる仕組みづくりに携わることもあります。

たとえば、一般的には以下のような役割がQAエンジニアには求められます。

• システム全体の品質定義
• 仕様品質の担保
• テストフローの整備
• テスト計画・設計作成
• テスト仕様書作成・実施
• リリースの判断
• 不具合分析と改善の業務

ここでは、上記に挙げたような一般的な QAエンジニアの役割を具体的にみていきましょう。

品質保証テストの設計・計画

システムテストの実施計画を立て、関係部署とスケジュールを調整します。
テストのフローをどんなツールと手順で進めていくかをルール化することでスムーズなテスト完了を実現します。

テスト実行・検証

テスト計画に沿って、製品の動作や品質をチェックします。
企業やチームによってはテスト実務には QAエンジニアが関与しないケースもあり得ますが、対応領域としては認識しておくべきでしょう。

改善案を含めたフィードバック

テストで発見した不具合を分析し、開発者へ改善案を提示します。
プロダクト品質の責任を担い、クライアントと開発者の間に立って品質向上に尽力します。

その他工程でのフォロー

たとえば他チームと連携をしてシステムに求められる品質をの共通認識を作ることや、実装段階から不具合が起こりにくいように作業改善などに取り組むこともあります。

QAエンジニアとテストエンジニアとの違い

QAエンジニアと混同されがちな職種として、テストエンジニアの存在が挙げられます。

QAエンジニアは、システムやソフトウェアの品質管理・品質保証の業務（耐久性も含まれる）に対応するエンジニアです。
対してテストエンジニアは、仕様書通りに動作し、バグ・エラーなどの問題がないか検証するエンジニアです。
QAエンジニアの職務領域は検証業務だけではなく、より広範囲に渡ります。
QAエンジニアはテストエンジニアの業務範囲を包含した存在といえるでしょう。

ただし前提として、システム開発に関わる品質の担当は多岐に渡ります。
企業やサービスによっては QAエンジニアという名称ではなかったり、QAエンジニアの他にもシステム品質を管理する別のポジション（QAディレクター・SET（Software Engineer in Test）エンジニア等）があったりする場合もあります。

上記から、同じ QAエンジニアという名称のポジションであっても、企業や扱うプロダクトによって業務内容や範囲が異ることもあります。

QAエンジニアに必要なスキル

ここからは QAエンジニアに必要なスキルを6つ紹介します。

ソフトウェア開発全般のスキル

当然ではありますが、プログラミングやソフトウェア開発の流れ・工程・技法を知っておく必要があります。
具体的な内容をみていきましょう。

プログラミングについての知識

参画しているプロジェクトで使用している言語・フレームワークに関する知識が必要です。
実務経験があると、プログラミング実務に即した対応ができます。

ソフトウェア開発の流れ

ソフトウェア開発は、一般的に以下の流れで進行します。

• 要件定義
• 方式設計
• 詳細設計
• ソフトウェア構築
• テスト
• 保守・運用

各フェーズで何をするかが把握できていれば、スムーズに対応することができるでしょう。

ソフトウェア開発の技法

下記のようなソフトウェア開発の手法に関しての知識があると、プロジェクトの中でどんなところでエラーが起きやすいかといったことを考案できるため、効果的な技法を提案することが期待できます。

• ウォーターフォール
• アジャイル
• プロトタイプ
• スパイラル

上記に挙げたようなシステム開発手法についての知見があると良いでしょう。
必ずしも全ての手法に知見がある必要はありませんが、少なくともアサインされるプロジェクトが採用している手法については知識・経験共に備えていることが望ましいです。

テスト技法に関する知識

テスト技法の知識は品質担保に欠かせないスキルです。
QAエンジニアにとっては本領を発揮すべきポイントです。
適切なテスト技法を選択・使用することでテストを効果的に実施でき、結果的にプロダクト品質の向上に繋げます。

• ブラックボックス
• ホワイトボックス
• ユースケース
• 経験ベース

品質管理・品質保証に関する知識

開発工程全体の管理能力が要求され、開発現場によっては ISO などの知識も必要になります。
ソフトウェア開発に関連した ISO については、たとえば以下のような種類があります。

• ISO9001（品質管理システムの要件に関する国際標準）
• ISO12207（ソフトウェアのライフサイクルプロセスに関する国際標準）
• ISO14001（環境マネジメントシステム (EMS) の要件に関する国際標準）
• ISO29119（ソフトウェアテスティングに関する国際標準）

QAエンジニア参画にあたっての注意点

これまで QAエンジニアの役割について紹介してきました。
QAエンジニアは、システム品質を担保するために重要な役割を果たしますが、ただ参画させれば良いというわけではありません。
ここからは QAエンジニアがプロジェクトに参画するにあたって気をつけるべき点をみていきましょう。

システムを開発する分野に精通している必要がある

QAエンジニアは、これからシステムを開発する分野に精通していないと、品質管理・品質保証の役割を十分に果たせません。
言語や開発手法、システムの種類はもちろん、場合によってはシステムを活用する業界の慣習や法律といった知識に至るまで網羅していないと満足な品質担保が難しいこともあります。

QAエンジニアであれば誰でもいいのではなく、これからシステム開発を実施する分野に精通したQAエンジニアを参画させましょう。

システム開発の実務経験が要求される

いくら優秀な人材であるとはいえ、システムの開発経験がゼロでは、効果的なフィードバックはできません。システム開発経験を持つ人材をアサインするようにしましょう。
可能であれば、QAエンジニアの業務領域以外のシステム開発の業務についても、経験している方がよいでしょう。

優秀なQAエンジニア参画には相応のコストが必要になる

IT人材不足が指摘されている日本では、総じてエンジニアの採用コストは上昇傾向にあります。
ある調査※では、2016年～2021年までに QAエンジニアの平均年収は100万円以上上昇しています。

他のエンジニア職も上昇傾向ではありますが、比較しても QAエンジニアの年収上昇率は目を見張るものがあります。
上記の傾向からもQA参画には相応のコストを要すると考えた方がいいでしょう。

※参照元：「QAエンジニアとは？年収推移や将来性を転職ドラフトのデータから解説（新しいタブで開きます）」.転職ドラフト（参照：2023-9-22）

オフショア開発でもQAエンジニアは力を発揮

海外にシステム開発を依頼するオフショア開発（新しいタブで開きます）においては、システム品質に不安を抱えることもあります。
このような場面でも QAエンジニアのアサインで改善が図られる可能性があります。

近年は、オフショア開発拠点として人気の東南アジア諸国などのエンジニアも技術レベルはあがってきていますが、そうはいっても「人による」のが現実で、言語や文化、常識にに違いがある中で日本国内の依頼者側が求める品質のシステムを作ることは簡単ではありません。

しかし、オフショア開発に知見のある優秀な QAエンジニアが参画していれば、テストやルール、仕組みの構築といった方法でオフショア開発においても品質を担保できる可能性が高くなるでしょう。

実際に当社、スパイスファクトリーでもオフショア開発の品質担保のために QAエンジニアのアサインしています。機能単位でのテストで要件に沿った挙動をするかの検証はもちろん、コードレベルでのレビューや指導も行うことで品質の確保に取り組んでいます。

QAエンジニアはいらない説について

ここまでの内容で、QAエンジニアはシステム開発にとって重要であることをお伝えしてきました。
しかし Google検索などで「QAエンジニア」を検索すること、予測変換で「QAエンジニア　いらない」と表示されることもあります。
QAエンジニアはもちろんいたらいいけど、専属ポジションとして必須ではないのでは？といった声も聞かれます。

ここでは QAエンジニア不要論について考えていきます。

QAエンジニアは不要？QAエンジニアは誤解されることも多いポジション

システム開発におけるテストは必須であるものの、軽視されやすい工程でもあります。
不具合を見つけることは当然とみなされる傾向があり、1つ不具合を見つけたとしても、たとえば「営業職の社員が案件を受注した」のようなプラスアルファの価値を創造したような反応が得られることは少ないでしょう。
逆にたった 1つでも不具合を見逃してしまえば、マイナスの評価は受けるケースは多く、インシデントの影響が大きければ厳しく追及されてしまうこともあります。

マネジメント層や、開発部門以外の部署がこの記事で紹介したようなシステムの品質管理の重要性を理解していないと、軽視されてしまう可能性は否めません。
しかし、この記事で紹介してきた通り、システムの品質管理は経営にとっても大きなインパクトを持つ要素になっており、その需要を反映する形で 市場のQAエンジニアの給与も伸び続けています。

もちろん、開発規模やチームのサイズによっては専属の QAエンジニアではなく兼務のような形とする方が適切な場合もあるかと思いますが、その場合でもシステム品質管理の必要性・重要性が落ちることはありません。
このことからも QAエンジニアが不要と断じてしまうことは早計であるといえるでしょう。

アジャイル開発におけるQAエンジニア不要論

システム開発手法として近年注目されているアジャイル開発においては、素早く開発の PDCA をまわすためにオールラウンドなチームであることが求められます。
テストは専任のテスト担当者を設けて行うのではなく、状況に応じてチームメンバー全員が実施する体制となっているため、アジャイル開発において QAエンジニアは不要という認識の方もいらっしゃるでしょう。

たしかにアジャイル開発、とりわけスクラムの手法においての開発者は、テストや要件定義など専任の役割を設定してその業務だけをやればよいという体制ではなく、業務横断的に対応することが求められています。
その意味では「QA（しかやらない）エンジニアというポジションはアジャイル開発には不要である」という意見は正しいとも言えるでしょう。
ただし、その場合でも「QAエンジニアのみを担う」ポジションは不要という表現の方がより適切です。

各開発者が単なるテスターの役割を越えて、プロダクトの品質管理の業務も担っていく必要があるだけで、品質管理の重要性に変わりはありません。
むしろ、特定の人物に限らずチームメンバーに広く品質管理業務を担ってもらえるようにするためには、アジャイル開発チームに QAエンジニア経験のあるメンバーをアサインすることが大きなアドバンテージになると思います。
スクラムを採用しているプロダクト開発でも、QAチームを固定で設定して運用している事例（新しいタブで開きます）もあります。
絶対的な正解はない前提で、自社や自プロダクトの品質を最大化させるために必要な体制を構築していくことが求められているといえるでしょう。

QAエンジニアのアサインでお悩みの方はスパイスファクトリーへ

QAエンジニアは、デジタル時代のビジネスリスクを最小限に抑えるためになくてはならない存在です。
オフショア開発・アジャイル開発などあらゆる開発プロジェクトにおいて QAエンジニアの需要は今後も高まっていくでしょう。
スパイスファクトリーでは、QAエンジニアを参画させたフィリピンを拠点とするオフショア開発（新しいタブで開きます）や受託開発型のアジャイル開発（新しいタブで開きます）のサービスを提供しています。
システム開発にお悩みの場合は、ぜひ一度スパイスファクトリーにお問い合わせください。

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

参考文献

■参考書籍

• 吉山 慎二 著.『ゼロからわかるオフショア開発入門』（2020）.幻冬舎

■参考サイト

• エンワールド・ジャパン株式会社.QAエンジニアの仕事とは？仕事内容から必要な資格、向いている人の特徴を解説. 外資系企業の転職・求人エージェントならエンワールド・ジャパン.https://www.enworld.com/candidates/career-advices/useful-column/occupation/engineer/qa_engineer.html,（参照 2023-9-15）
• 株式会社パソナ.QAエンジニアとは？テストエンジニアとの違い・必要な資格について.Engineer Labo エンジニアラボ.https://x-tech.pasona.co.jp/media/detail.html?p=7334,（参照 2023-9-14）
• 株式会社翔泳社.プロダクトの品質はテストだけでは測れない――新規プロダクト開発における品質管理の考え方.Productzine.https://productzine.jp/article/detail/192,（参照 2023-9-20）
• 株式会社リブセンス.QAエンジニアとは？年収推移や将来性を転職ドラフトのデータから解説.転職ドラフト.https://job-draft.jp/articles/558,（参照 2023-9-20）
• Qiita株式会社.QAエンジニア.Qiita.https://qiita.com/jun2014/items/32ec77be1056f546aada,（参照 2023-9-25）