IT技術が進化しビジネスのスピードが加速するなか、システムやソフトウェアの開発環境も多様化しています。なかでも注目されているのがスクラム開発です。ただし、その用語を聞いたことがあっても、他の開発方法とどのように違うのかわからないという方もいるのではないでしょうか。本記事では、アジャイル開発やウォーターフォール開発との違いを押さえたうえで、スクラム開発の特徴やメリットをわかりやすく解説していきます。

スクラム・アジャイル・ウォーターフォール開発の違いと位置づけ

アジャイル開発とは開発スタイルの総称で、その中の代表的な手法の1つがスクラム開発です。

アジャイル開発とは、短いサイクルで設計、開発、実装、テストをすばやく繰り返し、優先順位の高い機能を順番にリリースしながら、全体の完成を目指す手法です。開発を小単位に区切り、各機能をユーザー側でテストすることで、開発途中での仕様変更も柔軟に対応できます。

アジャイル開発の詳細については、「アジャイル開発とは何か？変化に即応してユーザーの要望を最大限実現する手法とは」もご覧ください。

スクラム開発とは、アジャイルの考え方を、ラグビーのスクラムのようにチームを組んで役割やタスクを分散させつつ、コミュニケーションを重視したフレームワークのことです。

一方、ウォーターフォール開発とは、アジャイル開発と対比される従来の開発方法を意味します。あらかじめ立てた開発工程を計画通りに実行していく開発方法で、進捗状況は把握しやすいですが、途中で仕様変更しづらいという特徴があります。

つまり、アジャイル開発の一種であるスクラム開発とは概念が大きく異なるのです。

ウォーターフォール開発の詳細については、「システム開発の上流工程とは？起こりうるリスクや管理の重要性を解説」もご覧ください。

スクラム開発の論理と3つの柱

スクラム開発は、1990年代に米国の技術者によって生み出され、「スクラムガイド」で定義されています。これをもとに特徴を紹介していきましょう。

スクラム開発の論理

スクラム開発は、経験から生まれる知識と観察に基づき意思決定する「経験主義」と、無駄を省き本質に集中する「リーン思考」に基づいています。スクラムが機能するのは、それらの論理をもとにした「3つの柱」を実現しているからでしょう。 

3つの柱

• 透明性
  開発や作業内容はチームメンバーやその作業結果を受ける人に見えるようにしておくことが大切です。透明性によって検査が可能になるため、それが欠けた状態では誤解を招き、無駄なものとなる恐れがあります。

• 検査
  常に事案を検査し、問題の発見・解決を繰り返していきます。スクラム開発は変化を引き起こすことを前提としているため、検査には適応が大きなポイントです。

• 適応
  検査結果への対応はもちろん、作業中も適宜、手法やプロセスの見直しが必要です。スクラム開発では、検査によって新たに学んだことに対し、即時に適応することが期待されています。

スクラム開発のルール「3・5・3」

スクラム開発におけるルールは、「3つの役割」「5つのイベント（うち1つは任意）」「3つの作成物」といわれています。具合的に説明していきましょう。

3つの役割とは

• プロダクトオーナー（PO） 
  要件を定義し、最終的にソフトウェア開発者の成果を評価するプロジェクトの責任者です。必要な機能の選択や機能優先順位決定などのビジョンを考え、チームのメンバーに説明、共有します。スケジュールや予算管理なども行います。

• スクラムマスター（SM）
  スクラムがうまく回るように全体を調整するチームリーダーの役割です。チームで出た課題を解決するため、外部交渉やメンバーとの相談でプロダクトを円滑に進めるため、調整していきます。

• 開発メンバー
  プロダクトの品質や計画・専門性に責任を持つ開発者です。

チーム構成は通常10人以下で、人数が少ないほど生産性が高い傾向にあるといわれています。

5つのイベントの概要と目的

スクラムイベントとは、スクラム開発を実践するうえで必要なミーティングで、プロダクトの検査と適応の機会となります。スプリントと呼ばれる、アウトプットするまでの一定期間のなかで、行っていきます。「スクラムガイド」は4つのイベントとして定義していますが、今回は「リファインメント」という作業も加え、「5つのイベント」として流れを見ていきましょう。

1. スプリントプランニング

スプリントのゴールとその達成のために必要な作業を計画するイベントです。アウトプットまでの期間に何をするのかをチームで話し合います。チームのビジョンを明確にして共有するためにも、最高責任者であるプロダクトオーナー（PO）と開発メンバーの出席は必須です。この時点では、スクラムマスター（SM）は任意参加で構いません。このとき、スプリントバックログ（スプリント期間中にチームが取り組む作業アイテムを明確にするための手段）を作成し、アイテムの洗い出しをしておきます。

2. デイリースクラム

スプリントゴールが達成できるか、進捗を検査するためのイベント。チームの問題や課題を早期発見するためのものですので、開発メンバー主体で行います（PO、SMの参加は任意）。原則としては、毎日決まった時間に同じ場所で手短に行うのが良いとされています。業務の進捗状況や問題点、解決したことなどを共有。必要に応じて、この後に関係者を絞って話し合います。

3. リファインメント  （任意）

