Salesforceの生産性 ー プロトタイピングによる効果的な『要件定義』(2/3)


プロトタイピングを用いたSalesforceでの要件定義と開発

画像に alt 属性が指定されていません。ファイル名: work-5382501_640.jpg

ここで、筆者がお勧めするSalesforce導入時の要件定義、及びそれ以降のプロジェクトの進め方をご紹介します。今回は『使う人』があまりシステムに詳しくなく、『作る人』チームがリードして開発を進める場合を想定し、『作る人』チームの視点から進め方を記載することにします。

  1. 企画
    プロジェクトを始める前に『使う人』と『作る人』でやっておくべきことがいくつかあります。
    • 『使う人』の現在の業務上の課題や今回のプロジェクトで成し遂げたいこと等、プロジェクトの目標を明確にして関係者と共有する
      • 例:売上が伸びない ⇒ 新規顧客/商談開発・クロスセル/アップセルにつながる営業活動ができるCRM機能を充実させる
      • 例:営業が事務処理に忙殺され営業活動の時間が十分に取れない ⇒ 営業プロセスの効率化と営業支援チームとの連携強化を実現する
    • 『使う人』と上記を達成するために必要な「プロジェクトの基本方針」を決める
      • 例:CRM機能を充実させる ⇒ 営業支援・マーケティングに関する機能に関しては標準機能を利用し、カスタム開発は極力避ける
      • 例:効率化とチーム連携の強化を実現する ⇒ 自動化とコミュニケーションに関する機能はカスタム開発もしくは外部サービスの利用を促進、営業プロセスに関する機能は変更に素早く対応できるようカスタム開発を極力避ける
    • 『使う人』と以降に記載するプロジェクトの進め方を説明し、『使う人』代表として参画して頂けるキーパーソンを選出する(「この人が決めたことならばまずは従ってみよう」と『使う人』が納得する人物・組織であることが望ましい)
    • 『使う人』に業務の概略を聞き、業務データの参考になる資料を入手する
       
  2. 要件定義 ー プロトタイプ作成
    業務データベースのドラフト版をSalesforce上で作成し、1.で聞いた業務の概略をSalesforce上でデモできるよう準備する
    • この時、業務用語や英語表記(システムの設定名に用いる)の辞書を作ってそれなりに正しい綴りにしておくと後工程が楽になる
    • 顧客管理システムや商談管理システムなど、Salesforceが提供する業務機能を利用する場合、ここでSalesforce業務機能の仕組みと理念、効果を伝えるようにする
      ※ Salesforce専門家の助けが必要かと思います
    • この時点で複雑な設定やコーディングはしない。なるべく日を置かないでデモを実施することを優先する
       
  3. 要件定義 ー プロトタイプ確認
    準備したデモを『使う人』に説明し、業務の流れがあっているかを確かめる。そして、『使う人』に使い方を説明する。
     
  4. 要件定義 ー プロトタイプ体験
    『使う人』にデモを動かしてもらう。本業務で使ってもらうのがベストだが、時間を貰って一緒に動かしてみる、位でもよい。
     
  5. 要件定義 ー プロトタイプフィードバック
    『使う人』に、使ってみて困ったことを出してもらう。実際の画面で説明してもらう。例えば以下のようなもの:
    • 項目が多すぎて目的のものが探せない
    • 同じ情報を転記するのが大変で業務が回らなさそう
    • 別システムにある情報は自動で埋まって欲しい
    • 目的の情報をうまく探せない(検索がうまくできない)
    • 計算や集計を自動で行って欲しい(できればグラフも)
       
  6. 要件定義 ー 実装方針案作成
    それぞれの「困ったこと」1つ1つに対して対策案を以下のように用意する。
    • 工数・リスクの観点で「松」「竹」「梅」案を用意する。
      「松」案はコーディングを用いて細部の要件まで適えた案
      「梅」案は標準機能だけで実現した案
      「竹」案は工数・リスクの観点で真ん中の案
    • それぞれの案の工数・納期、できれば価格を記載する
    • それぞれの案のリスク・懸念点を記載する。
      特に「松」案ではリリース後の保守運用も視野に入れる
       
  7. 要件定義 ー 実装方針案検討
    対策案の一覧を『使う人』と『作る人』の間で確認し、議論する。必要であれば対策案のプロトタイプを作成し、デモする。最終的に以下を決める。
    • それぞれどの案で対応するか(もしくは対応しないか)
    • どの順で「困ったこと」を解決するか(優先順位)
    • 最初のリリースで絶対に解決すべきライン

      ここまでを繰り返して初回リリースに含める機能とその実装方針を定め、『使う人』と『作る人』の両者で合意する(要件定義完了)
      ※ 対策案の一覧の説明情報を充実させた「業務機能一覧」とこれまでに用いた説明資料をもって要件定義の資料とする
       
  8. 設計・開発・単体テスト
    あらためて全体最適となる設計を行い、コーディングを含めた開発を行う
    ※ 細かな仕様はデモに立ち戻って『使う人』に実機で確認してもらう
     
  9. テスト(結合テスト・システムテスト・ユーザ受入テスト等)
    要件定義で説明した業務の流れが細部まで実現できるか、要件定義で出した「困ったこと」が十分に解決されているか、『使う人』と『作る人』の両者の観点でテストする
     
  10. リリース & 保守改善
    リリースする。その後も本番環境を要件定義におけるデモとみなして同じサイクルを繰り返す

