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

要件定義の救世主『プロトタイピング』

そのような問題を解決する1つの手段が「プロトタイピング」です。これは、「使う人」と「作る人」が共に見ながらお互いの認識を合わせ、改善すべき点・回避すべきリスクを議論できる「模型版」を作ることです。

「プロトタイプ」、つまり「原型」とは、量産前に問題や課題を見つけるための「試作機」を意味します。IT業界においても、『作る人』が本格的に作り出す前に模型版を作り、課題を洗い出し解決策の見通しをつけることを「プロトタイピング」と言います。しかし、要件定義もその「課題」の1つなのですから、実物、特に実際に動くシステムを見ることで先の『使う人』との間の3つの課題を解決しようではないか、ということです。

ここでよく、「プロトタイプができたならば、要件定義と言わず、それを精査して本番システムにしてしまえばいい」「それがアジャイルだ」という方もいらっしゃると思います。しかし、筆者はここでは敢えて「要件定義」にとどめる、つまり要件定義の後にきちんと設計・開発・テストの工程をとることをお勧めします。これについてはまた別の機会にお話ししたいと思います。

この「プロトタイピング」の一番の問題は、その「模型版」ですら作るのに時間がかかる、ということです。むしろ、それを作る工数があるなら本番システムを作れる、と言えるほど、模型版であろうと動くものを作るには工数がかかったのが従来の開発技術でした。

もうお分かりの通り、ここで「ノーコード・ローコード開発」の真の実力が発揮されるわけです。つまり、コーディングなしで作ることで「模型版」を素早く作り確認する、というわけです。更にその「模型版」が「ベース」となり、そこに「コーディング」を付け足すことで実際の本番システムになる、つまり「模型版」が無駄にならない、作り直しによる「写し間違い」のリスクが低い、という利点もあります。

最終的には、この「模型版」を『使う人』が自身で作り、『作る人』に説明できるのがベストですし、それを実現しているお客様もたくさんいらっしゃいます。しかし、ここでの論点は、誰が作ろうとも「模型版を素早く作れる」ことが大事だ、ということです。紙やパワーポイントにイメージを描くのと同じ素早さで実際に動くシステムが見られるのであれば、それが誰によって作られようと『使う人』『作る人』にとって非常に役に立つツールとなることは間違いないのです。

次のページでは、Salesforceを用いたプロトタイピングについてご説明し、何故Salesforceを用いるとプロトタイピングで要件定義をしやすくなるのかを考えてみます。

コメントを残す

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