プロダクトバックログアイテム（以下PBI）を明確にするイベントです。PBIとは、開発チームが目標を達成するために、必要となるアイテムやタスクに優先順位をつけてリスト化した一覧に登録されているタスクのことです。チーム内の認識を合わせることを目的としているため、POと開発メンバーの出席は必須です （SMの参加は任意）。期間中、任意のタイミングで開催され、PBIの内容や見積もり、優先準備などの内容を確認し、詳細化します。

4. スプリントレビュー

スプリントの成果を確認し、結果を原因に反映させて調節していくイベントです。POと開発メンバーが戦略を練るために行います（SMの参加は任意）。最終段階の前に実施し、フィードバックをもとに話し合い、今後に向けた改善策を見つけていきます。

5. レトロスペクティブ

スプリント中の活動や過程を振り返るイベント。チーム全員が参加し、問題を改善し、良かった点や反省点を共有し、次回に生かしていきます。最後に実施され、この完了をもってスプリントが終了します。

3つの作成物

スクラム開発を実施するうえで作成するものが3つあります。それぞれ見ていきましょう。

• プロダクトバックログ
  プロダクトの開発や改善に必要なタスクを優先度順に並べた一覧。チームのメンバー全員で共有することで、誰がどのような作業内容をするかが確認でき、ゴールを共通認識できます。

• スプリントバックログ
  スプリントで実施するプロダクトバックログの項目を実行可能なタスクレベルにまで詳細化したものです。開発メンバーで日々チェックすることで、ゴールが達成できるかを検査し、リスクに適応するための行動計画を立てていきます。

• インクリメントのための完成の定義
  「スクラムガイド」では、完成の定義とは、プロダクトの品質基準を満たすインクリメント（プロダクトゴールに向けた具体的な踏み⽯）の状態を示した正式な記述とされています。つまり、完成の定義を満たすことで、何をもって作業が完了、完成したか、チーム全員が共通認識できるようになります。スクラム開発を始める前に作成しておくことで、メンバーによって完成の精度が異なるといったことを避けられるでしょう。

スクラム開発のメリット

スクラム開発をすることで、どのようなメリットが得られるでしょうか。

問題点を早期発見しやすい

スクラム開発は、チーム内でのミーティングで常に目標や進捗状況などを確認・共有する透明性を特徴とします。これによって、問題点を早期に発見しやすい体制にあり、問題が起こるたびに素早く改善・軌道修正していけるため、プロジェクトがスムーズに進捗しやすいでしょう。

生産性の向上が期待

目標が明確であることから、各メンバーには指示待ちの姿勢がなく、主導的に仕事を進めていくため、作業が効率的です。ひいては生産性の向上が期待できるでしょう。各スプリントで動作可能な機能を開発し、必要な機能がそろったタイミングでリリースできるため、短期間で成果を出しやすい傾向にあります。

仕様変更に柔軟な対応

アジャイル開発の特徴である柔軟性を踏襲しており、プロジェクトの途中での急な仕様変更に対応しやすいこともメリットの1つです。さらにスクラム開発のスプリントは短めに設定されていることから、成果物に対するフィードバックを次のスプリントに反映させ、仕様変更に対応していけるでしょう。

作業工数の見積もりが高精度

スプリントごとに作業工数を予測するため、必然的にプロジェクト全体の作業工数の見積もりが高精度になっていきます。結果、全体の納期が比較的、短縮されやすい傾向にもあるようです。

まとめ：スクラム開発の特徴を理解して実施を

スクラム開発はその柔軟性から自由度が高く、後に更新が必要となりそうなシステムに適しているといえるでしょう。しかし、更新をあまり要しないものや納期を確定させたいものなど、案件によっては他の開発方法が向いている場合があります。スクラム開発とはどのようなものか、その特性を理解したうえで実施することが大切です。

日本では政府の推進もあり、ビジネスにおけるDXの重要性が高まってきました。多くの業界でこれまでの常識が通用しなくなっている中、デジタルの力を活用したビジネスモデルの変革が求められています。こうした流れの中で、システム開発についても重視されるポイントが変わってきています。システムの開発にはいくつか形式がありますが、その中でも今回の記事では、ラボ型開発に焦点を当てて紹介していきます。

ラボ型開発とは

ラボ型開発とは、特定の案件に対して専用のチームを作り、同じチームメンバーで開発を行うことを言います。一定期間、開発人員を固定することで、メンバーがシステムに習熟しやすくなり、ノウハウの蓄積やチーム内での情報共有が容易になるといった効果が期待できます。また、請負開発と違い、契約期間内であれば追加費用なしに仕様変更や修正が可能なことも、ラボ型開発の利点です。これに加えて、請負開発では1つのシステムしか開発対象にできないのに対して、ラボ型開発ではメンバーの固定が確保されているため複数のシステム開発を担当できるという点も、特にSIerのような業態にとっては魅力でしょう。

ただし、一定期間専属のメンバーを確保するため、案件数がそれなりにないと費用が割高になることがあり注意が必要です。

なお、こうしたラボ型開発の課題を克服するためによく取られるのが、海外に開発を委託するオフショア開発という手法です。特に人材確保の面で大きなメリットがあるのですが、これについては本記事の後半で詳しく紹介します。

→　オフショア開発については、こちらの記事もご参照ください。

