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

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

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

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

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

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

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

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

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

• どのような業務を対象に、どのようなシステム機能をもって実現するのか、ドキュメントの形で明文化されていない
• ドキュメントがあったとしても、具体性・網羅性・現実性に欠ける
• 検討結果へのユーザー部門の理解が不足している　など

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

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

• 後続工程での手戻りによってプロジェクトが遅延する
• 業務遂行に必要な機能の開発が漏れる
• 開発された機能の仕様に関する、ユーザー要望の反映が漏れる
• 後続工程の費用見積が不正確になる、大幅な追加費用が発生する

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

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

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

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