汎用パッケージへのアジャイル型の導入アプローチの適用に関して~ 第1回:概要

汎用パッケージへのアジャイル型の導入アプローチの適用に関して~ 第1回:概要

今回は、汎用パッケージにおける最新の導入アプローチについてご紹介させて頂きます。 ERPシステムなどの大規模な導入プロジェクトでは、従来ウォーターフォール型の導入アプローチが主流でしたが、最近の米国などの事例では増分的・反復的アプローチであるアジャイル開発手法を活用した導入プロジェクトが増えてきています。 アジャイル開発手法の1つであるスクラム(SCRUM)をパッケージソリューション導入に適用する場合の概要を、米国における実施事例の情報を基にして、従来のウォーターフォール型と比較しながら考察してみたいと思います。 なお、スクラム開発手法の概要につきましては本稿では詳細な説明を省かせて頂きますので、文末の参考資料のURLなどをご参考にして頂ければと思います。

ウォーターフォール型導入アプローチの問題点

ウォーターフォール という名は「水の流れ」の様に工程が進むことから名付けられた 開発手法 です。前の工程には戻らないという前提、滝の水が上から下へと流れ落ちるようにといった意味合いでウォーターフォールと呼ばれています。ERPシステム導入などの大規模なプロジェクトで広く採用されているアプローチです。

プロジェクトを複数のフェーズに分け、各フェーズの終了時に成果物の作成を確認することにより、各フェーズにおける品質を確保します。管理者がスケジュールや進捗を把握しやすいという利点があります。

私が利用している方法論では、詳細なToBeプロセスの設計図である「ビジネス設計書」を初期の段階で作成し、「ビジネス設計書」に従って設定や開発、各種テストを行います。マイルストーンごとに品質ゲートを設定し、成果物の確認と承認を行っていきます。各マイルストーンで必要な成果物を確実に作成し文書化、顧客の承認を得た上で次の工程へ進むので、リスクを最小限に抑えることができるという利点があります。

問題点としては、プロジェクトの初期の段階で全体の設計を済ませてから機能を実装するため、開発着手までに時間がかかってしまう場合があります。グローバルの大規模プロジェクトの場合、ToBeプロセスの設計に1-2年かかる場合もあります。また一度開発が開始されると変更が難しく、ビジネス環境の変化に柔軟に対応できないという問題点があります。2-3年かかるような大規模プロジェクトでは、完成した時にはビジネス環境が大きく変わっており、その時点でのビジネス戦略とリンクしていないシステムになってしまうリスクがあります。

また不具合や変更などが発生した場合、手戻りの工数が大きいといった問題点もあります。

 

アジャイル型導入アプローチの特徴

アジャイル型 の導入アプローチの最大の特徴は「変化対応力」にあります。アジャイル型導入アプローチでは、仕様や設計の変更があるという前提に立ち、詳細なToBeプロセスの設計図である「ビジネス設計書」を作成しません。

まずお客様が実現されたいToBeプロセスに適合するベストプラクティスを選択し、評価用システム・デモシステムで有効化します。このベストプラクティスの業務プロセスをベースライン(たたき台)として、お客様とFit&Gap分析をワークショップ形式で行います。標準の機能で対応できる部分(Fit)と開発が必要な部分(Gap)を顧客の要望(ユーザストーリー)として記述します。そしてユーザストーリーの一覧表であるプロダクトバックログを作成します。このプロダクトバックログが「ビジネス設計書」の役割を担います。

プロダクトバックログ内のユーザーストーリーは、プロセスオーナが MOSCOW法などを使用してビジネス優先度を基に開発の順番をつけます。
(MOSCOW: Must Have Should Have Could Have Wont Have)

開発チームであるスクラムチームは、プロダクトバックログに格納されているユーザストーリーをビジネスの優先度の高い順番に処理していきます。選択したユーザストーリーの機能を実現するために作業を詳細化し、プロダクトバックログからスプリントバックログへ落とし込みます。スプリントとは開発の管理単位で時間枠が設定されており、通常4週間が設定されます。スプリント単位での「設計→実装→テスト→デモ・文書化→顧客受入れ」を繰り返して反復的な増分開発を行います。従来の単体テストはスプリントごとに実施することになります。

開発単位であるスプリントごとに顧客へのデモを行うことで、顧客のフィードバック/承認を適時得ることができます。これにより、大きな手直しを未然に防ぐことが可能になります。

上記のアジャイル型導入アプローチは海外では標準になりつつありますので、今後グローバルのプロジェクトでも採用されていくと予想されます。

例:アジャイル型導入アプローチのロードマップ 以下URLのPDFより引用(P22)し、和訳しました。 https://www.asug.com/discussions/servlet/JiveServlet/download/42912-3-43495/SAP%20Activate%20-%20Introducing%20SAPs%20Next%20Generation,%20Agile-Based%20Methodology.pdf

 

汎用パッケージ導入プロジェクトにおけるアジャイルアプローチの課題

汎用パッケージ導入プロジェクトに関しては、現時点ではウォーターフォール型導入アプローチが主流ですので、プロジェクトメンバーの方々はアジャイル型導入アプローチ(SCRUM)の経験がない方々が大部分だと思われます。まずプロジェクトメンバーへのSCRUM手法の教育が必要です。

また大規模プロジェクトでは、複数のスクラムチームが並行して作業を行うことになります。スクラムチーム間での調整・連携や、統合テストの管理などが重要になります。アジャイル型導入アプローチの採用により、導入プロジェクトで大きな影響が生じると思われる主な領域は以下になります。

  • プロジェクトマネージャ・プロジェクトメンバーが必要なスキル(SCRUMアプローチの知識)
  • SCRUM対応のプロジェクト管理ツール
  • プロジェクトガバナンス
  • スクラムチームのロールおよび責任、編成
  • 高位のToBeプロセスの設計、ToBeプロセスの詳細化
  • ソリューション文書化
  • テスト管理
  • 変更管理
  • オフショア開発

まとめ

従来のウォーターフォール型導入アプローチに慣れ親しんだプロジェクトメンバーの方々にとっては、アジャイル型導入アプローチの採用は非常に高いハードルがあるように思われます。

アジャイル導入型アプローチが、ERPなどの大規模導入プロジェクトに対して日本でも採用されるのか、今後の展開を見届けたいと思います。

参考資料

  1. スクラムガイド – Scrum Guides
    http://www.scrumguides.org/docs/scrumguide/v1/Scrum-Guide-JA.pdf
  2. SAP Activate – what is themethodology story?
    http://scn.sap.com/community/asap-methodology/blog/2015/06/24/sap-activate–what-is-the-methodology-story

記事は、予告なく変更または削除される場合があります。
記載された情報は、執筆・公開された時点のものであり、予告なく変更されている場合があります。
また、社名、製品名、サービス名などは、各社の商標または登録商標の場合があります。