要件は膨張しがち

　「簡にして要」な要件定義を行うことは、システム構築プロジェクトの大命題であるが、得てして要件は膨張しがちである。ユーザー部門としては、現行の運用管理レベルを落としたくないし、せっかくの機会なのでいろいろと実現したい。導入コンサルタントとしては、現場の雰囲気を悪くしないよう、ついついさまざまな提案をしてしまう。

　多くの要件を押し込むことができた結果、ユーザーは「限られた予算で、たくさんのことを実現した」と一時的には満足するかもしれない。しかし、結果としては、複雑過ぎて設計や開発が膨らみ、運用開始が遅れることが多い。または仕様変更の影響を分析し切れずに、運用開始後のシステム改善ができないなど、最終的にはユーザーにとっても「高い買い物」になりかねない。

要件の膨張を防ぐにはどうするか

　では、どのようにして要件の膨張を防ぐのか。要件定義の現場でコンサルタントがうまく立ち回ることで、必要最小限の要件に絞り込むという方法もある。しかし、人間の力量にはバラツキがあり、いつも確実に抑えられるわけではない。対処するには、「仕組み」の導入が必要である。

出典:アクセンチュア株式会社

（1）予算枠と工数算出モデル

　まず、プロジェクト予算枠と工数算出モデルを定義しておくことが重要である。事前にユーザーと共有しておくことで、機能追加／変更があった際のシミュレーションの説明が容易になる。あらかじめ明らかにしておきたいのは以下だ。

• 予算枠の内訳（1）RFPなどで開発することが決まっている機能の一覧とそれぞれの工数
• 予算枠の内訳（2）ユーザーからの追加要望に備えたバッファー工数
• 機能が追加される際に増加する工数の算出モデル（画面、帳票、バッチなどの機能種類ごと）

　SAP ERP開発では、帳票、インタフェース、移行ツール、機能拡張、画面、ワークフローで工数算出モデルを用意することが多いが、あらかじめ関連アーキテクチャを決めておくことが重要である。インタフェースではSAP ERP標準のIDOC技術を使うのか、ワークフローでもSAP標準を利用するのかなどにより、開発工数は大きく変わるからだ。SAP ERPは、パッケージにいろいろと機能が備わっているために、アーキテクチャ部分の事前検討がおろそかになることがあるので、気を付けなければならない。

（2）予算の消化状況のモニター

　次に予算の消化状況を適宜把握できるようにしておくことも重要である。開発機能一覧に工数のカラムを設けておき、常に全体の予算消化状況を把握できるようにするのが良い。加えて課題検討など想定外の作業で工数が消化されてしまうこともあるため、必要に応じて実績工数を把握し、工数算出モデル以上に工数を消化していれば、問題事象を深掘りすることも大切である。

　また工数算出モデルで扱うのが難しい作業として、SAP ERPの開発ではテーブル項目の追加が挙げられる。カスタム開発のアプリケーションでは、テーブル項目の追加は比較的容易であるが、標準テーブルを持つSAP ERPの場合、追加項目によっては標準テーブルが利用できず、丸ごとアドオン開発になってしまう場合がある。近年、Web Dynpro技術の登場などで、SAP ERPでも画面開発の柔軟性が増してきているが、レイアウトの作りやすさに惑わされて安易に項目追加すると、大きな痛手をかぶることになる。

　なお、設計が進み、追加アドオンを抽出していくタイミングでは、導入コンサルタントの力量が重要になる。SAP ERPと業務の両方に詳しいコンサルタントが参画していれば避けられる課題は非常に多い。標準機能の組み合わせで対応できる機能が大規模なアドオン開発となってしまったり、業務運用で補える機能を追加のアドオンで開発してしまうなどの失敗を避けることができるのだ。

　SAPと業務の両方を深く知っている人が一般企業に在籍していることはほぼないだろう。そのためSAP ERPの導入では外部の協力が必須となる。SAP導入パートナーを選定する際は、その点を十二分に見極めることも重要だ。

（3）要件取捨選択の優先度付け

　モニタリングの結果、予算枠を超えそうな場合は、ユーザー部門に要件を取捨選択してもらうことが必要である。そのためには費用対効果の他、要件を取捨選択するための基準をあらかじめ決めておくことが重要である。プロジェクトの目的に寄与するのか、または、全社要件なのか、特定部門要件かなどが典型的な基準となる。これらの基準をプロジェクトの末端にまできちんと展開しておかないと、現行業務を変えたくないユーザー部門の厚い壁に阻まれることとなるので、要注意である。

　特にSAP ERPの場合は、現行オペレーションをパッケージに合わせることで追加開発を抑えることが重要である。しかし、現場や取引先との関係などで現行オペレーションに優位性があると主張するユーザーも多い。例えば、海外との取引業務は国際調達部などで集約され、特定の要員でオペレーションしていることが多いため、現行維持の圧力が強い。結果的にSAP ERPの追加開発が膨らむのである。現行オペレーションでなく、目的を基に判断することを徹底しなければならない。

（4）要件を取捨選択する会議体

　要件を判断する材料がそろったら、しかるべき責任者に判断を委ねることが必要である。しかし、アドオン判定会などの会議体はあるものの、有効に機能していない場面も多く見受けられる。会議体を設定する際は以下の点について留意することが重要である。

会議体設定時の留意点の例

• 予算に責任のある人を巻き込めているか
• 複数部門の利害を調整できる人が参加しているか
• 予算枠を超えそうな場合のエスカレーションの仕組みが用意されているか

　縦割りだった部門の横連携を狙って、統合システムであるSAP ERPを導入することは多い。それ故、それまで部門をまたいで調整をする習慣が無い企業も多く、各部門の利害調整が難しくなりがちだ。SAP ERPの導入をスムーズに進めるには、部門間の調整という新しい習慣を定着化するための仕組み、つまり、会議体を公式な仕組みとして用意しておくことが必要なのである。

　要件の膨張を防ぐには、コンサルタントの力量以上に仕組みの力が大きい。プロジェクトの成否は仕組み作りにあると捉え、プロジェクト開始前に各キーマンと合意をしておくことが不可欠であるし、そういった仕組み作りに知見のあるSAP ERP導入パートナーを選ぶ必要がある。