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

  1. 『作る人(開発者)』にイメージが伝わらない
     「『使う人(利用者)』は作るべきものが何か分からない」のと同じように、「『作る人』は『使う人』の業務や課題が分からない」のも事実です。いくらSalesforceやその業務・業界の専門家であっても、『使う人』以上に『使う人』の日々の業務や悩みを知ることはできません。そして厄介なことに、『使う人』は「『作る人』は『使う人』の業務や課題が分からない」ということを忘れがちなのです。専門家だから知ってくれていて当然、と思ってしまいがちなのです。
     前述のように、専門家は一般的な課題や解決策で落とし穴を回避し、重要な効果を説明しようとしますから、これはとても危険なすれ違いです。

     そこでプロトタイプの重要な側面、「業務の流れを作ること」が重要になってくるわけです。要件定義におけるプロトタイプは、『作る人』がSalesforceの機能や狙い、効果を説明するためのものではなく、『使う人』の新しい業務の流れを一緒に確認するものなのです。プロトタイプの示す「新しい業務の流れ」が本当に目指すべき姿を実現するものか、課題を解決するものなのかを確認する過程において、Salesforceの機能や理念、効果を活用し説明する必要性があるだけです。その過程で、『使う人』の業務や課題に対する『作る人』の認識違いがあれば、ここですり合わせを行うわけです。プロトタイプがあれば、それを使って『使う人』が『作る人』に本当の業務や課題を教えることができるのです。
     つまり、「プロトタイプを作ってみて試す」行為は、まず最初に『作る人』が業務を理解するための「勉強」であり、Salesforceの機能や理念が対象の業務や課題解決に適しているかを試す「研究」なのです。プロトタイプを作る際に、どれだけ『使う人』の情報を解釈し、『使う人』の身になって業務を考えられるかが『作る人』の腕の見せ所なわけです。
     この小さな「心がけ」の差が、ちょっとした業務のオペレーション、例えば関係者との情報共有や見落とし・忘れを防ぐリマインダーなど、への対応となり、説得力のあるプロタイプやデモにつながります。Salesforce開発における『作る人』には対象の業務や業界の知識・経験、『使う人』側の経験がとても活きるのです。
     
     「『作る人(開発者)』にイメージが伝わらない」という『使う人』側の悩みに対してどれだけ自らアプローチできるか、これも『作る人』の腕の見せ所というわけです。

コメントを残す

メールアドレスが公開されることはありません。 が付いている欄は必須項目です