SAP導入、悩むユーザー部門：「ゆるふわ要件定義」にご注意を！

本稿は「悩むユーザー部門」と銘打ち、要件定義でよく見られる問題を扱います。

詳細は省きますが、要件定義はユーザー部門の働きが肝となる工程です。
業務要件（新業務で実現したいこと）や機能要件（新システムに必要な機能・仕様）をベンダーに提示するという大役を担うためです。

実際苦労するユーザー部門の方も多く、本工程について理想と現実を踏まえながら述べたいと思います。

SAP導入プロジェクトに途中から助っ人で入った弊社のメンバーと話すと、以下のようなコメントを聞くことがあります。

筆者

新しいプロジェクト、どんな状況ですか？
参画前にお客様から聞いた話では、テストで不具合が多発しているとのことだったけど。

弊社メンバー

これ、要件定義の段階で失敗している可能性が高いっすね。
業務要件を整理しないまま開発していて、機能が複雑なつくりになっているし、今になってユーザーから仕様に関する問い合わせが頻繁に来るし……。

このやり取りには要件定義という工程の重要さが表れています。
要件定義はシステム開発の出発点で、プロジェクトの行く末を左右するといっても過言ではありません。

「まだ序盤だから」と、主要な論点を詰めなかったり、課題のさばき方を誤ったりすると、後になってしわ寄せがきます。
残念ながら、上記はそのパターンでした。

要件定義の大切さは、弊社が携わった成功事例の共通点にも表れています。
それは「安定稼働したプロジェクトは、いずれも要件定義の検討結果が明確で、ドキュメントの形でしっかり残されている」という点です。

なお、これはS/4HANA標準機能に適合しない要件をアドオン開発でまかなうケースに限った話ではありません。
昨今トレンドのSAC（SAP Analytics Cloud）など他のSAP製品や、非SAP製品と組み合わせるケースも同様です。

しかし現場では、上記とは真逆のプロジェクトが多いのが実情です。

このような要件定義を、私は「ゆるふわ要件定義」と呼んでいます。
「ゆるふわ要件定義」は見過ごされることも多いです。次のような例に皆さん心当たりはないでしょうか？

事例（1）

会議にて、ベンダー担当者から「以上がこの領域のSAP標準機能です。ユーザー側からコメントはありませんか？」と聞かれた。
→必要な機能といった形では整理されていなかったが、担当ユーザーが新業務で実現したい夢をとにかく即興で語った。
→するとベンダー担当者が困ったような反応をしていた。

事例（2）

ベンダーが「S/4HANAではこんなこともできます！」と自信満々に語っている。
→よくわからないが便利そうなので、差し当たってベンダー側の提案に任せた。

事例（3）

ベンダーからドキュメントのレビューを求められた。
→こちらの要望が一部書かれていないが、期日も迫っており、とりあえずサインオフした。

事例（4）

正直、各業務の担当ユーザーが新しい業務の流れについてイメージできていない。
→次の工程で明らかになればいいと思っている。

程度の差はあれ、上記の事例（1）～（4）に心当たりのある方は以下のリスクにご注意ください。

上記からおわかりのとおり、「ゆるふわ要件定義」の実害は後になって出てきます。
例えは悪いですが、遅効性の毒のようにプロジェクトが進むにつれユーザー部門の悩みとなっていく点が厄介です。

言い方を換えると、要件定義の時点ではこの問題に気付かないことも多いということです。
専門家であるベンダーや情シス部門も目先のタスクの推進で手一杯になり、見過ごしてしまうケースは少なくありません。

実際、プロジェクト序盤での遅延を嫌い、詰めが甘くても要件定義を終わらせる例も（残念ながら）散見されます。
そのため、まずはユーザー部門が危険サインを見逃さないようにする姿勢が大切です。

次回はこの問題に対する解決アプローチについて考察します。

弊社はSAP-FIモジュールの導入を中心に、ユーザー部門支援の実績が多数あります。
本稿に関し、より詳細な情報をお知りになりたい場合は、ぜひ弊社にお問い合わせください。