また、ラボ型開発は同じメンバーで開発するため、小規模な単位で短期間に開発・テスト・リリースを行い、かつ仕様変更が頻繁に発生するアジャイル開発と相性が良いことでも知られます。

ラボ型開発を成功させるには

ラボ型開発を成功させるためには、どのようなことが必要になるのでしょうか。成功のためにキーとなるポイントについて見ていきます。

事業部と情報システム部門間での連携

よく見落とされがちなのが、開発したシステムの最終的なオーナーとなる事業部との連携が鍵となるという点です。特に、事業部が開発するシステムによって「何を実現したいのか」というビジョンを、情報システム部門がよく理解することが重要と言えます。これには、開発を担当する情報システム部門は事業部が行っている業務の背景や考え方を理解することも求められるということです。システムを開発する側は、どうしても自動化や無駄をなくすことに目がいきがちですが、事業部としてはUIが一番重要だ、ということもあります。

事業部側としてやれることは、指示系統の統一が肝心です。情報システム部門との窓口が複数あると、開発についての優先事項や実現したい仕様がぶれてしまい、頻繁な仕様変更につながってしまう可能性もあるためです。

また、ラボ型開発において、一定期間固定されたメンバーが習熟した環境で開発プロジェクトを成功させるためには、スモールスタートから開発を始めて、コアメンバーとのコミュニケーションを確立していく方法が有効です。

最初の案件としてPoCで実現性を検証

ラボ型開発の力を引き出すためにも最初の開発プロジェクトとして行いたいのが、PoCです。大規模な開発に取りかかる前に、プロトタイプを作ってシステムの実現性を検証する手法をPoC（Proof of Concept）と呼びますが、ラボ型開発と特に相性の良い工程です。ラボ型開発でアサインされたメンバーの経験値が高ければ、問題点の洗い出しを高い精度で行うことができ、目的とするシステムの大枠を早い段階から見ることにも寄与します。

コミュニケーション不足を補う

他の手法と同様に、ラボ型開発でもコミュニケーション不足が開発の失敗につながることがあります。こうした事態を防ぐためにも、事業部がシステムを開発しようとする背景や目的について、ラボ型開発チームでもあいまいにせず、不明な点はどんなことでも確認することが大切です。

また、多くの人が意見をバラバラに述べるとまとまらなくなるため、開発チームや事業部での取りまとめ役をあらかじめ選定しておくことも忘れずに行いましょう。

ラボ型開発はオフショア開発がおすすめ

先述の通り、ラボ型開発を行うなら、オフショア開発がおすすめです。その理由について、より詳しく見ていきましょう。

• 人材確保が容易

ラボ型開発は、専属の開発チームを作ることがポイントですが、そこで課題になってくるのが、いかに人員を確保するかという点です。オフショア開発を委託する先は、日本よりも若く優秀なIT人材が豊富にいる海外です。このため、優秀なエンジニアを一定期間囲い込むことが、日本よりも容易になります。

• コスト低減

オフショア開発がおすすめである2つ目の理由は、人件費の安い海外に開発を委託するため、ラボ型開発でのデメリットになりやすいコストについても、国内と比較して大幅に抑えられることです。

オフショア開発の人気国、ベトナム

近年、オフショア開発を委託する先として人気なのが、ベトナムです。その理由としては、以下のような点が挙げられます。

• オフショア実績の豊富さ

最近では、AI（人工知能）やIoTといった高度な技術を要する開発案件も増えており、こうした技術に知見のあるエンジニアの確保も可能です。また、オフショア案件の増加に伴って、開発品質も上がってきていると言われています。

• 優秀な人材の豊富さ

ベトナムは、国策としてIT人材の育成に力を入れており、IT系の技術者は年間5万人輩出されていると言われています。層が厚いことだけではなく、最新の技術についても知見がある優秀なエンジニアを確保できる、という点でもベトナムが他の国よりもオフショア先として有利なポイントです。

→　ベトナムでのオフショア開発については、こちらの記事もご参照ください。

ラボ型開発をオフショアで行う際の懸念点

ラボ型開発をオフショア開発で行う場合は、日本とオフショア先の国とのコミュニケーション方法や文化の違いに考慮する必要があります。特に仕様書は、あいまいなところをなくし細かいところまで明文化する必要があるでしょう。ラフな要求を出してデモを見せてもらい、理解力や技術力をチェックし、それに合わせて指示の行い方に注意を払うといった、開発メンバーの実際の能力をチェックすることも重要です。

→　オフショア開発におけるキーとなるブリッジSEについては、こちらの記事もご参照ください。

まとめ：ラボ型開発はオフショア開発が最適

ラボ型開発は、顧客のために専属のチームを作り開発できる形態です。一定期間、同じエンジニアによる開発が可能となり、顧客がSEやプロジェクトマネージャーと直接コミュニケーションを取りながら、形を作り上げていきます。専属チームを作ることから、人材確保が課題となることもある手法ですが、海外に委託するオフショア開発を取ることで効果を最大化できます。オフショア先としては、優秀な人材が多く高度な開発も可能なベトナムが人気になっています。ラボ型開発でオフショア開発を考えている場合には、ぜひ検討してみてはいかがでしょうか。

