今回からはsalesforce案件の要件定義で発生する特徴的な問題や解決方法について事例を交え書いていきたいと思います。
従来のSI案件の要件定義
従来のSIでは要件定義では基本設計書に必要なシステム化の目的や業務一覧、システム構成図などを作成されると思いますが、要件定義の目的をすごくものすごく大雑把に言うと機能一覧を作成することと考えています。
正確な見積もりが算出するという意味合いもあります。
機能一覧は業務フローや業務一覧の資料に基づきお客様にヒアリングを行い、背景や課題を考慮してシステムに必要な機能を洗い出すというやり方で作成します。
そのため、SAPなどパッケージシステムで機能一覧を作成する時はそのパッケージで想定している機能とのギャップを分析するという形式で進めることが一般的です。
なので受注登録という業務であれば、
- 営業担当が受注伝票登録機能
- 得意先からEDIサーバー経由での受注データ取り込み機能
- 得意先からFAXによる受注情報入力機能
などの機能が一覧表として整理されます。
しかしsalesforce案件ではこのような従来のSIのやり方で要件定義を行うと顧客の要望を実現するのは難しい考えています。
その理由ですが、salesforce案件の業務要件は機能に対するものではなく、使い方に対する要求が多いためです。
例えば、
- 「顧客への回答時間やクレームを減らし顧客満足度を高めたい」
- 「ノウハウを共有して失注率を減らしたい」
- 「商談の進め方を標準化して営業一人当たりの商談数を増やしたい」
- 「重要顧客への訪問頻度を増やしたい」
などが導入目的になりますので、目的を実現するために次のようなチェックをレポートダッシュボードを使ってできるようにしたいというのが業務要件となります。
ですから従来のSIのように機能ごとにギャップ分析をしても何も要件は出てこないのです。
このやり方を打ち合わせでそのままやってしますとお客様はいつになったら自分たちの要求が実現できるのかと不安に感じられることになり、当初思っていたことが実現できないではないかという厳しいお言葉をいただくことになるのです。
しかしsalesforceのパートナー企業はSI企業ばかりです。私の知る限りでは大体機能要件に基づいた要件定義が実施されているのではと推測しています。
Salesforce案件の要件定義
実は弊社でも機能ごとにヒアリングすることを実施していました。私がSAPの開発現場のノウハウを活用してはじめた事業なので10年近くやっていたことになります。
10年の間に従業員も増えたのでsalesforce向けの機能一覧はテンプレート化されました。
この一覧表に基づきお客様との打ち合わせで画面を見て検証を実施してきたのですが、先に申し上げましたとおり、顧客の業務要件とは大きな隔たりがあるため、議論にすら発展しないことがあります。
一方、システム部門の方には好評です。一覧から漏れている業務のチェックや機能ごとに必要なバリデーションルールを検討いただくことができるためです。
もう一つ大きなデメリットはKPIに必要な項目、例えば商談フェーズをどう定義するというようなテーマは、商談フェーズが一つの機能の１項目でしかないため打ち合わせの議論にならないということです。お客様に次回までの検討してくださいで終了してしまっているのです。
これでは顧客に価値が提供できてないと思い改めることにしました。
機能一覧に基づく検証が顧客の要望にあってないからと言ってやめるわけにもいきません。
本稼働が開始されるとそのインプット画面やアウトプット帳票が使われるわけですからお客様検証もなく納品というわけにはいかないからです。
そのため、機能の検証作業は機能一覧にお客様検証結果欄を追加しお客様に実施いただきその結果をご報告する方式に変更したのです。
商談フェーズも同様でまずはお客様にて検討いただくのですが結果は会議でご報告いただくようにしています。
従来のSIプロジェクトではベンダーがお客様に機能の紹介を説明するのはスタンダードですが、salesforceのプロジェクトでは、システムを使って成果をあげることをお客様は望まれています。
そのため、お客様にも作業負担をいただき、その期限も管理する必要があるのですが、打ち合わせから機能検証を極力減らし、KPIや商談管理方法などいわゆる使い方を議論の中心にすることが望まれるのです。