次のページでは企画、要件定義、設計・開発・単体テスト、テスト、リリースのポイントとなる点をご説明します。

Salesforceの生産性 ー プロトタイピングによる効果的な『要件定義』(1/3)

前回お話しした「Salesforceの生産性 ー ローコード開発の秘訣」について1つ1つ解説していくローコード開発の秘訣シリーズ、1つ目のキーワードは「要件定義」です。

要件定義の難しさ

要件定義はシステム構築プロジェクトにとって、「システムがどう動いて何を実現するべきか」を決めるとても重要な工程です。この工程で最も話を難しくする要素は「『使う人(利用者)』と『作る人(開発者)』が異なる」ということです。つまり、作るべきものを知っている『使う人』が『作る人』に「システムがどう動いて何を実現するべきか」を伝える工程と言えます。

「両方知っている人が考えて作ればいいじゃないか」、そう思われる方もいるかもしれませんが、例えいたとしても1人ではどれだけ時間があっても足りません。作る側も作ってもらう側も組織として責任があるため、法的にトラブルにならないよう「依頼する」という形をとる必要もあります。何より、利用者の業務や課題、開発に必要なシステム構築・運用の知識は、どちらも直ぐに理解できるほど浅いものではありません。それどころか、多くの場合、『使う人』はシステムのことを全く知らず、実際に手を動かす『作る人』は利用者の業務など全く知らないことがほとんどです。「ノーコード・ローコード開発」が直接この問題を解決するのはまだ先の話でしょう。

そのような2者が、「システムがどう動いて何を実現するべきか」を議論すると、以下のような問題が発生します。

  1. 『使う人(利用者)』は作るべきものが何か分からない
    システムを『使う人』は、自身の業務をよく理解しているものの、システム、特にこれから使う新しい技術が何をしてくれるかを知りません。まだ古いシステムを使っていれば「今のシステムのココを直してほしい」と言えるのですが、特に新規に導入するシステムの場合は「何ができるようになるとよい」という要望すら出すのが難しいのです。
     
  2. 『作る人(開発者)』にイメージが伝わらない
    この有名な絵をご存じでしょうか?このサイトによると、オリジナルは1970年代に遡るほど昔のもので、それほど有名な絵のようです。これは、『使う人』である顧客が「作るべきもの」として伝えた要件が『作る人』側のチームの各メンバーに伝わるさまを揶揄したものです。


    顧客が本当に必要だったもの(出典:顧客が本当に必要だったものとは (コキャクガホントウニヒツヨウダッタモノとは) [単語記事] – ニコニコ大百科

    つまり、例え『使う人』が何を作るべきかを分かっていたとしても、それを業務や背景を知らない『作る人』に伝え、全員が同じイメージを共有することはそれほど難しいということです。少なくとも私にはこのジョークは笑えません・・・(あまりに現実を捉えすぎています)
     
  3. 「リスク」は議論されない
    これは少し悲観的過ぎる考えかもしれませんが、実際によく起こることです。『使う人』は、頼めば作ってくれると思い『作る人』に要件を伝えます。この際に、それを実現する際の難易度やそれに伴うリスク、工数などを考慮することはまずありません。『作る人』が考慮してくれると思い込みます。
    一方、「作る人」も、実は作ることが技術的に可能と分かればその難しさやリスク、工数を積極的に議論しようとしないケースがあります。少し不思議な気がしますが、『使う人』と『作る人』が違う会社の場合、『作る人』側にとっては契約違反にならない事が最も重要、もっと言えば、折角「大きな開発になる」方向に進んでいるのにわざわざブレーキをかけたくない、と思ってしまうのがビジネスです。
    よって、『使う人』がこうして欲しい、と言った要件は、多少???と思ってもそのまま受け止めて作ってしまう、ということが起きて得てしまうのです。

次のページでは、この問題に対する有効な解決策の1つ「プロトタイピング」についてお話しします。