また、本資料ではラボ型開発を中心に失敗しないコツをまとめましたが、その他にもオフショア開発一般という観点で失敗を防ぐための方法がいくつかあります。下記の資料にてご確認いただけますので、是非ダウンロードのうえ、ご活用ください。

失敗から学ぶオフショア開発の成功法

お問い合わせページ

事業環境の変化のスピードが加速する昨今では、システムを開発する環境も変化を余儀なくされています。その中で注目されているのがアジャイル開発と呼ばれる開発手法です。本記事では、従来の開発方法と違い、変化に柔軟に対応し、ユーザーの要望を最大限に実現することを目的とするアジャイル開発について解説します。

アジャイル開発とウォーターフォール開発の違い

アジャイル開発とは、短いサイクルで設計・開発・実装・テストを繰り返し、優先順位の高い順に各機能をリリースしていき、全体としてのシステム完成を目指すといった開発手法のことです。「アジャイル（agile）」とは英語で「俊敏な」といった意味ですが、開発期間を短く区切って各機能をユーザー側でテストしてもらうことで、途中の仕様変更にも柔軟に対応できるようになります。2001年に米国のエンジニアによって『アジャイルソフトウェア開発宣言（Manifesto for Agile Software Development）』がまとめられ、考え方や実践の詳細が示されました。アジャイル開発は、必要なものを必要なときに供給し製品を早く市場に供給するという、トヨタ自動車の生産方式「Toyota Production System（TPS）」が源流になっています。

アジャイル開発が対比される、いわゆる従来型の開発手法はウォーターフォール式と呼ばれます。こちらは、最初にしっかりと要件定義を固め、設計・開発・実装・テスト・リリースという工程を滝が流れるように一つひとつ確認しながら行うものです。プロジェクト全体の進捗状況の把握は容易になりますが、次のフェーズに進むと後戻りができないのと、すべての工程が終了してはじめてシステムが使えるため、仕様変更や切り戻しが入った場合は、非常に大がかりになってしまいます。

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

アジャイル開発は、細かい仕様変更に強いといったメリットがあるものの、デメリットもあります。ここではメリットとデメリットについて比較してみます。

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

アジャイル開発は、優先度をつけ必要な機能を素早くリリースできるため、スピード感を持って開発できる点が魅力です。徐々に変化を取り入れられるため、既存システムやWebベースのアプリなどの部分的な変更といった、小さい範囲から着手し、広げていくといった方法もできます。最初にリリースした機能のユーザー側の反応を確認してからプロジェクトを進められるため、ユーザー側での新しいシステムに対する抵抗を少なく抑えるといった効果もあるでしょう。

こうした特徴から、アジャイル開発はWebサイトのUIや使い勝手を変更するような場合に向いています。こうした案件が多くなる分野としては、eコマースやモバイルアプリの開発で力を発揮する形です。

アジャイル開発は、仕様変更を前提として柔軟に修正を行っていく開発手法ですが、案件に対して一定期間専属のチームを作るラボ型開発と組み合わせれば、より効率を上げられるでしょう。チームが固定されているラボ型開発であれば仕様変更が発生した場合でも、追加費用がなく対応できるため、コストを抑えられます。また、同じメンバーで対応するためシステムへの習熟によるスピードアップという面でも、効果が期待できます。

→　ラボ型開発については、こちらの記事もご参照ください。

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

アジャイル開発は、ユーザーとよくコミュニケーションを取って顧客の要望を反映させようという開発姿勢なのですが、これがデメリットになってしまうこともあります。特に、コミュニケーションを密に取った結果として、あまりにも多くの仕様変更をしてしまう、といったパターンです。

根本的な原因としては、開発側での要件理解が不十分なことと、事業部側でもシステムへの理解が乏しく、提案された内容から成果物のイメージが正しくできていないことが考えられます。アジャイル開発の利点は、顧客からのフィードバックによる改善を重ねながらシステムをよりユーザーの要求に近いものに仕上げる工程にあります。しかし、前述のように根本的な部分でのコミュニケーションが不足していると、何度も修正して工数が膨れるだけでユーザーが満足するシステムができないという悲劇が起きてしまいます。

また、修復や手戻しが増えるにつれ、コミュニケーションがより複雑になり、ユーザーの開発側への信頼が薄れてくることもあり得ます。このような事態を避けるためにも、最初から顧客が実現したいビジョンを明確にしておくことが大切です。

アジャイル開発の方法

アジャイルで用いられる開発方法を紹介します。代表的なものにスクラム開発、XP（エクストリームプログラミング）、FDD開発があります。

スクラム開発

スクラム開発はアジャイル開発の代表的な方法で、コミュニケーションに重きを置いたフレームワークです。この方法では、プロジェクト全体をスプリントと呼ばれる1～2週間の小単位に区切り、その中で計画・設計から実装・テストまでの作業を進め、各機能を実現していきます。大体3～8人単位でチーム編成を行い、チーム内でラグビーのスクラムのように一丸となってコミュニケーションを密に取り合い、開発していきます。

スクラム開発は、メンバーにプロダクトオーナー（PO）やスクラムマスター（SM）といった役割が明確に与えられ、チーム内で密にコミュニケーションをとることが求められます。このため、先にも挙げた一定期間同じメンバーで開発するラボ型開発との相性が非常に良い手法です。

