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

  1. 「リスク」は議論されない
     前回の「プロジェクトの進め方」で最も示したかったのはこの点です。先の2点で示した、『作る人』が示す「完成形への誘導」と『使う人』が示す「本当の業務や課題の説明」、ともすればすれ違いや衝突になりそうな双方からの『主張』は何を軸にすればよいのでしょうか?
     それは『利益』と『リスク』です。『使う人』『作る人』の両者が『利益』と『リスク』を示して議論すればすれ違いや衝突は起こらず、建設的で前向きな議論ができるわけです。
     しかし、最初に申し上げた通り「『作る人』が訴える『利益』に対し、『作る人』がそれに伴う『リスク』を述べない」パターンがあることが問題です。この裏に隠された問題は、プロトタイプそのもので解決することはできません。「こうして欲しい」という『使う人』の要求に対し、『作る人』が「分かりました、では作りましょう」と応えてしまえばいいだけだからです。

     そこで重要なのが、前回示した「プロジェクトの進め方」にある、「プロトタイプに対した課題の解決策は、『選択肢』を示してそれぞれの『利益』と『リスク』を議論する」工程です。さらに言えば、上記の「裏に隠された問題」の本質である「『作る人』は作りたい」という心理を抑制するために、選択肢を「標準」~「開発」という軸で3段階「松竹梅」に分けるという手法が効果的なのです。
     つまり、「標準機能によるプロトタイプ」という出発点から1つ外れる度に選択肢を示しながら「利益」と「リスク」を、「(未来も含めた)工数(金額)」という縮尺で具体的に議論する、これにより必ずリスクを検討する過程を踏むわけです。
     この「工数(金額)」という縮尺で議論することは、『作る人』にとって大きな意味があります。『作る人』の「作りたい」という心理にも実は「十分な費用が請求できない/予想以上に費用が掛かる」という不安要素があります。そのため、「開発に倒したい」と思うかもしれない『作る人』側にも、「工数(金額)」を示してリスクを議論することにはとても大きな意義があるわけです。

いかがでしょうか? プロトタイピングは要件定義の問題を解決してくれそうでしょうか?

次のページでは、3回に分けてご説明してきた「Salesforceの生産性 ー プロトタイピングによる効果的な『要件定義』」の締めくくりとして、Salesforceプロジェクトにて生産性を向上させる要件定義のポイントを振り返りたいと思います。

もう既にお気づきかと思いますが、プロトタイピングは「要件定義の問題を解決」するわけでも、「Salesforceの生産性を向上」させるわけでもありません。大切なのはそこではないのです。

コメントを残す

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