全3610文字

 JQベーカリーではサービスの企画・構想フェーズが終わり、いよいよ中身を具体化していく要件定義工程に入ります。要件定義の作業計画を立てようとしている、DXリーダーの和田さんと、システム開発担当の平川さん、JQベーカリーに常駐するコンサルタント三宅さんの会話を見てみましょう。

和田:さて、いよいよ要件定義だね。どう進めましょうかね。

平川:そうですね、まずは業務要件定義をして、その後システム機能要件定義に移るのが定石ですね。

和田:なるほど。ただ「業務要件」と言われても、新しいサービスだから既存業務がないよね?

平川:うーん……確かに。

三宅:新サービス開発の要件定義は、基幹系システム開発とは手順が異なるんです。

 この会話のように、DXプロジェクトで新サービスを開発する場合、既存業務はありません。システム化の対象となる業務を整理してからシステム要件を定義するという、基幹系システム開発の定石は通用しません。

 ではどうすればよいのでしょう。実はDXプロジェクトでも、その内容によって要件定義作業の進め方は異なります。具体的に見ていきましょう(図1)。

図1●DXプロジェクトと基幹系システム開発プロジェクトの要件定義作業の違い
図1●DXプロジェクトと基幹系システム開発プロジェクトの要件定義作業の違い
[画像のクリックで拡大表示]

 最初に、基幹系システム開発プロジェクトの要件定義の流れを確認しておきます。生命保険会社の保険引受(契約の締結)関連のシステムを例にします。保険引受にまつわる業務としては、保険の申し込み内容に不備がないかのチェックや、被保険者の総額保険金額の確認などがあります。これを整理したものが業務要件です。

 保険会社では、新しい保険商品を開発する際に、既存の業務のどこをどう変えるのかを業務要件としてまとめます。この業務の中でどこをシステム化するのか、またはどのシステム機能に変更があるのかをまとめるのがシステム要件定義です。