XP（エクストームプログラミング）

XP（エストリームプログラミング）は、冒頭でも紹介した『アジャイルソフトウェア開発宣言』の提唱者の1人であるケント・ベック氏により、1999年に考案された開発方法です。柔軟さ、簡潔さに重点を置いた開発方法で、アジャイル開発の先駆けになったものと評価されています。コミュニケーション、シンプルさ、フィードバック、勇気、尊重という5つのコンセプトを柱にしており、さらに反復やペア・プログラミングといった細かなプラクティスを4カテゴリに分けて具体的な開発方法が定義されています。

FDD開発

FDD開発は「Feature Driven Development」の略で、「ユーザー機能駆動開発」とも呼よばれるものです。この手法では、最初に全体リストを作り、そこからフィーチャーリストを構築。リスト化したフィーごとに計画・設計と開発プロセスを進めていきます。その名前にある「フィーチャー」とは、ユーザー視点で見た各機能のことをと呼んでおり、顧客にとっての価値に重点を置いた開発方法です。ユーザーでテストが可能な最新状態のデモ機を用意しておく、プロジェクトの内部・外部に向けて見える形で進捗を行う、など顧客にとって何が行われているのかを把握できるように配慮されます。

アジャイル開発をオフショア開発で行う際のポイント

アジャイル開発は、開発を海外に委託するオフショア開発とも相性が良いものです。

実施するにあたって注意しておきたいのは、短いサイクルでの開発と修正が繰り返されるため、顧客・メンバー間でのコミュニケーション頻度が高くなるという点です。オフショア開発を委託するチームの開発知識・実績・システムへの理解といった面で高いレベルが求められることはもちろんですが、そうしたチームであってもコミュニケーションの取り方によって、成果物の品質が変わってきます。デメリットとしても挙げたように、コミュニケーションの課題から修正を繰り返し工数ばかりが膨れる事態は避けなければなりません。このためにも、顧客を含め関係者を巻き込んだシステムの動作確認を行う環境を用意できるかどうか、顧客側での指示系統が整っているか、といった点を確認しておきましょう。

→　オフショア開発については、こちらの記事もご参照ください。

オフショア開発では、委託する国について迷うこともありますが、近年オフショア先として人気が高いのがベトナムです。ベトナムは国を挙げてエンジニアの育成を行っているため、若く優秀なIT人材の確保が容易なこと、最近ではAIやIoTといった高度な開発の実績が増えているという点で注目を集めています。また、日本語学習者が多いという点も魅力的です。

→　ベトナムでのオフショア開発については、こちらの記事もご参照ください。

まとめ：柔軟性の高さが魅力アジャイル開発

短期間で必要な機能を開発し、仕様変更にも柔軟に対応可能なアジャイル開発は、変化のスピードが速い現代のビジネスにあった開発手法です。この手法を成功させるためには、コミュニケーションが鍵となるため、コミュニケーションがしやすい環境づくりが大切になります。また、特に開発側での人材確保という課題を解決するためにも、相性の良いラボ型開発やオフショア開発といった手法と組み合わせるのが有効と言えるでしょう。

お問い合わせページ

PoC（Proof of Concept）とは、概念実証とも言われる開発方法で、システムの実用化が可能かどうか、プロトタイプを作成して検証するものです。実際に開発に入った後に、中止になることを避けるためにも用いられます。PoCを成功させるために知っておきたいポイントについて解説します。

システム開発にPoCが必要な理由

PoCは、「開発中のシステムが実際に稼働するのか」「（見込んでいる）効果があるのか」といった点について、費用と時間をセーブしながら検証するために行われます。

システムを実際に導入するかどうかを決めるにあたっては、自社の事業にメリットがあることが重要です。しかし、通常の開発手法の場合、そうした効果を確認できるのはシステムが稼働してから、すなわちほとんどシステムが完成に近づいた段階ということになります。ここで仮に「見込んでいたメリットが得られない」という判断がされたとしても、すでに開発は終わりに近づいており、費用も時間も無駄になってしまいます。

こうした事態を防ぐため、事業に対してどのようなメリットを届けられるのか、初期段階で試験的にシステムを動かして確かめよう、というのがPoCです。この目的のために、PoCはシステムの実現性が検証するのに十分な機能を載せたプロトタイプを準備する必要があります。

また、PoCでは顧客を巻き込むため、顧客が何を求めているのか、というニーズをより的確に把握できます。顧客から得られたフィードバックで問題点が明らかになれば、それに対する改善を行っていきます。そして、設定したターゲットに到達したら、実際のシステム開発に取りかかります。スムーズにPoCを完了させて次のステージに進むためにも、ここまでできればほぼクリアという指標を設定することが重要です。

ちなみに、PoCは小規模な予算で実施し費用対効果を見極められるので、小規模市場に導入をして市場性を確認するプレマーケティング的な用途にも使えるでしょう。あるいは、スタートアップにおいてシステム開発資金調達のためのプルーフにするなど派生的な目的も満たせます。

なお、PoCは、短いサイクルで開発・テスト・リリースを繰り返すため、仕様変更に柔軟なアジャイル型開発と相性が良い手法です。

