前回お話しした「Salesforceの生産性 ー ローコード開発の秘訣」について１つ１つ解説していくローコード開発の秘訣シリーズ、１つ目のキーワードは「要件定義」です。
要件定義の難しさ
要件定義はシステム構築プロジェクトにとって、「システムがどう動いて何を実現するべきか」を決めるとても重要な工程です。この工程で最も話を難しくする要素は「『使う人（利用者）』と『作る人（開発者）』が異なる」ということです。つまり、作るべきものを知っている『使う人』が『作る人』に「システムがどう動いて何を実現するべきか」を伝える工程と言えます。
「両方知っている人が考えて作ればいいじゃないか」、そう思われる方もいるかもしれませんが、例えいたとしても１人ではどれだけ時間があっても足りません。作る側も作ってもらう側も組織として責任があるため、法的にトラブルにならないよう「依頼する」という形をとる必要もあります。何より、利用者の業務や課題、開発に必要なシステム構築・運用の知識は、どちらも直ぐに理解できるほど浅いものではありません。それどころか、多くの場合、『使う人』はシステムのことを全く知らず、実際に手を動かす『作る人』は利用者の業務など全く知らないことがほとんどです。「ノーコード・ローコード開発」が直接この問題を解決するのはまだ先の話でしょう。
そのような２者が、「システムがどう動いて何を実現するべきか」を議論すると、以下のような問題が発生します。
- 『使う人（利用者）』は作るべきものが何か分からない
システムを『使う人』は、自身の業務をよく理解しているものの、システム、特にこれから使う新しい技術が何をしてくれるかを知りません。まだ古いシステムを使っていれば「今のシステムのココを直してほしい」と言えるのですが、特に新規に導入するシステムの場合は「何ができるようになるとよい」という要望すら出すのが難しいのです。
- 『作る人（開発者）』にイメージが伝わらない
この有名な絵をご存じでしょうか？このサイトによると、オリジナルは1970年代に遡るほど昔のもので、それほど有名な絵のようです。これは、『使う人』である顧客が「作るべきもの」として伝えた要件が『作る人』側のチームの各メンバーに伝わるさまを揶揄したものです。
顧客が本当に必要だったもの（出典：顧客が本当に必要だったものとは （コキャクガホントウニヒツヨウダッタモノとは） [単語記事] – ニコニコ大百科）
つまり、例え『使う人』が何を作るべきかを分かっていたとしても、それを業務や背景を知らない『作る人』に伝え、全員が同じイメージを共有することはそれほど難しいということです。少なくとも私にはこのジョークは笑えません・・・（あまりに現実を捉えすぎています）
- 「リスク」は議論されない
これは少し悲観的過ぎる考えかもしれませんが、実際によく起こることです。『使う人』は、頼めば作ってくれると思い『作る人』に要件を伝えます。この際に、それを実現する際の難易度やそれに伴うリスク、工数などを考慮することはまずありません。『作る人』が考慮してくれると思い込みます。
一方、「作る人」も、実は作ることが技術的に可能と分かればその難しさやリスク、工数を積極的に議論しようとしないケースがあります。少し不思議な気がしますが、『使う人』と『作る人』が違う会社の場合、『作る人』側にとっては契約違反にならない事が最も重要、もっと言えば、折角「大きな開発になる」方向に進んでいるのにわざわざブレーキをかけたくない、と思ってしまうのがビジネスです。
よって、『使う人』がこうして欲しい、と言った要件は、多少？？？と思ってもそのまま受け止めて作ってしまう、ということが起きて得てしまうのです。
次のページでは、この問題に対する有効な解決策の１つ「プロトタイピング」についてお話しします。
Page:次のページ