アジャイル開発をERP構築に適用するには

InfoQにアジャイル開発をERP構築に適用する記事があったのでメモ。

【元ネタ】
Twitter / @akipii: アジャイル開発の利点は小規模リリースだけでなくプロダクトオーナーを含む体制にあると最近は強く感じる RT @bengkarita: アジャイルはERP構築失敗を防げるか http://bit.ly/sm3DEz #yam

InfoQ: アジャイルはERP構築失敗を防げるか

【1】ERPの特徴はいくつかある。
一つ目は、とても大規模で複雑なシステムであること。
ERPはその名の通り、1企業の基幹業務システムのパッケージ製品だ。
企業の業務で、製造や販売から会計までの全てをシステム化するから、大規模で複雑になりがち。
それゆえに、設計だけでなくプロジェクトの体制そのものも複雑化しやすい。

ERPに関しては、BPR、EA、SOAなどのバズワードがたくさん言われては消えていった。
新しい技術を取り入れたとしても、今動いているシステムを止めるわけにいかず、そう簡単に移行できない。
だから、SOAなどで古いシステムと新しいシステムを接続するアーキテクチャが持てはやされるが、その技術ですべての問題を解決できるわけではない。

「エリック・エヴァンスのドメイン駆動設計」は、複雑なシステムをOOAの観点でモデル化して、その複雑さを見える化しようとする。
僕の個人的な考えとしては、ERPで重要なのは業務データであり、渡辺さんの本「業務システムのための上流工程入門―要件定義から分析・設計まで」や羽生さんの本「楽々ERDレッスン」に書かれているようなDOAのモデリング技法が根本的な解決策に近いだろうと思っている。

二つ目は、プロジェクトの体制も複雑になりやすいこと。
大規模な業務システムを作るには、共通フレームワークを独自に作り、その上で各業務をサブシステム化する手法が普通。
だから、共通フレームワークという基盤に熟知し、顧客と開発チームの間を取り持つアーキテクトという役割の人が必要になる。
だが、アーキテクトの能力を持つ人が各チームにいるわけではないから、開発チームがすぐに問い合わせたい時もすぐに回答が得られるとは限らなので、開発が滞りやすい。

また、顧客の側でも、たくさんの利用部門の要望を取りまとめて、経営戦略や予算や納期の観点から優先順位付けしなくてはならない。
その役割がプロダクトオーナーになる。
プロダクトオーナーがしっかりしていないと、それぞれの利用部門から開発チームへ要望が五月雨式に届くため、開発チームの作業負荷が大きくなるだけでなく、ERP全般のリリース計画を考慮していないから、デグレードや新機能の影響範囲の考慮漏れが発生しやすく、変更管理や構成管理の観点でも危険。

更に、ERPを受託するSIでも、開発チームの要員や予算を最終的に意思決定するプロジェクトオーナーという役割が必要になる。
プロジェクトオーナーは普通はプロジェクトマネージャと呼ばれる。
各チームのリーダーは、チーム自身で解決できない問題や、リソースやコストなどを増やしたい時、プロジェクトオーナーへ直訴して調整する時が結構ある。
だが、プロジェクトオーナーとチームリーダーの人間関係がうまくいかないと、体制上の問題が先送りされて、開発そのものが破綻してしまう危険もある。

三つ目は、ERP導入によって、顧客側の体制も大きく変わってしまうこと。
従来は手作業で行ってい会計3伝票による仕訳、工場の製造や納品作業の指示書を印刷して作業を指示する運用などが全てIT化されることによって、それらの作業の従事する人が不要になる。

例えば、会計業務ならば、正社員の事務女性が出張旅費などの精算していたのだろうが、その作業は派遣社員の事務女性に置き換わり、会計に関連する正社員は会計データの整合性チェックという役割に変わる。
つまり、IT化されて業務がなくなるだけでなく、業務の役割が変わることによって、高度な知識を持つホワイトカラーという役割へ変化する。
この組織上の変化に経営者だけでなく社員自身が対応出来なければ、本来の目的であるERPによる業務の全体最適化までたどりつかない。

このように、ERP構築は受託企業だけでなく顧客企業にとっても劇薬だと思う。

【2】上記の記事で興味を引いた箇所は次の二つ。

(引用1)
顧客への価値創造に費やした時間はとても少ないです。

(引用2)
最も重要なのはアジャイルの方法を身につけ、ERPを知悉しているPMがいることです。

前者は、プロダクトオーナーという役割が曖昧か、プロダクトオーナーという人が存在しないために、顧客の価値に直結する機能とは何なのか、という議論ができなかった点にあるのだろうと思う。

後者は、プロジェクトリーダーが単にアジャイル開発の運用方法を知っているだけでなく、プロジェクトオーナーやプロダクトオーナーと頻繁に調整して問題解決していく手法を持っているのが重要な点と示唆しているように思う。
また、プロダクトオーナーがアーキテクトの役割を持ってくれればいいが、いつもそうとは限らない。
だから、プロジェクトリーダーがアーキテクトの役割も兼ねて、ERPの設計思想の観点で要件を整理したり、開発の方針を決定することも大切だと思う。

そんなことを考えると、ERP構築にアジャイル開発手法を取り入れる場合、テスト駆動開発やデイリービルド、小規模リリースなどのような技術よりも、プロダクトオーナー・プロジェクトオーナー・アーキテクトと言った体制面の仕組み作りの方がもっと重要だろうと思う。