→　アジャイル開発については、こちらの記事もご参照ください。

PoCの課題

PoCを行うにあたって一番問題となるのが、PoCばかりを繰り返して実現に結びつかないことです。

これについてはさまざまな原因が考えられますが、実際の開発フェーズへとGoサインを出す事業部との連携が関係していることもあります。このため、PoCの次のステージに移行するためにも、請負開発のようにシステム部が一方的に進めるのではなく、プロジェクトにシステムを利用する事業部を巻き込んでいくことが大切でしょう。実際にシステムの責任を持つ事業部からの理解を得ることが、肝心になるためです。

事業部の中にはITに明るくない人がいる場合もあります。そのような場合は、システム部がイメージしやすく動作例を上げて説明するようなフォローアップ体制も重要でしょう。

また、一般的に新しいシステムの導入は、既存の業務プロセスになじみのある社員から反発を受けやすい傾向にあります。そうした際には、既存のシステムに近い形で小さい範囲からPoCを実施する方法が有効です。自社がターゲットとしている市場にシステムがどのように浸透し、現状と比べてどのぐらい多くの利益をもたらすのかといったデータを示し、分かりやすい形で説明できると理想的です。既存のシステムに近いほうがイメージを持ちやすく、小さい範囲で成功させて新システム導入までの道筋を作るという狙いもあります。

課題としてはほかにも、PoCを繰り返すことで予算を使い切ってしまい、最終的なシステム開発に至らないというもののもあります。これは最初に検証したい課題を明らかにし、確実に検証できる機能をPoCに入れておくこと、さらにスピードを持ってプロジェクトを進められる精鋭メンバーをPoCにあてるといった対策で防げると考えられます。

PoC開発で取り入れたい手法

それでは次に、PoCで取り入れたい開発手法について見ていきましょう。

MVP開発

1つ目がMVP開発です。MVPとは「Minimum Viable Product」の略で、実行が可能な最小の製品を意味します。システムの実行にあたって、立てた仮説を検証できるだけのミニマムな単位での開発を行うもので、導入可能かどうかを最小限のコストとリスクで実証できるものになります。まだシステムのイメージが固まっていない場合に、システム側からユーザーへ提案を入れイメージを固めるためにも役立ちます。

実際の環境でテストするDevOps

2つ目は、DevOpsと呼ばれる手法です。DevOpsとは「Development（開発）」と「Operation（運用）」を組み合わせた言葉です。

この手法は、ユーザーからのフィードバックをもとに、問題点をピックアップし、必要な機能を加えてシステムを強化していくといった形で進められます。開発担当だけでなく運用担当者も一緒になって開発に携わっていくため、実際の環境に近い形で開発・テスト・運用が行え、さらに開発サイクルを縮められるというメリットがあります。早期にシステムの実現性を確認するために有効です。

オフショア開発でPoCを成功させる

PoCの要件を考えていくと、海外に開発を委託するオフショア開発という選択肢も浮かんできます。それは、オフショア開発では優秀な人材を日本国内よりも容易に確保できること、世界中の多くの企業からオフショア開発を受けている国であれば、経験や知識に期待できることなどからです。

具体的にオフショア開発でPoCを行うメリットについては、以下のようなことが挙げられます。

第一に上げられるのは、オフショア開発における人材の豊富さです。オフショア開発では東南アジアをはじめとした海外に開発を委託しますが、特に人気の国では優秀なIT人材が多くいます。このため、PoCを行うにあたり理想である、一定期間同じスタッフでチームを組み開発を行うラボ型開発の体制が取れます。専用のスタッフで開発できることは、短期でコストを抑えながらスピーディーに進めたいPoCに最適です。改修のプロセスを経ながら開発スタッフが徐々にシステムに習熟していくため、修正や問題点の発見を素早く行ったりバグを減らしたりなどの効果を期待できます。

また、PoCでは切り戻しが多くなることが予想されるため、そういった場合に備えて人員を確保できるオフショア開発が向いているでしょう。

これに加えて、1つ目は、自社の業界（自動車、医療、食品業界など）とオフショアされている地域で請け負っているシステムの開発が同じ業界だった場合、共通点が多いため、スタッフがシステムに習熟するスピードが早いことです。オフショア開発は、Webサービスを得意とすることが多いため、同じくWebサービスを利用する業界であれば、さらに親和度が高いでしょう。

→　オフショア開発については、こちらの記事もご参照ください。

まとめ：PoCで事前に課題を洗い出し、システム導入を成功させる

PoCはシステムの実現が可能かどうかを検証するために欠かせない開発手法です。

システム導入を成功させるためには、開発されるシステムがどのように日々の業務に役立つのか、事業部で具体的にイメージしてもらう必要があります。そのイメージを作り、新システム導入をスムーズにするためにもPoCは有効です。また、PoC実施に当たっては、コストを抑えて優秀な人材を確保しやすいオフショア開発がおすすめです。

お問い合わせページ

新型コロナは収束に向かっていますが、依然として非対面型・非接触型ビジネスモデルへの転換が求められています。

これらの新たなビジネスモデルを展開してくには、ITの活用は不可欠なものとなります。

