2011年の11月3日のComputer Weekly誌の記事によれば、アメリカ軍はオープン標準とアジャイルを推進しているということだ。現在のベンダのERP構築に逆風が吹いているのが原因だ。記事によれば、
“アメリカ軍が一般のコンピューティングのトレンドを追いかけ、ERPパッケージの導入で既存のシステム全体を置き換えるという野心的な試みに乗り出して10年が経つ。
しかし、スケジュールは遅れ、数十ドルの予算超過になってしまった。
現在、国防総省はアジャイルを実践し、オープンな標準とセマンティックウェブを採用しようとしている。 “
国防総省の主席管理官補であるElizabeth McGrath氏はアメリカ議会での証言で次のように言う。
"[ビジネスエンタープライズアーキテクチャの]の次のリリースを通じて、オープンな標準とプロトコルを設計に採用し、セマンティックウェブや共通のビジネスプロセスモデリングの手法、アジャイル開発の方法論を導入する予定です。"
ERPの実装失敗はよく知られており、情報産業の分野では蓄積もある。CIOマガジン誌は2009年に10の有名なERPシステムの失敗事例を紹介している。Computer World UK誌もERP失敗の一覧を掲載している。どれも、ERP実装の困難さを指摘する事例ばかりだ。アメリカ軍のアジャイル導入は先例に鳴りうるだろうか。それともただの希望的観測で終わってしまうだろうか。
Guerilla Project ManagementのブログはERPを実装するときにアジャイルを使うことについて論じている。事例によれば、アジャイルを使ったSAPのシステムの導入が納期前に完了したという。
Genesis ConsultingのCEOであるJason Fair氏へのインタービューによれば、
“...顧客への価値創造に費やした時間はとても少ないです。”.
氏は従来のウォーターフォールによるERPの構築では顧客への価値創造に使える時間は5-10%に過ぎなかったと見積もっている。これを20%にすることで顧客により重要な価値を提供できると考えている。
Agile ScoutはSAPに特化したBluefinのMike Curl氏へインタビューした。氏はERP構築にアジャイルを使う上での推奨事項を教えてくれている。
始めに信頼できる顧客のリスクの少ないプロジェクトを選び、比較的厳しいスケジュールでトライアルを行い、現実の問題に取り組んでみること。
-
多くの人を使わずに‘仕事を始める’こと。 解決すべき真の問題と権限のある プロダクトオーナーの本物の要望が必要。 .
-
いくつのスクラムをどのくらいのリソースで稼働させるか注意深く考えること。スクラムチームが増えるにつれ、協調やコミ二ケーションの複雑さや開発の衝突などが増大する。
-
プロジェクトチームが一夜漬けで新しい方法論を身につけられると思ってはならない。, 教育とコーチングが必要。アジャイル導入を受け入れさせ、よくある冷笑主義を克服するための真剣なチェンジマネジメントやも必要。
-
アジャイルの世界は少数の熟練のエンジニアのリソースを上手に使うが、特にSAPの世界ではこの傾向が顕著だ。 アジャイルチームのメンバは考え、設計し、開発し、トラブルを解決し、テストし、コミュニケーションすることを同時に行う必要がある。弱点となるリソースはすぐに目立ち、ボトルネックになる。
-
価値を提供することのプレッシャーは不断に続く、苛烈なものだ。チームの集中力とモチベーションを長期にわたって維持するのはとても難しい。
-
上手くいかないことの方が多い。実利的に臨機応変に行動する必要がある。誰かの責任を告発するような言動が見られ始めたら、すぐに収拾する必要がある。そうしないとリスクを回避する態度が蔓延してしまう。
-
何らかのマイクロブログを使うこと。こうすることで、すべての人が自分が何をしているのかわかるようになる。誤解を回避し、コミ二ケーションを促進し時間の節約にもなる。
-
回帰テストの概念を、継続的に開発が続くことを想定しているアジャイルの手法に適合させるのは簡単ではない。しかし、重要なSAPのシステムを構築しているとき、回帰テストは‘構築中のソフトウエア’が他のソフトウエアを壊さないことを保証する唯一の方法だ。
-
複数のコンポーネントと技術が同時に使われたとき、チームは‘弱い結びつき’を見つけ出して、それに成果の未達成や計画のずれの責任をなすりつけようする。これは対処すべき文化の問題だ。
-
モデルと組織のサポートの影響は先に考えておくこと。何かを運用環境へリリースしたら、すぐに次のイテレーションに注力するのはプロジェクトの成功を導かないし、アジャイルの手法とも言えない。
ウェブにもERP構築でのアジャイル実践についての議論がある。下記はwww.focus.com
Kamanraj Shankar氏によれば、
アジャイルの方法論は大きな複雑なERP構築に適用できます。普通、ERPの構築はウォーターフォールやベンダ特有の方法で行われます。要求やブループリント、ビルド、テストなどという言葉が使われます。
アジャイルの手法はスプリントと呼ばれる短期間の中で顧客と密に強力しながら計量可能な具体的成果を生み出すことに注力します。
顧客はプロジェクト全体を見通せるアジャイルの方法を好むでしょう。
アジャイルでERP構築を行うには、始めに下記を計画する必要があります。
- プロジェクト全体をスプリントに適合するかたちの成果物に分割すること。
- スプリントのバックログを管理するために顧客を巻き込むこと。
- 各スプリントにオンデマンドで効率的にリソースをアサインすること。
最も重要なのはアジャイルの方法を身につけ、ERPを知悉しているPMがいることです。
私はERP構築でのアジャイル導入の具体的な難点について回答することができます。
Bill Wood氏は異なる視点から議論している。
"アジャイル"は"アジャイルマニュフェスト"の定義によれば、ERPプロジェクトに大災害をもたらすと思います。
すでに議論されていますが、巨大で、相互に依存し合っているソフトウエアプロジェクトに必要なのは注意深く構造化された手法です。
しかし、現在ではすべてが"アジャイル"と呼ばれています。"アジャイルマニュフェスト"の要求とは180度反対の従来の管理手法でもアジャイルと呼ばれています。
したがって、元々の"アジャイル"はERPプロジェクトにと災害をもたらします。従来のプロジェクト管理手法の中で"アジャイル"と呼ばれているものであれば上手くいくと思います。
-------------------
アジャイルがERPプロジェクトに災害をもたらす証拠として、私のSAP ERPの経験を紹介します。1990年代前半から中盤のSAPはプロジェクトの失敗を繰り返し、高価で問題を含んだプロジェクトもたくさんありました。これに対して、すぐに一歩一歩確実に進める特別な方法が編み出されました。これがASAPで、現在でも使われています。
何千ものプロジェクトで使われた結果、この方法は文字通り必要不可欠なものだと証明されました。
しかし、ASAPは"アジャイルマニュフェスト "の基本的な原則に違反しています。
アメリカ軍の新しいERP開発の方向性が成功するかどうかは現時点ではわからない。しかし、ビジネスの世界ではERPプロジェクトの失敗が蓄積され、新しい方法が模索され始めた。あなたはどう思うだろうか。アジャイルはERPの失敗から会社を救えるだろうか。