3.1 業務要件定義
前章でも業務要件によってシステム要件がどのように変わってくるか見てきましたが、Webシステムの設計を行う段階では、より細かい点で業務要件によりシステム要件が変化していきます。たとえば、受注決裁フローをシステム化するにあたっても、下記のようなさまざまな業務要件によってシステム要件としては異なるものとなってきます。
[受注決裁申請を行うのが社内の営業スタッフのみか代理店も行うか]
代理店経由の販売を一部にしても行う業態での受注決裁フローのシステム化を行う場合、受注決裁申請を行うのが社内の営業スタッフに限定されるのか、あるいは代理店の方々にも入力してもらいたいかによって、セキュリティ面あるいは業務プロセスが変わりうるので注意が必要です。
代理店の方々にも入力としてもらうということは、社外の方にシステムにアクセスしてもらうことになります。「申請」というのは基本的には入力する操作ですし、代理店の方々に入力してもらうとしても、あくまでもその後に担当営業が内容を確認して情報を追加入力して申請するのであれば、社内の情報を表示/提供することもなく問題ないと判断するのであれば特別なセキュリティは必要ないという判断もあり得るとは思いますが、不特定多数に操作させない仕組みを作る場合には、代理店の方々に対してアカウント発行してログイン認証して利用してもらう仕組みの構築まで必要となる可能性があります。
一方で、業務プロセス面としては、エンド顧客に直接対峙している代理店の方々に情報を入力してもらう手順にするにしても、社内の窓口となっている営業担当にどのような情報連携や追加情報入力などをしてもらうプロセスとするのかなどが影響事項として考えられます。特に、直販営業が主である企業で主たる営業プロセスである直販営業での業務要件で考えていく場合、サブの営業プロセスとなる代理店販売での業務プロセスの検討が設計プロセスの後の方になってはじめておこなわれると、設計の基本的な部分への変更を必要とする場合もあるので、設計プロセスの最初に要件の全体像としてサブとしての営業プロセスの存在も踏まえておくことは重要です。
[受注決裁フロー上で原価データを取り込んで表示するか]
受注決裁フロー上で、その販売価格だと利益がどの程度残るかがわかるように、外部から原価データを取り込んで表示するようなシステムを構築する場合、画面上に表示する内容と外部から取り込むデータ項目との違い/加工処理の必要性なども要注意項目のひとつです。
当然、画面上に表示したい各項目(各品番の原価、固定費・変動費など)のデータを外部から取り込めれば、データ選択して表示すればよいので一番よいのですが、表示するための情報は外部から取り込めるものの加工が必要な場合もあります。既存の原価データとして、各製造拠点の原価および間接費用と品番ごとの配賦割合の一覧がすでに存在するとしても、全製造拠点の原価を合計して間接費用も合算した原価の合計金額を品番ごとに算出した上で、画面上には当該品番の申請売値に対する利益額を表示したいのであれば、今回構築するWebシステム内で外部から取り込んだ原価データを加工する処理まで実装するか、あるいは外部からデータを取り込む前に前処理を行う仕組みを別途作る必要があります。
外部から取り込む原価データが存在していて、十分な情報が含まれているとしても、今回構築するWebシステムで必要となるデータ項目そのものとなっているのか、加工が必要なのかもWebシステムの要件を変化させますので、設計の初期段階で確認することが重要です。
[受注決裁フローで承認不要の案件も内容を確認できるようにするか]
受注決裁フローでは、値引き金額が大幅な場合にはより上位の職階の人間の承認が必要となるものの、値引き金額が少額の場合には承認人数が少なくてよいというルールはよくあるかと思います。
値引き金額が少額の場合には承認が不要となる職階の人が、承認不要な申請案件についても参照することは可能とする必要があるかどうかなどは、設計の初期段階ではなかなか要件として詰め切れない内容です。選択したSaaSあるいはシステムアーキテクチャが対応できればよいのですが、場合によってはシステム設計内容やSaaSの変更を行うか、業務要件としてあきらめてもらう必要があるということになる可能性があるポイントです。
このように設計の初期段階にて、かなり細かいところまで業務要件を定義できることが好ましいということがわかるかと思います。業務要件というと、業務概要や業務の流れを「業務フロー図」を作成してまとめるようなイメージもあるのではないかと思いますが、前述のような例はそのようなまとめ方ではなかなか含まれてこない詳細な業務要件も注意が必要な例です。さまざまな部署・人間が関係する新しい業務、あるいは既存業務の変更をひきおこすようなWeb構築の場合には、「業務を設計する」認識をもって取り組むとよいと思います。顧客側で事前に業務をきちんと設計してまとめてくれていればベンダー側としては対応不要となる作業なのですが、多くの場合には、顧客側ではある程度は対応するものの、十分に詰め切れていない段階でベンダー側の作業が始まるのが多いと思います。
Webサイトの設計手法の特徴としては、「ユーザ体験」の設計を行おうとするところがあるかと思います。ユーザ体験の設計を行うために、ターゲットのユーザ像を明確とするとともに、Webサイトで実現したいビジネスゴールやWebサイト運用面や予算・期間面などの制約条件を加味して、どのようなWebサイトを作るのか、その方向性としてのサイトコンセプトと満たすべき条件をはじめに明確にしておいた上で、Webサイトを訪れてくれたユーザがどのようにサイトを利用してもらい、各タイミングでどのような情報や印象を得てもらい、それに従ってどのようなアクションを行ってもらうかというWebサイトでのユーザ体験を設計するというものです。
Webの利用シーンがさらに広がり、さまざまな業務のシステム化にWebが利用されるようになり、そのようなWebを構築するにあたって、最初に業務要件をきちんと規定するという作業は、Webサイト設計におけるユーザ体験の設計を行う、あるいは構築しようとするWebの外側の業務まで含めてカスタマージャーニーの設計を行うことが、よりよい業務プロセスを実現する手順として重要という言い方もできるかと思います。
Webディレクタとして次のステップをさがしている方たちへ
これからのWeb構築・Webディレクションとして、業務にまで踏み込んでディレクション/プロデュースすること、それが近年のバズワードであるDXにもつながること、そしてWebの進化とともにWeb構築の各種ツール/サービスやSaaSが広がってきていることにしたがって、業務とシステムの両面からWeb構築・運用していく人間が求められていくこと、そのためにどのような知識や能力を身に着けていくとよいかについて解説している「マガジン」です。