本稿は「悩むユーザー部門」と銘打ち、要件定義でよく見られる問題を扱います。
詳細は省きますが、要件定義はユーザー部門の働きが肝となる工程です。
業務要件(新業務で実現したいこと)や機能要件(新システムに必要な機能・仕様)をベンダーに提示するという大役を担うためです。
実際苦労するユーザー部門の方も多く、本工程について理想と現実を踏まえながら述べたいと思います。
SAP導入プロジェクトに途中から助っ人で入った弊社のメンバーと話すと、以下のようなコメントを聞くことがあります。
このやり取りには要件定義という工程の重要さが表れています。
要件定義はシステム開発の出発点で、プロジェクトの行く末を左右するといっても過言ではありません。
「まだ序盤だから」と、主要な論点を詰めなかったり、課題のさばき方を誤ったりすると、後になってしわ寄せがきます。
残念ながら、上記はそのパターンでした。
要件定義の大切さは、弊社が携わった成功事例の共通点にも表れています。
それは「安定稼働したプロジェクトは、いずれも要件定義の検討結果が明確で、ドキュメントの形でしっかり残されている」という点です。
なお、これはS/4HANA標準機能に適合しない要件をアドオン開発でまかなうケースに限った話ではありません。
昨今トレンドのSAC(SAP Analytics Cloud)など他のSAP製品や、非SAP製品と組み合わせるケースも同様です。
しかし現場では、上記とは真逆のプロジェクトが多いのが実情です。
このような要件定義を、私は「ゆるふわ要件定義」と呼んでいます。
「ゆるふわ要件定義」は見過ごされることも多いです。次のような例に皆さん心当たりはないでしょうか?
程度の差はあれ、上記の事例(1)~(4)に心当たりのある方は以下のリスクにご注意ください。
上記からおわかりのとおり、「ゆるふわ要件定義」の実害は後になって出てきます。
例えは悪いですが、遅効性の毒のようにプロジェクトが進むにつれユーザー部門の悩みとなっていく点が厄介です。
言い方を換えると、要件定義の時点ではこの問題に気付かないことも多いということです。
専門家であるベンダーや情シス部門も目先のタスクの推進で手一杯になり、見過ごしてしまうケースは少なくありません。
実際、プロジェクト序盤での遅延を嫌い、詰めが甘くても要件定義を終わらせる例も(残念ながら)散見されます。
そのため、まずはユーザー部門が危険サインを見逃さないようにする姿勢が大切です。
次回はこの問題に対する解決アプローチについて考察します。
弊社はSAP-FIモジュールの導入を中心に、ユーザー部門支援の実績が多数あります。
本稿に関し、より詳細な情報をお知りになりたい場合は、ぜひ弊社にお問い合わせください。
【RPA開発Tips】いまさらだけれどWinActorフローティングライセンスとは?
【RPA開発Tips】いまさらだけれどWinActor Manager on Cloudとは?
【RPA開発Tips】ファイル操作に強くなる 後編
【RPA開発Tips】ファイル操作に強くなる 前編
【RPA開発Tips】エラーに強くなる(後編)
【RPA開発Tips】エラーに強くなる(前編)
SAP導入、悩むユーザー部門:「ゆるふわ要件定義」を防ぐ対策3点
SAP導入、悩むユーザー部門:「ゆるふわ要件定義」にご注意を!
【RPA開発Tips】Webブラウザ操作に強くなる(後編)
【RPA開発Tips】Webブラウザ操作に強くなる(前編)
【RPA入門】フローチャートを学ぶ(応用編)