完全な対面型からのビジネスモデルの転換には大規模なシステム開発も必要となりますが、そうした開発では開発手法の選択が重要となります。

前回、オフショア開発の失敗を限りなく減らす！外注にあたってのチームの考え方！で開発手法についても簡単に言及しました。

今回はウォーターフォールとアジャイルの二つの開発手法を中心に開発手法について掘り下げて解説します。

1. ウォーターフォール型開発

ウォーターフォール型開発とは

ウォーターフォール型開発は、1970年ごとに初めて誕生した最も古い開発手法の一つです。

古典的な開発手法ではありますが、今でもその活用が広がっています。

日本では工程毎に異なる企業が開発を行うというIT業界の構造上、特に広く受け入れられています。

ウォーターフォールを日本語に直訳すると、「滝」という意味です。

ウォーターフォール型開発は滝のように「要件定義」、「基本設計」、「詳細設計」、「実装」、「テスト」、「運用」という流れを段階毎に完了させます。

段階毎の成果物を確認し、前の工程に戻らないことを前提とすることがウォーターフォール型開発の特徴です。

ウォーターフォール型開発のメリット

①計画の余裕を持たせやすい

ウォーターフォール型開発では、要件を確定してから、開発に着手します。

そのため、開発内容や作業全体を考慮して、スケジュールを決めることができます。

無理がないようにタスクを割り振り、進行計画に余裕をつけるケースも多いです。

②予算と人員の計画が立てすい

ウォーターフォール型開発では、工程毎に明確に作業が定義されるため、プロジェクト開始前に「各段階で何が必要か」、「その時、何人必要か」が明確に定まります。

そのため、プロジェクト開始前の準備時間でチームメンバーを工程に合わせて手配できます。

また、工程毎に明確に作業が定義されるため、人員の入れ替えが発生しても簡単に引き継げるため、プロジェクトの進捗に影響を与えずに柔軟に対応することも可能です。

③設計が上手くいけば、不具合を防げる

ウォーターフォール型開発では、開発開始前にシステム全体の機能を設計してから順次に開発を進めていきます。

ソフトウェア開発では途中で追加する機能が既にある機能と矛盾し、不具合を起こすことも少なくありません。

ウォーターフォール型開発では、全体の機能設計を固めてから開発するため、設計の段階で不具合を考慮することが可能です。

ウォーターフォール型開発のデメリット

①準備時間が長い

要件定義や設計が完了しないと開発に進めないことがウォーターフォール型開発の特徴です。

これらが完了して、はじめて具体的な機能が定まり、タスクに落とすことができます。

そのため、実際にプロジェクトを開始するまでの準備時間は必然的に長くなります。

②柔軟性が足りない

ウォーターフォール型開発は、仕様変更や工程戻りが起こらないことが前提です。

しかし、どんな周到な計画でも全ての問題を予測しきれません。

プロジェクト実施時に想定外の問題が発生して、仕様変更や手戻りが起こると計画全体を見直す必要があります。

また、問題は起きずとも、ユーザーの要望、アイディアが途中で変わることも起きえます。

そのため、ウォーターフォール型開発では、開発途中での仕様変更や追加対応が難しいことを考慮する必要があります。

③成果物の確認がしにくい

上記でも述べた通り、ウォーターフォール型開発では各工程が順次進められるます。

そのため、イメージしていたものと実際の動くもののがずれているかどうかは、全ての工程が完了した後となります。

最悪の場合、ユーザーが求めるものと全く異なり、一からやり直さなければなりません。

そうすると追加費用と開発期間の延期でトラブルになることもあります。

ウォーターフォールが向いているシステム

NTQは下記3点の条件を満たすケースでウォーターフォール型開発をおすすめしています。

・要件が明確

・予算の制約が厳しい

・スケジュールのズレが許せない

ウォーターフォール型開発は工程の手戻りが許されないため、特に一つ目の条件が重要です。

社内の基幹システム、業務システムなどは既存の業務にのっとってつくられることで要件が整理しやすいため、また予算の制約が大きくスケジュールを厳格に定める必要がある大規模な開発となるため、ウォーターフォール型開発に向いています。

業界としては適切な人員の手配、綿密な管理が求められる金融、メーカー系のお客様が良くウォーターフォール型開発を活用しています。

また、レガシーシステムをマイグレーションする場合、すでに必要な機能が明確に決まっていますので、ウォーターフォール型開発を活用することで最適な予算で進行できます。

2. アジャイル型開発

アジャイル型開発とは

アジャイル型開発は2001年にアメリカで生まれました。

17名の技術者やプログラマーに提唱されたアジャイル型開発は現在、アメリカでは主流の開発手法となります。

アジャイルという単語の意味は「素早い」「機敏な」「頭の回転が速い」です。

その意味の通り、アジャイル型開発は計画、設計、実装、テストという開発工程を短いサイクルで何度も繰り返して開発を進め、短期間でリリースを目指します。

機能毎に小さいサイクルで開発を繰り返し、開発したものを最後に統合して、1つのシステムを形成します。

そのため、優先度が高い重要な機能から着手し、途中で柔軟に仕様変更ができます。

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

①高い柔軟性

アジャイル型開発では、計画からテストまでの工程を短期間で何度も繰り返すため、計画段階で綿密な仕様を決めなくても開発に着手できます。

