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

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

要件定義の難しさ

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

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

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

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


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

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

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

コメントを残す

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