ハイブリッド開発とは何か？

　ハイブリッド開発とは、開発手順を1つずつ確認しながら工程を進める「ウォーターフォール型開発」と、仕様や設計の変更を前提として厳密な仕様は決めずにイテレーション（反復）を繰り返す「アジャイル開発」の2つの利点を組み合わせた開発手法です。従来通りプロジェクト計画をしっかり立てつつ、主にモノ作りの工程を反復的に実施することを基本としています。

　ウォーターフォール型では要件定義・設計・プログラミング・テストなどの開発工程が順を追って進むため、動くようになったシステムを最後になってユーザーが確認することが原則です。しかしながら、ハイブリッド開発では早いタイミングでモノ作りを行いながらユーザーレビューを実施するため、ユーザーの真のニーズを早く取り込むことになります。

　結果として後工程での認識相違を大幅に削減できます。一方で、結合テストやシステムテスト以降の検証工程は従来通りウォーターフォール型で行うことにより、リリース品質を確保することが可能です。


　モノ作りの工程では、まず全体計画（スプリント設計）を決めたのち、スプリント（注1）と呼ばれる単位で期間を区切り、ユーザー部門と開発部門が協働でモノ作りを進めます。最終日にはモノ作りの内容を確認するスプリントレビューを実施し、その結果を含めて振り返りを行い、次のスプリントへ進んでいきます。そうすることにより、期間が進むごとに機能が段階的に充足して、システムが成長していきます。



　複数のシステムが関係するような規模の大きな案件では、一部のシステムにのみハイブリッド開発を適用することがあります。スプリント期間中はシステム間で情報連携しながら自システムの品質を担保し、複数システムが合流した検証工程では、全体のリリース品質を確認します。

　従来の工程定義やリリース品質の確保の仕方は企業により異なるため、ハイブリッド開発に新しく取り組む際には、既存のプロセスのどこに変更が必要になるのか、社内の開発規程・手続きをあらかじめ確認し、修正しておくことも必要です。

ハイブリッド開発が求められている背景

　近年、アジャイル開発は日本でも浸透してきており、DX（デジタルトランスフォーメーション）の推進に合わせて、導入を検討する企業も多くなっています。

　ただしアジャイル開発が適しているのは、ユーザー要望の多いインターフェース部分（画面・帳票）を新規に開発する案件など、適用範囲が限定的であることが多く、長年稼働している基幹システムなど、規模の大きなシステムを持つ多くの企業では、アジャイル導入の効果を十分に享受できないのが現実です。

　それに加えて、大企業の基幹システムでは安定的な稼働が求められるため、フィードバックを受けて改善するというコンセプトのもとに、短期間でプロダクトを市場にリリースすることが多いアジャイル開発は適用が難しいということもあります。一方、従来のウォーターフォール型開発では、ビジネスニーズや技術の変化が速い今の時代に対応することが難しくなってしまいます。

　システム開発ライフサイクル全体にアジャイル開発の適用が難しい場合でも、要件が明確に定義できないケースやビジネスニーズが変化するケースは多くあると認識しています。そのような場合に、ウォーターフォール型の開発にアジャイルのメリットを適用したハイブリッド開発が求められます。ハイブリッド開発の導入により開発手法の選択の幅を広げることができ、基幹システムを含む比較的規模の大きな案件に対しても適用することが可能となります。

　以上のことから、アジャイル開発を導入しようとしているものの、計画通りに効果が得られていない企業にこそ、ハイブリッド開発に着手する意義があるのです。

ハイブリッド開発に必要なアジャイルの要素

　2001年、アジャイルの先駆者たちが「アジャイルソフトウェア開発宣言」で変化に対応することの必要性について同意し、「アジャイル」という言葉が選択されました。アジャイルソフトウェア開発宣言から読み取れることは、開発手法だけでなく、心構え・価値観を理解することも重要だということです。

　より重視する4つの価値（個人と対話・動くソフトウェア・顧客との協調・変化への対応）が定義されており、従来とは違う価値観のもとで開発するということを理解する必要性が述べられています。

　その心構え・価値観に基づき、ソフトウェア開発手法としてのアジャイル開発フレームワークがあり、中でも「スクラム」は代表的なフレームワークの1つです。スクラムガイドによると、スクラムは経験主義であり、「透明性」「検査」「適応」を実現することで機能します。そしてスクラムが成功するかどうかは、「確約」「集中」「公開」「尊敬」「勇気」という5つの価値基準を実践できるかにかかっているとされています。

　価値基準を実践する組織が、スクラムチームです。スクラムチームの構成要素として、「プロダクトオーナー」「スクラムマスター」「（狭義の）スクラムチーム」という役割が明確に定義されています。それぞれの役割については後述しますが、スクラムチームは機能横断型であり、自己管理型であるべきであるとされています。

　機能横断型とは1つのスクラムチームに要件に責任を負う者およびシステムの挙動に責任を負う者を含んでいることを表し、自己管理型とは「いつ」「誰が」「何を」行うかをスクラムチーム自身で管理し、責任を持ってプロダクトを作り上げることを表します。

ハイブリッド開発プロセスを導入する工程の考え方

　ウォーターフォール型の開発プロセスのどの工程にアジャイルの要素を織り込むかについては、開発案件やシステムの特性によります。本章では2つの例を示します。

（1）モノ作りの工程全体（要件定義からプログラミング）にアジャイルの要素を導入
　ユーザー体験（User Experience：UX）や従業員体験（Employee Experience：EX）が重要視される案件（DX推進案件やユーザーのニーズを机上では予測しにくい案件など）に適しています。モノ作りの工程をアジャイルで実施することにより、ユーザーの要求をすぐにモノ作りに反映して確認することで、認識相違を最小限に抑えつつ開発を進めることができるメリットがあります。ユーザーが実際のシステムを使って確認することから、要件定義の最初からモノ作りの体制（プログラマーの参画、テスト環境など）が準備できること、社内手続きに必要な開発規程などのルールが整備できていることが必須条件です。

（2）要件定義から設計工程にのみアジャイルの考え方を導入
　ある程度要件は固まっているものの、画面や帳票などのユーザーインターフェースのレイアウトなどの要件を詰めていく場合に適しています。設計書や一覧の文面ベースで要件定義するのと比べて、実機に近いイメージのアウトプットを反復的に確認していくことで認識相違を最小限に抑えることができます。この場合、必ずしもユーザーが直接触れるテスト環境を用意する必要がないので、より手軽にアジャイルの考え方を適用できます。

【次ページ】ハイブリッド開発の推進体制とは？