開発途中でユーザーとコミュニケーションをとりながら、仕様変更にコスト負担なく対応できます。

そのため、ユーザーのニーズと合致したシステムになりやすく、ユーザーの満足度が高いシステムの開発がしやすくなります。

②開発期間の短縮可能

アジャイル型開発は、短期間で実際に動く機能をつくりながら開発を繰り返すため、要件がおおまかにしか決まっていない段階でも開発が開始できます。

また、アジャイル型開発では、1週間から4週間を目途に１つの機能をリリースするため、すぐにシステムのユーザーの確認が取れます。

開発の途中でユーザーのフィードバックに基づいて修正することもでき、後戻りが少なくなります。

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

①開発の方向性がブレやすい

アジャイル型開発では、全体の仕様を完全に固めずにフィードバックを得て修正を繰り返すことを前提とします。

そのため、改善、変更、追加のフィードバックを大量にさばくことになる可能性が高いです。

大量のフィードバックを受けるなかで、当初の計画からズレていく可能性があります。

②納期遅延がしやすい

アジャイル型開発は全体の詳細計画を設定せず、開発チームのペースで開発を進めることになることも多々あります。

そのため、進捗の管理がしにくくなり、納期に遅れる可能性もあります。

納期遅延を防ぐためには、ある程度、厳密な進行スケジュールを設定したほうがいいでしょう。

アジャイル型開発の向いているシステム(NTQの事例)

アジャイル開発は、要件が曖昧なプロジェクト、または開発の途中で仕様の変更や追加が予想されるプロジェクトに向いている手法です。

例えば、モバイルアプリ、WEBアプリなどユーザーの反応を確認しながら、改善していくシステムはアジャイル型開発が向いています。

弊社でWEBアプリ、モバイルアプリ、SNSアプリ、ECサイト等の開発を行う場合、お客様からの要望も受け、多くの場合はアジャイル型開発を活用します。

また、アジャイル型開発はDXでもベストな開発方式として評価されています。

DXは元来、新たなビジネスモデルへの転換を意味するため、要件をシステム開発開始前に決めることが難しいです。

実際に動くものを見てみないと上手くいくか判断しづらいビジネスアイデアもあります。

これらの特性から、短期間で実際に動く機能を見ながら修正を繰り返していくアジャイル型開発がマッチすると評価されています。

3. その他の開発手法

ここまででウォーターフォール型開発とアジャイル型開発という2つの主要な開発手法について、解説しました。

これら2つの手法ほど名前を聞くことはないものの、他にもいくつか開発手法があります。

ここからは、その他の開発手法をご紹介します。

プロトタイピング型開発

ソフトウェア製品の試作を使って検証や改善を繰り返す手法です。

商品のUI/UXの検証を目的としてプロダクト、サービスなどの開発やデザインの段階で使われ、プロトタイプをユーザー視点で評価し、機能や仕様を洗練していきます。

スパイラル型開発

システムを機能ごとに分けて開発工程を反復するル開発手法です。

一見、アジャイル開発と混乱されやすいですが、スパイラル開発はより品質を重視します。

不明確な要件でプロトタイプを作成した後、ビジネスの観点から改良を繰り返して要件を具体化しながら、機能を完成させます。

DevOps

DevOpsはDevelopment and Operationsの略語で、日本語にすると「開発と運用」という意味になります。

システムの価値を継続的に向上させるために、開発担当者と運用担当者が協力し合える関係を作り出し、運用側から開発側へのフィードバックを繰り返すことでシステムを改善していく手法です。

MVCモデル

MVCはModel、View、Controllerの頭文字です。

Model、View、Controllerのそれぞれに役割を分担してコーディングを行うモデルです。

Webフレームワークのアプリケーション設定に使われることが多いです。

 4. オフショア開発に向いている開発手法は？

請負型ならウォーターフォール型開発

請負型開発は仕様要件書を基に開発し、成果物を納期までにリリースする契約形態です。

そのため、請負型開発はその特性上、要求が明確であるため、ウォーターフォール型開発が向いています。

詳細な要件定義書があれば、成果物と責任範囲が明確になるため、オフショア開発会社に依頼しやすくなり、日本側の管理負担も少なくてすみます。

ラボ型ならアジャイル開発

ラボ型開発はお客様の専任チームを形成し、そのチームを一定期間お貸しする契約形態です。

要件定義をせずに時間単位で確保した優秀なエンジニアに任せることで、ユーザーのフィードバックを反映しながら柔軟に対応できるため、アジャイル開発を活用することが多いです。

特にUI/UXを重視するWEBアプリ、モバイルアプリと特に相性が良く、NTQも含め、多くのオフショア会社はこの手法を得意とします。

5. まとめ

ここまで特に普及しているウォーターフォール型開発とアジャイル型開発をそれぞれのメリットとデメリットを解説し、あわせて他の手法についても簡単に触れました。

また、オフショア開発に向いている開発手法についても言及しました。

開発手法の選択の仕方でオフショア開発のメリットを活用し、デメリットをおさえることも可能です。

開発手法の選択も含め、オフショア開発でお悩みのことがあれば、お気軽にお問い合わせください。

・「お問合せ」ページ