独学で初めての要件定義に挑むあなたへ【Salesforce】

私は現在、社内のSalesforce管理者として、要件定義から実装までを1人で担当することが多々あります。要件定義については誰からも教わる機会がなく、この2年間は試行錯誤の連続でした。

そんな中で培った経験を一度まとめてみたいと思います。同じような立場の方にとって、少しでも参考になれば幸いです。

要件定義の前に知っておくべきこと

システム開発の目的は「ユーザーの課題を解決すること」です。まずは、その課題を明確にしましょう。

例:
契約管理をスプレッドシートで行っているが、契約内容の詳細確認には契約書を見に行く必要があり、営業からCSへの引き継ぎに手間がかかっている。

一見、当たり前のように思えるこのプロセスですが、実務では具体的なシステム変更案に目が行きがちです。

例えば、ユーザーから直接、「〇〇を作って！」といった具体的な要望が飛んでくることがあります。このとき、背景を掘り下げずにそのまま実装すると、次のような問題が発生します：

こうした事態を防ぐには、具体的な要望を受け取った段階で「なぜそれが必要なのか？」と背景や解決すべき課題を掘り下げることが重要です。このプロセスを通じて、より効果的かつ効率的な解決策を提案できるようになります。

さらに言えば、「システム開発をしない」という選択肢も検討可能です。例えば、運用フローの見直しだけで課題が解決する場合もあります。

要件定義では、常に「この要件は課題解決にどう繋がるのか？」を念頭に置きましょう。これにより、プロジェクトに本当に必要な要件を見極めることができます。

要件定義の途中で新たな要求が追加されることも多いですが、課題を明確にしておけば、それらを切り分けて優先順位を適切に管理できます。

要件定義は、ユーザーがシステムの挙動を理解し、合意するためのものです。そのため、ユーザー視点で記述することが求められます。

設計以降は開発者が中心となりますが、要件定義の段階ではユーザーが納得できるよう、わかりやすさを最優先にしましょう。

文面だけで認識合わせを行い、実装後に「思っていたのと違う」と言われるのは避けたいものです。

そのため、要件定義や設計の段階から、以下のような具体的なイメージをユーザーに提示し、フィードバックを得るプロセスが重要です：

これらは「ダメ出しを受ける前提」で、作り込まず軽く作成することがポイントです。ユーザーからのフィードバックを得ながら進めることで、認識のずれを最小限に抑えられます。

要件定義は難しいプロセスですが、適切な手順を踏むことで確実に成果に繋がります。自分の経験が少しでも役立てば嬉しいです。