【b→dash #06】半年後に差が出る、非エンジニアのための要件定義３つのポイント
b→dashの導入・運用に対してお悩みをお持ちの マーケターの方・その上司の方に向け、全12回に渡り解決のヒントをお伝えしていきます。
累計50社以上のb→dashプロジェクトを支援。クライアントは、金融・不動産・アパレル・食品・スポーツ球団・化粧品・人材・店舗ビジネスなど業界業種を問わず、企業規模も創業まもないベンチャー企業から大手上場企業まで幅広く担当。多種多様な観点からの助言や、豊富な経験をもとに先回りした提案を強みに、b→dash初心者がつまずきがちなポイントを強力にサポートしています。
第6回は、非エンジニアのマーケターのための『半年後に差が出る 要件定義*３つのポイント』をテーマにお届けします。ぜひ最後までご覧ください。
*要件定義：システム開発などのプロジェクトを始める前の段階で、必要な機能や要求をわかりやすくまとめていく作業のこと
前書き
非エンジニアであるマーケターのための半年後に差が出る要件定義のポイントを解説するにあたり、そもそも「要件定義」という非エンジニアにとって聞きなれない言葉について説明していきたいと思います。※ここでは、一般的なシステム開発ほどの高度な要件定義には言及せず、あくまでb→dashにおいて必要な最低限度の要件定義についてお伝えします。
私も完全未経験からb→dashの世界に飛び込んだ際に、この「要件定義」なる取り組みには本当に手を焼きました。基本的に、b→dashにおける要件定義は以下の流れで進みます。
要求の確認
課題や目的の明確化
アウトプットイメージの明確化
機能要件定義
非機能要件定義
要件定義書の作成
（データ設計）
まず、「要件」と「要求」の違いを簡単にお伝えすると、後者（要求）は「こういうことがしたい」という抽象度の高いビジネス上の目的を端的に表したもので、前者（要件）は「要求を充たすために必要となる条件」を表します。従って、「要求の確認」とは、新たに行う分析や施策において、何を達成したいのかをざっくりと確認します。
次に、より詳細に「要求」が解決したい課題や目的を明確にします。なぜならば、課題解決や目的達成の手段（＝要求）は１つではないからです。より経験豊富な担当者になれば、課題解決・目的達成のためにもっと効果的な要求を引き出してくれるかもしれません。
次に、上記を充たすためには、どのような分析用データ・施策用データが必要かを決めていきます。Excelなどを使って、実際のレポート画面のイメージや、メール配信シナリオなどを描き、最終的に必要となるデータにズレが起きないようにします。
次に、アウトプットイメージに沿って、どのようにデータを加工していけばいいかを明確にしていきます。例えば、「売上」という金額があったとしても、税込みで見たいのか、税抜きで見たいのか。値引き後の金額で見たいのか、送料はどうするのか、などを決めていく必要があります。
次に、「ｘｘ時までにレポートが最新化されてほしい」「ｘｘ時には、メール配信用のデータが最新化されて、自動で毎朝ｘｘ時にメールを配信したい」など、非機能要件（ユーザビリティ、性能、拡張性、セキュリティなど）を決めていく必要があります。
最後に、これまで決めたことをドキュメントに落とし込み、双方で検収を行います。
それでは、上記の流れを踏まえた上で、半年後に差が出る要件定義３つのポイントを見ていきましょう。
半年後に差が出る要件定義のポイントとは？①
まず何より大事なことは、『ヒアリングの型を作ること』です。
ウェブサイトの構築などのシーンでも「ヒアリングシート」というものを用意することがほとんどだと思います。予めどういった内容をクライアントに確認をすれば、社内に確認をすれば、抜け漏れなく要件定義ができるかということをヒアリングシート（ドキュメント）に落とし込んでおくことが重要です。新しい要求が生まれるたびに、また一から思い付きでヒアリングをしてしまっていては、いずれ絶対聞き漏らしたポイントが出てきて、やり直しが発生し、プロジェクトが停滞してしまいます。
ヒアリングシートなどの型が予めあれば、誰が要件定義してもある程度の品質は担保できるようになります。ヒアリングをする側も楽ですし、ヒアリングをされる側も「毎回これは聞かれるから事前に決めておかないといけないな」という感じで事前準備をすることができるようになり、品質だけではなくスピードも向上することが可能となります。
但し、型を作りさえすればいいというものではありません。そこには適切なコミュニケーションが必要となります。まず間違いなく「これ埋めておいて」だけでは相手には正しく伝わらず、雑に記入したヒアリングシートが戻ってくるだけです。また、ヒアリングシートにおいて大事なのは「解釈の余地を残さないこと」です。b→dashに限らず、仕事において起こりがちなのが「ｘｘｘだと、思っていました」という思い込みによるやり直しです。主観的な「思っていました」ではなく、「誰がどう読んだとしても、同じ理解に至る」ような型であったり、書き方であったりする必要があります。そして、そのような書き方となるよう、時には読み合わせをしながら一緒に埋めていくことも必要となります。
半年後に差が出る要件定義のポイントとは？②
半年後に差が出る要件定義のポイントとは？③
記事の続きは、非エンジニアのためのテクノロジー活用メディア『umbrElla』でご覧ください。
もし少しでも自社のマーケティング組織が当てはまっているな...と感じてしまった方は、ぜひumbrEllaに一度お悩みをぶつけてみてください。きっと何かのお役に立てるかと思います。