タグ: 要件定義

プロトタイピングは要件定義の難しさを解決するのか？

Salesforceの生産性 ー プロトタイピングによる効果的な『要件定義』(1/3)では、要件定義が何故難しいかを以下の３点で説明しました。

1. 『使う人（利用者）』は作るべきものが何か分からない
2. 『作る人（開発者）』にイメージが伝わらない
3. 「リスク」は議論されない

果たして、プロトタイピングはこの３つの問題を解決しているのでしょうか？

1. 『使う人（利用者）』は作るべきものが何か分からない
   　『使う人』は、というよりも、一般的に人は、「何が欲しいですか」とオープンクエスチョンで聞かれると答えに困るものです。でも、「○○は欲しいですか？」とYES/NOで聞かれると答えられるもので、「何故ですか？」「どこがよいですか？」と聞くとどんどん答えていけるものです。そのため、プロトタイプで出発点を示し、「これでよいですか？どこか問題がありますか？」と問うと、少なくともそこから議論が始まるのです。
   　しかし、最も大切なことは「出発点がどこか」ということです。「作るべきものが何か分からない」ことの最も恐ろしい点は、「大切ではないことにこだわってしまう」ことです。実は大切でないものを大切だと思ってしまうと、本当に必要なものにはたどり着きません。
   　例えば「ボタンの位置が悪い」「操作が１つ多い」といったことは、電話を受けながら注文を代理入力するような業務では大切かもしれませんが、商談を入力するような数日に１回行う業務では商品やビジネスモデル、プロセスの変化に柔軟にシステムを対応させたり、受注率や売り上げを上げるために戦略的な分析ができることの方が重要です。ここで「ボタンの位置」など「操作性」にこだわり過ぎて全面開発してしまうと、もっと重要な「保守性」や「Salesforceの標準業務機能の活用」を阻害してしまう可能性があり、少なくともそういった議論に費やすべき時間を大きく浪費してしまいます。
   　ただ、作るべきものが分からない『使う人』にとって、最初に思い浮かんだそれらしいことの方が重要に思えるものなのです。今のお客様の、対象の業務に最も重要なことは何か、Salesforceのどの機能、どの理念、どの特長に注目すべきか、それを冷静に分析でき「出発点」として誘導できる専門家の「プロトタイプ」と「デモンストレーション能力」が重要になってくるというわけです。その専門家の魔法のような「プロトタイプ」と「デモ」の重要な材料が、前工程である「企画」段階の課題検討、あるべき姿の議論であることは言うまでもありません。
   
   　プロトタイプは、専門家が落とし穴を避けて適切な出発地点からお客様の頭の中の「完成形」を構築・誘導していくための強力なツールなのです。
   　
   　ただし、「落とし穴を避ける」とは「誤解されそうな点は見せず誘導したい完成形だけを見せつける」という意味ではありません。『作る人』は、落とし穴になりそうな「『使う人』の小さな心配」も適切に拾って見せるべきです。むしろ、『使う人』がそれに気づく前にプロトタイプで見せてその点を説明すべきです。
   　大切なのは、Salesforceの専門家として、それが「どうして重要でないのか」「Salesforceがそのようにしている理由（利点・狙い）」をきちんと説明することです。それが慣れの問題であるならばそのようにデモし、またSalesforceの狙いがあるならばそれを具体的に示して見せ、『使う人』に納得してもらうことが重要なのです。

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

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

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

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